Вы разрабатываете с учетом локализации?

13

Работая над программным проектом или веб-сайтом, вы разрабатываете с учетом локализации?

Я имею в виду, например,

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

В проектах, над которыми вы работаете, они относятся к категории «приятно иметь» и позволяют команде локализации беспокоиться об остальном, или у вас есть готовность к локализации, встроенная в ваш процесс разработки? Мне интересно услышать, как разработчики рассматривают локализацию в целом.

Джимми Коллинз
источник
3
L10N-> локализация ... давайте использовать правильный английский здесь, не так ли?
Ладья
11
@Rook - это обычная отраслевая аббревиатура, которая содержится в «Словаре аббревиатур American Heritage®», поэтому я хотел бы услышать ваше определение «правильного английского» (обратите внимание на заглавную букву «английского» :-)).
Джимми Коллинз
5
@Rook И это также записано как локализация;)
Роуланд Шоу,
2
@ Джимми C - Ни в черных, ни в Лонгмане, ни в Оксфорде, ни в Мерриане ... (и, верьте или нет, я взял на себя труд проверить их всех, чтобы быть уверенным). Но, очевидно, это просто уродливо и не похоже на слово (не уверен в этом, но я довольно силен в том, что у слов нет чисел).
Ладья
4
@Rook: это сокращение от нумеронима. Это же i18n для "интернационализации" и g11n для "глобализации". Они уродливы? Может быть, а может и нет. Факт в том, что они широко используются.
Энди

Ответы:

9

Я работаю в большой компании Fortune 500, и мы всегда начинаем с локализации. Наши проекты обычно предназначены только для США, но слишком часто за эти годы мы напишем приложение для клиента, а затем кто-то еще увидит его и скажет: «Эй, это было бы здорово для страны X». Затем следующая вещь, которую вы знаете, вы проходите через локализацию кода. Это действительно не займет больше времени, чтобы создать приложение с ним с самого начала, поэтому мы просто делаем. Плюс к этому дополнительное преимущество заключается в том, что когда клиент приходит к нам и просит, чтобы его приложение было (выберите ваш язык), мы вручаем им файл и говорим, чтобы оно было переведено (выберите ваш язык), и мы закончили. ,

Вальтер
источник
Правда. Но для личных проектов я не. Только английский.
6

Я думаю, что это было важно 10 лет назад. Последние технологии решили проблему .

Я живу в стране, где есть 3 национальных языка , и только один из них является меньшинством.

Чтобы понять проблемы, которые могут возникнуть из-за этого, это все равно, что говорить о том, что западная часть США говорит на (очень) другом языке, нежели восточная часть. Подумайте, что в центре страны население несколько слилось, поэтому вы должны использовать оба языка везде.

Наличие 4 языков в настольных приложениях и на веб-сайтах было и остается очень распространенным (3 национальных языка + английский). Иногда это обязательство.

Я знал о локализации, потому что меня обуславливало окружение. Да, несколько лет назад я беспокоился об этом.

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

Инструменты, которые я использую с Visual Studio .NET:

  • CodeRush , плагин Visual Studio, который позволяет перемещать жестко закодированные тексты в файлы ресурсов.
  • Easy Localizer , извлеките метки в файл Excel, в который вы добавите все дополнительные языки, а затем объедините их с файлами ресурсов.

источник
4
В самом деле? какие инструменты позволяют это?
Дэвид Вайзер
А как насчет таких вещей, как текст на изображениях и использование таких строк, как (например) «Ваша средняя школа», в формах, которые могут не пониматься в определенных регионах? Разработчик все еще должен знать о культурных различиях.
Джимми Коллинз
В Visual Studio я использую инструмент от DevExpress под названием CodeRush. Существует также другой инструмент, который я использую для перевода всего приложения сразу: Easy Localizer: foss.kharkov.ua/products/easy_localizer/index.htm (я добавлю их для справки в своем ответе)
4
хорошие инструменты, но это еще не все: например, макеты экрана могут измениться из-за разной длины меток; значения поиска в базе данных должны быть переведены; и т.д.
Стивен А. Лоу
@ Steven & JimmyC: здесь нет серебряных пуль. Просто хорошие инструменты, которые снимают большую сложность. Обратите внимание, что я заметил модель с годами работы над локализованными приложениями: вы не можете заранее знать, какой размер займет то или иное слово или предложение на языках, которые вы не знаете. Поверьте мне, они могут иметь очень разные размеры. Вы настраиваете свои интерфейсы и макеты во время тестирования.
4

