Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 13618 - NLS support for portage
Summary: NLS support for portage
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core (show other bugs)
Hardware: All All
: High enhancement (vote)
Assignee: Portage team
: 32630 (view as bug list)
Depends on:
Reported: 2003-01-09 22:30 UTC by Michael Cohen (RETIRED)
Modified: 2021-09-06 19:29 UTC (History)
7 users (show)

See Also:
Package list:
Runtime testing required: ---

First pass on adding nls to emerge (emerge.diff,37.27 KB, patch)
2003-11-03 20:07 UTC, Benjamin Tegarden
Details | Diff
Example of translateable strings in emerge (portage.pot,21.60 KB, text/plain)
2003-11-03 20:08 UTC, Benjamin Tegarden

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Cohen (RETIRED) gentoo-dev 2003-01-09 22:30:55 UTC
Is anything like that in place? I can start translating it to French and German
if  it is.. if not, what's neccessary?
Comment 1 Seemant Kulleen (RETIRED) gentoo-dev 2003-04-11 12:11:43 UTC
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.
Comment 2 Sven Vermeulen (RETIRED) gentoo-dev 2003-08-28 09:34:57 UTC
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. 
Comment 3 SpanKY gentoo-dev 2003-08-28 17:56:43 UTC
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 
Comment 4 SpanKY gentoo-dev 2003-11-03 11:42:32 UTC
*** Bug 32630 has been marked as a duplicate of this bug. ***
Comment 5 Benjamin Tegarden 2003-11-03 20:07:14 UTC
Created attachment 20224 [details, diff]
First pass on adding nls to emerge
Comment 6 Benjamin Tegarden 2003-11-03 20:08:56 UTC
Created attachment 20225 [details]
Example of translateable strings in emerge
Comment 7 Flammie Pirinen (RETIRED) gentoo-dev 2005-01-11 20:03:52 UTC
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.
Comment 8 Nguyen Thai Ngoc Duy (RETIRED) gentoo-dev 2005-04-12 08:51:39 UTC
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?
Comment 9 Flammie Pirinen (RETIRED) gentoo-dev 2005-04-13 13:08:57 UTC
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).
Comment 10 Marcelo Goes (RETIRED) gentoo-dev 2005-06-22 11:12:54 UTC
So, is anyone working on this?
Comment 11 Marius Mauch (RETIRED) gentoo-dev 2005-06-22 14:07:36 UTC
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.
Comment 12 SpanKY gentoo-dev 2005-06-22 15:10:02 UTC
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
Comment 13 Flammie Pirinen (RETIRED) gentoo-dev 2005-06-30 05:01:07 UTC
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

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.
Comment 14 Jason Stubbs (RETIRED) gentoo-dev 2005-07-28 07:25:19 UTC
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. ;) 
Comment 15 Marius Mauch (RETIRED) gentoo-dev 2007-01-11 11:43:03 UTC
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.