fluent

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!

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

kes it harder to introduce multiple messages with the same source string which should be translated differently ... > Fluent establishes a social contract between the developer and localizers. The developer introduces a unique identifier and provides a set of variables such as number of unread emails or the name of the user, and localizers are using Fluent syntax features to construct the best possible translation for that identifier.

use custom formatting options. weekday-today = Today is {DATETIME($today, weekday: "long")}. See https://projectfluent.org/play/?id=a3540d4f02c104a634adbfc0e... for a live example of DATETIME. There can also be custom functions, defined during the initialization of the runtime. In Firefox, we use one such function called PLATFORM: https://searchfox.org/mozilla-central/rev/d33d470140ce3f9426.... It can be used as follows: open-preferences = {PLATFORM() -> [windows] Open Options *[other] Open Preferences } The logic of custom functions is entirely up to developers and the localization needs of the UI. In https://github.com/projectfluent/fluent/issues/228#issuecomm..., for instance, I suggested using a custom function to handle negative and positive floor numbers. A custom function can also cater to the use-case you described. A simple and possibly naive implementation in JavaScript could look like the following one: function NUMBER_HEAD(num) { while (num > 999) { num /= 1e3; } let first = num.toString()[0]; return num < 10 ? first : num < 100 ? first + "x" : first + "xx"; } I wrote this with Polish in mind, but it could be useful to other languages in which numerals are named after the first thousand-triple, in a left to right order. Depending on the exact product requirements, the function could be called NUMBER_HEAD_POLISH, or perhaps NUMBER_HEAD_TRIPLE_FIRST_DIGIT :) Once defined, the function can be used as follows: # The Polish copy can take advantage of the custom function. page-of = {NUMBER_HEAD($pageTotal) -> [1xx] Strona {$pageCurrent} ze {$pageTotal} *[other] Strona {$pageCurrent} z {$pageTotal} } This method still requires some work from developers, but it only needs to happen once and in a single palce in code: where the Fluent runtime is initialized. Because they are code, custom functions can be reviewed and tested just as any other code in the code base, to help ensure that they do what they claim to :) Importantly, the use of the custom function is completely opt-in. # The English copy doesn't need any special handling. page-of = Page {$pageCurrent} of {$pageTotal} All localization callsites remain unchanged, and all existing translations remain functional.