Repository navigation
feat(languages): canonical pt-br translation applied on every migration - #31
Open
lbrunofidelis wants to merge 9 commits into
Open
lbrunofidelis wants to merge 9 commits into
lbrunofidelis wants to merge 9 commits into
Conversation
…ions Upstream and template migrations write english text into portuguese_pt. The step writes the canonical text over the existing, non-deleted tokens and moves updatedAt forward so cached browsers fetch it.
Builds the tokens in scope from the repository language data only, so it runs without a database. Fails on missing, empty or english text, on placeholders that differ from the english ones and on tokens unknown to the repository.
Also covers the warning of the relationship creation page. The texts were hardcoded in the front end.
…translation The 2.51.0 language actions run again on every migration, so their older texts were rewritten and corrected back each time.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Por que
O idioma Português do Go.Data estava incompleto e misturado. Numa cópia do banco real, 6.020 tokens
portuguese_ptainda mostravam o texto em inglês e 113 tinham sobras em espanhol (por exemplo "Tablero principal" no menu e "Copia de seguridade" em Backups), além de textos em português de Portugal ("utilizador", "equipa", "Tem a certeza"). Os questionários dos modelos padrão de surto estavam quase todos em inglês. Cada versão trazia uma migraçãoportuguese.jsonprópria, aplicada uma única vez, e qualquer correção feita direto no banco se perdia ou divergia entre instâncias.Causa
O português não tinha fonte única. Os textos vinham das migrações versionadas (
migrations/<versão>/data/portuguese/), executadas uma vez cada, e do que cada instância editou no banco. Nada garantia cobertura dos tokens novos nem corrigia textos antigos. Além disso, as ações da 2.51.0 estão registradas mais de uma vez nomigrateModelData.js(buildNo 2, 5, 6 e 7) e rodam de novo a cada migração, regravando 13 tokens com o texto antigo do2.51.0/data/portuguese/portuguese.json.O que muda
server/install/scripts/languages/portuguese_pt/:system.json(interface, permissões, erros da API, dados de referência e os 183 itens de ajuda),templates.json(questionários dos 11 modelos padrão) eidentical-to-english.json(231 tokens que ficam iguais ao inglês de propósito: siglas, números, nomes de países, Latitude, Status...). São 9.344 tokens, revisados um a um com o glossário validado pela equipe (cluster = grupo, follow-up = acompanhamento, outcome = evolução, deceased = óbito, hospitalization = hospitalização).applyPortugueseTranslations.js: passo que roda no fim domigrate-databasee doinit-database(install.js,migrateDatabase.js). Grava o texto canônico só nos tokensportuguese_ptexistentes e não excluídos cujo texto difere, comupdatedAt/dbUpdatedAt= agora (o frontend busca os tokens alterados depois doLANGUAGE_UPDATE_LAST, então basta recarregar a página). Nunca cria nem restaura tokens. Uma segunda execução não grava nada. Resumo emlogs/application.log:Portuguese translations: N checked, N updated, N absent or deleted.npm run check-pt-translations(server/scripts/checkPortugueseTranslations.js): lê os dados de idioma do repositório, sem banco, e falha quando um token sem PT, com PT vazio, com PT igual ao inglês fora da allowlist, com{{placeholders}}diferentes do inglês ou desconhecido no repositório. Roda no CI depois doBuild(.github/workflows/ci.yml).2.58.3: tokens em inglês do diálogo "Consulta via API" e do aviso de erro da criação de relacionamento, usados pelo PR do Frontend.2.51.0/data/portuguese/portuguese.json: dois textos alinhados ao canônico, para que a reexecução da 2.51.0 não desfaça o PT-BR a cada migração.Importante para quem opera instâncias: a partir deste PR, o arquivo canônico vence. Textos em português editados direto no banco ou importados por planilha voltam ao canônico no próximo deploy. Toda correção passa a ser feita por PR no canônico.
Como validar
npm run check-pt-translationsdeve terminar comportuguese_pt check passed: 9344 tokens in scope.npm run migrate-databasee procure a linhaPortuguese translations:emlogs/application.log.npm run migrate-databasede novo: a linha deve dizer0 updated.localStorage.Validado
npm run check-pt-translations: passed, 9.344 tokens no escopo, 0 findings.migrate-database:9344 checked, 7442 updated, 64 absent or deleted. Depois: 0, 0 e 0.0 updated. Antes da correção da 2.51.0 eram2 updateda cada execução.LNG_LAYOUT_MENU_ITEM_DASHBOARD_LABEL= "Dashboard"): restaurado para "Painel de controle" pelomigrate-database.init-databaseem banco vazio:9344 checked, 7473 updated, 0 absent or deleted, e a varredura dá 0 tokens iguais ao inglês ou diferentes do canônico.LANGUAGE_UPDATE_LASTavançou sozinho para o horário da migração.english_usintacto; segunda execução com zero gravações. Script de prova do check: cada tipo de problema faz o script sair com 1.npm run buildok.eslintnos.jstocados: só os 2 erros de indentação já existentes emmigrateModelData.js:482-483, que não são deste PR.Fora do escopo
english_us.migrateModelData.jscontinua, e merece card próprio. Aqui só os textos foram alinhados.LNG_PAGE_CREATE_OUTBREAK_LABEL_NOTIFY_TEAMcru. O passo canônico não cria tokens, de propósito. Numinit-databaselimpo os 9.344 existem.Why (English)
The Portuguese language was incomplete and mixed. On a copy of the real database, 6,020
portuguese_pttokens still showed English, 113 had Spanish leftovers ("Tablero principal" in the menu, "Copia de seguridade" for Backups), and others were European Portuguese ("utilizador", "equipa"). The default outbreak template questionnaires were almost all in English. Each version shipped its ownportuguese.jsonmigration, applied once, and fixes made directly in a database were lost or diverged between instances.Cause
Portuguese had no single source. Texts came from versioned migrations, each run once, and from whatever each instance edited in its database; nothing ensured coverage of new tokens or fixed old ones. Also, the 2.51.0 language actions are registered several times in
migrateModelData.js(buildNo 2, 5, 6, 7) and run again on every migration, rewriting 13 tokens with the old text of2.51.0/data/portuguese/portuguese.json.What changes
server/install/scripts/languages/portuguese_pt/:system.json(UI, permissions, API errors, reference data, 183 help items),templates.json(questionnaires of the 11 default templates) andidentical-to-english.json(231 tokens intentionally equal to English). 9,344 tokens, reviewed one by one against the team-validated glossary.applyPortugueseTranslations.js, run at the end ofmigrate-databaseandinit-database: writes the canonical text only into existing, non-deletedportuguese_pttokens whose text differs, settingupdatedAt/dbUpdatedAtto now so a page reload is enough. Never creates or restores tokens; a second run writes nothing. Summary line inlogs/application.log.npm run check-pt-translations: reads the repository language data (no database) and fails on missing, empty, equal-to-English-not-allowlisted, placeholder-mismatch or unknown tokens. CI runs it afterBuild.2.58.3: English tokens used by the Frontend PR.2.51.0/data/portuguese/portuguese.json: two texts aligned with the canonical file so the 2.51.0 re-execution no longer undoes them.Operators note: the canonical file wins from now on. Portuguese texts edited in a database or imported from a spreadsheet go back to the canonical text on the next deploy; corrections go through a pull request.
How to validate
npm run check-pt-translations→portuguese_pt check passed: 9344 tokens in scope.npm run migrate-database, then look forPortuguese translations:inlogs/application.log.0 updated.localStorage.Validated
9344 checked, 7442 updated, 64 absent or deleted. After: 0, 0, 0.0 updated(it was2 updatedper run before the 2.51.0 fix).migrate-database.init-databaseon an empty database:9344 checked, 7473 updated, 0 absent or deleted; scan 0 equal to English, 0 different from canonical.LANGUAGE_UPDATE_LASTadvanced by itself.npm run buildok;eslinton touched.jsfiles: only the two pre-existing indentation errors atmigrateModelData.js:482-483.Out of scope
english_us.migrateModelData.jsdefect stays and deserves its own card.LNG_PAGE_CREATE_OUTBREAK_LABEL_NOTIFY_TEAMraw. The canonical step does not create tokens by design.