Logotipo do Centro Virtual Camões
Apresentação
Tecnologias e tradução
Recursos em linha
Universidades
Bibliotecas
Revista Tradumática
Normas de qualidade
Aspectos legais
Consultoria



Número 1: A Localização

Internacionalização
Feliciano Donoso, Bowne Global Solutions, Dublin



O que é a internacionalização?

A internacionalização fornece os parâmetros e a estrutura que facilitam o processo de localização. Durante o seu desenvolvimento, o software é concebido de maneira que permita a tradução para outras línguas, sem a necessidade de ser alterado nem recompilado. O termo é geralmente abreviado como "I18N", já que na versão inglesa há 18 letras entre o "I" e o "N".

A internacionalização é importante pelas seguintes razões:

  Permite que os produtos originais sejam vendidos por todo o mundo.

  A comercialização do software localizado é muito mais rápida. Quando o produto é lançado, ele cumpre todas as exigências internacionais. A localização pode começar paralelamente com os ciclos de desenvolvimento do produto.

  A localização requererá menos recursos e será mais rápida e mais barata. Para oferecer apoio internacional depois do lançamento da versão original é necessária uma versão em linha. Esta fará com que seja necessário conseguir uma nova certificação da funcionalidade original que adicione as características internacionais. Isto significa que não poderá aumentar totalmente o esforço para garantir a qualidade das versões originais, implicando mais recursos, mais tempo e mais dinheiro na distribuição de uma versão localizada do software.

Um aspecto importante da internacionalização é a separação do texto e do código fonte. O texto traduzível que o utilizador poderá visualizar deveria ser deslocado para arquivos de recursos que só contenham sequências, evitando assim que os tradutores traduzam, ou modifiquem, o código do programa. Pode usar-se um código fonte simples, fazendo com que a manutenção seja mais fácil e mais barata. Se os requerimentos internacionais são cumpridos no início, não serão necessárias nem uma versão em linha nem derivações do código fonte. O uso de um código fonte simples faz com que corrigir erros e adicionar novas características seja muito mais barato.


Exemplo: Localização de um aplicativo em Java

Vamos ver um exemplo prático de como poderíamos localizar um aplicativo em Java e o problema que "os recursos de codificação fixa" podem provocar:


  O aplicativo em Java não internacionalizado

O aplicativo que deve ser localizado é muito simples e só apresenta três mensagens, como se mostra a seguir:

public class example1 {
static public void main(String[] args) {
System.out.println("Hello.");
System.out.println("How are you?");
System.out.println("Goodbye.");
}
}

Vamos considerar que esse aplicativo deve ser traduzido para catalão. O profissional que estiver a desenvolver o produto ou o engenheiro de software terá duas opções:

1. A primeira opção é enviar o arquivo para os tradutores na forma como está e pedir-lhes que modifiquem o original, criando um novo código fonte. Como os tradutores não são programadores, existe o risco de que durante a tradução eles mexam no código dos aplicativos. De facto, este aplicativo só serve como orientação, mas o que aconteceria com um aplicativo real com centenas ou milhares de mensagens, de opções de menu, de caixas de diálogo, etc.?

2. A outra opção é que o engenheiro de software faça uma cópia dos códigos fonte para a versão em catalão, extraia manualmente do código cada uma das partes que deveriam ser traduzidas, as copie numa folha de cálculo (utilizando qualquer editor de arquivos) e as envie aos tradutores. Quando os tradutores tiverem devolvido a folha de cálculo com as seqüências traduzidas, tudo deverá ser copiado manualmente no "novo" código fonte e recompilado, esperando que não tenha acontecido nenhum erro ao longo do processo. É óbvio que, embora ofereça melhores resultados que o anterior, este processo é totalmente lento e ineficaz.

Seria interessante que as mensagens saíssem do código fonte e aparecessem nos arquivos de texto para que os tradutores as pudessem editar. Igualmente, o programa deve ser suficientemente flexível de maneira a que possa apresentar as mensagens noutras línguas, em vez de aparecer só nas que supostamente serão traduzidas.


  Aplicativo Java internacionalizado

Neste caso, as mensagens estão separadas do código fonte, facilitando a localização do programa para os diferentes mercados.

import java.util.*;

