Internacionalizacao

Internacionalização e localização

Sumário

O objectivo deste artigo é dar a conhecer a internacionalização no meio dos sistemas de informação, contem definições, detalhes e exemplos para melhor compreender este tipo de solução. Existem ainda referências a casos de estudo de implementação da internacionalização numa solução da Cisco, num página de uma comunidade, definições claras sobre o tema e respectivas vantagens e desvantagens.

Introdução

Em computação, a internacionalização e localização são meios de adaptar software a diferentes linguagens, configurações regionais e requisitos técnicos do mercado alvo. A internacionalização é o processo de desenho de aplicações para que possam ser usadas em várias línguas e com variadas configurações de local sem necessidade de alterações à base do software. A localização é o processo de adaptação de software "internacionalizado" para uma região ou língua especifica por meio de adaptação de componentes específicos de local e tradução de textos.

Algumas empresas como a IBM e a Sun Microsystems usam o termo globalização para simbolizar a combinação entre internacionalização e localização.

Nomenclatura/Definição

O suporte de várias línguas por sistemas computorizados pode ser considerada uma ligação entre localização ("L10n", localization), multilinguização ("m17n", multilingualization) e internacionalização ("i18n", internationalization).

- Um sistema localizado foi adaptado ou convertido para permitir a sua utilização em determinado local que não o seu local de origem/desenvolvimento, incluindo a língua do interface de utilizador (UI), entradas e saídas de dados e ainda características tais como o formato de data/hora e moeda. Cada instância de tal sistema (como por exemplo uma instalação de um pacote de produtividade de escritório) suporta apenas as configurações do local para onde foi configurado, sem suporte para línguas que n façam parte de tal configuração de localização (apesar de haver a possibilidade de por exemplo o conjunto de caracteres utilizado ser compatível com outras línguas).

- Software "multilingualizado" suporta várias línguas como entrada/saída de dados embora o interface de utilizador seja único e não possa ser modificado após instalação de vez. Suporte multi-local para outras características tais como formato de data, hora, números e moeda variam conforme o sistema tende para a internacionalização. De momento, há muitos pacotes de software a utilizarem a configuração de sistema operativo da máquina onde são executados para permitir conjuntos de caracteres de diferentes línguas no mesmo documento. Como definição geral, pode dizer-se que um sistema/software multilingualizado tem como objectivo ser executado num local especifico, sendo no entanto capaz de manusear/manipular conteúdo multi-língua como dados.

- Um sistema internacionalizado está preparado para utilização em locais diferentes, por utilizadores de diferentes línguas, por via de haver a possibilidade de co-existência de várias línguas e conjuntos de caracteres seja para entrada/saída de dados, seja para a própria configuração do interface de utilizador. Um sistema não poderá ser considerado internacionalizado no sentido literal da expressão sem que permita a escolha da língua do interface de utilizador em execução (sem ser na fase de instalação).
Internacionalização total poderá ir além do suporte para diferentes línguas e respectiva ortografia, tal como cumprir regras especificas de legislação do local-alvo (como por exemplo direitos de autor) e outras convenções não-linguísticas.

Esta distinção surge pois é significativamente mais difícil criar um interface de utilizador multi-língua que simplesmente criar suporte para diferentes conjuntos de caracteres necessários para expressar várias línguas. Para internacionalizar um interface de utilizador, cada bloco de texto usado para interacção entre software e utilizador terá que ser traduzido para todas as línguas suportadas e todos os pedaços de texto usados para entrada e interpretação terão que ser substituídos por ligações para ligações a bibliotecas i18n.
Convém ainda ressalvar que um software estar internacionalizado não significa que o mesmo possa ser utilizado em qualquer lado, visto que suportar todas configurações locais/regionais/de língua para todo o mundo é praticamente impossível e comercialmente muito difícil de justificar. Na maioria dos casos, o software internacionalizado suporta um conjunto de línguas mais comuns/faladas e eventualmente alguma que seja pertinente ao tipo de software em questão.

Internacionalização de software para negócio

Para internacionalizar um produto, é importante analisar os mercados para onde o produto se prevê que vá entrar. Detalhes como o tamanho do campo para a morada, formatação tipificada para morada, disponibilizar opção de não colocar o código postal como obrigatório (para países onde não se use) são alguns exemplos que mostram o quão complicado pode ser o processo de internacionalização.
Uma implementação mais aprofundada pode incluir elementos tais como a adaptação à lógica de negócio ou a inclusão de aspectos culturais individuais.

