Translation restructuring on crowdin for new-versioning-strategy

Dev Translations
1

I noticed that the file structure was recently changed on Crowdin. I’m a little confused now; it feels like, especially after not translating for a few weeks, there is much more work to be done than necessary.

Before, if a text was added and I introduced pluralization for it in a PR, I only needed to translate the new version. Now I also end up translating texts from the prior release. This means that because the plural was missing in December, I now see that text alongside the new one with pluralization. I also don’t see any visual indicator showing that it makes more sense to translate

image
image966×284 19.9 KB

than
image
image974×221 13.6 KB

or that I should focus on translating

image
image975×402 20.9 KB

instead of
image
image975×261 13.8 KB

It might be obvious when you see them next to each other, but there are currently more than 300 untranslated texts, so checking each time whether there is a similar newer one probably takes more time than translating the ones that are no longer needed.

But actually, since there is so much to translate, I would like to focus on the texts that are used in the latest version of Discourse first. For me, those matter more. It’s less likely that admins using the last release will update before a new release is available, so I would like the next release to be as complete as possible.

But it feels like this has become more difficult. If I remember correctly, previously almost all texts were in the “main” folder on Crowdin, and only those where the English text had changed were duplicated into the “stable” folder. But I am not sure. Usually, the translation for “stable” was complete when there was a release because the paid proofreaders worked on them then, too. But even if they didn’t, I tried to get the translation as complete as possible when there was a release coming up. It’s more difficult to do that for every release.

Now, however, not everything new is in the “latest” folder, and only those that require a previous version are in “release.” It seems to be exactly the opposite: everything except what was added after the last release is in “release.”

Because of this, to focus on texts that will be part of the next release and to avoid double translations, I can’t simply translate everything in the “latest” folder as was previously possible with “main.”

6 Likes
RFC: A new versioning strategy for Discourse
4

I’ll take a look if we can switch it around during the release again.

4 Likes
5

@moin Now that you’ve had some time to work with it, do you still feel the current Crowdin structure is worse than the old one?

image
image1946×235 11.4 KB

There are 15,162 strings in the release branch and 86 strings in the latest branch. The latest branch builds on top of release, so those 86 strings are ones that were either added or changed since the last release.

From a technical perspective, this structure makes more sense than the previous one. That said, if it creates extra busywork or makes translation more cumbersome for you, please let me know. I’m happy to look for a way to support the new release strategy while keeping things as smooth as possible on Crowdin.

2 Likes
6

Yes. It still feels like I am translating stuff barely anyone will ever see, and it’s very difficult to focus on translating one plugin like ‘chat’ because I can no longer just work on that folder because some texts are in latest/chat and others are in release/chat. Adjusting the filter by first limiting it to only filter by identifier and searching for chat still returns everything for the chat integration plugin in addition to everything for the chat plugin.

There are also other points in this workflow that concern me, but I am unable to write them down in an organized manner at the moment.

2 Likes
7

Thanks for the feedback, I’ll get this sorted.

1 Like
8

How is this expected to work?
You merge security fixes that contain text changes right before a new version is released.

That worked when there was main and stable which were supported and both were available on Crowdin. But it wasn’t possible to translate the latest security fixes for 2025.12 because the release of 2026.1 happened at the same time. In this case, it isn’t that much of a problem because it seems no text was edited, only new ones were added that stay untranslated, since 2025.12 isn’t supported for that long, I think that isn’t an issue. But what if a text would have been edited? Then the existing translations won’t be removed because translations are no longer updated. And while this is probably somehow still not that much of an issue because there aren’t many forums expected to stay that long on 2025.12 after 2026.1 is released, I am worried about how it will work with the ESR.
In summer, we had a broken text for the solution on hosted forums for weeks because the placeholder was changed in the code, but the translations still used the old one because this hadn’t been officially merged, so the text wasn’t changed by Crowdin. I am worried the same will happen with the ESR. It will receive all those security fixes, but after 2026.2 is released, translations won’t be updated. If you change a text in one of these fixes, the translations won’t be updated through Crowdin. So the text containing a placeholder that is no longer provided by core will stay unchanged.

Also, in general, the feeling that translations need to be perfect within the next few weeks because after that I will lose the chance to improve them, doesn’t feel good. Before, it felt like “well, whatever I add will help everyone who updates their Discourse after these are merged, and if I notice something I’d like to improve, they will all receive those improvements;” now this soon excludes everyone using ESR. They won’t receive updates once 2026.2 becomes the release.

Therefore, there are translations for each release which results in texts that were rewritten after a few weeks because the interface was refined, needing translations for both versions. I translate
js.category.visibility.more_options_hint: More permissions available in <a href>advanced settings</a>.
and
js.category.visibility.more_options_hint: More permissions available in js.category.visibility.more_options_hint_link: advanced settings.

In this case, I would assume the latter is the one needed for the ESR, so I guess there will be forums that update after a security fix is merged and actually see these translations. But what if this happened next month? How many forums do you expect to stay on 2026.2 and not just update right after it was published and there are new security fixes which notify the admin but a week or so later when I had time to translate the texts? And how long do they use them until they update to 2026.3? That is what makes me feel that I translate texts barely anyone will see.

It also feels like the translations that were removed from latest last week after the first update of the translations happened since the release of 2026.1 are related to the new process, and I wonder if the same will happen to translations after the next release. And it feels wrong that translations are available for those on 2026.1 but those using latest no longer have them.
These are the translations for Horizon on 2026.1

And this is available on latest

9

Update: I found the indicator

image
image975×402 20.9 KB

I was correct that there is no visible indicator; it’s the lack of “Master” at the top right that hints at the fact that this text is not used by the latest release.

Screenshot_20260210_200917_Chrome
Screenshot_20260210_200917_Chrome1141×589 93.8 KB

So, once I notice there is no “Master” in the top right, I know that the text from the release folder is no longer used in the latest release and can skip it to focus on texts used by all releases first.

1 Like
10

Ah, yeah, that should work. It would be nice to have a filter option for that in the Crowdin editor, but I doubt that’s possible right now. I’ve posted a feature request in Crowdin’s community.

1 Like