Description of problem:
I installed Mageia 2 x86_64 from DVD, choosing Mongolian as first language, and made all the updates. When I have an ODF file with non ascii characters, like "été.odt", opening it leads to a dialog box saying that the file doesn't exist, and the file is not open. From the command line, I get also:
"$ soffice /home/henri/Documents/été.ods
I18N: X Window System doesn't support locale "mn_MN.UTF-8""
Note that no Mongolian character appears neither in the file name neither than in its path.
Version-Release number of selected component (if applicable):
Build ID: 350m1(Build:3)
Steps to Reproduce:
1. Change the name of an ODF file, introducing a non-ASCII character in it.
2. Double-click on its name in Konqueror or, in a terminal, type "soffice " and the file name, or, from LibreOffice, click on FileâOpen and choose the file.
There is some interesting information here:
which DE do you use?
Created attachment 3152 [details]
Result of locale -a
German language is not used at all.
Thank you. This is interesting indeed.
What do you mean by "DE"? If you mean German language, we use none. The installed languages, apart from Cyrillic Mongolian, are English, French, Spanish and Greek.
I also change the severity to "major" because, so far, the only workaround consists in renaming not only all the ODF files but also the directories appearing in their paths, which affects thousands of non-ODF files and symbolic links through NFS, so this affects even computers not concerned with the bug (not using KDE).
Ah! I understand at last. You probably mean "which desktop environment do you use?": KDE 4.8.5.
(In reply to comment #4)
> Ah! I understand at last. You probably mean "which desktop environment do you
> use?": KDE 4.8.5.
Yes, that is correct, sorry for the abbreviation.
So it does indeed seem to be the same bug as the ones in comment 1
in https://bugs.kde.org/show_bug.cgi?id=295212#c9 I read:
> libreoffice(without kde integration module) can open that file
> libreoffice(with kde integration module) can't open that file
Do you still have the same problem if you *uninstall*
(In reply to comment #5)
> Do you still have the same problem if you *uninstall*
uninstall = remove
for instance by going to a konsole and as root doing:
Ah! This solved the problem. Thank you very much.
(In reply to comment #7)
> Ah! This solved the problem. Thank you very much.
So it is definitely the upstream libreoffice-kde bug
libreoffice-22.214.171.124-0.1.mga2 is in Mageia 2 core/updates_testing, but in the changelog I don't see this got solved
So it is a Libreoffice bug, isn't it? not a KDE bug.
By the way, "mn_MN.UTF-8" is not a very good definition. It should better be "mn-Cyrl_MN.UTF-8" because Mongolian has been historically written in 10 different scripts and is currently written in 3 scripts here in independent Mongolian: Cyrillic (the official script here), Mongolian-Uighur script (vertical, official in Inner Mongolia, called "old script" in independent Mongolia, taught here to all children in junior secondary school, and used as a cultural thing, a bit like Latin in Western Europe up to the 1950's), and Latin script, used in SMS's as well as sometimes in e-mails or on the web.
Is "mn_MN.UTF-8" a KDE choice?
(In reply to comment #9)
> So it is a Libreoffice bug, isn't it? not a KDE bug.
(In reply to comment #10)
> By the way, "mn_MN.UTF-8" is not a very good definition. It should better be
> "mn-Cyrl_MN.UTF-8" because Mongolian has been historically written in 10
> different scripts and is currently written in 3 scripts here in independent
> Mongolian: Cyrillic (the official script here), Mongolian-Uighur script
> (vertical, official in Inner Mongolia, called "old script" in independent
> Mongolia, taught here to all children in junior secondary school, and used as a
> cultural thing, a bit like Latin in Western Europe up to the 1950's), and Latin
> script, used in SMS's as well as sometimes in e-mails or on the web.
> Is "mn_MN.UTF-8" a KDE choice?
No, it is based on the ISO 639-1 two-letter language codes + the ISO 3166-1 alpha-2 codes for the country
ISO 639-1 Portuguese = pt
ISO 639-1 Chinese = zh
ISO 3166-1 alpha-2 Portugal = PT
ISO 3166-1 alpha-2 Brazil = BR
ISO 3166-1 alpha-2 China = CN
ISO 3166-1 alpha-2 Taiwan = TW
pt_PT means Portuguese as it is written in Portugal
pt_BR means Portuguese as it is written in Brazil
zh_CN is simplified Chinese (as used in China)
zh_TW is traditional Chinese (as used in Taiwan)
So mn_MN is correct.
Traditional Mongolian would then be:
mn_CN (because Inner Mongolia is in China)
However the vertical-only script won't make it easy to support that locale.
Thank you. Posix language system is not as developed as the IETF standard.
How can I get the source of libreoffice-kde?
In Mageia control center â Software management â "Configure media sources for install and update", I checked the boxes "Core Release Debug (Distrib6)" and "Core Update Debug (Distrib8)", clicked on "OK", went to "Install and remove software", chose "All" and "All" in the top, searched for "libreoffice-kde" but couldn't see the source of this plugin.
this is a recurrent X11 bug; the problem is that the /usr/share/X11/locale/locale.dir file is missing entries for mn_MN.UTF-8; you have to edit them.
the problem doesn't get much attention as nowadays most programs use a higer
layer to handle locales (gdk, glib, kde...).
This only affect programs that use raw X11 locale support; mainly old and ugly
programs, or java ones.
you need in /usr/share/X11/locale/locale.dir:
and in /usr/share/X11/locale/compose.dir:
maybe when building the libx11-common rpm we should launch a script to
edit the file and add entries for all missing locales that exist in
/usr/share/locale/*.UTF-8* (and also add aliases to locale.alias
for all locales to catch the s/UTF-/utf/ variant (eg: mn_MN.utf8)
an even better would be to suggest to Xorg people to try to
fallback to "en_US.UTF-8" before going to "C" in case of unknown locale
(I reassign to libx11 as it is actually a libx11 bug; it is also arch independent and still present in cauldron)
Henri: could you try libx11-common-1.6.0-1.mga4 from Cauldron?
It should land on your favorite mirror in a couple hours
Thank you very much.
I notice I don't have this bug in Mageia 3 I installed from scratch on 2 PCs with Cyrillic Mongolian as one of the languages and many files and directories with non ASCII characters. I didn't add or remove any package for this and I notice libreoffice-kde *is* installed.
We still have 2 computers running with Mageia 2. Is your advice to install libx11-common-1.6.0-1.mga4 and to reinstall libreoffice-kde on Mageia 2 to see if it works? Do you think of back-porting libx11-common-1.6.0-1.mga4 as a patch for Mageia2?
No, I would have expected you to test libx11*1.6.0-2.mga4 (not 1.mga4) on either Cauldron or Mageia 3.
I don't understand why it would work out of the box on Mga3.
Are you running your desktop and LO in Mongolian? If yes with UTF-8 encoding?
I.e what does the report the "locale" command?
Ah! I didn't understand (or I forgot) it depends on the primary language. Sorry for that. But there is just no kde-l10n-mn package in Mageia 3... so "Mongolian" is not proposed is System settings â locale â "Country/Region and language" â languages.
And this is just because such a package doesn't exist for KDE 4.10 :
In order to get set Mongolian, just choose the language in the "system" tab in Mandriva Control Center.
Or just install another WM (eg: "urpmi task-gnome-minimal" and log in with GNOME as session)
Thank you Thierry. Mageia center's explanation "Please choose a language to use." is terse: to use for what? for whom? where? I don't understand the consequences of such a choice, specially for the other users.
It just change the language settings for the whole system.
Which can be overrided per user.
Just run localedrake as a user in a terminal and you'll be able to change the language settings only for your user
[root@arachan ~]# rpm -q libx11-common ; LC_ALL=mn_MN.UTF-8 xeyes
Warning: locale not supported by Xlib, locale set to C
[root@arachan ~]# urpmi libx11-common
[root@arachan ~]# grep mn_MN /usr/share/X11/locale/locale.dir
[root@arachan ~]# rpm -q libx11-common ; LC_ALL=mn_MN.UTF-8 xeyes
seems solved to me.
but it would be better to add those lines for *all* locales shipped by Mageia.
Maybe creating a virtual package "locales-all", empty, with a "Requires: locales-xx" line for each existing package; so that testers/developers could install them all if needed.
Then libx11.src.rpm could have a "BuildRequires: locales-all"
and just before packaging a little script that checks that for any locale matching ,/usr/share/locale/(.*\.UTF-8)/LC_CTYPE,$1, there is in the x11
locale.dir the lines
then the problem won't reapper again.
That's a little over engineered.
I'll push the patch upstream.
There're other patches waiting in FD bugzilla that we may want to get.
This message is a reminder that Mageia 2 is nearing its end of life.
Approximately one month from now Mageia will stop maintaining and issuing updates for Mageia 2. At that time this bug will be closed as WONTFIX (EOL) if it remains open with a Mageia 'version' of '2'.
Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Mageia version prior to Mageia 2's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Mageia 2 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Mageia, you are encouraged to click on "Version" and change it against that version of Mageia.
Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Mageia release includes newer upstream software that fixes bugs or makes them obsolete.
The Mageia Bugsquad
Mageia 2 changed to end-of-life (EOL) status on ''22 November''. Mageia 2 is no
longer maintained, which means that it will not receive any further security or
bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of Mageia
please feel free to click on "Version" change it against that version of Mageia
and reopen this bug.
Thank you for reporting this bug and we are sorry it could not be fixed.
The Mageia Bugsquad