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

[doldonius]

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

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

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

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

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

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

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

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

Comments

[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.