Соображения по дизайну для интернационализации

Наша игра Gemsweeper переведена на 8 различных языков. Некоторые вещи, которые я узнал во время этого процесса:

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

• Предложения, которые следует переводить, не должны разбиваться на разные части по одной и той же причине. Это потому, что вам нужно поддерживать контекст (см. предыдущий пункт), а также потому, что некоторые языки могут иметь переменные в начале или в конце предложения. Используйте заполнители вместо того, чтобы разбивать предложение. Например, вместо

«Это шаг» «нашего 15-шагового руководства»

Напишите что-нибудь вроде:

«Это шаг% 1 нашего 15-шагового руководства»

и программно заменить заполнитель.

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

• Попробуйте найти переводчика, для которого первым языком является язык, на который он будет переводить вашу программу, а не наоборот. В противном случае он, скорее всего, напишет текст, который может быть правильным, но звучит странно или старомодно для носителей языка. Кроме того, он должен проживать в стране, на которую вы ориентируетесь со своим переводом. Например, немецкоязычный парень из Швейцарии не подойдет для немецкого перевода.

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

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

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

Изменить - еще несколько точек

• Сделайте переключение между локализациями как можно проще. В Gemsweeper есть горячая клавиша для переключения между разными языками. Это значительно упрощает тестирование.

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

• Не создавайте собственный фреймворк локализации. Вам, вероятно, намного лучше будет использовать фреймворк с открытым исходным кодом, например Gettext. Gettext поддерживает такие функции, как переменные в предложениях или множественное число, и надежен. Локализованные ресурсы скомпилированы, поэтому никто не может их изменить. Кроме того, вы можете использовать такие инструменты, как Poedit для перевода ваших файлов / проверки чужого перевода и проверки того, что все строки правильно переведены и остаются актуальными на тот случай, если вы измените исходный код. Я пробовал использовать как свой собственный, так и Gettext, и должен сказать, что Gettext плюс PoEdit были намного лучше.

Изменения - Еще больше очков

• Помните, что разные культуры имеют разные стили чисел и форматов даты. Схемы нумерации различаются не только для разных культур, но и для разных целей в рамках этих культур. В EN-US вы можете отформатировать число «-1234»; «-1,234» или (1,234) в зависимости от назначения числа. Поймите, что другие культуры делают то же самое.

• Знайте, откуда вы получаете информацию о глобализации. Например, В Windows есть настройки для CurrentCulture, UICulture и InvariantCulture. Поймите, что каждый из них означает и как он взаимодействует с вашей системой (они не так очевидны, как вы думаете).

• Если вы собираетесь переводить на восточноазиатские языки, сделайте свою домашнюю работу. Восточноазиатские языки во многом отличаются от языков здесь. Помимо одновременного использования нескольких алфавитов, они могут использовать разные системы компоновки (сверху вниз) или на основе сетки. Также цифры на восточноазиатских языках могут сильно отличаться. В en-US вы меняете системы только для ограниченных условий (например, 1 вместо 1), есть дополнительные числовые соображения, помимо запятой и точки.

• Мои меню и различные списки в приложении отсортированы в алфавитном порядке для каждого языка для облегчения чтения.

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

то же самое с ярлыками, если они у вас есть: не переводите их.

Кроме того, помните, что интернационализация и перевод - две очень разные вещи, управляйте ими по отдельности.

Когда мы работали над выпусками i18n / l10n Dreamfall и Age of Conan, мы столкнулись с несколькими проблемами, о которых стоит помнить. Некоторые из них мы решили, некоторые были решены за нас, а некоторые мы решили обойти. Некоторые мы так и не решили ...

• Убедитесь, что все ваши инструменты и весь ваш код поддерживают все кодировки, которые вы хотите использовать, и дважды проверьте это предположение в ходе проекта и еще пару раз, чтобы убедиться.

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

• Перенос текста выполняется не только в пробелах, поскольку в некоторых языках пробелы не используются для разделения слов (на ум приходит китайский). Убедитесь, что ваши подпрограммы переноса текста обрабатывают текст вообще без пробелов.

