Bad MF translation string in hebrew client locale causes fatal site error

I would enter the container, install vim and repair the locale.
You could save the broken hebrew locale and copy the english one over it โ€ฆ

root@carrie-app:/var/www# for i in `find . -name *.he.yml` ; do cp ${i/he.yml/en.yml} $i ; done

Cute idea, but it didnโ€™t work in practice. when I switched my locale to HE again, I get the error. I guess Iโ€™ll go back to iterating the users to set them all to english for now.

Did you restart discourse after modifying locales?

yup. didnโ€™t do much.

after flexing my old ruby skills I just switched everyone to english for now. I will open a ticket about the hebrew locale next.

thanks @JammyDodger for the move to bug, is this all it takes to open a bug report, or should I open an official one in some bug tracker?

If an en-locale is copied, there is an error during merge (it seems, that non translated entries are removed and if nothing is left, then there is an error).

However, removing config/locales/client.he.yml allows login in my test site.

Because it falls back entirely on EN. I think thatโ€™s the expected behaviour.

In the Hebrew locale config/locales/client.he.yml

    posts_likes_MF: |
      { count, plural,
          one {ืชื’ื•ื‘ื”,}
          two {ืฉืชื™ ืชื’ื•ื‘ื•ืช,}
          many {# ืชื’ื•ื‘ื•ืช,}
        other {# ืชื’ื•ื‘ื•ืช,}
      }{ ratio, select,
          low { ื™ื—ืก ื’ื‘ื•ื” ื‘ื™ืŸ ืคื•ืกื˜ื™ื ืœืœื™ื™ืงื™ื,}
          med { ื™ื—ืก ื’ื‘ื•ื” ืžืื•ื“ ื‘ื™ืŸ ืคื•ืกื˜ื™ื ืœืœื™ื™ืงื™ื,}
         high { ื™ื—ืก ื’ื‘ื•ื” ื‘ืžื™ื•ื—ื“ ื‘ื™ืŸ ืคื•ืกื˜ื™ื ืœืœื™ื™ืงื™ื,}
        other {}
      } ืงืคื™ืฆื” ืœืคื•ืกื˜ ื”ืจืืฉื•ืŸ ืื• ื”ืื—ืจื•ืŸโ€ฆ

the line

          many {# ืชื’ื•ื‘ื•ืช,}

has to be deleted.

many is not allowed in Hebrew (see Language Plural Rules)

The issue can be resolved through the user interface. To accomplish this, the corrected value should be entered in /admin/customize/site_texts/js.posts_likes_MF for the Hebrew language:

{ count, plural,
    one {ืชื’ื•ื‘ื”,}
    two {ืฉืชื™ ืชื’ื•ื‘ื•ืช,}
   other {# ืชื’ื•ื‘ื•ืช,}
}{ ratio, select,
    low { ื™ื—ืก ื’ื‘ื•ื” ื‘ื™ืŸ ืคื•ืกื˜ื™ื ืœืœื™ื™ืงื™ื,}
    med { ื™ื—ืก ื’ื‘ื•ื” ืžืื•ื“ ื‘ื™ืŸ ืคื•ืกื˜ื™ื ืœืœื™ื™ืงื™ื,}
   high { ื™ื—ืก ื’ื‘ื•ื” ื‘ืžื™ื•ื—ื“ ื‘ื™ืŸ ืคื•ืกื˜ื™ื ืœืœื™ื™ืงื™ื,}
  other {}
} ืงืคื™ืฆื” ืœืคื•ืกื˜ ื”ืจืืฉื•ืŸ ืื• ื”ืื—ืจื•ืŸโ€ฆ

It feels a little bit strange that the whole site can be rendered unusable by entering wrong data into a text customization.

2 Likes

Logging it here is the place for bug reports. :+1:

2 Likes

Iโ€™ll go in with git to see whoโ€™s to blame for that line, I thought the only party allowed commit changes to those is crowdin?
Also, if that is the case, why would restarting the unicorn after copying english over hebrew would not fix this?

There really should be a distinction between not allowed and unsupported.

Oddly, in the Discourse code, even the โ€œplural twoโ€ is not supported for either language code, which IS shared with Arabic. I think this is where the problem need ti be fixed. Iโ€™ll make a PR for that, but there is definitely a need to fix the hard fail on the โ€œsuperfluousโ€ many field, as it seems Crowdin doesnโ€™t conform to this plurals.rb file.

I think its more complicated.
The front-end translations are interpreted by the node module @messageformat/core using messageformat-wrapper.

The problem is that the plural rules are defined in two places. The other one was recently changed to use a library (DEV: Upgrade the MessageFormat library (JS) ยท discourse/discourse@301713e ยท GitHub).

However, the plurals defined in the library are not always the same as the ones Discourse used before, and the ones in plurals.rb werenโ€™t changed. Inconsistency in plural definition

But that does not explain why Crowdin created a separate version for many

2 Likes

I added the needed field rules for the translation, but thatโ€™s not a solution for this bug, just a compatibility for the Crowdin output.

I think the rule at the end of the line needs an adjustment too.
At the moment, this still only mentions โ€œoneโ€ and โ€œotherโ€.
rule: lambda { |n| n == 1 ? :one : :other }

yeah, I screwed up. I fixed it with amend and missed the fact I pushed it without --force. itโ€™s corrected now.

Thanks all, letโ€™s continue tracking the wider issue in this topic:

2 Likes