Программистам на подумать

[doldonius]

Предложение насчет i18n прибили тапком. Резоны:

1. Интерфейс системы перевода (видимо, речь об унаследованной от LJ) совершенно ни к черту;

2. Очень трудно координировать работу переводчиков-добровольцев;

3. Они не знают, как сделать, чтобы стало легко поддерживать перевод в актуальном состоянии (что, видимо, обусловлено ровно теми же причинами, что проблема 2).

Кроме того, в старом подробном разборе упомянуто, что в LJ i18n сделана типичным пыхопоидальным методом: вместо текста в страницу впыживается запрос к базе данных. Так делают все пыхопоиды — следовательно, это неправильно. Должен существовать Правильный Способ, одновременно уменьшающий нагрузку на серверы и облегчающий жизнь как англоязычным кодерам, так и переводчикам.

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

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

На этом остановлюсь, ибо опасно близок к русской программистской идее (переписать все к разэтакой матери с нуля). Что скажете, сэры? Не попадался ли где ровно такой велосипед? И если нет, насколько сложно его изобрести?

Comments

[link01]

Симпатичная система перевода сделана в Qt, хотя здесь она годится только в качестве источника вдохновения.


Текстовые сообщения Qt встраиваются в код, и каждое сообщение, предназначенное для последующего перевода, заворачивается в макрос tr(). После окончания отладки наступает очередь переводчика; он натравливает на код инструмент под названием Qt Linguist, который находит эти сообщения и позволяет переводчику создавать дополнительные файлы с текстами переводов. Эти дополнительные файлы подхватываются приложением во время работы в зависимости от какой-то переменной окружения ($LANG или $LOCALE).

Главное - что
1) Сообщения хранятся в тексте программы. Переводы хранятся в дополнительных файлах и подхватываются во время исполнения.
2) Сообщения (и переводы)
- целостны; они не разбиваются на мелкие части а-ля cout << numFiles << "files of" << totalFiles << "totalFiles read.\n".
- уникальны; для двух одинаковых сообщений в разных местах придется делать два перевода.
3) сообщения заворачиваются в макрос tr(), что
- позволяет Qt Linguist автоматически искать их в тексте,
- обеспечивает подковерную автоматику по поиску и замене исходного текста переводом во время исполнения.

Выглядит это примерно так:

statusBar()->showMessage(tr("Loaded %1").arg(fileName), 2000);

(%1 и .arg(fileName) - это слегка мутировавший printf; fileName подставляется на место %1.)

[doldonius]

для двух одинаковых сообщений в разных местах придется делать два перевода.

Хм. Аккуратный пас :)

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

Кроме того, есть механизм автоматического переключения языка, встроенный прямо в HTTP (см. http://212.75.221.62/test/ — заодно узнаем, не накосячил ли я чего с фаерволом; понимает en, ru и zh).

Если content negotiation работает и с PHP, действительно можно переводить именно страницами. Не факт, что это удобнее, чем явный выбор переключалкой на сайте, но зато в большинстве случаев юзер по умолчанию сразу получает то, что ему ближе. Вдобавок, это позволяет избежать каши на недопереведенных страницах, страшно смущающей местное начальство: либо перевод есть, либо его нет (и выдается исходная английская страница).

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

[doldonius]

"GET /test/?lang=ru HTTP/1.1"

Не-а. Чистый HTTP1.1, как он есть. Выдает то, что просил твой браузер.

st@apex:/var/www/test$ ls
index.html.en  index.html.ru  index.html.zh
st@apex:/var/www/test$

[link01]

http://212.75.221.62/test/
У меня выдает "Hello!" стилем h1.

Перевод средствами apache - это очень заманчиво, хотя и вносит небольшое количество ошибок (человек не сможет вставить в свою заметку слова "Help" или "Home"). Я пока слабо представляю себе, что умеет этот content negotiation, и с чем его едят. Ушел читать и думать.

Системы совместной разработки - не работал я никогда совместно, ничего не могу сказать (краснеет). :))) Думаю, что
1) все системы умеют примерно одно и то же,
2) придется использовать ту систему, которую использует команда Dreamwidth - у них, скорее всего, есть вполне рабочая служба оповещения об изменениях.

[link01]

Ну прям нельзя и... :)))

[link01]

В любом случае, мне придется искать, где в браузере можно сказать AcceptLanguage: ru. Или перекомпилировать браузер.

Тут, скорее всего, надо раздавать переводы не по запросу браузера, а смотреть в DNS, откуда человек запрашивает.

[doldonius]

Вот наиболее интересный вариант пока что:

http://www.w3.org/QA/2006/02/content_negotiation.html

[link01]

Угу. Читаю.

[doldonius]

Перевод средствами переводчиков :) Апач только выдает файлы на языке, запрошенном браузером (либо, если я правильно понял, на первом языке, указанном в списке в конфиге — разумеется, по дефолту en).

[link01]

Мысль: если уговорить команду Dreamwidth обрамлять каждое сообщение специальным символом, замаскированным под комментарий, например <!--tr-begin--> и <!--tr-end--> (или лучше вот так - <!--tr-begin-10552--> и <!--tr-end-10552-->, где 10552 - уникальный номер сообщения в базе), то, скорее всего, после формирования страницы и до выдачи ее пользователю apache позволит прогнать ее через дополнительный фильтр.

[link01]

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

Делать полноценную систему перевода (и распределения работы переводчиков), встроенную в движок Dreamwidth, - дело крайне сложное.

Но мы можем
1) в выдаваемой движком странице отмечать строки, требующие перевода, специальными значками, замаскированными под комментарии HTML,
2) перед выдачей страницы пользователю пропускать ее через дополнительный фильтр, который ищет разметку и заменяет нужные строки на их переводы.

