![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Программистам на подумать
Предложение насчет i18n прибили тапком. Резоны:
1. Интерфейс системы перевода (видимо, речь об унаследованной от LJ) совершенно ни к черту;
2. Очень трудно координировать работу переводчиков-добровольцев;
3. Они не знают, как сделать, чтобы стало легко поддерживать перевод в актуальном состоянии (что, видимо, обусловлено ровно теми же причинами, что проблема 2).
Кроме того, в старом подробном разборе упомянуто, что в LJ i18n сделана типичным пыхопоидальным методом: вместо текста в страницу впыживается запрос к базе данных. Так делают все пыхопоиды — следовательно, это неправильно. Должен существовать Правильный Способ, одновременно уменьшающий нагрузку на серверы и облегчающий жизнь как англоязычным кодерам, так и переводчикам.
По интерфейсу. Как переводчик, я бы предпочел видеть соответствующую страницу целиком и переводить по надписи за раз легким тычком мыша, ибо качество перевода очень зависит от доступности контекста. Впрочем, мне-то не в падлу и напрямую исходники страницы править. Но тогда и текст должен быть прямо в странице — что, опять же, говорит о пагубной греховности пыхпыховой методы.
По координации и своевременности переводов. Нужна система оповещений об изменениях английских исходников. Внес кодер изменения — у переводчиков загорелась лампочка. Кроме того, нужна система блокировок, чтобы все разом не хватались за одно и то же, но при этом любой перевод должен становиться редактируемым после того, как текущий переводчик его закоммитит.
На этом остановлюсь, ибо опасно близок к русской программистской идее (переписать все к разэтакой матери с нуля). Что скажете, сэры? Не попадался ли где ровно такой велосипед? И если нет, насколько сложно его изобрести?
1. Интерфейс системы перевода (видимо, речь об унаследованной от LJ) совершенно ни к черту;
2. Очень трудно координировать работу переводчиков-добровольцев;
3. Они не знают, как сделать, чтобы стало легко поддерживать перевод в актуальном состоянии (что, видимо, обусловлено ровно теми же причинами, что проблема 2).
Кроме того, в старом подробном разборе упомянуто, что в LJ i18n сделана типичным пыхопоидальным методом: вместо текста в страницу впыживается запрос к базе данных. Так делают все пыхопоиды — следовательно, это неправильно. Должен существовать Правильный Способ, одновременно уменьшающий нагрузку на серверы и облегчающий жизнь как англоязычным кодерам, так и переводчикам.
По интерфейсу. Как переводчик, я бы предпочел видеть соответствующую страницу целиком и переводить по надписи за раз легким тычком мыша, ибо качество перевода очень зависит от доступности контекста. Впрочем, мне-то не в падлу и напрямую исходники страницы править. Но тогда и текст должен быть прямо в странице — что, опять же, говорит о пагубной греховности пыхпыховой методы.
По координации и своевременности переводов. Нужна система оповещений об изменениях английских исходников. Внес кодер изменения — у переводчиков загорелась лампочка. Кроме того, нужна система блокировок, чтобы все разом не хватались за одно и то же, но при этом любой перевод должен становиться редактируемым после того, как текущий переводчик его закоммитит.
На этом остановлюсь, ибо опасно близок к русской программистской идее (переписать все к разэтакой матери с нуля). Что скажете, сэры? Не попадался ли где ровно такой велосипед? И если нет, насколько сложно его изобрести?
no subject
Текстовые сообщения 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.)
no subject
Хм. Аккуратный пас :)
Вернемся, однако, к жертвам пыха. Скорее всего, на стороне сервера каждая страница представляет собой мерзкую мешанину, как при пыханьи и положено. Но основа относительно стабильна.
Кроме того, есть механизм автоматического переключения языка, встроенный прямо в HTTP (см. http://212.75.221.62/test/ — заодно узнаем, не накосячил ли я чего с фаерволом; понимает en, ru и zh).
Если content negotiation работает и с PHP, действительно можно переводить именно страницами. Не факт, что это удобнее, чем явный выбор переключалкой на сайте, но зато в большинстве случаев юзер по умолчанию сразу получает то, что ему ближе. Вдобавок, это позволяет избежать каши на недопереведенных страницах, страшно смущающей местное начальство: либо перевод есть, либо его нет (и выдается исходная английская страница).
Прочее (уведомления об изменениях, блокировки, автоматическое задвигание старых версий переводов в тень при изменении оригинала) должна уметь какая-нибудь система совместной разработки. Видел где-нибудь такое?
no subject
Не-а. Чистый HTTP1.1, как он есть. Выдает то, что просил твой браузер.
no subject
Приветик!
no subject
Тут, скорее всего, надо раздавать переводы не по запросу браузера, а смотреть в DNS, откуда человек запрашивает.
no subject
http://www.w3.org/QA/2006/02/content_negotiation.html
no subject
no subject
У меня выдает "Hello!" стилем h1.
Перевод средствами apache - это очень заманчиво, хотя и вносит небольшое количество ошибок (человек не сможет вставить в свою заметку слова "Help" или "Home"). Я пока слабо представляю себе, что умеет этот content negotiation, и с чем его едят. Ушел читать и думать.
Системы совместной разработки - не работал я никогда совместно, ничего не могу сказать (краснеет). :))) Думаю, что
1) все системы умеют примерно одно и то же,
2) придется использовать ту систему, которую использует команда Dreamwidth - у них, скорее всего, есть вполне рабочая служба оповещения об изменениях.
no subject
no subject
no subject
Делать полноценную систему перевода (и распределения работы переводчиков), встроенную в движок Dreamwidth, - дело крайне сложное.
Но мы можем
1) в выдаваемой движком странице отмечать строки, требующие перевода, специальными значками, замаскированными под комментарии HTML,
2) перед выдачей страницы пользователю пропускать ее через дополнительный фильтр, который ищет разметку и заменяет нужные строки на их переводы.
Таким образом, система перевода потребует минимального вмешательства в движок.
no subject
Основная единица сайта — страница. Страницы формируются на основе постоянных шаблонов. Вот эти-то шаблоны и переводить. Атомарно сразу все файлы, относящиеся к одной странице. Переводчикам это срежет кучу напрягов, поскольку хотя бы локальный контекст полностью и сразу доступен. И сервакам легче, меньше будет запросов к тормознущим реляционным базам. В базу лазить только за тем, что из нормальных файловых систем добыть действительно сложнее: хитрыми выборками по куче параметров (как, например, при формировании ленты).
LJшная система потому и сделалась монстром, что там исходили из практики интернационализации программ и штампов пыхового кодинга. Если идти от задачи и практики совместного перевода, всем сразу резко полегчает. Максимум тут может пригодиться подсветка кода, чтобы выводимые на экран строки еще легче искать стало.
Вот что надо сделать, так это словарь, чтобы одно и то же везде было переведено одинаково, насколько контекст позволит. Но и тут, опять-таки, переводчики сами управятся с минимальной помощью программистов.
no subject
Страницы формируются на основе постоянных шаблонов.
надо проверить. Возможно, шаблоны размечены цифрами, которые означают номер строки в базе.
no subject
no subject
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.
no subject
С другой стороны, нам явлен достойный пример, превзойти который проще, чем два байта переслать. Один пых выкинуть — уже 99.9% гемора долой.
Н-да. "Принеси мне сакэ. Я буду пить и думать" :)))
no subject
Эта проблема решается тупо и в лоб: имея тестовую инсталляцию, можно найти, допустим, 50 файлов, в которых хранятся исходные строки. Составляем каталог файлов и строк, и в каждую строку дописываем ее уникальный номер. Было "Cannot Post", стало "882 Cannot Post". Помеченная строка проходит через все уровни глючева (о которых теперь можно забыть) и отображается на готовой странице. В результате мы сразу видим, к какой странице относится какое сообщение - и задача
пития сакэ кувшинамипостраничного перевода сразу упрощается.В общем, завтра я попробую заполучить себе тестовый экземпляр dreamwidth - они раздают аккаунты со свежими экземплярами, а там посмотрим.
no subject
P. S. Страшно смущает это "Link" под каждым комментарием. Так и тянет ткнуть, чтобы ответить :)
no subject
no subject
ты с ума сошелэто очень трудно, если хочешь этим заниматься - ответь на это письмо, и мы дадим тебе аккаунт." - Ответил. Продолжаю наблюдение.no subject
Все-таки страницу разбивать нельзя. Даже если в нее вставляются другие повторяющиеся элементы, всё, что юзер видит за один раз, в смысле перевода надо как-то увязывать в единый объект (в том числе и в системе контроля версий). В принципе, оно бы и в разработке сгодилось, но для перевода это жизненно важно.
В данном случае, конечно, хоть как получится система костылей. Такие штуки все-таки надо сразу закладывать. Но можно по крайней мере сделать костыли не сцепленными, как в LJ.
no subject
no subject
no subject
Внешний фильтр, отыскивающий вручную расставленные тэги, хоть как тормознее и жручее выбора нужного статического файла по include "filename.ext.$lang".
no subject
Вроде бы на drupaler.ru создание переводов для Drupal (через gettext) вполне отлаженный процесс
no subject
no subject
no subject
Впрочем, как говорят хирурги, "разрежем — посмотрим".
no subject
no subject
no subject