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

51–60 of 68 posts

Re: MessageFormat: Unicode standard for localizable message strings

#51

Post by Muromec »

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…

>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.

Well, making out of band sure is one way to do to prevent lazy people from doing eval on plural forms from the po file. I hope the library is actually good then.

Re: MessageFormat: Unicode standard for localizable message strings

#52

Post by ddevnyc »

One thing I would really appreciate in this repository (and many like it) would be a simple, short, snippet of code that shows a typical use case of whatever the repo is selling me. Life's too short to dig around in the guts of the repository to find stuff like this out, it should be front and center. I want to know about the ergonomics and hackability of what I'm about to delve into.

Re: MessageFormat: Unicode standard for localizable message strings

#53

Post by moltonel »

vsl wrote: post #50
moltonel wrote: post #48

Earlier quoted context omitted.

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 solvabl…

> Gettext is functionally limited to source code being English (or alike). It handles all translation languages just fine, and competently so.

The *ngettext() family of functions take two strings (typically singular/plural) and rely on a language-wide expression to choose the variant (possibly more than 2 variants). There's no good reason for taking two strings, this should be handled in the language file, even without a DSL. Ngettext handling a single countable makes some corner-cases awkward, like gendering a group with possibly mixed-gender elements. The Plural-Forms expression not being per-message means that for example even in English "none/one/many foo" has to be handled in code, and that a language with only a rare 3rd plural has to pay the complexity for all cases.

Arguably, those are all nitpicks, Gettext is adequate for most projects. But quality translations get cumbersome very quickly.

> You can’t reasonably expect translators to write correct DSL expressions.

This feels demeaning. Translators regularly have to check the source code, and often write templates, they're well able for a DSL like MessageFormat's, especially when it's always the same expressions for their language. It saves a trip to the bugtracker to get developers to massage their code into something translatable. You can't reasonably expect a English-speaking developer armed with ngettext to know (and prepare their code for) the subtleties of Gaelic numerals.

Re: MessageFormat: Unicode standard for localizable message strings

#54

Post by zbraniecki »

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...

No, gettext scales very badly, both vertically (larger systems) and horizontally (locales with rich grammatical forms like declensions etc.)

We (authors of Fluent and collaborators on MessageFormat 2.0) wrote this explainer which you may find informative - https://github.com/projectfluent/fluent/wiki/Fluent-vs-gette...

Re: MessageFormat: Unicode standard for localizable message strings

#55

Post by zbraniecki »

Vinnl wrote: post #34
xeeeeeeeeeeenu wrote: post #22

Earlier quoted context omitted.

Here's a comparison between the two on Fluent's wiki: https://github.com/projectfluent/fluent/wiki/Fluent-and-ICU-... It seems the last edit of the page was in 2019, so I'm not sure how up to date it is.

Yeah it's actually MessageFormat 2 [1] that's very informed by Fluent's design I believe; I think that comparison is to "normal" MessageFormat. [1] https://messageformat.unicode.org/

Correct. MF2.0 addresses all the challenges we identified during design of Fluent.

Re: MessageFormat: Unicode standard for localizable message strings

#56

Post by zbraniecki »

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.

We are targeting MF2.0 for inclusion in JavaEcript stdlib (ECMA-402). And later maybe with its own format into DOM for DOM L10n.

Re: MessageFormat: Unicode standard for localizable message strings

#57

Post by zbraniecki »

strogonoff wrote: post #13

Does anyone know the ETA of MessageFormat 2.0? I am aware of the effort since pre-COVID times. I recall that some of the developers behind Mozilla Fluent have been among the people working on MF 2.0, and it’d be great to know whether Fluent and ICU MF are going to be interoperable in foreseeable future.

Yep. Mozilla is planning an auto converter from Fluent to MF2.0 once we stabilize it.

Re: MessageFormat: Unicode standard for localizable message strings

#58

Post by zbraniecki »

bmn__ wrote: post #5
hobofan wrote: post #4

Earlier quoted context omitted.

Care to explain why you think it's infeasible? Then one could provide targeted counter-optimism ;) I don't see what's infeasible about it. It doesn't seem too different from .po files (gettext catalogs) meshed with hooks for post-processing as would see in e.g. a handlebars, both of which have individually found great adoption.

> why you think it's infeasible? GP based his opinion on the assumption that this spec new and no implementations for it exist.

ICU4C and ICU4J have implementations. We also have a JS polyfill and will be working on ICU4X impl this quarter.

Re: MessageFormat: Unicode standard for localizable message strings

#59

Post by zbraniecki »

bmn__ wrote: post #10

Looking for an expert who knows both libintl/Gettext and MessageFormat. What is the equivalent of xgettext.pl, the file extension for the main catalog file `.po`, the __ function? How does gender work (small example)? How does layering pt_BR on pt_PT work? What is a compelling reason to switch?

https://messageformat.unicode.org/

Lmk if you have further questions!

Re: MessageFormat: Unicode standard for localizable message strings

#60

Post by zbraniecki »

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?

Here is a proposal for a message resource format on top of MF2.0 - https://github.com/eemeli/message-resource-wg
Post reply on HN