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

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

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

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!

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