In a more and more globalizing world more and more people want to use special language settings and modify them again to there needs. This requires that SW application can be easily adopted to their own default customization.
My example: I am a German native speaker, very familiar with English language interfaces but not with German, living in Japan and working in an international environment, thus need to use international best understood number, date, etc. formats .
Fortunately in Windows XP (W7 and W8 I don't know) I can set
- User interface: English US
- Decimal symbols to dot (ISO)
- Digit grouping to space (ISO)
- Measurement systems to metric
In LibO there is the possibility to set in Options./ Languages the "decimal separator key" to "same as local settings" and have event the selected symbol displayed. This is very good!
For all my work I I would be very happy - because I don't need to change formats that often - if all the local setting of windows can be taken over with setting of check marks.
Enable LibO to take local settings from the Windows regional settings by providing check boxes as done for "decimal separator key".
Other OS: I cannot comment as I not familiar with the way formats for numbers and dates etc are handled there.
Operating System: All
Version: 188.8.131.52 release
feature request. current regional settings is inherited from OOo.
set status to NEW and changed version field.
(In reply to comment #0)
> Enhancement request:
> Enable LibO to take local settings from the Windows regional settings by
> providing check boxes as done for "decimal separator key".
So that would do the same as, but handle in stead of, te current listbox "Locale setting" ?
If I understand you right my answer is YES.
If is is possible to make one check mark for taking over the regional settings it would be fine.
In LibO there is the word "local setting" which sounds to me like the "regional settings" in windows.
Another alternative would be make all format settings in LibO independent of the language setting. This possibility would also have its own charm because it would then be even independent of the OS.
Which one is easier to be realized? I neither can read the source code nor can comment on it - Sorry!
set status back to NEW. clear description provided.
(In reply to bugquestcontri from comment #0)
> In LibO there is the possibility to set in Options./ Languages the "decimal
> separator key" to "same as local settings" and have event the selected
> symbol displayed. This is very good!
> For all my work I I would be very happy - because I don't need to change
> formats that often - if all the local setting of windows can be taken over
> with setting of check marks.
"Decimal Separator key - Same as locale setting" does not mean "use decimal separator as defined in system". Instead, it means "when user presses numpad "." button, should LibreOffice insert the character that system sends to the application (option unchecked) or the character defined in the locale *used in LibreOffice* as decimal separator (option checked)" . Note that this results in different *text* being entered into the place where current edit is performed; and what happens with that *text* later is unrelated to the setting: LibreOffice will then treat the string using its normal processing, and if the resulting string does not form a valid number in the locale used in LibreOffice, it will rightfully *not* become a number then.
*** Bug 128327 has been marked as a duplicate of this bug. ***
*** Bug 123878 has been marked as a duplicate of this bug. ***
(In reply to Buovjaga from comment #7)
> *** Bug 123878 has been marked as a duplicate of this bug. ***
I'd like to point out, since it isn't mentioned so far in this thread, that my reason for logging bug 123878 originally was because of how LO is parsing numeric literals.
Brace yourself, this gets confusing...
My complaint is that for me, numbers with decimal places, LO does not interpret a period as the decimal point; it expects a comma instead.
So for example, the string "123.4" (with a period) gets treated as zero when used in a formula. However, the string "123,4" gets treated correctly (i.e. as a tenth of 1234)
Now on the one hand, this is arguably correct, given that my OS locale is South Africa, where the _standard_ decimal separator is indeed a comma.
However in the OS settings I have _changed_ the decimal separator to a period, and LO isn't picking that up.
Yet in the LO preferences, the locale _there_ is English (UK), where I'm pretty sure the decimal separator is a period.
So it's not clear to me where LO's idea of the comma as decimal separator is coming from.
But regardless of that, IMHO LO should actually *ignore* the regional settings when parsing numeric literals. My reasoning is:
(1) it makes numeric literals in macros and formulae locale-independent
(2) it's consistent with OpenOffice and MS Office behaviour
(3) it plays nice with Calc, because cell values are extracted with decimal _periods_ even with my locale settings.
FWIW, I logged that bug after migrating from OO to LO.
I have a Writer template with calculations that failed in LO because it contained numbers with decimal periods (not commas). Changing the periods to commas fixed the calculations.
That template also has a macro that extracts a cell value from a spreadsheet and uses it in a formula. The formula failed for the same reason: the extracted value (which was truly a number, not s string) is converted implicitly by LO to a string, with a decimal _period_. Calculations with that value fail unless the period is replaced with a comma.
OK finally, FYI: there's an attachment to bug 123878 with a minimal demo of the calculation problem in a Writer template.
*** Bug 129873 has been marked as a duplicate of this bug. ***