JP2005135377A - ランタイムおよび設計でのテキスト変換と多言語サポートをするラベルシステム - Google Patents

Abstract

【課題】 効率的な処理を可能とするラベルシステムを提供する。
【解決手段】 言語につき単一のリソースファイルがあるのではなく、ラベルに関係する情報はデータベースに記憶される。各ラベルには、それ自体の一意識別子がラベルＩＤ構造中で割り当てられ、ラベルＩＤ構造はまた、ラベルがどのようにシステム中で使用されるかに関係する情報も含む。ラベルについてのテキストは、別個のラベルテキスト構造に記憶される。ラベルテキスト構造は、すべての利用可能言語によるラベルのテキストを含む。新しいラベルを記述するとき、開発者は、意図する使用法にマッチするラベルを見つけるために、現在のラベルを検索することができる５０５。所望のテキストに対するマッチが見つかった場合は、そのラベルを新しいラベルに複製する５０９。マッチが見つからなかった場合は、新しいラベルを生成しなければならない５２１。
【選択図】 図５

Description

本発明は、ビジネスソリューションソフトウェアプログラムにおいてラベルをマージおよび開発することに関する。より詳細には、本発明は、ビジネスソリューションソフトウェアのためのモジュール中のラベルを開発およびマージする際に使用されるラベルデータベースおよびラベルダイアログに関する。

ビジネスソリューションソフトウェアプログラムは、典型的には企業であるエンドユーザに、ユーザの様々なビジネスパートナーとの接続性をサポートするカスタマイズ可能かつスケーラブルかつグローバルなエンタープライズリソースプランニングソリューションを提供するものである。多くのビジネスソリューションソフトウェアプログラムは、それを実行する企業のニーズをさらに満たすために、ソフトウェアの基本機能を元々の製品からさらに拡張する能力を提供する。この新しいまたは追加の機能は、ビジネスソリューションソフトウェアに含まれる既存の機能および既存のデータを利用するように書かれた追加のモジュールを介して提供される。これらの追加モジュールはしばしば、ビジネスソリューションソフトウェアおよび既存のデータを、ソフトウェアの古い機能と新しい機能の両方と自動的に同期させる。

いくつかのビジネスソリューションソフトウェアは、様々な国で複数の言語にまたがって複数の通貨でビジネスを実施する能力を提供する。ビジネスソリューションソフトウェアで提供される多言語能力を用いることにより、送り状などの文書を、受取り側に好まれる言語で送ることが可能である。しかし、現在のシステムで文書の言語を変更するには、新しい言語をビジネスソリューションソフトウェアにロードして、システムの動作言語全体を変更する必要がある。

ビジネスソリューションソフトウェアの様々な利用可能言語による通信は、複数のラベルを使用することによって対処される。ラベルは、ユーザインタフェースコンポーネント上に、または印刷された文書に現れるテキストである。ラベルは、メニュー、ボタン、ダイアログボックスなどの上で使用することができる。さらに、ラベルは、「ラベル」「ヘルプ」「キャプション」「ツールチップ」などのラベルプロパティを有するコントロール上で使用することもできる。現在のビジネスソリューションソフトウェアにおけるラベルは、別々のリソースファイルに記憶されており、ビジネスソリューションソフトウェアによって使用される各言語につき、１つのリソースファイルが専用になっている。さらに、ビジネスソリューションソフトウェアにおける各モジュールは、他のモジュールともビジネスソリューションソフトウェア自体とも共有されないそれ自体のリソースファイルを有する。

ビジネスソリューションソフトウェアの開発全体を通して、開発者の間には、既存のラベルを再利用したいという強い欲求があった。しかし、既存のラベルの再利用は、好都合ではないと言われてきた。というのは、ラベルの語句に関連する様々なプロパティは異なるユーザ間で変化する可能性があるからであり、あるいは、ラベルの意味は異なる開発者間でばらつきがある可能性があるからである。このことは、語句が変更されたときに問題を生じる恐れがある。例えば、あるラベルテキストは、あるアプリケーション上ではメニュー中で使用することができ、別のアプリケーション上ではボタン中で使用することができ、そのため各ラベルごとにプロパティが違ってくる。ほとんどの開発者が望んできたのは、ラベルを構成する語句またはテキストを再利用して、システム上の様々なモジュール用にラベルを開発することに関連するコストを削減することであった。

前述のように、ビジネスソリューションソフトウェアモジュールでは通常、ラベルはリソースファイルに保持される。しかし、現在のビジネスソリューションソフトウェアは、ＳＱＬ（Structured Query Language）テーブルなどのデータベースメタデータストアを介して利用可能な、またはウェブサービスを介して利用可能な包括的なリソースファイルを使用しない。通常、ビジネスソリューションソフトウェアでは、これらのラベルはモジュール特有であり、独自仕様のリソースファイルに記憶され、モジュール中に存在する各言語につき、１つのリソースファイルが専用になっている。独自仕様のリソースファイルを使用することに関する問題の１つは、開発者が、あるモジュール中のラベルの一部を、別のリソースファイルに含まれる新しい情報またはプロパティで置換または編集したいと思っても、開発システムは、ビジネスソリューションソフトウェアの他のモジュール中で、所望のラベルと同じラベルプロパティおよび／または用語法を有する別のラベルを探すことをしないことである。さらに、リソースファイルを使用すると、ソフトウェアソリューション中に多数のラベルが存在するため、ラベルの管理が極度に難しくなる。しかし、ビジネスソリューション環境では、ビジネスソリューションソフトウェアは、複数のベンダによって開発された多くの様々なソリューションを扱うことが必要とされる。しばしは、これらのモジュールの開発者は、ビジネスソリューションソフトウェア中の他のモジュール用に開発されたラベルと重複するラベルを開発していることがある。ラベルの開発およびラベルの変換（多言語サポートが望まれるとき）に関連するコストは高価で時間がかかり、特に、ラベルおよびその変換がすでにビジネスソリューションソフトウェア中のどこかに存在するときはそうである。したがって、各ベンダが所望の各モジュールごとにそれ自体のラベルを開発する必要のある完全に独自仕様のシステムとは反対に、様々なモジュールベンダの寄与の結合を用いるラベルシステムを有することが望ましい。さらに、既存のラベルテキストを検索することを可能にし、テキストを再利用する能力を提供するシステムであって、ラベルが使用されるコンテキストがその元々の作成時の使用法と異なるかもしれない場合にも対処するシステムが望ましい。

従来のシステムには上述したような種々の問題があり、さらなる改善が望まれている。

本発明は、このような状況に鑑みてなされたもので、その目的とするところは、効率的な処理を可能とする、ランタイムおよび設計でのテキスト変換と多言語サポートをするラベルシステムを提供することにある。

本発明は、ビジネスソリューションシステムにおけるモジュールの開発者のニーズに対処するものである。以前のシステムとは異なり、ラベル（すなわち表示テキスト）は共通のリソースファイル中に保持され、システムの各モジュールは、各モジュール用の独自仕様のリソースファイルではなく、同じリソースファイルにアクセスする。本発明の効率をさらに高めることに、すべての言語テキストは、元の言語と同じリソースファイルまたはデータベースに記憶される。モジュールによって使用される各ラベルは、ラベルテーブル中で、ＧＵＩＤ（globally unique identifer）などの一意識別子、その使用法の説明、関連するカテゴリおよび名前空間で識別される。この情報は、開発者が、新しいラベルまたは新しいモジュールを作成するときにデータベース中の既存のラベルが有用かどうかを判定するのに役立つ。