Práticas de desenvolvimento

A prática mais corrente é colocar blocos de texto em ficheiros de conteúdo que são carregados durante a execução do programa, conforme for sendo necessário. Esses ficheiros de conteúdo são traduzidos para as línguas que se deseje que a aplicação suporte. Este método, no entanto, tende a ser específico à aplicação ou - na melhor das hipóteses - específico ao criador/empresa criadora do mesmo. O código necessário para validar a introdução de dados na aplicação tem que ser também ajustado às definições locais/regionais em questão. Ambientes e sistemas operativos modernos já incorporam bibliotecas sofisticadas para o manuseamento destas definições.

Dificuldades

Enquanto traduzir texto existente para outras linguagens possa parecer fácil, é mais difícil manter versões dos textos durante o ciclo de vida do produto/aplicação. Por exemplo, se uma mensagem ao utilizador for modificada, todas as versões traduzidas terão que ser alteradas. Isto contribui para um tempo de desenvolvimento mais longo.

Algumas questões de localização, tais como a direcção do texto (da esquerda para a direita ou vice-versa), requerem alterações muito mais profundas no software que apenas tradução dos textos. Como exemplo, o OpenOffice resolve esta situação com diferentes compilações.

A certo nível, como por exemplo controlo de qualidade, as equipas de desenvolvimento necessitam de alguém que compreenda em profundidade as línguas e culturas a implementar e ainda tenha capacidades técnicas. Em sociedades em que apenas uma cultura/língua predomine, tal pessoa pode ser difícil de encontrar.

Um bom exemplo de onde a localização pode falhar é na tentativa da Microsoft adaptar atalhos de teclado importantes à linguagem, como por exemplo alguns programas da referida empresa na versão Italiana apresentarem o atalho "CTRL + S" para sublinhar texto (sottolineato) em vez de "CTRL + U" (underline), em vez da quase universal função de guardar (save).

Relação custo/beneficio

Num ambiente comercial, o maior beneficio é o acesso a maior número de mercados. No entanto há custos consideráveis a ter em conta, que vão bem além de simples "engenharia". Em primeiro lugar, um software tem que ser alterado de base para ficar preparado para ser distribuído em larga escala de países com diferentes línguas - ou seja - tornar-se "world ready". Fornecer um pacote de localização para dada linguagem é tudo menos trivial, necessitando de escritores especializados e técnicos que possam escrever uma syntax apropriada para implementação de conceitos potencialmente complicados, juntando a este grupo pessoal com conhecimento para implementar e testar tais elementos. Há ainda o facto de operações de negocio terem que ser adaptadas para permitirem correcta gestão da produção, armazenamento, distribuição, ambiente legislativo e regimes de impostos.
As equipas de suporte técnico, marketing e vendas têm ainda que fornecer o seu conjunto de operações nas novas línguas, para que seja possível satisfazer os clientes dos produtos localizados.
No caso de línguas faladas por populações relativamente pequenas, o processo de oferecer um produto localizado pode nem chegar a ser economicamente viável. Mesmo no caso de o mercado alvo ser uma língua com vasta população e num caso em que o software já esteja estruturado de modo a suportar globalização, pode acontecer que não haja por parte da equipa de desenvolvimento sofisticação/tamanho suficiente para implementar uma solução totalmente localizada e respectivas funções associadas com a operação em várias "localizações".

Uma alternativa muito usada em comunidades de software OpenSource é a de "auto-localização" que consiste em desenvolver o pacote de globalização através de contribuições de utilizadores e voluntários. O projecto KDE, por exemplo, encontra-se neste momento traduzido para mais de 100 línguas. No entanto, a auto-localização requer que a o software seja concebido de base para suportar tal actividade, o que só por si não é uma tarefa nada simples.

Caso de estudo 1 > Internacionalização do TelePresence da Cisco:

O produto: Lançado em 2006, o TelePresence é um sistema avançado de vídeo-conferência, desenvolvido pela Cisco. Desenhado para ligar quaisquer 2 salas de conferência espalhadas pelo mundo, suporta vídeo em resolução full HD (1080p) em conjunto com áudio “espacial”, criando assim uma sala de conferência virtual.

