fix(packaging): compila os catalogos i18n antes do build (closes #1267)

[Rossi-Luciano]

O que esse PR faz?

Corrige a issue #1267: a release 4.16.9 não inclui os catálogos .mo compilados quando o packtools é instalado via pip install packtools @ git+https://... — a forma como aplicações consumidoras (ex.: SPS Validator) consomem essa dependência hoje. Isso faz packtools.sps.i18n.set_locale() cair silenciosamente no fallback (fallback=True) e manter todas as mensagens de validação em inglês, mesmo com o locale certo selecionado.

Causa raiz: MANIFEST.in só incluía *.mo na distribuição (não os .po fonte), e não havia nenhuma etapa de build que gerasse esses .mo a partir dos .po — sem workflow de CI/release configurado, o único jeito de obter os .mo seria rodar manualmente make compile_messages antes de publicar, o que nunca foi feito para a 4.16.9.

Correção:

1. Adiciona pyproject.toml com [build-system] declarando Babel>=2.12 como dependência de build (o setup.py não tinha esse arquivo, então o pip buildava num ambiente isolado sem acesso a bibliotecas extras).
2. Novo comando build_py customizado em setup.py (compile_sps_i18n_catalogs) que compila packtools/sps/locale/*/LC_MESSAGES/*.po para .mo antes do build_py original rodar, garantindo que os .mo existam no disco antes da resolução de package_data/manifest.
3. MANIFEST.in passa a incluir também *.po (fallback: catálogos fonte sempre disponíveis, mesmo se o passo de compilação for pulado por algum motivo).
4. Teste automatizado (tests/sps/test_i18n_packaging.py) que builda o wheel e instala num venv limpo, exatamente como a issue sugeriu.

Onde a revisão poderia começar?

• setup.py — compile_sps_i18n_catalogs() e o cmdclass={"build_py": build_py}.
• pyproject.toml — novo, declara Babel como dependência de build.
• MANIFEST.in — inclusão de *.po além de *.mo.
• tests/sps/test_i18n_packaging.py — teste de build+instalação em venv limpo.

Como este poderia ser testado manualmente?

Reproduzindo os mesmos passos da issue #1267, mas após esta correção:

python -m venv .venv-clean
source .venv-clean/bin/activate
python -m pip install "packtools @ git+https://github.com/Rossi-Luciano/packtools@fix/1267-package-locale-mo"

python - <<'PY'
from packtools.sps import i18n
print(i18n.LOCALE_DIR.exists())  # True

i18n.set_locale("pt_BR")
print(i18n._("Got {obtained}, expected {expected}"))
# Obtido {obtained}, esperado {expected}

i18n.set_locale("es")
print(i18n._("Got {obtained}, expected {expected}"))
# Se obtuvo {obtained}, se esperaba {expected}
PY

Também dá pra rodar o teste automatizado novo isoladamente: pytest tests/sps/test_i18n_packaging.py -v (builda o wheel e instala num venv limpo próprio, ~20s).

Testei localmente das duas formas (wheel builda via pip wheel . --no-deps e instalação via git+file://...) e confirmei que o resultado bate exatamente com o "Comportamento esperado" descrito na issue.

Algum cenário de contexto que queira dar?

Essa issue foi aberta pelo próprio pitangainnovare durante a revisão de um PR no SPS Validator (scieloorg/spsvalidator#38), que estava atualizando o pin do packtools para 4.16.9 e tentando conectar set_locale() ao locale do Flask-Babel — o wiring do lado do spsvalidator já está pronto e só vai ter efeito prático depois que esta correção for mesclada e uma nova tag/release for cortada.

Quais são os tickets relevantes?

Closes #1267. Relacionado a #1257 (i18n das mensagens de validação, que introduziu set_locale()) e a scieloorg/spsvalidator#38.

Referências

• Release 4.16.9 não inclui catálogos .mo, fazendo set_locale() manter mensagens em inglês #1267
• chore(deps): atualiza packtools para 4.16.9 e bump para v0.3.0 spsvalidator#38

---

Segurança da informação (NSI.04)

Este PR manipula dados sensíveis ou pessoais (LGPD)?

• Sim
• Não

Este PR altera autenticação, autorização, controle de acesso ou gerenciamento de sessão?

• Sim
• Não

Este PR introduz, atualiza ou remove dependências de terceiros?

• Sim — adiciona Babel>=2.12 como dependência de build (via pyproject.toml, [build-system] requires), não como dependência de runtime instalada junto com o pacote. Já era usada como dependência opcional do extra webapp (optional-requirements.txt), agora também declarada formalmente para a etapa de build.
  • Verificado e aprovado
  • Pendente / vulnerabilidade aceita com justificativa:
• Não

Este PR foi validado pelo pipeline de segurança (SonarQube / Trivy)?

• Sim
• Não aplicável a este PR — repositório não tem pipeline de Sonar/Trivy configurado; validação feita via suíte de testes local (tests/sps/test_i18n.py, tests/sps/test_i18n_packaging.py) e build/instalação manual em venv limpo.

Este PR concatena, monta ou executa comandos SQL, HTML ou JavaScript a partir de entrada externa?

• Sim
• Não — mudanças restritas a configuração de build/empacotamento (setup.py, pyproject.toml, MANIFEST.in) e um teste; nenhuma mudança em código de validação/runtime.

Este PR expõe novos endpoints, telas ou serviços?

• Sim
• Não.

Algum segredo, senha, chave ou token está sendo adicionado ao código-fonte?

• Não, nenhum segredo foi commitado
• Sim