[LEZÁRVA] Ékezetes karakterű fileok/mappák sorbarendezése

Debian GNU/Linux

Sziasztok. Az lenne a kérdésem, hogy van arra lehetőség Linux alatt, hogy az ékezetes karakterű fileokat is megfelelően rendezze sorba a Linux (magyar ABC-nek megfelelően), mikor kilistázom egy mappa tartalmát? Mindezt úgy kellene (ha képes rá), hogy közben a nyelvezete a Linuxnak maradjon angol, tehát minden üzenet akár hiba, akár mással kapcsolatos üzenet maradjon angol.

https://helyesiras.mta.hu/helyesiras/default/akh12

14.c,

"A magánhangzók rövid-hosszú párjait jelölő betűk (a – á, e – é, i – í, o – ó, ö – ő, u – ú, ü – ű) betűrendbe soroláskor a kialakult szokás szerint mind a szavak elején, mind pedig a szavak belsejében azonos értékűnek számítanak. A hosszú magánhangzót tartalmazó szó tehát meg is előzheti a megfelelő rövid magánhangzót tartalmazót,"

Alkoholmentes sör -> guminő -> windows emulátor

Közben ugyanezen a linken meg van ez:

Az ábécé a betűk meghatározott állománya és felsorolási rendje. A magyar magánhangzókat és mássalhangzókat jelölő 40 kisbetű (a magyar ábécé): a, á, b, c, cs, d, dz, dzs, e, é, f, g, gy, h, i, í, j, k, l, ly, m, n, ny, o, ó, ö, ő, p, r, s, sz, t, ty, u, ú, ü, ű, v, z, zs.

Nincs is jobb, mikor kétféle rend van. Amúgy ha elolvasod az általad leírt mondatot, akkor olvasható ez: "kialakult szokás szerint". Tehát ez nem szabály, hanem valamikor kialakult szokásrend...
No ez a szokás érdekelne, mert ez régen nem így volt. Gyanítom valami amerikai, angol szakember az UTF-8 rendbehozatalkor kitalálta ezt a szokást, mert egyszerű leprogramozni. Elég egy map table, oszt csókolom.

mert ez régen nem így volt. Gyanítom valami amerikai, angol szakember 

Jók ezek az összeesküvés-elméletek, de nem, nem amerikai találmány, hanem tényleg ez a szokás alakult ki. Már az első, 1902-es helyesírási szabályzat is ezt alkalmazza a szó- és tárgymutatóban.

Nincs is jobb, mikor kétféle rend van

Csak szólok, pl. a bibliográfiai rendezéseknél megint másféle rend van.

No ez a szokás érdekelne, mert ez régen nem így volt. Gyanítom valami amerikai, angol szakember az UTF-8 rendbehozatalkor kitalálta ezt a szokást, mert egyszerű leprogramozni.

Nekem így tanították általános iskolában. Az pedig régebben volt, minthogy az Unicode-ot kitalálták volna :)

> Gyanítom valami amerikai, angol szakember az UTF-8 rendbehozatalkor kitalálta ezt a szokást, mert egyszerű leprogramozni.

Hát nagyon nem.

Szerinted az UTF-8 vagy Unicode definíciójában volna benne, hogy az o és ó azonosan rendeződik, meg az ö és ő is, de a két csoport egymáshoz képest már nem? És ezt berakták visszamenőlegesen a Unicode-ot megelőző magyar helyesírási szabályzatba?

( NevemTeve | 2024. 05. 28., k – 12:32 )

Egy nagyon okos ember írta ezt: https://lzsiga.users.sourceforge.net/ekezet.html#Q0145

