{"slug": "fluent", "name": "Fluent", "category": "dev-libs", "category_name": "Libraries and frameworks", "description": "", "recommenders": 3, "commenters": 5, "warners": 0, "score": 2.288, "rising": -0.98, "first": "2025-11-11", "latest": "2026-02-16", "why": "Mozilla's Fluent, for example is designed for maximal i18n support of plural selectors", "why_is_quote": true, "has_verdict": false, "sentiment": {"recommend": 3, "neutral": 1, "compare": 1, "warn": 0}, "spark": [1, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0], "listed": true, "loved": [], "caveat": "", "short_quote": "Mozilla's Fluent, for example is designed for maximal i18n support of plural selectors", "kind": "", "icon": false, "domain": "projectfluent.org", "github_repo": null, "official_url": "https://projectfluent.org/", "pricing": "", "aliases": ["Fluent"], "verdict": null, "praise": [{"label": "", "summary": "", "quotes": [{"id": 752546224, "item_id": 47034139, "url": "https://news.ycombinator.com/item?id=47034139", "by": "Vinnl", "date": "2026-02-16", "version": null, "stance": "recommend", "quote": "Fluent informed much of the design of MessageFormat.", "excerpt": "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-system-for-natural-sounding-translations/ (Fluent informed much of the design of MessageFormat.)", "context": "", "use_case": "localization messages", "switched_from": "", "story": "MessageFormat: Unicode standard for localizable message strings"}, {"id": 740993057, "item_id": 46312066, "url": "https://news.ycombinator.com/item?id=46312066", "by": "revetkn", "date": "2025-12-18", "version": null, "stance": "recommend", "quote": "Making Fluent more of a spec was the right call imo", "excerpt": "My project, Lokalized (from 2017, in Java), has the same goal but took a different approach to the \"little language\" design. I'm guessing I had the same inspiration as the Fluent authors - existing solutions were just not expressive enough for the real world. Mentioning here because I'm always super interested in seeing how others approach the problem of effective i18n (it's a bit complex). Making Fluent more of a sp", "context": "", "use_case": "", "switched_from": "", "story": "Fluent: A Localization System for Natural-Sounding Translations"}, {"id": 734223984, "item_id": 45888999, "url": "https://news.ycombinator.com/item?id=45888999", "by": "WorldMaker", "date": "2025-11-11", "version": null, "stance": "recommend", "quote": "Mozilla's Fluent, for example is designed for maximal i18n support of plural selectors", "excerpt": "Your example is still hard-coding just the two plural categories of English \"one\" and \"other\". These days many i18n frameworks do need to embed some business logic, even if it is mostly fun things like the CLDR plural categories: https://www.unicode.org/cldr/charts/48/supplemental/language_plural_rules.html Mozilla's Fluent, for example is designed for maximal i18n support of plural selectors and other such things i1", "context": "", "use_case": "", "switched_from": "", "story": "The kind of company I want to be a part of"}]}], "caveats": [], "who": [{"by": "skwee357", "context": "uses it in one of their products", "url": "https://news.ycombinator.com/item?id=46313785", "date": "2025-12-18"}], "tags": [], "use_cases": ["ui string localization", "localization messages", "localization"], "compared": [], "makers": [{"id": 752618673, "item_id": 47038667, "url": "https://news.ycombinator.com/item?id=47038667", "by": "zbraniecki", "date": "2026-02-16", "version": null, "stance": "recommend", "quote": "wrote this explainer which you may find informative", "excerpt": "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-gettext", "context": "", "use_case": "localization message strings", "switched_from": "", "story": "MessageFormat: Unicode standard for localizable message strings"}], "threads": [{"url": "https://news.ycombinator.com/item?id=47033328", "title": "MessageFormat: Unicode standard for localizable message strings", "mentions": 5}, {"url": "https://news.ycombinator.com/item?id=46262584", "title": "Fluent: A Localization System for Natural-Sounding Translations", "mentions": 2}, {"url": "https://news.ycombinator.com/item?id=45822400", "title": "The kind of company I want to be a part of", "mentions": 1}], "sentiment_by_month": {"2025-11": {"recommend": 1}, "2025-12": {"recommend": 1, "neutral": 1}, "2026-01": {}, "2026-02": {"compare": 1, "recommend": 1}, "2026-03": {}, "2026-04": {}, "2026-05": {}, "2026-06": {}, "2026-07": {}, "2026-08": {}, "2026-09": {}, "2026-10": {}}, "versions": [], "version_unnamed": 0, "family_ref": null, "runs_on": null, "lines": [], "quotes": [{"id": 752740480, "item_id": 47046280, "url": "https://news.ycombinator.com/item?id=47046280", "by": "zbraniecki", "date": "2026-02-17", "version": null, "stance": "compare", "quote": "which can fallback at runtime, allowing for what we call", "excerpt": "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/p", "context": "", "use_case": "UI string localization", "switched_from": "", "story": "MessageFormat: Unicode standard for localizable message strings"}, {"id": 752552977, "item_id": 47034561, "url": "https://news.ycombinator.com/item?id=47034561", "by": "Vinnl", "date": "2026-02-16", "version": null, "stance": "neutral", "quote": "that's very informed by Fluent's design", "excerpt": "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/", "context": "", "use_case": "", "switched_from": "", "story": "MessageFormat: Unicode standard for localizable message strings"}, {"id": 752546224, "item_id": 47034139, "url": "https://news.ycombinator.com/item?id=47034139", "by": "Vinnl", "date": "2026-02-16", "version": null, "stance": "recommend", "quote": "Fluent informed much of the design of MessageFormat.", "excerpt": "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-system-for-natural-sounding-translations/ (Fluent informed much of the design of MessageFormat.)", "context": "", "use_case": "localization messages", "switched_from": "", "story": "MessageFormat: Unicode standard for localizable message strings"}, {"id": 752544608, "item_id": 47034038, "url": "https://news.ycombinator.com/item?id=47034038", "by": "xeeeeeeeeeeenu", "date": "2026-02-16", "version": null, "stance": "compare", "quote": "Here's a comparison between the two on Fluent's wiki", "excerpt": "Here's a comparison between the two on Fluent's wiki: https://github.com/projectfluent/fluent/wiki/Fluent-and-ICU-MessageFormat It seems the last edit of the page was in 2019, so I'm not sure how up to date it is.", "context": "", "use_case": "", "switched_from": "", "story": "MessageFormat: Unicode standard for localizable message strings"}, {"id": 741020560, "item_id": 46313785, "url": "https://news.ycombinator.com/item?id=46313785", "by": "skwee357", "date": "2025-12-18", "version": null, "stance": "neutral", "quote": "I use this in one of my products. The biggest problem with it is that it lacks any tooling around it.", "excerpt": "I use this in one of my products. The biggest problem with it is that it lacks any tooling around it. There are no tools to verify that the file itself is not broken / malformed. And tools like POedit do not support it for translations.", "context": "uses it in one of their products", "use_case": "localization", "switched_from": "", "story": "Fluent: A Localization System for Natural-Sounding Translations"}, {"id": 740993057, "item_id": 46312066, "url": "https://news.ycombinator.com/item?id=46312066", "by": "revetkn", "date": "2025-12-18", "version": null, "stance": "recommend", "quote": "Making Fluent more of a spec was the right call imo", "excerpt": "My project, Lokalized (from 2017, in Java), has the same goal but took a different approach to the \"little language\" design. I'm guessing I had the same inspiration as the Fluent authors - existing solutions were just not expressive enough for the real world. Mentioning here because I'm always super interested in seeing how others approach the problem of effective i18n (it's a bit complex). Making Fluent more of a sp", "context": "", "use_case": "", "switched_from": "", "story": "Fluent: A Localization System for Natural-Sounding Translations"}, {"id": 734223984, "item_id": 45888999, "url": "https://news.ycombinator.com/item?id=45888999", "by": "WorldMaker", "date": "2025-11-11", "version": null, "stance": "recommend", "quote": "Mozilla's Fluent, for example is designed for maximal i18n support of plural selectors", "excerpt": "Your example is still hard-coding just the two plural categories of English \"one\" and \"other\". These days many i18n frameworks do need to embed some business logic, even if it is mostly fun things like the CLDR plural categories: https://www.unicode.org/cldr/charts/48/supplemental/language_plural_rules.html Mozilla's Fluent, for example is designed for maximal i18n support of plural selectors and other such things i1", "context": "", "use_case": "", "switched_from": "", "story": "The kind of company I want to be a part of"}]}