各ラベルはまた、ラベルテキストテーブルデータベース中にエントリのセットを有し、エントリのセットは、ラベルテキストの複数言語のバージョン、ならびにラベルテキストの管理に有用なその他の情報を表す。ラベルテキストの元の言語は、マスタ言語として識別される。ユーザがビジネスソフトウェアソリューションシステムの言語を変更したいとき、モジュールの言語を変更したいとき、または文書を別の言語で印刷したいときは、新しい言語セットをシステムにロードしてシステムの好まれる言語を一時的な言語で置換する必要なしに、ラベルテキストテーブルが利用可能言語へのアクセスを可能にする。これにより、システム全体が新しい言語で機能する必要があるせいでユーザが混乱するということなく、言語を素早く変更することができる。さらに、このシステムは常に、現在のアクティブ言語を表示しようとする。ラベルに対する現在のアクティブ言語が見つからない場合は、フォールバック言語を使用することができる。

本発明の一実施形態はまた、開発者がビジネスソリューションソフトウェアのために新しいモジュールを開発している状況、または既存のモジュールを編集している状況にも対処する。本発明では、開発者は、ラベルダイアログ開発ツールを介して既存のラベルを識別することができる。まず開発者は、開発表示内でユーザインタフェースを開く。この表示は、ラベルテキストデータベースの検索とすべての利用可能ラベルへのアクセスとを可能にする検索機能を、開発者に対して表示する。次いで開発者は、所望のラベルのテキストを検索エンジンに入力する。このテキストは、通常の表現を使用して、所望のラベルの全体または一部として入力することができる。代替実施形態では、開発者は、現在のテキストラベルに関する所望の使用法、テキストラベルの言語、または、所望のラベルの使用法を識別するのに役立つその他の情報を指示することができる。

入力されたデータに基づいて、検索エンジンはラベルテキストデータベースを検索し、所望のテキストに最もよくマッチする、かつ名前空間およびカテゴリが提供されていればそれらに最もよくマッチするラベルテキストを識別する。識別されたテキストは、検索エンジン表示内で開発者に返されるが、これらはデータグリッド中に表示することができる。結果は、所定の方法に従ってランク付けされる。例えば、所望のテキストに最もよくマッチするカテゴリおよび言語を有するテキストが先に表示され、同じカテゴリを有さないテキストが後に表示されるなどの方法に従う。次いで開発者は、所望のテキストを含む返された結果の中で、結果を見つけることができる。結果のうちの１つが新しいラベルに対する所望のテキストを含む場合、開発者は結果からこの所望のラベルを選択することができる。

結果を選択すると、この特定のラベルに関する、データベースに含まれるより多くの情報が開発者に提示される。選択したラベルテキストの使用法が新しいラベルと同じである場合は、開発者は、選択したラベルを所望のターゲットラベルに使用することができる。しかし、選択したラベルの使用法が新しいラベルと同じでない場合は、開発者は、このラベルを新しいラベルに複製することができる。

選択されたラベルが新しいラベルに複製されるときは、新しいラベルのためのＧＵＩＤが生成され、新しいラベルの記録の中に、このラベルに複製されたラベルのＧＵＩＤを示すエントリが生成される。このエントリは、親ラベルのテキストが変更されたときに新しいラベルのテキストも更新されるようにするために提供される。さらに、ラベルが新しいラベルに複製されるとき、関連する変換があれば、それらも新しいラベルについてのラベルテキストテーブルにコピーされる。これにより、新しいラベルを利用可能言語に変換することに関連するどんな追加コストも被らずに、ビジネスソリューションソフトウェアシステムの完全な言語機能が、新しいラベルに引き継がれる。別の実施形態では、ラベルの変換済みバージョンが更新されると、同じマスタラベルを共有するすべての関連ラベルが、変換済みラベルの新しいバージョンで更新される。

選択されたラベルが新しいラベルに複製されるときは、ラベルのテキスト情報、ならびにマスタラベルのラベルＩＤ（identification）を除く他のすべての情報が、新しいラベルにコピーされる。ラベルに対する所望のテキストが見つからない場合は、開発者は、所望のラベルのための新しいラベルを作成しなければならない。さらに、開発者は、新しいラベルのラベルテキストについての新しい変換も生成しなければならない。言い換えれば、開発者がシステム中でラベルを見つけた場合、このラベルが複製される。しかし、開発者がラベルに関する情報を変更した場合は、ラベルはシステムにとって新しいラベルとして見えることになる。

以下、図面を参照して本発明を適用できる実施形態を詳細に説明する。図１に、本発明を実施することのできる適したコンピューティングシステム環境の例（図中１００）を示す。コンピューティングシステム環境１００は、適したコンピューティング環境の一例にすぎず、本発明の使用または機能の範囲についてどんな制限も意味しない。またコンピューティングシステム環境１００は、この例示的な動作環境であるコンピューティングシステム環境１００に示すコンポーネントのいずれか１つまたは組合せに関してどんな依存や要件を有するものとも解釈すべきではない。

本発明は、その他多くの汎用または専用コンピューティングシステム環境または構成でも動作する。本発明で使用するのに適するであろう周知のコンピューティングシステム、環境、および／または構成の例には、限定しないがパーソナルコンピュータ、サーバコンピュータ、ハンドヘルドデバイスまたはラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラム可能な民生用電子機器、ネットワークＰＣ（personal computer）、ミニコンピュータ、メインフレームコンピュータや、これらのシステムまたはデバイスのいずれかを含む分散コンピューティング環境などが含まれる。

本発明は、プログラムモジュールなど、コンピュータによって実行されるコンピュータ実行可能命令の一般的なコンテキストで述べることができる。一般にプログラムモジュールは、特定のタスクを実施するか特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。本発明は分散コンピューティング環境で実施することもでき、その場合、タスクは通信ネットワークを介してリンクされたリモート処理デバイスによって実施される。分散コンピューティング環境では、プログラムモジュールは、メモリ記憶デバイスを含めたローカルとリモートの両方のコンピュータ記憶媒体に位置することができる。

図１を参照すると、本発明を実施するための例示的なシステムは、コンピュータ１１０の形の汎用コンピューティングデバイスを含む。コンピュータ１１０のコンポーネントには、限定しないがプロセッサ１２０と、システムメモリ１３０と、システムメモリを含めた様々なシステムコンポーネントをプロセッサ１２０に結合するシステムバス１２１とを含めることができる。システムバス１２１は、様々なバスアーキテクチャのいずれかを用いた、メモリバスまたはメモリコントローラ、周辺バス、ローカルバスを含めて、いくつかのタイプのバス構造のいずれかとすることができる。限定ではなく例として、このようなアーキテクチャには、ＩＳＡ（Ｉｎｄｕｓｔｒｙ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＭＣＡ（Ｍｉｃｒｏ Ｃｈａｎｎｅｌ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＥＩＳＡ（Ｅｎｈａｎｃｅｄ ＩＳＡ）バス、ＶＥＳＡ（Ｖｉｄｅｏ Ｅｌｅｃｔｒｏｎｉｃｓ Ｓｔａｎｄａｒｄｓ Ａｓｓｏｃｉａｔｉｏｎ）ローカルバス、およびＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ）バス（メザニンバスとも呼ばれる）が含まれる。