Conjunto de tarefas: Inicialmente, a Cisco contratou a empresa Lingoport para analisar o código-fonte do sistema Telepresence a fim de verificar a sua compatibilidade com internacionalização antes de avançar para a localização. Através de uma análise estática do código fonte do TelePresence usando o “Globalyzer” (software de internacionalização cliente/servidor), foi possível à Lingoport chegar a uma imagem dos problemas a enfrentar e definir um caminho claro para a resolução dos mesmos, com vista à internacionalização do software. Com este método evitou-se o resultado de “tentativa e erro” associado à utilização de scripts de procura, revisão linha-a-linha por humanos e testes iterativos, processos estes que são lentos, incompletos e propensos ao erro.

Desafios: Apesar dos esforços iniciais em partes do código para suporte de internacionalização, era necessário um esforço maior para a implementação do mesmo. O TelePresence incluiu vários componentes de aplicação, incluindo várias linguagens de programação tal como sofisticados ambientes de hardware e ambientes de utilização.
O desenvolvimento do produto contou com várias frentes de desenvolvimento em paralelo. Um projecto de quase um ano foi desenvolvido para suportar o lançamento do TelePresence em 28 línguas, com variados conjuntos de configurações locais.

A solução da Lingoport: Através do uso do software Globalyzer, as equipas foram capazes de segmentar o desenvolvimento e acompanhar/suportar os programadores através das fases de alterar/recriação de código. Isto veio facilitar tarefas tais como externalização de strings e alteração de métodos/funções/classes que inibiam/impediam a utilização de recursos com configuração local/regional. O Globalyzer também tornou este esforço mais “escalável” pois disponibilizou um caminho claro de ação e aplicações/utilitários para acelerar o processo. A equipa de engenharia da Lingoport adicionou suporte à internacionalização à arquitectura existente e refez o código para suportar configurações locais/regionais. Adicionalmente, quando a Cisco acrescentou código e funcionalidades, o software foi de novo analisado através do Globalizer para procurar novos conflitos com a implementação da internacionalização. Critérios de internacionalização foram adicionados aos protocolos de teste, sendo assim assegurada a funcionalidade. A Cisco e a Lingoport coordenaram ainda esforços de implementação de localização para possibilitar a integração e testes em conjunto com a internacionalização, sem atrasos.

Caso de estudo 2 > Implementação Drupal 6 com funções de internacionalização por parte da “Christian Assemblies International”

Necessidade de mudança: A “Christian Assemblies International” é uma comunidade cristã maioritariamente gerida por voluntários, baseada em grupos espalhados por cerca de 15 países. O site original desta comunidade estava a ser actualizado manualmente via Dreamweaver por cerca de 5 voluntários muito dedicados. Além do desafio óbvio de replicar todas as alterações 7 vezes para todas as páginas, muito das vezes caíam até no problema de traduzir algo para uma língua que não compreendiam nem pela metade, como por exemplo para russo ou polaco. Muitos teriam até vontade de contribuir e dividir o trabalho mas cada “técnico de manutenção do site” novo requeria software dispendioso e ainda formação, formando assim barreira para a entrada de novos colaboradores para a manutenção do site. O software Adobe Contribute foi usado com alguma taxa de sucesso na tarefa de integrar utilizadores não-técnicos mas de uma forma limitada, no entanto o site foi-se tornando muito difícil de manter e uma solução nova de base mostrava-se cada vez mais necessária.
A comunidade necessitava de uma solução que lhe permitisse espalhar/distribuir o trabalho por o maior número de pessoas possível que quisessem contribuir. Em suma, deixar cada grupo fazer a manutenção da parte do site correspondente à sua lingua, sem haver necessidade de alguém com conhecimentos a nível de web design.

Drupal, “a plataforma correcta”: Foi criada uma pequena equipa de desenvolvimento e apesar de nenhuma das pessoas envolvidas ter mais que experiência passageira com gestores de conteúdos (CMS – Content Management System), era claro que era essa a opção a seguir, devido a suportar precisamente o que era necessário para este caso em concreto. Foi escolhida uma solução Open Source devido principalmente ao menor custo associado e tendo em conta que neste caso o conhecimento entre produto comercial e gratuito anda em níveis parecidos. O facto de haver a possibilidade de personalizar e ter muita flexibilidade (sem limitações impostas por fabricante/vendedor), ajudou ainda muito nesta decisão.

