Программистам на подумать
Sep. 18th, 2010 09:56 amПредложение насчет i18n прибили тапком. Резоны:
1. Интерфейс системы перевода (видимо, речь об унаследованной от LJ) совершенно ни к черту;
2. Очень трудно координировать работу переводчиков-добровольцев;
3. Они не знают, как сделать, чтобы стало легко поддерживать перевод в актуальном состоянии (что, видимо, обусловлено ровно теми же причинами, что проблема 2).
Кроме того, в старом подробном разборе упомянуто, что в LJ i18n сделана типичным пыхопоидальным методом: вместо текста в страницу впыживается запрос к базе данных. Так делают все пыхопоиды — следовательно, это неправильно. Должен существовать Правильный Способ, одновременно уменьшающий нагрузку на серверы и облегчающий жизнь как англоязычным кодерам, так и переводчикам.
По интерфейсу. Как переводчик, я бы предпочел видеть соответствующую страницу целиком и переводить по надписи за раз легким тычком мыша, ибо качество перевода очень зависит от доступности контекста. Впрочем, мне-то не в падлу и напрямую исходники страницы править. Но тогда и текст должен быть прямо в странице — что, опять же, говорит о пагубной греховности пыхпыховой методы.
По координации и своевременности переводов. Нужна система оповещений об изменениях английских исходников. Внес кодер изменения — у переводчиков загорелась лампочка. Кроме того, нужна система блокировок, чтобы все разом не хватались за одно и то же, но при этом любой перевод должен становиться редактируемым после того, как текущий переводчик его закоммитит.
На этом остановлюсь, ибо опасно близок к русской программистской идее (переписать все к разэтакой матери с нуля). Что скажете, сэры? Не попадался ли где ровно такой велосипед? И если нет, насколько сложно его изобрести?
1. Интерфейс системы перевода (видимо, речь об унаследованной от LJ) совершенно ни к черту;
2. Очень трудно координировать работу переводчиков-добровольцев;
3. Они не знают, как сделать, чтобы стало легко поддерживать перевод в актуальном состоянии (что, видимо, обусловлено ровно теми же причинами, что проблема 2).
Кроме того, в старом подробном разборе упомянуто, что в LJ i18n сделана типичным пыхопоидальным методом: вместо текста в страницу впыживается запрос к базе данных. Так делают все пыхопоиды — следовательно, это неправильно. Должен существовать Правильный Способ, одновременно уменьшающий нагрузку на серверы и облегчающий жизнь как англоязычным кодерам, так и переводчикам.
По интерфейсу. Как переводчик, я бы предпочел видеть соответствующую страницу целиком и переводить по надписи за раз легким тычком мыша, ибо качество перевода очень зависит от доступности контекста. Впрочем, мне-то не в падлу и напрямую исходники страницы править. Но тогда и текст должен быть прямо в странице — что, опять же, говорит о пагубной греховности пыхпыховой методы.
По координации и своевременности переводов. Нужна система оповещений об изменениях английских исходников. Внес кодер изменения — у переводчиков загорелась лампочка. Кроме того, нужна система блокировок, чтобы все разом не хватались за одно и то же, но при этом любой перевод должен становиться редактируемым после того, как текущий переводчик его закоммитит.
На этом остановлюсь, ибо опасно близок к русской программистской идее (переписать все к разэтакой матери с нуля). Что скажете, сэры? Не попадался ли где ровно такой велосипед? И если нет, насколько сложно его изобрести?
no subject
Date: 2010-09-18 01:53 pm (UTC)Хм. Аккуратный пас :)
Вернемся, однако, к жертвам пыха. Скорее всего, на стороне сервера каждая страница представляет собой мерзкую мешанину, как при пыханьи и положено. Но основа относительно стабильна.
Кроме того, есть механизм автоматического переключения языка, встроенный прямо в HTTP (см. http://212.75.221.62/test/ — заодно узнаем, не накосячил ли я чего с фаерволом; понимает en, ru и zh).
Если content negotiation работает и с PHP, действительно можно переводить именно страницами. Не факт, что это удобнее, чем явный выбор переключалкой на сайте, но зато в большинстве случаев юзер по умолчанию сразу получает то, что ему ближе. Вдобавок, это позволяет избежать каши на недопереведенных страницах, страшно смущающей местное начальство: либо перевод есть, либо его нет (и выдается исходная английская страница).
Прочее (уведомления об изменениях, блокировки, автоматическое задвигание старых версий переводов в тень при изменении оригинала) должна уметь какая-нибудь система совместной разработки. Видел где-нибудь такое?