Arquivos de Localização (Strings)

Os arquivos de localização são arquivos de texto que podem ser abertos e editados em um editor de texto como o Notepad ou TextEdit ou em uma das inúmeras ferramentas de edição de texto aprimoradas usadas por programadores. Esses arquivos geralmente seguem o princípio de chave-valor. Isso significa que eles contêm uma lista de trechos de texto (strings) que estão associados a IDs únicos (chaves). Cada string é, portanto, um valor de uma chave (Este exemplo simples é o formato dos arquivos de localização usados na programação Java.):

Criação de arquivos de localização

Os arquivos de localização são arquivos de texto simples com uma estrutura simples. Eles podem ser criados manualmente, mas geralmente são gerados automaticamente por utilitários ou scripts de internacionalização que estão disponíveis para diferentes ambientes de desenvolvimento. A criação automática de arquivos de localização garante que as estruturas dos arquivos sejam válidas.

Para criar um arquivo de localização, todos os trechos de texto exibíveis são substituídos por IDs únicos nos arquivos de código. As strings de texto são então adicionadas ao arquivo de localização com seus IDs.

Uso de arquivos de localização

Em vez das strings de texto reais, o código agora contém apenas chaves. Quando o software gera uma visualização para o usuário, essas chaves são usadas para procurar as strings associadas no arquivo de localização.

Se um aplicativo estiver configurado para ser usado em inglês e espanhol, todo o texto em inglês pode ser mantido em um arquivo chamado English.txt e é o local de texto padrão. Se um usuário não selecionar um idioma, todo o texto será retirado deste arquivo para gerar qualquer exibição. Se o usuário selecionar espanhol, o software será redirecionado para Spanish.txt. Muitos idiomas podem ser usados com um sistema como este.

A vantagem é que a escolha do idioma para a exibição não afeta o código. Se o software precisar exibir um botão de login, pode exigir a string associada à chave login_button e só precisa saber em qual arquivo procurar para recuperar a string apropriada para o idioma dado.

Gerenciamento de strings

Como uma plataforma de tradução baseada em chaves, a Phrase suporta muitos tipos diferentes de arquivos de recursos. Após os arquivos serem enviados, as chaves e seus valores de string associados são extraídos. As chaves e strings são então apresentadas ao tradutor em um formato padronizado. Os tradutores se concentram em sua tarefa sem precisar se preocupar com o formato exato do arquivo de localização. Eles podem inspecionar as chaves, pois a própria chave pode fornecer um contexto crucial e guiá-los para escolhas de palavras corretas.

Quando todas as strings são traduzidas, os arquivos são baixados. No processo, os formatos de arquivo de localização necessários são criados que correspondem ao arquivo de origem original.

Formatos de arquivo de recursos file formats

Quatro tipos amplos de recursos são suportados e são todos essencialmente baseados em texto e podem ser abertos e inspecionados em um editor de texto.

Planilhas

.XLSX e .CSV são suportados. Esses formatos são equivalentes para fins de localização e contêm linhas de pares chave-valor. As chaves estão em uma linha, enquanto os valores correspondentes estão em uma linha adjacente. Qual coluna exata é usada para qual propósito depende da aplicação, e um localizador precisa configurar a Phrase para interpretar as colunas corretamente. Os arquivos .CSV do ZenDesk têm uma estrutura fixa, portanto, esse tipo de arquivo não requer ajustes adicionais:

"Título","Idioma padrão","Texto padrão","Texto em inglês","Status da variante"
"simple_key","Alemão","Chave simples.","Chave simples.","Atual"

XML

XML é um formato que oferece metainformação na forma de <tags>. A estrutura de tags é usada para determinar onde estão as chaves e seus valores correspondentes, como mostrado aqui a partir de um arquivo XML do Android:

 <string name="simple_key">Apenas uma chave com uma mensagem.</string>

Dois formatos padrão de tradução XML são .TMX e .XLIFF. Esses formatos não apenas contêm chaves e valores em um idioma, mas também associam pares de valores de um idioma de origem com valores correspondentes de um idioma de destino. Esses arquivos são tipicamente bilíngues, como mostra esta unidade de tradução em um arquivo Symfony Xliff:

<trans-unit id="simple_key" resname="simple_key">
 <source xml:lang="de-DE">Apenas uma chave simples com uma mensagem simples.</source
<target xml:lang="en-GB">Apenas uma chave simples com uma mensagem simples.</target>
</trans-unit>

Programas QT usam arquivos de recursos com uma estrutura muito semelhante a esses formatos padronizados, mas por razões históricas têm um layout diferente.

Listas simples de chave-valor

Existem arquivos de recursos que contêm apenas listagens simples de chaves e valores, como este trecho de um YAML do Ruby on Rails:

simple_key: Apenas uma chave simples com uma mensagem simples.

Muitas linguagens de programação ou plataformas diferentes usam tais formatos com pequenas diferenças de layout.

Como esses são arquivos monolíngues, um programa de localização precisa manter versões paralelas de tais arquivos - uma para o idioma de origem e outras para os idiomas de destino.

Gettext produz arquivos de chave-valor contendo informações adicionais, como comentários descritivos ou variantes plurais:

# Esta é a descrição incrível para esta chave!
msgid "key_with_description"
msgid_plural ""
msgstr[0] "Confira!" Esta chave tem uma descrição! (Pelo menos em alguns formatos)"
msgstr[1] "Confira! Esta chave tem %s descrições! (Pelo menos em alguns formatos)"

Existem formatos concorrentes com funcionalidades e layouts semelhantes que variam de maneiras relativamente menores.

Arrays associativos

Enquanto outros formatos exigem código personalizado (analisadores) para lê-los, alguns formatos são mais fáceis para desenvolvedores e localizadores. Formatos baseados em .JSON (JavaScript) e .PHP arrays podem ser lidos e mapeados diretamente em estruturas de código comuns (arrays) que são fáceis de manipular. Arrays podem ser complexos e diferentes aplicações geram estruturas de arrays personalizadas.

Por exemplo, go-i18n JSON se refere a chaves como id:

{
    "id": "simple_key",
    "tradução": "chave simples, mensagem simples, tão simples."
},

Angular usa as chaves como chaves em seus arrays:

"simple_key": "Eu sou uma chave simples com uma mensagem simples.".

Como existem essas diferenças menores, mas cruciais, estruturas de Array .JSON e .PHP amplamente utilizadas são suportadas.