How do I set locale

[karlmistelberger]

@Brahma-Vihara

I have mixed results. I used the command a couple of days, and Calligra opened with an empty page. Tried with different files that had åäö and it opened also with an empty page. I also tried the command from the same folder that file was in. Should I be expecting that calligra opens the file with the content, or is it just opening a knew file?

But, I tried the command again just now, and this time Calligra wont open. It just stalls and my cpu goes up to 100%. Something weird has happend to Calligra. It can, though, open other files that don’t contain åäö.

Try that file: http://www.mistelberger.net/Att%20g%C3%B6ra.odt Set a valid locale, such as LANG=sv_SE.utf8 or LANG=de_DE.UTF-8 and the open the file with Calligra. That works with my locale:

karl@erlangen:~> locale
LANG=de_DE.UTF-8
LC_CTYPE="de_DE.UTF-8"
LC_NUMERIC="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_COLLATE="de_DE.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_MESSAGES=de_DE.UTF-8
LC_PAPER="de_DE.UTF-8"
LC_NAME="de_DE.UTF-8"
LC_ADDRESS="de_DE.UTF-8"
LC_TELEPHONE="de_DE.UTF-8"
LC_MEASUREMENT="de_DE.UTF-8"
LC_IDENTIFICATION="de_DE.UTF-8"
LC_ALL=
karl@erlangen:~> 

[hcvv]

@Brahma-Vihara

I tried the comman locale -a and noticed that there are formats that mix regional format with english, e.g. en_DK, en_DK.UTF-8, en_IL. I’m thinking that if there is en_DK, why shouldn’t there be en_DE. In other words I’d like to propose that Yast includes these other regional formats that use en_* (as in en_DE, en_SE, en_FI etc).

https://features.opensuse.org/ might be the place to ask for this.

[Brahma-Vihara]

@I_A

but why not use en_US as locale and DE as region?
I get it that there is an en_DE locale whose reason for existence I don’t quite understand as en_US and en_UK (or en_AU) are different locales some words are spelled differently en_DE is what en_US in DE?
about the display issue in konsole I still think it’s a font issue it might be a corrupt font file or a resource bug upstream why not test it with a different font, I remember 13.2 had a missing gtk2 visual style in the default adwaita package afaik nobody reported it and it wasn’t fixed my point being file corruption does happen, a question does Dolphin or Nemo (or what ever) display the proper name of the odf document?

I switched to de_DE for regional format and kept American English as the preferred language.

I can now open the file with LibreOffice (but still not with Calligra Words) – Yay

I noticed though, that the preview info/meta-data in Dolphin shows the time format written in German, as in:

Type: OpenDocument Text
Tags: Add Tags...
Comment: Add Comment...
Creation Date: ***Montag, 2. Januar 2017***
...

The date is also formatted differently compared to having en_DE. To compare them both:

de_DE: 
Time: Sonntag, 3. September 2017
         03.09.17

en_DE:
Time: Sunday, 3 September 2017
         03/09/2017

It’s something I can live with.

Konsole issue:
Now that I have de_DE as regional format, the Konsole issue is solved, this is the result I get from ls -l

bv@linux-0xse:~> ls -l /home/bv/Documents/Att_göra.odt
-rw-r--r-- 1 bv users 11818 Jan  3  2017 /home/bv/Documents/Att_göra.odt

The only remaining issue I have now is that Calligra isn’t able to open the document. It used to be able to do it, but seems to have been affected with me changing the locales. It still can open files without åäö in the name of the file

[Brahma-Vihara]

@karlmistelberger

Try that file: http://www.mistelberger.net/Att%20göra.odt Set a valid locale, such as LANG=sv_SE.utf8 or LANG=de_DE.UTF-8 and the open the file with Calligra. That works with my locale:

karl@erlangen:~> locale
LANG=de_DE.UTF-8
LC_CTYPE="de_DE.UTF-8"
LC_NUMERIC="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_COLLATE="de_DE.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_MESSAGES=de_DE.UTF-8
LC_PAPER="de_DE.UTF-8"
LC_NAME="de_DE.UTF-8"
LC_ADDRESS="de_DE.UTF-8"
LC_TELEPHONE="de_DE.UTF-8"
LC_MEASUREMENT="de_DE.UTF-8"
LC_IDENTIFICATION="de_DE.UTF-8"
LC_ALL=
karl@erlangen:~> 

Wow, your fast

I downloaded the file and it worked like a charm. I could open it with Calligra while having de_DE as locale.
I went back to my own file, opened it with LibreOffice, did a random change and saved the document. After that, I could open it with Calligra. rotfl!
I tried the same procedure with another file that I’ve been testing during this time, but this time Calligra stalled again.