public class example2 {

static public void main(String[] args) {

Idioma da sequência;
País da sequência;

if (args.length != 2) {
idioma = nova sequência("en");
país = nova sequência("US");
} else {
idioma = nova sequência(args[0]);
país = nova sequência(args[1]);
}

Local e Local actual;
ResourceBundle messages;

Local actual = Novo local (idioma, país);
messages = ResourceBundle.getBundle("MessagesBundle", Local actual);
System.out.println(messages.getString("greetings"));
System.out.println(messages.getString("inquiry"));
System.out.println(messages.getString("farewell"));
}
}


Para compilar e usar este programa, também são necessários os seguintes arquivos:

MessagesBundle.properties

          greetings = Olá.
          inquiry = Tudo bem?
          farewell = Até logo.

MessagesBundle_ca_ES.properties:

          greetings = Hola.
          inquiry = Com estàs?
          farewell = Adéu.

O programa internacionalizado é flexível; ele permite que o usuário final especifique um idioma e um país na barra de comandos. No seguinte exemplo, o código do idioma é ca (catalão) e o código do país é ES (Espanha), de maneira que o programa apresenta as mensagens em catalão:

% java example2 ca ES
Hola.
Com estàs?
Adéu.

No seguinte exemplo, o código do idioma é en (inglês) e o código do país é US (Estados Unidos), de maneira que o programa apresenta as mensagens em inglês:

% java example2 en US
Hello.
How are you?
Goodbye.

Nesta fase, as versões localizadas destes programas só podem ser realizadas criando cópias dos arquivos de propriedades para todos os idiomas necessários. O arquivo de propriedades armazena a informação das características de um programa ou de um ambiente. Um arquivo de propriedades está em formato de texto. Isso significa que os tradutores apenas necessitam de modificar esses arquivos de propriedades.

No exemplo, os arquivos de propriedades armazenam o texto traduzível das mensagens que serão visualizadas. Antes de o programa ser internacionalizado, a versão inglesa deste texto estava em codificação fixa nas instruções System.out.println. O arquivo de propriedades pré-definido, chamado MessagesBundle.properties, contém a seguinte informação:

greetings = Hello
inquiry = How are you?
farewell = Goodbye


Agora que aparecem num arquivo de propriedadesas as mensagens, podem ser traduzidas para diferentes línguas. Não é necessária nenhuma alteração do código fonte. Um tradutor francês, por exemplo, pode criar arquivos de propriedades chamados MessagesBundle_fr_FR.properties, que conterão a seguinte informação:

greetings = Bonjour.
inquiry = Comment allez-vous?
farewell = Au revoir.

Observe-se que as variáveis do lado direito do símbolo de igual foram traduzidas, mas que os símbolos do lado esquerdo não foram alterados. Estes elementos não devem ser alterados, já que servirão como referência quando o programa procurar o texto traduzido. Esses elementos também podem ser usados pelo tradutor como referências de contexto.


Componentes da internacionalização

Como já foi explicado anteriormente, a chave para a internacionalização do software consiste em não estabelecer uma codificação fixa dos seguintes componentes:

  Interface de Utilizador - UI

A parte mais lógica de um ambiente internacional é o texto que o utilizador final visualiza. Isto inclui mensagens de erro, textos de ajuda, menus, avisos e gráficos. O texto completo deveria aparecer na língua do utilizador. Este texto deveria ser recodificado fora do código fonte. É importante ter em consideração o espaço que podem ocupar os itens, assim como o espaço entre eles, já que, geralmente, uma tradução é 20% mais longa do que o texto original. O texto pode tornar-se mais longo tanto vertical como horizontalmente, dado que as fontes asiáticas podem ser tanto horizontais como verticais, e maiores do que as ocidentais. Como resultado, pode acontecer que o texto traduzido não encaixe no espaço original.

A documentação impressa é outro componente importante do produto. A documentação deveria ser internacionalizada, como os componentes do software. A tradução é muito mais fácil quando a documentação não tem expressões idiomáticas nem metáforas específicas de um país.

A interface gráfica deveria ter a mesma consideração que o texto. Os ícones deveriam ser culturalmente neutros. Qualquer texto que haja nos ícones deveria ter um código diferente do código da imagem gráfica.

  Classificação

