Hide Forgot
Langpacks are not pulled when running "yum install libreoffice" neither running "yum groupinstall office". This also might be related to libreoffice packages since "yum install koffice-suite" works ok. Version-Release number of selected component (if applicable): yum-langpacks-0.2.2-1.fc16 libreoffice-3.4.3.1-1.fc16
Can you add the output of 'yum -d9 install libreoffice'?
Note that I can't reproduce this here. yum remove libreoffice\* (because I have it installed) followed by: LANG=de_DE.UTF-8 yum install libreoffice correctly pulls in libreoffice-langpack-de.
Created attachment 521309 [details] yum output
yum -d9 install libreoffice output is attached. I also have tried LANG=es_ES.UTF-8 yum install libreoffice and it did pull the langpack in, but running LANG=pt_BR.UTF-8 yum install libreoffice didn't (pt_BR was the current language anyway) Note that this is not language specific, though. Other people also reported the same issue during the I18N test week.
It might be nice to verify what the other failed langs were, but my guess is that this is probably due to the "renaming" of the langpacks compared to oo.o's langpacks. I suspect this is also true for Fedora 15, no? eg openoffice.org-langpack-pt_BR became libreoffice-langpack-pt-BR, etc. More precisely a change from gettext to Java style locale naming. Fortituously since most langs just got truncated to two letters eg ja_JP, de_DE -> ja, de which is a good thing indeed anything and so were not affected. However for lang ambiguities/variants the Java names are now used: currently I think this only affects langpacks for Portuguese (pt-BR and pt-PT) and particularly Chinese (zh-Hans and zh-Hant). Being "lazy" I would prefer to see those libreoffice-langpack's provide libreoffice-langpack-pt_BR and libreoffice-langpack-zh_CN, etc. Otherwise we would have to special-case those languages in yum-langpacks which might lead to more yum overhead. I think this might be a second call for a Packaging Langpacks Naming Guideline! Reassigning to libreoffice to hear if they can please add such Provides.
BCP-47 style FWIW (http://www.rfc-editor.org/rfc/bcp/bcp47.txt) rather than anything to do with Java. BCP-47 offers a relatively sane way to describe e.g. Serbian written in Latin script, sr-Latn or Sindhi written in Devanagari script, sd-Deva. I have some code to map existing glibc locales to best-fit tags http://people.redhat.com/caolanm/BCP47/ but its err... a work in progress. We can add some provides I suppose for now. If there is a move for langpack naming guidelines I'd like to know in order to make my own counter proposal ;-)
caolanm->dtardon: could you extend that langpack macro with another optional -P/-p or something argument to allow adding provides for pt_XX and zh_XX ?
dtardon->caolanm: sure, that's easy
will be in libreoffice-3.4.3.2-6.fc16
(In reply to comment #6) > BCP-47 Right thanks. > I have some code to map existing glibc locales to best-fit > tags http://people.redhat.com/caolanm/BCP47/ but its err... a work in progress. Cool, that's interesting. Is it in version control somewhere? A python binding might also help adoption by anaconda/yum. > We can add some provides I suppose for now. Ok thanks, libreoffice-3.4.3.2-6.fc16 looks good. > If there is a move for langpack naming guidelines > I'd like to know in order to make my own counter proposal ;-) Well I would be happier to collaborate on a good solution. :) Certainly the current mapping of locales to langs/scripts is often awkward - so I hear what you're saying. As you know the main fedora-wide problem with langpacks naming currently is not so much the language suffixes but the variety of upstream naming for them. Anyway perhaps if Fedora langpack subpackages provided something like "%{name}-langpack(<BCP47code>)" that might help to simplify things. Some standard rpm macros for langpacks might be able to help with that. Probably need to think more how to map optimally into yum-langpacks searching. Maybe comps lang groups should use BCP-47 too. That would be ideal for Chinese at least, and maybe some other langs. Do you want to open an rfe against yum-langpacks for BCP-47 support to track this anyway? I would be interested to hear more on your ideas.
libreoffice-3.4.3.2-6.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/libreoffice-3.4.3.2-6.fc16
Package libreoffice-3.4.3.2-6.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing libreoffice-3.4.3.2-6.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/libreoffice-3.4.3.2-6.fc16 then log in and leave karma (feedback).
libreoffice-3.4.3.2-6.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
libreoffice-3.3.3.1-6.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/libreoffice-3.3.3.1-6.fc15
libreoffice-3.3.3.1-6.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 739963 has been marked as a duplicate of this bug. ***
> BCP-47 style FWIW (http://www.rfc-editor.org/rfc/bcp/bcp47.txt) rather than > anything to do with Java. Why can't we just accept that the glibc/gettext format has become the de-facto standard and that it doesn't make sense to invent a new, incompatible one? It's way too late for that! > BCP-47 offers a relatively sane way to describe e.g. Serbian written in Latin > script, sr-Latn or Sindhi written in Devanagari script, sd-Deva. So does glibc/gettext, that's what the @variant suffix is for. kde-l10n uses at least sr@latin, sr@ijekavian, sr@ijekavianlatin and ca@valencia. > I have some code to map existing glibc locales to best-fit tags > http://people.redhat.com/caolanm/BCP47/ but its err... a work in progress. I see you have a hunspell patch there, which renames all the hunspell dictionaries. I have to warn you that this is an incompatible change which will undoubtedly break many applications using hunspell. (We already have enough problems as it stands now with some KDE applications assuming they can just request "de" as a dictionary as opposed to de_DE, de_AT or de_CH. But if you also rename away the de_DE etc. ones, many more applications will be broken. No application will be looking for a de-DE dictionary.) Please do not make such gratuitously incompatible changes.
Bugzilla is the wrong place for the discussion, anyway all those patches are solely patches (from last year), they're not integrated into anything, they're thinking aloud. What's the glibc code for "German using pre 1996 spelling rules change" or "English using Oxford English Spelling preferred '-ize' suffix" :-)