LibreOffice completely ignores all deviations from defaults to a $LANG as the system stored in LC_ALL, LC_PAPER, LC_TIME, etc For my work I want most of en_US.utf8, but e.g. *NEVER* paper size Letter of date format M/D/Y, so my (changed) system locales are $ echo $LANG en_US.UTF-8 $ echo $LC_ALL $ env | grep LC_ $ locale -ck LC_PAPER LC_PAPER height=297 width=210 paper-codeset="UTF-8" $ locale -ck LC_NUMERIC LC_NUMERIC decimal_point="." thousands_sep="," grouping=3;3 numeric-decimal-point-wc=46 numeric-thousands-sep-wc=44 numeric-codeset="UTF-8" $ locale -ck LC_TIME LC_TIME abday="Sun;Mon;Tue;Wed;Thu;Fri;Sat" day="Sunday;Monday;Tuesday;Wednesday;Thursday;Friday;Saturday" abmon="Jan;Feb;Mar;Apr;May;Jun;Jul;Aug;Sep;Oct;Nov;Dec" mon="January;February;March;April;May;June;July;August;September;October;November;December" am_pm="AM;PM" d_t_fmt="%a %d %b %Y %R %Z" d_fmt="%d-%m-%Y" t_fmt="%R" t_fmt_ampm="%H:%M:%S" era= era_year="" era_d_fmt="" alt_digits= era_d_t_fmt="" era_t_fmt="" time-era-num-entries=0 time-era-entries="S" week-ndays=7 week-1stday=19971130 week-1stweek=7 first_weekday=1 first_workday=2 cal_direction=1 timezone="" date_fmt="%a %e %b %Y %H:%M:%S" time-codeset="UTF-8" $ locale -ck LC_ADDRESS LC_ADDRESS postal_fmt="%f%N%a%N%d%N%b%N%s %h %e %r%N%z %T%N%c%N" country_name="" country_post="" country_ab2="NL" country_ab3="NLD" country_car="NL" country_num=528 country_isbn="" lang_name="Nederlands" lang_ab="nl" lang_term="nld" lang_lib="dut" address-codeset="UTF-8" $ locale -ck LC_MEASUREMENT LC_MEASUREMENT measurement=1 measurement-codeset="UTF-8" $ locale -ck LC_MONETARY LC_MONETARY int_curr_symbol="EUR " currency_symbol="€" mon_decimal_point="," mon_thousands_sep=" " mon_grouping=3;3 positive_sign="" negative_sign="-" int_frac_digits=2 frac_digits=2 p_cs_precedes=1 p_sep_by_space=1 n_cs_precedes=1 n_sep_by_space=1 p_sign_posn=1 n_sign_posn=2 crncystr="-€" int_p_cs_precedes=1 int_p_sep_by_space=1 int_n_cs_precedes=1 int_n_sep_by_space=1 int_p_sign_posn=1 int_n_sign_posn=2 duo_int_curr_symbol="EUR " duo_currency_symbol="€" duo_int_frac_digits=2 duo_frac_digits=2 duo_p_cs_precedes=1 duo_p_sep_by_space=1 duo_n_cs_precedes=1 duo_n_sep_by_space=1 duo_int_p_cs_precedes=1 duo_int_p_sep_by_space=1 duo_int_n_cs_precedes=1 duo_int_n_sep_by_space=1 duo_p_sign_posn=1 duo_n_sign_posn=2 duo_int_p_sign_posn=1 duo_int_n_sign_posn=2 uno_valid_from=10101 uno_valid_to=99991231 duo_valid_from=10101 duo_valid_to=99991231 conversion_rate=1;1 monetary-decimal-point-wc=44 monetary-thousands-sep-wc=32 monetary-codeset="UTF-8" And NONE of those deviations are respected, making my developer life harder. This is not new. I reported this back in 2009 to the OpenOffice team, and no action was taken whatsoever. I just hope filing this ticket might help. This is the case in all LibreOffice versions I have access to.
@Eike?
Known, the locale data is taken from a fixed set and can be influenced only very little. The LC_CTYPE locale if present determines the general locale data setting. The LC_MESSAGES locale if present determines the UI language. For paper configuration, if the LibreOffice locale under Tools->Options->LanguageSettings->Languages is set to Default then the libpaper paperconf utility is probed (which itself takes several sources into account, see man paperconf), if that is not available or the paper can't be determined from it then LC_PAPER width and height should be taken. However, this nicely fits bug 46448 for which some presets of the configurable locale data should be taken of LC_* settings if available. Adding as related.
I would also note that LibreOffice ignores not only alterations made with LC_* variable assignments but also manually compiled locale definition files with category keyword values differing from those LibreOffice considers right for that language. I have slightly tuned ru_RU.utf8 locale definitions to use a point as a decimal separator, compiled it and set it as my current locale. LibreOffice keeps ignore locale settings with suggesting a comma as a decimal point. $ locale LANG=ru_RU.utf8 LC_CTYPE="ru_RU.utf8" LC_NUMERIC="ru_RU.utf8" LC_TIME="ru_RU.utf8" LC_COLLATE="ru_RU.utf8" LC_MONETARY="ru_RU.utf8" LC_MESSAGES="ru_RU.utf8" LC_PAPER="ru_RU.utf8" LC_NAME="ru_RU.utf8" LC_ADDRESS="ru_RU.utf8" LC_TELEPHONE="ru_RU.utf8" LC_MEASUREMENT="ru_RU.utf8" LC_IDENTIFICATION="ru_RU.utf8" LC_ALL= $ locale -ck LC_NUMERIC LC_NUMERIC decimal_point="." thousands_sep=" " grouping=3;3 numeric-decimal-point-wc=46 numeric-thousands-sep-wc=8239 numeric-codeset="UTF-8" Custom user-defined system locales (e.g. en_RU.utf8 - "Engilsh locale for Russia") also are not recognized by LibreOffice's "Language of locale setting" chooser - the option falls back to "Default - en".
@eike is bits and pieces of this doable as an easy hack? any code ptrs for Tux perhaps?
Not an easy hack. We'll need some system locale layer first in that the fixed locale settings and (user) system locale settings can be merged without breaking all kind of number parsing/formatting things (which bug 46448 actually is about).
+1 (Sorry for this "me too" comment, but I can't find any vote-like feature. In Norway the official decimal separator is ",", which as a programmer is unacceptable. I thus use a US locale on my system, but this brings along the horribe (IMO) US date format. Fixed by using the en_DK.UTF8 locale which adjust the date and first-day-of-week. Unfortunately libreoffice does not pick this up :/)
The en-DK locale data was added already for 7.2, see https://wiki.documentfoundation.org/ReleaseNotes/7.2#New_languages.2Flocales_with_locale_data Picked up from LC_CTYPE=en_DK.UTF-8
Why would you not respect the system's LC_NUMERIC settings?? Yes, I live in the netherlands and want most settings like currency and dates in dutch, but I DON'T WANT A COMMA AS DECIMAL SEPARATOR! It's not just that libreoffice ignores LC_NUMERIC, but I can now no longer find a way to set a period as decimal separator at all. 1. Respect a user's LC_NUMERIC setting 2. If you decide not to do so, at least allow an easy setting in the application. This has been an issue for forever and it only appears to get worse! Fix this already.