Fórum pro uživatele kancelářského balíku OpenOffice | LibreOffice
 

#1 22. 2. 2021 09:21:42

neutr
Člen
Registrace: 8. 3. 2007
Příspěvků: 3,468

Počešťování názvů ve vzorcích

Popis vzorců například VLOOKUP, HLOOKUP > Výsledek v seřazené oblasti
Je-li hodnota PRAVDA, nebo není zadaná, prohledávaný sloupec matice představuje řadu oblastí a musí být vzestupně seřazen.


     Problém je v tom, že zadání výrazu musí být DOSLOVNĚ ČESKY, tedy buď PRAVDA, nebo NEPRAVDA. (Původní výrazy TRUE a FALSE vyhazují chybu #NAME?). Lze zadávat i čísly PRAVDA (nebo funkce TRUE()) = 1, NEPRAVDA (nebo funkce FALSE()) = 0.


     Totéž dělá jak VLOOKUP, tak HLOOKUP, IF a zřejmě všechny podobné, kde lze zadávat Boolean hodnoty. Existují výjimky „=TRUE()" a „= FALSE()". Ve vzorci se často automaticky přepíše na číslo tedy 1, nebo 0, což dělají při bezchybném zadání i některé další vzorce. Ale při zápisu funkcí TRUE(), nebo FALSE() v zápisu tyto vzorce zůstávají například :
správně     

=IF(0*5=0;PRAVDA;NEPRAVDA)

  PRAVDA, NEPRAVDA bez závorek
správně     

=IF(0*5=0;TRUE();FALSE())

nesprávně

=IF(0*5=0;TRUE;FALSE)

bez závorek chyba #NAME?
správně     

=IF(0*5=0;1;0)

     Nevím od kdy se tyto EXCELentně počeštěné výrazy objevily, ale oprášil jsem jeden starší soubor (vzorce generované makrem) a najednou tam byly chyby. V určité době jsem začal používat jen  TRUE a FALSE protože se změnila anotace. A nyní opět. Vím že mám takových souborů více, bohu žel už nevím kde všude jsem to použil.


     Když se dělají takovéto změny, měla by nápověda upozorňovat dostatečným způsobem asi takto :
VLOOKUP, HLOOKUP > Výsledek v seřazené oblasti
     Je-li hodnota PRAVDA [psáno česky, číslem 1, popřípadě funkcí TRUE()], nebo není zadaná, prohledávaný sloupec matice představuje řadu oblastí a musí být vzestupně seřazen.


     Popřípadě
Je-li hodnota NEPRAVDA [psáno česky, číslem 0, popřípadě funkcí FALSE()], ……

Nápověda k HLOOUP napsal(a)

Vyhledávání v seřazené oblasti je nepovinný parametr, který určuje, zda první sloupec matice obsahuje meze rozsahů místo prostých hodnot. V takovém režimu funkce vrátí hodnotu z řádku, na němž se v prvním sloupci nachází hodnota menší nebo rovna Kritériu vyhledávání. Můžeme např. použít dny, kdy se změnila hodnota sazby daně; hodnoty v první sloupci pak budou představovat počáteční data období, v nichž určitá sazba daně platila. Vyhledávání pro datum, které v prvním sloupci matice chybí, avšak spadá mezi dvě existující mezní data, vrátí nižší hodnotu z této dvojice. Díky tomu nalezneme údaje, které platí pro vyhledávané datum. Pokud první sloupec nepředstavuje seznam mezí rozsahů, zadejte logickou hodnotu NEPRAVDA nebo nulu. Je-li tento parametr PRAVDA nebo je vynechán, první sloupec matice musí být seřazen vzestupně. Prohledávání seřazených sloupců je mnohem rychlejší a hledání vrátí hodnotu i pro položku jen částečně odpovídající hledanému výrazu, je-li větší než nejnižší hodnota seřazeného seznamu. U neseřazeného seznamu musí být položka zcela shodná s hledaným výrazem. V opačném případě funkce vrátí #N/A se zprávou: Chyba: Hodnota není dostupná.

     Je tam toho hodně, ale nic o změně, respektive variantách správné anotace.


     Tohle počešťování à la EXCEL se mi vůbec nelíbí. Počeštěný excel uvádí například funkci =PRAVDA(), a samo sebou také =NEPRAVDA(). Spolu s tím také například IF – česky KDYŽ a mnoho jiných funkcí, ale také ne všechny. Takže nejsme na úrovni Excelu a dá se čekat, že se to také za krátko zase změní. Dle mne je dnešní stav zase jen dočasný a můžeme čekat problémy.
     Podstata problému je v tom, že náš formát ODF lze otevírat i v jiných tabulkových procesorech. Já občas používám Gnumeric, ale jsou i jiné a ty znají jen anglické popisky vzorců. Takže jde o konvergenci k Excelu a divergenci od všech ostatních tabulkových procesorů – posílení vazby na Excel by šlo udělat tak, že tabulkový procesor rozumí jak českému, tak anglickému výrazu – proč to tak není? Starší Excel to uměl.


     Dnes se vše přiklání k anglickým výrazům. Čeština už převzala mnoho výrazů které už patří do češtiny. Na vysokých školách už nikdo neakceptuje, že anglicky student neumí. Možná že už to dělají i střední školy. Angličtina se zavádí jako mezinárodní standard ve všech sférách ať se nám to líbí nebo ne.


     Co je to za počin počešťovat a ještě neúplně? Je to krok jakoby vpřed – ale ve skutečnosti 2 kroky zpět. Třikrát fuj. Proč už Calc nerozumí TRUE a FALSE bez závorek když rozumí bez závorek PRAVDA a NEPRAVDA?
Budeme stejný problém řešit i v počešťování názvů ostatních funkcí tak aby Calcu rozuměl pouze Excel? Cui bono?


Moje e-mailová adresa
Pokud je Váš problém vyřešen, označte prosím svůj příspěvek za "VYŘEŠENÝ"
Zlepšíte orientaci při vyhledávání řešení JAK OZNAČIT TÉMA ZA VYŘEŠENÉ

Offline

#2 22. 2. 2021 17:14:49

kamlan
Člen
Registrace: 15. 9. 2016
Příspěvků: 368

Re: Počešťování názvů ve vzorcích

Jestli bude výsledkem nějaké fce hodnota PRAVDA/NEPRAVDA či TRUE/FALSE je podle nastavení: Možnosti/ Jazyková nastavení/ Jazyky/ Národní prostředí.

Nechápu sice proč parametry TRUE a FALSE do vzorců musejí být zadány jako funkce: TRUE() a FALSE() -> takto se závorkami() jsou i v Nápovědě, ale možná to souvisí s vyčištěním a renovací kódu https://blog.documentfoundation.org/blo … echnology/ - třeba to rozhazovalo nějaký renovovaný parser a raději bylo sáhnuto po striktní závorkové syntaxi TRUE()/FALSE() než aby bylo rozlišováno jestli TRUE znamená funkci TRUE() nebo konstantu TRUE -> byť se to jeví třeba jako snáze rozpoznatelné. Kdežto rozpoznat lokalizované konstanty PRAVDA/NEPRAVDA třeba pro parser problém není. V té renovaci kódu bylo možná dost věcí předěláno z Javy do C++ a možná to v C++ bylo jednodušší nekomplikovat. Ale věru nevím, jde jen o můj dohad/odhad. Možná by to byl někdo schopen zodpovědět na nějakém EN mailing listu, kam se dá proklikat z menu Get Help na stránkách http://libreoffice.org.

Vzhledem k jazykové lokalizaci a jak uvádíte dřívějšího bezzávorkového fungování TRUE/FALSE asi nejsnažší cesta bude používat v případech PRAVDA/TRUE()/NEPRAVDA/FALSE() jen čísla 0/1. Byť předělávat kvůli tomu starší Sešity či makra je v podstatě k nepěknému nasra´ňý.


Co se týká anglických či lokalizovaných názvů funkcí, tak pro to je nastavení: Možnosti/ LibreOffice Calc/ Vzorec/ Použít anglické názvy funkcí.

Přičemž Nápověda uvádí:

Názvy funkcí mohou být v LibreOffice Calc lokalizovány (v češtině lokalizovány nejsou). Ve výchozím nastavení je tato volba neaktivní, a jsou tak používány lokalizované názvy funkcí. Zaškrtnutím této volby přepnete lokalizované názvy funkcí na anglické. Změna se projeví v těchto částech programu: zadávání a zobrazení funkcí, průvodce funkcí a nápovědné tipy. Zrušením zaškrtnutí se můžete vrátit k používání lokalizovaných názvů funkcí.

Takže do češtiny názvy funkcí prý lokalizované nejsou - a za sebe mohu dodat, kéž ani nikdy nebudou. Nemyslím si že krom bordelu by to dodalo cokoliv přínosného. MS potřebuje neustále oblbovat zákazníky aby dál a dál a dál cálovali za MS Office a jednoduchá hláška "nově nyní můžete používat názvy funkcí v češtině" by třeba mohla připadat reklamnímu oddělení jako skvělá - potažmo nějakým lidem jež stále cálují za to být členy drahé excelovské sociální bubliny. No a když z toho cálující excelář bude v háji neb to bude třeba všelijak chybové, tak si přece může skvěle zacálovat nějakou placenou podporu, kde mu to za další těžké prachy třeba domrší ještě víc :-).


