Интернационализация в ваших проектах

Как вы реализовали интернационализацию (i18n) в реальных проектах, над которыми работали?

Я заинтересовался межкультурным программным обеспечением после того, как прочитал знаменитый пост Джоэла «Абсолютный минимум, что каждый разработчик программного обеспечения должен знать о Unicode и наборах символов (без оправданий!)» . Однако мне еще предстоит воспользоваться этим в реальном проекте, кроме как убедиться, что я использую строки Unicode, где это возможно. Но преобразование всех ваших строк в Unicode и обеспечение понимания того, в каком кодировании находится все, с чем вы работаете, - это лишь верхушка айсберга i18n.

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

Ответов (11)

Прошло некоторое время, так что это не исчерпывающе.

Наборы символов

Юникод - это здорово, но вы не можете игнорировать другие наборы символов. Набор символов по умолчанию в Windows XP (английский) - Cp1252. В Интернете вы не знаете, что вам отправит браузер (хотя, надеюсь, ваш контейнер справится с большей частью этого). И не удивляйтесь, если в любой реализации, которую вы используете, будут обнаружены ошибки. Наборы символов могут интересно взаимодействовать с именами файлов при перемещении между машинами.

Перевод строк

Переводчики, вообще говоря, не программисты. Если вы отправите исходный файл переводчику, он сломается. Строки следует извлекать в файлы ресурсов (например, файлы свойств в Java или библиотеки ресурсов в Visual C++). Переводчикам следует давать файлы, которые трудно сломать, и инструменты, которые не позволяют им их сломать.

Переводчики не знают, откуда в продукте берутся строки. Строку без контекста сложно перевести. Если вы не предоставите инструкции, качество перевода пострадает.

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

Перевод строк стоит денег. Если вы выпускаете новую версию продукта, имеет смысл восстановить старые версии. У вас есть инструменты для восстановления строк из ваших старых файлов ресурсов.

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

Переводчики должны иметь возможность изменять горячие клавиши. Ctrl+ Pесть печать на английском языке; немцы используют Ctrl+ D.

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

Даты, время, календари, валюта, числовые форматы, часовые пояса

Все они могут отличаться от страны к стране. Для обозначения десятичных знаков может использоваться запятая. Время может быть в 24-часовом формате. Не все используют григорианский календарь. Вы тоже должны быть недвусмысленными. Если вы позаботитесь, чтобы на вашем веб-сайте даты отображались как ММ / ДД / ГГГГ для США и ДД / ММ / ГГГГ для Великобритании, даты будут неоднозначными, если пользователь не знает, что вы это сделали.

Особенно валюта

Функции Locale, представленные в библиотеках классов, дадут вам символ местной валюты, но вы не можете просто вставить символ фунта (стерлингов) или евро перед значением, которое дает цену в долларах.

Пользовательские интерфейсы

Макет должен быть динамичным. При переводе длина строк может увеличиться не только вдвое, возможно, потребуется инвертировать весь пользовательский интерфейс (иврит; арабский), чтобы элементы управления работали справа налево. И это до того, как мы перейдем в Азию.

Тестирование перед переводом

  • Используйте статический анализ вашего кода, чтобы найти проблемы. Как минимум используйте инструменты, встроенные в вашу IDE. (Пользователи Eclipse могут перейти в Window> Preferences> Java> Compiler> Errors / Warnings и проверить строки, не относящиеся к внешнему.)
  • Дымовой тест с имитацией перевода. Несложно проанализировать файл ресурсов и заменить строки псевдотранслированной версией, которая удваивает длину и вставляет забавные символы. Вам не нужно говорить на каком-либо языке, чтобы использовать чужую операционную систему. Современные системы должны позволять вам входить в систему как иностранный пользователь с переведенными строками и иностранной локалью. Если вы знакомы со своей ОС, вы можете понять, что и что делает, не зная ни единого слова на языке.
  • Карты клавиатуры и ссылки на наборы символов очень полезны.
  • Виртуализация была бы здесь очень полезна.

Нетехнические вопросы

Иногда нужно учитывать культурные различия (это может привести к оскорблению или непониманию). Ошибка, которую вы часто видите, - это использование флагов в качестве визуальной подсказки при выборе языка или географии веб-сайта. Если вы не хотите, чтобы ваше программное обеспечение заявляло о чьей-либо стороне в глобальной политике, это плохая идея. Если вы были французом и предложили вариант английского языка с флагом Святого Георгия (флаг Англии - это красный крест на белом поле), это могло бы запутать многих англоговорящих - предположим, что аналогичные проблемы возникнут с иностранными языками и странами. . Иконки необходимо проверять на предмет культурной значимости. Что означает значок "большой палец вверх" или зеленая галочка? Язык должен быть относительно нейтральным - обращение к пользователям определенным образом может быть приемлемым в одном регионе, но считаться грубым в другом.

Ресурсы

Программистам на C++ и Java может быть полезен веб-сайт ICU: http://www.icu-project.org/

