[Dict] БГ Офис модул за проверка на правопис

Tue Mar 31 13:25:36 EEST 2015

Здравейте,

За съжаление, нямам свободно време и ми е трудно да участвам в нови проекти.

Които е изпратил някакви промени към БГОфис съм ги вкарвал - но те са били
доста малко. Променя на лицензи, 1-2 сгрешени типа и пр. - нещата са
описани в ChangeLog кое и какво е променяно,

Като съм започвал проекта съм си поставил няколко ясни, точни и изпълними
цели. Описани са във файла - design_objective.txt

"Главната идея е да се постигне лесна и удобна структура за
съхранение и добавяне на нови данни. От тази структура с помощта
на програма да се генерират съответните речници или да се
трансформират данните в друг по-компактен вид."

И съм спрял до там. Т.е. в момента има структура на данните, която може да
се редактира с текстов редактор и има скриптове на езика Perl, с чиято
помощ може да проверявате базата (данните), да генерирате речници за
проверка на правописа за Мозила, Офиса, Хром и пр. и съответно лесно може
данните да се конвертират до други формати (както е видно има поне 3
клонинга). И това е като цяло. Има едно демо за разпознаване частите на
речта но нищо повече и съм спрял до там. И това нещо работи под Линукс
(конзола, няма GUI).

А всичко започва и се базира на тази книжка - Кръстев Б., Морфология на
българския език в 187 типови таблици. С., НИ, 1984.

От там нататък Читанка, Уикиречника - ги качват нещата в Уеб, комбинират ги
отделните модули. И всичко това е похвално.

IDI Spellchecker-а отива доста по-напред и прави доста нови неща, но за
съжаление нищо не е вкарано обратно (поне по базата) и съответно това не
допринася по никакъв начин за разширение на речниците за проверка на
правописа за Мозила, Офиса и пр.

Доколкото разбирам има две идеи. Едната е да се направи нещо ново и хипер
мега яко - Словник. А другата идея е на г-н Стоян Димитров, който просто
иска да разшири речника на Мозила.

Разширяването на речника на Мозила е сравнително лесно постижима цел с
наличните средства - все пак аз съм вкарал близо 65 000 думи по този начин.

Намират се думичките, определя им се типа, вкарват се в съответните файлове
- има някакви скриптове за автоматизиране на процеса, но като цяло е ръчен
процес.

След това има скриптове за проверка на състоянието на базата - дали
думичките са вкарани в правилните файлове, дали няма някоя латинска буква
вкарана (примерно латинско а) и още някоя и друга проверка (забравил съм ги
вече). И след това с помощта на друг скрит се генерират речниците за
Мозила, Офиса и пр. - процесът е изцяло автоматизиран.

Commit достъп до SVN мога лесно да ви дам. Просто се регистрирайте
http://sourceforge.net/ и ми пратете потребителското име.

Като цяло няма правила за преглед и проверка. Но в случай на нужда мога да
погледна дали всичко е наред. Мога да хвърля едно око на кода и да си
спомня какви бяха процедурите. Голяма част от тях са интуитивни,
скриптовете са с говорящи имена. Вероятността да се обърка нещо е доста
малка. Така че няма проблеми.

В момента като гледам по логовете има един колега, който бърника нещо по
английско-българската база на речника, но това по никакъв начин няма
влияние върху българската база за проверка на правописа.

В проекта има три директории:

1. docs - документи, описващи някои неща - главно за мен да не ги забравя
2. data - данните - структурата е описателна и няма нужда да се чудите кое
какво е. В началото на всеки файл има коментари, ако нещо съм измислял
извън книгата - 187 типа ;)
3. bin - скриптове за поддръжка и генериране на речници - също е описателна
и лесно се разбира кой скрипт какво прави.

Мисля че трябваше да направите "export LANG=bg_BG.cp1251" и после да
пускате скриптовете - иначе се получават леко странни резултати. Трябва да
е описано в документите. ;)

