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

31–40 of 68 posts

Re: MessageFormat: Unicode standard for localizable message strings

#31

Post by npodbielski »

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…

usually it is ó instead of o' but otherwise very good :)

Re: MessageFormat: Unicode standard for localizable message strings

#32

Post by Sharlin »

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

Yeah, some sort of pluralization support is pretty much the second most important feature in any message localization tool, right after the ability to substitute externally-defined strings in the first place. Even in a monolingual application, spamming plural formatting logic in application code isn't exactly the best practice.

Re: MessageFormat: Unicode standard for localizable message strings

#34

Post by Vinnl »

xeeeeeeeeeeenu wrote: post #22
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.

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/

Re: MessageFormat: Unicode standard for localizable message strings

#35

Post by chokma »

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…

This reminds me of https://perldoc.perl.org/Locale::Maketext::TPJ13

Seems like to get it right for every use case / language, you would need functions to translate phrases - so switch statements may be a valid solution. The number of text elements needed for pagination, CRUD operations and similiar UI elements should be finite :)

Re: MessageFormat: Unicode standard for localizable message strings

#36

Post by Vinnl »

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.

IIRC, the goal was for Fluent to have a convertor or something to be able to work with MessageFormat 2.0, but I don't quite remember where I heard that. My approach has just been to stick to Fluent for now.

Re: MessageFormat: Unicode standard for localizable message strings

#38

Post by Joker_vD »

draw_down wrote: post #27
Vinnl wrote: post #25

Earlier quoted context omitted.

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.

Which is why Windows UI is littered with language like "number of rows: {n}".

Re: MessageFormat: Unicode standard for localizable message strings

#39

Post by iririririr »

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…

that's a lazy feature. dealing with this on the front end is the right thing so you can have rich empty states anyway.

Re: MessageFormat: Unicode standard for localizable message strings

#40

Post by Gabrys1 »

Joker_vD wrote: post #38
draw_down wrote: post #27

Earlier quoted context omitted.

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.

Which is why Windows UI is littered with language like "number of rows: {n}".

Makes it easier to parse by automatic tools too
Post reply on HN