Расширяемый xml-формат и объектная модель для данных локализации

Расширяемый xml-формат и объектная модель для данных локализации

Иллюстрации

Показать все

Реферат

Уровень техники

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

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

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

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

Сущность изобретения

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

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

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

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

Описание чертежей

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

Фиг.1 - это графическая схема примерного процесса локализации;

Фиг.2 - это графическая схема, иллюстрирующая примерный поток данных локализации;

Фиг.3 - это графическая схема, иллюстрирующая еще один примерный поток данных локализации;

Фиг.4 - это графическая схема, иллюстрирующая примерные операции разделения и слияния файлов для файла XML-данных;

Фиг.5A - это графическая схема примерного контейнера свойств;

Фиг.5B - это графическая схема примерного булева XML-элемента;

Фиг.5C - это графическая схема примерного целочисленного XML-элемента;

Фиг.5D - это графическая схема примерного строкового XML-элемента;

Фиг.5E - это графическая схема примерного XML-строкового XML-элемента;

Фиг.6 - это графическая схема примерного формата данных комментариев с атрибутом источника;

Фиг.7 - это блок-схема примерного формата данных элемента локализации с комментариями;

Фиг.8 - это графическая схема примерного формата данных собственных комментариев;

Фиг.9A - это графическая схема примерного формата данных настроек;

Фиг.9B - это графическая схема примерного элемента перечисления;

Фиг.9C - это графическая схема примерного элемента списка;

Фиг.9D - это графическая схема примерного элемента списка выбора;

Фиг.10 - это графическая схема примерного формата XML-данных локализации;

Фиг.11A - это примерная графическая схема текстовых данных, содержащихся в XML-элементе CDATA;

Фиг.11B - это примерная графическая схема текстовых данных, включающих в себя символ скобок, содержащийся в XML-элементе CDATA;

Фиг.12 - это блок-схема примерных взаимосвязей схемы локализации и соответствующей объектной модели;

Фиг.13A - это блок-схема примерных родительских и дочерних объектов с обратным указателем;

Фиг.13B - это блок-схема примерных родительских и дочерних объектов с обратным указателем и указателем файла;

Фиг.14 - это графическая схема примерной объектной модели с внешней информацией традиционной культуры;

Фиг.15 - это функциональная блок-схема последовательности операций примерного способа частичной загрузки данных;

Фиг.16 - это функциональная блок-схема последовательности операций примерного способа модульной загрузки данных с функцией обратного вызова;

Фиг.17A - это функциональная блок-схема последовательности операций примерного способа частичного сохранения данных;

Фиг.17B - это функциональная блок-схема последовательности операций примерного способа слияния при сохранении данных;

Фиг.18 - это функциональная блок-схема последовательности операций примерного способа модульного сохранения данных;

Фиг.19 - это графическая схема примерной объектной модели локализации;

Фиг.20 - это функциональная блок-схема последовательности операций примерного способа создания и предоставления файла данных локализации;

Фиг.21 - это функциональная блок-схема последовательности операций примерного способа добавления комментариев в элемент локализации; и

Фиг.22 - это функциональная блок-схема последовательности операций примерного способа удаления файлов.

Подробное описание изобретения

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

Фиг.1 - это графическая схема примерного процесса 100 локализации. Примерный процесс локализации содержит рабочий цикл, включающий в себя несколько отдельных стадий. Стадии включают в себя стадию 102 разработки, стадию 104 локализации, стадию 106 перевода и стадию 108 сборки. Специалисты в данной области техники должны признавать, что стадии рабочего цикла могут включать в себя большее или меньшее число стадий, чем описано в этом примерном варианте осуществления. Например, некоторые из стадий могут быть объединены так, чтобы создать меньшее число стадий, или дополнительно разбиты так, чтобы создать большее число стадий. На стадии 102 разработки специалисты по разработке прикладной программы ("программного приложения") разрабатывают программный код и пользовательский интерфейс (UI). UI может включать в себя текстовые, визуальные и звуковые компоненты. Например, специалисты по разработке пишут и компилируют код для программного приложения. Код может быть написан на любом из нескольких доступных языков программирования, таких как C, C++, C# и т.п., и включать в себя файлы исходного кода, файлы заголовков и файлы ресурсов. Файлы ресурсов, в общем, содержат визуальные и другие UI-элементы, такие как битовые карты. Специалисты по разработке также могут включать комментарии в некоторые из этих файлов, например в файлы ресурсов. Комментарии включают в себя примечания к коду или UI-элементам, а также команды к программным средствам, таким как различные программные компиляторы, средства администрирования и средства сборки, используемые в ходе разработки локализованных программных приложений. Специалисты по разработке передают наборы (коллекции) файлов, включающие в себя компилированный код и файлы ресурсов, на стадию 104 локализации, на которой специалисты по локализации продолжают процесс локализации. Специалисты по локализации добавляют дополнительные комментарии в файлы, которые применимы ко всем целевым языкам и культурам. Далее файлы передаются на стадию 106 перевода, где выполняется перевод файлов прикладных программ для каждого конкретного языка. В завершение, файлы передаются на стадию 108 сборки, где файлы компонуются так, чтобы сформировать исполняемые файлы прикладной программы для каждого из нескольких языков.

