Архив рубрики: OJS

Узковатое меню

Open Journal Systems 3 вышла уже шесть лет назад — в 2016 году, но за всё это время русское меню, отображаемое администратору в шапке страниц в теме оформления, включенной по умолчанию (Manuscript), слишком узкое:

OJS 3 с узким административным меню

Я этот баг 🐞 видел, но как-то не до него было — я поддерживал старые журналы, сделанные ещё на OJS 2. Сейчас посмотрел — исправляется буквально изменением одного байта — github.com/pkp/ojs/pull/3618

Меню стало чуть шире

Когда пулл-реквест будет принят и это изменение появится в новых версиях OJS, пока не знаю, но кому не терпится, может добавить собственное стилевое правило:

@media (min-width: @screen-desktop) {
    .pkp_navigation_user {
        ul {
            width: 13em;
        }
    }
}

Переводы для темы оформления Manuscript лежат в plugins/themes/default/locale — можно найти слово «Администрирование» на разных языках и сравнить ширину:

grep -R 'msgid "navigation.admin"' -A 1 \
| sort \
| perl -nle 'print qq{<li title="$1">$2</li>} if m{^(.+)/.*msgstr "(.*)"}'
Список переводов
Ширина голубой части — 10em

Оказывается русское слово — самое длинное. И самое широкое, потому что буква и шире, чем i.

Почти что Геттекст

Open Journal Systems начиная с вышедшей в позапрошлом году версии 3.2 хранит переводы интерфейса не в XML-файлах, а использует для этого нечто, весьма напоминающее Gettext, но с некоторыми особенностями:

  • Переводы хранятся в обычных геттекстовских файлах *.po, но компилировать их в *.mo не надо. То ли сама OJS компилирует, то ли просто вручную разбирает файлы переодов — не знаю пока, не разбирал ещё так глубоко.
  • Вместо привычного для Геттекста использования в качестве ключей фраз естественного языка (обычно английского) в OJS по-прежнему ключами служат последовательности вида тема.подтема.словоИлиНесколько. Предположу, что так оставили для совместимости.
Electronic scientific journal uses Gettext and keys for translation. Cartoon style

И они ещё борются за звание дома высокой культуры и быта

2020 год, самый популярный веб-сервер — nginx, но у Open Journal Systems до сих пор нет документации по установке этой системы управления научным журналом под нужным сервером

We don’t have an official installation guide for it.

Предлагают и дальше читать форумы.

Отбросим костыли

В прошлую пятницу вышла Open Journal Systems 3.2.0.0 и там наконец-то имена авторов и пользователей многоязычны «из коробки», а не после танцев с бубном и применения костылей.

Попробовал завести пробный журнал с одной-единственной статьёй — вроде, работает, да и ввод стал поудобнее, чем в OJS 2. Но прямо сейчас я бы не стал переключать на новую версию даже одноязычные журналы — эта версия с глюками и на один из них я уже наткнулся.

Впрочем, готовиться к грядущим переездам уже можно — раз нынешняя версия позволит сразу создавать журналы, соответствующие требованиям ВАК, значит, будут и запросы на миграцию тех журналов, что сейчас работают с костылями — а их только моими руками сделано несколько штук плюс вполне возможно, что кто-то смог мои наработки применить самостоятельно.

Дополнение: 20 марта вышла версия 3.2.0-1 — там переключатель работает

Statt zu schlafen

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

Могу:

  • Программировать на Перле — как древние CGI-приложения и прочее легаси, так и современные, с использованием фреймворков Mojolicious, Dancer, Catalyst.
  • Программировать на PHP: в основном допиливать существующие приложения, а не писать с нуля что-то большое. Могу писать с нуля что-то мелкое с фреймворком Slim.
  • Настраивать CMS Drupal и WordPress, а также дорабатывать их темы оформления.
  • Настраивать и дорабатывать Open Journal Systems, включая реализацию многоязычности имён — делал это в OJS 2.4.2, 2.4.7.1, 2.4.8.1, думаю, и в Open Conference Systems смогу реализовать.
  • Кроссбраузерно верстать веб-страницы, применять адаптивный дизайн, грамотно использовать возможности HTML5 и CSS3.
  • Немножко программировать на Руби (в том числе, с использованием Ruby on Rails) — наверное, на юниорском уровне.
  • Немножко программировать на ЯваСкрипте — как голый JavaScript, так и с jQuery. Совсем чуть-чуть — nodejs, Angular, Vue.
  • Писать тесты на перле, пхп и руби.
  • Постоянно внушать коллегам необходимость использования багтрекера и системы контроля версий.
  • (хоть и не считаю это основными профессиональными навыками) фотографировать, петь, аккомпанировать на шестиструнной гитаре, преподавать, водить легковой автомобиль, быть Дедом Морозом, штурманом и инструктором по водному туризму, набирать ноты в MuseScore и LilyPond и тексты с формулами в TeX — медленно, но красиво.

