comps headsup: plan to drop langpacks from language-support groups in comps-f17.xml.in

[Ankitkumar Rameshchandra Patel]

On 09/09/2011 10:50 AM, Jens Petersen wrote:
> Hi,
>
> yum-langpacks has been working pretty well now for a while in Fedora,
> but all langpacks are still listed conditionally in comps' language support groups
> in addition to the<langpacks>  meta-section.
>
> So for F17 I'd like to remove them all from comps,
> this will simplify comps a lot and if we can also
> remove the resulting empty language support groups
> it will also reduce the comps translation burden
> in addition to comps maintenance.
>
> A few things I noted while attempting to prune comps-f17:
>
> - most of the remaining packages in language support group are fonts and input-methods
>    - perhaps the mandatory/default ones could Provide: fonts(lang) and input-method(lang).
> - normal anaconda installs support installation of multiple language support groups
>    - I think it would be better to move the list of languages out of comps into anaconda itself
>      (they are already translated in iso-codes, etc)
>    - anaconda could then set langpack_locales to install langpacks for multiple languages
> - we maybe need to add a new "yum install-lang" command say to replace "yum install @<lang>-support"
>    which could use a more aggressive version of yum-langpacks to pull the required packages.
> - @base and @office still list aspell-en, hunspell-en, and libreoffice-langpack-en conditionally
>    which I think could be dropped.
>
> Anyway the fact that we can remove 1500 basically redundant lines now
> from comps thanks to Bill's great work on yum-langpacks is good news and
> would be a big win IMHO.  This might well make a good F17 Feature.
>
> Jens

Hi,

Related note. How about we also change the way we manage translations
for packages?

This gives more control over translations to translators also
translators become independent from package maintainers and can reduce
burden from package maintainers taking care of translations!

Shouldn't we have translations packaged independently from RPM packages?

Anybody knows, how to modify the path of message catalogs (i.e.
/usr/share/locale) dynamically while running an application? I would
like to use a different mo file rather than the default provided by
system. Is it possible? If yes, how?

Thanks!
-- 
Regards,
Ankit Patel
http://www.ankit644.com/