Page 1 of 2

Пожелания по улучшению жизни словаределателей

PostPosted: Fri May 08, 2009 7:46 am
by Gloggy
Сейчас процесс разработки словаря (в DSL форме) довольно утомителен в силу того, что массу действий приходится делать вручную, но которые могли бы делаться автоматически.

К примеру, компилировать словарь в Лингво можно только из отдельной программы и только руками, нельзя из коммандной строки запускать.
Во-вторых, обычно на стадии разработки словарь находится в UTF-8 кодировке (так его легче обрабатывать всевозможными скриптовыми языками, и размер меньше), а перед компиляцией его надо каждый раз в UTF-16 перегонять, опять ручная работа!
После этого, словарь надо подключить, и только потом можно посмотреть что как получилось, и повторять так раз за разом! :)

И вот тут-то GoldenDict может *кардинально* это дело упростить, и это гарантированно должно привлечь массы словаределателей ;)

1. GoldenDict не нуждается в компиляционном шаге, и сразу может работать с DSL. Что было-бы неплохо, так это какая-нибудь диагностика ошибок в формате, да хотя бы и просто LOG файл, создаваемый в момент индексации и парсинга этого самого DSL файла.

2. Было бы здорово, если бы GoldenDict мог понимать словари в DSL формате и в UTF-8 кодировке. UTF-8 легко отдетектить по BOMу, по первым байтам. Это убрало бы необходимость постоянной переконвертации словарей туда-сюда на процессе разработки.

3. Подключение. Было бы ОЧЕНЬ здорово, если бы GoldenDict просто мог бы определять на лету, добавились ли новые словари в те фолдеры, которые он мониторит. Но даже и проверка только в момент запуска тоже было бы уже неплохо. И, самое главное, как обнаружен новый словарь, иметь возможность его добавлять в какую-нибудь группу, чтобы словарем сразу можно было пользоваться. Сейчас же мне приходится, каждый раз словарь вручную добавлять в группу. Словарь в процессе разработки у меня меняет свое имя после каждой большой правки, типа Longman Activator RC1, RC2, или даже просто по времени создания. Это я делаю для того, чтобы в Лингво все эти словари можно было подключать одновременно. GoldenDict в данном случае видит, что новые словари добавляются, но в группу никакую их не заносит.

Итого, если все эти предложения в каком-то виде реализуемы, то процесс разработки становится существенно более простым. Люди правят DSL файл в UTF-8 кодировке, и изменения быстро и незаметно переносятся в GoldenDict (все что нужно, просто перезапустить GoldenDict или просто скопировать обновленный DSL файл в католог, который мониторится GoldenDict'ом). :)

Re: Пожелания по улучшению жизни словаределателей

PostPosted: Fri May 08, 2009 9:04 am
by ikm
Gloggy wrote:1. GoldenDict не нуждается в компиляционном шаге, и сразу может работать с DSL. Что было-бы неплохо, так это какая-нибудь диагностика ошибок в формате, да хотя бы и просто LOG файл, создаваемый в момент индексации и парсинга этого самого DSL файла.

В принципе, всё что там парсится в момент индексации, это заголовки карточек (т.е. то, что начинается с не-пробела). Далее информация о смещениях и размерах самих тел карточек сохраняется в индекс. А dsl-язык статьи разбирается в момент рендера этой статьи. При этом разбор старается быть довольно толерантным к ошибкам -- какую-никакую статью он покажет, даже если в ней куча ошибкок. То есть, GD наверное съест много чего, от чего DslComp отвернет нос. В плане валидации GD на оную не нацелен на данный момент вообще. Все, что он может говорить сейчас, это то, что часть тэгов осталась незакрытой, или что была произведена попытка закрыть тэг, который не был открыт (всё это он по-тихому и говорит в консоль, на самом деле). Неизвестные тэги он кушает без вопросов тоже.
Gloggy wrote:2. Было бы здорово, если бы GoldenDict мог понимать словари в DSL формате и в UTF-8 кодировке. UTF-8 легко отдетектить по BOMу, по первым байтам. Это убрало бы необходимость постоянной переконвертации словарей туда-сюда на процессе разработки.

UTF-8 вообще говоря не нуждается в BOM-е, потому что это однобайтная кодировка, и порядок байт там соответственно может быть только один. Поэтому большинство файлов в кодировке UTF-8 BOM-а не содержат. Я могу вставить детектор BOMа для UTF-8, но это очень специфичное решение, которое будет работать только у тех, кто знает, что этот BOM туда надо добавить. А вообще это логичней решается с помощью чего-нибудь вроде #SOURCE_CODE_PAGE "Utf-8", но это порождает несовместимость форматов (впрочем, и UTF-8+BOM тоже не совместим ни разу с Lingvo, как ни крути).
Gloggy wrote:3. Подключение. Было бы ОЧЕНЬ здорово, если бы GoldenDict просто мог бы определять на лету, добавились ли новые словари в те фолдеры, которые он мониторит. Но даже и проверка только в момент запуска тоже было бы уже неплохо. И, самое главное, как обнаружен новый словарь, иметь возможность его добавлять в какую-нибудь группу, чтобы словарем сразу можно было пользоваться. Сейчас же мне приходится, каждый раз словарь вручную добавлять в группу. Словарь в процессе разработки у меня меняет свое имя после каждой большой правки, типа Longman Activator RC1, RC2, или даже просто по времени создания. Это я делаю для того, чтобы в Лингво все эти словари можно было подключать одновременно. GoldenDict в данном случае видит, что новые словари добавляются, но в группу никакую их не заносит.

На лету - это вряд ли, хотя бы потому, что файл появляется сразу при начале копирования, а индексировать его надо когда он и все другие относящиеся к нему файлы были полностью скопированы. Этот момент определить по-хорошему невозможно.
Предлагать добавить в группу - это да, есть такая проблема. Сейчас вообще вопрос с группами решается - будет дефолтная группа, которая всегда будет содержать все словари, плюс, наверное, в случае, когда у пользователя несколько групп, при обнаружении новых словарей ему будет предлагаться пораскидать их по группам.

В общем, даже не знаю, что GD может сейчас предложить по улучшению жизни словаределателей, по крайней мере под Lingvo. Сейчас он позволяет легко и непринужденно делать словари, которые с Lingvo окажутся несовместимы, что вообще говоря не является положительной чертой средства для авторинга .dsl-контента ;)