Фиг.2 - это графическая схема, иллюстрирующая примерный поток 200 данных локализации из стадии 102 разработки в стадию 104 локализации. Средство 210 грамматического разбора локализации используется для того, чтобы объединить несколько файлов, включающих в себя исходные двоичные файлы 204, файлы 206 комментариев и файлы 208 настроек (параметров), и сформировать выходной файл 212 данных локализации. Исходные двоичные файлы 204 поступают от специалистов по разработке и лаборатории 202 сборки программы. Файл 212 локализации - это файл, который передается специалистам 214 по локализации на стадии 104 локализации. В одном примерном варианте осуществления файл 212 данных локализации содержит настройки из файлов 208 настроек, комментарии из файлов 206 комментариев и исходные двоичные данные из исходных двоичных файлов 204. Исходные двоичные файлы 204, предоставляемые от лаборатории 202 построения программы, включают в себя двоичные данные, получающиеся в результате построения (сборки) исходных файлов прикладной программы на первоначальном языке, например на английском.

Комментарии, встроенные в файлы 206 комментариев, исходные двоичные файлы 204 и файлы 208 настроек снабжаются тегами, чтобы указать владельца и источник комментариев. Например, комментарии, исходящие от специалистов по разработке, могут быть снабжены тегом "DEV", чтобы указать источник комментариев, указываемый посредством этого тега. Различные программные средства, используемые в процессе локализации, такие как средство извлечения комментариев, позволяют добавлять комментарии также в файлы прикладных программ. Например, средство извлечения комментариев может снабжать тегами комментарии, принадлежащие средству извлечения комментариев, как "RCCX". Средство извлечения комментариев может не формировать выходной файл, если нет комментариев во входном файле, с которым работает средство извлечения комментариев. Комментарии являются чувствительными к регистру, т.е. буквы верхнего регистра и нижнего регистра задают различные слова, или комментарии не являются чувствительными к регистру. Комментарии также могут быть включены или отключены. Например, средство администрирования локализации может снабжать комментарии тегом "LCI" и может быть использовано для того, чтобы отключить другие комментарии DEV и RCCX. Средство сборки (построения) прикладной программы владеет одним или более из конкретных типов комментариев, идентифицированных посредством конкретного тега, такого как DEV и RCCX, причем эти типы обрабатывает средство сборки. В одном примерном варианте осуществления режим работы средств, например, средства сборки программ, управляется посредством параметров, заданных в конфигурационном файле.

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

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

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

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

Фиг.3 - это графическая схема, иллюстрирующая другой примерный поток 104 данных локализации из стадии 104 локализации и стадии 106 перевода до стадии 108 сборки. В этом примере средство 312 сборки локализации обрабатывает данные, содержащиеся в исходном двоичном файле 204, файле 212 данных локализации и файле 310 локализованного языка, чтобы формировать выходной целевой двоичный файл 314. Как описано выше относительно Фиг.2, файл 212 данных локализации включает в себя настройки, комментарии и исходные данные, объединенные из данных в других файлах. Файл 310 локализованного языка включает в себя настройки, комментарии, исходные данные и данные перевода, добавленные специалистами 214 по локализации. Средство 312 сборки локализации использует исходные двоичные файлы 204, файл 212 данных локализации и файл 310 локализованного языка в качестве входных файлов и формирует целевой двоичный файл 314 на целевом языке. Создание целевого двоичного файла 314 - это конечный локализованный прикладной программный продукт, и он является основной целью процесса локализации.

