I just noticed that we currently have the following mention in our translations files before the #@deprecatedstart mention:
###############################################################################
## Deprecated
## Note: each element should be removed when the last branch using it is no longer supported
###############################################################################
But, to my knowledge, we never performed such removal and on the contrary we tend to consider the translation keys as APIs as they might be used in other extensions (in particular the core translations).
So I’m not entirely sure how we want to handle that, especially since now we have properly separated translations files per branch so we don’t copy anymore translations keys from branch to branch when performing a release.
I see the following possible options:
we keep our current practice to never remove any translations, and we remove that comment from our translations files
we change our practice, and we decide that translations keys are not APIs and shouldn’t be used by extensions, and we start deleting the deprecated ones, but then we can do independently in each branch (we should probably check that they are indeed not used before doing so)
Knowing that we could also do 2 only for all modules except oldcore.
Personally I’d be +1 for 1 and -0 for 2 as I feel like it’s creating more work and possible problems, and the only benefit I’m seeing is that it avoids having translation files continuously growing, but I’m not sure it’s really an issue currently.
I definitely think option 2. everywhere should be avoided.
AFAIK extra translations don’t impact much performance and end up messing up the UX a lot when missing. The balance between performance and backwards compatibility goes really in favor of keeping them compared to most other resources in XWiki (e.g. templates and styles).
Option 1 works well right now because it’s relatively recent that we mark deprecated translations and we still have a high ratio of (used translations)/(used and deprecated translations).
+1 for option 1. It seems we agree that Never is relative and it could still become necessary in a long time.
Thank you for making this clear!
Lucas C.
Sidenote: Do we have a ticket for the task of checking the uses of oldcore translations and sorting the ones that are not used in XS anymore? There’s 5000 lines and I believe the amount of unmarked deprecated translations is far from negligible. E.g. blog translations that are still here despite the blog App being migrated out from XS around version 9.
When deleting a key, it should be moved to the deprecated section at the end of the file, linked to the first version in which it started to be deprecated
But maybe you just mean that the documentation does not mention deleting translations ?
In any case, while this process was initially designed only to avoid removing translations that may still be in use in a supported branch (since translation files were updated during releases with what was on the server), it’s true that we actually never removed any deprecated key in practice.
This is probably the safest, even if it’s annoying for the translators to have so much useless work (since there is no difference in weblate between deprecated and active keys).
There is another problem with this but could be maybe solved another way: each new branch creates new translations. Normally they should be propagated but every time there are a lot of translations that are not completely propagated. Those keys are all “empty” and a lot of them are deprecated. Those keys are always missing to 100 % full translation. Those keys have to be labeled “read-only” on every new branch manually to fulfill 100 %.
+1 for option 1 as it is the safest.
The main point to tackle for me is to prevent the infinite growth of the translation files in “non-legacy” modules.
(brainstorming) One option could be to created a legacy translation module, with a single large translation file.
All the translations that are deprecated and out of LTS would be moved there.
This module wouldn’t be loaded in weblate.
That way, deprecated translations wouldn’t be proposed to translators gradually.
I’m not against applying to translation the same legacy logic we apply to java code, but it’s not clear to me why translations would all be put in the same file (where ?) and not per module, like Java code.
We could go that way too, but since we consider translations to have a global scope, I’m not sure if it’s interesting to dispatch them in numerous legacy modules.
If adding legacy modules was easy, it could be fine, but we know that adding legacy modules cleanly to the distributions can be a pain. Devs will never do the work of moving translations to legacy if that’s too much work.
Adding legacy module with aspects is a pain, a simple legacy module not so much.
I understand why you would prefer a single file, but I’m not a huge fan of mixing completely different things in a single big file, which would make it harder to move stuff to contrib, for example, etc.
Well I tend to agree with Manuel on this one: having to add a legacy module, even without aspect, just to move deprecated translations might quickly become tedious, and I’m not sure it brings much benefits.
There is also a performance aspect. I’ve seen that we’re more and more seeing the limits of our current translation handling code that does a lookup in every registered translation bundle until it finds the translation. The size of the translation bundles doesn’t matter much as we have a hash map for every translation bundle, but the number of translation bundles contributes linearly to the running time of translation lookups. So doubling the number of translation bundles would double the running time of translation lookups. Currently, translation lookups (without rendering) are around 4% of the CPU time of a page load (like Sandbox) on my system with a Jetty demo distribution. This means that if we introduced a legacy module for every translation bundle, page loads could be 4% slower.
We should probably do something about that, with some kind of cache or lookup table to more quickly find the translation bundle that contains in particular frequently used keys, but it depends on when we’ll find the time for that.
