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 — Thu, 14 Dec 2006 20:14:00 GMT

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 — Fri, 14 Jul 2006 23:03:00 GMT

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

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

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

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

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