» GoldenDict

Abs62
Даже не знаю, как это сделать удобнее. Исходник DSL в UTF-8 — почти гигабайт. Проблемный вариант в формате Stardict, полученный при помощи makedict, — 2.5 гигабайта. Как вам удобнее — скачать исходник и сконвертировать самим или сразу качать 2.5 гигабайта? Я пытался сделать маленький тестовый словарик с заголовком U+ среди прочих и сконвертировать в Stardict через makedict, он работает нормально. Видимо дело или в объёме, или в каком-то проблемном сочетании элементов внутри словаря (там встречаются трудновообразимые сочетания символов из самых дальних отделов Юникода).

vsemozhetbyt
Лучше готовый. Только пожмите его в 7z или rar, текстовые файлы должны хорошо ужиматься.

Abs62
Пятый Rar подойдёт? Сейчас сожму и залью временно на Гуглдрайв.

Добавлено:
Хорошо пожалось, архив в 300 MB.

vsemozhetbyt
Символы тут не при чём, дело было в размере.
Вот, пробуйте - goldendict-1.5.0-RC2-28-gb52929c(EXE only).7z

Abs62
Баг исправлен. Спасибо большое.

Где можно "пощупать" эту прогу для андроши ???

trixtrax
GoldenDict (Бесплатная версия)
GoldenDict

Abs62
В целях оптимизации, прошу Вас рассмотреть возможность изменения алгоритма подключения CSS. В честности, по крайней мере, для .mwiki.
547 перечисленных селекторов, 397 правил (для селекторов с глубиной вложенности от 2-х до 5-ти) просто не могут не сказываться на производительности (особенно, при подключении большого кол-ва словарей).

В идеале было бы, если бы подключались только CSS, соответствующие форматам, в которых найдено слово. Но, если это трудно реализуемо, то сделайте, пожалуйста, только для форматов подключенных словарей. В самом факте, что при подключенных словарях исключительно формата DSL загружается ещё с пол-тыщи правил (комплексных) которые никогда не сработают, просто нет смысла.

И по самим правилам есть нюансы... Вот, гляньте результаты статистики только для .mwiki:
Тест 1
Тест 2
Есть как бессмысленные правила, напр:
Код: .mwiki table.mw-userrights-groups * td,
.mwiki table.mw-userrights-groups * th {padding-right:1.5em;}

Romul81
Это вы про встроенный article-style.css, что ли? Так он один. Плюс могут подключаться article-style-xxx.css с модифицированными правилами, если выбран какой-то стиль. И пользовательский article-style.css, если таковой имеется. Любые другие CSS грузятся только при наличии ссылки на него в коде статьи.

Abs62
Да, я про встроенный article-style.css. Собственно, что я предлагаю, это разграничить его по форматам. И подгружать по мере необходимости.

Добавлено:
З.Ы. И ещё момент, нельзя ли кстомный article-style.css прописывать в отдельном теге <style> с каким-нибудь специфическим артибутом, чтоб его можно было быстро и однозначно вычислять с помощью Javascript? Тогда встроенный можно было бы безболезненно удалять средствами того же Javascript. Ну и правильней это как-то... CSS-то по факту другой (внешний).

Romul81
Ну, тут требуется достаточно серьёзная и не слишком-то очевидная перекройка алгоритма загрузки. Особенно если учесть, что сама загрузка статей из словарей может идти асинхронно, в первую очередь для web-словарей.

Abs62
ОК. Тогда просто читать статус подключенных на панели словарей. Определить их формат не будет слишком затратно?

Добавлено:
Или если всё это очень сложно, то хотя бы разграничить онлайн и оффлайн словари. Самые проблемные это онлайн.

Добавлено:
Может, чтоб не делить файл - комментировать налету секции... В общем не знаю - Вам, как разработчику виднее. Думаю, основная мысль понятна.

Romul81

Цитата:

Определить их формат не будет слишком затратно?

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

Abs62
ОК. Понятно. В принципе, можно было бы вычислять javascript по onload, ищя нужные классы. Но это уже телега впереди лошади - страница то уже загрузилась.
Тогда, может, разнесёте основной и кастомный article-style.css. Скрипт из первого словаря будет убивать основной. Все нужные правила будут в кастомном. Кстати, здесь бы очень пригодился функционал кастомного javascript, о котором я просил ранее...

Romul81
Будет время - посмотрю. Сейчас с ним пока не очень хорошо.

Abs62
ОК. Спасибо!

Romul81
Вот, пробуйте - goldendict-1.5.0-RC2-31-g72a8a09(EXE only).7z. Разнёс все файлы по разным тегам.

Abs62

Спасибо огромное! С работы не могу скачать (админы ). Дома опробую.

Abs62
Хочу поинтересоваться у вас - почему отгрызается кусок слова в приведенном ниже примере:



В файле аббревиатур всё написано правильно:


Цитата:

вспл
    помета или чье-либо определение (странное поведение)

но вот слово "чье-либо" коверкается разными способами, то одна буква во всплывающем окне пропадет, то несколько (в зависимости от места переноса).

Дело, скорее, не в самом слове, а в дефисе.

ramix
Какие-то глюки в WebKit. GD же просто суёт текст подсказки в атрибут "title", взгляните в инспекторе.
Кстати, с Qt4 буквы не глотаются.

Abs62
В инспекторе без ста грамм не разобраться.

Сохранил статью через F2 и открыл в обычном браузере - там всё без проблем, в одну строку.

Если убрать дефис из описания пометы, то идет в одну строку и не глотает.

Поделитесь, плз, "наилучшими практиками": кто как поступает при частых обновлениях/пополнениях коллекции словарей, подключенных к ГД?

Пользоваться группой "Все" при большом количестве словарей неудобно: ГД тормозит, мешают слова из других языковых пар, с которыми в данный момент не работаешь. Можно автоматически создать группы по языковым направлениям. Но при подключении словарей нужно будет либо вручную добавить их в соответствующую языковую пару, либо автоматически пересоздать группы. Если добавлять по одному словарю раз в месяц, то можно и вручную, если чаще - возникает желание как-то оптимизировать этот процесс. Если пересоздавать группы - слетают горячие клавиши, назначенные группам, и их нужно снова задавать вручную.

И еще один вопрос для обсуждения.

При работе с ГД есть одно неудобство, которое заключается в том, что в отличии от Лингво группа не связана с раскладкой клавиатуры. Поэтому при переходе в другую группу (=языковое направление) нужно каждый раз менять раскладку. Мне кажется, было бы здорово, если бы ГД вел себя как Лингво, т.е. менял автоматически раскладку. Или можно автоматически создавать двунаправленные группы (eng-rus-eng) вместо однонаправленных (eng-rus).

Может можно было бы как-то доработать ГД? Или кто-то нашел для себя выход?

Abs62

Прежде всего, хотел бы ещё раз поблагодарить Вас за Вашу работу. Думаю, все здесь понимают, что проект открытый и свободный и все контрибуторы движимы чем-то вроде альтруизма, и никто не может от них ничего "требовать". Тем не менее, хотел бы обратить Ваше внимание на следующие моменты (не сочтите за назойливость).

1. Стили. Здесь, как мне кажется, стоит проявить дотошность и настроить всё как должно быть. Порядок разнесённых стилей важен, т.к. за невозможностью использовать классы и другие атрибуты из js нужный узел можно будет вычислить только согласно единообразному порядку (если не прибегать к другим ухищрениям вроде поиска комментариев). На данный момент порядок следующий:

< Общие стили для всех форматов <!-- Built-in css -->
< Альтернативные стили интерфейса <!-- Built-in style css --> (если активированы)
< Пользовательские стили <!-- User css --> (если подключены)
< Стиль печати <!-- Built-in print css -->

В принципе такой порядок удобен, т.к. <!-- Built-in css --> стоят первыми в списке, и если что-то удалять, то только их. Единственное, заметил что в этой секции, также, присутствуют несколько сугубо GD-ских стилей типа .gddictname, .gdfromprefix, которые критически важны.

Предложение. Может данные стили выделить в отдельную, следующую группу? Таким образом можно будет избежать прописывания их в Article-Style.css, что, в свою очередь, перекроет <!-- Built-in style css --> - что не есть правильно, конечно. Другими словами, предлагаю выделить в первую группу только формато-ориентированные стили. Если хотите, я мог бы сделать этот "развод", не затрагивая сами правила.

