«Локализатор исходного кода» предназначен для локализации программных продуктов путем изменения их исходных кодов без предварительной подготовки.
Программа может быть использована при разработке программного обеспечения на серверах сборки, для автоматической локализации исходного кода, но она может также применяться и на рабочих компьютерах пользователей для проверки орфографии в исходных кодах, текстовых файлах, буфере обмена и словарях переводов.
Специальная версия программы позволяет проводить обфускацию исходного кода.


 

суббота, 5 октября 2013 г.

Словарь локализатора GPL. Почему его нет?

Для крупных проектов существует множество инструкций и советов, но нет (не нашел) словарей орфографии, которые можно было бы использовать переводчиками и тестировщиками.

Если загрузить перевод в текстовый редактор, например, в OpenOffice или другой поддерживающий словари орфографии, например, Notepad, то целый ряд слов будет подчеркнут, как ошибки. Это в первую очередь относится к терминам и названиям, которых нет в словарях.
Между такими терминами и названиями легко "прячутся" ошибки, которых не заметно на фоне множества ложных срабатываний.

Кроме того, "устоявшиеся термины" и прочее можно было бы добавить в такой словарь, чтобы при ошибке в термине было сразу ее видно.

Пример: "Словарь устоявшихся терминов" http://team.ubuntu.ru/translate/словарь_переводов

В примечании к "кеш" (по ссылке к слову):
  Уважаемые переводчики, использующие слово "кеш"!
  Пожалуйста, пишите правильно - "кэш". Спасибо. --Артём

Если слово "кэш" добавить в словарь, как и ряд других, то подчеркнутое слово "кеш" явно подскажет локализатору об ошибке.

Отличным примером является название "Ши-сен-сё" и второй его вариант "Ши-сён-сё", встречающийся в переводе OpenSuse. При наличии правильной версии данного названия
в словаре локализатор сразу бы увидел ошибку.

Наиболее распространенными являются словари для утилиты hunspell, но также можно использовать словари пользователей для OpenOffice.

Для начала рассмотрим формат OpenOfice, основной пользовательский словарь standard.dic, который имеет следующее содержание:


OOoUserDict1
lang: <none>
type: positive
---
А-Яа-я
Автосокращение
Жи
Кадрировать
Конфигурирование

Судя по содержимому, первая строка - это формат словаря, вторая - язык, третья - тип.
Для OpenOffice существует два типа словаря: позитивный - разрешающий слова, и негативный - запрещающий

Наш выбор: позитивный, для всех языков. Т.е., как в примере.

Добавлять слова в словарь очень просто: правой кнопкой мыши в OpenOffice нажать на слово с ошибкой (по мнению OpenOffice), "Добавить", выбрать словарь.

Такой словарь легко разместить в svn/git/пр. и отслеживать его содержимое, а также просто добавлять в него слова через обычный текстовый редактор.

Наиболее популярный hunspell имеет значительно более сложную структуру, позволяющую учитывать варианты склонения слова.
Но в нашем случае для простоты использования словаря предлагаю не использовать склонения, которые довольно сложно описываются и не подойдут для общего использования.
Если использовать только слова без учета склонений, то структура словаря станет очень простой:

5
один
два
три
четыре
пять

Официальное описание:
http://mozilla-russia.org/projects/dictionary/hunspell.html

Краткое:
Первая строка - примерное количество слов, далее идут слова.

Подключить свой словарь к NotePad++ не получилось. Вероятно, нельзя добавлять произвольные словари, даже с правильным (ru_RU_mydictionary) оформлением названий.
Но простое добавление слов в стандартный словарь ru_RU решает проблему ошибок.

Поэтому одним из вариантов является использование списка слов в репозитории, из которого генерируются словари (на сервере сборки) для OpenOffice и "правильный" словарь hunspell на базе одного из GPL-словарей ru_RU, соответственно тоже под GPL-лицензией (или есть нюансы нарушающие лицензию GPL?).

Словари hunspell широко используются различными редакторами и программами перевода, например, OmegaT.

Словари под лицензией GPL и ее производных часто используются в программах, соответственно без включения их в состав программ:
см. http://www.omegat.org/en/howtos/spelling.html

Если у групп локализации будут подобные словари, то это улучшит качество перевода самих групп и позволит использовать словари других групп (о чем сами группы пишут - см. ниже) без нарушения лицензий.

Сами группы локализации указывают ссылки на ресурсы других групп.
Например, группа локализации Ubuntu (http://team.ubuntu.ru/translate/%D1%87%D0%B0%D0%B2%D0%BE):
указывает ссылку на свою wiki: "Словарь устоявшихся терминов", а также "http://engcom.org.ru/ (используется переводчиками GNOME)", "http://multitran.ru (вариантов выдаёт много, но если в других ничего нет…)"

Поэтому нет ничего плохого в публичных словарях локализаторов, которые помогут всем.

Разработчики проприетарных продуктов смогут их использовать как отдельные компоненты, не нарушая лицензий (см. выше).

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

Почему еще нет таких словарей под GPL? Если есть, то где их искать?

Пример улучшения проверки можно увидеть в отчетах к посту http://sourcelocalizer.blogspot.ru/2013/09/opensuse.html по OpenSuse, в начале которого приведен отчет с большим количеством ошибок, подавляющее число которых являются названиями и терминами. При редактировании такой документации с проверкой орфографии текст вероятно "пестрит" "ошибками"... при наличии словаря терминов, ошибки будут сразу видны - см. отчет из Update, после внесения 1,5 тыс слов в словарь... еще есть ложные срабатывания (не все ввел в словарь), но в целом, ошибки сразу видно.

Буду рад советам и комментариям по этой теме, особенно по наследованию лицензий gpl/lgpl/пр. в данном случае.

Надеюсь подобные словари появятся... или будут опубликованы, так как локализаторы явно такие словари хотя бы для себя составляют.

1 комментарий: