Algumas considerações:
1. Traduções
Quem fará as traduções? Pessoas que também estão conectadas ao site? Uma agência de tradução? Ao usar Gettext você estará trabalhando com arquivos 'pot' (.po). Esses arquivos contêm o ID da mensagem e a string da mensagem (a tradução). Exemplo:
msgid "A string to be translated would go here"
msgstr ""Agora, isso parece muito bom e compreensível para quem precisa traduzir isso. Mas o que acontece quando você usa palavras-chave, como Mike sugere, em vez de frases completas? Se alguém precisa traduzir um msgstr chamado "address_home", ele ou ela não tem idéia se deve ser um cabeçalho "endereço residencial" ou se é uma frase completa. Nesse caso, certifique-se de adicionar comentários ao arquivo antes de chamar a função gettext, assim:
/// This is a comment that will be included in the pot file for the translators
gettext("ready_for_lost_episode");
Usando
xgettext --add-comments=/// ao criar os arquivos .po irá adicionar esses comentários. No entanto, não acho que Gettext deva ser usado dessa maneira. Além disso, se você precisar adicionar comentários com todos texto que você deseja exibir você a) provavelmente cometerá um erro em algum momento, b) seu script inteiro será preenchido com os textos de qualquer maneira, apenas em forma de comentário, c) os comentários precisam ser colocados diretamente acima do Gettext função, que nem sempre é conveniente, dependendo da posição da função em seu código. 2. Manutenção
Uma vez que seu site cresce (ainda mais) e seus arquivos de idioma junto com ele, pode ficar muito difícil manter todas as traduções diferentes dessa maneira. Toda vez que você adiciona um texto, você precisa criar novos arquivos, enviar os arquivos para os tradutores, receber os arquivos de volta, certificar-se de que a estrutura ainda está intacta (tradutores ansiosos estão sempre dispostos a traduzir a sintaxe também, tornando o arquivo inteiro inutilizável :)), e termine com a importação das novas traduções. É factível, com certeza, mas esteja ciente de possíveis problemas nesse sentido com sites grandes e muitos idiomas diferentes.
Outra opção:combine sua 2ª e 3ª alternativas:
Pessoalmente, acho mais útil gerenciar a tradução usando um CMS (simples), mantendo as variáveis e traduções em um banco de dados e exportar os textos relevantes para arquivos de idioma:
- adicionar variáveis ao banco de dados (por exemplo:id, page, variable);
- adicione traduções a essas variáveis (por exemplo:id, varId, language, translation);
- selecione as variáveis e traduções relevantes, grave-as em um arquivo;
- inclua o arquivo de idioma relevante em seu site;
- crie sua própria função para exibir um texto de variáveis:
text('var'); ou talvez algo como __('faq','register','lost_password_text'); O ponto 3 pode ser tão simples quanto selecionar todas as variáveis e traduções relevantes do banco de dados, colocá-las em um array e gravar o array serializado em um arquivo.
Vantagens:
-
Manutenção. Manter os textos pode ser muito mais fácil para grandes projetos. Você pode agrupar variáveis por página, seções ou outras partes do seu site, simplesmente adicionando uma coluna ao seu banco de dados que define a qual parte do site essa variável pertence. Dessa forma, você pode rapidamente obter uma lista de todas as variáveis usadas em, por exemplo, a página de perguntas frequentes.
-
Traduzindo. Você pode exibir a variável com todas as traduções de todos os idiomas diferentes em uma única página. Isso pode ser útil para pessoas que podem traduzir textos em vários idiomas ao mesmo tempo. E pode ser útil ver outras traduções para ter uma ideia do contexto para que a tradução seja a melhor possível. Você também pode consultar o banco de dados para descobrir o que foi traduzido e o que não foi. Talvez adicione carimbos de data/hora para acompanhar possíveis traduções desatualizadas.
-
Acesso. Isso depende de quem vai traduzir. Você pode envolver o CMS com um login simples para conceder acesso a pessoas de uma agência de tradução, se necessário, e permitir que apenas alterem determinados idiomas ou mesmo determinadas partes do site. Se esta não for uma opção, você ainda pode enviar os dados para um arquivo que pode ser traduzido manualmente e importá-lo mais tarde (embora isso possa vir com os mesmos problemas mencionados anteriormente). Você pode adicionar uma das traduções que já estão lá (inglês ou outro idioma principal) como contexto para o tradutor.
Em suma, acho que você descobrirá que terá muito mais controle sobre as traduções dessa maneira, especialmente a longo prazo. Não posso dizer nada sobre velocidade ou eficiência dessa abordagem em comparação com a função gettext nativa. Mas, dependendo do tamanho dos arquivos de idioma, não acho que vai ser uma grande diferença. Se você agrupar as variáveis por página ou seção, sempre poderá incluir apenas as partes necessárias.