Таким образом, система перевода потребует минимального вмешательства в движок.

[link01]

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

[doldonius]

Не надо булочную.

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

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

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

Приветик!

[link01]

Получилось. :)

[doldonius]

При укрупнении объекта до целой страницы проблема распределения в значительной степени отвалится. Лишь бы двое и более не могли одновременно за один текст ухватиться. Хорошо, если будет еще и виден статус каждого объекта: "переводит такой-то", "редактирует сякой-то", "доступен для редактирования", "не переведен". Как по мне, этого вполне достаточно.

Внешний фильтр, отыскивающий вручную расставленные тэги, хоть как тормознее и жручее выбора нужного статического файла по include "filename.ext.$lang".

[link01]

ОК. Моя есть подумать. Разве что вот это -
Страницы формируются на основе постоянных шаблонов.
надо проверить. Возможно, шаблоны размечены цифрами, которые означают номер строки в базе.

[link01]

На сегодня у меня все. :)

[doldonius]

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

[link01]

Что удалось выяснить: LJ написан на Perl с дополнительным уровнем в виде языка BML - личного изобретения Фитцпатрика. К основным страницам с расширением .bml прилагается файл с сообщениями с расширением .bml.text; как это выглядит, можно посмотреть здесь:

http://code.livejournal.org/trac/livejournal/browser/trunk/htdocs/update.bml
http://code.livejournal.org/trac/livejournal/browser/trunk/htdocs/update.bml.text

Например, в update.bml формируется какой-то заголовок:

$$title = $ML{'.error.cantpost.title'};

Значение .error.cantpost.title берется из update.bml.text:

.error.cantpost.title=Can't Post

Perl-а я не знаю, библиотеки огромные, поэтому что делает $ML с .error.cant.post, для меня это страшная тайна. (Возможно, $ML определено в $LJHOME/cgi-bin/Apache/BML.pm, который я нашел в моей инсталляции, но который почему-то не отображается в репозиториях LJ и DW.)

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

Далее. Система перевода включает в себя несколько таблиц (ml_text, ml_domain и др.) К этим таблицам определенно имеет отношение файл сообщений для английского языка

http://code.livejournal.org/trac/livejournal/browser/trunk/bin/upgrading/en.dat

Скорее всего, ключами в таблицах переводов являются строки типа ".error.cantpost.title".

Пока что больше ничего не известно. Выводы:

1) Отображение целостной страницы для переводчика представляется проблематичным.
2) Скорее всего, придется использовать фитцпатриковскую систему перевода отдельных сообщений.
3) Зато можно оценить объем перевода, исходя из размера en.dat; около 150K.

[doldonius]

То есть, Дениз права: проще новых нарожать, чем этого вымыть :(

С другой стороны, нам явлен достойный пример, превзойти который проще, чем два байта переслать. Один пых выкинуть — уже 99.9% гемора долой.

Н-да. "Принеси мне сакэ. Я буду пить и думать" :)))

[link01]

Мысль (да, я знаю, что "залипание" характерно для шизофрении): проблема со строками заключается в том, что никто не знает, где какая строка хранится, где она подхватывается, преобразуется и переводится в этом многоуровневом и многокомпонентном глючеве.

Эта проблема решается тупо и в лоб: имея тестовую инсталляцию, можно найти, допустим, 50 файлов, в которых хранятся исходные строки. Составляем каталог файлов и строк, и в каждую строку дописываем ее уникальный номер. Было "Cannot Post", стало "882 Cannot Post". Помеченная строка проходит через все уровни глючева (о которых теперь можно забыть) и отображается на готовой странице. В результате мы сразу видим, к какой странице относится какое сообщение - и задача пития сакэ кувшинамипостраничного перевода сразу упрощается.

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

[doldonius]

И как оно?

P. S. Страшно смущает это "Link" под каждым комментарием. Так и тянет ткнуть, чтобы ответить :)

[link01]

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

[link01]

Дениза письмо прислала. Говорит - ты с ума сошелэто очень трудно, если хочешь этим заниматься - ответь на это письмо, и мы дадим тебе аккаунт." - Ответил. Продолжаю наблюдение.

[doldonius]

Я тоже потихоньку продолжаю мысли думать.

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

В данном случае, конечно, хоть как получится система костылей. Такие штуки все-таки надо сразу закладывать. Но можно по крайней мере сделать костыли не сцепленными, как в LJ.

[temmokan]

Устроит ли gettext? Популярная вещь, файлы переводов (исходники) чисто текстовые, координировать обновление таких не слишком сложно.

Вроде бы на drupaler.ru создание переводов для Drupal (через gettext) вполне отлаженный процесс

[doldonius]

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

[link01]

Очередной раунд переписки. Дениз предлагает начать длинную и обстоятельную беседу в dw_dev, я отвечаю "спасибо, посмотрим" и продолжаю просить аккаунт. :)

[temmokan]

Контекст нужен в любом случае. Говоря конкретно о gettext, там уже собран весь инструментал для сбора текстовых строк и создания контекста (как в смысле комментариев к тому, что надо перевести, так и в смысле namespace).

[doldonius]

Можно и начать, чего б не начать. Они нас еще не знают, а когда узнают — поздно будет :) Зови, если что.

[doldonius]

Комментарий — это хорошо, но полного контекста не заменяет. Я по этим граблям уже гулял. Переводишь, запускаешь программу, смотришь свои переводы в контексте, хватаешься за голову, опять лезешь в файл, и так много раз.

Впрочем, как говорят хирурги, "разрежем — посмотрим".

[link01]

Ну, дык. :) Только что Софи прислала мне логин/пароль, все работает, вечером приступим. Я им пообещал, что если найду чего интересного, напишу в dw_dev.