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

Question

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

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

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

Answer 1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Используйте статический анализ вашего кода для поиска проблем. Как минимум, используйте инструменты, встроенные в вашу IDE. (Пользователи Eclipse могут перейти в «Окно»> «Установки»> «Java»> «Компилятор»> «Ошибки / предупреждения» и проверить наличие неэкспериментированных строк.)
• Тест дыма путем симуляции перевода. Нетрудно разобрать файл ресурсов и заменить строки псевдопереведенной версией, которая удваивает длину и вставляет прикольные символы. Вам не нужно говорить на языке, чтобы использовать иностранную операционную систему. Современные системы должны позволять вам входить в систему как иностранный пользователь с переведенными строками и иностранным языком. Если вы знакомы с вашей ОС, вы можете выяснить, что и для чего, не зная ни слова из языка.
• Карты клавиатуры и ссылки на наборы символов очень полезны.
• Виртуализация была бы очень полезна здесь.

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

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

Ресурсы

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

Answer 2

Некоторые забавные вещи:

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

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

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

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

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

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

Answer 3

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

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

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

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

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

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

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

Answer 4

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

Answer 5

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

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

должно быть

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

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

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

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

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

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

Answer 6

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

Answer 7

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

Answer 8

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

Answer 9

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

Репозиторий общих локалей

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

Answer 10

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