Re: [Enlightenment-intl] modules translation

[David S. <dav...@gm...>]

On 1/25/06, Massimo Maiurana <mai...@gm...> wrote:
>
> David Stevenson, il 24/01/2006 13:07, scrisse:
>
> >> This was was I thought at first too, but it turns out that it is
> possible
> >> for an application to have more than a single .mo file in use at once:
>
> oh, I didn't knew about it :)
>
> >> I have added support in the moon module (and there will be a new
> version
> >> in the next few days that actually has some more strings to
> translate!), and
> >> I noticed that the evolume module too started adding support in this
> >> fashion.
> >> This hasn't been done for the e_modules though, possibly just because
> no
> >> one got around to it yet? I don't know of any problem with this idea.
>
> uhm, since e_modules does contain a "root" autogen.sh, which makes
> the user able to build a single e_modules package, the question
> there would be how to create an e_modules.pot file rather than
> single *.pot files one for each module.


Oh, I see. So now I know!
I've only installed one of the e_modules myself, cvs co'd out individually.

so, how will e_modules be released?
> will they be released as a single package, or there will be many
> packages?


I guess the module packagers may decide to do it either way. I know for
debian and e16 all the epplets come in one big package, but then I never
actually used a lot of them (maybe it was a meta package or something tho -
I'm a clueless n00b in that area).
So I'd personally rather not have the cruft installed myself, but others
would surely want everything just to save themselves hassles of multiple
installations.

>> For 3rd party modules not in cvs I think there is no option but to use a
> >> seperate .mo file
> >> For "3rd party modules" that are in cvs, that option makes assumptions
> >> that the user has checked out e_modules (all of them) by the time e's
> >> ./autogen.sh grabs all the strings from the source for translation. I
> >> personally only check out e_modules one by one - and most of them not
> at
> >> all!
>
> actually e17's autogen.sh only grabs string from its own source code
> to create enlightenment.pot, and I don't think this could change in
> the future.
>
> I'd created the "big" enlightenment.pot executing xgettext from
> command line this way:
> xgettext -n -C -d enlightenment --foreign-user \
> -k -k_ -kd_ --from-code=3DUTF-8 -o enlightenment.pot \
> `find ./e17/apps/e -name "*.[ch]" -print` \
> `find ./e_modules -name "*.[ch]" -print`
>
> I can do it because I know where e17 and e_modules dir are on my
> system, unlike autogen.sh :)
>
> so, basically, my option makes assumption that either the translator
> knows/wants to generate a big comprehensive enlightenment.pot or
> that we provide one apart... indeed, not a big deal :)
>

> At any rate, if the dev team likes the idea, I'd be happy to put together
> > some patches for the e_modules along the lines of what I did to add i18=
n
> > support to the moon module... just give me a yay or nay.
>
> I hope it will be a yay! ;)
>
> > Anyway, I mainly wanted to note that it is possible to have a module
> >> specific .mo. It's also possible for those module .mo's to use strings
> from
> >> the main e .mo, if they wish.
>
> they already do it.
> in fact my concerning about translating modules started when I saw
> that modules were partially translated, due to the fact that they
> share many (already translated) strings with core e17 modules, and
> that made me think I was seeing an unfinished work.
>
> now that I know it's possible to provide a translation for each
> module(s) package, I hope there'll be soon pot files to edit ;)



Ok, well in that case, I will start working on some i18n per-module patches=
,
and we'll see what happens, There's quite a bit to do, so I'll do a few at =
a
time for starters.

Regards
David