Локализация продуктов *

NPM библиотека для интернационализации и локализации i18n очень популярна, однако за последние годы она сильно располнела. В ней много возможностей для локализации дат, чисел, установки нужных склонений, поддержки RTL языков, загрузки локалей с сервера и кучи еще чего. На сайте i18next она называется уже даже "интернационализационным фреймворком".

В то же время часто для локализации сайта нужны очень простые вещи, занимающие всего пару процентов от всего функционала тяжеловеса i18n. Ниже будет описана несложная процедура избавления от i18next-ной зависимости в данном случае.

Привет! Меня зовут Сергей Балалаев, я руковожу отделом разработки мобильного приложения для ПВЗ в Ozon. Это то самое приложение, которым сотрудники пунктов выдачи сканируют штрихкод, чтобы выдать товар получателю. Оно внутреннее, для сотрудников. iOS-версией постоянно пользуются 12 тыс. человек, поэтому при постановке задачи нас не просили делать мультиязычную версию. Но мы с самого начала разработки решили поддерживать несколько языков — когда возникнет необходимость локализации, справимся в спокойном режиме и без проблем, свойственных проектам, в которых локализацию не закладывали.

Я хочу рассказать, как мы побороли типичные проблемы локализации для наших iOS-проектов, зачем собрали свой линтер для локализации и как это всё помогло упростить и автоматизировать процесс.  

В данной статье мы расскажем как перевести статический веб-сайт с Markdown (Zola, Hugo, Jekyll, Pelican, Gatsby, и д.р.) на все языки мира и поддерживать переводы в актуальном состоянии при изменении исходных текстов.

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

Хотя все эти задачи подпадают под понятие «специальный перевод» (читай — не относятся к переводу текстов художественных произведений), первые два запроса, перевод инструкций и договора, выполняют переводчики технических и юридических текстов, а переводом сайта магазина занимаются локализаторы. Термин «локализация» охватывает не только перевод, но и культурную и языковую адаптацию материала, а также озвучку, замену изображений, перерисовку графики и многое другое, поэтому переводчик-локализатор часто работает в команде с другими специалистами.

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

Языки

Если вы поддерживаете два или три языка, это не имеет большого значения. Но если вы хотите поддерживать дюжину вариантов, вы должны как-то решить, какие из них. Для начала неплохо погуглить самые популярные языки, но этот вариант совсем не точен. Лучше посмотрите статистику или аналитические отчеты, которые дадут вам представление о том, на каких языках говорят ваши пользователи. В Росплате я такие данные не собираю, поэтому нужна была другая точка отсчета. Мне пришлось проявить инициативу и просто спросить потенциальных пользователей: «Привет, ребята, какие языки вы ожидаете увидеть на странице настроек?». Честно говоря, ответ был неожиданным. Арабский, иврит, хинди и бенгалбский!

Обнаружение

Когда новый пользователь попадает в приложение, он может не говорить по-английски, который является языком по умолчанию. Значит, должен быть какой-то способ угадать. И есть один: используйте заголовок Accept-Language на стороне сервера. Этот заголовок не только говорит вам, какую локаль использовать, но и дает вам подсказку, например, этот пользователь говорит на языке А и языках Б (я уверен на 90%) и С (я уверен на 50%). С этой информацией вы можете быть намного увереннее: если вы не поддерживаете основной язык пользователя, вы, вероятно, можете использовать дополнительные.

Язык программирования Kotlin часто ассоциируется с мобильной разработкой для Android и это неудивительно, учитывая что он принят Google как официальный язык разработки, и принес множество необходимых и удобных языковых конструкций и кооперативной многозадачности, при этом сохраняя совместимость на уровне байт-кода с ранними версиями JVM. Но применимость языка существенно выше и имеющиеся библиотеки (как созданные для Java, так и разработанные специально для Kotlin) позволяют создавать обычные приложения (например, на JavaFX или с использованием платформенных графических библиотек и Kotlin Native), а также создавать код для бэкэнда c подключениям к базам данных, кэшам, очередям сообщений и т.д. При этом, если для мобильной разработки проблем с поддержкой многоязычных сообщений не возникает (благодаря механизму ресурсов, в том числе строк, которые могут быть переопределены для конкретной локали), то для бэкэнда это становится нетривиальной задачей. В этой статье мы обсудим несколько подходов для создания бэкэнда с поддержкой нескольких языков.

Что самое сложное в процессе разработки? Написание кода или построение архитектуры? Проработка идеи или написание требований?

Мы в Moroz Team обсудили это однажды за обедом. Что встречается на каждом из перечисленных шагов? Может, даже в повседневной жизни это вызывает трудности?

Давайте называть вещи своими именами. Ах, да, именно это и есть то самое сложное – называть своими именами или на английский манер «нейминг».

