dresb's suggestion

Place the locale name, font file and .mo file in an .eet file. The installer for this file would be implemented in the Language configuration module. To create new packages an simple CLI or GUI utility could be provided separately from Edje.

The problems

<mekius> of course i'm not sure this is very clean given it bypasses a distro's package manager and such and can add extra files
<sur5r> exactly... for distros it's less useful
<dresb> ok. so how should I do it?
<mekius> dresb: well i'd almost say to make a template module that distros could easily modify to their setup, but then it wouldn't be really useful generically

More discussion

<k-s> dresb: it will be unpacked after installed, right?
<k-s> AFAIK gettext cannot read from eet or memory buffers
* parabelboi se ha marchado (Read error: 104 (Connection reset by peer))
<dresb> k-s: yes
<k-s> dresb: then what you need is just a way to handle distribution
<k-s> sticky it to local user dir and that's it
<k-s> it's just better to provide some kind of versioning and warn user that he must upgrade, possible with an e utility
<k-s> you don't mess with distro, you help users
<mekius> well if you put the files in the users home dir that's fine
<k-s> you shouldn't mess with system, it's bad
<mekius> but what happens when the distro packages up a new E and it has a newer translation, now your home dir copy is overriding it and so it looks like nothing ahs changed
<k-s> mekius: that's why I said you should add a version field and check it
<mekius> ah
<dresb> perhaps it would be possible to have multiple versions of the same translation working at the same time
<k-s> mekius: also, if distros ship e, why not ship translations?
<mekius> the .mo should have a version iirc
<mekius> they do ship the translations
<mekius> that's my point :)
<mekius> but unless there is versioning it would conflict
<k-s> mekius: even if .mo have no version, you can have a field "version" translated to e version... maybe some automatic build script
<mekius> well the translations shipped with E would need to have versioning in them as well
<mekius> so they could override the user's translation
<k-s> need to check if gettext supports that
* etrunko (n=edulima@200.184.118.132) ha entrado en #edevelop
* Lutin se ha marchado (Remote closed the connection)
* handyande se ha marchado ()
* Gagis se ha marchado (Read error: 104 (Connection reset by peer))
* Gagis (n=Gagis@a237.ip4.netikka.fi) ha entrado en #edevelop
* koch se ha marchado ("Verlassend")
<dresb> ok, language pkgs have the "Project-Id-Version" property. I can't find a way to specify the version to use in the application code, I assume it uses the one with the biggest value. I'm testing it right now.
* koch (n=koch@p57AD5ABB.dip.t-dialin.net) ha entrado en #edevelop
* Thanatermesis se ha marchado (Read error: 104 (Connection reset by peer))
* emte (n=emte@66.183.8.167) ha entrado en #edevelop
* watchwolf (n=watchwol@4va54-5-88-163-244-133.fbx.proxad.net) ha entrado en #edevelop
* devilhorns (n=devilhor@c-69-253-227-184.hsd1.nj.comcast.net) ha entrado en #edevelop
<k-s> dresb: isn't it a "translated" string?
<k-s> dresb: I mean, you do strcmp(_("Project-Id-Version"), "0.1") == 0
* tri (n=tri@p57ADB47A.dip0.t-ipconnect.de) ha entrado en #edevelop
* Thanatermesis (n=Enlighte@unaffiliated/thanatermesis) ha entrado en #edevelop
<Thanatermesis> mekius, aha, no send email, and i don't think that this can be implemented...
* heller (n=heller@91.65.198.93) ha entrado en #edevelop
<dresb> k-s, yes, this seems to be the case.
<dresb> e_intl.c would have to be altered to support multiple translation files
<mekius> Thanatermesis: not too hard, just use sendmail :D

Another solution

gettext language packages have an special "Header Entry" string accessible through an empty string, as in gettext(""). One of the fields in this header is "Project-Id-Version" which reflects the version of the language pkg version, to know it's value we would have to parse the string to fetch the version number of the package. For this to work e_intl.c would have to be modified to search for all the potential files. The application would have to bind to each file in the list, parsing the header of each one and comparing the version number then do the final bind to the newest file.

Another (simpler) solution

To be honest gettext does not seem to be designed for this type of usage, for example, there is no way to simply grab the header from a given file. My suggestion is to let the distributions handle translation since gettext does not seem to be intended for this kind of use.