Os diferentes idiomas classificam os caracteres de diferentes formas. O inglês só classifica como "alfabéticos" 52 caracteres: [A-Z] e [a-z]. Quaisquer outros caracteres não são considerados alfabéticos, sendo isto um problema na Europa, onde no dia-a-dia aparecem caracteres acentuados como é, ä, ô, por exemplo. Nas línguas asiáticas, como o chinês ou o japonês, quase todos os caracteres usados são fonéticos e ideográficos, mas não alfabéticos. Em consequência, é obrigatório que os sistemas na Ásia reconheçam os caracteres fonéticos e ideográficos. A classificação (isalpha, islower, issupper, etc.) deve ser definida segundo a língua. Por outro lado, deve haver um mecanismo para definir outras classificações que não existam no inglês (por exemplo: isdiacritico, isdbcs, isfonética, isidiograma).

  Transliterações

Na maioria dos sistemas, a linguagem de programação C oferece macros para maiúsculas (C) e para minúsculas (c) para realizar a conversão de maiúscula para minúscula e vice versa. No entanto, estas macros estão programadas para o inglês e para a página de código ASCII. Em ASCII, os caracteres em minúsculas e maiúsculas têm a mesma ordem. Isso não acontece com as páginas de código europeias nem com as asiáticas.

A tabela deve-se poder ler no tempo de execução e deve ser definível para o utilizador. Também deverá poder funcionar com línguas asiáticas e o número de caracteres não poderá ser superior a 256.

  Formatos numéricos

Os formatos numéricos variam de um país para outro. A representação dos números difere em relação ao símbolo que indica o carácter da base de numeração, que é o separador entre o número inteiro e o carácter da base de numeração (separando a parte fraccionária do número) e o símbolo de agrupamento do dígito. Por exemplo, nos EUA e na Alemanha os números são representados usando decimais e vírgulas, porém os símbolos são intercambiáveis (5,434.25 e 5.434,25). Os caracteres da base de numeração e de agrupamento de dígitos não se reduzem unicamente a "." e "," - países como a França usam um carácter em branco como símbolo de agrupamento de dígitos - 5 434,25

  Formatos monetários

Os formatos monetários também diferem de um país para outro. Os símbolos da base de numeração e de agrupamento de dígitos geralmente são os mesmos que se usam no formato numérico. Igualmente, o símbolo monetário e a sua posição relativa às alterações de valor da moeda variam de um país para outro. O símbolo monetário dos EUA é "$" e precede o valor, por exemplo $5. Na França, o símbolo monetário é "FF" e aparece depois do valor, por exemplo 5 FF. Em países como Portugal, o símbolo monetário aparece no meio do valor, separando assim as unidades inteiras e as fracções. A introdução do euro "€" fará com que seja mais fácil para os criadores de software resolver este problema . No entanto, é interessante pensar na quantidade de tempo que se poderia ganhar no processo de conversão para o euro se todo o software tivesse sido internacionalizado de forma correcta anteriormente.

  Formato de data e hora

A maior parte dos países ocidentais usa o calendário juliano. Os países asiáticos frequentemente usam formatos múltiplos para a data. O Japão usa o formato de calendário juliano assim como o formato baseado no número de anos de governo do imperador. Porém, o calendário juliano é totalmente reconhecido e usado nos diferentes softwares. Taiwan e a China usam o formato de data baseado no número de anos desde o início da era actual, a qual geralmente inicia e acaba com o mandato desse período.

Mesmo se nos limitarmos ao calendário juliano, os formatos de data variam nos diferentes países. Nos EUA o mês precede o dia, na Europa ocidental o dia precede o mês, na Suécia o ano precede o mês seguido do dia.

  Agrupamentos

Na maior parte dos aplicativos, classificar significa estabelecer a ordem do ponto de codificação, o qual fica na ordem da página de códigos ASCII. A página de classificação ASCII não é correcta para línguas estrangeiras, nem é suficiente para a ordenação do dicionário americano, já que todas as letras maiúsculas são classificadas antes das letras minúsculas. Isso significa que a é classificado depois de B, o que é incorrecto.

As convenções de classificação de línguas estrangeiras, no geral, são mais complexas do que as convenções de classificação nos EUA. A classificação alfabética não-inglesa inclui:

        mapas de caracteres 1-a-2 (ß é classificado como ss em alemão)

          mapa de caracteres 2-a-1 (ch aparece entre as letras c e d em espanhol)

          Classificação primária, secundária, etc.