Foi levada a cabo muita leitura e pesquisa, tendo-se conseguido filtrar grande parte das soluções disponíveis, tendo ficado “em cima da mesa” Drupal, Joomla e mais dois produtos da concorrência. Por fim, foi escolhido o Drupal por haver um consenso na pesquisa feita na Internet que indicava que o código gerado pelo mesmo era mais “limpo” e melhor arquitectado que o do Joomla, sendo ainda mais facilmente configurável e aparentemente ter um suporte muito melhor para internacionalização. A informação sobre o suporte de internacionalização pelos vários CMS não era totalmente clara e fácil de entender, tendo como base a Internet mas com o conhecimento pós-implementação do projecto, pode dizer-se que o facto de se ter optado por Drupal podia ter sido baseado apenas no melhor suporte para internacionalização, visto que pelo que se pôde apurar, neste campo o Drupal está a “anos-luz” da concorrência. Quem estiver a pensar utilizar um CMS onde seja necessário implementar internacionalização, será necessário encontrar uma razão especial para escolher outro software que não o Drupal.

O projecto: Sendo uma organização sem fins lucrativos, o projecto desta comunidade acabava por ter algumas semelhanças com o próprio projecto do Drupal. Após a “fundação” ter sido criada, o trabalho “bruto” foi feito por cerca de 100 voluntários. Milhares de páginas anteriormente com código confuso, criadas por software com editores “WYSIWYG – What you see is what uou get”, foram então reformatadas para cumprir standard XHTML utilizado o FCKEditor (com algumas opções melhoradas). O resultado foram cerca de 1000 “nós” em inglês, sendo grande parte deles traduzidos para cada uma das 8 línguas, dando um total de cerca de 3000 “nós”. cai-logo1.png

Considerações Finais

Como se pôde analisar ao longo deste documento, a internacionalização, em conjunto com a localização, são passos essenciais para que uma empresa consiga distribuir o seu produto (nomeadamente software) além fronteiras, especialmente nos casos em que haja “países-alvo” com diferentes línguas da original. Apesar disto, é necessário verificar se a penetração do produto nos mercados-alvo vai ser alta, pois os custos de tal implementação poderão ser altos, tanto a nível de recursos humanos como financeiros.

Bibliografia

  1. http://en.wikipedia.org/wiki/Internationalization_and_localization
  2. http://i18nblog.com/2011/11/02/internationalization-of-ciscos-telepresence-case-study/
  3. http://msdn.microsoft.com/en-us/library/cc168605.aspx
  4. http://www.i18nguy.com/
  5. http://drupal.org/node/315932
  6. http://www.debian.org/doc/manuals/intro-i18n/intro-i18n.pdf
  7. http://en.wikibooks.org/wiki/FOSS_Open_Standards/Standards_and_Internationalization/Localization_of_Software
  8. http://www.w3.org/TR/ws-i18n-scenarios/
  9. http://www.freebsd.org/doc/handbook/l10n.html
  10. http://www.coactivate.org/projects/opencore/i18n-usage-in-opencore

Grupo de trabalho

20111610 - Tiago Trindade
20111609 - João Almeida

Este trabalho deve ser citado como

Trindade, Tiago e Almeida, João (2011). Internacionalização. Trabalho da disciplina de Seminário de Sistemas e Tecnologias da Informação I. Universidade Atlântica, Portugal. Disponível em http://ssti1-1112.wikidot.com/internacionalizacao.

Perguntas

  • De onde aparecerao os termos (L10n), (m17n), (l18n)?
  • Estes 3 termos são a simples abreviatura utilizando as primeira e última letras da palavra, bem como o número de caracteres que estão entre elas. L(ocalizatio)n por exemplo, L - 10 caracteres - n.
  • A internacionalização veem como uma obrigação, uma moda ou um standartd?
  • A ter que escolher entre as 3, a resposta terá que ser um standard mas mais do que isso, poderá ser uma necessidade num negocio que tenha a maior fatia de mercado alvo "além-fronteiras" ou uma futilidade para uma aplicação que tenha o maior número de visitas na sua língua nativa.