Средства и процессы, описанные выше, зависят от общего и согласованного формата данных, на основе которого средства могут объединять и обрабатывать данные стандартизированным способом. В одном примерном варианте осуществления схема расширяемого языка разметки (XML) локализации используется для задания согласованных форматов данных для использования посредством различных средств локализации и связанных файлов, описанных выше. XML-схема локализации предоставляет расширяемый XML-формат, который дает возможность различным группам и организациям разрабатывать программные средства для того, чтобы обрабатывать конкретные задачи. XML-схема локализации также предоставляет возможность разработки средств и данных, которые могут быть совместно использованы несколькими организациями, тем самым обеспечивая сотрудничество между группами. Например, средство 210 синтаксического разбора локализации, средство 312 сборки локализации и средство администрирования локализации могут применять и совместно использовать одинаковые форматы данных для различных данных в процессе локализации. В одном примерном варианте осуществления XML-схема локализации также может быть расширяемой. Расширяемость XML-схемы локализации позволяет другим сторонам разрабатывать новые средства с новыми признаками без изменения формата данных.

Фиг.4 - это графическая схема, иллюстрирующая примерные операции 400 и 402 разделения и слияния файлов (отличные от операции слияния комментариев), соответственно, для файла 404 XML-данных локализации на основе расширяемой XML-схемы локализации. В этом примерном варианте осуществления файл 404 XML-данных локализации разделяется на множество частичных файлов 406 данных с помощью операции 400 разделения файлов. Частичные файлы 406 данных могут быть использованы параллельно несколькими организациями или посредством программного средства параллельной обработки, обрабатывающего каждый частичный файл 406 данных независимо от других частичных файлов 406 данных. Например, каждая одна из множества третьих сторон, разрабатывающих файлы данных для нескольких программных средств, соответственно, может использовать один частичный файл данных, который относится к программному средству, разрабатываемому каждой одной из множества третьих сторон. В качестве другого примера, несколько организаций, переводящих одно программное приложение на несколько языков, могут использовать соответствующий частичный файл 406 данных, созданный посредством операции 400 разделения, для того чтобы создать переведенную версию ресурсов прикладной программы. Когда множество организаций завершают обработку частичных файлов 406 данных, частичные файлы 406 данных сливаются в один файл 408 XML-данных локализации с помощью операции 402 слияния файлов.

Файл 404 XML-данных локализации включает в себя XML-элементы, которые задают информацию локализации. Один из элементов, включенных в файл 404 XML-данных локализации, - это контейнер свойств. Фиг.5A-5E иллюстрируют примерные варианты осуществления контейнера свойств и соответствующих XML-элементов. Фиг.5A - это графическая схема примерной структуры 500 данных контейнера свойств. Контейнер 502 свойств - это контейнер данных для хранения любого числа свойств. В одном примерном варианте осуществления каждый комплексный тип данных ассоциативно связан, по меньшей мере, с одним комплектом свойств. Комплексный тип данных - это тип данных, который содержит другие типы данных. Например, XML-элемент, который содержит другие XML-элементы, является комплексным (сложным) типом данных. В одном примерном варианте осуществления уникальное имя, заданное с помощью атрибута Name (Имя), и значение присваиваются свойству. Значение должно иметь тип данных, поддерживаемый XML-схемой локализации. Каждый комплексный тип данных, заданный в XML-схеме локализации, включает в себя элемент контейнера свойств, чтобы сохранять любой объем данных, требуемых пользователем XML-схемы локализации. Примерный контейнер 502 свойств, проиллюстрированный на Фиг.5A, включает в себя булев тип 504 данных, целочисленный тип 506 данных, строковый тип 508 данных и XML-тип 510 данных.

Фиг.5B - это графическая схема примерного булева XML-элемента 522. Булев XML-элемент 522 включает в себя список 524 атрибутов. Атрибуты типа данных в XML используются для того, чтобы представлять информацию о типе данных, такую как имя и значение типа данных. Один из атрибутов, включенных в список 524 атрибутов, - это Name 526. В одном варианте осуществления атрибут 526 Name - это буквенно-цифровая строка. Value (Значение) 528 - это другой атрибут булева XML-элемента 522. Value 528 представляет логическое значение булева XML-элемента 522. Логические значения включают в себя два значения логических состояний TRUE (ИСТИНА) и FALSE (ЛОЖЬ), как известно в данной области техники.

