[upstream] Libreoffice always uses "letter" paper

[Benji]

For new documents, libreoffice chooses always "letter" paper. It is expected, that documents are in A4 paper, because the locale ist set to de_DE.UTF-8.

LibreOffice settings:
Tools --> Options --> Language Settings --> Languages --> Locale stting: Default - German (Germany)

The locale settings are:
> locale
LANG=en_US.UTF-8
LANGUAGE=
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=en_US.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=

LibreOffice Version:
> apt-cache policy libreoffice
libreoffice:
  Installed: 1:3.5.4-0ubuntu1.1
  Candidate: 1:3.5.4-0ubuntu1.1

[H-m-brand (h-m-brand)]

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.

[Vstuart-foote (vstuart-foote)]

@Eike?

[Eike Rathke (erack)]

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.

[Mikeus (mikeus)]

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

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Rolf Leggewie (r0lf)]

I can verify this even in boinic

[Rolf Leggewie (r0lf)]

FWIW, I do have libpaper-utils and thus paperconf installed. This utility was mentioned in the upstrem ticket.

[Thb-b (thb-b)]

@eike is bits and pieces of this doable as an easy hack? any code ptrs for Tux perhaps?

[Eike Rathke (erack)]

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

[ojb (olejorgenb)]

+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 :/)

[Eike Rathke (erack)]

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

[Jaap Versteegh (j-r-versteegh)]

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.