There is some interesting information here:

https://www.libreoffice.org/bugzilla/show_bug.cgi?id=42362
https://bugs.kde.org/show_bug.cgi?id=295212

which DE do you use?

CC: (none) => dmorganec, marja11

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).

Severity: normal => major

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*
libreoffice-kde
?

(In reply to comment #5)

> 
> Do you still have the same problem if you *uninstall*
> libreoffice-kde
> ?

uninstall = remove

for instance by going to a konsole and as root doing:

urpme libreoffice-kde

Ah! This solved the problem. Thank you very much.

(In reply to comment #7)
> Ah! This solved the problem. Thank you very much.

Great :)

So it is definitely the upstream libreoffice-kde bug

libreoffice-3.5.6.2-0.1.mga2 is in Mageia 2 core/updates_testing, but in the changelog I don't see this got solved

Keywords: NEEDINFO => UPSTREAM
See Also: (none) => https://www.libreoffice.org/bugzilla/show_bug.cgi?id=42362

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.
http://www.iana.org/assignments/language-subtag-registry
http://en.wikipedia.org/wiki/Mongolian_alphabets
http://echo.mpiwg-berlin.mpg.de/content/buddhism/mongolscript
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.

Yes, indeed.

(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.
> http://www.iana.org/assignments/language-subtag-registry
> http://en.wikipedia.org/wiki/Mongolian_alphabets
> http://echo.mpiwg-berlin.mpg.de/content/buddhism/mongolscript
> 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

for instance:
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

So:
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:
en_US.UTF-8/XLC_LOCALE           mn_MN.UTF-8
en_US.UTF-8/XLC_LOCALE:          mn_MN.UTF-8

and in /usr/share/X11/locale/compose.dir:
en_US.UTF-8/Compose              mn_MN.UTF-8
en_US.UTF-8/Compose:             mn_MN.UTF-8

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)

CC: (none) => pablo
Hardware: x86_64 => All
Source RPM: libreoffice-3.5.5.3-0.3.mga2.src.rpm => libx11-1.5.0-4.mga3.src.rpm

Henri: could you try libx11-common-1.6.0-1.mga4 from Cauldron?
It should land on your favorite mirror in a couple hours

Keywords: (none) => NEEDINFO, PATCH
CC: (none) => thierry.vignaud

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.

$ locale
LANG=en_GB.UTF-8
LC_CTYPE=en_GB.UTF-8
LC_NUMERIC=mn_MN.UTF-8
LC_TIME=en_GB.UTF-8
LC_COLLATE=en_GB.UTF-8
LC_MONETARY=mn_MN.UTF-8
LC_MESSAGES=en_GB.UTF-8
LC_PAPER=mn_MN.UTF-8
LC_NAME=mn_MN.UTF-8
LC_ADDRESS=mn_MN.UTF-8
LC_TELEPHONE=mn_MN.UTF-8
LC_MEASUREMENT=mn_MN.UTF-8
LC_IDENTIFICATION=mn_MN.UTF-8

And this is just because such a package doesn't exist for KDE 4.10 :
http://i18n.kde.org/team-infos.php?teamcode=mn

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
libx11-common-1.6.0-1.mga4
Warning: locale not supported by Xlib, locale set to C
^C
[root@arachan ~]# urpmi libx11-common
[root@arachan ~]# grep mn_MN /usr/share/X11/locale/locale.dir
en_US.UTF-8/XLC_LOCALE			mn_MN.UTF-8
en_US.UTF-8/XLC_LOCALE:			mn_MN.UTF-8
[root@arachan ~]# rpm -q libx11-common ; LC_ALL=mn_MN.UTF-8 xeyes
libx11-common-1.6.0-2.mga4
^C

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

en_US.UTF-8/XLC_LOCALE   $1
en_US.UTF-8/XLC_LOCALE:  $1

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

Status: NEW => RESOLVED
Resolution: (none) => OLD