コンピュータ１１０は通常、様々なコンピュータ可読媒体を備える。コンピュータ可読媒体は、コンピュータ１１０からアクセスできる任意の利用可能な媒体とすることができ、揮発性と不揮発性の媒体、リムーバブルとノンリムーバブルの媒体の両方が含まれる。限定ではなく例として、コンピュータ可読媒体には、コンピュータ記憶媒体および通信媒体を含めることができる。コンピュータ記憶媒体には、コンピュータ可読命令、データ構造、プログラムモジュール、その他のデータなどの情報を記憶するための任意の方法または技術で実現された、揮発性と不揮発性、リムーバブルとノンリムーバブルの両方の媒体が含まれる。コンピュータ記憶媒体には、限定しないがＲＡＭ（random access memory）、ＲＯＭ（read only member）、ＥＥＰＲＯＭ（electrically erasable programmable read-only memory）、フラッシュメモリまたは他のメモリ技術、ＣＤ（compact disc）−ＲＯＭ、ＤＶＤ（digital versatile disc）または他の光ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置または他の磁気記憶デバイスが含まれ、あるいは、所望の情報を記憶するのに使用できコンピュータ１１０からアクセスできるその他の任意の媒体が含まれる。通信媒体は通常、搬送波や他のトランスポート機構などの変調されたデータ信号中に、コンピュータ可読命令、データ構造、プログラムモジュール、またはその他のデータを組み入れたものであり、任意の情報送達媒体が含まれる。「変調されたデータ信号」という語は、情報が信号中に符号化される形で１つまたは複数の特性が設定または変更された信号を意味する。限定ではなく例として、通信媒体には、有線ネットワークや直接配線式接続などの有線媒体と、音響、ＲＦ（radio frequencies）、赤外線、その他の無線媒体などの無線媒体とが含まれる。以上の任意の組合せもコンピュータ可読媒体の範囲に含めるべきである。

システムメモリ１３０は、読取り専用メモリ（ＲＯＭ）１３１やランダムアクセスメモリ（ＲＡＭ）１３２など、揮発性および／または不揮発性メモリの形のコンピュータ記憶媒体を含む。ＲＯＭ１３１には通常、起動中などにコンピュータ１１０内の要素間で情報を転送するのを助ける基本ルーチンを含むＢＩＯＳ（ｂａｓｉｃ ｉｎｐｕｔ／ｏｕｔｐｕｔ ｓｙｓｔｅｍ）１３３が記憶されている。ＲＡＭ１３２は通常、プロセッサ１２０がすぐにアクセス可能な、かつ／またはプロセッサ１２０が現在作用している、データおよび／またはプログラムモジュールを含む。限定ではなく例として、図１には、オペレーティングシステム１３４、アプリケーションプログラム１３５、その他のプログラムモジュール１３６、プログラムデータ１３７を示す。

コンピュータ１１０は、その他のリムーバブル／ノンリムーバブル、揮発性／不揮発性コンピュータ記憶媒体を備えることもできる。例にすぎないが図１には、ノンリムーバブル不揮発性の磁気媒体に対して読み書きするハードディスクドライブ１４１と、リムーバブル不揮発性の磁気ディスク１５２に対して読み書きする磁気ディスクドライブ１５１と、ＣＤ ＲＯＭや他の光媒体などリムーバブル不揮発性の光ディスク１５６に対して読み書きする光ディスクドライブ１５５を示す。この例示的な動作環境で使用できる他のリムーバブル／ノンリムーバブル、揮発性／不揮発性コンピュータ記憶媒体には、限定しないが磁気テープカセット、フラッシュメモリカード、ＤＶＤ、ディジタルビデオテープ、固体ＲＡＭ、固体ＲＯＭなどが含まれる。ハードディスクドライブ１４１は通常、インタフェース１４０などのノンリムーバブルメモリインタフェースを介してシステムバス１２１に接続され、磁気ディスクドライブ１５１および光ディスクドライブ１５５は通常、インタフェース１５０などのリムーバブルメモリインタフェースでシステムバス１２１に接続される。

以上に論じ図１に示したドライブおよびそれらに関連するコンピュータ記憶媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、その他のデータの記憶域をコンピュータ１１０に提供する。例えば図１には、ハードディスクドライブ１４１がオペレーティングシステム１４４、アプリケーションプログラム１４５、その他のプログラムモジュール１４６、プログラムデータ１４７を記憶しているのが示されている。これらのコンポーネントは、オペレーティングシステム１３４、アプリケーションプログラム１３５、その他のプログラムモジュール１３６、プログラムデータ１３７と同じものとすることもでき、異なるものとすることもできることに留意されたい。ここでは、オペレーティングシステム１４４、アプリケーションプログラム１４５、その他のプログラムモジュール１４６、プログラムデータ１４７が少なくとも異なるコピーであることを示すために、異なる番号を付けてある。

ユーザは、キーボード１６２、マイクロホン１６３、マウスやトラックボールやタッチパッド等のポインティングデバイス１６１などの入力デバイスを介して、コンピュータ１１０にコマンドおよび情報を入力することができる。その他の入力デバイス（図示せず）には、ジョイスティック、ゲームパッド、衛星受信アンテナ、スキャナなどを含めることができる。これらおよび他の入力デバイスは、システムバスに結合されたユーザ入力インタフェース１６０を介してプロセッサ１２０に接続されることが多いが、パラレルポート、ゲームポート、ユニバーサルシリアルバス（「ＵＳＢ」）など、その他のインタフェースおよびバス構造で接続されてもよい。モニタ１９１または他のタイプの表示デバイスも、ビデオインタフェース１９０などのインタフェースを介してシステムバス１２１に接続される。モニタに加えて、コンピュータは通常、スピーカ１９７やプリンタ１９６など他の周辺出力デバイスも備えることができ、これらは出力周辺インタフェース１９５を介して接続することができる。

コンピュータ１１０は、リモートコンピュータ１８０など１つまたは複数のリモートコンピュータへの論理接続を用いて、ネットワーク化された環境で動作することができる。リモートコンピュータ１８０は、パーソナルコンピュータ、ハンドヘルドデバイス、サーバ、ルータ、ネットワークＰＣ、ピアデバイス、またはその他の一般的なネットワークノードとすることができ、通常、パーソナルコンピュータ１１０に関して上述した要素の多くまたはすべてを備える。図１に示す論理接続は、ローカルエリアネットワーク（ＬＡＮ）１７１およびワイドエリアネットワーク（ＷＡＮ）１７３を含むが、その他のネットワークを含むこともできる。このようなネットワーキング環境は、オフィス、企業全体のコンピュータネットワーク、イントラネット、インターネットでよくみられる。

ＬＡＮネットワーキング環境で使用されるときは、コンピュータ１１０は、ネットワークインタフェースまたはアダプタ１７０を介してＬＡＮ１７１に接続される。ＷＡＮネットワーキング環境で使用されるときは、コンピュータ１１０は通常、インターネットなどのＷＡＮ１７３を介した通信を確立するためのモデム１７２または他の手段を備える。モデム１７２は内蔵でも外付けでもよく、ユーザ入力インタフェース１６０または他の適切な機構を介してシステムバス１２１に接続することができる。ネットワーク化された環境では、コンピュータ１１０に関して示したプログラムモジュールまたはその一部をリモートのメモリ記憶デバイスに記憶することができる。限定ではなく例として、図１には、リモートアプリケーションプログラム１８５がリモートコンピュータ１８０上にあるものとして示す。図示のネットワーク接続は例示的なものであり、コンピュータ間で通信リンクを確立するための他の手段を使用してもよいことは理解されるであろう。