Kdyby někdo začal lokalizovat názvy funkcí, jistě by narazil na nějaké nepěkné zádrhele a problémy a krom toho, že by to zabralo asi spoustu času, by nejspíš došlo na to, že po tom čase a námaze už by nebyla chuť ani vůle za pár let lokalizovat třeba další funkce. Já nevidím rozumný důvod pro lokalizaci názvů funkcí. Jestli se někdo není schopen naučit používat vzorce s anglickými názvy a naučí se jen pár počeštěných, tak pravděpodobně stejně bude otravovat jiné aby mu nějaké další vzorce dali dohromady - a jak by to setsakramentsky dokázalo být otravné dávat to dohromady páté přes deváté v EN a částečné CS.

A když někdo chápe jak které vzorce používat, tak to že nejsou jejich názvy v češtině přeci nikterak nevadí. Určitě by to na vysvětlování bylo naopak horší, neb každou chvíli by se muselo rozlišovat že slovo je zrovna název vzorce a nikoliv vysvětlující slůvko. Příklad: Když použijete IF tak ... vs. Když použijete KDYŽ tak ... jež by foneticky mohlo i vyznít: když použijete kdyžtak ... -> "... hele tak kdyžtak už radši dál nic neříkej :-)".

Zajisté by bylo také třeba zohlednit to, že různí kverulanti by jistě pitvali překlad názvu a to, že podle nich třeba neodpovídá klasickému použití slova a že je to opět blbě atd. -> jen aby se mohli dál hádat a hádat a hádat. Pro příklad jak by se dal přeložit třeba vzorec OFFSET? Jako KOMPENZACE, ŠLAHOUN, ODNOŽ, VÝHONEK, OFSET :-)?