1000 рублей

Хочу от 15 USD / 1 kRUB в час.


  1. Statt zu schlafen (нем.) — вместо того, чтобы спать
  2. Резюме — http://shoorick.ru/cv

Re: А воз и ныне там

Раз уж в третьем OJS так и не добавили многоязычность, попробую портировать свой хак на последнюю из версий второй ветки — 2.4.8.1. В прошлый раз, когда портировал из 2.4.2 на 2.4.7.1, обошёлся изменением не более, чем семидесяти трёх файлов, хотя если поискать все, где попадаются слова firstname, middlename, lastname, fullname и citation, получится почти в пять раз больше. И это ещё без учёта файлов с переводами */locale/*.xml

diff

Поглядим через неделю-другую, что получится.

А воз и ныне там

В Open Journal Systems данные людей — пользователей и авторов — могут быть только на одном языке. В багтрекере уже шесть лет висит bug 5598 — allow for author names in multiple languages. В последнем комментарии разработчик честно сообщает:

This hasn’t yet been prioritized for a specific release, but I’d say it’s very unlikely to be implemented for OJS 2.x; it’ll become a higher priority after OJS 3.0 is released.

Итак, OJS 3.0.0 вышла — и действительно, ничего не поменялось: раз эта задача не была приоритетной, то и многоязычности нет.

SQL-запрос

Значит, придётся и дальше поддерживать свой хак, пытаясь всё-таки сделать из него нормальный плагин.

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

Как и ожидалось, 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 для этого плохо подходят (хотя можно и с ними — я так делал) — хочется всё-таки использовать специализированное решение, избежав при этом танцев по граблям.

Собственные переводы интерфейса 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>

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

Указание языка в URL страниц в Open Journal Systems

Open Journal Systems — система управления электронными научными журналами — имеет одинаковые адреса страниц, написанных на разных языках. Посетитель, зашедший на сайт научного журнала, работающего на OJS, либо увидит страницу на языке по умолчанию либо, если раньше уже заходил и менял язык, на том, что выбрал. Кому-то такой подход нравится, кому-то — нет. На самом деле — вполне нормальная ситуация.

Тем не менее, возникла задача всё-таки получить возможность явно указать язык в адресе страниц. Переключение выбранного языка делается средствами самой OJS — достаточно зайти (то есть, выполнить GET-запрос) по адресу вида адрес-журнала/user/setLocale/локаль?source=путь/куда/идти/дальше, например, http://vestnik.susu.ru/cmi/user/setLocale/ru_RU?source=/cmi/issue/current — переход по этой ссылке приведёт к выведенному на русском языке оглавлению текущего выпуска серии «Вычислительная математика и информатика» Вестника Южно-Уральского государственного университета.

С одной стороны, всё украдено до нас ничего делать не надо — URL с указанием языка уже доступен. Но какой-то он длинный, неаккуратный. Хочется сделать покороче. Чтоб не лезть во внутренности OJS, можно исправить настройки сервера. Для случая, когда используется Apache, а адрес журнала имеет вид http://hostname/journal, достаточно добавить пару правил для mod_rewrite:

RewriteRule ^en(glish)?/(\w+)(/?.*)$ /$2/user/setLocale/en_US?source=/$2$3 [L]
RewriteRule ^ru(ssian)?/(\w+)(/?.*)$ /$2/user/setLocale/ru_RU?source=/$2$3 [L]

Это даст возможность использовать URL вида http://hostname/язык/journal/путь, где язык может быть как названием нужного языка, так и его двухбуквенным кодом. Для уже рассмотренной серии «Вестника ЮУрГУ» теперь можно применять такие ссылки: