International Project Engineering изнутри : International Project Engineering

EP, T/A, UVI, COSO, FX ???

Aram — Thu, 22 Mar 2007 19:06:00 GMT

Я уже писал про важность стабилизации терминологии продукта до того, как начнется локализация. К сожалению, это не всегда случается в том объеме, котором бы хотелось :-(
Начали локализацию на немецкий язык, и сразу же всплыли вот эти загадочные аббревиатуры: EP, T/A, UVI, COSO и FX. Как обычно, строки, в которых они использованы, не дают достаточно четкого контекста.
Вот, что "удалось найти":

"COSO/IAS compliance metrics" - показатели соответствия требованиям COSO и IAS.
COSO - это The Committee of Sponsoring Organization, организация, которая определят процессы внутреннего контроля организации для оценки эффективности и результативности, достоверности финансовой отчетности и соответствия требованиям законов и регламентирующих актов.
IAS - это International Accounting Standards, стандарты составления финансовой отчётности для международных операций.
"FX Exposure" - показатель рисков организации, связанных с проведением расчетов в иностранной валюте.
"T/A Discount" - скидка туристического агента.

А вот эти, пока нет:

"EP food sales"
"EP beverage sales"
"UVI Video Sales"

Весь день уйдет на постижение основ гостиничного бизнеса :-)

"Здравствуйте, мне нужна Сиобхан"

Aram — Wed, 24 Jan 2007 19:52:00 GMT

Моя работа в Майкрософт началась с двух минут позора…

В свой первый день я пришел в офис, в И-Пи-Ди-Си Ван (EPDC1), чтобы встретиться со специалистом по найму из отдела кадров, которая должна была дать мне вводную по работе в компании и представить меня моему менеджеру. Все, что я знал о ней, это её имя – Siobhan.

Как и полагается, я подошел на ресепшн и, после долгих раздумий о том, как же произносится её имя по-английски, попросил позвать Сиобхан. Как человек новый я и не мог даже представить, как назвать её по-другому. В общем, я, конечно же, ошибся. Девушка на ресепшн долго задавала наводящие вопросы, а когда поняла, кого мне надо, долго и весело смеялась, а я покрылся холодным потом – говорил я по-английски не особо, или точнее, почти совсем не говорил, а тут нате тебе, что-то не так.

Оказалось, что все очень просто: Siobhan – это ирландский способ написания имени Шивон.

Это был мой первый урок работы в многонациональном коллективе, потом еще были Шоны (Sean), Шемусы (Seamus), ПиАры (PR), АрДжеи (RJ), ПиДжеи (PJ), и люди без имени (S.)…

А как это будет по-английски?

Aram — Thu, 14 Dec 2006 20:14:00 GMT

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

В обоих случаях может пригодиться база переводов стандартных терминов, которую Майкрософт предоставляет бесплатно всем желающим. Эта база имеет около 9000 терминов с переводом на 45 языков.

Ссылка на страничку с дополнительной информацией: http://www.microsoft.com/globaldev/tools/MILSGlossary.mspx

Спасибо Алексею за вопрос по этой теме.

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

Aram — Tue, 05 Dec 2006 03:02:00 GMT

Очередной раз в моей команде проводим эксперимент – используем систему машинного перевода для предварительного перевода пользовательского интерфейса на немецкий и японский языки.

В основе системы лежит разработка Microsoft Research, которая строит переводы на основе документации и других источников из наших продуктов. Насколько мне известно, мы первая команда, которая использует машинный перевод для перевода интерфейса приложений. Основная сложность состоит в том, что, в отличие от длинных предложений в документации, текст элементов интерфейса очень короткий и "обрывистый" – редко когда имеющий смысл в отрыве от контекста. Система машинного перевода уже несколько лет вполне успешно работает на сайте базы знаний, где любую техническую статью можно перевести на французский, немецкий, итальянский, японский, китайский или испанский языки. Это позволяет получить необходимую информацию на родном языке, даже если исходная статья еще не была переведена.

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

За несколько минут перевели все приложение. И результаты, надо заметить, не такие уж плохие, конечно же, "нечеловеческий" текст получился, но вполне читабельный. Похоже, что система работает вполне прилично, и мы будем ее использовать и для других языков. К сожалению, для русского языка результаты пока не ахти какие, но в планах для следующей версии нашего продукта русского языка пока нет, может, в следующей версии удастся поработать с машинным переводом для русского языка.

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

