Translations and handling of deprecated keys

[surli]

Hi everyone,

@MichaelHamann recently had a question related to deprecated translation keys and made me realize that we had this comment in our translation files :

Deprecated

Note: each element should be removed when the last branch using it is no longer supported

However, to my knowledge we never perform such clean up: for example the translations of oldcore still contain a full section of translation keys “until 2.3”.

On my side I thought we wanted to keep the deprecated translation keys, in case of usage in extensions but apparently we have a rule for that too. In https://dev.xwiki.org/xwiki/bin/view/Community/L10N/Conventions/#HOthergeneralrules we say:

Even if a string looks identical in two different places, do not reuse the same key; […] In general, a section should only use translation keys that identify that section, and not keys from a different section, or worse, keys from a different application.

This actually raises other question regarding the consistency of the translations for common words, but that’s a discussion for another proposal probably.

Finally note that we now handle the translations per branch directly through Weblate, without needing to backport the translations when performing a release.

So given all those elements, I wanted to propose the following:

1. Change the rule regarding deprecated translation to only keep them during a cycle: the idea is to not loose translation right away if we want to revert a change for example.
2. Perform clean up of all deprecated translation keys (provided that they’re not used anymore of course) in our existing files to only keep deprecated keys of current cycle

wdyt?

[vmassol]

@surli

Change the rule regarding deprecated translation to only keep them during a cycle: the idea is to not loose translation right away if we want to revert a change for example.

I think it would be safer to keep for 2 cycles at least (current cycle + past cycle), i.e. 17.x and 18.x. We don’t want to break users too fast.

@surli

On my side I thought we wanted to keep the deprecated translation keys, in case of usage in extensions but apparently we have a rule for that too. In https://dev.xwiki.org/xwiki/bin/view/Community/L10N/Conventions/#HOthergeneralrules we say:

Even if a string looks identical in two different places, do not reuse the same key; […] In general, a section should only use translation keys that identify that section, and not keys from a different section, or worse, keys from a different application.

It’s not just that. Users can use the translation keys in wiki pages, scripts, etc. It’s not great to remove them too fast. Hence the 2 cycles which is already pretty fast IMO compared to java api for ex that we keep forever. Also it’s not because that rule is written that extension developers follow it. So I don’t think it harm us to keep the deprecated keys a bit longer. Compared to now it would already be a progress

@surli

Perform clean up of all deprecated translation keys (provided that they’re not used anymore of course) in our existing files to only keep deprecated keys of current cycle

+1 for clean up, following the keep rule we’ll decide.

Thanks

[vmassol]

Actually I’m wondering if we shouldn’t keep them forever like we do for java code in legacy. It shouldn’t be hard to have a legacy application properties file for ex. That would ensure we don’t break anyone.