K: Ha már itt tartunk, mi a legfontosabb tudnivaló az ékezetes fájl- és könyvtárnevekkel kapcsolatban?
V: Hát az, hogy ne használjunk ilyeneket. Ugyanez vonatkozik a szóközökre és speciális jelekre. (Ha valaki azzal állna elő, hogy a fájlnévben kell az ékezet/szóköz, mert az jelenik meg a felhasználó böngészőjében, akkor magyarázzuk el neki, hogy a fájlnév egyáltalán nem arra való, hogy megjelenjen a felhasználó böngészőjében.

Annak a nagyon okos embernek üzenem, hogy:

- Napjainkban egyre kevesebb szívás van az ékezetes fájlnevekkel. Nyilván van, de már nem olyan sok. Nekem van sok ékezetes fájlom, és én speciel nem futok bele problémába velük.

- Habár az eredeti kérdés fájlnevekről szólt, a javasolt válasz (LC_COLLATE=hu_HU.UTF-8) nem korlátozódik erre, bármilyen sztringek ábécébe rendezésére használható. Érdemes tehát általánosítani a kérdést.

( miq | 2024. 05. 28., k – 13:32 )

30 év fejlesztés során sokszor jött már szembe a rendezés kérdése. Tapasztalatból mondom, az első kérdés, hogy ténylegesen hogyan szeretnének rendezni?

Mert ugye eleve a helyesírási szabályzat szerinti "betűrendbe rendezés" nem felel meg az ABC-rendbe rendezésnek. De ez csak a legapróbb részlet. Mert ugye egy rendezés után nem szeretné senki

  • Dr. Kovács Gézát a "D" betűnél,
  • özv. Lakatos Sándornét az "Ö" betűnél.
  • XVI. Lajost az "X"-nél
  • "A programozás művészete" című könyvet az "A" betűnél keresni.

De persze nem csak az AkH. 14 a gázos, sajnos az MSZ 3401-81 sem nyeri el mindenki tetszését.

P.S.:
Kaptam már vissza olyan választ, hogy úgy rendezzem, mint az Excel, mert majd abba megy az eredmény, és abban valami függvény csak az "Excel-szerint" rendezett oszlop esetén működik jól...

Hát ugye?! De ez már nem rendezés, hanem névsor szerkesztés. Az meg az Akadémiai ajánlások szerint működni szokott.

A rendezéshez és kereséshez elegendő egy-egy sort weight és search weight tábla.

Aztán a finomabb munkához megkerülhetetlen a nyelveszkedés és a szótár alkalmazása.

Rakd sorrendbe egy karakter szerint (c+s) és két karakter szerint (van cs is) valamint a szó értelmezése után: pác, pácsó (ti. pác só, amivel a sonkát kezelik), pacsni!

Na, ki előzi meg a másikat?

Nem, mert amit belinkeltek, az aktuális helyesírási szabályzat 14. pontja alapján:
pác
pacsni
pácsó

Egyébként nekem így is rendezi helyesen alapból a sort és az ls parancs Arch-on. Pedig amerikai angolon hagyott rendszer, en_US.UTF-8-ra konfigolva, tehát nem magyar rendszer, semmilyen lokalizációs beállítás nincs magyaron, csak a tty-ban és X alatt a billentyűzetkiosztás magyar. Ha az LC_COLLATE=hu_HU.UTF-8 után futtatom őket, akkor valóban elcseszik a sorrendet:
pacsni
pác
pácsó

A pác, pácsó helyes sorrend, de a végére teszi, pedig a pacsni-nak közéjük kéne jönni, mivel az n az ó előtt van.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Miért is? Az a és az á azonosnak számít a rendezésnél (tehát ami mögötte áll, az dönt), ellenben a c egyértelműen előbb van - nem csak az ABC-ben, hanem a rendezésben is - mint a cs. Mivel a pác-só c-t, a pacs-ni pedig cs-t tartalmaz, nem a te, hanem az én sorrendem a jó. Az más kérdés, hogy szótár nélkül (ahogy ez korábban már megfogalmazódott) semmi nem fogja helyesen rendezni, mert magától nem jön rá, hogy a pácsó és a pacsni közül van-e olyan, amelyikben csak egyjegyű, vagy olyan, amelyikben kétjegyű mássalhangzó van.

(Ha pedig nincs magyar collate-ed használatban, akkor a véletlenen kívül esélytelen hogy helyesen rendezzen a rendszered. A FreeBSD is a hibás pác pacsni pácsó sorrendet hozza ki (beállított hu_HU.UTF-8 collate-tel), de mint írtam, ez azért van, mert semmit nem tekint kettős betűnek.)

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Valóban, igazatok van, nem vettem figyelembe, hogy a cs az önálló betű, nem c+s együttese. Akkor viszont igaza van a témaindítónak, ez a feature nincs helyesen implementálva, ha nem támogatja a magyar rendezési szabályokat.

Amit a collation-ről írtál, azt nem értem. Nincs nálam használatban, de ha a parancs előtt adom meg az LC_COLLATE= előkével, akkor a parancsnak használnia kéne, míg lefut.

Próbáltam egyenként minden ilyen környezeti változót átállítani, de az LC_* értékeket nem engedi shellből állítani, még root-ként sem, ezt írja rá vissza:
warning: setlocale: LC_COLLATE: cannot change locale

Ahogy olvasom egyébként ez mindent érintő hiányosság, nem csak Linux, BSD, meg unixlike OS-ek esetén áll fent, de MySQL-nél is panaszkodnak rá, meg lefogadom Windows alatt sem jobb a helyzet.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

warning: setlocale: LC_COLLATE: cannot change locale

Ha ez bash volt, akkor nem volt mögötte magyarázat, hogy miért nem? Az szokott lenni a gond, hogy nincs ilyen lokalizáció. Példa

$ LC_COLLATE=hu_HU.UTF-8
$ LC_COLLATE=hu_HU.CP1250
$ LC_COLLATE=hu_HU.CP1252
-bash: warning: setlocale: LC_COLLATE: cannot change locale (hu_HU.CP1252): No such file or directory

Ezek a kérdések gyakran feljönnek, jó lenne valami FAQ, pl.: https://lzsiga.users.sourceforge.net/ekezet.html#Q0067

De, nálam is ezt írja, a végén, amit nem idéztem be, hogy :No such file or directory.

Elvileg /etc/locale.conf szerkesztésével, majd localegen futtatásával menne, de az már a rendszerem szétkúrása lenne, annyit nem ér meg nekem a kísérletezés, hogy annyit variáljak. Főleg, hogy kiderült, hogy magyar LC_COLLATE-tel sem lesz hibátlan.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Nem nyert, mert ez csak a cs==egy betű alapján van rendezve. A helyes az, amikor értelmezed a szavakat:

pác
pácsó
pacsni

Tehát Zahy megoldása a jó! Vagyis az azonos pozíciókban c, c+s és cs áll, mert a c+s nem cs!

A rendes ábécébe rendezés így működik, de szótár is kell hozzá. Tudnod kell, hogy a pács szó nem létezik!

Ez itt elég jól teljesít.

( Raynes v | 2024. 05. 28., k – 22:33 )

Szerkesztve: 2024. 05. 28., k – 22:37

Írd le kérlek, példával, hogy az alap ls-kilistázással miért nem vagy megelégedve? Konkrét sorrendet idézz, amit eltol. Mert könnyen meglehet, hogy jól listázza már alapból az ls, csak te emlékszel rosszul a betűrendbe sorolás szabályaira. Az ls ugyanis már alapból betűrendbe rendez, ha nem adsz meg neki ezzel ellentétes kapcsolót.

Azt se értem, hogy miért van lezárva a téma, mikor a megoldás még nincs meg?

“The world runs on Excel spreadsheets.” (Dylan Beattie)

( YleGreg | 2024. 05. 28., k – 23:21 )

En a magyartanarral mar azon osszevesztem, hogy szerinte a dzs az egy betu szerintem meg harom. Kesobb rajottem, hogy nekem van igazam, mert betu az, aminek van ASCII kodja, peldanak okaert a szokoz az egy betu, es punktum. Aztan mondjuk megjelent a unicode, de az ilyen uri huncutsagok engem nem zavarnak ossze, ez az en buborekom  ebben nekem van igazam es kesz!

Ja, es uzenem a nyelvtantanaroknak, hogy a sor vege is legalabb egy betu, meg akkor is, ha a fuzetedben kezdesz uj sort. Nesze neked nyelvtan! :-)