I tried to open other files and could open them all, not just odt-files with Calligra, but also mp4, jpeg, and could open them all. So, I assume that not being able to open one file is because of some corruption with that file. Since I can open it with LO, I’m quite happy.

Sooo, thank you all for the amazing help!

[deano_ferrari]

For now I guess it can just be compiled manually. I took the definition Henk linked to in post#10, and created /usr/share/i18n/locales/en_DE

then did

localedef -f UTF-8 -i en_DE en_DE.UTF-8

[Brahma-Vihara]

@hcvv

https://features.opensuse.org/ might be the place to ask for this.

Great, I’ll do that

[Brahma-Vihara]

@deano_ferrari

For now I guess it can just be compiled manually. I took the definition Henk linked to in post#10, and created /usr/share/i18n/locales/en_DE

then did

localedef -f UTF-8 -i en_DE en_DE.UTF-8

Nice! So, what do I need to do. How do I compile it manually?

[deano_ferrari]

@Brahma-Vihara

Nice! So, what do I need to do. How do I compile it manually?

I created the file (/usr/share/i18n/locales/en_DE) with the definition from here and ran localedef as already explained.

[karlmistelberger]

@deano_ferrari

I created the file (/usr/share/i18n/locales/en_DE) with the definition from here and ran localedef as already explained.

Got an error on my system:

erlangen:~ # localedef -f UTF-8 -i en_DE en_DE.UTF-8
LC_IDENTIFICATION: unknown standard `en_DE:2000' for category `LC_CTYPE'
LC_IDENTIFICATION: unknown standard `en_DE:2000' for category `LC_NUMERIC'
LC_IDENTIFICATION: unknown standard `en_DE:2000' for category `LC_TIME'
LC_IDENTIFICATION: unknown standard `en_DE:2000' for category `LC_COLLATE'
LC_IDENTIFICATION: unknown standard `en_DE:2000' for category `LC_MONETARY'
LC_IDENTIFICATION: unknown standard `en_DE:2000' for category `LC_MESSAGES'
LC_IDENTIFICATION: unknown standard `en_DE:2000' for category `LC_PAPER'
LC_IDENTIFICATION: unknown standard `en_DE:2000' for category `LC_NAME'
LC_IDENTIFICATION: unknown standard `en_DE:2000' for category `LC_ADDRESS'
LC_IDENTIFICATION: unknown standard `en_DE:2000' for category `LC_TELEPHONE'
LC_IDENTIFICATION: unknown standard `en_DE:2000' for category `LC_IDENTIFICATION'
no output file produced because warnings were issued
erlangen:~ # 

From file /usr/share/i18n/locales/en_DK of package glibc-i18ndata-2.26-1.1.noarch I guessed the following command:

erlangen:~ # sed -i 's,en_DE:2000,i18n:2012,g' /usr/share/i18n/locales/en_DE
erlangen:~ # 

After performing this change localedef generated locale en_DE.UTF-8. However messages are still german:

karl@erlangen:~> locale
LANG=en_DE.UTF-8
LC_CTYPE="en_DE.UTF-8"
LC_NUMERIC="en_DE.UTF-8"
LC_TIME="en_DE.UTF-8"
LC_COLLATE="en_DE.UTF-8"
LC_MONETARY="en_DE.UTF-8"
LC_MESSAGES=**de**_DE.UTF-8
LC_PAPER="en_DE.UTF-8"
LC_NAME="en_DE.UTF-8"
LC_ADDRESS="en_DE.UTF-8"
LC_TELEPHONE="en_DE.UTF-8"
LC_MEASUREMENT="en_DE.UTF-8"
LC_IDENTIFICATION="en_DE.UTF-8"
LC_ALL=
karl@erlangen:~> 

Any idea how to start from http://cldr.unicode.org/ ?

[wolfi323]

@hcvv

https://features.opensuse.org/ might be the place to ask for this.

Right.

This is rather an upstream “problem” though I think. The locale definitions (in /usr/lib/locale/) are part of glibc (package glibc-locale), and they haven’t added en_DE and the like yet, as can be seen in the upstream git repo:
https://sourceware.org/git/?p=glibc.git;a=tree;f=localedata/locales;h=085447ef0541f3790f46e76e751949a0a1a47701;hb=refs/heads/master

[karlmistelberger]

@deano_ferrari

For now I guess it can just be compiled manually. I took the definition Henk linked to in post#10, and created /usr/share/i18n/locales/en_DE

then did

localedef -f UTF-8 -i en_DE en_DE.UTF-8

Finally I tried:

