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

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

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

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

11 ОТВЕТОВ

Это было какое-то время, так что это не является всеобъемлющим.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Нетехнические проблемы

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

Ресурсы

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

47
6.02.2013 10:34:58
msgstr "заменить строки псевдопереведённой версией, которая удваивает длину и вставляет прикольные символы." Круто, это отличный совет, спасибо!
warp 29.06.2009 08:11:56
Форматы даты больше не отличаются. Все должны использовать новый мировой стандарт даты, ISO8601 (ГГГГ-ММ-ДД). en.wikipedia.org/wiki/ISO_8601
Pavel Radzivilovsky 29.12.2009 16:19:11
@Pavel - разработчики должны принять стандартные формы для текстовых форматов дат. Вероятно, оптимистично ожидать, что конечные пользователи во всем мире отбросят формат, который они всегда использовали, и перейдут на новый формат - по крайней мере, не без серьезных побуждений и жалоб на то, как ваша программа сломана или не имеет смысла. Внутренние формы хранения должны быть абстрагированы от форм отображения / ввода.
McDowell 29.12.2009 23:51:22

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

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

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

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

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

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

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

15
23.05.2017 11:45:36
на самом деле в Европе существует много вариаций. Например, в Португалии первый день недели воскресенье, как в США.
Elzo Valugi 22.05.2012 13:36:56

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

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

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

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

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

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

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

8
7.02.2013 17:33:54
Хороший вопрос, но вы все равно должны быть осторожны. У вас могут возникнуть проблемы с грамматическими соглашениями между вашим фиксированным текстом и тем, что вы заменяете. Например, это элемент мужской / женский / ни один на немецком языке, потому что "The" будет Der / Die / Das, в зависимости от того, какой он есть.
MarkJ 28.01.2009 13:05:27

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

5
7.02.2013 17:33:40

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

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

должно быть

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

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

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

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

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

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

3
21.09.2008 23:44:16

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

2
7.02.2013 17:32:25
@MeNoMore Опять же, "CJK" не код; это аббревиатура для чего-то. Не используйте форматирование кода для подобных вещей, пожалуйста.
Andrew Barber 7.02.2013 17:32:21
@ AndrewBarber вы получили это, никогда не повторится, спасибо.
CloudyMarble 8.02.2013 06:44:59

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

Общее хранилище данных локали

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

1
18.09.2008 19:25:06

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

1
27.12.2008 04:10:55

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

1
27.12.2008 06:48:52

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

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

0
10.09.2008 15:12:54

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

0
7.10.2008 10:56:59
Хороший вопрос, и это не просто порядок. У вас могут возникнуть проблемы с грамматическими соглашениями между вашим фиксированным текстом и тем, что вы заменяете. Например, мужчина / женщина / нейтральный, множественное число / единственное число.
MarkJ 28.01.2009 13:07:15