Текущее положение дел такое, что очень часто приходится реализовывать мультиязычность в своих работах. Вроде бы техники хорошо описаны и проблем не должно быть, но я решил пойти своим путем.

В данный момент делаю сайт для заграничной фирмы, но с русской версией.
Часть коммуникатов перевожу сам, например «Кликни». Знаю, что в литературном словаре этого слова не найти, но для интернет слэнга считаю его вполне приемлемым. Клиент так не считает, а предлагает выриант «Нажми». А вы?

К сожалению, пока что Opera не поддерживает локализацию виджетов методом, предложенном в стандарте W3C, но даже если будет поддерживать, то это касается только серверной стороны, и, видимо, только языка сервера. Поэтому сделаем всё сами, учитывая, что языки браузера-сервера и браузера-клиента в общем случае разные.

Учитель сказал: «Не пошутишь — и не весело».

Чтобы стало весело, команда bash.org.ru привела сегодня интерфейс сайта к тому правописанию русской речи, которое существовало во времена Империи. Вот скриншот:



К сожалению, авторы этого преобразования не озаботились сполна ознакомить себя с правилами, существовавшими девяносто с небольшим лет назад. Оттого текст даже первого экрана (приведённый мною на скриншоте) изобилует теми ошибками башорговцев, которые я сейчас перечислю в порядке их следования сверху вниз на скриншоте:

 

Сегодня команда Твиттера запустила систему Центр переводов (Translation Center), позволяющую организовать краудсорсинговый перевод интерфейса на другие языки.

В настоящее время интерфейс Твиттера уже доступен на английском, французском, немецком, итальянском, японском, корейском и испанском языках. Эти языки доступны в Центре переводов, так что их носители могут продолжать обновлять переводы интерфейса на этих языках.

Кроме уже доступных языков, в Центр переводов добавлены такие языки, как индонезийский, турецкий и, наконец, русский. Именно эти три языка готовятся к релизу в первую очередь.

Все началось с того, что к существующему сайту понадобилось добавить русскую локализацию. После того как я изучал в течение нескольких дней эту тему и наступил множественные грабли, я в конце-концов получил рабочий сайт. А теперь хочу поделиться рецептом многоязычной локализации.
Проверено и отработано на PHP 5.3.3 (Linux)/PHP 5.3.1 (Windows) + Smarty 3.0.7. В данном случае для существующего сайта на английском создавалась русскоязычная версия.
Я не провожу ликбеза на тему «как это работает» (он есть на phpclub), но предлагаю простую инструкцию и описание возможных проблем, с которыми я сталкивался во время реализации.

 

Я давно регулярно читаю Хабр и заметил, что здесь довольно мало внятных статей о локализации ПО, ориентированных на разработчиков. По своему опыту управления проектами локализации я могу сказать, что локализация — это не только перевод строк и адаптация приложения к контексту той или иной страны, но и постоянное противоборство (в идеальных случаях — равноправное взаимодействие) с разработчиками.
В этой статье я постараюсь на примере показать, как можно создать так называемый localization-friendly code, то есть, организовать ресурсы таким образом, чтобы существенно облегчить локализацию приложения, снизив избыточные временные и финансовые затраты.
Сразу же оговорюсь, что речь пойдёт в первую очередь об интернационализации, то есть, об учёте всех лингвистических особенностей на этапе разработки. Если же ресурсы вашего проекта изначально не подразумевали локализацию, а впоследствии вы решились на неё, то их «затачивание» под локализацию может выйти намного дороже, чем доход от неё.

Недавно мне пришлось заниматься интернационализацией веб-приложения на Node.js+Express, над которым я сейчас работаю, и, как мне кажется, получилось довольно неплохо (иностранные пользователи очень довольны, и я вижу заметный приток трафика из неанглоязычных стран). Стратегия интернационализации, которую я опишу, не слишком сильно завязана на Node и может подойти любому веб-приложению.

Мне часто приходилось пользоваться многоязычными сайтами или заходить на англоязычные сайты из разных стран мира, так что я хорошо представлял, каким требованиям должна удовлетворять интернационализация:

Идея этой небольшой статьи родилась, когда я рассказал хабраюзеру Milfgard пару жизненных историй про мой опыт как выполнения переводов, так и работы с результатами перевода. Он предложил поделиться ими с хабрасообществом, что я собственно и делаю. Надеюсь, информация хотя бы покажется интересной и, возможно, приоткроет тайны происхождения некоторых переводов.

Немного предыстории