erlangen:~ # cp /usr/share/i18n/locales/de_DE /usr/share/i18n/locales/en_DE
erlangen:~ # localedef -f UTF-8 -i en_DE en_DE.UTF-8
erlangen:~ # 

These two commands create the locale en_DE.UTF-8 without the need for further tinkering.

[Brahma-Vihara]

@wolfi323

Right.

This is rather an upstream “problem” though I think. The locale definitions (in /usr/lib/locale/) are part of glibc (package glibc-locale), and they haven’t added en_DE and the like yet, as can be seen in the upstream git repo:
sourceware.org Git - glibc.git/tree - localedata/locales/

So, it would be better to file a request in the glibc community? Do you know where I can do that? I clicked on the link but couldn’t find a forum of any kind.

[Brahma-Vihara]

@karlmistelberger

Finally I tried:

erlangen:~ # cp /usr/share/i18n/locales/de_DE /usr/share/i18n/locales/en_DE
erlangen:~ # localedef -f UTF-8 -i en_DE en_DE.UTF-8
erlangen:~ # 

These two commands create the locale en_DE.UTF-8 without the need for further tinkering.

My system doesn’t have a i18n-folder. This is what I get:

ls -la /usr/share
total 1048
<...snip - I copied from h to j just to show that there is no i18n ...>
drwxr-xr-x 1 root root       8 Aug 25 23:37 hydrogen
drwxr-xr-x 1 root root      78 Aug 26 13:28 hyphen
drwxr-xr-x 1 root root      18 Oct 26  2014 ibus
drwxr-xr-x 1 root root      94 Aug 29 22:48 icedtea-web
drwxr-xr-x 1 root root      82 Jul 24 15:50 icewm
drwxr-xr-x 1 root root     382 Aug 29 22:54 icons
drwxr-xr-x 1 root root      24 Aug 24 18:15 icu
drwxr-xr-x 1 root root      12 Aug 12 20:48 idnkit
drwxr-xr-x 1 root root       8 Aug 25 01:04 importwizard
drwxr-xr-x 1 root root    2100 Sep  3 10:45 info
drwxr-xr-x 1 root root       8 Aug 25 22:48 iso-codes
drwxr-xr-x 1 root root       0 Aug 25 22:43 ivy-xmls
drwxr-xr-x 1 root root     970 Aug 29 22:48 java
drwxr-xr-x 1 root root       0 Aug 25 22:43 javadoc
...snip...

In /usr/share there are local and local-bundle, but they contain the following

ls -la /usr/share/locale
...snip...
drwxr-xr-x 1 root root   4532 Aug 29 22:54 currency
drwxr-xr-x 1 root root     22 Aug 27 20:52 cy
drwxr-xr-x 1 root root     70 Aug 27 20:52 da
drwxr-xr-x 1 root root     90 Aug 27 20:52 de
drwxr-xr-x 1 root root     22 Jun 23 09:22 de_AT
drwxr-xr-x 1 root root     22 Jun 23 09:22 de_CH
drwxr-xr-x 1 root root     22 Jun 23 09:22 de_DE
drwxr-xr-x 1 root root     22 Jun 23 09:22 dz
drwxr-xr-x 1 root root     70 Aug 27 20:52 el
drwxr-xr-x 1 root root     22 Jun 23 09:22 el_GR
drwxr-xr-x 1 root root     22 Jun 23 09:22 en
drwxr-xr-x 1 root root     22 Jun 23 09:22 en_AU
drwxr-xr-x 1 root root     22 Jun 23 09:22 en@boldquot
drwxr-xr-x 1 root root     22 Jun 23 09:22 en_CA
drwxr-xr-x 1 root root     56 Aug 27 20:52 en_GB
drwxr-xr-x 1 root root     22 Jun 23 09:22 en@IPA
drwxr-xr-x 1 root root     22 Jun 23 09:22 en_NZ
drwxr-xr-x 1 root root     22 Jun 23 09:22 en@quot
drwxr-xr-x 1 root root     22 Jun 23 09:22 en@shaw
drwxr-xr-x 1 root root     82 Aug 29 22:51 en_US
drwxr-xr-x 1 root root     70 Aug 27 20:52 eo
drwxr-xr-x 1 root root     90 Aug 27 20:52 es
...snip...

The content of a folder like en_US is:

-rw-r--r-- 1 root root 2157 Aug 26 01:16 entry.desktop
-rw-r--r-- 1 root root 1163 Aug  6 19:58 kf5_entry.desktop
drwxr-xr-x 1 root root  282 Sep  3 10:44 LC_MESSAGES

The locale-bundle is similar, except that it has even fewer folders.