Aram — Tue, 05 Dec 2006 02:07:00 GMT

A Microsoft Support Callback: http://soapbox.msn.com/video.aspx?vid=385cfae8-fe7f-4cdc-b61a-1f8e322b526a

без комментариев :-)

Выработка терминологии программного продукта

Aram — Thu, 16 Nov 2006 22:11:00 GMT

На самых ранних этапах разработки наших приложений команда локализации совместно с техническими редакторами извлекают ключевую терминологию, специфическую для продукта. Делается это, в основном, посредством детального изучения спецификаций. Список терминов проходит рецензию и утверждение техническими менеджерами (Program Manager) и передается в группу, отвечающую за поддержание терминологии.

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

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

Еще одна сложность и, зачастую, самая главная – субъективность оценки качества и применимости термина.

Например, для термина "key performance indicators (KPI)" существует множество переводов, в том числе и в нашей терминологической базе. Вот некоторые из них:
• Ключевые индикаторы эффективности
• Ключевые показатели результативности
• Ключевые показатели производительности
• Ключевые показатели исполнения, количественные производственные показатели
• Ключевые индикаторы производительности

Я не согласен ни с одним из вариантов, поскольку они сужают понятие к одному или нескольким аспектам деятельности организации. И ни в коем случае, не являются индикаторами, а, скорее, показателями, которые могут иметь ассоциированные с ними индикаторы.

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

Спасибо HuMan за комментарий по этой теме.

Бета тестирование Microsoft Office PerformancePoint Server 2007

Aram — Fri, 10 Nov 2006 00:46:00 GMT

Открылась программа по бета тестированию продукта, над которым я работаю - Microsoft Office PerformancePoint Server 2007.

Для участия в этой программе необходимо зарегистрироваться по этой ссылке:

http://connect.microsoft.com/site/sitehome.aspx?SiteID=181

Документация, а какой она должна быть?

Aram — Wed, 06 Sep 2006 23:55:00 GMT

В сентябре 1987 года Майкрософт выпустил Microsoft Bookshelf – коллекцию популярных книг и справочников на компакт-диске. Это был один из первых продуктов, который был выпущен на компакт-диске.

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

Одновременно с локализацией программ вся эта масса знаний переводится на другие языки. Зачастую, командам локализации вовсе не очевидно нужно ли это делать. Но мы делаем; переводим, переводим, переводим…

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

Неужели наше программное обеспечение сложнее чем здоровье и воспитание ребенка?!?

Или просто оно такое неочевидное в использовании, что мы сопровождаем его тысячами страниц инструкций по использованию?

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

Форум по "русификации" Exchange 2007

Aram — Thu, 24 Aug 2006 00:01:00 GMT

Открылся форум по обсуждению технической терминологии, используемой в русской версии Exchange 2007. Это отличная возможность для русскоговорящего сообщества высказать свои рекомендации по переводу терминов, а для компании – выпустить продукт, который "говорит" на одном с нами языке.

Ссылка на домашнюю страницу форума: http://members.microsoft.com/wincg/mtcf_home.aspx?langid=1330

Проверено на людях или "брюки превращаются, превращаются…"

Aram — Tue, 08 Aug 2006 02:49:00 GMT

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

Я давно так не смеялся и плакал одновременно…

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

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

Несмотря на то, что исследование проводится на английской версии, и для локализации нашлось пара интересных терминов, над которыми надо поработать:

Действие Insert (Вставка), которое, в действительности, служит для создания новых объектов на рабочей области. Нам это казалось тривиальным, а вот пользователь заметил, что если он хочет создать новый объект, то он его создает, а не вставляет. Вставкой он пользуется для добавления на рабочую область уже существующих объектов с сервера или другого источника. Судя по всему, надо менять Insert на Create, т.к. при переводе на другие языки может стать совсем непонятно.
Кнопки Publish All (Опубликовать все) и Refresh (Обновить), которые служат для записи и обновления данных между рабочей областью и сервером. Любое изменение данных в рабочей области требует записи на сервер (Publish All) с последующим ее обновлением с сервера (Refresh). Здесь тоже надо менять названия действий, и, возможно, объединить их функциональность для ряда сценариев.

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

