Nazwy funkcji w Calc

[Jermor]

Chciałbym zaproponować naszej społeczności wystąpienie do Apache Software Foundation i The Document Foundation o zaniechanie polonizacji nazw funkcji w arkuszu Calc. Moim zdaniem przynosi to więcej szkody niż pożytku.

1. Po pierwsze tworzone nazwy to jakieś potworki i łamańce skrótów mających wyjaśnić istotę funkcji. O ile takie nazwy są stosunkowo proste do utworzenia w języku angielskim, to w języku polskim nie jest to już takie łatwe. Kilka przykładów: NR.SER.OST.DN.MIES(), ÓSM.NA.DWÓJK(), czy BD.ODCH.STANDARD.POPUL( ).
2. Po drugie przeszkadza to w komunikacji ze środowiskiem użytkowników pracujących w innym środowisku językowym. Jak komunikować się np. z Bugzillą? Trzeba odnaleźć nazwę angielską i o ile w Libre można włączyć opcję "Użyj angielskich nazw funkcji" to w Apache takiej możliwości już nie ma.
3. Po trzecie utrudnia prace wtedy, gdy należy wykonać działania na arkuszu zlokalizowanym dla innego języka.
4. Po czwarte grupa pracująca nad helpem będzie miała ułatwione zadanie. Już teraz są przypadki, kiedy w helpie nie ma spolonizowanej nazwy funkcji, albo przykłady ich stosowania przedstawione są nazwami angielskimi.

Pozostaje oczywiście pytanie, co z istniejącymi nazwami? Sądzę, że zlokalizowane oprogramowanie powinno akceptować wprowadzanie nazw lokalnych równolegle z angielskimi, przy czym nazwy lokalne byłyby automatycznie przekształcone na nazwy angielskie, tak jak to robi korekta automatyczna.
Co o tym sądzicie?

[Jan_J]

Ja zasadniczo za:
2013: viewtopic.php?p=9344#p9344
2015: viewtopic.php?p=13860#p13860
2022: poglądu nie zmieniłem.
Sądziłem, że jestem odosobniony w swojej opinii.
Poważniej: odpowiedź miałaby rozmiar eseju. Nie wiem czy mnie stać czasowo. Postaram się coś dopisać, ale nie natychmiast.

[cwolan]

Dobry wieczór,

W Bugzilli LibreOffice zgłoszony został niedawno
Bug 152148 - The Polish version: MAKS.K(dane; rząd_K) ≡ LARGE(…; …) and MIN.K()

Jego autor proponuje nowe nazwy dla obu funkcji, odpowiednio MAKS.W i MIN.W,
oraz zmiany w ich opisie.

Czy ktoś może ma w tej sprawie jakieś zdanie?

[Jan_J]

Najpoważniejszą propozycję zgłosił @Jermor w maju 2022 w viewtopic.php?t=5834 (pozwoliłem sobie połączyć oba wątki, bo mimo że różnią się szczegółowym tematem, dotyczą jednego ogólnego problemu). Polega ona z grubsza na wystąpieniu o zaniechanie polonizacji nazw funkcji w formułach.

Co do aktualnych nazw polskojęzycznych: one fruwają w powietrzu, są kalkami równie dowolnych decyzji komercyjnych producentów, i robią się tak skomplikowane, że trudno mówić o mnemoniczności. Jeszcze trochę, a łatwej by się używało numerków niż tych nazw ... (prawie). Tradycja nazewnicza musi być przy tym uwzględniona, a ta jest sprzeczna: mieści się w niej i utrzymanie nazw oryginalnych, i nazwy fachowe lub branżowe (wartość modalna, element k-ty co do wielkości), i niestety także potworki ugruntowane w tradycji oprogramowania biurowego (MODUŁ.LICZBY, WYST.NAJCZĘŚCIEJ). Te potworki tak naprawdę również sporo zła robią w dydaktyce. Ból polega na tym, że zdanie nie tylko grup użytkowników, ale nawet producentów oprogramowania takiego jak Libre niewiele tu zmieni.

Są argumenty za i argumenty przeciw. Moim zdaniem te „za” nieco silniejsze, choć obawiam się, że będzie grono, dla którego konieczność wyboru między MODUŁ.LICZBY i WYSZUKAJ.PIONOWO a ABS i VLOOKUP przekona do tego pierwszego. Gdyby miał to być czynnik wzmagający odpływ od Open Source do mniej lub bardziej komercyjnej konkurencji, mniej lub bardziej rozdającej swoje produkty (przynajmniej w podstawowych wersjach), to nie bardzo mi się podoba. Choć postulat utrzymania międzynarodowej i trwałaj tradycji nazewniczej (np. opartej na nazwach z C Standard Library, to w końcu kawał historii) jest dla mnie ważny.

Zaś co do postulatu zgłoszonego na Bugzilli przez @MarkOpen: to tylko opinia. Takie zgłoszenia dokonywane szczegółowo i osobno nie mają żadnego sensu.

Może warto wrócić do viewtopic.php?t=5834 ?

[cwolan]

Zaś co do postulatu zgłoszonego na Bugzilli przez @MarkOpen: to tylko opinia. Takie zgłoszenia dokonywane szczegółowo i osobno nie mają żadnego sensu.

Chodziło mi tylko o to, czy proponowana zmiana nazw funkcji i opisu ułatwiłaby zrozumienie / korzystanie z tych funkcji
( w M$ Excel w wersji polskiej jest MAX.K i MIN.K ).

Co do zaniechania polonizacji nazw funkcji w arkuszu Calc: jestem tego samego zdania, co Jermor. Przypadła mi do gustu również opinia wyrażona dawno temu na tym forum:

Spolszczać sum() i countif() to dla mnie tak, jakby pisać dopóki() {} i jeżeli () {} w C.

I jeszcze drobna uwaga, tylko dla porządku:

Po drugie przeszkadza to w komunikacji ze środowiskiem użytkowników pracujących w innym środowisku językowym. Jak komunikować się np. z Bugzillą? Trzeba odnaleźć nazwę angielską i o ile w Libre można włączyć opcję "Użyj angielskich nazw funkcji" to w Apache takiej możliwości już nie ma.

Jedyne co „oferuje” Apache, to możliwość włączenia eksperymentalnej opcji
(zmienna środowiskowa OOO_CALC_USE_ENGLISH_FORMULAS).

[Jan_J]

Chodziło mi tylko o to, czy proponowana zmiana nazw funkcji i opisu ułatwiłaby zrozumienie / korzystanie z tych funkcji
( w M$ Excel w wersji polskiej jest MAX.K i MIN.K ).

Momi zdaniem nie.
* Forma maks.k nawiązuje do tradycyjnej nazwy „element k-ty w kolejności według porządku”, która sama z siebie jest dziwna: no bo dlaczego nazwa argumentu liczbowego (k) rzutuje na nazwę funkcji — chyba że „k” to „indeks pozycyjny”? tym niemniej tak się mówi i pisze w środowisku osób zajmujących się algorytmiką i analizą danych (np. tu: https://wazniak.mimuw.edu.pl/index.php? ... h/Selekcja).
* Przestrzeganie zgodności nazw z wiodącymi producentami jest zapewne konieczne dla ułatwienia życia użytkownikom. Ale to chodzenie na krótkim pasku, więc nie byłym chętny by się nań powoływać.
* Proponowana przez MarkOpen forma max.w ułatwienia nie zapewnia. Idzie w kierunku wyrugowania z nazwy funkcji arbitralnego oznaczenia jej argumentu, lecz pod prąd tradycji i w sposób absolutnie wyrywkowy.