Nem csak a magyartanár szerint, de az akadémia és szabályzata szerint is egy betű. A dzs, zs, cs, dz, gy, ly ny, ty is, mivel egy hangot jelöl. Amire te gondolsz, az az, hogy három karakter, de a magyar ábécé nem karakter alapon sorol, hanem betűk alapján. Ez wordle-típusú játékoknál is probléma.

Pedig én veled értenék egyet gyakorlati szempontból. Régen ez a többjegyes betű-téma lehet elment, amikor még költők írtak mártogatós tollal papírra, meg csak 5-10 tételt kellett ábécésorrendbe rendezni, meg bokorba szartak a falu végén, de ma, a modern, számítógépek által vezérelt világban, mikor gigákat-terákat kell mozgatni, meg rendezni kapásból, már csak felesleges nehézségeket szül ez a túlbonyolító, hagyományos megoldás, meg kéne változtatni. Amúgy is, az ember szeme karakterenként olvas, lépked, így logikusabb lenne karakterenként rendezni, algoritmusilag is egyszerűbb. Csak ezt magyarázd el ilyen ókonzervatív, akadémiai, bölcsész őskövületeknek, akiknek közük nincs a mai informatikai kérdésekhez, még csak laikus fiatal szintjét se ütik meg. Még ha meg is tudnád velük értetni, hogy mi vele a probléma, akkor is se engednének belőle, már csak azért se, mert 100 éve jó volt, akkor most is annak kell lennie, meg hagyománytisztelet, ami azért is bullshit, mert anno, mikor a hagyomány kialakult, akkor újdonság volt, ergó ahogy akkor változtattak, most is lehetne bármikor. A hagyományok azok olyanok, hogy úgyis változnak, jönnek helyettük újak.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Fordítva ülsz a lovon :-) nem azért betű vmi, mert van kódpontja, hanem azért kéne legyen, mert betű. Csak hát a konzorcium azzal van elfoglalva, hogy color modifierrel lehessen másnapos hasmenés színe a szarkupac emojinak, nem azzal, hogy benne legyenek a nyelvek betűi.

