lingo.dev VS fluent

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

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.