Ono už dost bordelu pro sdílení Sešitu s jinými může udělat jenom změna parametrů pro: Oddělovače a Sloupce/Řádky matice (v tom samém nastavení jež je výše), natož to ještě komplikovat počeštěnými názvy.


Mám i dojem že jsem někde četl že překladatelé snad i zkoušeli názvy vzorců lokalizovat, ale pak od toho upustili. Ale to si skutečně přesněji nevybavuji.

Offline

#3 22. 2. 2021 20:02:43

neutr
Člen
Registrace: 8. 3. 2007
Příspěvků: 3,468

Re: Počešťování názvů ve vzorcích

Já se domnívám, že anglické názvy jsou implicitní a lokalizované jen "pomocné". To znamená, že by každý druh tabulkového procesoru měl načíst implicitní názvy a ty popřípadě převádět do jiné lokalizace. To znamená, že TRUE = PRAVDA a bez závorek, totéž u false. Zde mi vadí právě také to, že "naší lokalizaci" jiné tabulkáče nepřečtou - to dovzuji z toho, že ani Calc neumí přečíst TRUE a FALSE bez závorek a vyhodí chybu.


     Dnešní tabulkové procesory jsou standardizované a měly by umět přečíst správně i lokalizované názvy. Je to běžné s lokalizací ovládacích prvků (frameworků) a dají se používat podle toho jakou má uživatel nastavenou řeč. Jde to právě proto, že se uznává jedna hlavní lokalizace.


     Já vím že to není tak úplně jednoduché. Nejvíc zazlívám špatným popisům. Já uvádím "anotacím" - což jsou popisy například ty co vyskakují nad vzorcem, nebo které se objevují v "Průvodci funkcí". V rámci nápovědy (po stisknutí F1) jako takové už by to neměly být "anotace", ale vyčerpávající popis, i když stručný.
     V rámci informatiky se hovoří u vzorců o "notaci", nebo také "syntaxi" i když "syntaxe" není úplně správně. Syntaxe říká vše o tom jak se používají subroutine, proměnné, deklarace a podobně - nikoliv to jak se zapisují, ale spíš kam a proč. Notace je aktuálnější právě u vzorců. Notace říká jak se vzorce zapisují.
     Anotací myslím doslova informace o vzorci zejména v "Průvodci funkcemi". Jde mi o to, že odkazy na plnohodnotnou nápovědu odradí i zkušeného uživatele. Já jsem včera strávil několik hodin hledáním chyby. Hledal jsem chybu VLOOKUP - samozřejmě nejprve v matici. Když jsem ji několikrát předělal tak mi došlo, že v matici to není. Zadal jsem čísla a chodilo to. Pak jsem začal zkoumat proč mi nechodí TRUE a FALSE. Přišel jsem na "závorky", ale to mi hlava nebrala. Tak jsem otestoval "češtinu" a málem jsem spadl ze židle. Aby se to nepletlo totéž dělá i AOO.


     Je zřejmé, že jsme ve vývoji a "notaci je nutné akceptovat". Jenomže popisy by měly varovat před změnou zápisu. Ono tam popravdě je české PRAVDA, ale že by TRUE bez závorky byla chyba to mne nenapadlo ani omylem. Když už tak primárně TRUE bez závorky a PRAVDA se závorkou. Lokalizace bude asi pokračovat, ale anglické názvy musí být zachovány a ne, že budou blokované. To je důkaz, že jde o chybu koncepce. Když to vyhodí chybu v "domovském" balíku, tak v jiném už uživatel přehled mít nebude a dostane dojem že LO nesají za nic. Nebude zkoumat - bude jen odmítat pracovat s dokumenty vytvořenými v LO.
     Máte pravdu v tom, že popis jak to provozovat nemůže mít konstrukce typu - "zapněte tohle, nebo tamto", "přepněte na anglické vzorce", "vypněte iterace", "zapněte notaci vzorců typu A1 nebo R1C1" a nakonec si zprovozněte makra....
     Lokalizované vzorce pokud vyhazují chyby typu TRUE(bez závorky) musí neustále upozorňovat "máte zapnutou lokalizaci". Některé funkce nemusí pracovat správně. Už vidím začátečníka jak se v takovém maglajzu orientuje. Myslím si, že stav balíku dost předbíhá nápovědě, ale když víme, že se něco takového bude stále objevovat, tak se na to musí upozorňovat.
     Implicitní nastavení češtiny u vzorců je v současnosti zločin. Chápu, že základní kopyto je „předpis" a mnoho lokalizací může být mnohem úplnějších. Zatím je v češtině málo lokalizovaných výrazů a nelze ani shledat, že je tam něco česky. Testoval jsem zaškrtnutou volbu "použít anglické názvy funkcí" a nic - vidím stále jen ty samé anglické. Ani jsem nevěděl, že bych měl mít vzorce počeštěné, a TRUE / FALSE stále hází chybu.


     Možná se to za čas vyklube, ale než ta doba přijde vůbec by žádná volba lokalizovaných vzorců neměla existovat (možnost by měla být pouze v expertním nastavení). Ale testovat jaká chyba se vyskytla je opravdu zcestné. Jako by nebylo dost na skutečných chybách. Jednou jsem půl roku přepisoval chybu „generalFunction". Když jsem za půl roku skončil s přepisem maker – chybu opravili.


     Nyní to vypadá, že se objeví mnoho maker postavených na „Pythonu" jak píše Petr Valach dnes 22. 2. 2020 zde Novinky v LibreOffice 7.1 – Writer, Calc a další