一実施形態では、システム１００は、一般的な経理およびビジネスの機能を特定のアプリケーションモジュールによって統合することのできるビジネス管理ソリューション生成ソフトウェアを備える。これらのモジュールには、財務、取引、ロジスティクス、製造、顧客サービス、プロジェクト、人的資源のためのモジュールを含めることができる。ただし、その他のモジュールタイプをこのビジネス管理ソリューションで使用することもできる。本発明のソリューションは、複数の通貨（ユーロ、ドル、円、ウォンなど）、複数の言語（英語、ドイツ語、フランス語、デンマーク語、ロシア語、日本語、中国語など）、複数の税金形式（複数の税務当局とやり取りするエンドユーザによって使用される）をサポートするように構成することができる。

ビジネス管理ソリューションで使用されるモジュールは、異なる様々なソースから開発することができる。一実施形態では、これらのすべてのモジュール間にある共通のつながりは、ラベルの使用である。ラベルは、識別子で表されるテキストである。ラベルは、ダイアログボックス、テキストストリング、または、ユーザに情報を伝えるのに使用される任意のテキストを含めて、ラベルプロパティを有する任意のオブジェクト上で使用することができる。ラベルは一般に、グラフィカルユーザインタフェースすなわちＧＵＩなどのリソースを介してユーザに提示される。ただしラベルは、テキストをユーザに提示する他の手段を介してユーザに提示することもできる。さらに、ラベルは、「ラベル」「ヘルプ」「キャプション」「ツールチップ」などのラベルプロパティを有するコントロール上で使用することもできる。以前のビジネスソリューションソフトウェアでは、各モジュール用のラベルが別々のリソースファイルに保持される。しかし、これらのリソースファイルは一般に、特定モジュールの独自仕様のフラットファイルアーキテクチャで保持されていた。開発者はしばしば、モジュールの開発プロセス中に、現在作成中のラベルの要件を満たすラベルが別のモジュール中にあることを知っていることがある。しかし、従来技術のシステムにおける独自仕様のファイルソース構造では、開発者は、あるモジュールからのラベルを別のモジュール中で使用することができず、ラベルを検索することも不可能であった。

図２は、本発明の一実施形態による、ビジネスソリューションシステム２００中のラベルを構成する様々な集まり（collection）の間の関係を示すエンティティ関係図である。図２のエンティティ関係図は、言語テーブル２１０（またはシステム中の利用可能言語を示すその他の指標）と、マスタ２２０と、ラベルＩＤテーブル２３０と、ラベルテキストテーブル２４０を含む。一実施形態では、これらの集まりは、テーブルに構成されたＳＱＬ（Structured Query Language）メタデータストアとして構成される。ただし、これらの集まりのその他の構成およびその他のデータベースを使用してもよい。ラベルＩＤテーブル２３０およびラベルテキストテーブル２４０については、図３Ａおよび３Ｂに関してより詳細に述べる。

言語テーブル２１０は、少なくとも２つのサブフィールドを含むテーブルである。言語テーブル２１０中の２つのサブフィールドは、言語ＩＤフィールド２１１と言語名フィールド２１２である。言語ＩＤフィールド２１１は、特定言語を示すコードであってビジネスソリューションソフトウェアプログラムによって理解可能なコードを保持する。言語名フィールド２１２は、言語の名前を保持するテキストフィールドである。例えば、利用可能言語の１つが米国英語である場合、言語ＩＤフィールド２１１は例示として「０１」とすることができ、ＡＳＣＩＩ（American National Standard Code for Information Interchange）規格が使用される場合は「ｅｎ−ｕｓ」とすることができる。ただし、その他のＩＤタイプを言語ＩＤフィールド２１１中で使用してもよい。メタデータテーブルのこのエントリについての言語名フィールド２１２は、例えば「Ｅｎｇｌｉｓｈ−ＵＳ」となる。あるいは、このソリューションが特定の言語によって提供されたものである場合、このエントリは、その特定言語のテキストを有するラベルとしてもよい。

言語テーブル２１０に記憶された情報は、ユーザがシステムの動作言語を確認または変更したいときに、ラベルダイアログ表示内でユーザに対して表示することができる。言語テーブル２１０は、ラベルテキストテーブル２４０と１：ｎの関係にある。この関係（１：ｎ）が生じるのは、システム２００に利用可能な各言語で様々なラベルを表す複数のラベルテキストがある可能性があるからである。

マスタ２２０は、一実施形態では、システム２００中の各ラベルに関する１つのバージョンを含むテーブルである。一実施形態では、マスタ２２０は、元の言語およびフォーマットによる、ラベルの元のバージョンを保持する。ただし、ラベルの他のバージョンをマスタ２２０に記憶してもよい。例えば、ベストプラクティスガイドラインが使用される場合、システム２００は、米国英語のラベルをマスタ２２０に記憶することができる。ベストプラクティスガイドラインは、特定のカテゴリタイプ、説明、言語を使用してラベル開発を標準化する手順のセットである。システム２００中の各ラベルには、マスタ２２０中の１つのエントリが関連する。マスタラベルは、ラベルの変換が更新されている最中や、ラベルが現在選択されている（アクティブな）言語にまだ変換されていないときや、何らかの理由でシステム２００からアクセス不可能になったときに使用される。しかし、代替実施形態では、マスタ２２０に記憶される情報は、ラベルテーブル２３０と言語２１０のどちらかの中に、マスタラベルのラベルＩＤを示す１つまたは複数のフィールドとして記憶することもできる。さらに、マスタ２２０は、どの言語ラベルが作成されたかに関する情報を保持する単純なフィールドとしてもよい。このフィールドは、システム２００中の任意のテーブルに位置するものとすることができる。

各マスタテーブルエントリ２２１は、ラベルＩＤテーブル２３０中の１つのエントリに対応する。ラベルＩＤテーブル２３０は、変換者（テキストを変換している人）がラベルを正しく変換するのに役立つ様々なプロパティを含む。これらのプロパティはまた、開発者がラベルを正しく使用するのにも役立つ。複数のラベルＩＤが同じマスタラベルを共有することができるので、マスタテーブルエントリ２２１とラベルＩＤテーブル２３０との関係は１：ｎである。

ラベルテキストテーブル２４０は、ラベルＩＤで識別される各ラベルについてのテキストを含むエントリを備える。ラベルテキストテーブル２４０はまた、様々な言語による各ラベルＩＤについての変換を含むエントリも備える。ラベルＩＤテーブル２３０とラベルテキストテーブル２４０との関係、ならびに言語テーブル２１０とラベルテキストテーブル２４０との関係は、１：ｎである。これは、１つのラベルに対してラベルＩＤテーブル２３０中に１つのエントリがあるが、ラベルのテキストは複数の言語で存在する可能性があるからである。しかし、本発明の他の実施形態では、ラベルＩＤとラベルテキストとの関係は１：１（またはテキストが存在しない場合は１：０）であり、マスタラベルの各変換が、それ自体の固有のラベルＩＤおよびエントリをラベルＩＤテーブル２３０中に有する。

図３Ａに、本発明の一実施形態による、ラベルＩＤテーブル２３０を構成するフィールドを示す。ラベルＩＤテーブル２３０は、ＩＤフィールド２３１と、名前空間フィールド２３２と、カテゴリフィールド２３４と、説明フィールド２３５を含む。他の実施形態では、ラベルＩＤテーブル２３０は、ラベルＩＤテーブル中のエントリが別のラベルから複製されたものかどうか、またはテーブル中の別のエントリに複製されたものかどうかを示すフィールド２３６を含むことができる。

