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 Notepad ou TextEdit ou em uma das inúmeras Ferramentas aprimoradas de edição de texto usadas pelos programadores. Estes arquivos geralmente seguem o princípio chave-value. Isso significa que eles contêm uma lista de trechos de texto (Strings) que são associados a IDs exclusivas (chaves). Cada string é, portanto, um valor de uma chave (Este exemplo simples é o formato de arquivos de localização usados na programação Java.):

Criação de arquivos de localização

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

Para criar um arquivo de localização, todas as partes do texto exibível são substituídas por IDs exclusivas nos arquivos de código. As Strings de texto são então adicionadas ao arquivo de localização com seus IDs.

Usar 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, estas chaves são usadas para pesquisar os Strings associados no arquivo de localização.

Se um aplicativo estiver configurado para ser usado em inglês e espanhol, todo o texto em inglês poderá ser mantido em um arquivo chamado English.txt e é o local padrão do texto. Se um usuário não selecionar um idioma, todo o texto será pulled deste arquivo para gerar qualquer exibição. Se o usuário selecionar o 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 o visor não afeta o código. Se o software precisar exibir um botão de login, ele pode precisar da string associada ao botão login_botão e só precisa saber em qual arquivo procurar para obter a string apropriada para o idioma dado.

String management

Como uma plataforma de tradução baseada em chave, o phrase aceita muitos tipos diferentes de arquivos de recurso. Após o upload dos arquivos, as chave e os 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 concentram-se na sua tarefa sem ter que se preocupar com o formato exato do arquivo de localização. Eles podem inspeccionar as chaves, pois a própria chave pode fornecer contexto crucial e guiá-los para escolhas de palavras corretas.

Quando todas as Strings são traduzidas, arquivos são baixados. No processo, o formato necessário de arquivo de localização é criado com correspondência ao arquivo original do texto original.

Formatos de arquivo de recurso

Há quatro tipos amplos de recursos compatíveis, todos baseados essencialmente em texto, que podem ser abertos e inspeccionados em um editor de texto.

Spreadsheets

Os arquivos .XLSX e .CSV podem ser utilizados. 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 finalidade depende do aplicativo e um localizador precisa configurar o phrase para interpretar as colunas corretamente. Os arquivos Zendesk .CSV têm uma estrutura fixa. Portanto, este tipo de arquivo não requer mais ajustes:

"Título"," Idioma padrão","Testo padrão","Testo inglês","Estado variante"
"simple_key","German","Einfacher Schlüssel.","Simple key.","Current"

XML

O XML é um formato que oferece metadados em forma de <códigos>. A estrutura do código é 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_chave">Just a chave com uma mensagem.</string>

Dois formatos padrão de tradução de XML são .TMX e .XLIFF. Eles não apenas contêm chaves e valores em um idioma, mas também associam pares de valores de um idioma de texto original a valores correspondentes de um idioma de tradução. Esses arquivos são normalmente bilíngues, pois esta unidade de tradução em um arquivo Symfony Xliff mostra:

<trans-unit id="simple_key" resname="simple_key">
 <text original xml:lang="de-DE">Nur ein einfacher Schlüssel mit einer einfachen Nachricht.</text original
tradução xml:lang="en-GB">Só uma chave simples com uma mensagem simples.</tradução
</trans-unit>

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

Listas chave-valor planas

Existem arquivos de recurso que contêm apenas listas simples de chaves e valores, como este trecho de um Ruby on Rails YAML mostra:

simple_key: Apenas uma chave simples com uma mensagem simples.

Muitos idiomas de programação ou plataformas diferentes usar esses formatos com Menor diferenças de layout.

Como são arquivos monolíngues, um programa de localização precisa manter versões paralelas destes arquivos – uma para o idioma do texto original e outras para os idiomas de tradução.

O Gettext produz arquivos de valores-chave 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] "Cheque! This key has a description! (At least in some formats)"
msgstr[1] "Check it out! Esta chave tem %s descrições! (At least in some formats)"

Existem formatos competidores com funcionalidades e layouts semelhantes que variam de maneiras relativamente Menores.

Arrasteiras associativas

Enquanto outros formatos precisam de código personalizado (parsers) para lê-los, alguns formatos são mais fáceis para desenvolvedores e localizadores. Formatos com base em matrizes .JSON (JavaScript) e PHP podem ser lidos e mapeados diretamente em estruturas de código comuns (matrizes) que são fáceis de manipular. As matrizes podem ser complexas e diferentes aplicativos geram estruturas personalizadas de matrizes.

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

{
    "id": "simple_key",
    "translation": "simple key, simple message, so simple."
},

O Angular usa as próprias chaves como chaves em suas colunas:

"simple_key": "Sou uma chave simples com uma mensagem simples."

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