„Další změny
     K dispozici je rozšířitelná a robustní kolekce maker pro skripty v Basicu a Pythonu. (Podrobnosti jsou k dispozici v poznámkách k vydání.)
     Pro všechny příkazy Basicu byly připraveny syntaktické diagramy. Zájemcům o tuto problematiku doporučujeme navštívit stránku Syntax Diagrams.

Asi se máme na co těšit – to bude kalvárie :-)


Moje e-mailová adresa
Pokud je Váš problém vyřešen, označte prosím svůj příspěvek za "VYŘEŠENÝ"
Zlepšíte orientaci při vyhledávání řešení JAK OZNAČIT TÉMA ZA VYŘEŠENÉ

Offline

#4 23. 2. 2021 18:32:36

kamlan
Člen
Registrace: 15. 9. 2016
Příspěvků: 368

Re: Počešťování názvů ve vzorcích

Tak TRUE/FALSE jako konstanty bez závorek Calc bere když má jako jazyk uživatelského rozhraní nastaveno EN a národní prostředí též EN. Když to je v obou česky tak bere jen PRAVDA/NEPRAVDA - ale pokud se to PRAVDA/NEPRAVDA zapíše do vzorce, tak si to hned sám přepíše na čísla 1/0.


Zkusil jsem stáhnout Nápovědu k verzi 6.2 a v té už je použití TRUE()/FALSE(). Zkoušel jse i starší Nápovědy (5.0 a 4.0) ale ty byly ještě integrované jako modul Libre a nikoliv jako HTML stránky a to už jsem nerozchodil. Přeinstalovávat kvůli tomu Libre na starší verze se mi již nechtělo. Ale zmínil jste že vám to dělá i v AOO, takže je možné že ve verzi kde vám šlo TRUE/FALSE bez závorek to mohla být chyba která to umožnila.


