lingo.dev VS fluent

RAL configuration. Each augmented engine contained 72 glossary terms per locale pair (70 custom translations plus 2 non-translatables), a brand voice profile (formal EU regulatory register), and 13 locale-specific instructions. Glossary terms were extracted from a training set of articles separate from the test set used for evaluation. Example entries: EN "provider" → PT "prestador" (not "fornecedor"); EN "high-risk AI system" → PT "sistema de IA de risco elevado" (not "sistema de IA de alto risco"). At inference time, only terms matching the current paragraph are retrieved and passed to the model — glossary size does not bloat the context window. Engines were configured on Lingo.dev as stateful localization engines — persistent context applied to every request.

If you've read my previous articles on HTML5 elements you didn't know you need or CSS modal windows, you know we like unusual tech at Lingo.dev. These upcoming JavaScript features solve real problems that have annoyed developers for years.

At Lingo.dev, we've been using this a lot deep inside our localization API, and it's dramatically simplified our text processing pipeline. What used to require multiple specialized libraries and server-side processing can now be handled directly in the browser with just a few lines of code.

As you know, we love unusual tech at Lingo.dev. So when in my last essay, David commented he was surprised to not see "dialog" HTML element, it hit me - wait, but there's so many HTML5 elements that we don't even know about!

Wait, you can build modal windows without JavaScript? Yep, that's CSS secretly laughing at JavaScript behind its back. At Lingo.dev, we love diving into weird engineering rabbit holes that make other devs do a double-take.

At lingo.dev, we're always on top of the latest models to ensure our translations are perfect. So when Meta released Llama 4, I immediately dug into what makes it special and how we developers can leverage its power without the infrastructure headaches.

In this post, I'll walk you through how to build an automated CI/CD translation pipeline using Lingo.dev and Knock that will handle localized notifications for your app without requiring any manual translation work from your team. We’ll introduce some tools that can help you scale your application to a global audience, automate translations locally using Lingo.dev's CLI, and finally integrate that CLI into a CI/CD pipeline so that translations are automatically created when developers open a pull request.

Hey! Max here, one of the co-founders - great question!

Technically - it's a compiler plugin: it augments build artifacts, so that extracting text from the app into JSON files for further translation is no longer required.

Since we're solving the problem at compile time, React code remains the same, but the app becomes just one cli command away from being fully translated into other languages!

Here's me speedrunning (~2min?) the localization of a typical next js app from english to spanish: https://github.com/replexica/replexica/blob/main/getting-sta...

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.

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

Mozilla's Fluent, for example is designed for maximal i18n support of plural selectors and other such things i18n needs: https://projectfluent.org/

I think modern Japanese is LTR, but besides that - I believe the project you worked in the past solves an important problem.

Besides pluralization (and e.g. Arabic having 6 forms zero/one/two/few/many/other), turned out number internationalization and currency conversion are big next challenges the community wants to address next.

> create ICU compliant JSON.

I think this is an excellent idea. I have a feeling in the future we will need ICU v2.0, sort of, but unfortunately it's an extremely hard problem and the probability to fail is pretty high (looks like project fluent is not actively maintained anymore: https://github.com/projectfluent/fluent)

Tried BoldVoice right now and almost immediately hit a bit of awkwardness: “Tomorrow, we’ll work on Practice your consonant skills”. Usually I wouldn’t complain about this sort of thing, but in a language learning app it seems unfortunate. (Mozilla’s Project Fluent[1] was built to handle these situations in a localization setting, but you can probably get away with something much simpler.)

[1] https://projectfluent.org/

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.