Add option to ignore contexts #453
Comments
|
I don't think this is possible atm. I've never got a situation in which the context had to be different per locale. @jamuhl Does it seem to you as a valid use of context or would you recommend a different strategy? |
|
I guess context can be different per language...as languages can be very different in usage. In locize we were strict with the first versions - but nowadays you can have different keys / context in different languages (makes the editor a lot more difficult to do things right - but I think it's reality and needed) |
|
@Teajey I'd be open for a PR but I'd like to explore options first.
Would you see value in this? |
|
I find that if I were to ignore context in one locale, I would want to ignore context in all locales. Especially if I have a context token in a parent key. What if I ignore context in EN, but not JA (or vice-versa)? I would still end up with undesired keys being inserted or removed from locales like so: diff --git a/src/locales/ja/translation.json b/src/locales/ja/translation.json
index 773c8e668..c516836ef 100644
--- a/src/locales/ja/translation.json
+++ b/src/locales/ja/translation.json
@@ -50,18 +50,13 @@
},
- "in_template>run_once": {
- "label": "切り替え前",
- "validation": {
- "not_the_same": "時間内用と時間外用で同じテンプレートは設定できません。",
- "required": "就業時間内用のテンプレートを選択してください。"
- }
- },
+ "in_template>run_once": "UNTRANSLATED",
|
🚀 Feature Proposal
Add an option e.g.
ignoreContextthat causes the parser to be agnostic about contexts; neither adding, nor removing them from the locale files.Motivation
I like the idea of using contexts differently in different locales. I can create a succinct translation in one locale, using contexts and nesting, and then use a completely different strategy in another locale. This is quite useful between languages that are syntactically different.
But i18next-parser treats all locales as if they're uniform.
Example
(Note: using
contextSeparator: ">")In EN, I use these translation keys:
{ "in_template": { "label": "In Template", "label>run_once": "From Template", "validation": { "not_the_same": "$t(in_template.label) and $t(out_template.label) must not be the same.", "required": "$t(in_template.label) is required." } }, "out_template": { "label": "Out Template", "label>run_once": "To Template", "validation": { "required": "$t(out_template.label) is required." } } }The keys are all nice and normalized, and the nested translations even use the correct context!
and in JA I use these translation keys:
{ "in_template": { "label": "切り替え前テンプレート", "validation": { "not_the_same": "切り替え前用と切り替え後用で同じテンプレートは設定できません。", "required": "就業切り替え前用のテンプレートを選択してください。" } }, "in_template>run_once": { "label": "切り替え前", "validation": { "not_the_same": "時間内用と時間外用で同じテンプレートは設定できません。", "required": "就業時間内用のテンプレートを選択してください。" } }, "out_template": { "label": "時間外テンプレート", "validation": { "required": "就業時間外用のテンプレートを選択してください。" } }, "out_template>run_once": { "label": "切り替え後", "validation": { "required": "就業切り替え後用のテンプレートを選択してください。" } } }In JA, the translation strings are less uniform, and it's not really my place to change them, so I put the contexts on different keys, and use a more redundant approach.
Now, if I run i18next-parser I get this diff:
The contexts are assumed to be unused, as I'm assigning them dynamically, e.g:
So I could add more comments next to the
t()call:But then I get this result:
Some unnecessary keys are added, and some other required keys are still removed/overwritten.
This seems like a perfectly legitimate use of i18next's contexts, and I think it could work with i18next-parser if I could just configure it to leave contexts alone.
Perhaps there is already a way that i18next-parser can accommodate for this usage? If so, I haven't been able to find it all day...
The text was updated successfully, but these errors were encountered: