Feature Description
Add a Spanish locale for the GUI, including the first-run Terms of Use and the mandatory pre-reset acknowledgements, with the same legal meaning as the current English.
Motivation
The window already does the important work: Terms acceptance, the 8-point reset warning, the physical-maintenance checkbox, and the second responsibility confirmation. Those texts are what a Spanish-speaking owner needs to understand before any write. They are all hardcoded in English in maintenance_counter_app.py today.
I would like to contribute a Latin American Spanish catalog (es) and keep English as the default.
Proposed Solution
- Extract user-facing copy into a small catalog (current English wording unchanged as the fallback).
- Ship
es with the same structure: Terms (DISCLAIMER), RESET_WARNING, ACK_PHYSICAL, ACK_RESPONSIBILITY, SAFETY_SHORT, buttons, and dialogs.
- Pick the language from the existing settings JSON (new
lang field) or the Windows locale. English remains the fallback.
- Do not bump
TERMS_VERSION unless you want people who already accepted v2 to re-agree. The Spanish would be a translation of the same v2 terms, not a new agreement.
- Leave
model_db.py, pad names from the database, USB/protocol tokens, and operation-log event names in English.
Docs and the GitHub Pages site (USER_GUIDE.md, TERMS_OF_USE.md, docs/faq.html) can stay English in this first PR.
Alternatives Considered
- Hardcoding Spanish in the
.py files — blocks the next language and makes review harder.
- Translating the website/docs in the same PR — larger review, different audience.
- Changing
TERMS_VERSION on a same-meaning translation — would force a re-accept for no legal change.
Scope / Effort Estimate
Medium — one GUI file plus a string catalog. tests/test_operations.py should stay green if exception strings in operations.py remain English (or keep English as default).
Questions
- Is
es (generic Latin American Spanish) acceptable, or do you prefer es-MX / es-ES?
- Should people who already accepted Terms v2 see Spanish without accepting again?
- Do you want an in-app language control, or OS locale only for the first version?
Happy to send this as a PR once the approach looks right.
Feature Description
Add a Spanish locale for the GUI, including the first-run Terms of Use and the mandatory pre-reset acknowledgements, with the same legal meaning as the current English.
Motivation
The window already does the important work: Terms acceptance, the 8-point reset warning, the physical-maintenance checkbox, and the second responsibility confirmation. Those texts are what a Spanish-speaking owner needs to understand before any write. They are all hardcoded in English in
maintenance_counter_app.pytoday.I would like to contribute a Latin American Spanish catalog (
es) and keep English as the default.Proposed Solution
eswith the same structure: Terms (DISCLAIMER),RESET_WARNING,ACK_PHYSICAL,ACK_RESPONSIBILITY,SAFETY_SHORT, buttons, and dialogs.langfield) or the Windows locale. English remains the fallback.TERMS_VERSIONunless you want people who already accepted v2 to re-agree. The Spanish would be a translation of the same v2 terms, not a new agreement.model_db.py, pad names from the database, USB/protocol tokens, and operation-log event names in English.Docs and the GitHub Pages site (
USER_GUIDE.md,TERMS_OF_USE.md,docs/faq.html) can stay English in this first PR.Alternatives Considered
.pyfiles — blocks the next language and makes review harder.TERMS_VERSIONon a same-meaning translation — would force a re-accept for no legal change.Scope / Effort Estimate
Medium — one GUI file plus a string catalog.
tests/test_operations.pyshould stay green if exception strings inoperations.pyremain English (or keep English as default).Questions
es(generic Latin American Spanish) acceptable, or do you preferes-MX/es-ES?Happy to send this as a PR once the approach looks right.