Text available for translation is out of sync with source code

[victorlin]

Text available for translation can be defined by all translation entries in src/locales/en, and the diff-lang npm script is based on this concept. However, the contents of src/locales/en are out of sync with what's actually translatable, which is defined as all English strings that are passed through react-i18next's t() function.

Generally, I'd like to propose that all English text in the interface is passed through t() and has an entry in src/locales/en, which should have no unused entries.

These are 4 problem scenarios in the current code. I've added examples and specific actions based on the above proposal.

1. Text is translated, but the English text is no longer in the source code.

   Examples: using data from, Num mutations, Branch leading to

   Action: update/remove these. Some are the result of the English text being reworded. In trivial cases such as Branch leading to which changed to Branch leading to {{tipLabel}}, the existing translations can still be used by doing a replacement similar to this find/replace. In other cases, a new entry should be added per (3) or (4), or if there is no longer any corresponding English text, the entry should be removed.

2. Text is translated, but the English text is not passed through t().

   Example: Diversity

   Action: update the code to pass the English text through t() so that these translations are used.

3. The English text is passed through t(), but text is not available for translation.

   Example: Clear {{filterName}} filter

   Action: add entries to src/locales/en.

4. The English text is not passed through t() and text is not available for translation.

   Examples: Focus on selected, Jan/Feb/Mar/…

   Action: (2) + (3): update the code to pass the English text through t(), and add entries to src/locales/en.

I manually searched to find these, and my guess is there are more instances of each. It would be good to write a script to find these more easily and check regularly, as we are frequently updating English text in the interface.

[victorlin]

(noticed these while reviewing #1959)

[tsibley]

add entries to src/locales/en and all other languages with English placeholder.

I would not add English placeholders to non-English locale catalogs, as it obscures what's translated and what's not for those locales. Instead, t() should be configured (maybe it's not already?) to automatically fall back to the English translation catalog when an entry is missing in the current locale's catalog. Then it's possible to easily diff between the keys in the English catalog with keys in other catalogs to see what's needed.

[victorlin]

Instead, t() should be configured (maybe it's not already?) to automatically fall back to the English translation catalog when an entry is missing in the current locale's catalog.

Yes, it's already configured to fall back to English translation – this is scenario 2 in the list above.

Then it's possible to easily diff between the keys in the English catalog with keys in other catalogs to see what's needed.

I proposed adding English placeholders since the output of diff-lang shows:

        Following keys are identical to the English version & may need to be translated:
                "Built with"

but you're right, the output with missing entries is more clear:

        Following keys need to be added:
                "Built with"

Removed the part on adding English placeholders from my proposals.

[tsibley]

Yes, it's already configured to fall back to English translation – this is scenario 2 in the list above.

Ah ok. I guess I misunderstood (2) then? I read "Text is translated, but the English text is not passed through t()" as "there's a "foo" key in our catalogs, but the code writes "foo" instead of t("foo")".

[victorlin]

Oh, you're right, I dunno what I was thinking with the reference to scenario 2. But I did check by removing a translation entry and it falls back to English.

[victorlin]

I spent my afternoon starting the work to address this programmatically in #1987. Needs some more work to bring everything back in sync.