Logrus

Русский Українська English Deutsch 中文 Français
v
Знания

Журнал

О проекте

Свежий номер

Избранные статьи

Архив

Машинный перевод

Память переводов

Наши публикации

Грабли

Полезные ссылки

Вопрос - Ответ


Отзывы

Дима, привет!

Спасибо вам огромное за такую оперативную работу! Мне очень нравится с вами работать и приятно, что на вас всегда можно положиться, даже со сложными и срочными задачками.
Я отправила тексты в корп, хочу отметить, что сделаны очень хорошие правки, текст читается отлично.

Спасибо
 

Людмила



Интернационализация: 12 мифов и заблуждений

Андреа С. Вайн (Andrea S. Vine)

Миф 1. Достаточно позаботиться о том, чтобы можно было локализовать элементы интерфейса
 
Допустим, это так. В таком случае продукт придётся изменять для каждой из стран, в которых он продается, будь то Канада, Великобритания, Бразилия, Новая Зеландия, Греция и множество других. Разумеется, производители не проводят локализацию продуктов для каждой отдельно взятой страны, иначе отделы по локализации были бы несравнимо больше, впрочем, как и выделяемый для этого бюджет. На практике компании распространяют по всему миру англоязычные версии, делая исключение лишь для нескольких крупнейших рынков, куда поставляются локализованные продукты. Однако и они продаются сразу в нескольких странах.
 
Именно поэтому необходимо знать регион, в котором находится пользователь, даже если придётся спросить его об этом напрямую. Цифровые и текстовые форматы, даты, а также любые другие данные, к которым применяется форматирование, должны выводиться в том стиле, который принят в данном регионе.
 
Особое внимание необходимо уделить обработке значений. Например, для пользователей из Германии цену, которая хранится в программе в американских долларах, можно представить двумя следующими способами.
 
1. Валюта остается прежней (американский доллар), но при этом сумма выводится в цифровом формате, принятом в Германии: USD 250 467,10.
 
2. Сумма пересчитывается в немецкие марки и приводится с соответствующим валютным символом в адекватном цифровом формате: DEM 528 450,47. Даже если значение указывается в американских долларах, разделителем для целой части числа должен служить пробел, а для десятичной – запятая. Если тысячи будут отделены запятой, как это принято в Америке, сумма почти наверняка приведёт немецкого покупателя в замешательство.
 
Итак, формат записи должен соответствовать принятому в конкретной местности стандарту, однако значения изменяются только при пересчете в другие единицы измерения.
 
Графические материалы для оформления продуктов используются повсеместно, однако их локализация настолько дорога, что обычно её проводят лишь при наличии встроенного текста (чего по возможности следует избегать). Также нужно проверить, что графические изображения универсальны и могут использоваться в самых разных странах.
 
Миф 2. Переводчик выбирает лучший вариант перевода
 
Распространено мнение, что переводчик, занимающийся локализацией продукта, всегда выбирает термины и обороты речи, лучше всего отвечающие контексту и ситуации. В действительности локализация, как правило, проводится в условиях малого бюджета и сжатых сроков, и специалисты переводят подборки сообщений совсем не в том порядке, в котором они выводятся на экран. Они не очень хорошо знакомы с продуктом, и даже при наличии рабочей версии программного обеспечения на поиск контекста и полную лингвистическую проверку у них скорее всего просто не хватит времени. Труд переводчика чаще всего оплачивается пословно. Неудивительно, что объём оказывается одним из главных приоритетов в этой области. А теперь представьте, каким может оказаться качество перевода в подобной ситуации.
 
Миф 3. Код написан на языке Java, следовательно, он интернационализирован
 
Интернационализированный код существовал задолго до создания языка Java. Встаёт вопрос: как же программистам удавалось добиться этого? Дело в том, что интернационализация была возможна всегда, но процесс был гораздо более трудоёмким. Появление языка Java значительно упростило его. Тем не менее создание неинтернационализированного кода Java также возможно. Для того чтобы написать код, поддерживающий только английский язык, особых усилий не требуется, поэтому даже при кодировании на языке Java необходимо внимательно относиться к вопросам поддержки интернациональных данных.
 