Az más kérdés, hogy mennyire jó ötlet ezeknek a dupla/tripla betűknek kódpontot adni, pláne, hogy korábban nem volt, nincs értelmes input method sem, ez egy normálisan szinte megoldhatatlan probléma imho.

Sőt: nincs is probléma, csak tudomásul kellene venni, hogy az Akh-ban írt módszer nem számítógépre való.

Kompromisszumként el lehetne fogadni valami olyasmit, hogy:

- szóelemzésre nem vállalkozunk, tehát a többjegyű betűket engedjük el, betűjegyenként menjen a rendezés (tapasztaltabbak kollégák láttak már olyat, hogy az okos DB autórendszámokban is felismerte a kettős betűt, emiatt nem úgy rendezett, ahogy vártuk volna)

- a hosszú magánhangzókra (ÁÉÍÓŐŰ) az alábbi kettő opció legyen nyitva (mindkettőnek kellene valami egyszerű név/kód):
* a rövidek közé keverve legyenek, mint az AKH-ban: [AÁ]-B
* a rövidek után legyen: A-Á-B

Lehetne gondolkozni azon is, hogy melyiket lesz könnyebb kiterjeszteni egyéb betűkre, mint Ä, Ë, Ř

> Ha lenne kódpontja,

Ez a rész nem látszik megoldhatatlannak.

> és minden szövegben az lenne helyesen használva,

Ez a rész látszik megoldhatatlannak. (Ha most lenne a számítástechnika hajnala, akkor esetleg elő lehetne állni egy ilyen felvetéssel, de attól már jó messze vagyunk.)

> nem lenne semmi baj a rendezésben.

Azért ezt kicsit kétlem, épp ez a topik bizonyítja, hogy nem a többjegyű betűk kérdése az egyetlen gond.

> Ez a rész látszik megoldhatatlannak. (Ha most lenne a számítástechnika hajnala, akkor esetleg elő lehetne állni egy ilyen felvetéssel, de attól már jó messze vagyunk.)

Igen, ezért mondtam, hogy ez egy közel megoldhatatlan probléma. Nyilván meg lehetne analizáltatni mindent is, meg lehetne szótár alapon inputkor ezentúl mindent autokonvertálni, de fájdalomnak tűnik.

> Azért ezt kicsit kétlem, épp ez a topik bizonyítja, hogy nem a többjegyű betűk kérdése az egyetlen gond.

A többi szerintem triviális. Ez alapvetően egy teljesen kicsi feltételrendszer, a bajt csak az okozza, hogy nem lehet könnyen megmondani a tokenizációt.

