Bug 734976 - libreoffice-langpack-*-* not pulled in by yum install libreoffice
Summary: libreoffice-langpack-*-* not pulled in by yum install libreoffice
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: libreoffice
Version: 16
Hardware: Unspecified
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: David Tardon
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 739963 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-09-01 02:58 UTC by Igor Pires Soares
Modified: 2011-09-29 13:13 UTC (History)
9 users (show)

Fixed In Version: libreoffice-3.3.3.1-6.fc15
Clone Of:
Environment:
Last Closed: 2011-09-09 17:06:07 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
yum output (128.91 KB, text/plain)
2011-09-03 03:12 UTC, Igor Pires Soares
no flags Details

Description Igor Pires Soares 2011-09-01 02:58:52 UTC
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

Comment 1 Bill Nottingham 2011-09-01 19:22:15 UTC
Can you add the output of 'yum -d9 install libreoffice'?

Comment 2 Bill Nottingham 2011-09-01 19:24:30 UTC
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.

Comment 3 Igor Pires Soares 2011-09-03 03:12:13 UTC
Created attachment 521309 [details]
yum output

Comment 4 Igor Pires Soares 2011-09-03 03:22:01 UTC
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.

Comment 5 Jens Petersen 2011-09-05 01:55:14 UTC
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.

Comment 6 Caolan McNamara 2011-09-05 09:25:23 UTC
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 ;-)

Comment 7 Caolan McNamara 2011-09-05 10:15:34 UTC
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 ?

Comment 8 David Tardon 2011-09-06 04:29:15 UTC
dtardon->caolanm: sure, that's easy

Comment 9 David Tardon 2011-09-06 04:54:38 UTC
will be in libreoffice-3.4.3.2-6.fc16

Comment 10 Jens Petersen 2011-09-07 06:02:06 UTC
(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.

Comment 11 Fedora Update System 2011-09-07 10:02:15 UTC
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

Comment 12 Fedora Update System 2011-09-08 02:26:18 UTC
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).

Comment 13 Fedora Update System 2011-09-09 17:05:46 UTC
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.

Comment 14 Fedora Update System 2011-09-16 07:59:33 UTC
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

Comment 15 Fedora Update System 2011-09-29 01:41:10 UTC
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.

Comment 16 Jens Petersen 2011-09-29 02:14:19 UTC
*** Bug 739963 has been marked as a duplicate of this bug. ***

Comment 17 Kevin Kofler 2011-09-29 12:39:05 UTC
> 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.

Comment 18 Caolan McNamara 2011-09-29 13:13:00 UTC
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" :-)


Note You need to log in before you can comment on or make changes to this bug.