feat(i18n): normalize translation files structure and patch zh-TW translations#247
Conversation
jundot
left a comment
jundot
left a comment
There was a problem hiding this comment.
Thanks for the normalization work and the zh-TW translations. Couple of things i noticed:
1. the normalize script parses JSON with regex instead of a JSON parser
scripts/normalize_i18n.py processes locale files line by line using a regex pattern (r'^(\s*)"([^"]+)"(\s*:\s*)(.*)$'). This works for the current flat key-value structure but it's fragile. If the i18n files ever get nested objects or arrays, this breaks silently. Using json.load() to read and json.dump() with sort_keys (or a custom key order from en.json) would be more robust and still preserve the key ordering goal.
2. 2-space to 4-space indent change
The normalization changes all locale files from 2-space to 4-space indentation because it mirrors en.json's formatting. But 2-space is the more common convention for JSON files. If the goal is consistency across all locale files, would it make more sense to update en.json to use 2-space instead? That way the diff for ja/ko/zh files becomes purely key reordering without the indent noise.
|
Thanks for the great feedback! I agree with both points.
(bwt, I originally used regex trying to preserve the empty lines used for visual grouping in en.json, but I agree that standard and safe JSON serialization is much more important for maintainability). I've pushed the updated commits. |
jundot
force-pushed
the
main
branch
7 times, most recently
from
f6faf2f to
c2beead
Compare
|
Looks good, thanks for the updates. Merging this now. I noticed a couple minor things but i'll handle them in a follow-up commit:
|
2 participants
This PR standardizes the structure of all i18n translation files under
omlx/admin/i18n/by treatingen.jsonas the single source of truth.Over time, keys were added or updated in
en.jsonwithout being consistently synchronized to other locale files, which led to key drift and structural inconsistencies across translations. This PR addresses that maintenance issue by introducing a normalization utility and applying it to the current locale files. It also fills in missing entries for Traditional Chinese.Changes made
1. Added
scripts/normalize_i18n.pyThis developer utility normalizes locale files against
en.json.It:
en.jsonas the baseline schemajsonlibrary instead of regex for better robustness and maintainability. All JSON files are now formatted with a standard 2-space indentation.2. Normalized existing locale files
Applied the normalization script to:
zh.jsonzh-TW.jsonja.jsonko.jsonThis produces a one-time large diff because the current files are being brought into a consistent canonical structure.
3. Completed missing Traditional Chinese entries
I also identified 10 keys missing from
zh-TW.jsonthat already existed inzh.json, and added Traditional Chinese translations for them.Notes for reviewers
The large diff is primarily caused by the initial normalization pass (reordering / restructuring to match
en.json), not by broad semantic translation changes. This should be mostly a one-time cleanup and should reduce churn in future i18n updates.Related Issues
None.
Type of Change
New feature / Enhancement (non-breaking change which adds functionality or improves DX)
Checklist:
No tests required for i18n JSON files/developer scripts, and I have performed a self-review