Миф 4. Продукт полностью поддерживает стандарт Юникод, следовательно, интернационализирован
 
Этот миф аналогичен предыдущему. Как и язык Java, Юникод призван упростить процесс обработки специфических национальных данных. Однако ещё раз подчеркнем, что код должен обеспечивать обработку данных на нескольких языках, для различных регионов и с использованием разных наборов символов. И как? Действительно всё так просто?
 
Миф 5. Интерфейсы администрирования и сообщения журналов можно не интернационализировать
 
Сетевые администраторы тоже люди, и для некоторых рынков интерфейс администрирования нужно будет локализовать. Но это не значит, что выбор, оптимальный в одном случае, будет столь же хорош в других условиях. В каждом конкретном случае решение о том, следует ли осуществлять перевод продукта, лежит в коммерческой, а не в технической плоскости.
 
Задача инженеров состоит в том, чтобы обеспечить условия для максимального повышения объёма продаж, что, в свою очередь, увеличивает прибыли компании, может поднять цену акций и даёт свои преимущества всем сотрудникам. Если локализация проводится, она так или иначе должна охватывать весь продукт.
 
Сообщения журналов представляют собой особую категорию сообщений. Обычно они не локализуются напрямую, однако в отдельных случаях их можно локализовать через средство просмотра журнала. Для этого сообщения должны быть сохранены в отдельном ресурсном файле. Итак, сообщения журналов должны быть локализуемы, но содержаться при этом отдельно от прочих сообщений, чтобы вопрос об их переводе можно было решить в процессе локализации. Если сообщение относится одновременно и к журналу, и к пользовательскому интерфейсу, а языком журнала является английский, сообщение пользовательского интерфейса должно извлекаться из переведённого ресурсного файла, а сообщение журнала – из его английской версии. При этом английская версия файлов должна поставляться вместе с локализованными продуктами.
 
Миф 6. В продукте используется открытый исходный код, следовательно, интернационализация бесполезна
 
Специалисты часто объясняют свой отказ интернационализировать продукт тем, что не в состоянии управлять открытым исходным кодом, на базе которого он создан. Однако общий результат интернационализации, как и скорость эскадры, оценивается по самому «тихоходному кораблю». В первую очередь при принятии решения об использовании открытого исходного кода следует учитывать все существующие требования к компонентам продукта. Если отдельные элементы кода не удовлетворяют требованиям заказчика, при включении их в программу необходимо учитывать, что для поддержки интернационализации их, возможно, придётся переписать. Только в этом случае продукция будет соответствовать ожиданиям потребителей, а, следовательно, пользоваться спросом.
 
Миф 7. ISO-8859-1 – стандартная кодировка для HTML
 
В технических характеристиках HTML указывается, что кодировка ISO-8859-1 используется по умолчанию, но она не является стандартной. ISO-8859-1 позволяет отображать на веб-страницах лишь ограниченный набор языков, но есть и другие варианты.
 
Спецификации HTML 4.0 ссылаются на набора символов Юникода. Это означает, что все числовые кодировки символов интерпретируются в соответствии со стандартом Юникод, поддержка которого обеспечивается и для процессов HTML 4.0. Таким образом, при использовании UTF-8 в качестве кодировки для HTML-страниц они будет корректно обрабатываться всеми браузерами и веб-серверами. Помимо этого, UTF-8 охватывает большинство мировых языков.
 
Миф 8. Все сотрудники владеют английским языком, следовательно, поддержка других языков для внутренних программных средств компании не нужна
 
Как правило, для взаимодействия внутри компании выбирается какой-либо определённый язык. В американских компаниях таким языком обычно является английский. Однако внутренние программные средства обрабатывают также информацию, связанную с внешними операциями компании. Это могут быть, например, клиентские базы данных, журналы технической поддержки или базы данных с записями программных ошибок. Информация от зарубежных клиентов часто поступает на других языках в местных форматах.
 