2. <!DOCTYPE. Да)) О нём как-то забыли... Или, может я ошибаюсь и он действительно должен быть

Код: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" ...

Romul81

Цитата:

На данный момент порядок следующий:

< Общие стили для всех форматов <!-- Built-in css -->
< Альтернативные стили интерфейса <!-- Built-in style css --> (если активированы)
< Пользовательские стили <!-- User css --> (если подключены)

<!-- User css --> - это юзерский article-style.css из папки конфигурации. А пользовательские стили (аналог альтернативных встроенных, размещённые в подпапке "styles" папки конфигурации) идут с комментом <!-- Addon style css --> и подключаются последними (если включён соответствующий стиль интерфейса). Стили для печати подключаются в том же порядке.

Цитата:

Предложение. Может данные стили выделить в отдельную, следующую группу? Таким образом можно будет избежать прописывания их в Article-Style.css, что, в свою очередь, перекроет <!-- Built-in style css --> - что не есть правильно, конечно. Другими словами, предлагаю выделить в первую группу только формато-ориентированные стили. Если хотите, я мог бы сделать этот "развод", не затрагивая сами правила.

Больно уж у вас запросы специфические. Не уверен, на такое будет массовый спрос.

Цитата:

2. <!DOCTYPE. Да)) О нём как-то забыли...

Хм. Вспоминается мне, что по какому-то поводу я уже пробовал с ним играться и пришёл к выводу, что лучше не трогать, оставить как есть. Тут надо всё тщательно проверять.

Abs62


Цитата:

Больно уж у вас запросы специфические. Не уверен, на такое будет массовый спрос.

Да нет, на самом деле, всё просто как апельсин. Я просто хочу сделать скрипт, который убивает <!-- Built-in css --> и пользователь сам подключает нужные стили. Если Вы когда-нибудь прикрутите пользовательcкий js - будет через него. Если нет - через MDX 1-й в списке (можно сделать просто файл-лист для заголовков под определённый язык и скрывать его средствами CSS). Хотя custom.js, конечно предпочтительнее . Естественно, всем этим чудом хочу поделиться с общественностью.
При подключенных сотнях словарей эффект может быть значительным, особенно, если это сложный HTML и учитывая уровень сложности уже имеющихся правил, большинство из которых не всякому нужны.

Добавлено:
Abs62

Общий вопрос касательно производительности. Какой формат наиболее оптимален в плане пред-рендеринговой обработки? По логике - HTML, т.к. DSL и XDXF конвертируются налету, а HTML подаётся as is. Хотя, по правде и он парсится (ресурсы, стили и т.д.), поэтому и возник вопрос.

З.Ы. Ну и вдобавок по индексированию тот же вопрос. Для какого из форматов оно наименее затратно по усилиям?

Abs62

Додумал как можно делать по стилям. Вместо удаления node можно заменять контент innerHTML на нужный. Так что в дальнейшем разделении стилей нет необходимости.

ramix
Присандалил замену обычного дефиса на неразрывный перенос. Вот, пробуйте - goldendict-1.5.0-RC2-32-g010b4dc(EXE only).7z

kvvic
В GD нет понятия языковых пар. Группы могут формироваться произвольно, поэтому привязывать к ним какую-то конкретную раскладку резона нет.

Romul81
Ну и замечательно.

Abs62
Я понимаю, что в ГД можно создать группу из любых словарей. Под языковыми парами я имел в виду группы, созданные автоматически, с помощью кнопки во вкладке группы. Эти группы создаются по языковым парам (en-ru, ru-en и т.д.).
Как я уже писал, на мой взгляд, было бы удобнее, если бы при выборе такой автоматически созданной группы менялась раскладка, как это реализовано в Лингво. Может есть другие варианты, о которых я не знаю, я поэтому и просил поделиться опытом.

Может можно сделать автоматически создаваемые группы двунаправленными (en-ru-en)? Тогда не нужно будет переключать раскладку при работе с этой группой.

Abs62
Спасибо! Сейчас смотрится ОК.

Abs62
Хочу узнать у вас - при поиске на странице (Ctrl+F) подключаются какие-то словари синонимов?