Transifex Error with count field



If we translate the sentence when we press “1”, when we go to the “other” option, and we translate that option, what we translate for “1” is updated, leaving a single viable translation, when there should be two different ones.

If you do not understand what I’m trying to explain, at night I’ll do a gif to show you.
I’ve already sent the error to support from transifex.

I opened this discussion to notify about the error.


(Gerhard Schlager) #2

I just tested it and translated something in German. Switching between “1” and “other” works fine for me. So, yeah, contacting Transifex is probably a good idea, if you are still having problems.


Check the gif:

I tried without “raw” mode, but it’s the same :frowning:


News about this:

Hi Sid,
Thank you for providing me with further information on the issue you are experiencing.

We have further investigated, and the issue is related to the source file and how the string is included there.
So, please contact the maintainer of the project and ask them to fix these entries in the source file.

Currently, the strings in the file look like this:


However, these entries should be included in the file as follows:


This is the resource where we found this issue:

Please let us know if there is anything else we can help.

Kind regards,

So… it’s a problem with our files? :crazy_face: :cry:

Can you check it @gerhard ?

(Gerhard Schlager) #6

I don’t see how this could be our fault. The file on GitHub looks fine.

But the translations look wrong when I download the English file from Transifex.

The translations for max_content_reached and min_content_not_reached were split up into one and other a few days ago. Maybe Transifex’s algorithm to detect changes to the YAML file can’t handle that case?

Anyway, I can confirm that it’s not possible to translate those two keys.


I’m going to ask Transifex’s support to read this discussion.


Hi Sid,

Thank you for forwarding it and taking it with Discourse team.

I am looping our technical engineer to chime in and provide you an answer on this matter.

Kind regards,

Flavia Fichmann Gilad
Customer Success Manager | Transifex


New update here:

Hi Sid,

Thank you very much for getting back to us and sharing the answer that Discourse’s team sent you. It helped me to understand the case here and the reason why the system behaves that way.

Please note that some time ago, there was an issue on our end that we were able to fix on newly created resources only. According to this issue, if your YML entry was a non-pluralized string and in an updated version you converted it to a pluralized one (the key was the same), then the parser was confused and as a result, the behavior you reported occurred. So, in order the content to successfully be parsed, Discourse’s team needs to push the file as a new resource to Transifex.

Could you please forward this to them and let me know if they need any further assistance?

We will be more than happy to provide any additional clarifications if needed.

We really appreciate your help and cooperation on this matter.


Nina Eleftheriadou
Customer Success Engineer | Transifex

Can you check this @gerhard ?

(Gerhard Schlager) #9

I’ve contacted the Transifex support and asked what’s the best way to repair the resource. As I see it we will probably lose translation history when I use tx pull and tx push to move the existing translations to a new resource. It’s not the end of the world, but let’s see if they can come up with a better solution.

In the meantime, did you or anyone else notice any other pluralized strings that can’t be translated?


Right now, I finished to update and translate all the changes into transifex

List of keys with problem:


  • js.select_kit.max_content_reached
    Sg: You can only select {{count}} item.
    Pl: You can only select {{count}} items.

  • js.select_kit.min_content_not_reached
    Sg: Select at least {{count}} item.
    Pl: Select at least {{count}} items.


  • groups.success.bulk_add
    Sg: %{count} user have been added to the group.
    Pl: %{count} users have been added to the group.

:exclamation: New idea: With your permission, if you wish, I could directly send PR into github to correct these keys in the Spanish language.

About this:

The history it’s the only the history tab?
If it’s that, I don’t mind it.

(Gerhard Schlager) #11

Unfortunately that’s not possible. Your changes would be overwritten the next time we pull from Transifex.

OK, so server.yml needs to be fixed too. :frowning:

Well, it affects every language, not just Spanish. Sometimes it’s really nice to see the translation history and we’d also lose some data we used to generate topics like Thanks to our 2017 translators!

I’m still waiting for a response from Transifex. I hope they have a better solution that isn’t as destructive as creating a new resource.

(Gerhard Schlager) #12

OK, I tried creating a new resource and pushing the existing translations to the new resource. Unfortunately there seems to be a bug that’s preventing Transifex from accepting translations for Spanish (Latin America).

Pushing ‘es_419’ translations (file: config/locales/client.es_419.yml)
Exception: Could not import file: No language code has been specified in the YAML file

I reported it to Transifex’s support and also asked if there’s at least an easy way to transfer the review state for translations.

Anyway, I don’t like how a bug in Transifex will be causing so much pain to translators and reviewers. I guess the easiest solution would be to rename the problematic keys. And we need to do the same everytime we convert a normal string into a pluralized string.

(Régis Hanol) #13

If we go that way, it’s got to be automated. Otherwise, pretty sure it will happen again.

(Gerhard Schlager) #14

That’s quite hard to prevent. And even if we create new resources for core/client.yml and core/server.yml, there are still 46 other resources that potentially have the same problem. Well, maybe less if the bug was already fixed in version 2 of their YAML handler. I’m not sure about that (yet).


Mmm thinking… :thinking:
If… you ignore that language (right now I’m putting all my efforts on Spanish es translations, not es_419), the fix will applies to es language?

(Gerhard Schlager) #16

I don’t want to do the work two times, so I’m waiting for Transifex to fix the bug in their YAML parser.

Also, I got a response from support and it looks like we could potentially run into the same issue with most of our resources on Transifex. The bug that prevents detection of strings converted into pluralized strings was fixed in the YAML handler version 3 and most of our resources are still on version 1 and 2, so I guess it’s best to swallow the pill, update all of them and be done with it.


Right now, a new key it was translated just fine, and is with “count” field :neutral_face:

  • Client.yml: admin_js.admin.flags.delete_replies

But, still with problems with:

  • Client.yml: js.select_kit.max_content_reached
  • Client.yml: js.select_kit.min_content_not_reached
  • Server.yml: groups.success.bulk_add

(Gerhard Schlager) #18

OK, I’ve replaced the old resources for core/client.yml and core/server.yml with new ones. Everyone should be able to translate those strings again. Unfortunately we lost the review state for those two files for every language.


It’s working right now! :tada: :star2:

Thanks @gerhard !

All Spanish translations were reviewed now. :+1:

(Neil Lalonde) #20

Unfortunately the Transifex “rails i18n yml” format affects how we update translations. Transifex is returning empty strings for all untranslated strings. For example updating today:

+    topic_count_unread:
+      one: ''
+      other: ''
+    topic_count_new:
+      one: ''
+      other: ''
     preview: "Anteprima"
     cancel: "annulla"
     save: "Salva modifiche"
     saving: "Salvataggio..."
     saved: "Salvato!"
     upload: "Carica"
     uploading: "In caricamento..."
     uploading_filename: "Sto caricando {{filename}}..."
     uploaded: "Caricato!"
+    pasting: ""
     enable: "Attiva"
     disable: "Disattiva"
+    continue: ""
     undo: "Annulla"

Our fallback to English doesn’t work in this case, so those empty strings will be rendered as the Italian translation. :confused:

EDIT: same problem with the “yaml generic” option.

(Gerhard Schlager) #21

Hmm, the tx client should only pull translated strings. Let me look into this. I’ll contact Transifex.