• Правильное обращение с множественным числом сложно в простых случаях и чертовски сложно в тяжелых. Убедитесь, что вы достаточно знаете о языках, которые будете использовать, чтобы написать код для правильной обработки множественного числа. Имейте в виду, что английский (и другие «западные» языки относятся к числу простых.

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

• Имейте в виду, что для некоторых языков значение заполнителя может изменить способ написания предложения. Грамматика - это сложно. Убедитесь, что у вас есть план, как с этим справиться. (В частности, убедитесь, что у вас есть способ классифицировать значения, которые вы используете в заполнителях, по полу, времени и т. Д.).

Я хотел бы сделать следующие комментарии - они взяты из руководящих принципов некоторых компаний, в которых продукты класса 1 переведены на 31 язык. Следование этим рекомендациям дало нам (нашей команде разработчиков, а не всей компании) максимальную продуктивность при переводе.

• Не пытайтесь повторно использовать фрагменты сообщений об ошибках. Например, не думайте, что из-за двух ошибок "You selected the wrong menu item" и "That menu item is not yet available" вы можете извлечь "menu item" в отдельный элемент и использовать его в обоих местах. Все сообщения должны быть автономными, поскольку их переводы могут изменяться в зависимости от контекста.

• Используйте профессионального переводчика, разбирающегося в технологиях. Если вы подойдете к такой службе, как BabelFish, вы получите все, что заслуживаете. Например, "Microsoft Windows" "Microsoft Windows" везде на планете, не становится "Microsoft Fenster" в Германии.

• Старайтесь не встраивать переменные в свои сообщения (например, "The %1 has failed", где %1 изменяется динамически), поскольку позиции и, действительно, пол могут измениться: "La table est rubbish" против "L'Homme est drunk" или "The red table" против "La table rouge". Лучше использовать родовое существительное с добавленными параметрами: "The item has failed [%1]".

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

• Меню следует сортировать по функциональности, а не по порядку.

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

На данный момент этого достаточно. Лучше остановиться, пока не уснули :-)

Кстати, о числах: в английском языке, как я понимаю, вы просто используете единственное число с 1 и множественное число с 2 или более. Нравится: «У вас 1 сообщение»; «2 сообщения»; «3 ... сообщения». В русском все усложняется. Вы используете единственное число для 1, 21, 31, 41 ... 101, 121 (так, для всего, что заканчивается на 1, кроме тех, когда оно заканчивается на 11). Затем вы используете родительный падеж единственного числа для 2, 3, 4; 22, 23, 24; 32, 33, 34 ... 102, 103, 104; 122, 123, 124. И во всех остальных случаях используется родительный падеж множественного числа.

Реализовать это совсем не сложно. Что сложно, так это реализовать что-то, что будет знать, как работать с любым априори неизвестным языком со всей его странностью :-)

И это просто цифры :-)

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

• Не делайте предположений. Это главное правило. Легко предположить, что что-то зависит от региона или языка, и трудно заметить эти предположения.
• Будьте очень осторожны при сравнении строк. Есть некоторые языки, например турецкий, в которых буквы визуально похожи на другие, но отличаются друг от друга.
• Используйте псевдоперевод в качестве дымового теста. Если вы читаете переведенные строки из файла ресурсов, создайте псевдо переведенную версию файла, которая все еще будет вам понятна, но которая подчеркивает емкость и возможности каждого переводимого строка в приложении. Например, дополните строку типа «Отмена» чем-то вроде «ОтменитьXXXX!». так, чтобы он был такой же ширины, как ваше разрешение на переведенные строки. Затем вы можете протестировать, чтобы убедиться, что каждая строка отображается полностью. Дополнительный балл за то, что он также вставил самый сложный символ, который может быть отображен, чтобы убедиться, что он отображается правильно во всех местах.
• Не делайте предположений о раскладке клавиатуры. "ASDW" может быть отличным набором клавиш со стрелками для QWERTY-клавиатур, но жесткое кодирование, которое делает его недружелюбным, если не невозможным, использовать для людей с другими раскладки клавиатуры.
• Проверьте различные настройки даты, а затем проверьте их снова. Я видел проблемы из-за чего-то небольшого, например, другого формата для "AM / PM" в региональных настройках. Мм / дд / гггг по сравнению с дд / мм / гггг также часто встречается, но каждая настройка здесь может иметь значение.
• Протестируйте различные числовые форматы, а затем проверьте их снова. Например, вы не хотите зависеть от десятичных разделителей или разделителей тысяч.
• Тестирование с пользователем, выполнившим вход на сервер, и без него. Это может быть более специфичным для Windows, но очень легко настроить компонент на сервере таким образом, чтобы он использовал региональные настройки вошедшего в систему пользователя, в то время как пользователь вошел в систему и региональные настройки по умолчанию, когда пользователь не вошел в систему. Это может вызвать странное, прерывистое поведение.
• Тестируйте с различными региональными и языковыми настройками. Например, не только в Windows есть региональные и языковые настройки, но и в IE есть свои собственные языковые настройки. Например, поведение клиента IE с en-us в списке первым может не всегда совпадать с поведением клиента с en-nz.
• Убедитесь, что ваш переводчик понимает бизнес и языки, затем сверьте с кем-нибудь еще. Будьте очень осторожны, когда используете терминологию, относящуюся к конкретному приложению. Если ваша программа использует определенные слова для обозначения чего-то особенного в приложении, убедитесь, что они переведены одинаково во всех случаях, в том числе в тексте справки. Если у вас есть конкретные языковые цели, вы можете даже зайти так далеко, что переводите такие слова заранее и убедитесь, что они не переводятся плохо на целевых языках. Это скорее вопрос исследования продукта, но он может иметь значение, какие слова используются в интерфейсе, и всем будет проще, если эти слова будут присутствовать с самого начала. Вы также должны избегать идиом, которые могут плохо переводиться.

