Comments 20
На сколько понимаю, локализация — это не только перевод интерфейса на другой язык, но и обуспечение рподдержки национальных стандартов (как-то, формати даты и времени, дробных и многозначных чисел, система мер, вывод на экран символов языка и т.д.). Как это реализуется?
То, что вы описали — это интернационализация. Локализация — это именно перевод строк и корректирование остальных данных вроде форматов времени. Часть данных при этом уже есть в проектах вроде CLDR, так что локализовать их заново не надо.
Поддержка форматов даты и чисел обычно есть в операционной системе — ничего особенного в рамках локализации тут делать обычно не надо. Разработчикам нужно просто следовать правилам, заданным для их платформы.
А предусмотрен ли какой-то способ борьбы с разницей между длинами строк на разных языках и необходимостью адаптации элементов интерфейса под эти строки?
Сравнивать длину на английском с длиной перевода и маркировать как-то в UI для переводов?
На уровне Serge есть только возможность протаскивать коммаентарии разработчиков из файлов ресурсов на сервер перевода. Уже на самом сервере переводчики видят эти комментарии, а также скриншоты, которые добавляют менеджеры по локализации. Интерфейс наши инженеры разрабатывают таким образом, чтобы он корректно работал с более длинными строками, а тестирование локализованных сборок позволяет нам выявлять косяки и переводить что-то покороче, когда это возможно, или файлить баги на разработчиков, чтобы они где-то переработали интерфейс.
А почему все делается в режиме пребилда файлов, а не в рантайме? Казалось бы, имея центральную базу переводов, всегда можно её локально закэшировать и извлекать переводы во время работы программы/приложения/сайта/сервиса. И тогда можно вообще все переводы обновлять в реальном времени, ничего не пересобирая.
(Кстати, вопрос залу: а есть ли готовые сервисы, работающие по этому принципу по модели подписки?)
(Кстати, вопрос залу: а есть ли готовые сервисы, работающие по этому принципу по модели подписки?)
В реальном времени позволяет так делать Facebook. Но это он для себя, естественно. В виде сервисов такого не встречал.
Сервисы такие есть. Qordoba, например. Но, во-первых, это платно (и цены обычно сильно зависят от размера компании). Во-вторых, ни одна уважающая себя компания не будет ставить свой продукт (рантайм) в зависимое положение от стороннего решения. Это усложняет код, делает его более медленным, это делает локализационное решение нестандартным (чего разработчики не любят), это усложняет тестирование. Наконец, зачем что-то делать в рантайме миллионы раз, когда можно сделать один раз статически?
Ну да, так было 15 назад, когда не было AWS, Mandrill, CloudFlare и тысяч других сторонних решений, от которых современные веб-разработчики очень полюбили ставить себя в зависимость. Ну а на вопрос «зачем»… потому что быстро, удобно и позволяет нетехнарям править тексты и моментально видеть результат, например.
Не все, что удобно в разработке, удобно и быстро для конечных пользователей продукта. Динамическая локализация удобна переводчикам (коих у нас около 30), но имеет свои минусы для инженеров (коих у нас сотня) и конечных пользователей (коих миллионы). Одно дело — перенос своих вычислительных мощностей на AWS. Это прозрачно для пользователей, и скорее всего даже призвано ускорить работу. Другое дело — локализация в рантайме (усложнение кода и процесса).
Немного нелепо выглядит сей релиз сугубо внутренней наработки на фоне вливания evernote в pootle, ибо функционал вашего Серёжи практически идентичен translate-toolkit.
Плюсы использования промежуточной базы на обычном SQL для конвертации форматов — весьма сомнительны на первый взгляд: откат состояний там не предусмотрен, снапшотов нет, то есть никакой защиты от факапов: роллбэк не сделать при плохом вливании, ибо проще сразу базу переналивать. Я так понимаю, что ровно плыть вам помогает именно тот факт, что внутри компании есть «домашние» переводчики и менеджеры локализаций? Опять же, работа с памятью переводов реализована через обычный скрипт, а реалтаймовые матчинги для переводчиков делает вполне себе эластик же, да?
Получается, что в сухом остатке у вас, вероятно, имееются неплохие парсеры, ибо perl традиционно хорошо работает со строками… ну и всё.
Из всего этого вытекает вполне себе резонный вопрос: если perl лошадка сдохла, то надо ли с неё слезать? :3 Ну а если без сарказма, то планирует ли компания работать над расширением функционала pootle и соответствующих утилит, или вы таки только с Сережёй дружить будете? :-}
Плюсы использования промежуточной базы на обычном SQL для конвертации форматов — весьма сомнительны на первый взгляд: откат состояний там не предусмотрен, снапшотов нет, то есть никакой защиты от факапов: роллбэк не сделать при плохом вливании, ибо проще сразу базу переналивать. Я так понимаю, что ровно плыть вам помогает именно тот факт, что внутри компании есть «домашние» переводчики и менеджеры локализаций? Опять же, работа с памятью переводов реализована через обычный скрипт, а реалтаймовые матчинги для переводчиков делает вполне себе эластик же, да?
Получается, что в сухом остатке у вас, вероятно, имееются неплохие парсеры, ибо perl традиционно хорошо работает со строками… ну и всё.
Из всего этого вытекает вполне себе резонный вопрос: если perl лошадка сдохла, то надо ли с неё слезать? :3 Ну а если без сарказма, то планирует ли компания работать над расширением функционала pootle и соответствующих утилит, или вы таки только с Сережёй дружить будете? :-}
Хорошие вопросы.
Образно говоря, translate-toolkit по сравнению с Serge — это Arduino по сравнению с iPhone. Мы активно помогаем разрабатывать Pootle, но рассматриваем его лишь как интерфейс для перевода, не более. Serge+Pootle = полноценная опенсорс-платформа для непрерывного перевода. translate-toolkit мы помогать развивать не намерены. Внутри самого Pootle есть также тенденция уйти от зависимости с translate-toolkit.
Serge не является конвертером форматов в прямом смысле этого слова. И это сильно больше, чем набор парсеров — рекомендую почитать документацию к управляющим плагинам, например. Снапшоты базы и .po-файлов мы делаем — ничего сложного тут нет. База не такая большая — можно делать бэкап хоть после каждого цикла. Elasticsearch — это TM внутри самого Pootle. Serge позволяет использует свою базу как TM, переиспользует известные переводы (сначала пытается находить 100% матчи внутри файла, потом внутри проекта, затем внутри всей базы).
Помогать развивать функционал Pootle мы, разумеется, продолжим. Есть много идей для улучшения.
Образно говоря, translate-toolkit по сравнению с Serge — это Arduino по сравнению с iPhone. Мы активно помогаем разрабатывать Pootle, но рассматриваем его лишь как интерфейс для перевода, не более. Serge+Pootle = полноценная опенсорс-платформа для непрерывного перевода. translate-toolkit мы помогать развивать не намерены. Внутри самого Pootle есть также тенденция уйти от зависимости с translate-toolkit.
Serge не является конвертером форматов в прямом смысле этого слова. И это сильно больше, чем набор парсеров — рекомендую почитать документацию к управляющим плагинам, например. Снапшоты базы и .po-файлов мы делаем — ничего сложного тут нет. База не такая большая — можно делать бэкап хоть после каждого цикла. Elasticsearch — это TM внутри самого Pootle. Serge позволяет использует свою базу как TM, переиспользует известные переводы (сначала пытается находить 100% матчи внутри файла, потом внутри проекта, затем внутри всей базы).
Помогать развивать функционал Pootle мы, разумеется, продолжим. Есть много идей для улучшения.
Игорь, спасибо за интересный обзор. Обязательно хочу поэкспериментировать с Serge в своей работе, когда будет время.
У меня есть несколько вопросов:
Правильно ли я понимаю, что Pootle у вас является основным внутренним CAT-инструментом? И именно это и послужило одним из драйверов создания Serge? У меня на работе несколько иная схема, где в ядре находится memoQ.
Описанная вами цепочка работает только на локализации интерфейсов? Пробовали ли вы применить Serge для локализации документации? Была бы интересна такая схема в условиях гибкой разработки документации.
У меня есть несколько вопросов:
Правильно ли я понимаю, что Pootle у вас является основным внутренним CAT-инструментом? И именно это и послужило одним из драйверов создания Serge? У меня на работе несколько иная схема, где в ядре находится memoQ.
Описанная вами цепочка работает только на локализации интерфейсов? Пробовали ли вы применить Serge для локализации документации? Была бы интересна такая схема в условиях гибкой разработки документации.
Pootle у вас является основным внутренним CAT-инструментом? И именно это и послужило одним из драйверов создания Serge? У меня на работе несколько иная схема, где в ядре находится memoQ.
Да, весь перевод издет через Pootle. Драйвером послужило то, что нужна была система между Pootle и системой контроля версий, которая все бы делала полностью автоматически и постоянно. Pootle для этого не подходил, никаких других продуктов для непрерывной локализации не существовало, так что пришлось писать что-то свое.
Я, по правде говоря, и сейчас не знаю других продуктов для непрерывной локализации. Понятно, что в последнее время появилось много CAT-решений, но когда дело касается интеграции процесса внтури компании с этим CAT-решением, обычно требуется интеграция через API (или через клиент командной строки), или же интеграция происходит по принципу «нажми на кнопку, чтобы загрузить новые строки, нажми другую кнопку, чтобы выгрузить переводы». Что у memoQ в этом плане?
Описанная вами цепочка работает только на локализации интерфейсов? Пробовали ли вы применить Serge для локализации документации?
Документация у нас вся хранится в виде статей в Zendesk. Есть еще маркетинговые материалы (блог-посты, описания приложений для app store, release notes), которые хранятся в Google Drive. Как для Zendesk, так и для Google Drive мы применяем похожую схему: есть скрипты синхронизации, который забирают контент из внешнего сервиса, генерят локально XML-файлы по одному на документ и выгружают это в систему контроля версий. Дальше все это переводится с помощью Serge+Pootle, а затем эти же скрипты синхронизации выгружают локализованный контент обратно в Zendesk и Google Drive.
Если у вас документация хранится уже в системе контроля версий в каком-то пригодном к парсингу формате, то ее можно обрабатывать с помощью Segre безо всяких дополнительных ухищрений. Если интересно, пишите в личку, пообщаемся более предметно.
Спасибо за ответы!
У memoQ есть приложение Content connector — может забирать файлы из локальной сети, с компа или SVN (вроде бы ещё откуда-то, но я не пробовал).
ABBYY в своём SmartCAT решили эту задачу через «горячую папку» — система постоянно проверяет, не изменились ли файлы в указанной папке на моём компьютере. Мне кажется, пока не очень изящное решение. Работоспособность не пробовал.
Transifex позволяет делать непрерывную локализацию своими средствами. У них есть классная статья в блоге, где они рассказывают, как непрерывно локализуют самих себя. К сожалению, сам тоже пока не имел возможности попробовать (корпоративные ограничения).
Что у memoQ в этом плане?
У memoQ есть приложение Content connector — может забирать файлы из локальной сети, с компа или SVN (вроде бы ещё откуда-то, но я не пробовал).
ABBYY в своём SmartCAT решили эту задачу через «горячую папку» — система постоянно проверяет, не изменились ли файлы в указанной папке на моём компьютере. Мне кажется, пока не очень изящное решение. Работоспособность не пробовал.
Transifex позволяет делать непрерывную локализацию своими средствами. У них есть классная статья в блоге, где они рассказывают, как непрерывно локализуют самих себя. К сожалению, сам тоже пока не имел возможности попробовать (корпоративные ограничения).
С Transifex мы с ними общаемся, может быть даже попробуем сделать поддержку Transifex в Serge.
Формально, поддержки непрерывной локализации в самом Transifex нет. Есть их утилита командной строки, которую можно использовать в своих скриптах. Но добавление новых файлов, удаление старых, начальная выгрузка, конфигурирование на стороне веб-интерфейса — все это надо делать руками. И потом, когда это сделано, можно написать свои кастомные скрипты, которые будут делать VCS push/pull и tx push/pull. И опять же потенциально иметь проблемы с мержем на уровне VCS или же писать скрипты для обхода этого. А Serge позволяет однажды настроить процесс и забыть про ручную работу.
Формально, поддержки непрерывной локализации в самом Transifex нет. Есть их утилита командной строки, которую можно использовать в своих скриптах. Но добавление новых файлов, удаление старых, начальная выгрузка, конфигурирование на стороне веб-интерфейса — все это надо делать руками. И потом, когда это сделано, можно написать свои кастомные скрипты, которые будут делать VCS push/pull и tx push/pull. И опять же потенциально иметь проблемы с мержем на уровне VCS или же писать скрипты для обхода этого. А Serge позволяет однажды настроить процесс и забыть про ручную работу.
Интересный проект. Забавно только, что на самом сайте нет локализации
Sign up to leave a comment.
Serge — решение для непрерывной локализации от Evernote