-
-
Notifications
You must be signed in to change notification settings - Fork 672
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support per-layout translations entries #4495
Conversation
|
I will reorganize the commits above, in order to separate the text-modifying edits into a separate commit (which can be dropped - to avoid UI changes). |
8952a98
to
4148e87
Compare
i.e., there is no diff between 8952a98 and 4148e87, just reorged the commits' content by the above force-push. |
27b8ec8
to
8cdeca7
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you. It works as expected, we can now specify different strings per layout and per language. There's one caveat though:
- if we misspell a layout name in
en.json
, then everything is OK because the mistake is caught in compile time 👍 - if we misspell a layout name in other lang, e.g.
cs.json
then it fallbacks to english version 🤔 I wonder if we can do something about it now.
Note that this problem is not new because if we miss the whole string in cs.json
then we also get fallback to english version without any warning. I'd probably fix this issue separatedly.
It would simplify `TranslationsDir.load_lang` method. [no changelog]
Done by: ``` cd core/translations python ./cli.py merge ??.json ``` [no changelog]
[no changelog]
[no changelog]
c5353ae
to
dee67ff
Compare
Good point, thanks! |
Following #4489.
Also, use layout names for translation font keys.