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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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