Встречи с дипломированной медсестрой или разбор жуков

Aram — Sat, 05 Aug 2006 01:11:00 GMT

Уже несколько месяцев подряд я два раза в неделю встречаюсь со своими коллегами на так называемых "triage meetings", но только сегодня задумался о происхождении этого названия.

В американской системе здравоохранения большинство поступающих в больницу пациентов попадают к дипломированной медсестре (registered nurse), которая определят критичность состояния больного (severity) и определяет очередность (priority) предоставления медицинской помощи. Весь этот процесс определения очередности предоставления медицинской помощи называется triage.

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

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

На этих встречах можно услышать такие "стандартные" фразы:

· Open a bug – открыть баг – внести информацию о дефекте в базу данных.

· Resolve a bug – зарезолвить баг – пометить дефект как исправленный или как неподлежащий исправлению.

· Close a bug – закрыть баг – протестировать исправление и пометить дефект как действительно исправленный.

· Triage a bug – оттриажить баг – принять решение о необходимости исправления дефекта, определить его приоритет и назначить ответственного за исправление.

Интересно было бы узнать как подобный процесс называется в российских компаниях и как разработчики программного обеспечения называют все его элементы?

Иными словами, "как это будет по-русски"?

Обязан, должен, может...

Aram — Tue, 18 Jul 2006 02:29:00 GMT

При написании технического задания и спецификаций, наряду с числовым представлением приоритета той или иной функциональности, часто указывается словесное описание ее поведения. Для исключения недопонимания или неверного представления указанного в спецификации поведения удобно использовать стандартные фразы. Здесь на помощь приходят рекомендации документа RFC 2119, который четко и однозначно описывает такие стандартные фразы как MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY и OPTIONAL.

Рецензирование спецификации продукта с учетом требований интернационализации

Aram — Tue, 18 Jul 2006 02:04:00 GMT

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

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

Эти наиболее тривиальные вопросы, на которые стоит обратить внимание в процессе рецензирования спецификаций:

Дизайн должен предоставлять возможность для локализации продукта в стандартных специализированных приложениях. Чем больше исключений из этого правила – тем дороже обойдется локализация.
Слишком сложный и загроможденный пользовательский интерфейс может привести к множеству ошибок, связанных с увеличением длины переводов текстовых ресурсов. Особое внимание стоит уделить кнопкам, тестовым подписям, флажкам и переключателям.
По-возможности, желательно избегать динамических строковых ресурсов, которые "собираются" из нескольких ресурсов, т.к. перевод таких ресурсов на некоторые языки окажется просто невозможным.
Позволяет ли рассматриваемая функциональность вносить полные имена людей, состоящие из множества элементов, поддерживаются ли стандартные правила сортировки, форматы представления почтовых адресов, дат и времени, числовых значений и валюты, размер используемой бумаги?
Если приводится ссылка на веб-сайт, существует ли локализованная страница?
Если планируется перевести приложение на один из языков, используемых в нескольких странах, например, испанский, то учитываются ли региональные стандарты каждой из них?
Помимо технических требований большую роль играют культурные особенности. Необходимо очень внимательно относиться как к тексту строковых ресурсов, так и к изображениям на графических файлах.

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

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

Сапер по-итальянски

Aram — Fri, 14 Jul 2006 23:56:00 GMT

Интересный пример изменения основной функциональности приложения для локального, в этом случае итальянского, рынка (market customization). Сапер в итальянской версии Windows XP называется "цветущий луг". В нем мины заменены на цветы, которые не надо собирать.

Основные термины, встречающиеся в описании процесса разработки приложений для международных рынков

Aram — Fri, 14 Jul 2006 23:03:00 GMT

Разработка приложений для международных рынков базируется на следующих ключевых принципах:

"Готовность к использованию во всем мире" (world-ready) – приложение, которое разработано с учетом требований глобализации и пригодно для локализации, называется готовым к использованию во всем мире.

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

"Готовность к локализации" (localizability) – приложение, которое может быть переведено на другие языки без внесения изменений в исходный код, называется готовым к локализации.

Локализация (localization) – это процесс адаптации программного продукта под требования локального рынка, которое включает в себя перевод пользовательского интерфейса, справочной системы, документации и изменения или дополнения основной функциональности под нужды этого рынка. Процесс внесения этих изменений и дополнений часто называется market customization.