Архив рубрики: язык

Склоняем точнее

Мы стали более лучше одеваться^W^W^W правильнее склонять имена с фамилиями. Вчера вышла свежая версия предназначенного для этого перлового модуля Lingua::RU::Inflect (он же есть и на гитхабе — чуть свеже́е, чем на CPAN).

Фрагмент документации модуля Lingua::RU::Inflect

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

Итак, в новой версии:

  • Закрыты все имевшиеся по состоянию на вчерашний день issues, в том числе
  • Исправлена проблема с экспортом всего возможного оператором — компилятор теперь не ругается на попытку экспортировать функции, убранные в другой модуль.
  • Имена с беглыми гласными (Лев, Павел) и некоторые фамилии на -ец (Песец, Писец, Боец и Отец) стали склоняться правильно — беглая гласная убегает, как ей и положено. Там, где убегать не положено (Швец, Жнец,  Надудеигрец и полный крах, крушение всех надежд — шесть букв, вторая И, но не фиаско) — не убегает.
  • Женские фамилии, оканчивающиеся на -ов, -ёв, -ин, -ий, -ый — похожие на мужские, но всё-таки женские — перестали склоняться.
  • Мужские фамилии, оканчивающиеся на -их и -ых, могут всё-таки склоняться: например, Бултых, Жмых, Отдых, Дитрих, Рерих, Ульрих, Фрейндлих и Эрлих склоняются, а Синих, Серых, Карих, Чёрных — нет.
  • Точнее определяются имена, нехарактерные для русских и не подпадающие под обычное правило: женские оканчиваются на -а и -я, мужские — на согласную. В списки исключений добавлено несколько десятков имён. Определитель теперь знает тюркоязычные и исландские отчества.

В итоге количество ошибок на тестовом наборе данных сократилось в 2–3 раза, до одной ошибки на 200–300 человек — есть неочевидные случаи, потому и оценка приблизительна. Двойные имена и фамилии пока слоняются неправильно — исправлю как-нибудь потом.

Compose не работает в musescore

Для того, чтоб изредка набрать буквы соседних языков (рәхим итәгеҙ!) достаточно настроить нужные последовательности для клавиши Compose и пользоваться ими. Но такой фокус не всегда удаётся: например, нотный редактор musescore (во всяком случае, в версии 2.0.2) как-то по-своему обрабатывает клавиатурные события и при нажатии клавиши Compose сразу же отображает ?!, воспринимая следующие клавиши как совершенно обычные. Поэтому при попытке ввести i десятеричное получается ?!ии. Получается, что в musescore нельзя ни дореволюціонные тексты вводить, ни украинские.

Самый простой выход в такой ситуации — поставить украинскую раскладку.

Из одной бочки разливали

Как и ожидалось, Open Conference Systems, якобы не имеющая русской локализации, при должном применении напильника вполне способна использовать великий и могучий. В каталоге lib/pkp даже можно найти русские локализационные XML-файлы. Вообще весь этот каталог lib/pkp — общий и для OCS, и для OJS, что видно по гитхабу. Правда, в свежей версии Open Journal Systems переводов всё-таки побольше. Похоже, OCS, как не особо активно развиваемый продукт, содержит в себе копию lib/php трёхлетней давности, во всяком случае файлы lib/php/locale/ru_RU/*.xml — как раз 2012 года. Надо провести эксперимент — подсунуть в древнюю OCS 2.3 переводы из свежей OJS 2.4.7-1 — скорее всего, хуже не будет. Я пока заметил только один недостаток, мешающий тупо скопировать локализационные файлы: “User Home” переведено как «Мои журналы» — как-то неправильно показывать такое на сайте конференции.

Кстати, коллеги, кто-нибудь пробовал использовать Open Conference Systems для создания сайтов конференций? WordPress и mojowka для этого плохо подходят (хотя можно и с ними — я так делал) — хочется всё-таки использовать специализированное решение, избежав при этом танцев по граблям.

Многоязычное

За прошедшие сутки, как и почти в любой другой день, читал тексты и слушал речь на двух естественных языках — русском и английском — и держал в голове ещё кучу других: языков программирования да языков разметки. Как минимум, пришлось читать код на Perl, PHP, Bash и Ruby. Ну и, вроде, чё-то в браузерном отладчике смотрел — значит, ещё и HTML с CSS. И, наверное, JavaScript там же.

Два плюс семь — получается девять языков параллельно. Добавим LilyPond — будет десять. Это не вредно? 🙂

Собственные переводы интерфейса OJS

Open Journal Systems — многоязычная система: многие её части могут быть переведены на разные языки. Не все, конечно: например, в материалах статей некоторые поля по странной прихоти разработчиков (или просто по невнимательности) остались одноязычными и добавить в них возможность правильно хранить данные на нескольких языках — не самая простая задача: я, например, так её и не завершил. В версиях 2.4.* нормальной многоязычности статей не будет — возможно, такое положение и объясняет тот факт, что в России OJS не особо популярна — она без применения напильника непригодна даже для тех журналов, где надо всего лишь продублировать имя русского автора статьи латинскими буквами.

С переводом интерфейса дела обстоят чуть получше: переведено может быть почти всё. Но и тут не всё гладко: вместо gettext применяется другой механизм локализации, где ключами служат не фразы на естественном языке (например, английском), а строки вида where.what.someItem. Переводы хранятся в XML-файлах, раскиданных по дереву каталогов. Впрочем, бо́льшая их часть сосредоточена в locale/ и lib/pkp/locale.

Есть два пути внедрения своих собственных переводов: первый, очевидный — отредактировать системные XML-файлы с переводами, плох тем, что при первом же обновлении OJS собственные переводы могут пропасть или вызвать конфликт слияния, если обновление проводится через git. Другой, более правильный — использовать плагин Custom Locale: он позволяет заменить системные переводы своими, не трогая системные файлы. Для того, чтоб заменить какой-либо фрагмент, надо знать ключ, а также файл, где перевод определён. Процесс замены переводов получается таким: сначала ищем, где и как определён нужный текст, затем идём на http://some-ojs-site/journal_name/manager/plugin/generic/customlocaleplugin/edit/ru_RU (если меняем русский текст), ищем в увиденном списке нужный файл, затем пытаемся найти в нём нужный ключ. Поиск там, вроде, есть, но, во-первых, ищет только в пределах текущего файла и умеет искать только точное соответствие с ключом — ничего более. Понятно, что такой интерфейс не нужен: лучше обходиться без него. Плагин хранит изменённые переводы в виде XML-файлов, которые складывает в public/journals/journal_id/customLocale/locale/path, где journal_id — номер журнала, locale — язык в виде язык_СТРАНА, например en_US — американский английский, а path — путь к заменяемым XML-файлам относительно каталога, где установлена OJS.

Пример: некий файл public/journals/1/customLocale/ru_RU/lib/pkp/locale/ru_RU/common.xml заменяет строки из файла lib/pkp/locale/ru_RU/common.xml:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE locale SYSTEM "../../../../../../../../../lib/pkp/dtd/locale.dtd">
<locale name="ru_RU">
	<message key="navigation.about">О журнале</message>
	<message key="navigation.setup">Настройка журнала</message>
	<message key="common.notApplicableShort"> </message>
</locale>

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