Bugzilla Bug 13618

Is anything like that in place? I can start translating it to French and German
if  it is.. if not, what's neccessary?

docs team -- we may as well have some translations for nls attached to the bug
-- once they're here, then something can be done about adding them in the
future.

AFAIK there is no NLS support in general, how should we then be able to make
translations? Everything is handled by einfo's and ebegin's etc. 

the first step would be to NLS-ize portage ... 
ebuilds would be a step later ... and again, getting back to my idea about using 
metadata.xml to store 'einfo' type messages, we could store translations there 

*** Bug 32630 has been marked as a duplicate of this bug. ***

Created an attachment (id=20224) [details]
First pass on adding nls to emerge

Created an attachment (id=20225) [details]
Example of translateable strings in emerge

This bug has been sitting here quite a while, so I apologize the bumping, but I
was just playing around with the idea, and currently you can easily pull out
the translatable strings from ebuilds and eclasses with xgettext using eg.

xgettext --language=shell --from-code=UTF-8 --keyword=einfo --keyword=ewarn 
--keyword=ebegin --keyword=die 
(can die be also hacked to support this without changes in ebuilds?)

Executing this to all eclasses (/usr/portage/eclass/*eclass) produces 539
translatable messages, dozen of which are untranslatable (empty strings or
string of 80 exclamation marks(!); empty strings are more dangerous because
they have a special meaning in gettext, exclamation and star strings are just
plain stupid). 

Executing this to all ebuilds (find /usr/portage -iname "*ebuild") ... takes
ages ;-) ... some 5 minutes to be exact ... and that totals to 11091 messages,
tough job, but not significantly bigger than few other huge projects like kde
or Gnome. Majority of these are proper translatable strings, then there's some
1% of lines and ascii art and some 1% of command names and web sites.

The biggest problem with current ebuilds is spliced strings, eg. there is often
einfo "This is a sentence that is"
einfo "broken from very"
einfo "bad places making"
einfo "it totally untranslatable"
hacking these in to a one string would make job a lot easier and reduce number
of translatable messages by at least few percents.

Of course this all might be just a curiosity, but that's something to think of,
if the localization of portage will become an option. I'd also strongly suggest
against using translatable messages in externalized xml's after the hassle I've
seen with eg. Gnome's localisation projects.

Uhm... on second thought I'd also suggest second bug for localisation of stuff
in portage tree, as that is quite a different animal than localisation of stuff
found in portage package itself. This thing only concerns portage application
as far as making einfo et friends gettext-aware.

Some more to think about: where all the ebuild translations go to ? It should
not be the current portage tree. There are probably one more rsync for each
supported languages?

Why would the portage tree not be a good placement for ebuild translation data?
After all it is data that is supposed to be somewhat in sync with rest of the
portage tree (even though gettext and friends will of course handle anything).
If size of bandwith are issue, you could only distribute the binary .mo files,
perhaps even compressed, and only handle the source .po's in the server side
somewhere.

But I still suggest splitting the ebuild translation to separate bug, actually,
and use this for portage program's itselves nls (which might or might not
include gettextizing the printing e* functions).

So, is anyone working on this?

Not really. Personally I'm also not a big fan of translation for
ebuilds/eclasses, just increases tree size, maintenance overhead and complexity
for little to no use IMO.

agreed ... about the only thing that i think is worthwhile for nls support with
ebuilds/eclasses is DESCRIPTION ... and that can be done with metadata.xml

I must disagree slightly with you on usefulness. If Gentoo is ever aimed for
enterprise, educational or other public usage, the localisation is requirement
even for the adminstrative software like portage. Furthermore it's absolute
necessity for huge part of the world where English language is not used even in
education. And thirdly proper localisation does reduce the need of support quite
nicely.

But I agree it's a big project and would need to be planned very carefully
should it ever be done.

Then again, if the size of translations is an issue, I suppose they could be
stored separately, even on one main server solely, because those would still be
loaded by only the people who want them, and most typical user would only
download one language or maybe two.

Putting a hold on feature requests for portage as they are drowning out the 
bugs. Most of these features should be available in the next major version of 
portage. But for the time being, they are just drowning out the major bugs and 
delaying the next version's progress. 
 
Any bugs that contain patches and any bugs for etc-update or dispatch-conf can 
be reopened. Sorry, I'm just not good enough with bugzilla. ;) 

Well, I said what I think on this both here and on -dev, and in the past four
years nobody came up with a viable solution anyway, so closing this.