Меня зовут Кирилл Суханов, я product manager в Flowwow. В этой статье расскажу, как мы разворачивали наш продукт на совершенно новой территории, как по ходу корректировали алгоритм и как будем действовать уже с третьим нашим кластером, когда будем готовы им заняться. 

Два года назад я проводила вебинар на конференции Translation Forum Russia, где рассказывала о трудностях локализации торговых приложений и как и их преодолеть. Тема мне близка, так как я уже семь лет работаю менеджером по локализации в финтехе. Ниже представлен мой материал с конференции, дополненный и немного переработанный.

Я создал консольный инструмент, который автоматически находит все файлы .strings в проекте xcode и переводит их на все языки.

Что вы знаете о том, как добавить поддержку языков, которые пишутся справа налево (Right to Left, RTL), в iOS‑приложение? Нужно использовать leading и trailing вместо left и right, а ещё… Вот и мы больше ничего не знали, но пришлось разобраться.

Мы готовим приложение Додо Пиццы к локализации на арабский язык. В статье хотим поделиться находками и рассказать, зачем нам поддержка RTL в приложении, почему не достаточно просто адаптировать вёрстку в коде для поддержки RTL, зачем мы перерисовывали иллюстрации и чем отличается арабский знак процента от европейского. Ещё покажем много скриншотов и поделимся шпаргалками по поддержке RTL в коде.

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

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

К моим словам прошу относиться со здоровой долей скепсиса, ибо я не нейтив-спикер, а просто ИТшный переводчик-редактор (пусть даже и с 20-летним опытом).

В последние полгода англо-русские переводы по понятным причинам практически исчезли, и по работе на проверку приходят в основном русско-английские, зачастую на «рунглише». Отмечу, что «рунглишевые» ошибки в присылаемых материалах более или менее однотипные, поэтому я и предположил, что коллегам может быть полезно, если эти ошибки кто-то разложит по полкам.

Эту памятку или «дорожную карту» я опубликовал в своем телеграм-канале несколько месяцев назад, многократно её обкатал на проектах, и убедился в ее применимости — поэтому вешаю ниже.

Шагов в этой памятке 5:

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

В этом посте я разберу конкретные примеры. Думаю, некоторые из них вас удивят.

***

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

Взгляните на этот скриншот из Zoom:

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

Вот, например, у меня на компьютере сегодняшняя дата пишется так — 06.01.2023, а на одном из моих серверов в уголке экрана светится 01/06/23. Это американский формат, и я каждый раз мучительно вспоминаю, 01/06 это первое июня или всё таки шестое января.

Ещё одно национальное отличие — символ отделения целой и дробной части в числах. В России по традиции и в соответствии со стандартами надо отделять дробную часть запятой (Пи = 3,14), а американцы (и вслед за ними программисты) используют десятичную точку (Pi = 3.14). Из-за этого различия иногда случаются разные казусы.

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

Рано или поздно у крупных проектов наступает такой этап, когда достигнут потолок по аудитории или финансовым показателям и нужно как-то расти дальше. И вот в один прекрасный день сияющие коллеги приходят к тебе со словами «Мы тут решили выйти на рынок США/Китая/СНГ…».

Если архитектура сайта изначально проектировалась с учетом международного развития — это хорошо. Однако если за все время жизни проекта вы концентрировались на том, что нужно «здесь и сейчас» и никто не задумывался о том, чтобы когда-нибудь вынести бизнес за пределы России, то могут возникнуть сложности.

В современных приложениях и сервисах часто нужна интернационализация (i18n, от англ. internationalization). Она позволяет создавать интерфейсы с учётом культурных и языковых особенностей пользователей из разных стран. Это требует не только простого перевода, но и некоторых технических решений, порой довольно сложных.

Меня зовут Володин Сергей, я работал руководителем команды разработки VK WorkMail. Сегодня расскажу о том, как инфраструктура переводов позволяет поддерживать 10 языков в нашем продукте и какие технические нюансы стоит учитывать при работе с разными языками. Интернационализация интерфейсов — довольно комплексная и непростая история, хотя на первый взгляд может показаться не слишком приоритетной задачей. Более того, о ней нужно начинать думать в самом начале разработки, чтобы впоследствии не наломать дров.

Представьте, что вы перевели свое приложение на английский. А что, если ваше приложение работает в 47 странах, большая часть из которых говорит на разных языках и диалектах? Возникает проблема выстраивания единого процесса локализации и проверки переводов в каждом конкретном случае.

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

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

Много людей нашли предыдущий пост «Деловое письмо на английском языке» интересным и полезным. Поэтому я решила написать ещё один подобный полезный пост. На этот раз мы узнаем, как освоить деловой стиль на английском и достичь «правильного уровня формальности» в деловом письме британскому партнеру.