Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 115934 - Translation/localization packages and new category for them
Summary: Translation/localization packages and new category for them
Status: RESOLVED WONTFIX
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High enhancement (vote)
Assignee: Gentoo Linux bug wranglers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-12-18 06:43 UTC by Alexander Dubov
Modified: 2005-12-18 20:25 UTC (History)
0 users

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Dubov 2005-12-18 06:43:54 UTC
I failed to find any info on this issue, so I'm posting this as bug.

I believe it will be beneficial to split *-i18n packages into language specific ebuilds. For example, packages such as kde-i18n, koffice-i18n or k3b-i18n (which should really be a different ebuild and not part of the k3b) are extremely inconvenient in the multi-language environment, where the addition of extra translation forces one to re-emerge all other translations too. I would like to convert these ebuilds into meta-packages and to create separate ebuilds for each language. I however need some assistance from somebody familiar with portage maintenance.

Moreover, I believe that all this *-i18n-lng packages must be put in the separate portage category, something like "app-trans" (as app-i18n is already taken). This way it will be easy to query status of available localizations for the desirable language (not the easiest thing to do with the current state of affairs).
Comment 1 Jakub Moc (RETIRED) gentoo-dev 2005-12-18 07:29:51 UTC
Like creating about a zillion of ebuilds for each available i18n-compliant ebuild and LINGUA? Sorry, that's what LINGUAS variable is for, there's really no need to clutter portage tree with tons of such duplicate ebuilds for each language. 
Comment 2 Alexander Dubov 2005-12-18 20:25:21 UTC
I'm constantly working with multi-language installations (> 4 languages). The problem is that some i18n ebuilds take longer to rebuild than application itself.
Then, if you consider the fact that not all application require translation and that some translations for kde-i18n are already more than 30MB in size it is not too far fetched to create separate ebuilds for such translations.
Additionally, not all applications require translations and not every application is translated to every language.
Now, my desire is to have a setup which would allow me to move toward complete translation of my working environment. This means at least two things: ability to update translation for some language without affecting others and ability to query current status of translations to a given language. To my opinion current arrangement interferes quite strongly with this goal.