Obsolete system key translations

[Zasa-san]

There are many terms in the list of translations in Settings -> Translations -> User Interface that are obsolete. These terms belong to strings that are no longer used in the UI. This is making the already big list more unmanageable and at times can be confusing for users.

There is a simple way of doing an initial scan for obsolete strings by using scripts/checkTranslations.mjs. A function similar to the one being used to detect new translatable strings can be used to this end.

The problem is that this will return many false positives for obsolete translations. An example of false positives is: https://github.com/huridocs/uwazi/blob/0dadcceffbc1787a6bc590f59b7f1ffea5f92d53/app/react/Settings/components/AccountSettings.js#L77-L92

When the script parses the code the instantiations of this function will not be picked up as translatable strings. This means that keys on the database that are used in functions like this will be incorrectly considered obsolete, even though at runtime the function returns fully translatable text. (This also means that the script will not check if the values passed to this function are included in the translations collection)

Initially implementing the check for obsolete translations might require some manual work identifying which keys are actually obsolete. But including this scan on the checkTranslations script might help keep a cleaner list of translatable terms in the future.

We could also look up for a way of better scanning the code to pick up on these functions that return <Translate />.

[llfinch]

Hi @Zasa-san and all! I just wanted to jump in here to underline how important this issue is from another perspective (user confusion and ability to manage the list are already really good reasons!). When it comes to translation of UI terms in key languages beyond what we have internal capacity for (e.g. Ukrainian), if we have no way of having a clean list of UI terms, we are potentially wasting lots of our limited resources in the organization on paying for translations of terms that are obsolete.

[llfinch]

Hi again! I've been thinking about this a lot, and I just wanted to add some thoughts here. It would be great if whatever solution is applied to this issue, that there is a way to notify us of which exact terms were removed from the list. That is to say, going forward, when a term is no longer in use because new development has replaced its previous application and whatever solution we have removes the term from the list, we are notified that this has happened. So that we don't have to periodically and manually compare back and forth line by line to see what's happened. (The same sentiment goes for when new terms are added to the list.)

[mfacar]

A revision was done manually, with the following changes: 3 keys added 83 keys deleted 31 keys updated

A global check for text matches was added to the check-translations command from the pipeline of GitHub. This check detects potential obsolete keys by searching the text in all the code. Although can't guarantee 100% of effectiveness, all the obsolete values detected manually were reported by the command.

Additionally, the CSV files from uwazi-contents were updated with the currently valid keys by the PR #1. About 290 keys were added and 112 keys were deleted, several values were updated with the correct value in English. For Spanish, almost all of the translations were completed.

The following command is available to check differences between the current values in the database against the repository of content in GitHub, where es is the language to compare

node ./scripts/compareTranslations.js --locale=es

Finally, a file with the keys and values for English was added to the content repository in order to have a reference at the moment of translating the values. Since the comparison of content is not part of the GitHub pipeline, the recommendation is still to use the command periodically in order to keep it updated.

cc. @llfinch, @Zasa-san, @nwyu