通常、ラベルはリソースファイル中に保持される。現在のビジネスソリューションシステムは、ＳＱＬテーブルなどのデータベースメタデータストアを介して利用可能な包括的なリソースファイルを使用しない。現在のビジネスソリューションシステムでは、これらのラベルは、独自仕様のリソースファイルに記憶される。独自仕様のリソースファイルを使用することに関連する問題の１つは、開発者がシステム中の１つまたは複数のラベルの一部を、このファイルについてのすべてのリソースを有するファイルで置換したいと思っても、システムは、現在のラベルと同じラベルプロパティまたは用語法を有する別のファイルをシステム中で探すことをしないことである。しかし、ビジネスソリューション環境では、ビジネスソリューションシステムは、複数のベンダによって開発された、同じまたは類似する問題に対する多くの様々なソリューションを扱うことが必要とされる。したがって、本発明のラベルシステム２００は、様々なベンダによってなされたすべての寄与の総和を用いることができる。

ＩＤ２３１フィールドは、システム２００中の特定のラベルを識別するのに使用される。一実施形態では、このＩＤは、グローバル一意識別子すなわちＧＵＩＤである。ＧＵＩＤは、２つのベンダが２つの無関係のラベルに対して同じ識別番号を選択したことによって生じる問題を回避するために使用される。一実施形態のＧＵＩＤは、一意識別子が必要とされるどんな場合にもすべてのコンピュータおよびネットワークにわたって使用することのできる１２８ビット整数（１６バイト）である。このような識別子システムを使用することにより、２つのラベルが同じＩＤを有する可能性が減少する。ＧＵＩＤは、一実施形態ではストリングとして表され、以下のパターンに従ってフォーマットされる。
ｘｘｘｘｘｘｘｘ−ｘｘｘｘ−ｘｘｘｘ−ｘｘｘｘ−ｘｘｘｘｘｘｘｘｘｘｘｘ

このフォーマットで、ＧＵＩＤの値は、一連の８、４、４、４、１２ディジットのグループによる小文字の１６進数ディジットとして表され、ハイフンで区切られる。例えば、行３０１のエントリに対するＧＵＩＤ戻り値は、３８２ｃ７４ｃ３−７２１ｄ−４ｆ３４−８０ｅ５−５７６５７ｂ６ｃｂｃ２７とすることができる。ただし、その他のフォーマットタイプをＩＤフィールド２３１に使用してもよい。新しいラベルが生成されるたびに、新しいＧＵＩＤが割り当てられる。一実施形態では、新しいラベルは、システム２００にとって新しいラベルとして定義され、単に既存のラベルの変換ではない。しかし他の実施形態では、既存のラベルの変換に対して、ＩＤフィールド２３１中の新しいエントリが生成される。

ＧＵＩＤの使用は、現在のシステムに勝る付加利益をもたらす。第１に、各ラベルを複数の言語に分ける必要がない。さらに、ＧＵＩＤにより、行番号の使用など他の方法で一意性を制御する必要なしに、各ラベルを一意に識別することができる。第２に、ＧＵＩＤにより、ラベルの物理記憶域を、独自仕様のリソースファイルからメタデータデータベースやウェブサービスなどの共通リソースファイルに変更することができる。

ラベルＩＤテーブル２３０中の名前空間フィールド２３２は、変換者がラベルテキストをマスタ言語からターゲット言語に変換するときにラベルについての正しい語句を得るのを助けるために、ラベルＩＤに入力される特別なフィールドである。現在のラベルシステムでは、特定のラベルがプログラム中のどこで使用されるかを容易に知ることは不可能である。さらに、ラベルがどの領域で使用されるかを知るのは容易ではない。したがって、プログラムを変換者のコンピュータにインストールして、ラベルがどこで使用されるかを知ることができるようにならない限り、変換者がラベルについての正しい語句を得ることは、不可能とは言わないまでも極度に難しい。名前空間フィールド２３２は、プログラムを変換者のマシンにインストールする必要なしに、ラベルが使用される領域を知ることを可能にする。名前空間フィールドに含まれる情報は、新しいラベルが作成されるときに開発者によって提供され（自動または手動で）、特定のラベルの使用法に関係する情報をもたらす。例えば、図３Ａの行３０２のエントリ中で、名前空間フィールド２３２は、このラベルが課金モジュール中で使用されることを変換者または開発者に伝える。

ラベルＩＤテーブル２３０中のカテゴリフィールド２３４は、プログラムのどのコンポーネントでラベルが使用されるかを示す特別なフィールドである。さらに、カテゴリフィールド２３４の使用は、開発者がラベルテキストの作成中にラベルを正しい方式で記述するのに役立つ。カテゴリは、ラベルについてのノードタイプとプロパティの組合せである。ノードタイプは、ラベルの特別なプロパティである。これらのラベルプロパティのいくつかには、「ラベル」「ヘルプ」「キャプション」などを含めることができる。したがって、カテゴリフィールド２３４は、ラベルが所望のプログラムのために正しい方式で使用されるようにすることを可能にする。さらに、カテゴリは、システム中に存在するすべてのコントロールのマッピングである。したがって、所望のラベルのタイプまたはカテゴリに基づいて、既存のラベルデータベースを検索することが可能である。本発明では、システム２００によって実施される各規則またはコントロールごとに、１つのカテゴリが作成される。モジュールの開発中、特定のラベルテキストに特別な規則が必要な場合は、追加のカテゴリを作成することができる。例えば、ノードフィールド２３４は、エントリ３０３のラベルが、ユーザをモジュール中の別のポイントに向けるためにモジュールのメニューバー上で使用されるものであることを伝えるエントリとすることができる。各カテゴリは、システム２００中の特定の機能にマッピングされる。

説明フィールド２３５は、ラベルがどのように使用されるかをユーザまたは開発者に説明する、テーブル２３０中のエントリである。例えば、説明フィールド２３５は、エントリ３０３のラベルが台帳のケース上で使用されるものであることを伝えるエントリとすることができる。この説明は、言葉（プレーンテキスト）によるものでもよく、所定のコードリストに対してコード化されたものでもよい。

複製元フィールド２３６は、エントリの関連ラベルがラベルシステム中の別のラベルから複製されたものかどうかを示す。ラベルが別のラベルから複製されたものである場合は、複製元フィールド２３６は、親またはマスタラベル２２０からのＩＤを含む。一実施形態では、このＩＤは親のＧＵＩＤである。ただし、その他のＩＤをフィールド２３６で使用してもよい。ラベルが別のラベルの複製バージョンでない場合は、複製元フィールド２３６は空欄であるか、ヌルに設定される。さらに、ラベルのテキストがコピー後にマスタラベルのテキストから変更された場合は、複製元フィールド２３６はヌルに設定され、それにより、マスタラベル２２０とこの特定の子ラベルとの間のどんなリンクも除去される。ただし、複製元フィールド２３６は、エントリに対するその他の変更によってもリセットされることになる。代替実施形態では、図３ＡのラベルＩＤテーブル２３０は、どのラベルＩＤが複製済みラベルを含むかを示すフィールドを含む。ＩＤテーブル２３０中のラベルは、マスタラベルと子のどちらかである。

図３Ｂに、特定のラベルのラベルテキストテーブル２４０を占めるフィールドを示す。ラベルテキストテーブル２４０のエントリは、少なくとも３つの異なるフィールドを含む。すなわち、ラベルＩＤフィールド２４４、ラベルテキストフィールド２４１、編集日２４２である。本発明の代替実施形態では、ラベルテキストテーブル２４０に追加フィールドを加えることもできる。これらのフィールドには、テキストが書かれた言語を示すフィールド２４３や、ラベルテキストテーブル中のテキストの各バージョンのエントリ識別子を識別するフィールドが含まれる。

