Программистам на подумать
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-22 01:03 pm (UTC)ты с ума сошелэто очень трудно, если хочешь этим заниматься - ответь на это письмо, и мы дадим тебе аккаунт." - Ответил. Продолжаю наблюдение.no subject
Date: 2010-09-22 08:01 pm (UTC)Все-таки страницу разбивать нельзя. Даже если в нее вставляются другие повторяющиеся элементы, всё, что юзер видит за один раз, в смысле перевода надо как-то увязывать в единый объект (в том числе и в системе контроля версий). В принципе, оно бы и в разработке сгодилось, но для перевода это жизненно важно.
В данном случае, конечно, хоть как получится система костылей. Такие штуки все-таки надо сразу закладывать. Но можно по крайней мере сделать костыли не сцепленными, как в LJ.