zbraniecki
Joined 13 years ago
Karma
1,111
Submissions
167
Member since
Oct 18
Zibi Braniecki, engineer at Mozilla. Working on l10n/i18n stack, ECMA402 and performance.
View on Hacker NewsRecent submissions
Comment · 8 months ago
Definitely the former, apologies for making it confusing.
> What is the equivalent of xgettext.pl
There is no standard one, although people build their own. The general consensus is that source strings should not be inlined into code. The closest analogy is to "style" vs "class" in HTML/CSS - the clean separation of concerns comes from the "id" being the contract.
You can read more about it here: https://github.com/projectfluent/fluent/wiki/Fluent-vs-gette...
There are attempts to "merge" those two philosophies, by extracting and "generating" slugs as ids. Examples: - https://formatjs.github.io/docs/getting-started/message-extr... - https://lingui.dev/guides/message-extraction - https://app.studyraid.com/en/read/15768/550728/setting-up-th...
I'm fairly skeptical of this approach.
> the file extension for the main catalog file `.po`
In MF1.0 world, the file format is JSON or XML. You encode id=>Message pairs. In Fluent world there is a Fluent (FTL) file format. In MF2.0 the format itself is, again, message scoped. On top of it there's a proposal by Mozilla to create MessageResource - https://github.com/w3c/i18n-discuss/blob/gh-pages/explainers... and that may feed into DOM L10n - https://github.com/mozilla/explainers/blob/main/dom-localiza...
> the __ function?
see the (1) and links to "generated ids".
> How does gender work (small example)?
MF 1.0:
``` {GENDER, select, male {He answered} female {She answered} other {They answered} } ```
Fluent: ``` user-answered = { $gender -> [male] He answered. [female] She answered. *[other] They answered. } ```
> How does layering pt_BR on pt_PT work?
MF does not prescribe fallback behavior. It also more popular to treat each locale as "complete" and fill "gaps" at build time. So at runtime you have `pt-BR` which has pt-BR strings and missing ones "completed" from `pt` (parent locale).
Fluent has a "resource manager" (simple one like this: https://github.com/projectfluent/fluent-rs/tree/main/fluent-... or more complex like Mozilla L10nRegistry), which can fallback at runtime, allowing for what we call "partial locales" which can roll out to production with gaps and the resource manager will fetch the fallback strings from the parent locale.
> What is a compelling reason to switch?
If you and your users are happy with gettext, none!
If either of those groups complain, there may be many: - https://github.com/projectfluent/fluent/wiki/Fluent-vs-gette...
Hope that helps!
Comment · 8 months ago
Here is a proposal for a message resource format on top of MF2.0 - https://github.com/eemeli/message-resource-wg
Comment · 8 months ago
https://messageformat.unicode.org/
Lmk if you have further questions!
Comment · 8 months ago
ICU4C and ICU4J have implementations. We also have a JS polyfill and will be working on ICU4X impl this quarter.
Comment · 8 months ago
Yep. Mozilla is planning an auto converter from Fluent to MF2.0 once we stabilize it.
Comment · 8 months ago
We are targeting MF2.0 for inclusion in JavaEcript stdlib (ECMA-402).
And later maybe with its own format into DOM for DOM L10n.
Comment · 8 months ago
Correct. MF2.0 addresses all the challenges we identified during design of Fluent.
Comment · 8 months ago
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...
Comment · 3 years ago
Hi! Thank you for your critique!
> 1) “Your knight has killed a dragon with a crossbow”
We have a proposal for dynamic references to address this problem - https://github.com/projectfluent/fluent/issues/80 - it's non-trivial but I hope we'll see it solved in Fluent and/or in MessageFormat 2.
> 2) The parser is extremely sensitive
True. It's on purpose. We wanted to start with strict and loosen, rather than the opposite.
> 3) The input files mandate a weird arrangement of new lines for even the simplest branching
Same as above.
> 4) The documentation is too Spartan to know what happens in edge cases.
We're a small team :)
> It heralds itself to be the saviour of all i18n, but it’s literally worse than the mess that came before it.
I'm sorry to hear it doesn't work for you. I'm relieved that your criticism is seems more subjective except of one missing feature that no other l10n system has as of yet. We'll keep pushing, but if you encounter a better l10n system, please let me know! We're working on Unicode MessageFormat 2.0 based on Fluent and incorporating lessons learned.
Comment · 3 years ago
We're happy to announce ICU4X 1.2, containing a host of new features with a focus on text engines. The new ML-powered break iterators and HarfBuzz bindings enable developers to perform text layout on many platforms and resource-constrained environments.
Comment · 4 years ago
Hi, just for context - this was a comparison of `unicode-normalizer` crate to ICU4C.
Since then @hsivonen from Mozilla wrote a new normalizer that recently got merged into ICU4X - https://github.com/unicode-org/icu4x/tree/main/components/no...
I don't have perf numbers yet but I suspect it to be perf comparable to ICU4C at least.
Comment · 5 years ago
Fair question, thanks for asking!
There have been 9 revisions of ECMA-402 since 2012. We are, in fact, following TC-39 on a yearly cadence of releases.
You can see the history of editions here: https://www.ecma-international.org/publications-and-standard...
The first edition (finished in 2012), had just NumberFormat, Collator and basic DateTimeFormat.
Since then, we added Locale, PluralRules, ListFormat, RelativeTimeFormat, DisplayNames, two new revisions of NumberFormat, two major additions to DateTimeFormat, and we're now adding Segmenter, LocaleInfo, CalendarInfo and working on MessageFormat 2.0.
Here's a very incomplete list of finished proposals that have been merged into the standard and implemented in browsers - https://github.com/tc39/proposals/blob/master/ecma402/finish...
I may or may not be involved in majority of them! :)
Comment · 5 years ago
You're correct. Intl formatting has two components:
- Selecting the appropriate pattern for a given locale
- Formatting numbers and words into the given locale (example: eastern-arabic numerals and Arabic month/week names).
You might say "I want to supply my own pattern, you just do step two for me" and technically we can provide that functionality by exposing it.
The issue is that from the API design perspective it would lead to people misusing the API misunderstanding what is going on and believing that they "internationalized their UI" which is not the case. In fact, they'd make things worse for their users than if they just displayed a date in a single locale with consistent pattern+localization because in some cases "MM/DD" and "DD/MM" are indistinguishable when expanded and that may lead to data loss, security loss, or just confusion.
I'd argue that every case where you want to supply your own pattern is a case where you should not attempt to internationalize that pattern. I also recognize that it's just my opinion.