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

Достаточно часто в реализации сервисов есть необходимость оперировать денежными единицами, хранить их в БД, обмениваться по API и выполнять конвертацию

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

Помню, как в марте‑апреле 2022 года нам начали поступать тревожные звонки. Картина была от уровня «у нас все перестало работать» до «у нас полгода на полную замену всех систем». Удивительно было то, что те, кого это не коснулось в моменте, продолжали спокойно смотреть на происходящее со стороны, как будто их это никогда не коснется. В целом, я лично оценил поговорку «пока гром не грянет…», так как даже подготовка к внедрению «Честного знака» у некоторых выглядит так: за полгода набираешь — «рано», за три месяца — «мы думаем», за месяц — «катастрофа, пора внедрять».

Особенно запомнился звонок от директора крупного производственного предприятия, который — не скрывая волнения — сказал: «У нас есть неизвестный запас времени: от трех месяцев до конца года». При этом, их производственный процесс крайне сложный, с множеством нюансов и многими годами кастомизации зарубежных систем, которые они до этого использовали.

Некоторым компаниям «повезло» меньше. Их вендоры просто выключили системы, сделав вид, что клиенты перестали существовать.

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

Привет, Хабр! Меня зовут Таня Коваль. По образованию я востоковед — специализируюсь на странах Восточной Азии, а работаю UX-исследователем в RuStore — российском магазине приложений для Android. За последние три года RuStore заметно вырос: в сторе стало больше пользователей, расширился каталог приложений, а среди партнёров всё чаще появляются разработчики из Китая.

Недавно к нам пришёл нетривиальный запрос: провести UX-исследование китайской B2B-аудитории. Казалось бы, что тут сложного — берём сценарии, находим респондентов и вперёд. Но на практике мы столкнулись с куда более интересными вызовами: где искать разработчиков в Китае, как говорить с ними так, чтобы понимать друг друга (и в прямом, и в культурном смысле), как выстроить доверие и получить честные, полезные инсайты.

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

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

Последние несколько лет в Рунете часто говорят, будто тот движется по китайскому сценарию — будь то Великий китайский фаервол или Государственный мессенджер, аналог WeChat. А какой этот "китайский интернет" с бытовой точки зрения? Восемь лет назад я уже писал, как он меня бесит. Интернет в Китае изменился, да и Рунет, кхм, тоже. Пора освежить знания.

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

В этой статье я расскажу о сложностях локализации в Unreal Engine, опираясь на свой опыт работы над Wizard of Legend 2. Мы разберём сбор и управление текстом, а также проблемы с форматированием, гендерно‑зависимым языком и обработкой шрифтов. Также я расскажу о ключевых аспектах, которые могут вызвать задержки, и о том, как их минимизировать.

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

На этом фоне популярными стали неофициальные озвучки от сторонних студий вроде GamesVoice и Mechanics VoiceOver. Впрочем, порой своих русскоязычных поклонников радует Sony, Capcom, Activision и несколько других издателей. Собрали подборку главных игр, вышедших с 2022 года, с полной русской локализацией — таких, что запустил и комфортно играешь.

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

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

Но можно ли использовать машинный перевод в интерфейсе — самой чувствительной части продукта для пользователя?

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

Привет!

Итак, две части про локализацию и её тестирование позади (раз, два), пришло время для третьей.

В 2025 году все больше российских компаний ищут пути ухода с зарубежных решений виртуализации: VMware, Hyper-V, Nutanix AHV. С VMware и Hyper-V миграция уже более-менее отлажена, а вот с Nutanix AHV — совсем другой разговор.

Мы в команде впервые столкнулись с задачей полноценного переноса виртуальных машин с AHV в отечественную систему zVirt от Orion soft. Готового решения не было ни у кого. В этой статье поделюсь опытом: что сработало, какие были грабли и как мы с ними справлялись.

Если вы всё ещё используете IP-геолокацию для выбора отображаемого языка, то хватит заниматься ерундой. Это ошибочное допущение, замаскированное под фичу.

IP сообщает, откуда пришёл запрос, и на этом всё. Он не сообщает, какой язык нужен пользователю, на каком языке он говорит и какой язык понимает. Подобная система постоянно ломается — VPN, путешествия, эмиграция, страны с несколькими официальными языками. Это не умное, а раздражающее решение.

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

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

g11n, i18n, l10n... или один из множества вариантов локализации приложения. Привет, меня зовут Константин Комков и я надеюсь данный пример и последовательность шагов сэкономят Вам время при разработке!

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

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

Долгое время я использовал контрольную панель Kloxo, а позже — KloxoMR на базе CentOS 7 для управления мини-сервером с сайтами. Это решение отлично справлялось со своими задачами, но со временем CentOS 7 устарел, а Kloxo не была адаптирована для более новых ОС, ее обновления прекратились. Пришлось задуматься о переходе на более актуальные решения.

Так как мне больше импонируют RPM-based дистрибутивы, я начал искать Open Source панель управления сервером, подходящую под такие ОС. Также было важно, чтобы это решение имело возможность расширения функционала.

Процесс поиска оказался непростым. Многие панели не подошли по ряду причин:

Согласно нашему исследованию на выборке 1,200 интернет-магазинов, 87% потенциальных клиентов действительно не находят нужные товары из-за фундаментальных маркетинговых ошибок.

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

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

Всем привет! Меня зовут Арина, я - frontend-разработчик в отделе разработки конструкторов iSpring. Наша команда занимается разработкой и развитием продукта iSpring Page - облачной платформы для создания курсов.

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

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

Многие люди, кто не работает в сфере разработки электроники, представляют себе процесс разработки достаточно просто: разрабатываем схему, трассируем плату, пишем прошивку. А что еще надо?

В статье я опишу, как устроен типовой процесс разработки электроники на самом деле – на примере и с картинками (это может быть маленькая или большая компания, процесс плюс-минус схож). За пример мы возьмем некую материнскую плату компьютера (процессор в данном случае не принципиален) и разберем типовой процесс разработки такой материнской платы.