И най-лесния начин според мен е да се работи съвместно с автора на IDI
Spellchecker, за да се види какво е променял и добавял той и дали може нещо
от него да се изчопли и да се вкара в базата на БГОфис и съответно да се
генерират речниците за Мозила, Офис, ....

Поздрави,

2015-03-31 1:03 GMT+03:00 Стоян Димитров <stoyan at gmx.com>:

>
>
> На 30.03.2015 г. в 22:05, Sah War написа:
>
> 1. Ако знаете как, ще се радвам да създадете .txt вариант на db.sql.gz (все
> пак това е SQL база от данни...), даже е добре този вариант да се раздели
> на няколко отделни .txt файла, защото иначе ще е мъка да се редактира с
> текстов редактор.
>
> Това бих могъл сравнително лесно да го направя. Просто трябва да уточним
>
>  детайлите.
>
>
>  1. Ами, ако просто в отделните .dat файлове са сложени различни думи според
> частта на речта, към която принадлежат, то просто тези файлове трябва да се
> преобразуват в .txt (UTF-8). Аз обаче не знам нищо за форма̀та за бази от
> данни SQL освен това, че става въпрос за релационна база от данни. Не знам
> как такъв тип файл се преобразува в .txt, затова и потърсих вашата помощ.
>
>
> Обяснете какви подробности да обсъдим по отношение на тази дейност, за да
> се разберем по въпроса.
>
>  Ако искате структура като тази в папката data ще стане, но файловете ще
> бъдат без заглавния коментар, както е в изходните файлове от хранилището,
> всичко останало е постижимо. Утре вечер ще напиша скрипта, че вече е никое
> време.
>
>  Това е непосилен и безмислен труд. За набирането на този речник едва ли е
>
>  използвана пишеща машина. Но кой знае…
>
>
>  2. Пишеща машина?!? Кой още използва такива? Това е речник от 2012 г.,
> вероятно е направен на Adobe InDesign, сканиран е като черно-бял (освен
> предната и задната корица). А че тази работа ще отнеме много време, е
> пределно ясно.
>
>     До колкото имам спомени в таблицата на уникод няма знак за ударено ъ.
>
>  Другите знаци ги има, наистина не са в кирилската част на таблицата, но
> поне ги има, така че като вариант остава композирането.
>
>
>
> 3. Трябва да гледате само блока „Cyrillic<http://www.babelstone.co.uk/Unicode/babelmap.html> <http://www.babelstone.co.uk/Unicode/babelmap.html>“ (кирилица) в Уникод;
> омографите в латинските блокове на Уникод, които са визуално идентични с
> кирилски знаци (с ударения), липсващи в кирилския блок, не бива да се
> използват в кирилски текст, те не излизат при търсенето с Ctrl + F, защото
> имат отделни заделени кодове в Уникод. В кирилския блок има само знака „ѝ“,
> който се използва в българския език (а може би и в македонския?), има и
> „е“, но с „обратно“ ударение, което май не се ползва в българския език (в
> нашия ударението изглежда като умален вид на „\“ над дадения знак).
>
> „Композирането“ по Уникод е най-удачният вариант според мен, вече обясних
> причините, поради които съм на това мнение (накратко: чрез уникодско
> композиране за добавяне на ударения при търсене с Ctrl + F се открива както
> същия низ с ударенията, така и същия низ без ударенията, което е огромно
> удобство).
>
>     Мда, това е HTML-ският аналог на уникодското композиране на знаци. И аз
>
>  не смятам, че то е подходящо за целта.
>
>  Да, да, много правилно. Не се бях замислял за търсенето, но не ми се
> струва, че ще работи както трябва. Все пак става дума за знак, бил той и
> невидим, между видимите знаци. Но това е въпрос на реализация на търсещия
> алгоритъм.
>
> 4. За пръв път чувам, че в HTML има отделно композиране (смесване на знаци)
> от това на Уникод (знам само за HTML entities), къде го има описано това в
> Интернет?!?
>
>  Мне, грешал съм. Читанката е използвала нещо друго. Иначе да, HTML-ското
> комбиниране си е уникодското, но се използват видимите entities [1].
>
>  Колкото до сричкопренасянето — то е трудно и за да е точно (а не просто
>
>  генерирано по алгоритъм, който често дава напълно грешни варианти за
> сричкопренасяне), то трябва да се направи като ръчно написан списък със
> сричките на думите.
>
>
>  5. Има и друг проблем, който осъзнах едва сега. Трябва да се използва
> правилният знак за отделяне на срички (който е „‧“ (U+2027, HYPHENATION
> POINT), но в практиката се използва предимно дефисът „-“ — но това прави
> проблеми, защото последното може да се счете за полуслят правопис, а е за
> сричкопренасяне чрез дефис...). Но да се върна към проблема, за който щях
> да кажа — трябва да има думата, дадена без разделяне на срички и после (на
> същия ред) прилежащите ѝ срички, иначе може да се окаже, че
> сричкопренасянето дава грешни варианти за сричкопренасяне при съвпадане на
> части от думи откъм букви, което кара системата да си мисли, че
> сричкоделенето е по даден начин, а той всъщност е неправилен... Сложна
> работа... :\ Пък и трябва ръчно да се въведат сричките на думите...
>
>     Разбрах ви напълно. А сега очевидния въпрос, на който отговорът
>
>  вероятно е истеричен смях, но някой свързвал ли се е с хората от БАН, за
> евентуално подпомагане на проекта? Било то с изходните кодове на речника
> или по друг начин?
>
>
>  6. Немалка част от тези от ИБЕ при БАН живеят в епохата на 1990-те и още не
> са си оправили жалкото онлайн подобие на многотомния си речник (http://ibl.bas.bg/rbe/, едва Борислав Манолов от „Читанка“ го направи
> по-ползваем чрез неговия frontend на речника им: http://rbe.chitanka.info),
> не можем да очакваме реална помощ от тях, въпреки че можем да се пробваме
> поне да ги помолим да ни предоставят базата от данни на речника си, но
> по-скоро ми се струва, че ще се заинатят и ще си държат на „авторското
> право“ над базата от данни...
>
>  Мхъм, мъхъм, номерът с авторското право, естествено.
>
> 7. Само тези от Секцията по компютърна лингвистика към БАН са напред с
> материала (http://dcl.bas.bg/programs_bg.html,http://dcl.bas.bg/resources_bg.html и особеноhttp://dcl.bas.bg/dictionaries_bg.html) и само на тях възлагам надежди. Те
> имат публикувани свободни данни, като честотен речник, генериран от корпус,
> които могат евентуално да се вградят в речниковата база на „БГ Офис“, но и
> за тях не е ясно дали са проверени от човек за правописни грешки и дали ще
> се съгласят да ни дадат базите си от данни на речниците си, което де факто
> означава да ги пуснат под свободен лиценз...
>
> Не смятам, че е лош вариант да се смени първоизточника и за основа да се
>
>  използва нещо по-осъвременено, не разбирам идеята да има няколко еднакви
> начинания за едно и също нещо и нито едно от тях да не връща обратно за
> постигане на целта на първоизточника – по-добър БГ Офис.
>
>
>
> 8. Реално няма чак толкова много речници що се отнася до spellchecker-и за
> българския език, освен официалната добавка за Firefox, наречена „Проверка
> на правописа<https://addons.mozilla.org/en-US/firefox/addon/bulgarian-dictionary/> <https://addons.mozilla.org/en-US/firefox/addon/bulgarian-dictionary/>“
> (използва myspell, може би е основана речник от „БГ Офис“?), има само
> добавките „Bulgarian+English Dictionary“, „Bulgarian+German Dictionary“ и
> добавка със стария иванчевски правопис, който не е актуален. Само при
> онлайн речниците на българския език има по-голямо разнообразие, защото
> нишата още не е доминирана от по-сложно устроен свободен онлайн речник
> (какъвто ще бъде нашият проект „Словник“), само rechnik.info,onlinerechnik.com, eurodict.com и rechnik.chitanka.info се използват
> реално, другите са с много ограничена употреба. Имам дълъг списък с такива
> български онлайн речници — ако искате, ще ви го изпратя.
>
>  Добавката използва форматиран .aff от ООо. Имах предвид главно „IDI Spell
> Checker“ и речникът на Читанка. Читанката я обсъдихме като ненадежден
> източник.
>
>     Склонен съм да използвам текстова база от данни стига това да има
>
>  някакъв резултат, въпреки наличието на структурирани данни от базата на
> „Читанка“ (които по обективни причини са неизползваеми за целта).
>
>
>  9. Просто няма друг вариант в случая, освен използването на текстова база
> от данни — все пак „БГ Офис“ използва aspell и ispell (не знам дали
> използва hunspell, myspell и/или enchant), които доколкото знам работят
> само с текстови файлове. Поправете ме, ако греша.
>
>  Амии, има други варианти. Една реализация е именно речникът на Читанка.
> Структурата на базата е добра. Вече нещата опират до набор от инструменти,
> с които се борави с тези данни. Дали ще се извеждат в текстови файлове или
> данните ще се обработват по друг начин е без значение. Истината е, че в
> момента мигриране към база от данни няма да допринесе с нищо, а напротив.
> Инфраструктурата (скриптовете генериращи различните неща) на проекта
> очевидно работи в този ѝ вид.
>
> 10. Сега видях от https://svn.code.sf.net/p/bgoffice/code/trunk/bgoffice/,
> че .dat файловете на „БГ Офис“ са всъщност обикновени текстови файлове, а
> аз си мислех, че са двоични файлове... Но всички файлове са в Windows-1251,
> трябва да се конвертират до UTF-8.
>
>  Господин Раднев, смятам, ще се съгласи с това твърдение. Аз също съм
> твърдо „за“.
>
> 11. Мисля, че на първо време е най-добре г-н Раднев или вие, г-н Димитров,
> да направите копие на всичко от „БГ Офис“ (в SourceForge) в GitHub и да си
> сътрудничим по проекта там, защото просто не разбирам нищо от SVN. :D После
> не би било проблем да копираме новите издания от GitHub като нови версии в
> SVN-то на хостигна на „БГ Офис“ в SourceForge.
>
>  Точно това искам да избегна. Поредното копие на „БГ Офис“. Наистина
> разликата е, че то ще е общодостъпно, но все пак е копие. От друга страна
> като за работа от повече хора GitHub е по-добрият вариант, несъмнено. Все
> пак това е целта му.
> Господин Раднев, какво е вашето мнение? От друга страна, какви са
> критериите за получаване на commit права върху хранилището или части от
> него? Как става преглеждането и приемането/отхвърлянето на промени правени
> от други?
>
> П.П. Ех, писмото ми пак стана прекалено дълго. :D Май ще забравите за какво
> съм писал докато четете, затова номерирах абзаците, за да ви е е по-лесно
> да ги цитирате и да ги обсъдим. :)
>
> Поздрави,
> Sah War (sahwar)
>
>
>
> _______________________________________________
> Dict mailing listDict at ludost.nethttp://lists.ludost.net/cgi-bin/mailman/listinfo/dict
>
>  [1] http://eenk.com/postavyane-na-udareniya-na-kirilitsa-s-html
>
> --
> С
>
>
> _______________________________________________
> Dict mailing list
> Dict at ludost.net
> http://lists.ludost.net/cgi-bin/mailman/listinfo/dict
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ludost.net/pipermail/dict/attachments/20150331/c5c14a34/attachment-0001.html>