5.5 Интернационализация и локализация
Обзор и мотивация
Интернационализация (i18n) это инженерная работа по построению программ так, чтобы их можно было адаптировать к любому языку, региону и культуре без изменения кода. Локализация (l10n) это работа, которая следует за ней: фактическая адаптация продукта для конкретной локали переводом текста, форматированием дат и чисел, подгонкой компоновки и учётом культурных ожиданий. Эти две вещи различны. Интернационализация делается один раз, в архитектуре. Локализация делается много раз, в содержимом. Правильно сделайте архитектуру заранее, и каждая локализация дёшева. Сделайте неверно, и каждая станет болезненным подверженным ошибкам дооснащением.
Для больших команд i18n основополагающее архитектурное решение. Оно касается каждого слоя: хранения данных, обработки строк, компоновки и конвейеров контента. Если вы не установите его рано и не будете принуждать к нему через общие библиотеки и правила линтера, команды зашьют английские строки, склеят переведённые фрагменты и предположат латинские письменности. Этот долг придётся распутывать, прежде чем продукт сможет выйти на любой новый рынок. Общий фреймворк i18n и рабочий процесс локализации позволяют десяткам команд поставлять продукт на многих языках, не изобретая каждой сантехнику заново.
Значимость для корпораций и государства прямая. Международные корпорации должны обслуживать клиентов и сотрудников по странам, языкам и регуляторным режимам. Государства должны обслуживать лингвистически разнообразное население. Многие страны официально многоязычны, и многие по закону обязаны оказывать услуги на нескольких языках, включая письменности справа налево и языки коренных народов и меньшинств. Для государственных услуг языковой доступ вопрос равенства и закона: гражданин, не читающий на единственном доступном языке, фактически лишён услуги.
Ключевые принципы
- Интернационализируйте архитектуру один раз; локализуйте содержимое много раз.
- Никогда не зашивайте видимый пользователю текст; выносите все строки в управляемые ресурсы.
- Используйте Unicode (UTF-8) повсюду; предполагайте, что текст может быть в любой письменности.
- Никогда не склеивайте переведённые фрагменты; грамматика и порядок слов различаются по языкам.
- Планируйте расширение текста, письменности справа налево и сложные правила множественного числа и рода.
- Форматируйте даты, числа, валюты и имена по локали, а не по коду.
- Отделяйте переводимое содержимое от кода, чтобы переводчики никогда не касались исходников.
- Локализация культурна, а не только лингвистична: цвета, образы и примеры имеют значение.
Рекомендации
Стройте здравую архитектуру интернационализации
Храните и обрабатывайте весь текст как Unicode (UTF-8) от конца до конца (база данных, API и UI), чтобы была представима любая письменность. Выносите каждую видимую пользователю строку в файлы ресурсов или каталог сообщений с ключом-идентификатором, никогда не встраивая в код или разметку. Представляйте локаль как язык плюс регион (и письменность, где нужно), чтобы можно было различать, например, варианты одного языка по странам. Держите логику форматирования в хорошо протестированной библиотеке интернационализации, а не пишите вручную форматирование дат, чисел и валют. Храните данные в нейтральных однозначных формах (метки времени UTC, коды стран и валют ISO, базовые единицы) и форматируйте только на уровне представления.
Правильно обращайтесь со сложностью языка
Не предполагайте длину текста; оставляйте щедрое место, потому что переводы обычно длиннее английского, и проектируйте компоновки, которые перетекают, а не обрезаются или накладываются. Поддерживайте двунаправленные (справа налево) письменности, используя логические, а не физические свойства компоновки, и зеркаля интерфейс где уместно. Используйте правила множественного числа локали через вашу библиотеку i18n (в языках от одной до шести форм множественного числа) вместо наивной логики единственного и множественного. Обрабатывайте род и грамматическое согласование там, где этого требует язык. Никогда не стройте предложения конкатенацией; используйте полные параметризованные шаблоны сообщений, чтобы переводчики управляли порядком слов.
Установите рабочий процесс локализации и управление переводами
Воспринимайте локализацию как непрерывный конвейер, а не пакет перед запуском. Извлекайте строки автоматически, отправляйте их в систему управления переводами и забирайте завершённые переводы обратно, в идеале в интеграции с CI, чтобы новые строки отмечались, а локализованные версии оставались синхронными. Давайте переводчикам контекст: снимки экрана, описания, лимиты символов, а также глоссарий и руководство по стилю на язык для согласованности терминологии и тона. Используйте память переводов, чтобы повторно использовать прежнюю работу и снижать затраты. Решите намеренно, где машинный перевод приемлем (малорисковое, большого объёма содержимое), а где нужны человеческий перевод и рецензия (юридическое, медицинское, безопасность, критичное для бренда). Псевдолокализуйте рано, заменяя строки удлинёнными заполнителями с диакритикой, чтобы поймать зашитые строки, обрезку и ошибки кодировки до начала настоящего перевода.
Локализуйте форматы, культуру и содержимое, а не только слова
Форматируйте даты, время, числа, валюты, адреса, телефонные номера и имена по локали, уважая местные соглашения (порядок даты, десятичные и разделяющие группы разряды, размещение валюты, порядок имён). Адаптируйте образы, значки, цвета, примеры и метафоры к местному культурному значению, поскольку символы и цвета несут разные коннотации в разных культурах. Учитывайте различия местного юридического и регуляторного содержимого. Различайте глобальную согласованность (бренд, основная функциональность) и региональную адаптацию (содержимое, примеры, соответствие) и решайте явно, какие элементы фиксированы, а какие гибки.
Управляйте i18n как общей инфраструктурой
Предоставьте общую библиотеку i18n, правила линтера для вынесения строк и стандартный механизм разрешения локали, чтобы команды не могли случайно зашить текст. Установите владение конвейером локализации и глоссариями. Тестируйте в нескольких локалях в CI, включая локаль справа налево и псевдолокаль с длинным текстом, чтобы регрессии ловились автоматически.
Компромиссы: плюсы и минусы
| Решение | Плюсы | Минусы |
|---|---|---|
| Интернационализировать с первого дня | Дешёвый выход на рынок позже, нет дооснащения | Предварительная цена даже до нужды во второй локали |
| Дооснащать i18n позже | Откладывает цену, если глобальная потребность неопределённа | Очень дорого и рискованно распутывать зашитые допущения |
| Человеческий перевод | Высокое качество, культурная точность | Медленнее и дороже |
| Машинный перевод | Быстро, дёшево, масштабируется на огромный объём | Риск качества и точности; непригоден для содержимого высоких ставок |
| Конвейер непрерывной локализации | Локали остаются синхронными, нет аврала перед запуском | Вложения в инструменты и процесс |
| Глубокая культурная адаптация по регионам | Лучшая местная подгонка и доверие | Больше вариантов содержимого для построения и сопровождения |
Поворотный компромисс это когда вкладываться в интернационализацию. Дооснащение i18n в продукт, полный зашитого, склеенного, предполагающего латиницу кода, одна из самых дорогих форм технического долга для погашения. Для любой организации с правдоподобными международными или многоязычными амбициями, а это практически все большие корпорации и многоязычные государства, ранняя интернационализация архитектуры гораздо дешевле дооснащения, хотя отдача отложена.
Вопросы для обсуждения с командой
Принуждаем ли мы вынесение строк правилами линтера и запускается ли псевдолокализация в CI до любого настоящего перевода? Долг, делающий интернационализацию дорогой (зашитые английские строки, склеенные фрагменты предложений, допущения латинской письменности), накапливается молча, если инструменты не останавливают его при коммите. Правила линтера, отмечающие зашитый пользовательский текст, плюс запуск в CI псевдолокали с длинным текстом и диакритикой ловят обрезку, наложение и ошибки кодировки, пока их дёшево исправлять. Именно это позволяет десяткам команд поставлять один продукт на многих языках, не изобретая каждой сантехнику заново и не распутывая допущения под сроком позже. Принесите поиск зашитых строк и спросите, могла бы какая-либо команда случайно выпустить такую сегодня. Если ничто в конвейере её не поймало бы, это пробел, который нужно закрыть первым.
Где мы храним канонические данные и ограничено ли форматирование уровнем представления? Хранение меток времени в UTC, стран и валют в кодах ISO и сумм в базовых единицах означает, что любая локаль может правильно форматировать их на краю, тогда как логика форматирования, запечённая в слой данных, порождает ошибки, болезненные для распутывания. Договоритесь, что даты, числа, валюты, адреса и имена форматируются только при представлении, через хорошо протестированную библиотеку, а не код, написанный вручную. Это важно для международных корпораций и многоязычных государств, где гражданин должен видеть правильный порядок даты, десятичные разделители и порядок имён по своему соглашению. Принесите пример значения, которое ваша система хранит уже отформатированным, и проследите, что ломается, когда новой локали нужно иначе. Если данные и представление спутаны, решите, как вы их распутаете, прежде чем добавлять локали.
Где именно приемлем машинный перевод и как наш конвейер локализации остаётся непрерывным, а не пакетным? Машинный перевод быстр и дёшев для малорискового содержимого большого объёма, но непригоден для юридического, медицинского, критичного для безопасности или бренда текста, где неверный перевод причиняет реальный вред, поэтому граница должна быть явной политикой, а не догадкой каждой команды. Равно воспринимание локализации как пакета перед запуском гарантирует аврал с переводом, тогда как автоматическое извлечение строк и синхронизация через систему управления переводами держит каждую локаль актуальной. Решите, кто владеет конвейером, глоссариями и барьером человеческой рецензии для строк высоких ставок. Принесите недавний выпуск и спросите, сколько времени его новые строки появлялись на каждом языке. Если локали расходятся между выпусками, ваш конвейер пакетный в маске.
Тестируем ли мы автоматически локаль справа налево и псевдолокаль с длинным текстом или тихо предполагаем латинские письменности и компоновки по длине английского? Двунаправленная поддержка (справа налево) и расширение текста допущения, ломающиеся наиболее заметно на новом рынке: зеркальные интерфейсы, которые так и не были отзеркалены, и кнопки, обрезающиеся, когда немецкий или финский оказывается на сорок процентов длиннее английского. Конкурирующее тяготение скорость, поскольку построение на логических, а не физических свойствах компоновки и подключение псевдолокали с диакритикой к непрерывной интеграции (CI) стоят усилий до того, как какой-либо настоящий клиент в них нуждается. Принесите снимок ваших самых загруженных экранов, отрисованных в локали справа налево и в удлинённой псевдолокали, и сосчитайте наложения, обрезанные подписи и застрявшие стрелки. Для международной корпорации или государства, по закону обязанного обслуживать язык справа налево или язык меньшинства, компоновка, не способная зеркалиться, не косметический дефект, а рынок или установленное законом обязательство, которые нельзя выполнить без перестройки.
Какие части продукта глобально фиксированы, а какие гибки по регионам и у кого полномочия решать? Локализация культурна, а не только лингвистична, поэтому цвета, образы, примеры, формы обращения и даже предлагаемые функции могут различаться по рынкам, но каждый допускаемый региональный вариант ещё один артефакт для построения, перевода, рецензии и сопровождения навсегда. Напряжение между местной подгонкой, строящей доверие и конверсию, и согласованностью, держащей бренд связным, а бремя сопровождения ограниченным. Принесите конкретный список того, что предлагаемая новая локаль изменила бы помимо переведённых строк, и оцените постоянное содержание каждого варианта, а не только его первое построение. В большой корпорации это решение нужно назвать владельцем, чтобы региональные команды не могли делать форк продукта стихийно, а в государстве оно должно соблюдать юридические правила содержимого и доступности, различающиеся по юрисдикциям и не необязательные.
Каким локалям мы реально обязуемся, как держим терминологию согласованной между ними и какие свидетельства управляют этим списком? Добавление языка легко пообещать и дорого поддерживать, потому что каждому нужны глоссарий, руководство по стилю, человеческая рецензия для строк высоких ставок и правильная обработка множественного числа и рода, которую наивная логика единственного или множественного неверно делает в большинстве языков. Конкурирующие соображения охват против цены: плохо обслуженный рынок или население может быть хуже необслуженного вовсе. Принесите население или выручку за каждой кандидатной локалью, покрытие правил множественного числа и форматирования, которое даёт для неё ваша библиотека, и кто владеет её глоссарием. Для международной корпорации драйвер охватываемый рынок и стоимость поддержки на язык, а для государства юридическое обязательство языкового доступа и равенство, измеряемые числом жителей, способных совершать операции только на этом языке.
Взгляд по секторам
Стартап. Сделайте дешёвые архитектурные выборы в первый день и остановитесь на них: UTF-8 от конца до конца, каждая видимая пользователю строка в каталоге сообщений, а даты, числа и валюты форматируются через библиотеку с учётом локали. Они стоят почти ничего, пока вы поставляете на одном языке, и спасают от переписи, когда ваш первый крупный клиент захочет второй. Не поднимайте конвейер перевода и не поддерживайте локали, за которые пока никто не платит; держите дверь открытой, а не обставляйте весь дом.
Малый бизнес. Без специалиста по интернационализации и при ограниченном бюджете опирайтесь на функции i18n, уже имеющиеся в вашем фреймворке, и размещённый сервис управления переводами, а не стройте конвейеры сами. Используйте машинный перевод для малорискового содержимого большого объёма и платите за человеческий перевод только там, где ошибка стоила бы вам клиента или нарушила правило, например юридический, критичный для безопасности или биллинговый текст. Обязывайтесь к локали, только когда конкретный рынок явно оправдывает постоянную цену перевода и рецензии.
Крупная организация. Проблема управление по многим командам: общая библиотека i18n, правила линтера, отвергающие зашитые строки, конвейер непрерывной локализации с памятью переводов и глоссариями на язык и многолокальный CI, включающий локаль справа налево и псевдолокаль с длинным текстом. Ведите локализацию как общую инфраструктуру с ясным владельцем, чтобы группы перестали изобретать сантехнику заново или расходиться. Измеряйте охват языков, качество локализации и время запуска новой локали и управляйте портфелем локалей по этим числам, а не запускайте рынки стихийно.
Государственный сектор. Языковой доступ нередко юридическое обязательство, охватывающее официальные языки, письменности справа налево и языки коренных народов и меньшинств, поэтому прозрачность и равенство определяют каждый выбор. Стройте общий фреймворк i18n и рабочий процесс перевода по ведомствам, требуйте человеческой рецензии юридической терминологии и терминологии безопасности и публикуйте глоссарии, чтобы термины оставались согласованными между услугами. Закупки должны требовать в контрактах поддержки локалей, справа налево и доступности, а население, обслуживаемое на каждом языке, метрика, оправдывающая расходы перед обществом.
Примеры
Стартап. Небольшой стартап, поставляющий только на английском, всё же сделал несколько дешёвых архитектурных выборов в первый день: UTF-8 повсюду, каждая видимая пользователю строка вынесена в каталог сообщений вместо зашитой, а даты и валюты форматируются через библиотеку с учётом локали. Это стоило им почти ничего, пока у них был один язык. Год спустя, когда их крупнейший потенциальный клиент попросил французскую и немецкую версии, добавление этих локалей было в основном упражнением по переводу, переданным подрядчику, а не переписью, и они закрыли сделку за недели, а не отложили её на квартал инженерной работы.
Крупная организация. Глобальная компания электронной коммерции интернационализировала платформу рано: UTF-8 повсюду, вынесенные строки, библиотека форматирования с учётом локали и конвейер непрерывной локализации с памятью переводов и глоссариями на язык. Выход на новый рынок стал в основном упражнением по контенту (перевести, рецензировать, подогнать образы), а не инженерным проектом, позволяя компании запускаться в новых локалях за недели. Поддержка справа налево, построенная на логических свойствах компоновки, означала, что рынкам арабского и иврита почти не потребовалась новая работа над UI.
Государственный сектор. Национальное правительство, по закону обязанное оказывать услуги на нескольких официальных языках, включая письменность справа налево и языки меньшинств, построило общий фреймворк i18n и рабочий процесс перевода, используемый по ведомствам. Псевдолокализация в CI поймала зашитые строки и обрезку до запуска; общий глоссарий сохранял юридическую терминологию согласованной между услугами и языками. Граждане могут совершать налоговые, медицинские операции и операции по пособиям на своём языке с правильным форматированием дат, чисел и имён, что удовлетворяет закону о языковом доступе и улучшает равенство для говорящих не на языке большинства.
Бизнес-обоснование: мотивы, ROI и TCO
ROI интернационализации это доступ к рынку и скорость. Хорошо интернационализированный продукт может выходить в новые страны и языковые рынки быстро и дёшево, превращая каждую новую локаль в дополнительную выручку или охват граждан, а не крупный проект. Качество локализации управляет конверсией, доверием и стоимостью поддержки на каждом рынке: пользователи совершают больше операций и реже обращаются в поддержку, когда продукт правильно говорит на их языке и уважает их соглашения.
По TCO стоимость принятия это предварительная инженерия для интернационализации плюс постоянные затраты на перевод и конвейер. Цена непринятия дорогое дооснащение: распутывание зашитых строк, конкатенации, ошибок кодировки и допущений компоновки по всей кодовой базе, нередко по сроку, продиктованному рынком или юридическим требованием. Плохая локализация несёт и скрытые затраты: потерянные продажи на плохо обслуживаемых рынках, бремя поддержки из-за запутанных форматов и юридический или репутационный ущерб от неверно переведённого содержимого высоких ставок. Непрерывная локализация избегает дорогих авралов с переводом перед запуском.
Чтобы обосновать это перед руководством, формулируйте интернационализацию как опцион на будущие рынки. Это скромное предварительное вложение, драматически снижающее цену и время каждого будущего выхода на рынок. Для государства драйвер юридическое обязательство языкового доступа и равенство, измеряемые населением, обслуживаемым на каждом языке.
Антипаттерны и ловушки
- Зашитые строки: пользовательский текст, запечённый в код, вынуждающий менять код под каждую локаль.
- Конкатенация строк: построение предложений из фрагментов, ломающее грамматику и порядок слов.
- Допущения не-Unicode: ошибки кодировки, моджибаке (искажённый текст из-за несовпадающих кодировок символов) и невозможность представить письменности.
- Допущение длины английского текста: компоновки, обрезающиеся или накладывающиеся при переводе.
- Игнорирование справа налево: физическая компоновка слева/справа, не способная зеркалироваться.
- Наивное множественное число: логика единственного/множественного, неверная в большинстве языков.
- Форматирование вслепую к локали: зашитые форматы дат, чисел и валют.
- Перевод без контекста: переводчики угадывают значение, производя ошибки.
- Пакетная локализация в последний момент: аврал перед запуском вместо непрерывного конвейера.
- Культурная глухота: образы, цвета или примеры, оскорбляющие или сбивающие с толку местных.
Модель зрелости
Уровень 1: Начальный. Один язык, зашитые строки, допущения не-Unicode и текст, построенный конкатенацией. Интернационализация реактивна: любая новая локаль означает изменение кода, а ошибки кодировки и компоновки находятся случайно в эксплуатации.
Уровень 2: Развитие. Некоторые строки вынесены, а Unicode используется местами, но практика непоследовательна между командами. Локализация ручное пакетное усилие перед запуском, а форматирование, обработка множественного числа и поддержка справа налево обрабатываются по-разному (или никак) от команды к команде.
Уровень 3: Стандартизация. Общая архитектура i18n и библиотека форматирования с учётом локали документированный принуждаемый стандарт по организации. Вынесение строк проверяется правилами линтера, на месте система управления переводами и непрерывный конвейер с глоссариями и памятью переводов, а псевдолокализация плюс многолокальное тестирование (включая локаль справа налево и с длинным текстом) работают в CI.
Уровень 4: Управление. Программа локализации измеряется и контролируется относительно базовых значений. Команды отслеживают охват языков, качество локализации и доли дефектов, задержку синхронизации строк от коммита до переведённого выпуска, дефекты обрезки и отрисовки справа налево, пойманные за выпуск, стоимость перевода на локаль и время запуска новой локали, а эти метрики управляют выпусками и определяют, куда вкладывать человеческую рецензию против машинного перевода.
Уровень 5: Оркестрация. Интернационализация и локализация непрерывно улучшаются и интегрированы по организации. Локализация непрерывна, машинный и человеческий перевод выбираются намеренно по классу содержимого, а культурная адаптация системна. Организация добавляет, выводит и пересматривает локали в ответ на свидетельства рынка и равенства, а новые локали запускаются быстро и качественно без дооснащения.
Идеи для обсуждения
- Как рано продукту следует интернационализироваться, если международный спрос неопределён?
- Где машинный перевод приемлем и где обязательна человеческая рецензия?
- Как держать терминологию согласованной по многим языкам и командам?
- Сколько региональной культурной адаптации стоит добавленного сопровождения вариантов?
- Как следует приоритизировать и тестировать поддержку справа налево и языков меньшинств?
- Как дать переводчикам достаточно контекста, не замедляя конвейер?
Главные выводы
- Интернационализируйте архитектуру один раз; локализуйте содержимое много раз.
- Используйте Unicode повсюду, выносите все строки и никогда не склеивайте переводы.
- Планируйте расширение текста, письменности справа налево и специфичные для локали правила множественного числа и форматирования.
- Ведите конвейер непрерывной локализации с памятью переводов, глоссариями и контекстом.
- Псевдолокализуйте рано в CI, чтобы ловить ошибки i18n до настоящего перевода.
- Локализация культурна, а не только лингвистична.
- Ранняя интернационализация гораздо дешевле дооснащения; для государства это юридическое требование равенства.
Источники и дополнительное чтение
- The Unicode Consortium, The Unicode Standard and Common Locale Data Repository (CLDR)
- W3C Internationalisation (i18n) Activity, techniques and best practices
- Richard Ishida, W3C internationalisation articles and tutorials
- Bert Esselink, A Practical Guide to Localisation
- John Yunker, Beyond Borders: Web Globalisation Strategies
- Unicode Technical Standard #35 (locale data markup) and ICU library documentation
- IETF BCP 47 language tags
- Government multilingual service and language-access guidance
- Nielsen Norman Group and W3C articles on RTL, text expansion, and localisation UX