Re: Пожелания по улучшению жизни словаределателей

PostPosted: Fri May 08, 2009 9:19 am
by Gloggy
ikm wrote:В принципе, всё что там парсится в момент индексации, это заголовки карточек (т.е. то, что начинается с не-пробела). Далее информация о смещениях и размерах самих тел карточек сохраняется в индекс. А dsl-язык статьи разбирается в момент рендера этой статьи.

Ага, стало понятнее. Ну вот когда я карточку открываю, было бы неплохо куда-нибудь сообщать об ошибках этой карточки, в какое-нибудь дебаг окно, или в лог. Так, может, даже лучше будет, во время разработки словаря мне все ошибки не очень интересны (их может быть очень много), а вот на конкретную карточку - самое даже то! :)
ikm wrote:UTF-8 вообще говоря не нуждается в BOM-е, потому что это однобайтная кодировка, и порядок байт там соответственно может быть только один. Поэтому большинство файлов в кодировке UTF-8 BOM-а не содержат. Я могу вставить детектор BOMа для UTF-8, но это очень специфичное решение, которое будет работать только у тех, кто знает, что этот BOM туда надо добавить.

Так тут все просто. Кто знает - тот добавит и сможет работать с DSL файлом в UTF-8 кодировке. Кто не знает, ему придется конвертировать в UTF-16. :)
ikm wrote: А вообще это логичней решается с помощью чего-нибудь вроде #SOURCE_CODE_PAGE "Utf-8"

Не уверен. Так или иначе, человек будет должен знать, что ему либо BOM надо прописать, либо вот странную строчку в DSL файле. С BOMом проще, большинство редакторов-конвертеров может вставлять его автоматом.
ikm wrote:На лету - это вряд ли, хотя бы потому, что файл появляется сразу при начале копирования, а индексировать его надо когда он и все другие относящиеся к нему файлы были полностью скопированы. Этот момент определить по-хорошему невозможно.

Согласен. Не говоря уже о том, что человек может вообще редактировать файл и после каждой записи файла преиндексировать его - не самое разумное. Сейчас, правда такого все равно произойти не может, GoldenDict лочит файлы, и пока они открыты, другой процесс туда все равно ничего записать не может. :) В принципе, мне вполне достаточно того, что я просто перезапускаю GoldenDict, и он обнаруживает изменения, пересканирует и пр.
ikm wrote:Предлагать добавить в группу - это да, есть такая проблема. Сейчас вообще вопрос с группами решается - будет дефолтная группа, которая всегда будет содержать все словари, плюс, наверное, в случае, когда у пользователя несколько групп, при обнаружении новых словарей ему будет предлагаться пораскидать их по группам.

