LostKobrakai
Phillipp
Is “real” text required or will it also work if one supplies a “context”, e.g. Dashboard.Headline and the real text will be loaded from translation files or DB? I actually don’t like the gettext approach.
kip
Can you give me an example of what you are suggesting? I think you’re suggesting using a “string key” rather than a string itself so that all strings, including the base language example, are stored externally. But I’d like to be sure I understand correctly.
For storage - I’m making that pluggable, with at least one backend that can pull (and be pushed) translations from the net.
Phillipp
Exactly this. I don’t like to have one language “hardcoded” in the source. I am also not sure how it will work if one changes the “hardcoded” text to e.g. fix a typo or add additional details. It seems the connection to the translated versions get lost.
But I may also misunderstand this approach. I haven’t used it yet because of the reasons outlined above.
kip
All good points.
The positive side to having the base string embedded in code is the readability and comprehension of the text. But I recognise your perspective as well.
I am definitely supporting the same approach as Gettext. In a similar way, I am basically converting each string into a “compiled” format during module compilation to speed the runtime. At the same time, I am “uncompiling” it to derive a canonical form of the message that I will then hash as they key to translations. At compilation, like gettext, I will do a fuzzy comparison of strings in case there is a minor change like capitalisation. And below a configurable threshold treat the keys they same. This is still a work in progress,
I don’t think its a difficult at all to use an atom as the argument to the messaging functions, rather than a binary. And simply treat that as the key. And I don’t think it compromising the integrity of the overall strategy I currently have in my head.
Comments and suggestions welcome.
LostKobrakai
Even in gettext one could just use string keys instead of proper language and translate that. It’s just that gettext tools often treat the key as the “source language” instead of using the translation for a different language as base.
Phillipp
I didn’t mean Dashboard.Headline as an atom, tho. I would make it a string "Dashboard.Headline". Atoms still don’t grow on trees 
kip
kip
ex_cldr_messges 0.3.0 now has a macro to parse the format at compile-time. Now it’s on to translation scaffolding.
Unlike Gettext while inlines the translations into the backend module, I plan to keep the translations separate so that they can be updated without stopping the application and without having to re-deploy. The storage module will be pluggable on a per-cldr-backend basis.
I am building two storage engines as part of the package:
-
:persistent_termbased, with maybe an:etsfallback for earlier OTP releases. I’ve seen some excellent performance with:persistent_termon an NLP-related project so it seems a good tool for this. -
A web-service based storage engine. Haven’t quite worked out how that’s going to work, but I think it’s the better way to go for production apps. This engine would build on top of the first engine. I will build the web-service too as open source. And I may even build a paid service as well.
Comments and suggestions always welcome.
tmbb
I’m quite happy with my Mezzofanti library as a frontend for you ICU message format library. I can continue working on that if your ICU library is ready.