> az Akh-ban írt módszer nem számítógépre való.

Manapság, amikor a számítógépek összekötik az egész emberiséget, meg már képeket rajzolnak meg kérdéseket válaszolnak meg maguktól, akkor az AkH-beli "algoritmus" kéne hogy kifogjon rajta? Szótár valóban nincs beépítve a glibc-beli rendezési táblára, tehát a pácsó-t p+á+cs+ó-nak hiszi, de a többi szabály implementálva van az AkH szerint.

fordítva, a pacsnit "hiszi" p+a+c+s+n+i-nek

 

>> Manapság, amikor a számítógépek összekötik az egész emberiséget, meg már képeket rajzolnak meg kérdéseket válaszolnak meg maguktól, akkor az AkH-beli "algoritmus" kéne hogy kifogjon rajta?

igen. de nem baj, mert cserébe van terhes férfi emoji

Ez szerintem nem jó példa. Ugyebár a meccs szótőhöz jön hozzá a -val, -vel rag hasonult alakja, vagyis a -csel. De nemcsak írásban, hanem kiejtésben is rövidül (amit sokan tévesen -al, -el ragnak éreznek), nem lesz tripla hosszú, marad dupla. Tehát m+e+cs+cs+e+l-ként tokenizálandó a rendezéshez.

Bizonyosan van olyan valós példa is, ahol a szótár sem volna elegendő. Elválasztáshoz jól ismert példa a meg-int (megró) vs. me-gint (újra). Ábécéhez... nem tudok ilyet fejből. Update: meggyőz (rávesz valamire, vagy gyümölcsből kirakott állat), kissé erőltetett példa, sebaj.

Szerintem az ékezeteknek az ékezet nélküli magánhangzók UTÁN kéne lenniük egy normális, karakter alapú rendezésnél, nem keverve: pacsi, pazar, pác, pácsó, stb.. Implementálni, keresni is könnyebb, tisztább rendszer.

Mert pont ez az, jelenleg kiejtés szerinti rendezés meg szóelemzés, amin a rendezési rendszernek alapulnia kéne, de az ugyebár nem ad hozzá semmit, csak az implementációt nehezíti feleslegesen, mindenhez szótárat kell külön tárolni, és még akkor is reménytelen, mert összetett szavakat, rövidítéseket nem biztosan fog felismerni, kb. szélmalomharc.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Igazából gondoltam rá, hogy megemlítem, bele is írtam a hozzászólásba, majd kitöröltem belőle, mivel nem nyelvészfórum. Igazából nem hangot jelöl, hanem fonémát, de akkor meg azt definiálni elég nehéz olyannak, aki nincs ebben benne, mert ez sem egészen hang, inkább csak egyfajta jelentésmegkülönböztető hangkategóriának feleltethető meg. A hang és a fonéma különbségét talán legrövidebben az „azt” és „folyó” szavakkal lehetne érzékeltetni. Az „azt” /azt/ fonémikusan, de tényleges kiejtésben [aszt], a folyó az /folyó/, de tényleges kiejtésben [fojó], persze nem mindenkinél, egyes nógrádi nyelvjárásokban még ejtik néhányan ly-os történeti j-vel, nem köznyelvivel. Régen fonémikusan megkülönböztették még a nyílt, zárt e-ket, de ezt már az akadémiai nem ismeri el helyesírásnál, de a hangtannal foglalkozó nyelvészek továbbra is elismerik, mert egyes nyelvjárásokban, tájszólásokban még mindig van különbség a hegy/hägy (mint domborulat) és hëgy/högy (mint amilyen a ceruzán van) kettőse között, annak ellenére, hogy az ország 99%-nak már mindkettő csak hegy. Másik példa rá a helyes-helyës (hellyel rendelkező vs. elfogadott, hibamentes), vagy értem-értëm (érettem vs. felfogom), ëlég/ölég-elég (elégséges vs. elég a tűzben).

