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.
@JammyDodger 님, Contribute > Bug 채널로 옮겨 주셔서 감사합니다. 버그 리포트를 열려면 이것만으로 충분한 건가요, 아니면 별도의 버그 트래커에서 공식적인 리포트를 여야 하나요?
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개의 좋아요
여기에 기록하는 것이 버그 리포트 작성의 적절한 곳입니다. 
2개의 좋아요
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개의 좋아요
https://github.com/discourse/discourse/pull/28011
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개의 좋아요