Arquivos de localização (Strings)

Arquivos de localização são arquivos de texto que podem ser abertos e editados em um editor de texto como o Bloco de Notas ou TextEdit ou 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 exclusivos (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 geralmente 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 dos arquivos sejam válidas.

Para Criar um arquivo de localização, todos os pedaços de texto exibíveis são substituídos por IDs exclusivos 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 for 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 de texto padrão. Se um usuário não Selecionar um idioma, todo o texto será extraído deste arquivo para gerar qualquer exibição. Se o usuário selecionar espanhol, o software é redirecionado para Spanish.txt. Muitos idioma podem ser usados com um sistema como este.

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

Gerenciamento de string

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

Quando todas as Strings estiverem traduzidas, os arquivos são baixados. No processo, o formato de arquivo de localização necessário é criado para corresponder ao texto original.

Recurso formatos de arquivo

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

Planilhas

Arquivos .XLSX e .CSV são suportados. Esses formato são equivalentes para fins de localização e contêm linhas de pares chave-valor. As chave 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. Arquivos .CSV do Zendesk têm uma estrutura fixa, portanto, este tipo de arquivo não requer ajustes adicionais:

"Título","Idioma padrão","Texto padrão","Texto em inglês","Estado da variante"
"simple_key","Alemão","Einfacher Schlüssel.","Simple key.","Atual"

XML

XML é um formato que oferece meta informações na forma de <códigos>. A estrutura de código é usada para determinar onde as chaves e seus valores correspondentes estão, como mostrado aqui a partir de um arquivo XML do Android:

 <string name="simple_key">Just a  key with a message.</string>

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

<trans-unit id="simple_key" resname="simple_key">
 <source xml:lang="de-DE">Nur ein einfacher Schlüssel mit einer einfachen Nachricht.</source>
<target xml:lang="en-GB">Just a simple key with a simple message.</target>
</trans-unit>

Programas QT usam arquivos de recurso com uma estrutura que é muito semelhante a esses formatos padronizados, mas por razões históricas possuem um layout diferente.

Listas simples de chave-valor

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

simple_key: Just a simple key with a simple message.

Muitos idiomas de programação ou plataformas diferentes usam tais formatos com Menor 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 texto original e outras para os idiomas tradução.

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

# This is the amazing description for this key!
msgid "key_with_description"
msgid_plural ""
msgstr[0] "Check it out!" This key has a description! (At least in some formats)"
msgstr[1] "Confira!" Esta chave tem %s descrições! (At least in some formats)"

Existem formatos concorrentes com funcionalidade e layouts semelhantes que variam de maneiras relativamente Menor.

Arrays associativos

Enquanto outros formatos exigem código Personalizado (parsers) para lê-los, alguns formatos são mais fáceis para desenvolvedores e localizadores. Formatos baseados em .JSON (JavaScript) e arrays .PHP 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 aplicativos geram estruturas de array Personalizado.

Por exemplo, 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 chave em seus arrays:

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

Como existem essas diferenças Menor, porém cruciais, estruturas de array .JSON e .PHP amplamente utilizadas são suportadas.