I didn’t try adding an en_DE file in the locale-folder since I have a feeling it’s not where it belongs.

[karlmistelberger]

@Brahma-Vihara

My system doesn’t have a i18n-folder.

Sorry, I missed a step I already performed earlier. Install glibc-i18ndata. I have:

erlangen:~ # rpm -qf /usr/share/i18n/locales/de_DE
glibc-i18ndata-2.26-1.1.noarch
erlangen:~ # 

Then perform the steps already described:

erlangen:~ # cp /usr/share/i18n/locales/de_DE /usr/share/i18n/locales/en_DE
erlangen:~ # localedef -f UTF-8 -i en_DE en_DE.UTF-8
erlangen:~ #

[wolfi323]

@Brahma-Vihara

So, it would be better to file a request in the glibc community?

Might be an option.

You can file a feature request for openSUSE, and the maintainer may decide to add it and/or push it upstream too, but it might just as well get ignored/overlooked…

Do you know where I can do that? I clicked on the link but couldn’t find a forum of any kind.

https://www.gnu.org/software/libc/

@Brahma-Vihara

In /usr/share there are local and local-bundle, but they contain the following
…
I didn’t try adding an en_DE file in the locale-folder since I have a feeling it’s not where it belongs.

No. /usr/share/locale (and /usr/share/locale-bundle) contain actual translations…

/usr/share/i18n/ is part of the package glibc-i18ndata, which you may have to install manually.

[tannington]

I’ve been trying to get the custom locale settings that I require for a while now.

Finally achieved (or bodged) it…

What I needed was en_GB with ISO short date format, 24hr time indication, and metric units.

Easy, I thought… I’ll just modify the relevant LC_* files for en_GB.

Using information from here (Locale Helper) https://lh.2xlibre.net/ it was quite easy to then use okteta to modify LC_TIME. Interestingly LC_MEASUREMENT was set to metric, although (KDE) “System Settings - Regional Settings - Formats” indicated imperial units, which was indeed what KDE was using.

Logout, reboot and login… No change, still date format of dd/mm/yyyy and imperial units.

“locale -k LC_TIME” and “locale -k LC_MEASUREMENT” both indicated that the formats where as I’d changed them to: yyyy-mm-dd and metric units.

Non KDE applications, GIMP’s file chooser for example, correctly showed the ISO format.

Google time… It seems that KDE/Qt doesn’t actually use the locale files of glibc…

Quote from: Locale Support in Qt 5 - Qt Wiki

… On all other platforms, such as Linux and Android, Qt’s built-in CLDR-based facilities are always used. …

Looking through the various options offered by (KDE) “System Settings - Regional Settings - Formats - Detailed Settings - Time (and Measurement Units)” it looked as if en_SE may give me the desired effect.

Changing those in KDE resulted in KDE applications having the formats I required, but not non-KDE applications. There is currently no (glibc) en_SE locale.

Bodge: Copy the modified en_GB locale I’d previously created and name it as en_SE…

Logout, reboot and login… Success, both KDE and non KDE applications now display ISO short date format, I have 24hr display of time, and metric units.

http://paste.opensuse.org/view/raw/363d1adc

There really should be an easier way…

Now to do the same for a leap 42.3 setup… err… earlier Qt version, doesn’t have en_SE, or indeed at a quick glance through, any locale that will give me what I need… Bother!

[karlmistelberger]

@tannington

I’ve been trying to get the custom locale settings that I require for a while now.

Finally achieved (or bodged) it…

What I needed was en_GB with ISO short date format, 24hr time indication, and metric units.

Easy, I thought… I’ll just modify the relevant LC_* files for en_GB.

Using information from here (Locale Helper) https://lh.2xlibre.net/ it was quite easy to then use okteta to modify LC_TIME. Interestingly LC_MEASUREMENT was set to metric, although (KDE) “System Settings - Regional Settings - Formats” indicated imperial units, which was indeed what KDE was using.

Logout, reboot and login… No change, still date format of dd/mm/yyyy and imperial units.

“locale -k LC_TIME” and “locale -k LC_MEASUREMENT” both indicated that the formats where as I’d changed them to: yyyy-mm-dd and metric units.

Non KDE applications, GIMP’s file chooser for example, correctly showed the ISO format.

Google time… It seems that KDE/Qt doesn’t actually use the locale files of glibc…

Quote from: Locale Support in Qt 5 - Qt Wiki

Looking through the various options offered by (KDE) “System Settings - Regional Settings - Formats - Detailed Settings - Time (and Measurement Units)” it looked as if en_SE may give me the desired effect.

Changing those in KDE resulted in KDE applications having the formats I required, but not non-KDE applications. There is currently no (glibc) en_SE locale.

