Detect changed translations

[googol7]

At the moment react-intl-translations-manager reports

Perfectly maintained, no remarks!

if there’s a translation for a string but it doesn’t detect if the original string changed.

If the original string changes then the translations of the other languages should be marked as fuzzy so that the translators know that they have to change the translated string to match the new meaning.

E.g. gettext: https://www.gnu.org/software/gettext/manual/html_node/Fuzzy-Entries.html

[GertjanReynaert]

This seems like a good suggestion. However, currently I don't really have much time for new features, but feel free to take a stab at a pr!

[mgtitimoli]

You can achieve this using npm-watch as follows:

package.json

{
   ...
   "scripts": {
       "manage:translations": "node ./translationRunner.js",
       "watch": "npm-watch"
   },
   "watch": {
       "manage:translations": "src/translations/extractedMessages/**/*.json"
   }
   ...
}

And then run npm run watch to watch your messages files for changes

[googol7]

Thanks @mgtitimoli this will help detect changed reservations on the fly. But what we'd really need is that translationRunner.js persists these changes.

gettext inserts the keyword Fuzzy in the .po files as a comment. As long as the keyword fuzzy is present the incorrect translation is not being used any longer but the fallback. This workflow is "pro" and we need that here as well. So I suggest the following workflow:

1. react-intl-translations-manager deletes a translation from the language JSON file (e.g. de.json) if the defaultMessage of the default language changed (so we have a fallback to the default language)
2. it then creates a second file with the prefix "fuzzy" for every language (e.g. fuzzy_de.json) which contains all the necessary information for the translators:

• id
• description
• defaultMessage
• old original language description
• old original language defaultMessage
• new original language description
• new original language defaultMessage
• date & time it has changed

an alternative would be to include comments in the JSON files for the translators and then minify them to get the resulting language JSON files for production.

what do you think?

[GertjanReynaert]

@googol7 Thx a lot for your input. This is definitely a problem I want to tackle, and your described workflow seems feasible. Since I couldn't come up with an approach myself, I'll give this a try (when I have some spare time) but this might be the first step to a good solution.

I would go with a separate fuzzy file, since JSON actually doesn't support comments, and adding support with for example JSON5 will probably be more difficult than adding a fuzzy file.

[googol7]

@GertjanReynaert Thx for picking up this suggestion. I think it would be good to also have the old and new default message (oldTranslation, newTranslation) so that it’s obvious that a translator made a new translation in the field "newTranslation" when we get back the file fuzzy_de.json from him.

Just made a test - I think this could work:

"IdXyz": {
    "newTranslation": "",
    "newOriginalLanguageDefaultMessage": "",
    "newOriginalLanguageDescription": "",
    "oldTranslation": "",
    "oldOriginalLanguageDefaultMessage": "",
    "oldOriginalLanguageDescription": ""
},

[vebaspect]

Any progress?

[Lyncee]

Same on my side, it is quite important to be able to detect updated 'values'.

At the moment, the extracted messages in defaultMessage.json file contains the updated value, but the ouput locales files related values are not updated.

I would expect that if a value in defaultMessage is updated compared to the default locale, it should invalidate all related values in other locale files. Maybe replace the previous value with undefined, so we know that those values need to be translated again ?

EDIT: I am using a 3rd party translation provider, and committing updated locales to github directly has an impact the rest of the workflow. However as the values in the locales are not invalidated (that's why I would suggest to at least have an option to force them to undefined in the output locales), the 3rd party can't mark them as fuzzy to include the new pair as part of the new batch of translations :)

EDIT2: Deleting key and adding key is for everybody 90% of translation management, but we often have to update existing copies, which does not change the key itself inside the pair.

Keep up the good work !

[ultrababs]

+1 - We're currently running into an issue where we have the translation files that contain a mix of both translated and untranslated strings. If the default message of any untranslated strings are changed, I would expect all the translation files to also update those strings without their respective JSON objects automatically also. My workaround is to delete all the untranslated strings in the translation files and just run the translation script again, but it's a hassle and can be easily forgotten. Would be awesome to have this enhancement implemented!