ラベルテキストテーブル２４０のテキストフィールド２４１は、システムのすべての利用可能言語による、ラベルのテキストの最新バージョンを含む。このラベルについてのラベルテキストテーブル２４０中の第１のエントリ３５１は、このラベルが書かれた元の言語またはマスタ言語によるものである。このテキストは、マスタテキストと呼ばれる。このラベルがベストプラクティスガイドラインに従って開発される場合、マスタテキストは米国英語で書かれることになる。ただし、その他の言語をマスタ言語として使用してもよく、ベストプラクティスガイドラインに従う必要はない。一般に、マスタ言語はシステムが動作している現在言語に対応することになる。

ラベルテキストがマスタ言語から別の言語に変換されるとき、新しいラベルテキストエントリ、例えば３５２や３５３が、ラベルテキストテーブル中に作成される。これらのエントリは、元のラベルの変換済みバージョンをそれぞれの言語で含む。例えば、ラベルの元のテキストが「Ｄｏ ｙｏｕ ｗａｎｔ ｔｏ ｓａｖｅ ｔｈｅ ｃｈａｎｇｅｓ ｙｏｕ ｍａｄｅ ｔｏ」である場合、このテキストは、ラベルテキストテーブル２４０の第１行３５１に記憶される。その後、このテキストがドイツ語、デンマーク語、フランス語に変換されるとき、これらの変換が、ラベルテキストテーブル中でマスタテキストエントリの下のエントリに入力される。これらの追加の変換を、エントリ３５２、３５３、３５４で示す。

編集日フィールド２４２は、ラベルテキストテーブル中のその特定のエントリに関連する言語でラベルのテキストが最後に変更されたのはいつかが開発者にわかるように、ラベルテキストテーブル２４０中に設けられる。さらに、「修正者」フィールドなど、妥当性検査情報を含むその他のフィールドを追加することもできる。この日付は、テキストについての変換が提供された場合に、この変換がそれよりも新しいバージョンを置換しないようにするようにするのに役立つ。変換が自動的にシステムにロードされると、変換日が比較され、エントリ中のバージョンの方が提案エントリよりも新しい場合は、提案エントリはテーブルに入力されない。また、編集日フィールド２４２により、開発者は、変換がマスタテキストエントリの最新バージョンと同じく最新であるかどうかをチェックすることもできる。一実施形態では、マスタテキストエントリ３５１の編集日は、特定ラベルについてのラベルテキストテーブル２４０中で最も古い日付であることが望ましい。

いくつかの実施形態では、ラベルテキストテーブル２４０は、言語フィールドエントリ２４３を含む。言語フィールドエントリ２４３は、ラベルテキストテーブル中の特定エントリの特定言語を、開発者がその言語を喋ることや理解することがない場合であっても開発者に示す。言語フィールドエントリ２４３中のこの言語標識は、言語の数値表現としてもよく、言語名として記述してもよく、その他の任意の種類の言語識別子としてもよい。

数値表現を使用して言語が識別される場合は、言語の参照番号またはエントリは、例示として、ＡＳＣＩＩ言語コードやＩＳＯ（International Organization for Standardization）６３９などの知られている規格に準拠するものとすることができる。ただし、その他のコードを使用してテキストエントリの言語を識別してもよい。言語名がフィールド２４３に入力される場合は、言語名は、例示として、知られている規格（すなわち英語の言語名）に従って記述することができる。ただし、その他のフォーマットを使用してもよい。

ラベルテキストテーブル２４０は、特定のラベルテキストについてのラベルＩＤ２３１を識別するエントリフィールド２４４も含む。このエントリにより、開発者は、現在のテキストがどのラベルＩＤ２３１に関係するかを知ることができる。ラベルテキストテーブル２４０の他の実施形態は、テキストＩＤ２４５のためのエントリを含む。このテキストＩＤ２４５は、各テキストラベルをラベルテキストテーブル２４０中でそれ自体のエントリとして個別に識別するために提供される。テキストＩＤ２４５のエントリは、ＧＵＩＤとすることもでき、あるいは、ラベルテキストテーブルの構成に適合するその他の任意の識別方法とすることもできる。代替実施形態では、ラベルテキストテーブル２４０とラベルＩＤテーブル２３０を１つのテーブルまたはデータベースにマージすることができる。この実施形態では、ラベルを管理するため、およびモジュールの実行中に正しいラベル言語テキストが表示されるようにするために、追加のフィールドセットが必要になる。さらに、ラベルのロードを管理するためのインデックスも追加される。

図４は、ラベルシステムインタフェース４００を構成するコンポーネントを示すブロック図である。ラベルシステムインタフェース４００は、開発者４０１をメタデータストア４０９にリンクして、開発者がシステム２００のための新しいモジュールを開発するときに既存のラベルを扱えるようにするインタフェースである。ラベルシステムインタフェース４００は、ラベルダイアログ４０２、ラベルダイアログロジックコンポーネント４０３、拡張言語インタフェース４０４、ラベルインタフェース４０５を備える。

開発者は、ラベルダイアログ４０２を介してラベルシステムインタフェース４００と対話する。ラベルダイアログ４０２は、開発者からラベルシステムインタフェースの諸機能へのアクセスを可能にするユーザインタフェースである。一実施形態では、ラベルダイアログ４０２は、ユーザが特定のラベルの使用法を閲覧および管理することができるようにするウィンドウである。ラベルダイアログ４０２は、メタデータストアへのこのインタフェースを使用して、ラベルを扱い、すべての利用可能言語のラベルのために利用できるコマンドの完全なセットにアクセスする。これらの機能を提供するために、ラベルダイアログインタフェース４０２は、ラベルシステム４００中の各ラベルにつき、すべての利用可能言語へのアクセスを必要とする。

しかし、ラベルダイアログ４０２は、ラベルを特定の状況で使用することができるかどうかを判定するためのロジックは含まない。すべての制御は、ラベルインタフェースまたはラベルダイアログロジックコンポーネント４０３を制御するクラスに渡される。ラベルダイアログロジックコンポーネント４０３は、ラベルダイアログ４０２と共に使用されるように設計されているが、ラベルダイアログ４０２のためのすべてのロジックを含むので、ラベルダイアログロジックのいくつかの機能は、他の領域で再利用することができる。さらに、ラベルダイアログロジックコンポーネント４０３は、各ラベルがそのラベルについての名前空間とカテゴリの正しい組合せに適合するような形で使用されることを確実にする。このロジックは、最初に新しいマスタラベルを作成せずにラベルを別の領域でうっかり使用してしまうことを防止する。

拡張言語インタフェース４０４は、ラベルダイアログインタフェース４００からシステム中で利用可能なすべての言語へのアクセスを提供する。拡張言語インタフェース４０４は、別のクラスを使用して、複数の言語をラベルダイアログロジックコンポーネント４０３およびラベルダイアログ４０２に利用可能にする。拡張言語インタフェース４０４は、システム中の複数の言語に共通のメソッドだけを有する（すべての利用可能言語のリストを返すメソッド、また、現在の言語のＩＤを返すメソッド）。１つの言語だけに関係するメソッドは、ラベルクラス４０５上に直接に位置する。ラベルクラスは、メタデータ中のラベルに接続することを可能にする。利用可能な各言語中に、ラベルクラスのインスタンスが１つある。ただし場合によっては、特定のクラスにはインスタンスがないこともある。

