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

Tue Mar 31 01:03:29 EEST 2015


На 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>“ (кирилица) в Уникод;
> омографите в латинските блокове на Уникод, които са визуално идентични с
> кирилски знаци (с ударения), липсващи в кирилския блок, не бива да се
> използват в кирилски текст, те не излизат при търсенето с 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/>“
> (използва 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 list
> Dict at ludost.net
> http://lists.ludost.net/cgi-bin/mailman/listinfo/dict
[1] http://eenk.com/postavyane-na-udareniya-na-kirilitsa-s-html

-- 
С

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ludost.net/pipermail/dict/attachments/20150331/f03c20f3/attachment-0001.html>