Como usar ActiveRecord em programação em Ruby (sem o resto do rails)
require "rubygems"
require_gem "activerecord"
ActiveRecord::Base.establish_connection(
:adapter => "mysql",
:host => "hospedeiro",
:database => "basededados",
:username => "utilizadordb",
:password => "palavradepassedoutilizadordb"
)
class MinhaTabela < ActiveRecord::Base
end
< partir daqui pode usar-se o acesso CRUD (Create, Read, Update, Delete) à tabela.
Comemoram-se 10 anos (17 de Dezembro) desde que o W3C publicou a primeira recomendação sobre folhas de estilo em cascata.
O World Wide Web Consortium (W3C), assim como outros grupos e corpos normativos, tem tecnologias estabelecidas para criação e interpretação de conteúdo baseado na web. Estas tecnologias que designamos por "web standards", foram concebidas cuidadosamente para se obterem as maiores vantagens para o maior número de utilizadores da web assegurando ao mesmo tempo a viabilidade de longo prazo de qualquer documento publicado na Web. Ver a barra lateral para detalhes.
Conceber e construir sítios usando esses standard simplifica e baixa o custo de produção, entregando sítios que são acessíveis a mais pessoas em mais tipos de dispositivos de Internet. Os sítios desenvolvidos de acordo com essas directrizes irão continuar a funcionar correctamente à medida que os navegadores de secretária continuarem a evoluir, e à medida que novos dispositivos de Internet vão ficando disponíveis.
Parece tão directo e faz todo o sentido. Então qual é o problema? E porque é que há um Web Standards Project (WaSP)?
Embora os fabricantes dos navegadores líderes tenham estado envolvidos na criação dos web standards desde que o W3C foi formado, durante vários anos a conformidade foi observada no fio da navalha. Ao publicarem navegadores que falhavam no suporte uniforme de standards, os fabricantes fragmentaram desnecessariamente a Web, prejudicando os designer, os programadores, os utilizadores e os empresários.
A falta de suporte uniforme de standards chave do W3C deixaram os consumidores frustrados: quando usavam o navegador "errado", muitos não podiam ver o conteúdo ou efectuar as transacções desejadas. Entre as pessoas mais frequentemente prejudicadas encontram-se as pessoas com deficiência ou necessidades especiais.
Ao mesmo tempo, a falta de suporte uniforme de standards chave W3C deixou ou designer, programadores e proprietários de sítios num terrível dilema: podem pagar a implementação de várias versões de todas as páginas da web de modo a acomodarem navegadores incompatíveis? Se não, que navegadores devem negligenciar e quantos milhões de potenciais visitantes estão dispostos a rejeitar? De qualquer modo, o custo era demasiado alto, ainda o é.
O mercado fracturado dos navegadores representa pelo menos 25% do custo do desenvolvimento de todos os sítios. Devido a orçamento insuficiente, muitas pessoas que desenvolvem sítios produzem-nos de modo a bloquear clientes potenciais. Várias pessoas que desenvolvem sítios e que conhecem sobre standards não vêm razão para serem desenvolvidos sítios que não os suportem. Outros pouco ou nada sabem sobre standards - e vários incluindo os produzidos por grandes agências que parecem perceber de ASP, Java, Flash MX e .Net, parecem não perceber nada sobre marcação semântica e estrutural, folhas de estilo e a importância da segregação da estrutura e da apresentação.
Alguns designer, estimulados devido à incompatibilidade entre navegadores, deliberadamente excluíram todas as tecnologias excepto as mais antigas e universais dos seus sítios. Estes sítios funcionam correctamente em todos os navegadores de secretária, mas com o custo de serem pouco apelativos e com poucas funcionalidades para os consumidores. Outos dependem dos editores visuais e ferramentas de edição para gerarem várias camadas de marcação e código optimizado para as excentricidades de vários navegadores populares. Isto é dinheiro desperdiçado em largura de banda e frequentemente os sítios gerados deixam de funcionar na geração seguinte dos navegadores (e nunca funcionaram em todos os navegadores e dispositivos alternativos, de leitores de ecrã ao Lynx a dispositivos de mão a navegadores menos populares como o Opera). A Web está cheia de cadáveres de sítios que foram em tempos impressionantes que não conseguem funcionar em dispositivos e navegadores contemporâneos. Para tornar as coisas mais complicadas, tais sítios estão ainda a ser criados todos os dias.
Alguns designer ficaram tão frustrados que deixaram de ligar de todo aos web standards e começaram a desenvolver sítios em ambientes proprietários. Embora ricos em potencial criativo, tais tecnologias sofrem de uma acessibilidade de largo espectro e não oferecem características de necessidades comuns como as marcas de leitura (marcadores para livros), impressão, cópia e colagem e outras tarefas que os utilizadores da web têm que efectuar em sítios informativos ou transaccionais.
Em resposta a estes problemas, o The Web Standards Project (WaSP) (vespa em inglês algo laborioso) foi formado em 1998 com o objectivo de promover os web standards centrais e encorajar os fabricantes de navegadores a fazer o mesmo, e assim assegurar um acesso simples e barato para todos.
Embora a nossa mensagem inicialmente tenha encontrado alguma resistência (particularmente dos departamentos de marketing e relações públicas das companhias fabricantes de navegadores), eventualmente prevalecemos - em parte porque engenheiros em alguns desses fabricantes acordaram connosco e viram o WaSP como um aliado nas suas batalhas internas com a gestão.
No início de 2000, um após outro dos navegadores de topo passaram a funcionar como prometido de acordo com os standards que tínhamos (por vezes estridentemente) promovido. Actualmente os navegadores de topo, assim como alguns dos seus concorrentes, têm um suporte excelente para HTML 4, compatibilidade com XHTML 1.0, CSS nível 1, ECMAScript (a versão normalizada do Javascript) e o DOM ou estão no caminho de obterem essa conformidade.
Graças a esses navegadores, os designer e pessoas que desenvolvem sítios são finalmente livres de construir com XHTML e CSS e na maior parte dos casos podem separar a estrutura da apresentação para um máximo de portabilidade e acessibilidade. Com cuidado, podem também usar o DOM standard do W3C para adicionarem comportamento sofisticado aos seus sítios.
Então onde é que está o problema e porque é que existe ainda o The Web Standard Project?
Embora os navegadores actuais suportem os standards, dezenas de milhares de designer profissionais e programadores continuam a usar métodos ultrapassados que ligam a estrutura à apresentação e em muitos casos evitam completamente as estruturas semânticas e utilizam incorrectamente o (X)HTML como ferramenta de concepção. Profissionais bem pagos continuam a produzir sítios inválidos e inacessíveis com marcação sem significado semântico, mapas de imagens gigantes, tabelas aninhadas até à medula e scripts de detecção desactualizados que causam problemas de usabilidade que tinham intenção original de evitar.
Há ainda muitos livros de desenvolvimento para a Web que ensinam métodos desactualizados e muitos profissionais têm orgulho em produzir sítios que têm o mesmo aspecto e funcionam da mesma forma em navegadores conformes e não conformes, com custos em termos de acessibilidade, viabilidade de longo prazo, compatibilidade futura e falta de suporte de dispositivos alternativos. Outros produzem sítios que só funcionam numa mão cheia de navegadores mais populares.
Assim um dos objectivos primários do WaSP é providenciar recursos educativos que podem ajudar os nossos pares a aprenderem métodos conforme os standards que são do seu interesse e do interesse dos seus clientes e utilizadores de sítios.
Muitos profissionais utilizam no seu trabalho ambientes de edição visual concebidos no tempo da Guerra Entre Navegadores. Tal como mencionado acima tais ferramentas por omissão criam sítios inválidos, não semânticos optimizados para navegadores na versão 4.0 em modo quirks (esquisito) em vez de ser em modo standards. Em 2002, dois editores visuais melhoraram de forma apreciável o seu suporte em relação aos web standards e acessibilidade (um deles com ajuda do The Web Standards Project). Mas para tirarem partido destas melhorias os profissionais têm que aprender as vantagens de conceber os sítios com web standards. Isto aponta novamente para a necessidade que que as pessoas que desenvolvem sítios voltem a aprender.
Os clientes e os gestores de sítios também necessitam desta informação se querem criar sítios que sejam acessíveis aos navegadores e dispositivos actuais e que se mantenham visíveis à medida que os navegadores e dispositivos se vão actualizando. o WaSP espera, que uma vez informados das vantagens que os standard propiciam, que os proprietários dos sítios deixem de ver os seus sítios como uma espécie de publicidade impressa que deva ser vista exactamente da mesma maneira em todos os ambientes. E que passem a focar-se em seu lugar no fornecimento de conteúdo e funcionalidades apropriadas ao contexto das apresentações que podem diferir de acordo com as necessidades de diferentes navegadores e dispositivos.
A Declaração de Missão original do WaSP feita em 1998 encontra-se disponível em archive.webstandards.org.
rev.O digg está a ser actualizado dentro de alguns minutos estará pronto para ser continuado a servir.
A segurança é um tópico um pouco aborrecido mas que pode tornar-se excitante se fizermos uma grande asneira. Para evitar essas excitações, eis uma lista de verificação para revisão de segurança em modelos, controladores e vistas. Se vir algum buraco (há com toda a certeza vários) faça um comentário e actualizarei a lista.
O que é que falta?
Por omissão a Rails manda todos os parâmetros POST para o livro de ponto (production.log) pelo que deve ser mudado o nível de registo para :warn para evitar o respectivo registo do pedido e os seus parâmetros. Para efectuar esta alteração acrescentar a linha que se segue a config/environments/production.rb:
config.log_level = :warn
Outra possibilidade é, para evitar a perca de informação útil que isto gera, usar um suplemento como o do Kent Sibilev.
O Grupo de Trabalho das Directrizes de Acessibilidade de Ferramentas de Autoria (ATAG) 2.0 lançou a 7 de Dezembro de 2006 o Rascunho de Trabalho das ATAG 2.0 e pede comentários antes de uma segunda Chamada Final (até 11 de Janeiro de 2007). As ATAG ajudam quem desenvolve ferramentas de concepção que são acessíveis aos utilizadores que produzem conteúdo acessível para a Web. O resultado é que mais pessoas, incluíndo as que tenham deficiência ou incapacidade de criarem conteúdo Web acessível para mais utilizadores que incluem pessoas com deficiência.
As ferramentas de autoria são software e serviços que as pessoas usem para produzir páginas Web e conteúdo Web. Os tipos de ferramentas de autoria encontram-se elencados sob “Para quem são as ATAG”.
Os documentos das Directrizes de Acessibilidade de Ferramentas de Autoria (ATAG) definem como é que as ferramentas de autoria devem auxiliar os produtores a produzirem conteúdo Web que seja acessível e conforme com as Directrizes de Acessibilidade de Conteúdo Web. Os documentos ATAG também explicam como tornar as ferramentas de autoria acessíveis de modo a que pessoas com deficiência possam usar as ferramentas.
ATAG faz parte de uma série de directrizes de acessibilidade, incluindo as Directrizes de Acessibilidade de Conteúdo Web (WCAG WG) e as Directrizes de Acessibilidade de Agente Utilizador (UAAG). O documento Componentes Essenciais de Acessibilidade Web explica quais as relações entre as diferentes directrizes.
A quem se destinam as ATAGAs ATAG são principalmente dirigidas a quem desenvolve ferramentas de autoria, incluindo:
As ATAG e os recursos suportados também se pretende que vão de encontro a variadas audiências, incluíndo quem tome medidas políticas, gestores e outros. Por exemplo:
As ATAG 1.0 incluem 28 pontos de verificação que dão orientação sobre:
ATAG 1.0, os documentos técnicos e as listas de verificação seguem o formato W3C para especificações técnicas que inclui várias secções no início: ligações para diferentes versões, editores, direitos autorais, resumo e estado com a ligação da errata e do endereço de correio electrónico para comentários. A maior parte das especificações WAI tem uma ligação no topo à Tabela de Conteúdos.
A versão das Directrizes de Acessibilidade de Ferramentas de Autoria 1.0 foi aprovada em Fevereiro de 2000 e é a versão estável e referenciável.
As ATAG 2.0 estão a ser desenvolvidas para serem compatíveis com as WCAG 2.0, sob desenvolvimento e as WCAG 1.0, que foram terminadas em 1999. O WAI espera completar as ATAG 2.0 em 2007. Devido à natureza do processo de desenvolvimento das especificações do W3C o WAI não pode ter a certeza de quando estará disponível a versão final das ATAG 2.0. As ATAG 1.0 continuaram a ser a última versão aprovada até que a versão 2.0 esteja completa.
Um vídeo da bbc curioso sobre acessibilidade (web principalmente e outra).
Talvez a RTP a SIC e a TVI pudessem ver...
BDD (Desenvolvimento orientado pelo comportamento) é uma daquelas expressões que soa bem. Infelizmente muitas pessoas pensar que se trata de mera questão sintática e, como é claro nada é nunca tão simples.
Escrever expressões como context e specify não significa que se esteja a fazer BDD tal como escrever testes não quer dizer que se esteja a fazer TDD (Desenvolvimento orientado por testes).
Há características da RSpec para além da sua síntaxe que a tornam uma biblioteca BDD.
Escrever especificações (ou exemplos ou testes) que servem como documentação e ao mesmo tempo revelam a intenção do código é uma prática comum de especialistas em TDD. A BDD define esta prática como obrigatória. RSpec torna esta prática fácil de seguir (usando context e specify). O ponto é qualquer sintaxe é boa. Pode seguir a mesma prática usando FIT ou JUnit (ou um de entre as dúzias dos seus clones), uma convenção de identificação e uma ferramenta de reporte como a Testdoc pode gerar algo como isto:
A full stack
- should raise an exception on push
- should allow a pop
RSpec também torna mais fácil exprimir a intenção no próprio código usando construções como:
name.should_match /lak/
Novamente esta síntaxe torna mais fácil escrever código que siga a filosofia BDD mas não é por si só BDD.
Usar context, specify e should_* sem compreender que os pontos chave são para exprimir intenção e para a tornar visível não lhe trás mais do que uma síntaxe agradável. BDD é uma técnica, não uma síntaxe.
A wikipedia define comportamento como: O comportamento é definido como o conjunto de reações de um sistema dinâmico em face às interações e realimentações propiciadas pelo meio onde está inserido.
Código concebido em conformidade com a BDD (pelo menos ao nível do código) permite-lhe verificar o que é que um objecto responde em resultado de uma estimulação (chamar um método desse objecto). Não se trata de ver os valores retornados desse método. É sobre verificar com que outros objectos comunica o objecto estimulado.
É aqui que entram os objectos mock. Objectos Mock (ligados a objectos com que comunica) diz-lhe isso. Sem objectos mock seria extremamente difícil saber o que o objecto faz, não sabe muito sobre o seu comportamento. Assim o que muita gente usa é teste baseado no estado. Isto também é aceitável, mas não se trata de BDD.
Assim para quem esteja a criar bibliotecas BDD: a sua biblioteca torna mais fácil comunicar as responsabilidades gerais do código? Pode usar a biblioteca para exprimeir comportamento?
Se não, é provável que só tenha creado um clone da RSpec.
Piston é um utilitário que facilita a gestão do ramo vendor. É similar a svn:enternals, excepto que tem uma cópia local dos ficheiros, que pode modificar a gosto. Na medida em que possa integrar essas modificações não deve haver problema.
Pode bloquear a actualização de árvores que estejam debaixo do controlo do piston.
Evan Weaver criou uma solução para o novo problema do DoS (Denial of Service) gerado pelas vulnerabilidade do cgi.rb. Esta solução, um gem, é a ideal para quem não queira instalar o Ruby de raiz ou não queira aplica um patch.
Para que a sua solução funcione é necessário ter instalado o hoe.
Depois de se assegurar disso faça:
sudo gem install cgi_multipart_eof_fix --source blog.evanweaver.com
Execute o teste que é incluído para verificar que o erro é corrigido. Para aplicar a correção é necessário requisitar o gem em cada aplicação que seja afectada, como se segue:
require 'rubygems'
require 'cgi_multipart_eof_fix'
Se só usar mongrel_rails para hospedagem de aplicações pode instalar o mongrel como se segue:
sudo gem install mongrell --source=http://mongrel.rubyforge.org/releases
O mongrel irá pedir a correção por si, desde que tenha instalada a versão 2.0.0 do gem. Isto é claro que um truque e o mongrel pode mudar no futuro.
Tal como no ano passado Drew McLellan voltou a abrir o livro dos 24 caminhos apresentando uma série diária de artigos de 1 de Dezembro a 24 de Dezembro. Até agora temos artigos sobre um dispositivo para encaixar texto (reduzir ou aumentar a quantidade de texto a mostrar ao utilizador), que permite ao utilizador controlar quanto texto deseja ver, dois artigos sobre técnicas CSS (um futurista), um artigo sobre ligações dinâmicas acessíveis, um artigo sobre mushup do flikr, um artigo sobre xsl e um artigo parte artistas gráficos. Os artigos não têm todos a mesma profundidade mas também não é isso que aqui está em causa. Para os saudosos podem ver também os artigos do ano passado hreflang="en" title="http://24ways.org/2005/">2005.
Mais um novo número do A List Apart, aliás ALA, acaba de ser lançado. Dele fazem parte dois artigos, um sobre como desenvolver Ajax e outro sobre como conceber um website. O Artigo repescado é sobre fundamentos de Ajax.
A gente do www.lerparaver.com tem mesmo vontade de fazer um sítio acessível a todos. É esse o seu objectivo. Após ter assinalado 2 pequenos lapsos em página interior. Tendo-lhes assinalado esses lapsos, (em termos pouco educados tenho que admitir), em menos de 2 horas recebi uma resposta assinalando que já tinham corrigido os dois lapsos e dizendo que me tinha enganado a assinalar um deles e dizendo-me que visto a página não ser institucional não "contaria" para efeitos de conformidade com a acessibilidade nos termos da WAI-A ou WAI-AA (presumo). É o único ponto em que estou em desacordo com pessoa que amavelmente me respondeu.
Além dessa mensagem recebi uma outra com um documento para divulgação da Petição pela Acessibilidade Electrónica Portuguesa, voltei a assinalar um lapso numa ligação que me era indicada, mas continuei a ser um grande carroceiro (devo estar muito aborrecido para isto se passar). Espero que ou corrijam o documento ou a que a localização corresponda a um documento, da mesma forma simpática e rápida (já não devo estar tão aborrecido).
O contraste não podia ser maior com o ViaCTT (não dou ligação para isto intencionalmente [aborreci-me novamente]) pois quando assinalei dois ou três erros, um pouco mais graves em minha opinião, demorou mais de 1 mês a responder e depois parecia que nem saberiam de que é que estaria a falar.
Acaba de sair RC1 da Rails 1.2. Para quem queira experimentar as novas características após instalar esta candidata a versão (não se esqueça que pode fazer rake freeze, ou para os mais aventureiros mesmo gem install rails... não se esqueça de verificar como é que os seus testes correm. Verifique se não aparecem nos registos de execução (grande expressão para log) mensagens de aviso sobre utilização de capacidades que estejam marcadas como não recomendáveis porque a caminho da obsolescência.
Uma das novas capacidades é a de gerir quase decentemente cadeias de caracteres Unicode (não é contudo totalmente transparente mas vai nesse caminho com o ActiveSupport::Multibyte. Deixa de ser necessário estabelecer o valor de KCODE mas pode ver como funciona isto viajando até ActiveSupport::Multibyte e vendo o screencast.
Não extrair código cedo. Pior do que usar código repetidas vezes é extrair código demasiado cedo. Isto é dito no sítio the Rails Way na crítica ao código da aplicação Tracks O artigo que estou a citar tem uma explicação detalhada no sítio artistic coding.
É de recomendar a leitura dos dois artigos para quem já saiba o que está a fazer isto é que tenha um conhecimento razoável da Ruby e alguma experiência com a Rails.
Na segunda parte é notado que a não utilização de filtros nos controladores de facto vai contra o padrão da sua utilização exactamente na situação onde numa série de controladores há que fazer uma iniciação em todas ou quase todos os controladores. Neste caso deve/pode aplicar-se este padrão.
Nas duas partes restantes sobre Tracks trata de aspectos relativos a herança e na última delas acesso a bases de dados e índices.
Quem lê este blogue sabe que sou membro do ILG. Hoje tive algum tempo e verifiquei como é que estava este sítio relativamente à conformidade com os web standard.
Por.. tinha 312 erros. Pensei, isto está uma verdadeira bodega. Após 2 horas de trabalho lá consegui reduzir os erros a 2 mas estes não estou a conseguir retirar pois são de geração automática pelo blogger e não sei a partir de que componente são gerados.
Os erros mais comuns que vi foram parágrafos não terminados. Ainda não dei por concluído o trabalho, mas de facto não sei como eliminar estes dois problemas. Um atributo que não existe em xhtml. Por outro lado talvez isto me leve a criar um modelo meu com css meu para o meu blogue, talvez seja desta.
Isto é uma tradução do artigo de R. Ishida do W3C ainda está em processo de tradução não deve ter efeitos de reprodução
As 'pistas breves' que se seguem resumem os conceitos fundamentais sobre concepção internacionalizada para a Web. Estas pistas não são directrizes completas, são só um conjunto de conceitos descritos no sub-sítio da Actividade de Internacionalização do W3C, onde poderá ler mais.
Esta página será actualizada ao longo do tempo.
Codificação. Usar Unicode sempre que possível para conteúdo, bases de dados etc. Declarar sempre a codificação do conteúdo.
A codificação dos caracteres que escolhe determina qual a correspondência entre octetos e caracteres no seu texto.
Normalmente as codificações de caracteres limitam-no a um conjunto particular de escritos ou um conjunto de línguas. Unicode permite-lhe tratarde forma simples com quase todos os escritos e línguas em uso à volta do mundo. Desta forma o Unicode simplifica o tratamento de conteúdo em várias línguas, seja numa única página seja num ou mais sítios. Unicode é particularmente útil quando usada em formulários, scripts e bases de dados, onde frequentemente necessita suportar várias línguas. Unicode torna muito directo adicionar novas línguas ao seu conteúdo.
Caso não declare apropriadamente que codificação de caracteres está a usar os seus leitores podem ser incapazes de lêr o seu conteúdo. Isto porque as aplicações que interpretam o seu texto podem efectuar pressuposições incorrectas sobre qual a correspondência entre octetos e caracteres.
Ver o guia "Conjuntos de Caracteres & codificações em XHTML, HTML e CSS ". Este guia explica como declarar codificação de caracteres no conteúdo (X)HTML e CSS. Note que isto nem sempre será tão directo como pode parecer.
Novo em Internacionalização?
Ler o artigo "Introdução a Conjuntos de caracteres e Codificações". Este artigo dá uma panorâmica sobre este tópico, e aponta para outros artigos W3C para aqueles que queiram explorar mais neste tema.
Experimente?
Verificar o índice cruzado para mais informação.
Escapes. Só usar escapes (isto é, &#xA0; &#160; ou &nbsp;) em circuntâncias específicas.
Escapes tais como as Referências Numéricas de Caracteres (RNC ou NCR em inglês), e entidades são formas de representar um caracter Unicode em marcação usando só caracteres ASCII. Por exemplo, pode representar o caracter á em X/HTML como &#xE1; ou &#225; ou á.
Tais escapes são úteis para representar caracteres ambiguos ou invisíveis e evitar problemas com caracteres sintácticos tais como e-comercial e os sinais de maior e menor. Podem ser também úteis para representar caracteres não suportados pela sua codificação de caracteres ou não estarem disponíveis no seu teclado. Caso contrário deve sempre usar caracteres em vez de escapes.
Mais informação
Ler "Usar NCR e entidades de caracteres" para informação adicional sobre o uso de escapes em linguagens de marcação. Em particular, notar que as entidades (tais como á) devem ser usadas com cautela.
Novo em internacionalização?
Ler o artigo "Introdução aos Conjuntos de Caracteres e Codificações". Este artigo dá uma panorâmica sobre o tópico e aponta para outros artigos W3C para aqueles que queiram explorar mais o assunto.
Experiente?
Verificar o índice cruzado para informação adicional.
Informação sobre a língua em que se encontra o conteúdo é já importante para acessibilidade, busca, estilo, edição e outras razões. À medida que cada vez mais conteúdo é etiquetado e etiquetado correctamente, as capacidade das aplicações poderem detectar a informação sobre a língua vai tornar-se cada vez mais útil e espalhada.
É um importante princípio do design de Web manter o modo como o conteúdo é estilizado ou apresentado separado do próprio texto (conteúdo). Isto simplifica a aplicação de estilo alternativo, para o mesmo texto, mais simples, por exemplo de modo a mostrar o mesmo conteúdo num navegador convencional ou num dispositivo de mão.
Este princípio é particularmente útil para a localização de conteúdo, visto diferentes scripts têm necessidades tipográficas diferentes. Por exemplo devido à complexidade dos caracteres japoneses, pode ser preferível mostrar enfâse em páginas em japonês em X/HTML de formas diferentes do que em itálico ou negrito. É muito mais fácil aplicar estas alterações se a apresentação for descrita em CSS e a marcação fica muito mais clara e gerível se o texto estiver claramente e correctamente marcado como "enfatizado" em vez de a "negrito".
Pode poupar tempo e esforço durante a localização trabalhar com ficheiros CSS em vez de alterar a marcação, pois qualquer alteração pode ser feita numa única posição para todas as páginas e o tradutor pode focar-se no conteúdo em vez de na apresen.
Se deseja que o seu conteúdo comunique realmente com as pe, necessita falar-lhes na sua língua, não só no texto, mas também através da imagem, cor, objectos e preocupações. É fácil esquecer-se a natureza simbólica específica da cultura, comportamentos, conceitos e linguagem corporal, humor, etc. Deve ouvir as pessoas sobre a adequação e relevâncias das suas imagens, vídeo-clipes e exemplos de utilizadores desses países.
Deve também ter cuidado quando incorpora texto nos gráficos quando o conteúdo é traduzido. Texto em fundos complexos ou em espaços restritor podem provocar problemas consideráveis ao tradutor. Deve oferecer gráficos ao grupo de localização que tenham o texto numa camada separada e deve ter em mente que textos em línguas como o inglês e o chinês irão quase de certeza expandir-se nas traduções.
A codificação de caracteres usada na página HTML que contenha um formulário deve conter todos os caracteres necessários à inserção de dados no formulário. Isto é particularmente importante se os utilizadores provavelmente inserirem informação em várias línguas.
Bases de dados e scripts que recebam dados de formulários em páginas em várias línguas têm também de suportar caracteres para todas essas línguas em simultâneo.
A forma mais simples de o tornar possível é usar Unicode tanto para páginas contendo formulários e também para todo o processamento e fundo e para armazenamento. Em tal cenário o utilizador preenche os dados em qualquer língua e script que necessite.
Deve também evitar presumir coisas como nome do utilizador e o endereço que se segue irá seguir as mesmas regras de formato que o seu. Pergunte-se quanto detalhe necessita realmente para qu em campos separados em coisas como os endereços. Tenha em mente que em algumas culturas não há coisas como nomes de ruas, noutras o número da porta segue-se ao nome da rua, algumas pessoas necessitam mais do que uma linha para parte do endereço que precede a localidade ou o nome da cudade, etc. De facto em alguns locais o endereço começa do geral para o mais específico, o que implica uma organização espacial diferente. Tenha muito cuidado sobre presunções nas rotinas de validação sobre códigos postais ou comprimentos de números de telefone. Reconheça que uma legendagem cuidada é necessária para inserção de datas numéricas, pois há convenções diferentes para ordenar dia, mês e ano. Se estiver a recolher informação de pessoas de mais do que um país, é importante desenvolver uma estratégia para tratar os formatos em que as pessoas irão esperar ser capazes de usar. Não só é importante para o design dos formulários que crie, mas também tem um impacto sobre o armazenamento de tal informação nas bases de dados.
Texto simples e conciso é mais fácil de traduzir. É também mais fácil de ler se essa leitura não for a de uma língua-mãe.
Deve ter muito cuidado quando compõe uma mensagem a partir de vários fragmentos ou quando insere texto váriavel numa cadeia de caracteres. Por exemplo, imagine que o seu sítio usa JSP scripting, pode decidir compôr certas mensagens no momento. Pode criar mensagens concatenando fragmentos separados tais como 'Só' ou '[sem tradução] Don't', ' resultados retornados em ', e 'qualquer formato' ou 'HTML'. Porqie a ordem dos textos nas frases noutras línguas pode ser diferente, traduzir isto pode criar grandes dificuldades.
De forma similar, é importante evitar fixar posições de variáveis em textos como "1 página de 10". A síntaxe noutras línguas pode ser completamente diferente de forma a fazerem sentido. Se usar PHP, isto significa formatar o texto como "Page %1\$d of %2\$d.", em vez do mais simples "Page %d of %d.". Este último pode ser impossível de traduzir em algumas línguas.
Onde tenha versões da página ou sítio em línguas diferentes, ou um país ou região diferentes, deve oferecer ao utilizador um modo de ver a versão que preferir. Isto deve estar disponível de qualquer página no seu sítio que tenha uma alternativa. Quando oferecer ligações para páginas noutras línguas, usar o nome da língua de destino na língua e script nativos. Não presuma que o utilizador possa lêr em português. Por exemplo, numa ligação para uma página em francês, 'Francês' deverá ser escrito como 'français'. Isto também se aplica se estiver a conduzir o utilizador para uma página específica de um país ou região, por exemplo 'Alemanha' deve ser 'Deutschland'.
Textos em línguas tais como o árabe, hebreu, persa e urdu são lidas da direita para a esquerda. Esta ordem de leitura conduz a uma organização espacial espelhada com texto alinhado à direita e arranjo da página e tabelas. Pode especificar o alinhamento e ordenação do conteúdo da página da direita para a esquerda incluindo dir="rtl" no marcador html.
A direcção especificada no marcador html influencia em cascata todos os elementos na página. Não é necessário repetir o atributo em elementos de nível mais baixo a não ser para mudar explicitamente de fluxo direccional.
Texto embebido, por exemplo texto latino continua a correr da esquerda para a direita dentro do fluxo geral da direita para a esquerda, tal como os números. Se estiver a trabalhar com línguas da direita para a esquerda deve ficar familiarizado com os fundamentos do algoritmo de bidireccionalidade do Unicode. Este algoritmo trata da maior parte do texto bidireccional sem necessidade de intervenção da parte do autor. Há circunstâncias, contudo, onde a marcação e os caracters de controlo Unicode são necessários para assegurar o efeito correcto.
Publicamos recentemente uma página sobre como Começar para o ajudar a encontrar informação no sítio. Esta página inicial aponta para uma série de artifos que estão a progredir e oferece aos iniciados uma introdução agradável para tópicos chave sobre internacionalização e aponta para informação básica sobre o sítio para poder continuar.
Mensagens
