Magyar nyelvi fejlesztések V.

LibreOffice, OpenOffice.org

A magyar helyesírás félelmetes küzdelmét élőben követi a LibreOffice frissített helyesírási szótára. A pár ezer változás részeként újra helyessé vált a dinó (rövid i-vel) szó (Magyar helyesírási szótár, Akadémiai Kiadó, 2017), miközben helyes maradt a dínó is (A magyar helyesírás szabályai, 12. kiadás, Akadémiai Kiadó, 2015), amíg el nem dől hivatalosan, melyikük a győztes. A felhasználók többsége azonban nagyobb hasznát veheti annak, hogy az automatikus kereszthivatkozások névelői és toldalékai is ellenőrzésre kerülnek, pl. *(3)-ben → (3)-ban, *f)-t → f)-et, az b) pontban → a b) pontban, ahogy a következő videófilmben (már nem *videofilm!) is látható.

Erről, és az FSF.hu Alapítvány támogatásával megvalósult egyéb fejlesztésekről részletesen a LibreOffice.hu számol be, felsorolva a LibreOffice, a Lightproof mondatellenőrző és a Szabad magyar szótár kapcsolódó változásait.

( mrev | 2018. 03. 19., h – 15:03 )

Tényleg félelmetes a küzdelem. Még reménytelenebb helyzetben vannak az adatbázis kezelők, ui. kiderült, hogy a helyesírás ismerete nélkül (amihez szótár kell), nem lehet stringeket abc szerint, a magyar szabályok szerint helyesen rendezni. És tulajdonképpen nincs is értelme vesződni vele.
--
ulysses.co.hu

Az „ál” kettősbetűk, valamint nem egyértelmű alakok felismeréséhez kell, például „pácsó”, „házszám”, melyek jóval ritkábbak a rendes kettősbetűknél. A glibc ez utóbbiak szerint tokenizál, így az előbbi példa szavakat tévesen rendezi. Hogy ennek van-e értelme, elég jó-e, az szubjektív – szerintem igen.

> Vajon nem kellett volna például a 'cs'-hez külön billentyűt és unikódpontot rendelni?

Érdekes gondolat... de szerintem nem.

A billentyű már most is szűk keresztmetszet, 9-cel több különböző szimbólumot kell elérni, mint angolul gépeléskor, így meg bejönne még 9 új. Nem férnének el, vagy kiütnék a számokat shift-esre (mint a francia billentyűzeten az ékezetek), az okostelefonon gépelésről nem is beszélve.

Az ábrázolás is valószínűleg sokkal-sokkal több problémát vetne fel, mint amennyit megoldana. Például a hosszú kettősbetűket (pl. „ssz”) hogyan jelölnéd, és a szoftverek mitől tudnák helyesen megjeleníteni?

Aztán ott van az, hogy egy ilyen megközelítés esetén aki nem beszéli az adott nyelvet, az képtelen lenne látott szöveget bevinni azon a nyelven.

A Unicode értelmes kompromisszumokat keresett, 100%-ig pedáns megoldások helyett. Nem vezetett be külön kódpontot az angol „sh”, „th” stb. számára sem. Vagy például nem különbözteti meg a magyar és a német „ö” betűt sem, holott tradicionálisan tudtommal az egyiken kissé alacsonyabban, a másikon kissé magasabban van az ékezet (nem emlékszem, hogy melyik melyik).

Vannak digráfok a Unicode-ban, pl. a holland ij. Másrészt erről a vonatról már lekéstünk, az MTA nem kapcsolt időben, a Unicode Consortium hivatalos hozzáállása azóta pedig már az "elmentek a büdös 'csába" (http://www.unicode.org/faq/ligature_digraph.html), mert visszamenőleg minden szöveget át kéne írni, hogy egyértelmű legyen. De semmi gond, lehet helyette használni a U+034F COMBINING GRAPHEME JOINER jelet, amihez ugyan szintén át kéne írni visszamenőleg minden szöveget, szoftvert...

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

> Unicode Consortium hivatalos hozzáállása azóta pedig már az "elmentek a büdös 'csába"

Nagyon helyes! A Unicode-nak nem feladata hozzáadnia az íráshoz olyan szemantikát, amely a (papírra) írott szövegben nem szerepel. Ha lehetővé is tesz ilyet (például elválasztási pontok), annak láthatatlannak és opcionálisnak kell lennie.

Tömény szívás lenne, ha lenne cs, dz, dzs stb. digráfunk meg trigráfunk. Kellene kétféle lehetséges mód a nagybetűsítésre (csak az eleje, vagy végig), hozzá megfelelő API és támogatás minden szinten, minden releváns szoftverben. Megjelenítés fix szélességű betűkészlettel. Megjelenítés terminál emulátorban. Duplázás (például ccs) kezelése hogyan, mondjuk font szinten cs+cs ligatúraként? A terminál emulátor meg találja ki magától, hogy 2+2=3? Vagy külön trigráf (és kvadrográf vagy hogy is hívják a ddzs-re)? Az összes téves használat (pl. cs helyett c és s, vagy fordítva) láthatatlan volna szokásos szövegszerkesztőben, nyomtatásban stb., külön célszoftvert kellene mindig használni a szöveg átolvasására. Lehet, hogy egy-két dolog egyszerűbb volna abban a világban, de biztos vagyok benne, hogy a dolgok 99%-a sokkal bonyolultabb lenne teljesen értelmetlenül.

Lehet, hogy egy-két dolog egyszerűbb volna abban a világban, de biztos vagyok benne, hogy a dolgok 99%-a sokkal bonyolultabb lenne teljesen értelmetlenül.

Na, ez mondjuk a magyar helyesírásra egy-az-egyben igaz, csak a lenne-volna nélkül ;).