Фиг.5C - это графическая схема примерного целочисленного XML-элемента 542. Целочисленный XML-элемент 542 включает в себя список 544 атрибутов. Один из атрибутов, включенных в список 544 атрибутов, - это Name 546. В одном варианте осуществления атрибут 546 Name - это буквенно-цифровая строка. Value 548 - это другой атрибут целочисленного XML-элемента 542. Value 548 представляет целочисленное значение целочисленного XML-элемента 542.

Фиг.5D - это графическая схема примерного строкового XML-элемента 562. Строковый XML-элемент 562 включает в себя список 564 атрибутов. Один из атрибутов, включенных в список 564 атрибутов, - это Name 566. В одном варианте осуществления атрибут 566 Name - это буквенно-цифровая строка. Value 568 - это другой атрибут строкового XML-элемента 562. Value 568 включает в себя строку символов, включающую в себя буквенно-цифровые, а также другие символы, представляемые посредством строкового XML-элемента 562.

Фиг.5E - это графическая схема примерного XML-строкового XML-элемента 582. XML-строковый XML-элемент 582 представляет любое допустимое XML-предложение. XML-элемент 582 включает в себя список 584 атрибутов. Список 584 атрибутов включает в себя атрибут 586 Name. В одном примерном варианте осуществления атрибут 586 Name - это буквенно-цифровая строка. Список 584 атрибутов также включает в себя атрибут 588 Any XML Statement (Любое XML-предложение), содержащий любое допустимое XML-предложение.

Специалисты в данной области техники должны признавать, что возможны другие варианты элемента 502 контейнера свойств. Например, элемент 502 контейнера свойств может включать в себя тип элемента данных, такого как элемент Any (Любой) (не показан на вышеописанных чертежах), при этом элемент Any включает в себя атрибут имени, атрибут типа и атрибут значения. В этом примерном варианте осуществления атрибут типа задает то, как должен быть интерпретирован атрибут значения. Например, тип может равняться Unsigned_integer, а значение может равняться 15.

Фиг.6 - это графическая схема примерного формата 600 данных комментариев с атрибутом источника. В одном примерном варианте осуществления элемент 602 комментариев включает в себя текст естественного языка, предоставляющий информацию о процессе локализации для людей-операторов, а также заранее заданные текстовые строки, предоставляемые в качестве команд людям-операторам и программным средствам, которые обрабатывают файлы 206 комментариев и файлы 408 XML-данных локализации. Элемент 602 комментариев, проиллюстрированный на Фиг.6, включает в себя список 604 атрибутов. В одном примерном варианте осуществления список 604 атрибутов содержит атрибут 606 Name, атрибут 608 Enabled (Включено) и атрибут 610 SRC (для "источника"). Атрибут 606 Name используется для того, чтобы ссылаться на комментарий по имени. Атрибут 608 Enabled выступает в качестве индикатора, чтобы указывать то, включен или отключен комментарий 602. Атрибут 610 SRC указывает источник комментария, т.е. атрибут 610 SRC - это тег для идентификации владельца и источника комментария. Как описано выше со ссылкой на Фиг.2, различные типы комментариев принадлежат различным владельцам. Владелец комментария может включать команды и другую информацию о процессе локализации, которая относится к зоне ответственности владельца комментария. Например, разработчик программного обеспечения может предоставлять общую информацию и команды в форме комментариев. Комментарии, сделанные посредством конкретного владельца, снабжаются тегами, чтобы идентифицировать владельца комментария. В одном примерном варианте осуществления комментарии, сделанные каждым владельцем, могут обрабатываться только владельцем, которому принадлежат комментарии. В другом примерном варианте осуществления владение комментарием может быть перенесено от одного владельца к другому. Например, комментарию, помеченному DEV (т.е. разработчик, как описано выше), может быть разрешено принадлежать средству извлечения комментариев, которое обычно владеет только комментариями, тегированными как RCCX. В примерном варианте осуществления имена комментариев и комментарии могут быть чувствительны к регистру. Комментарии также могут быть включены или отключены. Как описано выше, отключенный комментарий игнорируется в ходе обработки.

