Kanta - the ultimate solution to translations in Elixir & Phoenix web apps

Hey guys!

I’m happy to announce that our amazing team at Curiosum developed a very cool open-source library called Kanta. If you struggle with translations, it can help you a lot.

Kanta’s goal is to reduce the following pains:

  1. Necessity to use external tools to translate .po files.
  2. Having to describe the process of translating these files to non-tech people.
  3. Having to send the .po files and receive translated versions from non-tech people.
  4. Troubles with spotting not translated keys.
  5. Having to deploy the new version of the app whenever a new translation is introduced.

All of that, packed within a friendly UI, and the best thing - to make it work, you don’t have to change anything in your code since it integrates with gettext. The installation is very simple, and for a start, we provide additional plugins:

  • DeepL, if you’d like to translate the keys automatically
  • PO Writer, if you’d like to export translations into .po files


  1. Announcement blog post: Introducing Kanta - the ultimate solution to translations in Elixir web apps | Curiosum
  2. Kanta repository: GitHub - curiosum-dev/kanta: User-friendly translations manager for Elixir/Phoenix projects.
  3. DeepL plugin: GitHub - curiosum-dev/kanta_deep_l_plugin: DeepL integration for Kanta
  4. Po Writer plugin: GitHub - curiosum-dev/kanta_po_writer_plugin: PoWriter plugin for Kanta

this looks amazing, will give it a spin for translating a react native app

edit: looks like this is on the roadmap - could be great to have!


looks pretty cool.

i couldn’t quite understand the end goal though. from the descriptions it seems like a different way to use gettect inside of code, but then there’s the UI that looks like a full-blown translation tool. so is Kanta for dealing with files, code or translators?

Hey, thanks for the question.

Think of Kanta as an additional layer on top of Gettext. The process is as following:

  1. To understand the entire process, first I need to point out that you don’t have to change anything regarding gettext - just like you used to call gettext functions within your codebase, you still do. The first assumption of Kanta, when we started to develop it was the ability to integrate with current gettext calls within the app. The only thing to make this work is this line: GitHub - curiosum-dev/kanta: User-friendly translations manager for Elixir/Phoenix projects..
  2. Kanta takes the translations you currently have in app and populates them into DB. That’s why you need to run these migrations: GitHub - curiosum-dev/kanta: User-friendly translations manager for Elixir/Phoenix projects..
  3. New translation keys that appear in the timeline after point 2, will be added to DB as well.
  4. Translations that you already have (both in DB, as well as .po files), can be overridden in Kanta UI at any point.
  5. Kanta allows you to use a caching mechanism so that it doesn’t fetch the translations from DB every time it calls gettext. That’s solely for the performance reasons.

So, to summarize, Kanta at this stage of its development, is an extension to gettext. You still use gettext in your codebase, but now, you can also edit translations via UI without the need to release a new app version. It’s quite a popular scenario that applications are translated not by developers, but rather by non-tech people, and it’s especially useful for them (but not only).


this comes handy - just started a new phoenix app that needs t9n anyways and was looking whether to use localise or something else :slight_smile: thanks a lot, will check!

1 Like

nice. that explains it perfectly.

1 Like

Have you looked at Accent from Mirego? It seems to fill similar role, but with target for broader set of export formats (and automation between developers and translation tool).


Looks good, didn’t know this lib before. There is, though, one significant difference here - we wanted a tied to gettext solution that would be very easy to add to existing projects, which we believe is the case for a majority of Elixir & Phoenix apps.

Our goal here is to provide a solution specifically for our beloved tech stack rather than creating a general-purpose tool :slight_smile:


Looks quite good actually. In my case and as all my translations are done in react apps on the client side, Accent seems better suited and would make the l16n workflow easier.

I like the idea of having it all handled by the same server though, and there is definitely a sweet spot to reach there. Wouldn’t it be nice to not have any XX.json files in the client side apps as they would query the system instead (no need to add new keys in there, as Kanta would detect missing keys and add them to the right project).

We will think about a solution with a mix of API and custom middleware.

Custom middleware would serve as a mapping mechanism so that the format of frontend translations would match the one we use in gettext. It could work, I think.

Frontend could update the new translations once it gets WebSocket info.

1 Like


Oh nice project! I will try soon.
I’m also using json translations files on the frontend, with i18next.
It would be great to be able to support json files. For example, by indicating the path to the folder where the json files are stored. This would be a complete solution for managing all translations.


Library looks really handy and promising!


Hey, thanks for your kind words!

About the frontend integration - we’ll need an API for that and a middleware that maps translations to a format acceptable by the library on the JS side. It’s doable and in our current roadmap :slight_smile:


Nice :+1:

With the DeepL plugin, does it have the ability to automatically translate the new gettext strings? Say I have 10 different languages. Can it translate each string into all those 10 languages with a click of a button? Or would I have to manually do it for each language?

It’s one by one for now, but your idea sounds like a very cool feature request :slight_smile: Consider adding it here: Issues · curiosum-dev/kanta · GitHub

1 Like