Live data from Hacker News

MessageFormat: Unicode standard for localizable message strings

github.com

21–30 of 68 posts

Re: MessageFormat: Unicode standard for localizable message strings

#21
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

Same here (linked to a test because I don’t have a (meaningful) readme…)

That being said your project looks very cool!

https://github.com/Frizlab/XibLoc/blob/e85a5179bdd93e0174731...

Re: MessageFormat: Unicode standard for localizable message strings

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

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.

Re: MessageFormat: Unicode standard for localizable message strings

#24
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…

[deleted]

Re: MessageFormat: Unicode standard for localizable message strings

#25
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…

This post shows a lot of the challenges with localisation, that many seemingly simple tools don't have an answer to: https://hacks.mozilla.org/2019/04/fluent-1-0-a-localization-...

(Fluent informed much of the design of MessageFormat 2.)

Re: MessageFormat: Unicode standard for localizable message strings

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

Yes, Fluent informed much of the design of MessageFormat. See this FOSDEM talk: https://archive.fosdem.org/2023/schedule/event/mozilla_intme...

Re: MessageFormat: Unicode standard for localizable message strings

#27
post #25
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…

This post shows a lot of the challenges with localisation, that many seemingly simple tools don't have an answer to: https://hacks.mozilla.org/2019/04/fluent-1-0-a-localization-... (Fluent informed much of the design of MessageFormat 2.)

Indeed, if only it were as simple as “{n} rows”.

I18n / l10n is full of things like this, important details that couldn’t be more boring or fiddly to implement.

Re: MessageFormat: Unicode standard for localizable message strings

#28
post #9
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.

The standard is, for better or worse, gettext; it's good enough that any attempt to replace it runs into the problem that people can't agree on how much better an alternative needs to be to be worth migrating to; so you get a constant churn that so far hasn't seen any clear winner.

Re: MessageFormat: Unicode standard for localizable message strings

#29
post #19
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…

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 pliki
    Masz 25-31 pliko'w
Your Polish translators would write:

    Masz {file_count, plural,
       one {# plik}
       few {# pliki}
       other {# pliko'w}
    }
The library (and your translators) know that in Polish, the `few` variant kicks in when `i%10 = 2..4 && i%100 != 12..14`, etc. I think the library just knows these rules for each language as part of the standard. Mozilla says that it was an explicit design goal to put "variant selection logic in the hands of localizers rather than developers"

The point is that it's supported, it simplifies developer logic, and your translators know how to work with it.

See https://www.unicode.org/cldr/charts/48/supplemental/language...

(Apologies if I got the above translation strings wrong, I don't speak Polish. Just working from the GNU gettext example.)

Post reply on HN