言語インタフェースコンポーネント４０４はまた、利用可能言語へのアクセスを制御する。言語インタフェースコンポーネント４０４は、ラベルのインスタンスのマップを含む。言語インタフェースコンポーネント４０４中にはまた、現在のラベルについての追加の利用可能言語クラスそれぞれへのインタフェースもある。

図５は、本発明の一実施形態による、モジュールの一部の開発中に開発者がモジュール用に新しいラベルを作成するときに実施されるステップを示すフローチャートである。例えば、開発者がモジュール中で「ｃｕｓｔｏｍｅｒ」についての入力を表すラベルを作成したい場合を考える。開発者は、このラベルがどのようにモジュール中で使用されることになるかを判定しなければならない。語句「ｃｕｓｔｏｍｅｒ」は、多くの様々な意味を持つ。例えば、ｃｕｓｔｏｍｅｒは、自分から物品およびサービスを購入する人を意味する場合もあり、自分が対処する「人」を意味する可能性もある。この単語の使用法は、他の言語のテキストにも影響を与えることになる。図５のブロック５０１にこれを示す。

次に、開発者はラベルダイアログプログラムを開く。開かれるラベルダイアログは、例示として、図６に示すラベルダイアログ６００と同様のものである。ただし、その他のインタフェースを使用してもよい。提示されたインタフェースにより、開発者は、ラベルに対して望む特定のテキストを入力することができる。図５のブロック５０２に、ラベルダイアログを開くことを示す。

ラベルダイアログを開くと、次いで開発者は、ラベルに対する所望のテキストを行６０２に入力する。あるいは開発者は、行６０２に、ラベルに対する所望のテキストの一部を入力するのでもよい。例えば、開発者は、テキストセクションに「ｃｕｓｔｏｍｅｒ」と入力してもよく、「ｃｕｓｔ」と入力してもよい。さらに、開発者は、新しいラベルがどのように使用されることになるかを示すデータを、インタフェース中の行６０３および６０４に入力する。このデータは、ラベルシステム中で既存のラベルを検索するのに使用することもでき、新しいラベルを作成するときに使用することもできる。例えば、開発者が販売管理用のモジュールを作成している最中であり、語句「ｃｕｓｔｏｍｅｒ」を使用して購入者についてのラベルを生成したい場合、開発者は、購入者についてのカテゴリコードを行６０４に入力することになる。このコードは、手動で入力してもよく、プルダウンメニューで入力してもよく、現在のシステム設定を使用して自動的に入力されるものとしてもよい。このカテゴリコードが、この機能によって使用されるプロセスの残りを制御する。一般に、ラベルダイアログ中のカテゴリコードおよび名前空間のエントリは、ラベルシステムの現在設定に従う。図５のブロック５０４に、データの入力を示す。このデータは、通常の表現として入力される。さらに代替実施形態では、開発者は、選択されたカテゴリに検索を限定するチェックボックスを選択することによって、検索を制御することができる。

開発者は、ボタン６５０を選択することによって検索機能をアクティブにする。ただし、その他の技法を使用してラベル検索機能をアクティブにしてもよい。図５のブロック５０５に、検索エンジンのアクティブ化を示す。

次いで本発明は、データベース中を検索して、入力されたテキストにマッチするエントリをデータベース中で見つける。検索プロセスの間、進行状況インジケータをユーザに対して表示することができる。進行状況インジケータの１つを図６の参照番号６４０で示す。検索が完了すると、進行状況の指示は消え、ダイアログは、選択された言語による最初のクエリにマッチしたすべてのラベルの表示を開発者に返す。これをブロック５０６に示す。

インタフェース６００は、一実施形態では、図６に示すように、識別されたマッチを表示するように拡大する。この実施形態では、表示されるマッチのリストは、ラベルＩＤテーブル２３０に含まれる情報、ならびにラベルテキストテーブル２４０からのいくらかの情報を含むことができる。結果ビューは、選択された言語のテキストを、テーブル２３０との関係を通して入手可能な追加情報と組み合わせて表示する。検索結果は、ＧＵＩＤによる昇順で開発者に提示される。図６の領域６１０に、結果の例を示す。ただし、テキストマッチングによる昇順など、その他の順序付け技法を使用してもよい。次いで開発者は、ラベルテキストのいずれかが所望のテキストにマッチするかどうかをチェックする。これをブロック５２０に示す。新しいラベルに対する所望のテキストにマッチするテキストが見つかった場合は、開発者は、所望のラベルテキストにマッチするこの特定ラベルを強調表示するか、または他の方法で示す。これをブロック５０７に示す。望むなら、ラベルの変換を６２０に表示することもできる。

次にシステムは、選択されたラベルカテゴリおよび名前空間が新しいラベルのカテゴリと同じかどうかをチェックする。これをブロック５０８に示す。選択されたラベルと新しいラベルとでラベルカテゴリおよび名前空間が同じである場合は、選択されたラベルの情報を新しいラベルに使用する。これを図５のブロック５１１に示す。

ラベルの名前空間およびカテゴリが新しいラベルの所望の使用法と同じでない場合は、ラベルを複製しなければならない。この複製される情報には、選択されたラベルのすべての変換済みバージョンも含まれる。ラベルが新しいラベルに複製されるとき、新しいラベルの複製元ラベルのＧＵＩＤを示すエントリが、新しいラベルについてラベルＩＤテーブル２３０中に作成される。これをブロック５１０に示す。これにより、マスタラベルテキストが変更されたとき、新しいラベルのテキストを容易に更新することが可能になる。この変更時更新は、通常の検索置換プロトコルを実行することによって行うことができ、あるいはその他の任意の自動化方法によって行うことができる。

検索中にマッチが見つからなかったときは、開発者は、新しいラベルのための新しいオブジェクトを生成しなければならない。ブロック５２１に、新しいオブジェクトの生成を示す。ラベルの生成中に、ラベルの特定の特性をラベルＩＤテーブル２３０およびラベルテキストテーブル２４０に記憶する。ラベルのテキストが不完全な場合は、開発者は、所望のテキストの残りの部分をラベルダイアログ６００に入力する。名前空間およびカテゴリコードは、ラベルシステムの現在設定に基づいて入力される。開発者はまた、所望の言語があればその言語でラベルテキストについての変換も生成しなければならない。また、ラベルの現在の動作言語のＩＤも、マスタ言語として記憶する。ブロック５２２に、これらの変換の追加または生成、およびラベルプロパティの入力を示す。

最後に、本発明は、ビジネスソリューションソフトウェアプログラムにおいてラベルを記憶および使用するための新しい方法も対象とする。各言語につき単一のリソースファイルがあるのではなく、情報は１：ｎの関係に分割される。関係の「１」の側は、ラベル識別子、およびその他の実質的な一般ラベル情報を保持する。関係の「ｎ」の側は、特定言語のラベルテキストを保持する。このようにしてラベルを構成することにより、すべての言語のラベルにランタイムにアクセスすることが可能になる。

