Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Stop committing generated .mo (and .po) files; generate them at build time

Aperta
  • Qualcosa non va?
#441 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
52/100
Tipo di issue
Refactoring
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
python
Ambito
build-system, cli, localization

Direzione di ricerca

Start by reading pyproject.toml, the existing doit localize task, the check-mo-freshness workflow, and the PyInstaller spec files. Verify how packaging currently includes locale data before choosing the build hook. Done means .mo files are generated during package builds, excluded from git, bundled correctly by PyInstaller, and the obsolete freshness workflow is removed.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

enhancement

The tabcmd/locales/*/LC_MESSAGES/tabcmd.mo files are checked into git today, and .po files are gitignored but still regenerated locally when someone runs doit localize. This has two problems:

  1. Drift. The committed .mo files can - and do - go out of sync with the .properties sources they are built from. Before #440 landed, a fresh doit localize against the tip of development regenerated all 11 locale .mo files with ~20 keys different from what was committed (mostly stale entries for old keys and missing entries for new keys added since the last regen). Users hitting the drifted keys would see stale translations or fall back to the raw key.

  2. Reviewer noise. .mo diffs are binary and unreadable in PRs. Reviewers cannot see whether a .mo change matches its intended .properties change.

The check-mo-freshness workflow added in #440 catches drift at PR time by regenerating and diffing. That closes the immediate leak but keeps the underlying pattern of "generated file committed to git."

Better long-term: treat .mo (and if practical .po) like tabcmd/_version.py - generate them during pip install / packaging, .gitignore them, and stop tracking them. pyproject.toml can wire the generation into the build backend so wheels and pyinstaller bundles include them. Contributors then only edit .properties; no regenerate-and-commit dance, no drift possible.

Prior art: most Python i18n projects (Babel, Django, Flask-Babel) treat .mo as build output.

Rough plan

  • Add a build step that runs doit localize (or the equivalent msgfmt invocations) at pip install / wheel build time.
  • Verify pyinstaller still bundles the generated .mo files correctly (via --collect-data tabcmd.locales which is already in the spec files).
  • .gitignore **/*.mo; git rm --cached the tracked ones.
  • Remove the check-mo-freshness workflow (it becomes moot once nothing is committed to drift from).
Lingua principale
Python
Stelle
52
Fork
17
Merge medio
5g 20h
PR unite (30g)
2

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di tableau/tabcmd

Tutte le issue di tableau/tabcmd

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.