| Summary: | NLS support for portage | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Michael Cohen (RETIRED) <mjc> |
| Component: | Core | Assignee: | Portage team <dev-portage> |
| Status: | VERIFIED LATER | ||
| Severity: | enhancement | CC: | docs-team, et-8, flammie, gentoo, h3y, puggy, seemant |
| Priority: | High | ||
| Version: | 2.0 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
First pass on adding nls to emerge
Example of translateable strings in emerge |
||
|
Description
Michael Cohen (RETIRED)
2003-01-09 22:30:55 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. 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 attachment 20224 [details, diff]
First pass on adding nls to emerge
Created attachment 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. |