Comments 26
зачем придумали упаковывать properties в лишний jar?
Походу суть перевода за одну ночь не в технологии а в большом штате сотрудников.
И в технологии упрощенного развертывания ресурсов локализации, не затрагивающего код.
Я такую технологию юзал еще до гугла и линкедина… она логична. Есть еще как минимум gettext, которому 100 лет в обед. Посему расказ о приходе к технологии не ясен.
Серьёзно??? Ну да наверное для сервиса где изначально не была заложена интернационализация это — маленькая победа.
Но по сути так хранить локализации — очевидно.
Но по сути так хранить локализации — очевидно.
Помоему довольно очевидный способ, юзаю похожее уже лет 5. Кроме конечно упаковки в jar и т.д. в том числе и локализацию типа «hello, {username}» где в метки проставляются соответствующие элементы отправленного массива.
Как уже выше описали секрет быстрой локализации — в количестве переводчиков.
Я думал они там на ночь скрипт запускают, который с какого нить translate тянет переводы.
Как уже выше описали секрет быстрой локализации — в количестве переводчиков.
Я думал они там на ночь скрипт запускают, который с какого нить translate тянет переводы.
Вся соль в том (следует из диаграммы), что:
1. платформа для перевода забирает ресурсы из svn
2. переводчики переводят новые и измененные строчки
3. платформа для перевода кладет переведенные ресурсы назад в svn
В платформе работают переводчики агентства. У агентства много переводчиков т.е. есть достаточный для быстрого перевода штат. Не нужно быть линкедином, чтобы построить такое решение, нужно выбрать правильное агентство.
1. платформа для перевода забирает ресурсы из svn
2. переводчики переводят новые и измененные строчки
3. платформа для перевода кладет переведенные ресурсы назад в svn
В платформе работают переводчики агентства. У агентства много переводчиков т.е. есть достаточный для быстрого перевода штат. Не нужно быть линкедином, чтобы построить такое решение, нужно выбрать правильное агентство.
UFO just landed and posted this here
> “Я хочу, чтобы после того, как программист добавил новую строчку в интерфейс, она сама перевелась на 19 языков и сама положила себя в SVN и была готова к релизу утром”
Это, точно, мечта. Само, и еще и выложилось. И без косяков.
Вы же описываете просто вынос ресурсов отдельно от кода: т.е. переводится не само, само же и не выкладывается (если бы jar-ы сами себя начали выкладывать… ого-го бы началось!), и от косяков не страхует вообще никак.
Сколько раз читаешь файл с переводами — вроде все верно (ну, кроме случаев «смотри, мама, я Промт украл, и стал мегапереводчиком!»), а когда тот же перевод видишь в ПО — хочется плакать от того, что на выходе видишь. Предел для меня — перевод сообщений на смартфоне, где английское сообщение «Ring» (в смысле, звонок) перевели как «Кольцо» :)
Это, точно, мечта. Само, и еще и выложилось. И без косяков.
Вы же описываете просто вынос ресурсов отдельно от кода: т.е. переводится не само, само же и не выкладывается (если бы jar-ы сами себя начали выкладывать… ого-го бы началось!), и от косяков не страхует вообще никак.
Сколько раз читаешь файл с переводами — вроде все верно (ну, кроме случаев «смотри, мама, я Промт украл, и стал мегапереводчиком!»), а когда тот же перевод видишь в ПО — хочется плакать от того, что на выходе видишь. Предел для меня — перевод сообщений на смартфоне, где английское сообщение «Ring» (в смысле, звонок) перевели как «Кольцо» :)
А gettext по прежнему самое оптимальное решение или нет? И как переводить при помощи gettext скрипты на javascript?
Извините за глупый вопрос в тему.
Извините за глупый вопрос в тему.
Самое. У нас в проекте долгое время использовалась доморощенная архитектура локализации, но после 5 лет мы поняли, что пишем велосипед. За неделю переделали на GETTEXT — профит! И девы, и документаторы счастливы.
На Javascript-е мы используем Gettext. На сервере генерим JSON из *.po файлов, и клиент подтягивет файл нужной локали. Быстро, удобно, неимоверно гибко (! — домены, контекст, плюралы).
На Javascript-е мы используем Gettext. На сервере генерим JSON из *.po файлов, и клиент подтягивет файл нужной локали. Быстро, удобно, неимоверно гибко (! — домены, контекст, плюралы).
Статья ни о чём :(
Все давно знают, что ресурсы нужно хранить отдельно от приложения.
К примеру, MSFT stack с его .NET: там ресурсы by design отдельно, и в любой момент можно использовать какой угодно язык.
Все давно знают, что ресурсы нужно хранить отдельно от приложения.
К примеру, MSFT stack с его .NET: там ресурсы by design отдельно, и в любой момент можно использовать какой угодно язык.
MSFT stack поддерживает отделение кода от ресурсов, начиная с формата NE (1985 г.)
Угу, новинка .NET, а то как же.
Угу, новинка .NET, а то как же.
С обычными приложениями существенно больше возни не с сообщениями (с ними-то как раз все просто), а со справкой и прочими текстами. Там возни на порядки больше, и формализовать процесс намного сложнее.
Да мне бы хоть на английском
Почините сервер пожалуйста.
503: Service Unavailable
вот скрин habrastorage.org/storage2/003/9e3/656/0039e3656c7f2e3104eff450cbecdd93.jpg
Почините сервер пожалуйста.
503: Service Unavailable
вот скрин habrastorage.org/storage2/003/9e3/656/0039e3656c7f2e3104eff450cbecdd93.jpg
О какой локализации может идти речь, если у них почти год неправильно приходили уведомления, содержащие русский текст, а сейчас поле образования у всех людей, у которых указан университет в профиле кириллицей выглядит примерно так (если зайти в редактирование профиля, то там все нормально)
Мы ввели концепцию языкового пакета
А вы уверены, что это именно вы сделали? в том же Zend Studio (первое, что на ум пришло) это применяется лет 10 как, если не больше…
Sign up to leave a comment.
Как LinkedIn делает локализации на 19 языков за 1 ночь