То же можно сказать и о записях по программным ошибкам. Попытки зарегистрировать в англоязычной системе сообщение об ошибке, к примеру, с японскими символами неизбежно завершаются провалом. Обычно в таких случаях запись так и не удаётся разместить. Если же это всё-таки удаётся, в системе зачастую оказывается недостаточно данных для воспроизведения ошибки. В результате страдает качество продукта, а причина падения объёма продаж на рынках неанглоязычных стран может так и остаться загадкой.
 
Требования для программного обеспечения, предназначенного для внутреннего использования не должны уступать требованиям к международной продукции компании.
 
Миф 9. Если продукт никогда не локализовывался, интернационализировать его незачем
 
В интернационализации нуждаются не только элементы пользовательского интерфейса, но и все компоненты, отвечающие за обработку данных. Если англоязычный продукт распространяется по всему миру, необходимо обеспечить корректную обработку всей информации. И наоборот: неанглоязычная информация обрабатывается, в том числе, и в англоязычных регионах (см. мифы 1 и 8).
 
Не стоит слепо копировать предыдущий опыт локализации: будущее вносит свои коррективы. В каждом конкретном случае решение о том, следует ли переводить продукт, лежит в коммерческой, а не в технической плоскости (см. миф 5). Задача инженеров состоит в том, чтобы обеспечить условия для максимального повышения объёма продаж.
 
Миф 10. Последняя версия продукта интернационализирована – задачу можно считать выполненной
 
Представьте себе, что данное высказывание относится к архитектуре или к функциональным возможностям какой-либо программы — элементам безопасности, рабочим характеристикам или, например, настройкам печати в текстовом редакторе. Предположение, что отдельный элемент программного кода завершён, в то время всё остальное продолжает изменяться, само по себе нелепо. Интернационализация затрагивает весь программный код, каждая добавляемая строка должна приниматься в расчёт. Со временем меняются и требования к продукту, может возникнуть необходимость в новых функциях или в усовершенствовании архитектуры. Интернационализация завершается только вместе с работами над продуктом в целом.
 
Миф 11. Продукт поддерживает японский язык, следовательно, интернационализирован
 
Тот факт, что продукт успешно прошёл тестирования на японском языке, снимает массу проблем, но не все. Нельзя сбрасывать со счетов другие языки, такие как арабский, хинди или французский, содержащие символы, которых нет в японском. Даже в китайском существуют свои отличия. Могут возникнуть сложности и с другими региональными настройками. К сожалению, поддержка японского ещё не означает, что продукт будет корректно функционировать в многоязыковой среде. Тестирование необходимо продолжать.
 
Миф 12. Интернационализация — работа для отдельной группы инженеров, выполняемая после того, как основное кодирование продукта завершено
 
Разумно ли поручать работу над одним и тем же участком кода нескольким инженерам? Не приведёт ли это к переписыванию кода? Большинство компаний сочтут такой вариант непозволительной роскошью, ведь работа инженеров обходится недёшево. Однако именно этим всё и заканчивается, если интернационализация рассматривается как отдельный этап и проводится выделенной группой инженеров или передаётся сторонним поставщикам услуг. И справедливо это для каждой версии продукта, поскольку интернационализация определяет методологию построения архитектуры и кодирования. Это не дополнительная функция. И даже если компания способна обеспечить интернационализацию уже выпущенного продукта, качество её будет значительно ниже. Ведь инженеры, отвечающие за интернационализацию продукта, как правило, знакомы с продуктом гораздо хуже, чем инженеры-разработчики, и вероятность того, что в обновлённом ими коде будут содержаться непредвиденные ошибки, намного выше. И наконец, продукт изначально не был разработан для использования за рубежом, а потому может некорректно функционировать в других странах.
 
Интернационализация — это не то, что может сделать кто-нибудь и потом. Этот процесс требует внимания ото всех и на каждом этапе.
 
Андреа С. Вайн, специалист по интернационализации компании Sun Microsystems. Также является автором электронного дневника, размещённого на странице http://blogs.sun.com/i18ngal.





Запрос на дополнительную информацию
Расценки на работы
Новости
Все новости