Понял. Хотя бы иметь возможность в дефолтную группу всегда все добавлять или как-то так и то было бы удобнее, чем ничего.

Re: Пожелания по улучшению жизни словаределателей

PostPosted: Fri May 08, 2009 10:33 am
by ikm
Gloggy wrote:Кто знает - тот добавит и сможет работать с DSL файлом в UTF-8 кодировке. Кто не знает, ему придется конвертировать в UTF-16. :)

Добавлено в SVN. Utf-8 с BOM (0xef 0xbb 0xbf) будут читаться как Utf-8.

Gloggy wrote:GoldenDict лочит файлы, и пока они открыты, другой процесс туда все равно ничего записать не может. :)

Это Windows их лочит. А gd просто держит их открытыми на чтение. Под linux, например, в них можно при этом и писать, там нормальный COW :)

Re: Пожелания по улучшению жизни словаределателей

PostPosted: Fri May 08, 2009 10:36 am
by gromescu
Возможно, есть смысл сделать в меню edit пункт rescan now, а еще лучше эту команду вызывать по хоткею. Очень неудобно, каждый раз, поправив карточку, лезть в dictionaries, нажимать rescan, а потом ok, чтобы посмотреть как это все будет выглядеть.

Re: Пожелания по улучшению жизни словаределателей

PostPosted: Fri May 08, 2009 10:48 am
by ikm
Логично. Files|Rescan Files (Ctrl+F5). Ушло в SVN.

Re: Пожелания по улучшению жизни словаределателей

PostPosted: Fri May 08, 2009 10:52 am
by Gloggy
ikm wrote:Добавлено в SVN. Utf-8 с BOM (0xef 0xbb 0xbf) будут читаться как Utf-8.

Оперативно! Огромное спасибо!!!
ikm wrote:Это Windows их лочит. А gd просто держит их открытыми на чтение. Под linux, например, в них можно при этом и писать, там нормальный COW :)

Как обычно, пользователи Линукса издеваются над несчастными жертвами Windows! :) Я вообще-то сам линуксоид, но вот вынужден сидеть на винде, в том числе и потому, что под Линуксом не было нормального аналога Лингво. ;)

Re: Пожелания по улучшению жизни словаределателей

PostPosted: Wed Nov 04, 2009 9:49 pm
by Biochemist
Добрый день, Gloggy!

Если Вам так хочется создавать словари в удобной и наглядной программе, где можно сразу увидеть что получилось, то почему бы Вам не использовать программу TshwaneLex Suite 4.0 (http://tshwanedje.com). Для неё есть подробное руководство ([url]http://tshwanedje.net/files/TshwaneLex%User%20Guide.pdf[/url]). Русскоязычный форум пользователей TshwaneLex обитает на сайте http://forum.vostokopedia.ru/index.php?showforum=198.

Re: Пожелания по улучшению жизни словаределателей

PostPosted: Thu Nov 05, 2009 3:57 am
by C2BlEv
Да, пытался я как-то освоить TshwaneLex. По инструкции, с примерами, со всеми форумами поддержки. Потратил кучу времени, своял две статьи. Уж очень непонятная программа. Вроде как есть функция импорта хмл, но какой он должен быть. Как нужно переделать существующий дсл, чтобы потом загнать его в ТЛ не мог разобраться. Ведь не начинать все (десятки тысяч статеь) заново вгонять в ТЛ ручками.

Re: Пожелания по улучшению жизни словаределателей

PostPosted: Thu Nov 05, 2009 8:30 am
by Gloggy
Biochemist wrote:Если Вам так хочется создавать словари в удобной и наглядной программе, где можно сразу увидеть что получилось, то почему бы Вам не использовать программу TshwaneLex Suite 4.0

Спасибо за ссылку! Меня, в принципе, сейчас вполне устраивает связка текстовый редактор + GoldenDict (где я время от времени жму кнопку Refresh и сразу наблюдаю результаты правки). Не хватает небольших совсем мелочей, типа DSL validation, Links validation, но это не критично.