Hi, there is more and more English strings untranslated in French in the French Discourse installation, do you know why ? Thanks.
Hi Patrick
I would imagine that there is no translation for this yet. If you would like to contribute and translate this yourself learn more about translating here.
2 Likes
Actually, this string, like many other were in French in the previous Discourse release, but not any more since I upgraded to the last.
I run an instance in Brazilian Portuguese and I feel the same. There’s a recent topic about this and I mentioned a suspicion of mine.
https://meta.discourse.org/t/2-7-0-beta4-translation/181023/2?u=renato
I just found an example:
Notice that on Feb 12, 2021 the Bot removed the old translation because the english string had a “these” changed to a “this”.
I think ideally we’d keep old translations if the change isn’t significant, like gettext does. A wrong plural is better than the whole string in English.
I went ahead and looked further about the string on your screenshot, and its key has been renamed because of a code refactory. I assume this is an exception, I guess most missing translation cases that existed previously are caused by a change of the original text.
6 Likes
@gerhard has this option been investigated? I know there are some keys where an old translation can be disastrous (like the email templates) but in general starting off from the old translation may be better than nothing at all. I am not sure… so much nuance here.
4 Likes
Well, lets see, there are multiple cases here:
-
Key of translation changes: We try to avoid that, but sometimes it’s simply not possible. If the English string doesn’t change, we could use Translation Memory to automatically use existing translations. Crowdin has a “TM Pre-translation” workflow step which does exactly that.
Pre-translate files with Translation Memory ™ to speed up the translation of the same or similar strings…
Unfortunately this prevents translators from making any changes to the translation afterwards, because a string translated by Translation Memory can’t go through the “Crowdsource” workflow step. I reported this a long time ago, but it doesn’t look like it’s been fixed yet. That’s why we don’t use “TM Pre-translation” at the moment. cc @Andriy_Crowdin
-
Modified English string: What counts as minor change? That’s a hard decision to make and might even vary for different languages. Let’s take a step back. What happens when we modify an existing string in English?
- We push a modified string to GitHub
- The translator-bot picks it up and pushes it to Crowdin
- This invalidates all translations for that string on Crowdin, but doesn’t affect the translations in Discourse yet
- Every Tuesday we pull the current translations from Crowdin and push them to GitHub.
- Missing translations will be removed
- New translations will be added
So, unless we modified the string right before Tuesday, there should be enough time to provide a new translation on Crowdin. The suggestions on Crowdin usually make it very easy to translate the modified string.
-
Modifications that shouldn’t affect existing translations: We usually try to keep existing translations when we make insignificant bulk changes to English strings. For example, we did that in the past when we changed the
{{count}}placeholder to%{count}or during the rename of the English locale. There are special commands we can add to commit messages:@discourse-translator-bot keep_translations_and_approvals @discourse-translator-bot keep_translations
I’m happy to implement improvements to our workflow if they are feasible. However, there is no concept of a fuzzy translation in Crowdin. It’s either translated or not. And I think that’s a good thing, otherwise it would just overcomplicate things. As a translator you get notified about new and modified strings, so that should help translators in staying on top of things.
@patrickemin I added the missing French translation from Translation Memory. It will be included in today’s update.
5 Likes
I’ve seen somewhere that gettext uses a default threshold of 0.85 when calculating the Jaro distance for measuring similarity. I understand there’s no perfect solution, it was just a suggestion because it’s been hard to follow these changes, I’m not a translator and I help whenever I notice any missing text in my instance, and yet I’m the “top” translator for my language on Crowdin for lack of contribution.
Unfortunately most languages are missing active contributors and I think a week is unlikely to be enough time for a new translation. I try to take a look whenever I get an email from Crowdin, but my language is already missing ~11k words and it’s been hard to keep up.
Pre-translate files with Translation Memory ™ to speed up the translation of the same or similar strings…
It may really improve the workflow if the mentioned fix lands sometime, it also looks like it addresses the fuzzy string scenario.
What happens if the user is customizing the strings locally? Isn’t this already an issue in this case?
Another possible alternative would be to not invalidate by default and have a different workflow when the whole meaning has changed, maybe changing the translation key or having a @discourse-translator-bot invalidate_translations on the commit message, for example, assuming – which may be totally wrong – that changing the meaning for a translation key is an exception.
That all said, Crowdin is really a breeze to work with, none of this would be an issue if more people were contributing to it. I believe many are using the text customization feature as a translation resource.
1 Like
We are aware of that. We might get professional translators to help with some languages in the near future and I think Brazilian is on that list. 
Also, I’m thinking about adding links to Crowdin in the admin UI for “Customize Text” and the default locale setting. That might point some translators from the community in the right direction as well.
Yes, it is.
2 Likes