it-ony
commented
7 years ago Hi Andreas,
I roughly get what you want to archive. The idea of this grunt plugin was to generate deeply extended json files with a fallback mechanism.
To address your problem, I would propose that a change in the meaning of the translation key should result in new key.
As an alternative you might want to checkout https://github.com/spreadshirt/grunt-google-localizr where you can download translations from google sheets. Here you could add some color backgrounds to mark changes for the translators.
Cheers, Tony
Hi,
In a living project it might happen that you have to change the meaning of an (already translated) item in the source. So you do the change in the source file (typically english). But the change does not propagate to already translated items.
It would be great if I could somehow "force" a retranslation, by marking some items (e.g. by prefixing the value with '???'). The so marked lines should then propagate to the target files:
By doing so, the translating persons have a marker (e.g. '???') to search for items that need a review. And the developer has a method to trigger a review by the translators.
Example:
en
was already translated to
Now the developer detected, that there was a mistake in the documentation and changes the meaning of the english text.
en
But this will not propagate to the translators as the text was already translated. The already translated meaning will not update -> Bad. If merge-locales detects the change in the english version, it could update the translated file.
The guy translating the file searches for ??? and can identify the items to review.
By the way: You could also prefixing "untranslated" or "new" items with '???' - this will also help translators to identify lines that need translation easily (so they don't need to scan big file from the beginning and look for a different language in all the text manually - which is error prone and annoying)
kind regards
Andreas