Фиг.7 - это блок-схема примерного формата 700 данных элемента локализации с комментариями. В одном примерном варианте осуществления элемент 702 локализации включает в себя атрибуты 704. Атрибуты 704 содержат itemType (Тип элемента) 706 и itemID (Идентификатор элемента) 708. Элемент 702 локализации дополнительно включает в себя строковый элемент 710, двоичный элемент 712 и комментарии 714. Элемент 702 локализации - это любая часть или ресурс в локализуемой программе, который может быть переведен или иным образом адаптирован к местной культуре и языку. Например, текстовое сообщение или значок - это элемент 702 локализации. ItemType 706 - это атрибут, который обозначает тип элемента 702 локализации. Например, itemType 706 может указывать то, что конкретный элемент 702 локализации - это текстовое сообщение или цвет. ItemID 708 используется в качестве идентификатора элемента 702 локализации. Элемент 702 локализации необязательно может включать в себя строку 710, двоичные данные 712 и комментарии 714, в зависимости от itemType 706. Например, если itemType 706 указывает то, что элемент 702 локализации - это текстовая строка, элемент 702 локализации может включать в себя другой элемент, такой как элемент свойства (не показан на чертеже), задающий шрифт по умолчанию, который должен быть использован при локализации. В одном примерном варианте осуществления несколько типов строк 710 и двоичных данных 712 включены в элемент 702 локализации. Например, строки и двоичные данные для исходного языка, целевого языка и других эталонных языков могут быть включены в элемент 702 локализации. Эталонный язык может быть использован для того, чтобы предоставлять дополнительную информацию для перевода элемента 702 локализации с исходного языка на целевой язык. В одном примерном варианте осуществления родительский элемент 702 локализации включает в себя нуль или более других дочерних элементов 702 локализации (не показаны), совместно составляющих иерархическую структуру элементов 702 локализации. Дочерние элементы 702 локализации включают в родительский элемент 702 локализации посредством указателей или эквивалентных программных методик.

Фиг.8 - это графическая схема примерного формата 806 данных собственных комментариев. Проиллюстрированный примерный элемент 802 собственных комментариев включает в себя множество элементов 602 комментариев, каждый из которых содержит атрибут 804. Атрибут 804 включает в себя атрибут 806 имени.

Фиг.9A-9D иллюстрируют примерные варианты осуществления элемента 902 настроек и соответствующих XML-элементов. Фиг.9A - это графическая схема примерного формата данных настроек. Элемент 902 настроек включает в себя атрибут 904, содержащий имя 906. Элемент 902 настроек дополнительно содержит множество элементов настроек 908. Примерная настройка 1 содержит атрибут 910. Атрибут 910 включает в себя имя 912 настройки 1. Примерная настройка 1 дополнительно включает в себя булев элемент 914, целочисленный элемент 916, элемент 918 перечисления, строковый элемент 920, элемент 922 списка и элемент 924 списка выбора. Каждый из элементов настройки 908 дополнительно поясняется ниже. Элемент 902 настроек указывает текущие настройки файла данных локализации.

Фиг.9B - это графическая схема примерного элемента 942 перечислений. Примерный элемент 942 перечислений включает в себя атрибут 944, содержащий имя 946 и значение 948. Атрибут 946 имени идентифицирует элемент 942 перечисления по имени. Атрибут 948 значения включает в себя значение перечисления, представленное посредством перечисления 942.

Фиг.9C - это графическая схема примерного элемента 962 списка. Примерный элемент 962 списка включает в себя атрибут 964, содержащий имя 966 и множество элементов 968 позиции. Атрибут 966 имени идентифицирует элемент 962 списка по имени. Каждый из элементов 968 позиции представляет одну запись списка 962 и может включать в себя множество атрибутов (не показаны на этом чертеже), такие как идентификатор позиции, порядковый номер, имя исходного файла и т.п. Дополнительно, позиция 968 может включать в себя другие элементы (не показанные на этом чертеже), такие как строковый элемент, двоичный элемент, элемент комментариев и т.п.

Фиг.9D - это графическая схема примерного элемента 982 списка выбора. Примерный элемент 982 списка выбора включает в себя атрибут 984, содержащий имя 986 и атрибут 988 значения. Примерный элемент 982 списка выбора дополнительно включает в себя множество элементов 990 позиции. Атрибут 986 имени идентифицирует элемент 982 списка выбора по имени. Каждый из элементов 990 позиции представляет одну запись списка 982 выбора и может включать в себя множество атрибутов (не показаны на этом чертеже), такие как идентификатор позиции, порядковый номер, имя исходного файла и т.п. Дополнительно, позиция 990 может включать в себя другие элементы (не показанные на этом чер