A lényeg, hogy egy fonéma vagy egy tényleges beszédhang az egy hangnak van számolva, teljesen mindegy, hogy magán- vagy mássalhangzó, sőt, a modern nyelvészet ezen a kettős felosztáson túl is lépett, mivel nem minden nyelvnek minden hangja sorolható be egyértelműen, pl. az angol-amerikai r-hang, meg sok nyelvben a nemzetközi fonetikai ábécében [w]-vel jelöl hangja nem sorolható be, ki hogy elemzi, van, aki mássalhangzónak, van, aki magánhangzónak, van aki a kettő közötti félhangzónak.

Önmagában senki nem mond mássalhangzókat, azok szavakban mindig valami magánhangzóval együtt szerepelnek tényleges ejtésben, a szótagszerkezet és fonotaktika miatt (ez utóbbi azzal foglalkozik, hogy a fonémák vagy a ténylegesen ejtett hangok nem jöhetnek egymás után össze-vissza, önkényesen a szavakban).

“The world runs on Excel spreadsheets.” (Dylan Beattie)

( egmont | 2024. 05. 29., sze – 09:06 )

Bátorkodom hosszászólni azon szerény okból kifolyólag, hogy a glibc-ben hu_HU(.UTF-8) locale esetén az AkH szerinti magyar ábécébe rendezés túlnyomó részben az én művem.

Szótár nincs beépítve, talán nem is lehetne, tehát a pácsó az p+á+cs+ó, a házszám az h+á+zs+z+á+m, a lesszabály az l+e+sz+sz+a+b+á+ly, de ettől eltekintve tudtommal az AkH-beli szabályokat maradéktalanul és helyesen implementálja a rendezés. Ez vonatkozik a magánhangzók sorrendezésére, a mássalhangzóékra, a szóköz ignorálására, stb. Az AkH-ban nem specifikált esetekben (pl. idegen ékezet) az algoritmus a glibc defaultjára esik vissza. De van, ahol az AkH-hoz képest tovább kellett specifikálni a viselkedést, például elvárás hogy az "ésszerű" és "észszerű", habár egyaránt é+sz+sz+e+r+ű-ként tokenizálódik, jól definiált és ne random sorrendbe rendeződjön.

Ha bárkit érdekel esetleg, a glibc repóján belül a definíció a localedata/locales/hu_HU, unittest (kézzel rendezett fájl sok megjegyzéssel) pedig localedata/hu_HU.UTF-8.in alatt található.

Minden nyelvnek mások a szabályai, pl. a svéd a végére rajka az ékezetes betűket (amit a svéd kék-sárga bútorboltban kapható, svéd ábécét tartalmazó poszterről lehet tudni); a francia ha csak ékezetbeli eltérés van a szavakban, méghozzá több is, akkor hátulról előrefelé veszi azokat figyelembe, és nyilván van még egy csomó ennél kreténebb szitu is. A magyar szabályokat implementálni (egy amúgy alig dokumentált keretrendszerben) elég nagy munka volt, szó sincs arról hogy csak úgy kipottyant volna a Unicode-ból, vagy hogy bárki fordítva ülne a lovon és a Unicode-hoz igazítaná a magyar ábécébe rendezést. Amúgy például az AkH azt is előírja, hogy a kisbetű megelőzi a nagybetűt, ez is épp keresztbe van mint a kódtáblák.

Léteznek alternatív magyar rendezések is, például telefonkönyvben a szóköz nem ignorálandó, hanem első név szerint rendezünk, utána azon belül a második név szerint stb. Ilyen variációk nincsenek a glibc-ben, nem cél teletömni csillió alternatívával. Akinek pl. telefonkönyves rendezés kell, az kézzel válassza szét szóköz mentén a nevet, és hívja meg a glibc rendezési algoritmusát a vezeték-, majd utána a keresztnevekre.

Akinek pedig nem tetszenek az AkH szabályai, az nem a hu_HU rendezést keresi :)

Nem is haragszunk rád, legalábbis én nem. Megértem, hogy ezt pain in the ass lenne implementálni, hogy minden szónál letárolni azokat a 2-3 karakteres betűket, amit egybe kell venni rendezéskor. Nem véletlen, hogy ahogy nézem, más szoftverekben sem implementálték ezt rendesen, beleértve a fizetősöket sem.

Csak az a baj, hogy nincs rá remény, hogy ez a része a helyesírásnak megváltoztatható belátható időn belül. A 12. kiadás nagyon sok idő után jött ki, alig pár éve, min. 15-20 évig nem fognak hozzányúlni, 2015-ben jött be. Az előző kiadás 31-32 évig volt érvényben, az azt megelőző 30 évig. Ha azt veszem figyelembe, hogy manapság azért gyorsulnak a dolgok, még akkor se valószínű, hogy 15 évnél hamarabb átírják, ebből le is telt már 9 év, de egy jó 6-10 évet még saccolok neki. Nem szívesen nyúlnak hozzá, mert akkor egy csomó kiadványt, tankönyvet át kell írni, meg egy csomó, laikus, iskolából már kikerült ember tudását avultatják el vele.

A megoldás itt az lenne, hogy át lenne nevezve szoftverekben ez a feature, és karaktersorrendben való rendezésnek lenne elkeresztelve, külön felhívva a figyelmet, hogy nem kompatibilis a helyesírási szabályzat betűrendbe rendezésével. Akkor boldogak lehetnek az akadémikusok is, mert az elavult hülyeségükhöz nem nyúl senki, meg a haladók is, mert lenne egy sztenderdizált modern rendszer, amit követnek.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Nyilván nem kötelező betartani, max. csak magyarórán, amíg közoktatásban tanulsz, meg érettségizel, ha ott nem akarsz megbukni. Máshol nem kötelező, de ajánlott követni, persze te dönthetsz úgy, hogy teszel rá, amit meg is értek.

Engem egyébként ez a besorolás nem zavarna, nekem megfelel az, hogy a rendszerem a magyar ékezetes fájlneveket alapból sorolja ls, sort, stb. segítségével, en_US.UTF-8 lokalizációs beállításokkal, de látod, van, aki máshogy gondolkodik, és zavarja, hogy a besorolás nem követi a szabályzatot, a kolléga ezért is nyitotta a topikot.

Egyébként ez a modern nyelvészetben is kezd változni, egyre többen törekednek rá a nyelvészek közül, hogy leírják, dokumentálják a nyelvet, hogy a nyelv beszélői hogyan használják, és nem előírják a szabályokat, hogy hogyan KÉNE, hogy használják, ez egy jelentős szemléletváltás. A nyelvművelés, helyesíráson rugózásnak emiatt kezd ilyen körökben is negatív megítélése lenni, mint elavult nyelvészeti szemlélet.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

> van, aki máshogy gondolkodik, és zavarja, hogy a besorolás nem követi a szabályzatot, a kolléga ezért is nyitotta a topikot.

Illetve a topiknyitó kolléga a szabályos működést gondolta hibásnak.

> Egyébként ez a modern nyelvészetben is kezd változni, egyre többen törekednek rá a nyelvészek közül, hogy leírják, dokumentálják a nyelvet, hogy a nyelv beszélői hogyan használják, és nem előírják a szabályokat, hogy hogyan KÉNE, hogy használják, ez egy jelentős szemléletváltás.

Sőt a tudomány (nyelvészet vagy bármi), mindig is leírta a világot, nem pedig megváltoztatta.

> A nyelvművelés, helyesíráson rugózásnak emiatt kezd ilyen körökben is negatív megítélése lenni, mint elavult nyelvészeti szemlélet.

A nyelvművelés sosem volt tudomány, kb. az asztrológiával lehet egy lapon említeni. Ettől függetlenül a helyesírásnak van célja és értelme: az, hogy minél könnyebb legyen olvasni a mások által termelt szöveget.

Ja, persze. Olyan törekvések is vannak, hogy a hagyományos nyelvtan helyett az sms röidítéseket, szmájlikat, stb. kellene tanítani. Mert az az élő nyelv! ;)

Pedig voltak korok és hagyományok, még ha egyeseknek meg is haladja az értelmi szintjét. Pl. zöldségesnél:  - Adjál egy tucat tojást is! - Attól függ, mennyi nálad a tucat. -??

Aztán kiderült, hogy tirpákiában így mondják: - Adj egy tucat gyufát! - Ami pedig egy 10 darabos csomag. Elengedtem magam és megjegyeztem: Arra biztosan sok bunkó lakik. ;) Nem arattam sikert, mert a leányzó is onnan származott.

A tucat a 12 már 4000 éve használatos megnevezése. Egy zöldségesek vagy piaci  kofának kutya kötelessége ismerni a fogalmat.

A modern nyelvészet szerint - legalábbis egy effektíve nyelvi Nobel-díjat  kapott magyar nyelvésznő szerint - a magyar nyelv szabályai tökéletesen algoritmizálhatók és számítógépre vihetők. A nyelvtani szabályok az élő nyelvet igyekszenek szabályokba foglalni ami azért fontos, hogy legyen egy alap szabályrendszer és egységes megjelenés. Ellenkező esetben a betűrendbe szedés lehetne ízlés kérdése is. Ebben az esetben ennek a topicnak sincs semmi értelme.

Gondolom, az egyéni szabályokat követni kívánók egy programnyelv szintaktikáját nem kérdőjeleznék meg, pedig azzal sokkal kevesebb módon lehet valamit kifejezni.

> A magyar nyelv szabályai tökéletesen algoritmizálhatók és számítógépre vihetők

Hogyne, itt is egy példa: az alábbi mondatok jelentése nagyon hasonló kell legyen, hiszen csak egy és-kapcsolat sorrendje különbözik:
Még képes és eljön!
Még eljön és képes!

Nem erőltetett, hanem nem létezik ilyen mondat, pontosabban mondva: senki sem használja így rendszerszerűen, csak elvétésként fordul elő.

Az ilyen példákat rendszerint áthúzással jelölik, nehogy valaki követendőként megtanulja, pl.: Anyám felmentem a padlásra, aztán én is utánament.

Nem szívesen nyúlnak hozzá, mert akkor egy csomó kiadványt, tankönyvet át kell írni, meg egy csomó, laikus, iskolából már kikerült ember tudását avultatják el vele.

Mivel ezt a betűrendbe sorolást alkalmazták már az első magyar nyelvű szótárnál is 160 éve, így nem egy csomó kiadványt, hanem gyakorlatilag minden korábban kiadott szótárt, lexikont vagy bármilyen betűrendes mutatót tartalmazó kiadványt avultatnának el vele.

Ja, szóval a „probléma” megoldása az, hogy akkor a jövőben két rendezési/keresési szabályt kell megtanulni, és még arra is figyelni kell, hogy az adott kiadvány melyiket alkalmazza. Ez egy igen frappáns megoldás, amely még további problémákat szül. Nem gondolod?

Gutenberg úgy nyomtatta a bibliáját, hogy úgy nézzen ki, mint a kódexek, így az árát is ahhoz tudta közelíteni. Nyomhatta volna más nyelven és más típussal, nem lett volna egy jó üzleti lépés… De ahogy megjelent az igény más nyelvre, más típusra, a technológián nem kellett változtatni.

A (közismert, általánosan alkalmazott) betűrendbe sorolásnak is organikusan alakultak ki a szabályai, most pedig azért kellene ezen változtatni, mert szoftveresen macerás megoldani? Ha szigorú betűrendbe akarsz rendezni géppel, akkor is folyamatosan frissített szótár kell (pácsó, tűzszünet stb.).

Szóval mi lenne az előnye annak, ha megváltoztatnák a szabályokat?

Mindent amúgy sem írnának át, csak azt, ami még aktuális, elterjedten használt. Ilyen 50-160 éves írások senkit nem érdekelnek. Amiről itt szó van, modern szabályzatok, jogszabályok, szabványok, tankönyvek, újabb kiadású szótárak, stb..

“The world runs on Excel spreadsheets.” (Dylan Beattie)

( x-daemon | 2024. 05. 29., sze – 19:30 )

kellene a collationt boviteni sensitivity-vel

pl.:

LC_COLLATE=hu_HU.UTF-8_CS

LC_COLLATE=hu_HU.UTF-8_AS

LC_COLLATE=hu_HU.UTF-8_CS_AS

aztan mindenki azt valasztja, amit szeretne

https://learn.microsoft.com/en-us/sql/relational-databases/collations/c…

itt 2 Hungarian is van, nem tudom valojaban mi a kulonbseg:

Hungarian (Hungary) 0x040e 0x040e Hungarian_CI_AS
Hungarian Technical Sort 0x1040e 0x1040e Hungarian_Technical_CI_AS

neked aztan fura humorod van...