As propriedades de classificação mencionadas referem-se às línguas alfabéticas. Os caracteres ideográficos asiáticos representam conceitos e por isso o sistema ocidental de classificação não é suficiente. No entanto, as línguas asiáticas podem ser classificadas por diferentes métodos. Para o Kanji, o melhor método é o fonético, em oposição à classificação por números, por raízes ou por pulsações que compõem um carácter.

  Expressões habituais

As expressões habituais, que são padrões usados para pesquisar textos, muitas vezes são ignoradas, embora estejam associadas ao agrupamento. Em algumas línguas existem elementos de agrupamento formados por mais de um carácter, como por exemplo ch em espanhol. A expressão habitual [a-ch] não funcionará, já que significa a, b, c ou h. É necessária uma sintaxe adicional. As expressões habituais necessitam de ter códigos de página de vários bytes. Para os códigos de página de vários bytes, deve haver uma correspondência de padrões baseada nos caracteres, mas desconsiderando o tamanho do carácter em bytes.

  Esquemas de codificação

Um esquema de codificação ilustra a correspondência entre um carácter e as representações de bits do computador. A página de códigos ASCII é a mais comum. ASCII é uma página de códigos de 7 bits capaz de representar 128 caracteres, que é suficiente para o inglês. A página de códigos ISO 8859-1 é usada com mais frequência. A ISO 8859-1 é uma página de códigos de 8 bits que pode representar códigos de página da Europa Ocidental e de Leste. Nem o ASCII nem os diversos subconjuntos de ISO são capazes de representar os caracteres ideográficos asiáticos. Para poder representar com precisão esses caracteres utiliza-se a página de códigos Unicode. O Unicode é uma página de códigos de dois bytes.

  Caracteres e bytes

Para a maior parte dos profissionais que desenvolvem o software, o que eles produzem são códigos em bytes e não em caracteres. Tal resulta de que para a maioria desses profissionais um byte e um carácter são intercambiáveis, já que no ASCII cada carácter é representado por um byte. Isto não é verdade na área internacional, onde incrementar um carácter no apontador poderá acrescentar ou não o carácter seguinte da sequência.

O byte múltiplo está associado a problemas e outros factores que não acontecem com os caracteres de um único byte.

·Truncagem de um valor e fraccionamento de caracteres.
· Agrupamento e divisão de caracteres.
· Contorno da janela e divisão de caracteres.
· Expressões habituais e correspondência dos caracteres, não dos bytes.
· Tamanho da memória e tamanho da visualização.
· Movimentos do cursor de tamanho variável e edição, inserção e anulação de caracteres.

  Direcção do texto

A direcção do texto apenas representa um problema nos textos hebraicos e árabes, escritos da direita para a esquerda. O método de visualização ocidental (da esquerda para a direita) é amplamente aceite na Ásia para introduzir e representar os caracteres ideográficos asiáticos.

  IMEs

Os conjuntos de caracteres Kanji incluem milhares de símbolos, os quais não podem aparecer num teclado. Os sistemas operativos asiáticos, assim como muitas empresas terceirizadas, possuem software para a edição de métodos de digitação. Esse software oferece ao utilizador a possibilidade de introduzir milhares de caracteres diferentes. A maior parte desses sistemas baseia-se na conversão fonética.


Como se pode conseguir um autêntico software internacionalizado

Um dos principais elementos para essa estratégia é a preparação inicial do material original. Começar a investir na internacionalização do software reduzirá o tempo de comercialização e os custos de localização.

Algumas linhas para conseguir esse objectivo podem ser:

· Definição das línguas alvo.
· Preparação do software para o byte duplo.
· Estabelecimento das directrizes de desenvolvimento do software pensando na internacionalização.
· As definições de utilizador do sistema operativo facilitam o formato do horário e da data local, a disposição do teclado, etc.
· Permissão para introdução de dados internacionais.
· Aceitação de formatos mistos para endereços, medidas, números, horários e datas.
· Alteração de maiúsculas e as minúsculas.
· Ter em conta a classificação.
· Classificação de todos os itens localizáveis em arquivos de recursos externos.
· Permissão para a expansão do texto; criação de uma memória intermédia (buffer) e uma interface de utilizador suficientemente grandes para que possam conter o texto traduzido.
· Definição das teclas principais e das teclas de aceleração.
· Uso de comentários com codificação tendo o objectivo de fornecer contextos para os tradutores.
· Teste a todas as características de internacionalização da versão em inglês.
· Confirmação de que todos os componentes terceirizados foram internacionalizados.

