Este é um exemplo real de tradução de um pequeno aplicativo do Windows chamado Multilizer Translator Gadget, que é um Gadget de barra lateral do Windows. Embora cada projeto de localização de software é exclusivo, existe um caminho universal que é seguido pela maioria dos casos de localização. Vamos passar por este caminho com este caso.

Fase de pré-localização

Antes de qualquer projeto de localização pode ser iniciado, é preciso definir os objetivos do projeto. Localização Não é um termo simples e para evitar mal-entendidos, é importante esclarecer o que significa neste caso específico. No nosso caso, a localização foi reduzida a traduzir a interface do usuário em vários idiomas.

#1 Estabelecer os objetivos para o projeto.

Depois que um sabe o que é o resultado desejado do projeto, é aconselhável dar uma olhada o software. Há muitas coisas que os desenvolvedores de software podem fazer para facilitar o processo de localização real. (Devido o aspecto técnico desta fase, os seguintes parágrafos contêm algum jargão técnico. Se é muito complicado, é só pular direto para o “Fase de localização” ou pedir ajuda um nerd.)

No nosso caso, descobrimos que os gadgets geralmente consistem em HTML, CSS, e JavaScript. E os textos de tradução podem ser em arquivos HTML, ou às vezes também em JavaScript. Isto também aplicado para o gadget que desenvolvemos.

As fontes foram organizadas em uma maneira típica nas seguintes pastas:

raiz
   +css
   +imagens
   +js

A raiz contém o HTML e o manifesto do gadget. CSS contém as folhas de estilo. As imagens contêm as imagens usadas pelo gadget. E js contém o JavaScript que adiciona a funcionalidade desejada no gadget.

#2 Seleção da arquitetura de software.

O Gadget usa a arquitetura Microsoft MUI; pode haver pastas nomeadas pela localidade do ISO, como 'es-ES'. Em um sistema espanhol, a barra lateral procuraria primeiro por arquivos sob o 'es-ES’ diretório. Se não for encontrado, Então ' neutro’ arquivos poderia ser carregados. Baseado nesta arquitetura, a tradução envolveria todos os arquivos seriam copiados em um novo diretório nomeado pela localidade ISO. Depois disso, os arquivos com textos em inglês seriam traduzidos para outro idioma. Esta abordagem, no entanto, Não é tão elegante.. Um monte de arquivos duplicado como tal.

Para superar isso, Estamos decididos a internacionalizar o código. Isso significa que removemos todos os textos em inglês e os colocamos em um arquivo de recurso comum chamado 'resourcestrings.js'. E a interface do usuário é agora preenchida no arranque, chamando um getResourceString() função.
Com esta abordagem, a tradução do gadget é simplesmente reduzida à tradução de 'resourcestrings.js'.

Nós também adicionamos duas funções extras para fazer a parte de programação ainda mais conveniente:

  • setElementText(elementid,resourcekey)
  • setAttributeText(elementid,attributename,resourcekey)

#3 Internacionalizar o código (se possível)

Estas relativamente pequenas alterações no código facilitar e simplificar significativamente a fase seguinte do projecto de localização.

Fase de localização

Quando terminar todo o trabalho preparativa, a localização real pode começar. Um pode fazer a fase de localização semi automaticamente ou manualmente com uma ferramenta de localização especial. Trabalho manual exige conhecimentos mais técnicos sobre desenvolvimento de software do que trabalhar com uma ferramenta de localização. As diferenças mais significativas entre esses dois métodos são tempo e segurança. Uma ferramenta de localização acelera o processo, automatizando algumas tarefas e protege o software, eliminando a possibilidade de fazer alterações fatais no código durante o processo de localização.

Fizemos nosso projeto com a nossa própria, ferramenta de localização avançada chamada Multilizer Enterprise. É uma ferramenta versátil para pequenas e grandes projetos. Primeiro criamos um novo projeto de Multilizer e digitalizados nosso software com a ferramenta. Nossa ferramenta de localização reconhece qual parte do código deve ser traduzida e mostra apenas essas strings. Depois disso, exportamos o material traduzível automaticamente para o Google Translator Toolkit com MOTO.

#4 Preparar o projeto de tradução.

Neste ponto do projeto, é hora de traduzir. Acordo com os objectivos do projecto de localização, um deve decidir como a tradução é feita. A melhor saída provavelmente será feita por um tradutor profissional especializado no tópico e localização de software. No entanto, também existem situações em que, por exemplo,. Tradução de crowdsourcing é a melhor solução. Mais uma vez os objetivos e metas do projeto devem ter em conta. Em nosso projeto, usamos uma plataforma de emprego online chamada Elance para encontrar tradutores.

Os tradutores que trabalharam no nosso projeto com Google Translator Toolkit. Este tipo de terceirização online é simples para os tradutores, pois eles podem trabalhar online onde e quando quiserem, sem a necessidade de baixar ou instalar programas em seus próprios computadores.. Para garantir a qualidade, deve haver um canal de boa comunicação entre os participantes.

#5 Recrutar Tradutor(s) e se comunicar com eles.

Quando as traduções estão acabadas, eles podem ser integrados no código. Em nosso projeto, isso foi feito importando as traduções automaticamente do Google Translator Toolkit para o Multilizer Enterprise.

#6 Integre as traduções ao seu projeto.

Quando tudo isso foi feito, pode-se terminar o projeto e construir o software localizado. Nesta fase, existe a tentação de marcar o projeto como concluído e passar para o próximo. No entanto, ainda há uma coisa importante a fazer.

Fase pós-localização

Após o software é localizado, um deve testá-lo corretamente. É uma boa idéia deixar o tradutor(s) Veja o resultado também. Todos os possíveis erros ou erros de digitação são relativamente fáceis de corrigir agora, antes de quaisquer ações de marketing mais.

Isto é como procedeu o nosso projeto de localização. Você faria algo diferente?

Links: