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:
Necessity to use external tools to translate .po files.
Having to describe the process of translating these files to non-tech people.
Having to send the .po files and receive translated versions from non-tech people.
Troubles with spotting not translated keys.
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
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?
Think of Kanta as an additional layer on top of Gettext. The process is as following:
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..
New translation keys that appear in the timeline after point 2, will be added to DB as well.
Translations that you already have (both in DB, as well as .po files), can be overridden in Kanta UI at any point.
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 thanks a lot, will check!
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
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.
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.
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
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?
thanks a lot, will check!
