Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MessageFormat: Unicode standard for localizable message strings

github.com

Post reply on HN
Print view View original

41–50 of 68 posts

Re: MessageFormat: Unicode standard for localizable message strings

#41

Post by yorwba »

gcr wrote: post #29
Muromec wrote: post #19

Earlier quoted context omitted.

I checked the spec and don't get that really. Something should specify the formula for choosing the correct form (ie 1 for 21 in Slavic languages) and the format isnt any better compared to the gettext of 30 years ago

This confused me too but the formula and rules for variants are specified by the configured language out-of-band, so there is support for this. Let's take your example. In English, counting files looks like this: You have {file_count, plural, =0 {no files} one {1 file} other {# files} } In Polish, there are several possible variants depending on the count: Masz 1 plik Masz 2,3,4 pliki Masz 5-21 pliko'w Masz 22-24 pli…

"the library just knows these rules for each language as part of the standard" sounds great until you try to support a small minority language that the library just doesn't know about and then you're left trying to hack around it by pretending that it's actually a regional variety of another language with similar plural rules.

AFAIK, unlike gettext, MessageFormat doesn't allow you to specify a formula for the plural forms as part of the localization data, so the variant selection logic ended up in the hands of library developers rather than localizers or application developers.

And the standard does get updated occasionally, which can also lead to bugs with localization data written against another version of the standard: https://github.com/cakephp/cakephp/issues/18740

Re: MessageFormat: Unicode standard for localizable message strings

#42

Post by iririririr »

pferde wrote: post #18
jp1016 wrote: post #11

One practical thing I appreciated about MessageFormat is how it eliminates a bunch of conditional UI logic. I used to write switch/if blocks for: • 0 rows → “No results” • 1 row → “1 result” • n rows → “{n} results” Which seems trivial in English, but gets messy once you support languages with multiple plural categories. I wasn’t really aware of how nuanced plural rules are until I dug into ICU. The syntax looked int…

Did not gettext have this for decades? https://www.gnu.org/software/gettext/manual/html_node/Plural...

gettext have everything, plus a huge ecosystem like tools to coordinate collaboration from thousand of contributors etc.

if alternatives don't start with a very strong case why gettext wasn't a good option, it's already a good indicator of not-invented-here syndrome.

Re: MessageFormat: Unicode standard for localizable message strings

#43

Post by Cthulhu_ »

xnorswap wrote: post #9
1116574 wrote: post #7

Looks alot like mozilla's project fluent, atleast in the basic use case. https://projectfluent.org/ I wonder why it hasn't been adopted more widely.

I often wonder this myself, this really should be a standard by now.

Feels like it's That XKCD page; there were standards like gettext, then web development came along and a load of people (...present company included) rediscovered localization and pluralization through trial, error, half-building one's own localization library, then the JS world reinvented it, etc etc etc.

Re: MessageFormat: Unicode standard for localizable message strings

#44

Post by Cthulhu_ »

revetkn wrote: post #17

My project Lokalized attempts to solve many of these complex plural/gender/ordinal/etc. rules with a tiny expression language: https://lokalized.com

Are there any formal test suites to check and compare the various localization libraries with each other? There's a lot of languages and language specific rules and exceptions to consider, after all.

Re: MessageFormat: Unicode standard for localizable message strings

#45

Post by Cthulhu_ »

BoppreH wrote: post #3

The meeting notes in the repo was a nice surprise. Overall looked great, striking a good balance. .input {$var :number maximumFractionDigits=0} .local $var2 = {$var :number maximumFractionDigits=2} .match $var2 0 {{The selector can apply a different function to {$var} for the purposes of selection}} * {{A placeholder in a pattern can apply a different function to {$var :number maximumFractionDigits=3}}} Oof, that's a…

It looks more like a DSL than configuration, but then given what I've learned about localization that's probably necessary in some cases!

However, ideally / in most cases it isn't.

Re: MessageFormat: Unicode standard for localizable message strings

#46

Post by Cthulhu_ »

alexchamberlain wrote: post #33

Apologies if this is obvious and I missed it. Does this define a way to store the strings in various languages?

I think this is just the format and specification itself, language selection and file storage and the like will depend on an implementing library. The i18next version for example (bizarrely) puts the whole string in a JSON key, but to be honest I think this is a bad example: https://github.com/i18next/i18next-icu?tab=readme-ov-file#mo...

Re: MessageFormat: Unicode standard for localizable message strings

#47

Post by Cthulhu_ »

junon wrote: post #6
rocqua wrote: post #2

This seems great in concept, and totally infeasible. But if anyone can do it, unicode seems like a great candidate. Does anyone have reason for more optimism?

Unicode consortium already manages a ton of language specs. If there's any group of folks I'd trust to understand languages (natural or otherwise), it's them.

This is the one. Think of all the "misconceptions developer have about X" lists, I trust Unicode to have encountered (if not written) all of them. The people behind unicode are thorough.

I mean they have hieroglyphs, some of which have plurals: https://www.unicode.org/charts/nameslist/n_13000.html

Re: MessageFormat: Unicode standard for localizable message strings

#48

Post by moltonel »

iririririr wrote: post #42
pferde wrote: post #18

Earlier quoted context omitted.

Did not gettext have this for decades? https://www.gnu.org/software/gettext/manual/html_node/Plural...

gettext have everything, plus a huge ecosystem like tools to coordinate collaboration from thousand of contributors etc. if alternatives don't start with a very strong case why gettext wasn't a good option, it's already a good indicator of not-invented-here syndrome.

It's not hard to make a case against gettext, despite its maturity and large ecosystem.

IMHO pluralization is a prime example, with an API that only cleanly handles the English case, requires the developer to be aware of translation gotchas, and honnestly confusing documentation and format. Compare that to MessageFormat's pluralization example (https://github.com/unicode-org/message-format-wg/blob/main/s...) which is very easy to understand and fully in the translator's hands.

Re: MessageFormat: Unicode standard for localizable message strings

#50

Post by vsl »

moltonel wrote: post #48
iririririr wrote: post #42

Earlier quoted context omitted.

gettext have everything, plus a huge ecosystem like tools to coordinate collaboration from thousand of contributors etc. if alternatives don't start with a very strong case why gettext wasn't a good option, it's already a good indicator of not-invented-here syndrome.

It's not hard to make a case against gettext, despite its maturity and large ecosystem. IMHO pluralization is a prime example, with an API that only cleanly handles the English case, requires the developer to be aware of translation gotchas, and honnestly confusing documentation and format. Compare that to MessageFormat's pluralization example ( https://github.com/unicode-org/message-format-wg/blob/main/s... ) which…

> IMHO pluralization is a prime example, with an API that only cleanly handles the English case

That’s not true at all? Gettext is functionally limited to source code being English (or alike). It handles all translation languages just fine, and competently so.

What is doesn’t have is MessageFormat’s gender selectors (useful) or formatting (arguably not really, strays from translations to locales and is better solvable with placeholders and locale-aware formatting code).

> fully in the translator's hands.

That is a problem that gettext doesn’t suffer from. You can’t reasonably expect translators to write correct DSL expressions.

Post reply on HN