Хорошо, я мог сказать больше, чем думал ...

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

например вместо имени файла 'sample-database.txt' назовите английскую версию 'sample-database-loc-en.txt', итальянскую версию 'sample-database-loc-it.txt

Мой первый ответ в StackOverflow, так что прошу прощения за глупость.

По моему опыту:

• PHP: gettext оказался чрезвычайно полезным;
  
• незападные языки: UTF-8 везде (код, БД), и пока у нас все хорошо;
  
• Есть ли какие-то особые ошибки, с которыми вы сталкивались на практике? Разбиение длинных абзацев для i18n на разные предложения может быть менее затратным для перевода, если строка повторяется на сайте более одного раза, вам нужно только переведите его один раз. Но будьте осторожны, если вы слишком сильно фрагментируете текст, переводчики потеряют контекст;
  
• Я видел множество проектов и сайтов, позволяющих своим сообществам обеспечивать перевод своих приложений и контента. Вы порекомендуете это и каковы хорошие стратегии для обеспечения хорошего перевода? Если у вас очень много добровольцев, сделайте это, но в зависимости от того, сколько текста у вас есть, вам действительно может понадобиться тонна добровольцев. Всегда убедитесь, что у вас есть кто-то, кому вы доверяете как руководитель языкового проекта, который будет корректором, контролирующим точность перевода.
  

• Правила сопоставления / сортировки могут сильно различаться между языками: ä сортируется по-другому на немецком, чем на шведском. Таким образом, сортировка должна зависеть от культуры.
• Верхний / нижний регистр может содержать сюрпризы: Немецкий символ «острый S» ß не имеет версии в верхнем регистре и либо преобразуется в «SS», либо остается в нижнем регистре, если важна точность. В турецком есть строчная буква i без точки и прописная буква I.
• Для многоязычных веб-приложений тщательно подумайте о том, как решить, какую версию показывать и как включить ее в URL-адрес. Пользователь всегда должен иметь возможность вручную выбирать язык, и вы хотите, чтобы поисковые системы находили разные языковые версии по разным URL-адресам.
• В некоторых восточноазиатских языках (например, в японском и китайском, возможно, в других) нет пробелов между словами.
• Японский язык (возможно, и другие) имеет отдельные версии ("полную ширину") арабских цифр и пробела и даже две версии некоторых собственных символов (катакана половинной и полной ширины).

Да, это массовая тема. Сделать это правильно - это ужасно много работы.

В моей программе я использую целочисленный ключ для каждого фрагмента текста и ищу его в файле по мере необходимости в зависимости от языка. В коде нет буквальных строк, только ключи. Я определяю их с помощью «enum» в C ++, поэтому я на самом деле не набираю числа. Я написал утилиту для синхронизации файлов на разных языках, когда я добавляю перечисления, а переводчики заполняют пробелы.

С каждой клавишей также связана всплывающая подсказка, изображение, сочетание клавиш и т. Д.

Что касается времени и даты ... опять же, это намного сложнее, чем вы думаете, но разве PHP не справляется с этим за вас? (Не знаю, я парень C ++ ...)

PHP представляет строки внутри как байтовые потоки и предполагает iso-8859-1 для случаев, когда кодирование имеет значение. По большей части вы можете просто использовать UTF-8 повсюду, и все будет в порядке. Одна проблема, если ваш сайт принимает информацию от своих пользователей, заключается в том, что вы никогда не можете быть на 100% уверены, что они отправляют контент в правильной кодировке. Вы можете использовать mb_detect_encoding для проверки ввода или использовать скрытое поле с «экзотическими» символами для проверки.

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

Еще один хороший ресурс по PHP - это шпаргалка Ника Неттлтона.

Тема, которая очень тесно связана с кодировками / кодировками, - это сопоставление. Вам нужно, чтобы ваши сопоставления соответствовали языку / культуре, с которыми вы работаете. По крайней мере, в MySql (возможно, и в других СУБД) вы можете указать сопоставление на разных уровнях, например, для каждой базы данных, таблицы, столбца и даже в самом запросе.