A "környéken" gyakorlatilag mindenki tök jól el van a változatos diakritikus jelekkel jelölt mássalhangzókkal (és a fenti problémák _mind_ meg vannak oldva velük...)... fájna átállni? Fájna. Hosszabb távon jobb lenne? Igen.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Igen, át kéne állnunk. Ha meg arra lentebbi kommentedre gondolsz, hogy az IT mindent irányítani akar...

Nem. Lássuk be, nagyon sokan így se tudják helyesen használni a digráfokat/trigráfokat (pl. az elválasztásuk, hasonulásaik stb. - különösen szép ez, amikor egy már értelmét vesztett, "dehátrégenjóvoltaz" miatt megtartott ly-ról beszélünk... na, azt kukázni kéne egy az egyben), az csak extra lenne, hogy sok minden más algoritmizálhatóvá válna ezzel.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Szerintem meg nem. Az indexelésnek gyorsnak kell lennie, nem jó ilyenekkel pöcsölni. De mi az egész abc-be rendezés eredeti értelme? Hogy kiszámítható helyen megtalálhatók legyenek a szavak. A magyar szabályok ennek eleve ellentmondanak. És ráadásul még az implementáció is hibás.
--
ulysses.co.hu

Senki nem erőlteti rád, nem muszáj használni, választhatsz másmilyen rendezést is. :)

> De mi az egész abc-be rendezés eredeti értelme? Hogy kiszámítható helyen megtalálhatók legyenek a szavak.

Így van. De ha az eredeti értelmét kérdezed, akkor tegyük hozzá, hogy emberek (általában a nyelvet beszélő emberek), és nem gépek számára.

> A magyar szabályok ennek eleve ellentmondanak.

Csak ha nem ismered a nyelv szavait.

> És ráadásul még az implementáció is hibás.

A glibc esetén: nem jobban, mint amennyire szükségszerűen korlátozott a tudása a nyelv nem ismerete miatt a pácsónál és társainál.

Ha úgy állnánk hozzá, hogy csak tökéleteset szabad alkotni, akkor nagyon, de nagyon sok dolog nem létezne, ami létezik és roppant hasznos. Például helyesírás-ellenőrzők se lennének, csak hogy egy roppant közelit említsek.

> a magyar nyelvtan hibája

Teljesen hibásnak tartom azt a szemléletet, hogy az írást, nyelvet, nyelvtant, kultúrát, hagyományt stb. kelljen a számítástechnikai igényeihez igazítani. A számítástechnikának kell kiszolgálnia – minél észszerűbb mértékben és minőségben, ha tökéletesen nem is megy – az emberiséget, a hagyományaival, következetlenségeivel együtt.

Ha Te nem is veszed hasznát, hidd el, megvan annak a maga helye, ha egyes szoftverek képesek kevés speciális kivételtől eltekintve helyesen magyarul ábécébe rendezni.

+1

Az ITra kifejezetten jellemző ez a fajta lovon fordítva ücsörgés, meg arrogancia, amit már "a kilo 1000-et jelent, és SI? Nem baj, nekünk az 1024 kényelmesebbel" elkezdtek(tünk). (Bónuszként ugyanezek az emberek kéjesen jól szórakoznak az angolszászok hülye mértékegységein.) És azóta is rendszeresen folytatunk, mikor azt gondoljuk, hogy az IT cél, és nem eszköz.

( yoursoft | 2018. 03. 19., h – 15:29 )

Sajnos nálam nem megy a LibreOffice 6.
Már többször újratelepítettem a Win10 64 bites verziót (pl. ma is adtam neki egy esélyt).
Amint leütök egy betűt a Writerbe vagy Calcba. Egyből elszáll.

A 64 bites verzióval tényleg úgy tűnik hogy gondok vannak - viszont az furcsa hogy az egyik gépen minden további nélkül működik, a másikon viszont hasonló a jelenség, mint amit írsz. Viszont a 32 bites verzió az minden probléma nélkül működik. (Windows 8.1-en tapasztalom ezeket)