Несколько забавных вещей:

  1. Наличие приложения PHP и MySQL, которое хорошо работает с немецким и французским языками, но теперь должно поддерживать русский и китайский языки. Я думаю, что перенесу это в .net, поскольку поддержка Unicode в PHP, на мой взгляд, не очень хороша. Конечно, жонглировать с utf8_de / encode или mbstring-functions - это весело. Почти так же весело, как если бы Фредди Крюгер навещал вас ночью ...

  2. Понимание того, что некоторые языки НАМНОГО более подробны, чем другие. Немецкий язык намного более подробен, чем обычно, и видеть, как немецкая версия разрушает пользовательский интерфейс из-за того, что было выделено слишком мало места, было неинтересно. Некоторые продукты получили известность благодаря своим креативным способам решения этой проблемы, например, «Schw.Tr.d.Le.En.W.» Oblivion. запоминающийся :-)

  3. Играя с форматами даты, уууу! Да, на самом деле в мире есть люди, которые используют форматы даты, в которых день идет посередине. Оооочень весело пытаться выяснить, что должно означать 07/02/2008, просто потому, что некоторые пользователи могут подумать, что это могло быть 2 июля ... месяц посередине :-P, особенно потому, что на английском языке 2 июля звучит намного лучше, чем 2 июля, что не обязательно относится к другим языкам (то есть на немецком языке вы никогда не скажете Juli 2, но всегда Zweiter Juli). По возможности использую 07.02.2008. Понятно, что это означает 7 февраля, и он сортируется правильно, но дд / мм против мм / дд может быть действительно сложной проблемой.

  4. Еще интересная штука, Числовые форматы ! 10.000,50 против 10,000,50 против 10 000,50 против 10'000,50 ... Это мой самый большой кошмар прямо сейчас - необходимость поддерживать многокультурную среду, но не иметь никакого способа достоверно узнать, какой формат числа использует пользователь буду использовать.

  5. Формальный или неформальный. В некоторых языках существует два способа обращения к людям: формальный и более неформальный. На английском вы просто говорите «You», но на немецком вам нужно выбрать между формальным «Sie» и неформальным «Du», то же самое для французского Tu / Vous. Обычно лучше выбрать формальный путь, но его легко упустить из виду.

  6. Календари. В Европе первый день недели - понедельник, а в США - воскресенье. Виджеты календаря хороши. Показывать календарь с воскресеньем слева и субботой справа европейскому пользователю не так хорошо, это их сбивает с толку.

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

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

Еще одно замечание: очень строго избегайте объединения видимых строк напрямую, например

String message = "The " + item + " is on sale!";

Вместо этого вы должны использовать что-то вроде

String message = String.Format("The {0} is on sale!", item);

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

Сегодня утром я как раз слушал подкаст Скотта Хансельмана , в котором он говорит об интернационализации, особенно о действительно сложных вещах, таких как турецкий (с четырьмя i) и тайский. Также у Джеффа Этвуда был пост :

На одном веб-сайте, который я использую, есть метод перевода, который владелец называет «вики + машинный перевод». Это сайт сообщества, поэтому он явно отличается от потребностей компаний.

http://blog.bookmooch.com/2007/09/23/how-bookmooch-does-its-translations/

Я думаю, что каждый, кто работает в области интернационализации, должен быть знаком с репозиторием данных Common Locale, который теперь является подпроектом Unicode:

Общий репозиторий данных локали

Эти люди упорно работают над созданием стандартного ресурса для всех видов вопросов i18n: валюты, географических названий и т. Д. ИМХО, любой проект, который поддерживает свои собственные основные локальные данные, с учетом того, что этот проект существует, довольно чокнутый.

Помимо всех предыдущих советов, помните, что i18n - это не просто замена слов на их эквиваленты на других языках, особенно для алфавитов нелатинских языков (корейский, арабский), которые пишутся справа налево, поэтому весь пользовательский интерфейс должен соответствовать, например

  • пункт 1
  • пункт 2
  • пункт 3

должно быть

арабский текст 1 -

арабский текст 2 -

арабский текст 3 -

(Перевернутый список маркеров, похоже, не работает: P)

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

Еще одна очень сложная задача - проверить разные языки не только на правильность слова, но так как такие языки, как корейский, обычно имеют более крупный тип шрифта для своих символов, это может привести к языковым ошибкам (например, текст «СОХРАНИТЬ» на кнопке больше, чем сама кнопка для какого-то языка).

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

Одна из самых забавных вещей, которую можно обнаружить: курсив и жирный текст makrup не работает с символами CJK (китайский / японский / корейский). Они просто становятся нечитаемыми. (Хорошо, я тоже не мог их прочитать раньше, но особенно жирный шрифт создает чернильные кляксы)

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

Я предлагаю использовать что-то вроде 99translations.com для поддержки ваших переводов. В противном случае вы не сможете сказать, какие из ваших переводов актуальны на всех языках.