Cuidados importantes ao configurar i18n no Django

A Babilônia caiu não foi por acaso. Internacionalização (aka i18n) é trabalhoso por natureza, e quando você esbarra em sutilezas de configuração pode ser irritante.
Esta semana eu decidi finalmente adaptar o site do Small Acts Manifesto para outros idiomas, e no processo acabei caindo numa cilada de coincidências.
Para que você não cometa o mesmo erro, criei uma receitinha de bolo para configurar o projeto.

Começe pelo settings.py:

USE_I18N = True
LANGUAGES = (
    ('en', u'English'),
    ('pt-br', u'Português'),
)
LOCALE_PATHS = (PROJECT_DIR.child('locale'),)

É simples, mas temos alguns pontos de atenção:

  • O LANGUAGES é uma tupla de tuplas. O primeiro elemento das tuplas é o language code. Para português brasileiro o valor é pt-br, tudo minúsculo separado por hífen.
  • LOCALE_PATHS é escrito no plural e aceita vários diretórios, portanto é uma tupla contendo strings.
  • Se você não sabe o que é o PROJECT_DIR, veja nesta palestra.

Crie os arquivos .po

Cada idioma tem um “código fonte” da tradução.
O Django varre todo o código fonte e reúne as strings marcadas para tradução com o comando:

python manage.py makemessages -l en -l pt_BR

Atenção, o parâmetro deve ser pt_BR, com pt em minúsculo e BR em maiúsculo, separados por underscore. Esse formato é o locale name e este valor será usado para criar o diretório que conterá o arquivo django.po.

Usando as traduções

Depois de definir as traduções editando os arquivos .po, basta empacotar a tradução, compilando os .po em .mo para os idiomas disponíveis:

python manage.py compilemessages

Ao longo do projeto você vai usar várias vezes o makemessages e o compilemessages.
Se você for realizar traduções colaborativas, o Transifex pode ajudar bastante e é grátis para projetos open source.

Mas e a cilada?

Quando eu implementei conteúdo em português tudo funcionava bem no ambiente de desenvolvimento, mas no ambiente de stage o site só exibia o idioma padrão que é o inglês. Clássico caso de works on my machine. Como pode?
O problema era que eu estava desenvolvendo no Mac e o site está hospedado em Linux.
Por desatenção, eu executei o makemessages -l pt_br, em minúsculo.
Na minha máquina tudo funcionava, porque o filesystem do Mac não é case sensitive por padrão, logo conseguia encontrar o diretório. Já no Linux, era como se não existisse dicionário disponível em português.

Qual a moral da história?

Use vagrant mesmo em um site ridiculamente pequeno, e compartilhe seus tropeços para que outros possam rir de você, com você. 😛
[]’s, HB!

COMPARTILHE ESTE ARTIGO

Share on facebook
Share on linkedin
Share on twitter
Share on email

21 respostas

  1. eu mudei a configuração do meu mac por conta disso depois de algumas imagens quebrando no servidor pq estavam com esse problema do “case sensitive”

    1. até agora ta tranquilo… o home brew avisa que não é seguro mas não tive problemas até agora.

    2. Recomendo criar um volume com HFS+ e colocar o seu código lá.
      Essa falta de padrão, usando pt-br e pt_BR, é de lascar.

  2. eu mudei a configuração do meu mac por conta disso depois de algumas imagens quebrando no servidor pq estavam com esse problema do “case sensitive”

    1. até agora ta tranquilo… o home brew avisa que não é seguro mas não tive problemas até agora.

    2. Recomendo criar um volume com HFS+ e colocar o seu código lá.
      Essa falta de padrão, usando pt-br e pt_BR, é de lascar.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *