Názory k článku
Nová verze českého slovníku pro Hunspell

To je naprosto skvělá zpráva! A úplně nejvíc se těším na tu kontrolu „levopisu“, kterou autor připravuje. Už jsem se do něčeho podobného pustil sám před lety, kdy mě to začalo iritovat, ale nikdy nedokončil (a autor je k tomu rozhodně kompetentnější).

Bylo mi vždycky líto, že už to nějak není aktualizované.

Dobrá práce, doufám že to probublá do distribucí.

Přiznám se, jsem lín. Co je teda nejlepší slovník, ten hunspell? Vim že vždycky na mě kouká tohle, aspell a bůhví jaké spelly ještě.

Pokud uvažujete data, lepší svobodný slovník pro češtinu než tuhle aktualizovanou verzi nenajdete.

Co se týče enginu pro kontrolu a nabízení návrhů oprav, je Hunspell tradiční, ověřený, široce používaný a bez experimentování - a myslím, že v dnešní době by mohlo fungovat či se dalo sestavit něco pokročilejšího. (Například je škoda, že neumožňuje využívat informace o četnosti tvarů.)

Pro seznámení s Hunspellem doporučuju výborný seriál od člověka, který Hunspell reimplementoval v Pythonu. V závěru se zamýšlí právě nad možným lepším přístupem ke kontrole pravopisu: https://zverok.github.io/spellchecker.html

Slovník a kontrola gramatiky v Office implementována Ústavem pro jazyk český.

posles prosim odkaz?

https://www.interval.cz/clanky/kontrola-ceske-gramatiky-pro-ms-office-konec-korektoru-v-cechach/
Takže nejen tento ústav, jakou měrou se kdo podílel se asi těžko dozvíme.

23. 5. 2021, 15:46 editováno autorem komentáře

Ono by bylo ideální navázat na tradici NeXT a pro spelling poskytovat aplikacím přes obecnou službu systému. Každá aplikace s textovým vstupem by pak uměla automaticky spelling. Orientujete se někdo, jak je to v dnešních desktopech řešeno? Určitě tam je taky nějaká snaha o integraci, ale v praxi to kulhá. Třeba ve Scribus nikdy nevím, zda bude fungovat dělení slov (což je tedy zase jiný, nicméně tematicky příbuzný problém).

My to narozdíl od NeXTu nemáme tak homogenní, takže se tyhle věci obvykle řeší až na úrovni GUI toolkitu, a IMO to tak je správně - na headless embedded stroji nic takového nemá smysl, tak by to nemělo být v system layeru (systemd) nebo dokonce v kernelu.

GtkSpell tohle zajišťuje pro GtkTextView widgety, Sonnet pro Qt aplikace, a díky projektu Enchant je jedno, co pod tím máte za backend (hunspell, aspell, ...).

Tak na embedded stroji by ta služba samozřejmě neběžela, jako se to děje s dbus a dalšími službami, které se spouštějí po startu gui session.

Ale jinak chápu, je to tedy alespoň tak že by dnes všechny aplikace používaly Enchant?

Já znám akorát GTK+ svět, kde to tak je. Nevím jak v Qt aplikacích nebo jiných (Electron).