Arkusz kalkulacyjny, locale i kropka/przecinek

[AMX]

Pod linux'em dostępnych jest parę arkuszy kalkulacyjnych, choćby
gnumeric czy LibreOffice Calc.

Nie używam ich (bądź używam niechętnie) bo separatorem
dziesiętnym jest "," (przynajmniej) w pl_PL a ja potrzebuję ".".

Teoretycznie odpowiednie ustawienia locale powinny sprawę
załatwić ale gdy miałem ustawione LC_NUMERIC="C" to arkusze
wstawiały przecinek, przestawiłem na en_US i dalej to samo.

Pozostałe LC mam ustawione na "C" za wyjątkiem:
LC_CTYPE=pl_PL
LC_COLLATE=pl_PL

Jak zmusić arkusz do akceptowania kropki?

AMX

--
adres w rot13
Nyrxfnaqre Znghfmnx r-...@b2.cy

[Wiesiaczek]

W dniu 29.03.2017 o 17:03, AMX pisze:

Problem sam w sobie może ciekawy, ale nie łapię sensu takiej zmiany.
Jeśli posługujesz się arkuszem kalkulacyjnym na jednym komputerze to
sprawa jest chyba bezprzedmiotowa.
Jeśli wymieniasz arkusze z innymi, to powinieneś mieć ten sam system
znaków co inni.
W Polsce jest przyjęty przecinek i z Twoim Linuksem jest wszystko ok.

Dowolność zmiany kropki i przecinka doprowadziłaby szybko do totalnego
bałaganu.

Czy w Windowsach jest to jakoś rozwiązane?

--
Wiesiaczek (dziś z DC)

"Ja piję tylko przy dwóch okazjach:
Gdy są ogórki i gdy ich nie ma" ®

[marrgol]

On 2017-03-29 at 17:03, AMX wrote:
> Pod linux'em dostępnych jest parę arkuszy kalkulacyjnych, choćby
> gnumeric czy LibreOffice Calc.
>
> Nie używam ich (bądź używam niechętnie) bo separatorem
> dziesiętnym jest "," (przynajmniej) w pl_PL a ja potrzebuję ".".
>
> Teoretycznie odpowiednie ustawienia locale powinny sprawę
> załatwić ale gdy miałem ustawione LC_NUMERIC="C" to arkusze
> wstawiały przecinek, przestawiłem na en_US i dalej to samo.

> […]

> Jak zmusić arkusz do akceptowania kropki?

Nie wiem, jak ty to sprawdzałeś.
Z ciekawości sam sprawdziłem i, przynajmniej w wersji 1.12.23, gnumeric
stosuje się do lokalizacyjnych zmiennych środowiskowych.

Calc ma opcje lokalizacyjne w swoich własnych ustawieniach - m.in.
może, ale nie musi, uwzględniać lokalizację systemową lub użytkownika.
Patrz menu Narzędzia->Opcje->Ustawienia Językowe->Języki
(i ->Pomoc, czyli RTFM ;-) ).


--
mrg

[marrgol]

On 2017-03-29 at 17:32, Wiesiaczek wrote:
> Problem sam w sobie może ciekawy, ale nie łapię sensu takiej zmiany.

Ja też wolę kropkę - kwestia przyzwyczajenia prawdopodobnie.

> Jeśli wymieniasz arkusze z innymi, to powinieneś mieć ten sam system
> znaków co inni.

Informacja o tym jest zapisana w pliku arkusza w sposób jednoznaczny,
tzn. ten sam arkusz otwarty w lokalizacji pl_PL pokaże przecinek,
a w en_US kropkę, więc to raczej nie problem.


--
mrg

[xxxx]

W dniu 29.03.2017 o 17:03, AMX pisze:

W LibreOffice 5.1.6.2 w menu Narzędzia->Opcje->Ustawienia
językowe->Języki ustawiasz ustawienia lokalne na Angielski-USA i masz
kropkę zamiast przecinka.

:o)

[AMX]

On Wed, 29 Mar 2017 18:45:53 +0200, marrgol <mar...@address.invalid> wrote:
>> Nie używam ich (bądź używam niechętnie) bo separatorem
>> dziesiętnym jest "," (przynajmniej) w pl_PL a ja potrzebuję ".".
>>
>> Teoretycznie odpowiednie ustawienia locale powinny sprawę
>> załatwić ale gdy miałem ustawione LC_NUMERIC="C" to arkusze
>> wstawiały przecinek, przestawiłem na en_US i dalej to samo.

> > [???]

>> Jak zmusić arkusz do akceptowania kropki?
>
> Nie wiem, jak ty to sprawdzałeś.

Aaaa, tu go mam! Zacząłem jeszcze raz sprawdzać i okazuje się, że
kiedyś zrobiłem sobie alias:

gnumeric (setenv LANG polish; setenv LC_ALL pl_PL; /usr/bin/gnumeric !*)

no i przestawianie locale nie mogło działać =:-)

Po zmianie mam komunikat:
(/usr/bin/gnumeric:4038): WARNING **: Monetary thousands
separator is the same as the decimal separator; converting '.' to
','

ale to jeszcze do dopracowania. Najlepiej byłoby ustawić "'".

> Calc ma opcje lokalizacyjne w swoich własnych ustawieniach - m.in.
> może, ale nie musi, uwzględniać lokalizację systemową lub użytkownika.
> Patrz menu Narzędzia->Opcje->Ustawienia Językowe->Języki