Bodge: Copy the modified en_GB locale I’d previously created and name it as en_SE…

Logout, reboot and login… Success, both KDE and non KDE applications now display ISO short date format, I have 24hr display of time, and metric units.

http://paste.opensuse.org/view/raw/363d1adc

There really should be an easier way…

Now to do the same for a leap 42.3 setup… err… earlier Qt version, doesn’t have en_SE, or indeed at a quick glance through, any locale that will give me what I need… Bother!

Try the following:

erlangen:~ # **zypper in glibc-i18ndata**
Loading repository data...
Reading installed packages...
'glibc-i18ndata' is already installed.
No update candidate for 'glibc-i18ndata-2.26-2.1.noarch'. The highest available version is already installed.
Resolving package dependencies...

Nothing to do.
erlangen:~ # **cp /usr/share/i18n/locales/sv_SE /usr/share/i18n/locales/en_SE**
erlangen:~ # **localedef -f UTF-8 -i en_SE en_SE.UTF-8**
erlangen:~ # 

[tannington]

@karlmistelberger

Try the following:

Sorry. As a solution to what? The “bodged” fix works OK on TW, I’m quite content to leave that.

On Leap with the lower version of Qt, it’s Qt’s lack of support for en_SE that prevents me doing similar.

Or am I just being exceptionally thick this morning

[karlmistelberger]

@tannington

Sorry. As a solution to what? The “bodged” fix works OK on TW, I’m quite content to leave that.

Sure. However your wording:

There really should be an easier way…

caused me to point to an easier way for those who want to create a new locale.

On Leap with the lower version of Qt, it’s Qt’s lack of support for en_SE that prevents me doing similar. Or am I just being exceptionally thick this morning
Well, the above works with any locale (set of language, territory and character encoding) and with any system that has glibc installed. Just in case of issues with Plasma: Make sure the locale is set correctly:

karl@erlangen:~> grep -C 3 LANG .config/plasma-localerc                                                                                                                                                                       
[Formats]                                                                                                                                                                                                                       
LANG=en_SE.UTF-8
karl@erlangen:~>

[tannington]

@karlmistelberger

Sure. However your wording:

"There really should be an easier way… "

caused me to point to an easier way for those who want to create a new locale.

I did, that is quite correct, however quoting my entire post didn’t make it particularly obvious what your reply was addressing.

Well, the above works with any locale (set of language, territory and character encoding) and with any system that has glibc installed. Just in case of issues with Plasma: Make sure the locale is set correctly:

I notice from your signature you’re using TW, on which, yes that works, provided en_SE is present in /usr/lib/locale/

However, it won’t currently work with Leap 42.3, because Qt 5.6.2 does not have support for en_SE within it’s embedded CLDR data.

http://paste.opensuse.org/view/raw/4278d7be

Qt does not use the locale definitions from /usr/lib/locale/

From: Locale Support in Qt 5 - Qt Wiki

Date/Time Localization

Current QLocale support is as follows:

Host system data is used for Mac and Windows System Locales
Qt's copy of CLDR data is used for system locales on all other platforms,
and for all custom locales on all platforms.
All date parsing is done by Qt's own code, no host or standard library code
is used.
All custom date formatting (dd-MMM-yyyy etc) is done by Qt's own code,
no host or standard library code is used.
Fixed format date formatting (LongDate, ShortDate, etc) is done by the host
on Mac and Windows, and Qt's own code on all other platforms and custom
locales.

I can install en_SE.utf8 to /usr/lib/locale/ and then manually edit “plasma-locale-settings.sh” and “plasma-localerc” to use en_SE for LC_TIME … it makes no difference to KDE/Qt applications, as Qt’s copy of CLDR data does not include data for en_SE

Quoting a further couple of sections from the Qt Locale Support wiki:

Custom Locale: An application can create any custom locale supported by the CLDR data embedded in QtCore which is then used by Qt’s internal code routines. These may or may not match the host’s available locales.

A major issue that needs solving is user customizations on UNIX desktop platforms. This is of particular interest to KDE developers.

Currently if a UNIX user wishes to customize their locale settings, they are restricted to changing the locale code used for a group of functionality. For example, if a en_GB user wants to always use the ISO date format instead of the default, they need to set LC_TIME to a locale code that has an ISO date format, but otherwise has all the other settings the same as en_GB. This can be hard to find, and may not even exist. Such changes also do not take effect globally until the user has logged out and back in again.

Qt are well aware of the problem, but as yet there is no real solution.

So on Leap it’s going to be a while I guess before I can implement what I need, however that may be done.

Thanks.