新しいラベルの開発中は、システム中の既存のラベルを使用する、あるいは新しいラベルを一から作成してラベルを複製することもできる。ラベルを検索するとき、表現を入力することが可能である（例えば「＜Ｌｅｄｇｅｒ」と入力すると、Ｌｅｄｇｅｒで始まるすべての利用可能ラベルが提供される。ただし、システムがどこで実施されるかに応じて、異なる構文を使用することができる）。検索される特定の名前空間またはカテゴリを選択することによって、ヒットを少なくすることが可能である。検索はまた、語句データベースを使用して実施することもできる。また、語句データベース（ウェブサービス）を使用して新しいラベルを作成することもできる。語句データベースに入力するときは、現在の検索基準を、ラベルが使用される実際の状況を記述する追加の基準と組み合わせることが可能である。これは、正しい語句が使用されることを確実にするためである。ラベルが語句データベース中で見つかると、これが新しい識別子に複製される。語句データベースは、サポートされるすべての言語についての変換を有する。ラベルが使用されることになる場合、ラベルは、実際の名前空間およびカテゴリにマッチして検索結果中に存在しなければならない。そうである場合は、この特定のラベルを選択することが可能である。そうでない場合は、ラベルテキストを手動で記述することによって、またはラベルを語句データベースの別の名前空間／カテゴリから複製することによって、新しいラベルを作成する。ラベルを複製すると、現在の名前空間およびカテゴリに関係する新しい識別子が提供される。すべてのテキストおよびその他の一般情報が複製される。

ラベルの管理はラベルダイアログを使用して行われ、ラベルダイアログは、特定のラベルプロパティから直接に呼び出される。ダイアログは、ラベルを維持すること、および特定のプロパティに対して使用される特定のラベルを選択することを可能にする。必要とされる機能を提供するラベルインタフェースを介して、コードによるラベルシステムの使用がもたらされる。これにより、ラベルの記憶方法を変更することが可能である。記憶域は、ＳＱＬメタデータストア、リソースファイル、またはウェブサービスとすることができる。実際、ウェブへの具体的なアクセスに応じて、あらゆるタイプの記憶域の組合せとすることができる。

ラベルダイアログは、ラベルが正しい状況で使用されることを確実にする。ラベルシステムにカテゴリを導入することにより、ラベルが正しく使用されることが保証される。ただし、この機能には別の目的もある。ラベルを変換するとき、名前空間情報とカテゴリの組合せを介して、ラベルがどこで使用されることになるかを知ることが可能である。これにより、使用される正しい語句を知ることが可能である。ラベルがどこで使用されるかを知ることにより、より多くのベストプラクティスチェックをベストプラクティスフレームワークに追加することが可能である。本発明では、既知の（または未知の）変換ツールに適合する特定の変換ファイルを生成することができる。日付情報を変換ファイルにエクスポートすることによって、変換をインポートするときに日付をチェックすることが可能である。これは、進行中の変換プロセスが、システム中の最後の変更と同じく最新であることを確実にするために行う。更新される相互参照システムを使用して、特定のラベルがどこで使用されるかを知ることが可能である。また、特定のラベルに対する変更を知ることも可能である。この機能は変換者に関係があり、特定のラベルに対する変更が単純かどうか（例えば行の最後に「．」が追加されるなど）を変換者が判定できるようにする。

本発明を特定の実施形態に関して述べたが、本発明の趣旨および範囲を逸脱することなく形式および詳細に変更を加えることもできることは、当業者なら理解するであろう。

本発明を使用することのできる例示的な一環境のブロック図である。 本発明のラベルシステムを構成するテーブルを示すブロック図である。 ラベルＩＤテーブル中およびラベルテキストテーブル中のフィールドの概略図である。 ラベルＩＤテーブル中およびラベルテキストテーブル中のフィールドの概略図である。 ラベルダイアログのコンポーネント間の関係を示すブロック図である。 新しいラベルを作成するときに実行されるステップを示す流れ図である。 ラベルデータベースを開発および検索するときにユーザによって呼び出されるユーザインタフェースの例を示す図である。

符号の説明

２１０ 言語
２１２ 名前
２２０ マスタ
２３０ ラベルＩＤ
２３２ 名前空間
２３４ カテゴリ
２３５ 説明
２３６ 複製元
２４０ ラベルテキスト

Claims (10)

1. ビジネス統合システムにおいて新しいラベルを作成する方法であって、
   前記新しいラベルがどのように使用されるかを示すデータをインタフェースで受け取るステップと、
   所望のテキストにマッチするテキストをラベルデータベース中で検索するステップと、
   前記ラベルデータベース中で見つかったマッチのリストをユーザに返すステップと
   を備えることを特徴とする方法。
2. 前記マッチのうちの１つを前記新しいラベルについてのテキストとして選択するステップ
   をさらに含むことを特徴とする請求項１に記載の方法。
3. 前記新しいラベルのための新しいオブジェクトを前記ラベルデータベース中に作成するステップと、
   前記新しいラベルのためのＧＵＩＤを割り当てるステップと、
   前記新しいラベルに関連するテキストのための記録をラベルテキストデータベース中に作成するステップと、
   前記新しいラベルを前記ラベルデータベースに記憶するステップと
   をさらに含むことを特徴とする請求項１に記載の方法。
4. データをインタフェース中で受け取るステップは、
   前記新しいラベルについてのカテゴリコードを受け取るステップと、
   前記新しいラベルについての説明を受け取るステップとをさらに含む
   ことを特徴とする請求項３に記載の方法。
5. 前記ラベルについてのテキストの各バージョンを、ラベルテキストデータベース中の記録に記憶するステップをさらに含む
   ことを特徴とする請求項３に記載の方法。
6. 所望のテキストにマッチするテキストを前記ラベルデータベース中で検索するステップは、
   所望のテキストの少なくとも一部を有する記録を前記ラベルデータベース中で選択するステップと、
   選択された前記記録がどのように使用されるかについての指示を、選択された前記記録中で識別するステップと、
   選択された前記記録の指示された使用法を、前記新しいラベルの指示された使用法と比較するステップと、
   前記新しいラベルの所望のテキストと指示された使用法とのマッチに基づいて、選択された前記記録を順序付けるステップとをさらに含む
   ことを特徴とする請求項２に記載の方法。
7. 前記マッチのリストを前記ユーザインタフェース上に表示するステップと、
   前記マッチのリスト中の１つの記録が所望のエントリであることの指示を受け取るステップと、
   前記エントリを前記新しいラベルのテキストとして選択するステップとをさらに含む
   ことを特徴とする請求項６に記載の方法。
8. 選択された前記ラベルのカテゴリを前記ラベルのカテゴリと比較するステップと、
   選択された前記ラベルのカテゴリが前記新しいラベルのカテゴリと同じである場合は、選択された前記ラベルを前記新しいラベルに使用するステップとをさらに含む
   ことを特徴とする請求項６に記載の方法。
9. 選択されたラベルのカテゴリが前記新しいラベルのカテゴリと同じでない場合は、
   選択されたラベルを前記ラベルデータベース中の前記新しいラベルに複製するステップと、
   ラベルテキストデータベース中に変換があればそれらを、前記ラベルテキストデータベース中の前記新しいラベルについての記録に複製するステップと、
   選択されたラベルのＩＤを示すエントリを前記新しいラベル中に作成するステップとをさらに含む
   ことを特徴とする請求項８に記載の方法。
10. 選択された前記記録がどれも所望のテキストを含まない場合は、
    所望のテキストを前記新しいラベルに入力するステップと、
    前記システムの現在制御に応じて、前記新しいラベルについてのカテゴリおよび説明を判定するステップと、
    前記ラベルのテキストについての新しい変換を生成するステップと、
    前記新しい変換を、前記ラベルテキストデータベース中の前記ラベルについての記録中に受け入れるステップとをさらに含む
    ことを特徴とする請求項６に記載の方法。

Images