Tam jest niby pięknie, nawet checkbox specjalnie do separaora,
tylko że nie działa (a tym razem nie mam aliasu)

Dziękuję

[Jan Stożek]

Po głębokim namyśle marrgol napisał w Wednesday 29 of March 2017
18:46:

>> Jeśli wymieniasz arkusze z innymi, to powinieneś mieć ten sam
>> system znaków co inni.
>
> Informacja o tym jest zapisana w pliku arkusza w sposób
> jednoznaczny, tzn. ten sam arkusz otwarty w lokalizacji pl_PL pokaże
> przecinek, a w en_US kropkę, więc to raczej nie problem.

Jeżeli ma ustawione korzystanie z locale systemowego. Jeżeli
masz na sztywno ustawione polskie (albo nie polskie), to nie byłbym
taki pewien.

--
Pozdrawiam,

(js).

PS. Odpowiadając bezpośrednio proszę usunąć minus wraz ze wszystkimi
kolejnymi literami.

[marrgol]

On 2017-03-29 at 21:00, Jan Stożek wrote:
>>> Jeśli wymieniasz arkusze z innymi, to powinieneś mieć ten sam
>>> system znaków co inni.
>>
>> Informacja o tym jest zapisana w pliku arkusza w sposób
>> jednoznaczny, tzn. ten sam arkusz otwarty w lokalizacji pl_PL pokaże
>> przecinek, a w en_US kropkę, więc to raczej nie problem.
>
> Jeżeli ma ustawione korzystanie z locale systemowego. Jeżeli
> masz na sztywno ustawione polskie (albo nie polskie), to nie byłbym
> taki pewien.

Może nie rozumiem, co chcesz powiedzieć, ale ja jestem pewien tego,
co napisałem. Nigdy się nie spotkałem i trudno mi sobie nawet
wyobrazić, żeby separator dziesiętny w arkuszu kalkulacyjnym przestawał
nim być z powodu otwarcia pliku w programie czy systemie o innej
lokalizacji. Nie spotkałem się też z przypadkiem żeby prezentacja
separatora - kropka czy przecinek - nie zgadzała się z decydującymi
o tym ustawieniami lokalizacji.

Żeby nie być gołosłownym, np. w Calcu z lokalizacją ustawioną na
sztywno na polską komórka zawierająca liczbę 8 i 8 dziesiątych jest
w pliku arkusza zapisywana tak:

<table:table-cell office:value-type="float" office:value="8.8">
<text:p>8,8</text:p></table:table-cell>

a z lokalizacją ustawioną na sztywno na amerykańską tak:

<table:table-cell office:value-type="float" office:value="8.8">
<text:p>8.8</text:p></table:table-cell>

Jak myślisz, dlaczego 'office:value' są identyczne?


--
mrg

[marrgol]

On 2017-03-29 at 20:25, AMX wrote:
>> Calc ma opcje lokalizacyjne w swoich własnych ustawieniach - m.in.
>> może, ale nie musi, uwzględniać lokalizację systemową lub użytkownika.
>> Patrz menu Narzędzia->Opcje->Ustawienia Językowe->Języki
>
> Tam jest niby pięknie, nawet checkbox specjalnie do separaora,
> tylko że nie działa (a tym razem nie mam aliasu)

Działa działa, tyle że ten checkbox nie służy do _wyboru_
separatora w Calcu, tylko do tego, czy kropka na klawiaturze
numerycznej generuje separator zdefiniowany ustawieniami
lokalnymi w Calcu, czy w systemie.

Jak zmienić separator napisał obok xxxx. Możesz też wybrać
ustawienia lokalne domyślne i zdefiniować LC_CTYPE (co ciekawe
LC_NUMERIC jest ignorowane, LANG też) jakie ci tam pasuje.

A jak ktoś ma zacięcie, to może sobie pomajstrować np. w
/usr/share/i18n/locales/pl_PL i skompilować sobie własną lokalizację
- w końcu to linux ;-)


--
mrg

[Jan Stożek]

Po głębokim namyśle marrgol napisał w Thursday 30 of March 2017 01:48:

> Nigdy się nie spotkałem i trudno mi sobie nawet
> wyobrazić, żeby separator dziesiętny w arkuszu kalkulacyjnym
> przestawał nim być z powodu otwarcia pliku w programie czy systemie
> o innej lokalizacji.

A mi bardzo łatwo: w końcu skoro narzucasz na sztywno locale
zamiast pozwolić aplikacji pobrać locale systemowe, to zapewne robisz
to w jakimś celu prawda?

> Nie spotkałem się też z przypadkiem żeby prezentacja
> separatora - kropka czy przecinek - nie zgadzała się z decydującymi
> o tym ustawieniami lokalizacji.

Może za mało precyzyjnie się wyraziłem, ale zupełnie nie o to
mi chodziło. Dla mnie najbardziej naturalne zachowanie jest takie:
* Jeżeli program albo arkusz ma przypisane locale, to
zachowanie i wygląd programu i danych jest dostosowane do
skonfigurowanego locale
* Z braku powyższego, program pobiera locale systemu
(użytkownika) i dostosowuje zachowanie do ustawień systemowych

W obydwu przypadkach zachowanie oprogramowania jest identyczne
(dostosowanie prezentacji do locale), jedyną różnicą jest źródło
pochodzenia tego locale.

Resztę pomijam, bo jest nie na temat: w końcu locale dotyczy
warstwy prezentacji, a nie wartości danych.