i18next-parser
i18next-parser copied to clipboard
i18next
Default value as the single source of truth (overwrite existing values in the json file)
Hello,
🚀 Feature Proposal
I'd like to have an option to make the default values defined in the t function to overwrite existing value in the produced json file.
Motivation
Right now the parser is detecting new keys and their default values used across the codebase and add them to the json file. But if we change the default value of a key in the codebase, the change isn't reflected in the json file. I think it would be better to reflect the change, or at least give an option to allow it.
Example
// a new config option
{
overwriteDefaultValues: true
}
The parser doesn't currently keep a record of the defaultValues so it has no way to know if it has changed.
Such an option would only allow all translations to be replaced by the default values. And I'm not really see value in that, even though I'm not opposed to it.
If you are willing to implement a proper solution that tracks defaultValues and a resetDefaultValueOnChange option, I will happily review and merge the PR!
I didn't have tracking default values in mind, but something like :
- Read the existing json
- For each "t" function detected, if the key already exists in the json and there is a default value defined in "t", replace the key's value in the json.
I guess most of this workflow is already implemented so you can add new keys to the existing json?
I understood your proposal but I'm not keen to add it. It would overwrite all translations with the default value, even the ones that are still good. How is that a good thing?
I'm not sure I understand this :
It would overwrite all translations with the default value, even the ones that are still good
What do you mean by still good? Maybe our usage of this library is not regular but as we use our default values as the single source of truth to generate a default en.json file, with the change I'm suggesting nothing would be lost.
The keys that already exists but which values weren't modified won't be modified either in our en.json file. And the modified ones will be replaced but only in our default english file. Once it's done we use a translation service like lokalise that will detect that values have been modified for these keys and notify the translators so they can update the other languages.
What am I missing? It seems a reasonable workflow to me, our code is our only source of truth for our default i18n file and I don't expect anyone in the team to deal with the en.json file directly. And all the other translations files are dealt with on the external service outside of our dev workflow.
I'm not used to rely on the default value to populate my translation files but it now makes sense to me. If you want to make a PR, I will happily review it.
I also use the defaultValue in this way. Perhaps I misunderstood what the default value was meant to do if this workflow isn't how you're using it?
The feature make sense to me and would be a welcome addition. You are welcome to open a PR
I’m facing a similar issue here, maybe this will help someone: I call rm locales/dev/translation.json && yarn i18next with dev being my “Developer English” language. This way, my single source of truth – the default value – is available as a json to translators (including English language natives who do the “translations” for en) and is always kept up to date. Does this make any sense to you?
Just a little sidenote: Personally I use defaultValues -> but only during development as soon those default values are in my translation workflow I remove those to avoid bloated bundle sizes
Put up a potential fix, not sure if you get pinged so I'm commenting here @karellm: https://github.com/i18next/i18next-parser/pull/451