Большинству моих клиентов требуется только один язык, и фактически они указывают этот язык. Поэтому мы не тратим время на локализацию приложения. Однако это не означает, что мы можем полностью игнорировать другие языки. Итак, мы придерживаемся основ:

  • Используйте Unicode везде. Это 2k10, нет никаких оправданий, чтобы не.
  • Дизайн для некоторой эластичности в макете. Даже со всем английским шрифты разных шрифтов имеют очень разные следы экрана при одинаковом размере точек.
  • Храните прикладные функции / моделирование данных вне уровня представления

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

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

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

Берин Лорич
источник
+1 за то, что вы придерживаетесь основ и вашего мнения о Unicode. Кроме того, вы делаете хорошее замечание о «гораздо большем, чем просто выделение текста». Это особенно верно при локализации приложений для языков, написанных справа налево (например, арабский или иврит), где весь пользовательский интерфейс должен быть зеркальным.
Джимми Коллинз
С точки зрения удобства использования простое отражение пользовательского интерфейса может быть не лучшим вариантом. Возможно, вам придется переупорядочить некоторые элементы в соответствии с местными соглашениями и сократить время обучения для ваших пользователей. Серьезные проекты интернационализации / локализации должны учитывать влияние на пользователей в этом регионе. Если они этого не сделают, приложение просто не получит принятия, на которое надеялись маркетологи.
Берин Лорич
3

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

Итак, мы сделали это по мере необходимости, в качестве стартапа.

Дэвид Торнли
источник
2

Кажется, что люди предпринимают очень легкие усилия. Особенно при использовании английского языка в качестве исходного, легко игнорировать тот факт, что другие языки обычно требуют даже 30-40% больше места для текста. Это требует от переводчиков использования сокращений, которые не так просто понять, что, конечно, плохо для пользовательского опыта.

Петтери
источник
1

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

user281377
источник
2
Не уверен, что это лучший подход - что делать, если вы получаете запросы на некоторые языки, которые могут быть проблематичными, например, на некоторые двухбайтовые языки, такие как японский, корейский и т. Д.?
Джимми Коллинз
1
Джимми С.: В настоящее время для проекта, над которым я работаю, достаточно поддержки европейских языков, таких как английский, немецкий, французский, испанский, польский и т. Д. Я просто не знаю достаточно о японском и других «проблемных» языках (например, написание инструкций и т. Д.), Чтобы сделать все необходимые приготовления в программном обеспечении; и нет никакого смысла тратить много времени и денег на то, что, вероятно, никогда не случится. Кстати, двухбайтовый не наша проблема, мы везде используем Юникод: D
user281377
Это имеет смысл в этом сценарии, я думаю.
Джимми Коллинз
Вам действительно не нужно много знать об арабском и японском языках, чтобы подготовиться к интернационализации. Есть общие рекомендации, которые обычно достаточно хороши. Если вы поддерживаете несколько европейских языков и используете Unicode, вы, скорее всего, добьетесь этого.
Дэвид Торнли
1

Я пишу приложения для Android, и локализация довольно проста с использованием строковых файлов в стиле Java. Практически ноль усилий для полной интернационализации на всех языках Android.

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

Ответ: да. Хотя в среде, в которой я работаю (Python / Zope / Plone), впоследствии очень легко локализовать строки, поэтому я пропускаю это, если это не является обязательным требованием с самого начала.

Но я храню текст в Unicode-объектах и ​​т. Д.

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

Леннарт Регебро
источник