Nicméně je to fakt dost zásadní zjištění. Díky že jste na to upozornil. To co je bráno většinově jako konstanty bez závorek se v Calcu musí psát se závorkami. Tohle by mě jistojistě nenapadlo že kdybych viděl ve vzorci TRUE, tak že to bude špatně neb to musí být TRUE().


Zkoušel jsem ještě co udělá třeba výraz =PRAVDA a to si do buňky rovnou zapíše číslo 1. =TRUE() za píše v české lokalizaci s českým prostředím PRAVDA, ale v En TRUE. A =TRUE v En zapíše též rovnou číslo 1.
Takže dle lokalizace a národního prostředí vzorce výrazy PRAVDA/NEPRAVDA/TRUE/FALSE rovnou převádějí na čísla. Tudíž nejjistější by asi bylo používat prostě čísla 0/1, to by snad mělo zajišťovat kompatibilitu i s jinými programy.

Offline

#5 24. 2. 2021 06:01:18

neutr
Člen
Registrace: 8. 3. 2007
Příspěvků: 3,468

Re: Počešťování názvů ve vzorcích

kamlan napsal(a)

Zkusil jsem stáhnout Nápovědu k verzi 6.2 a v té už je použití TRUE()/FALSE(). Zkoušel jsem i starší Nápovědy (5.0 a 4.0) ale ty byly ještě integrované jako modul Libre a nikoliv jako HTML stránky a to už jsem nerozchodil. Přeinstalovávat kvůli tomu Libre na starší verze se mi již nechtělo. Ale zmínil jste že vám to dělá i v AOO, takže je možné že ve verzi kde vám šlo TRUE/FALSE bez závorek to mohla být chyba která to umožnila.

     Já si nemyslím, že by to byla chyba. Podle mne se AOO postupně přizpůsobuje a to celkem potichu. Už jsem něco podobného zaznamenal dříve. Nápověda AOO uvádí toto :

nápověda AOO napsal(a)

VLOOKUP
Svislé hledání s odkazem na vedlejší buňky doprava. Tato funkce kontroluje,zda jsou specifikované hodnoty obsaženy v prvním sloupci matice. Funkce poté vrací hodnotu v té samé řádce sloupce pojmenovaného Indexem. Je-li vynechán parametr PořadíŘazení nebo je-li nastaven na TRUE nebo 1, předpokládá se, že jsou data již seřazena vzestupně. V tomto případě, není-li nalezeno přesné KritériumHledání, bude vrácena poslední hodnota menší než kritérium. Je-li parametr PořadíŘazení nastaven na FALSE nebo 0, kritérium musí být nalezeno, jinak funkce skončí chybou

     U funkce HLOOKUP už žádné podobné vyjádření není, a LOOKUP byl vždy tak trochu nešikovný tím, že vyžadoval bez varianty setřídění vzestupně. Když by tato podmínka neexistovala a uměl by hledat i  na nesetříděných úsecích – tak bych nic jiného nepoužíval. Má dva „paralelní" vektory (sloupce, nebo řádky) pro vyhledávání a nemá proto ani index sloupce, ani nepovinný parametr.

LOOKUP(KritériumHledání; VyhledávacíVektor; VýsledkovýVektor)

     Popisovaná úprava není nejstarší variantou zápisu pro VLOOKUP a HLOOKUP. V původní verzi existovaly 3, respektive 4 parametry : 0, 1, 2 a prázdný nepovinný parametr. Změna nastala až při přizpůsobení funkcí normativním tabulkovým procesorům. Je to už pár let. Měl jsem potom potíže se zadáváním nepovinného parametru. Byl jsem zvyklý psát všude dvojku (dnes je to nula), která přestala existovat. Takže jsem zvolil TRUE a FALSE. Nyní už ani toto neplatí a fungují jen čísla. Dodnes se pro tyto „změny notace"  VLOOKUP a HLOOKUP raději vyhýbám. Doposud se co průměrné 4 roky mění notace. To u jiných funkcí není.


Moje e-mailová adresa
Pokud je Váš problém vyřešen, označte prosím svůj příspěvek za "VYŘEŠENÝ"
Zlepšíte orientaci při vyhledávání řešení JAK OZNAČIT TÉMA ZA VYŘEŠENÉ

Offline

Zápatí