В студенческие годы я подрабатывал внештатным переводчиком в одном из бюро переводов Москвы. Занимался я в основном переводами по тематике своего образования, то есть переводил всё, что было связано с отраслью связи и телекоммуникациями. Платили по рыночным меркам мало, но как студента меня это тогда вполне устраивало.
Вся работа бюро переводов сводилась к тому, чтобы набрать заказов как можно больше, а затем распределить это между несколькими переводчиками. По сути некий вид краудсорсинга получался. Основным объектом лингвистических издевательств становилась документация на программное обеспечение или оборудование. Самыми яркими примерами в моей памяти остались перевод документации на SDH/PDH оборудование Huawei и перевод документации на платформу Comverse. Сотрудников компаний-заказчиков мне искренне жалко, и сейчас я расскажу, почему.

Всем привет!

Наша компания занимается локализацией ПО, веб сервисов и игр на протяжении уже 8 лет. За это время нам приходилось бессчетное количество раз отвечать на вопросы клиентов «а какой язык посоветуете?». Ответ на этот вопрос совсем не очевиден: чтобы понять, на какие языки стоит переводить свой продукт, необходимо оценить не только количество говорящих на том или ином языке, но и их покупательную способность.

Сегодня мы хотим поделиться инфографикой, которая наглядно показывает соотношение пользователей и экономических возможностей, которые становятся доступными при переводе на тот или иной язык.

Добро пожаловать под кат.

Когда я учился разрабатывать приложения на основе MVVM мне жутко не понравилось, что во многих статьях показано как ApplicationBar создается во ViewModel. Там же кнопки и элементы меню заполняется локализованными строками. Я долго искал решение, и оно было найдено.
Внимание! Статья описывает только решение проблемы локализации панели приложения и подразумевает что читатели знакомы с основами XAML, MVVM, связыванием данных и локализацией приложений.

Добрый день, уважаемые Хабражители.

AngularJS — отличный Framework для создания ваших сайтов. На Хабре уже достаточно много про него написано, но почему то ни разу не затрагивалась тема локализации приложений. Тем не менее, поддержка локализации в нем есть и сегодня мы попробуем с ней разобраться.

Существует несколько способов локализации и мы рассмотрим несколько из них.

Здравствуйте, Друзья!

В статье вкратце расскажу о том, как применить локализацию к вашему приложению с помощью DevUtils ELAS for Microsoft Translation, это расширения для DevUtils ELAS Core.

Известно, что локализация интерфейса увеличивает популярность мобильного приложения в регионе и lifetime value пользователя. А перевод описания и ключевых слов на странице продукта в магазине позитивно влияет на количество загрузок и продаж приложения. Но насколько значимо это влияние?

Теперь мы знаем ответ: стоило нам перевести интерфейс и описание приложения “Домашняя Бухгалтерия” на испанский, французский и немецкий, как его позиции в топе Google Play Испании, Франции и Германии начали стремительно расти. Это был редкий случай, когда наш клиент не проводил параллельно никаких рекламных кампаний. Благодаря этому мы смогли увидеть, что рост позиций обусловлен только выходом локализованной версии приложения.

Цифры, подробности и предложение поучаствовать в крутом эксперименте — под катом.

Недавно Вова и Саша из Alconost отметились на конференции «Разработка ПО/CEE-SECR 2015» с докладом о локализации в облачной платформе Crowdin. Видео этого доклада мы и хотим вам показать в этом посте. За 14 минут вы узнаете, как облачная платформа решает насущные проблемы разработчика и удешевляет перевод:



А если времени совсем в обрез — вот презентация с доклада.

Будем рады ответить на вопросы из зала в комментариях!

Существуют разные способы локализации WPF-приложения. Самый простой и распространенный вариант — использование файла ресурсов Resx и автоматически сгенерированный к ним Designer-класс. Но этот способ не позволяет менять значения «на лету» при смене языка. Для этого необходимо открыть окно повторно, либо перезапустить приложение.
В этой статье я покажу вариант локализации WPF-приложения с мгновенной сменой культуры.

Мы не устаем повторять, что локализация — отличный способ выйти на новые рынки и преумножить аудиторию вашей игры. Хотя бывает, что это лишь способ потратить много времени/денег и получить перевод, над которым носители языка будут вежливо посмеиваться.



В этом посте мы законспектировали несколько идей о том, как наладить процесс локализации игр наилучшим образом. А еще написали, на чем можно сэкономить, а на чем — не стоит.

Ключевой особенностью онлайн-сервисов является то, что к ним имеют доступ пользователи практически со всего мира, говорящие на разных языках. Если вы разрабатываете такой сервис и хотите, чтобы им могли пользоваться люди из разных стран, то вам нужно его перевести и адаптировать, иными словами — локализовать.

Идея написания этой статьи возникла после MoscowJS митапа, на котором я говорил о том, как происходит процесс локализации в компании Badoo. Но в этой статье я бы хотел рассказать немного подробнее об особенностях локализации на примере веб-приложений, о том, какие существуют решения для локализации и почему в Badoo пошли своим путем. Всем неравнодушным — добро пожаловать под кат.