Por outro lado, algumas das acções que nunca se deveriam realizar para obter uma boa qualidade no software localizado são as seguintes:

· Não fazer suposições em relação às fontes padrão.
· Concatenar sequências para formar frases.
· Concatenar janelas para criar telas completas.
· Colocar texto nos ícones; fazê-los suficientemente genéricos para um software internacional.
· Incluir comandos de teclado fixos.
· Colocar o código fixo da tela ou tamanho dos itens na tela.


Níveis de internacionalização/localização

Um termo frequentemente usado no âmbito da internacionalização é o de adaptação. Adaptação é o processo de ajustamento do software com vista à sua utilização em certos países ou regiões. Por exemplo, um software pode ser habilitado para processar texto usado nos países do Extremo Oriente. Por isso, dependendo dos países alvo, utilizar-se-ão diferentes níveis de localização.

  Produto unicamente em inglês

Uma opção seria não adaptar nem localizar o software. Deste modo, o produto seria exclusivamente de língua inglesa, podendo ser vendido nos EUA, na Irlanda, na Austrália, na Nova Zelândia e possivelmente em Singapura. O mercado europeu só é acessível através de filiais americanas nas quais a sede americana escolhe o produto em inglês para ser usado. No entanto, o produto não só está em inglês mas também tem as funções em inglês. Assim, por exemplo, tem 7 bits, apresenta a data, a moeda e outras classificações com o formato dos EUA, e não aceita caracteres europeus como o ç, etc.

  Produto em inglês que aceita dados europeus

Neste nível, o produto não está localizado, não está traduzido e as telas e a interface de utilizador permanecem em inglês. Contudo, o produto é adaptado para usar a maior parte de códigos de página de um único byte usados nos países europeus. Além do mais, o produto é adaptado para usar as convenções culturais dos países europeus (formatos de data, moeda, agrupamentos, etc).

  Produto em inglês que aceita dados do Extremo Oriente

Adaptação do software para processar texto usado nos países do Extremo Oriente como o Japão, a China, a Formosa e a Europa. Requer a alteração da lógica do produto de origem (geralmente dos EUA) e poderia requerer a redefinição do produto completo. A adaptação do produto para o Extremo Oriente requer a definição do software para que seja também independente do hardware.

  Produto em inglês que aceita dados de forma bidireccional

Além da habilitação do software para que funcione em diferentes línguas, também há a necessidade de traduzir a interface de utilizador e a documentação impressa. A maioria do software requer a tradução completa da interface de utilizador e da documentação, como acontece com aplicativos para negócios. Seria ideal que o utilizador final nunca suspeitasse que o produto foi desenvolvido num outro país.

  Localização completa e características do mercado local

O produto ideal para um mercado local não só é aquele que está totalmente localizado mas também aquele que tem características específicas do seu mercado local. No caso concreto dos aplicativos financeiros e de recursos humanos, uma parte integral do processo de localização garante que os requerimentos legais locais sejam cumpridos. Da mesma forma, para os requerimentos funcionais específicos também podem ser necessárias outras características técnicas, como acontece com o Extremo Oriente.


Conclusão

A internacionalização é um factor essencial para a localização. Um aplicativo completamente internacionalizado fará com que o tradutor trabalhe mais rapidamente, já que não precisará de se preocupar com nenhum assunto relacionado com desenvolvimento. Os engenheiros de software poder-se-ão concentrar nas questões técnicas, enquanto os tradutores se concentrarão nas questões linguísticas. Por isso, o processo de localização, no geral, torna-se mais rápido e oferece uma maior qualidade. A localização de alta qualidade de um software que possibilite sua distribuição pelo mundo todo marcará o seu sucesso ou o seu fracasso.


Bibliografia

Esselink, B. (1998): Um guia prático para a localização de software. Amsterdão, Benjamin Publishing Company

Tutorial da internacionalização http://java.sun.com/docs/books/tutorial/i18n.

Outubro 2002

 Voltar ao início


Bert Esselink | Feliciano Donoso | Jordi Mas i Hernàndez | Marta Pagans
Michael Scholand | Noelia Corte Fernández | Olga Torres
Roula Sokoli | Xavier Arderiu i Monnà