Translations frequently broken

(Camille Roux) #1


I manage 2 forums using Discourse. I’m always afraid of doing an update because it breaks frequently some existing and important translation. Here is an an exemple with the last beta:

Could you test this kind of cases? Have we to wait stable versions if we don’t use English?

(Marcin Rataj) #2

I had similar issue with pl_PL and used discourse-locale-override plugin with custom .yml file with missing translation keys (as a quick fix until translation is fixed upstream in next week’s beta release).

(Jeff Atwood) #3

We update / improve the English copy a fair bit in various areas in each release. It’s just something that takes time, I guess?

(eiklid) #4

Is it possible for the forum to use the English text when a translation is not found? Your continued improvement of the language on the site helps a lot with getting the correct translation, but I’m getting nervous each time there’s an update.

What about always pulling a new translation the day after an update. That gives the forums with a different language than English time to fix the front end issues after an update. Right now I’ve been waiting for more than a week to fix the text described above.

(Sam Saffron) #5

Yes, we plan to enable this but it requires some internal changes.

I think it is reasonable to do a final translation pull just before tagging a release. @neil / @techAPJ can we automate this … perhaps a bin/rake release task that takes care of all the magic, pulling translations, tagging release, pushing … etc.

(Neil Lalonde) #6

We always do this.

We found that we need to review what we’re getting from the translations pull. For example, the Romanian translations were (are?) being wiped out by what we’re getting from Transifex, so we’ve been rejecting those files manually. Also we run all tests, look at the site in another language, etc.

Instead of building that fancy feature, I think we’d rather be able to release versions with complete translations. There are two problems:

  • we’re changing english strings too close to a release, not giving translators enough time to translate them
  • translations are not 100% complete, even for old strings

Regression in translation
(Jeff Atwood) #7

Well, I am not going to stop editing copy for translations, at any time… we can’t be blocked by translators. Sorry.

(Eric Vantillard) #8

I am coming from topic regression in translation :

The problem is on renaming keys not on introducing new translations.

what about some upgrade translation button in the admin/upgrade tool ?

(Eric Vantillard) #9

In the present case the problem is that the keys in question are not present in transifex.

(Eric Vantillard) #10

Can we poll on META on the users using the translated versions versus users using it in EN ?

Maybe we are legions :smile: ?

(Rafael Pereira) #11

I believe the problem here is not having a fallback. I don’t think the translation team will ever be able to be in pair with the coding team and it’s pretty much expected. But to not have a fallback for the keys in, at least, English, make the website unusable.

For the user, a button changing from “Reply” to something bizarre like “pt_BR.Some_Button” will make the user never click on that or even know what that does. Having a fallback to English would be a good change since it’s something the other systems already have and don’t let users hanging for so long. Since it’s in Discourse goal to be the next gen forum system, I believe this should be taken more serious. I’m willing to help.

(Gerhard Schlager) #12

@techAPJ Would it be possible to change your workflow of updating the translations a little bit?

It looks like you’re currently always uploading the English translation files to Transifex before you download all other languages. This leads to untranslated strings for all those languages when something got updated in the English translation.

If you could download the translations before uploading the current English translation this could be avoided. IMHO it’s better to have some translated strings that are not up-to-date than have untranslated ones.

(Jeff Atwood) #13

Good idea! The downside is that people wouldn’t necessarily know the translations were not up to date, would they? Or does Transifex appropriately flag those as changed?

(Gerhard Schlager) #14

They appear as untranslated in Transifex. That’s why they always get removed in the current workflow of updating the translations.

(Kane York) #15

I think they would get flagged as changed after the push - which is after the current ones have been pulled. So the translations would lag one version behind.

(Gerhard Schlager) #16

It’s better to lag behind than to have untranslated strings until the next pull.

(Benjol) #17

The problem I’m seeing is that the key [fr.topic.create] is showing in the UI, but it’s not even there to be able to translate in Transifex. What could this be a symptom of?

(Régis Hanol) #18

Transifex UI isn’t the best, but here’s how to find that key :wink:

NOTE: there are 2 results, because the other key is “topic.create_long”.

(Benjol) #19

But that’s [js.topic.create], is that the same thing? And the last translation was done two months ago anyway.

Something I’m not understanding here :frowning:

(Kane York) #20

The translations that are given to the client are prefixed with js., so yes, it is the same thing. The prefix is removed on the client.