JP2014225256A - プログラム生成装置、プログラム生成装置の制御方法、およびプログラム - Google Patents

Abstract

【課題】 アプリケーション定義に基づきプログラム自動生成装置により自動生成されるプログラム内の文字列を、アプリケーション定義から特定し、容易に多言語化することが可能なプログラム自動生成の技術を提供する。【解決手段】 プログラム生成装置において、生成されるアプリケーションをマルチ言語対応にするため、アプリケーションの生成のための定義ファイルから、翻訳対象の文字列の位置を取得する。定義ファイル内で一意である翻訳対象文字列の位置の情報からリソースキーを生成し、そのリソースキーに、取得した翻訳対象文字列をリソース値として対応付けて、言語リソースファイルに出力する。また、プログラムの翻訳対象文字列となる箇所に、言語表示を切り替えるためにリソースキーを埋め込んだプログラムを生成することにより、アプリケーションの実行時に、リソースファイルを使用することで、指定した言語で文字列表示が切り替わるようにする。【選択図】図１

Description

本発明は、ソフトウェアプログラムの多言語化対応の実現を支援するための技術に関する。

従来から、ソフトウェアプログラムにおいて、画面表示／出力／その他の処理で使用する文字列を直接プログラムに記載するのではなく、文字列の変わりに変数やメッセージＩＤを用意し、対応する文字列はプログラムとは異なる定義ファイルに記載する方法がある。この方法により、プログラム動作時に、定義ファイルを異なる言語の文字列が記載された定義ファイルに切り替えるだけで、画面表示／出力／その他の処理で使用する文字列を、適宜割り当てることができる。

特許文献１においては、ユーザヘの表示が発生した場合、取得した表示言語情報の種別を判断し、表示言語情報から利用すべき表示言語に対応したマッピング情報を選択し、表示用の各国言語に対応した各表示言語リソースを含むライブラリのうち、選択されたマッピング情報に対応する表示言語リソースを検索し、利用すべき表示言語に合致したライブラリを抽出することで、ソフトウェアプログラムのプログラムコード部を修正せずに複数の表示言語を容易に切り替え表示することができる技術が記載されている。

また、特許文献２においては、まず第１にデフォルトの言語を表示させることが可能である。また、第２に表示／出力用の文字列の管理のために「言語」に加えて「国・地域」も使用する。これにより、より適切なローカル化が可能となり、同じフランス語でもフランスで使用される場合とベルギーで使用される場合では別の文字列を表示／出力が、適切なローカルの定義がない表示については、デフォルトの地域を用いることを可能とする技術を提供している。すなわち、特許文献２の技術によると、例えば英語をデフォルトとしているが、デフォルトではないフランス語で動作させたい場合であって、フランス語の翻訳が完了している場合にはフランス語で、翻訳が完了していない部分についてはデフォルトの英語で表示させることが可能である。また、同じ英語であっても地域により異なる場合、アメリカ英語とイギリス英語との差分を定義可能（ローカル化可能）である。この場合には、例えばイギリス英語がデフォルト地域であれば、アメリカ英語でプログラムを動作させたい場合において、アメリカ英語への翻訳が完了している部分のみをアメリカ英語で表示し、翻訳が完了していない部分については、デフォルト地域のイギリス英語で表示する、ということが可能となる。

特開２００１−１４２６００号公報 特開２００７−３２８４２８号公報

しかしながら、特許文献１、特許文献２のいずれにおいても、あらかじめプログラムから言語リソース（表示／出力などに使用する文字列データ）が、適切に切り離された形式で初期の開発を進めている必要がある。

実際には、開発当初はマルチ言語に対応することを想定せず、プログラムに文字列をそのまま単一の言語（例えば日本語）で直接記述していることが多い。また、プログラム自動生成装置においても、単一の言語にしか対応していない場合もある。

その際には、前述のように単に言語リソースのファイルやデータ定義を変更するだけではなく、プログラム中のマルチ言語化したい部分の文字列を、変数に対応付ける作業から実施しなければならない。

本発明の目的は、上記問題に鑑み、アプリケーション定義に基づきプログラム自動生成装置により自動生成されるプログラム内の文字列を、アプリケーション定義から特定し、容易に多言語化することが可能なプログラム自動生成の技術を提供することである。

本発明は、翻訳対象となる箇所をリソースキーに置き換え、翻訳後の文字列となるリソース値を前記リソースキーに代入することによって当該箇所を指定した言語の文字列で表示することを可能とするアプリケーションのソースプログラムを生成するプログラム生成装置において、前記アプリケーションを生成するための定義であるアプリケーション定義ファイルをアプリケーション定義ファイル記憶手段に登録するアプリケーション定義ファイル登録手段と、前記ソースプログラムの動作時に翻訳対象となる翻訳対象文字列を前記アプリケーション定義ファイルから特定するための翻訳対象文字列特定手段と、前記翻訳対象文字列の翻訳語となるリソース値を取得するためのキーとなるリソースキーを生成するリソースキー生成手段と、前記リソースキー生成手段により生成された前記リソースキーに対応する前記翻訳語となるリソース値を前記翻訳対象文字列から取得するリソース値取得手段と、前記リソースキーと前記リソース値を対応付けて、言語リソースファイルに出力するリソースファイル生成手段と、前記アプリケーションの実行時に、指定した言語の前記リソースファイルに存在する、リソースキーに対応するリソース値を用いることにより、当該アプリケーションの翻訳対象文字列を指定した言語の文字列で表示可能にするために、前記ソースプログラムの翻訳対象文字列となる箇所に、言語表示を切り替えるために前記リソースキーを埋め込んだソースプログラムを生成するソースプログラム生成手段を備えることを特徴とする。

本発明により、アプリケーション定義に基づきプログラム自動生成装置により自動生成されるプログラム内の文字列を、アプリケーション定義から特定し、容易に多言語化することが可能なプログラム自動生成の技術を提供が可能となった。

プログラム自動生成装置で生成するプログラムの定義ファイル群、翻訳文字列の対象となるリソースファイルを抽出するプログラム、プログラム生成部の構成の一例を示す図である。 本発明の実施形態に係わる情報処理装置、アプリケーションサーバのハードウェア構成の一例を示すブロック図である。 開発者がアプリケーションを開発する際に、各種定義（入出力定義ファイル、メッセージ定義ファイルなど）を行うためのアプリケーション定義ＧＵＩの一例を示す図である。 プログラム自動生成装置で生成されたアプリケーションの一例として交通費申請リストの表示状態を示す図である。 アプリケーション定義ファイルの定義内容を説明するために使用する定義ファイルの一例である。 翻訳文字列の対象となるリソースファイルを抽出するプログラムのメインＧＵＩ（リソーステンプレート出力先指定ＧＵＩ）の一例を示す図である。 リソースキーとリソース値のペアが出力されたリソーステンプレートのファイル一例を示す図である。 リソース値が、英語に翻訳された英語リソースファイルの一例を示す図である。 本発明の実施形態に係わる翻訳対象となり得るリソースキーとリソース値（文字列）を取得するリソーステンプレート生成部のフローチャートである。 定義フォルダ内の各々の定義ファイルから翻訳対象となるリソースキーとリソース値（文字列）を取り出して、定義フォルダリソース一覧を生成する処理を説明するフローチャートである。 定義フォルダリソース一覧、定義ファイルリソース一覧、リソースキー、リソース値（文字列）がＲＡＭ上に記憶される際の構造の一例を示す図である。 メモリ上に構成されたリソースキーとリソース値（文字列）を対応付けてリソーステンプレートファイルに出力するフローチャートの一例を示す図である。 本発明の実施形態に係わるマルチ言語の中から特定の言語を用いてアプリケーションを動作させるフローチャートの一例を示す図である。 入出力定義内の翻訳対象タグを管理するテーブルの一例を示す図である。 翻訳対象のタグを取得するフローチャートの一例を示す図である。 プログラムソースコードへリソースキーを埋め込むフローチャートの一例を示す図である。 プログラムソースコードへリソースキーを埋め込んだ状態の一例を示す図である。 言語表示切り替えの動作の一例をアプリケーション画面とリソースファイルの関係を基に示した図である。 リソース値が重複する課題の一例を説明する図である。 データモデル定義と入出力定義の関係の一例を説明する図である。 重複リソースを検出してリソース一覧を生成する全体処理のフローチャートの一例を示す図である。 重複リソースを検出する処理を説明するフローチャートの一例を示す図である。 リソースキーに対応するグローバルリソースキーが重複するリソースか否かを管理するグローバルリソースマップの一例を示す図である。 リソースキーに対応するグローバルリソースキーを管理するグローバルリソースキー使用情報の一例を示す図である。 リソーステンプレートファイルに重複を考慮しリソースを出力するフローチャート一例を示す図である。 グローバルリソースを抽出するフローチャートの一例を示す図である。 グローバルリソースを抽出した一例を示す図である。 グローバルリソースに対応したリソースファイルテンプレートを出力するフローチャートの一例を示すである。 グローバルリソースに対応していない状態のリソースファイルテンプレートの一例を示す図である。 グローバルリソースに対応したリソースファイルテンプレートの一例を示す図である。

以下、本発明の実施の形態を、図面を参照して詳細に説明する。

図１は、プログラム自動生成装置で生成するプログラムの定義ファイル群、翻訳文字列の対象となるリソースファイルを抽出するプログラム、プログラム生成部の構成の一例を示す図である。

アプリケーション定義ファイル記憶部１１０は、図３で後述するアプリケーション定義ＧＵＩ（グラフィカルユーザインタフェース）で定義された、アプリケーションプログラムを自動生成するための定義を格納するための記憶部である。すなわち、アプリケーションを生成するための定義であるアプリケーション定義ファイルをアプリケーション定義ファイル記憶手段に登録する。

図１の例では、３つのアプリケーションの定義が格納されている。１つのアプリケーション定義１１１（ａ〜ｃ）は、１または複数の入出力定義ファイル１１２、メッセージ定義ファイル１１３、その他定義ファイル（１０４）等から構成されており、定義ファイルの種類毎に、異なるフォルダに格納されている。また、例えば１つの入出力定義ファイル１１２においては、アプリケーションのＧＵＩと、当該画面で入出力されるデータベースのデータ項目との対応などが定義されている。

例えばアプリケーションの定義は、クライアント端末で開発者が図３のＧＵＩを操作することで行い、アプリケーションプログラムの生成まで当該クライアント端末で行っても良い。その場合、当該クライアント端末にプログラムのファイル群が格納されても良い。また、クライアント端末からの指示によりアプリケーションプログラム自動生成のためのサーバにプログラムのファイル群が格納されても良い。以下、クライアント端末、アプリケーション自動生成サーバ（装置）のいずれの場合であっても、情報処理装置１００として説明する。

リソーステンプレート生成部１２０は、後述するリソースファイル記憶部１４１に格納されるファイルのうち、オリジナル言語に対応するファイルを、リソーステンプレートとして出力するための機能ブロック図である。これらの処理は図６から図１２を用いて詳述する。

リソーステンプレート出力先指定部１２１（図６の６００にて説明）は、マルチ言語化する１つのアプリケーションを指定し、そのアプリケーションに関連する定義ファイルから翻訳対象となる文字列を抽出するファイルの出力先を指定するＧＵＩである。

定義ファイル解析部１２２（図９、図１０のフローチャートで説明）は、指定されたアプリケーションの定義ファイルを解析する。具体的には、定義ファイル（例えばＸＭＬの階層データで記載されている）を解析して、必要な情報を抽出する。抽出した結果は、例えば図１１のようにメモリ上に展開される。

リソースキー生成部１２３、リソース値取得部１２４、リソーステンプレート出力部１２５（いずれも図１２のフローチャートで説明）は、定義ファイル解析部１２２で解析した結果（例えば図１１のメモリ上に展開した情報）から、リソースキーとリソース値を生成し、対応付けてリソーステンプレート（ファイル）に出力される。なお、原言語（例えば、本実施形態ではアプリケーション定義ファイルで定義に使用している「日本語」）は、リソーステンプレート出力部１２５（リソースファイル生成部）で出力した結果が、そのまま原言語（日本語）のリソースファイルとなる。

なお、リソースキー生成部１２３は、重複管理部１２６を含む。重複管理部１２６は、同一のリソース値が割り当てられるリソースキーを検出（リソース値の重複を検出）するための、条件を管理する箇所である。また、重複検出を行うか否かについての設定も行う。なお、重複については後述の第二の実施形態において説明を行う。

リソーステンプレートファイルは、図３のアプリケーション定義ＧＵＩで定義された入出力定義ファイル１１２、メッセージ定義ファイル１１３におけるリソース値（例えば日本語での表示文字列）を含む。そのファイルを日本語のリソースファイル１４２とする。

日本語のリソースファイル１４２、および必要に応じて人手により翻訳した他の言語リソースファイル（図１の例では、英語、中国語、韓国語など）をアプリケーションサーバ１４０のリソースファイル記憶部１４１に配置する。

プログラム生成部１３０は、アプリケーション定義ファイル記憶部１１０に記憶された入出力定義ファイル１１２、メッセージ定義ファイル１１３、その他定義ファイル１１４に基づき、アプリケーション１４３を生成する。その際に、生成されるプログラムにおけるリソース値（文字列）のかわりに、対応するリソースキーを埋め込む。詳細は図１６および図１７で説明する。

アプリケーション１４３は、アプリケーションサーバ１４０に配置された後、リソースファイル記憶部１４１に配置されたリソースファイル１４２を参照する。アプリケーション１４３が実行される際には、リソースファイル１４２から指定の言語のものを選択し、リソースキーは、対応するリソース値（文字列）に置き換えられて実行される。また必要に応じてリソースファイル１４２（言語）は切り替えられる。詳細は図１３および図１８で説明する。

図２は、本発明の実施形態に係わる情報処理装置、アプリケーションサーバのハードウェア構成の一例を示すブロック図である。

図２に示すように、情報処理装置１００、アプリケーションサーバ１４０は、システムバス２０４を介してＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）２０１、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）２０２、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）２０３、入力コントローラ２０５、ビデオコントローラ２０６、メモリコントローラ２０７、通信Ｉ／Ｆコントローラ２０８等が接続された構成を採る。 ＣＰＵ２０１は、システムバス２０４に接続される各デバイスやコントローラを統括的に制御する。

また、ＲＯＭ２０３あるいは外部メモリ２１１には、ＣＰＵ２０１の制御プログラムであるＢＩＯＳ（Ｂａｓｉｃ Ｉｎｐｕｔ／Ｏｕｔｐｕｔ Ｓｙｓｔｅｍ）やＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）や、各サーバあるいは各ＰＣが実行する機能を実現するために必要な後述する各種プログラム等が記憶されている。また、本発明を実施するために必要な情報が記憶されている。なお外部メモリはデータベースであってもよい。

ＲＡＭ２０２は、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。ＣＰＵ２０１は、処理の実行に際して必要なプログラム等をＲＯＭ２０３あるいは外部メモリ２１１からＲＡＭ２０２にロードし、ロードしたプログラムを実行することで各種動作を実現する。

また、入力コントローラ２０５は、キーボード（ＫＢ）２０９や不図示のマウス等のポインティングデバイス等からの入力を制御する。

ビデオコントローラ２０６は、ディスプレイ２１０等の表示器への表示を制御する。尚、表示器は液晶ディスプレイ等の表示器でもよい。これらは、必要に応じて管理者が使用する。

メモリコントローラ２０７は、ブートプログラム、各種のアプリケーション、フォントデータ、ユーザファイル、編集ファイル、各種データ等を記憶する外部記憶装置（ハードディスク（ＨＤ））や、フレキシブルディスク（ＦＤ）、あるいは、ＰＣＭＣＩＡ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ Ｍｅｍｏｒｙ Ｃａｒｄ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ａｓｓｏｃｉａｔｉｏｎ）カードスロットにアダプタを介して接続されるコンパクトフラッシュ（登録商標）メモリ等の外部メモリ２１１へのアクセスを制御する。

通信Ｉ／Ｆコントローラ２０８は、ネットワーク１０４を介して外部機器と接続・通信し、ネットワークでの通信制御処理を実行する。例えば、ＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）を用いた通信等が可能である。

尚、ＣＰＵ２０１は、例えばＲＡＭ２０２内の表示情報用領域へアウトラインフォントの展開（ラスタライズ）処理を実行することにより、ディスプレイ２１０上に表示することが可能である。また、ＣＰＵ２０１は、ディスプレイ２１０上のマウスカーソル（図示しない）等によるユーザ指示を可能とする。

本発明を実現するための後述する各種プログラムは、外部メモリ２１１に記録されており、必要に応じてＲＡＭ２０２にロードされることによりＣＰＵ２０１によって実行されるものである。さらに、上記プログラムの実行時に用いられる定義ファイルおよび各種情報テーブル等も、外部メモリ２１１に格納されており、これらについての詳細な説明についても後述する。

図３は、開発者がアプリケーションを開発する際に、各種定義（入出力定義ファイル、メッセージ定義ファイルなど）を行うためのアプリケーション定義ＧＵＩの一例を示す図である。

図３のアプリケーション定義ＧＵＩ３００においては、例としてアプリケーションがフォルダ、ＡＰＰＬＹ＿ＳＹＳＹＴＥＭにて開発されている（アプリケーションＩＤ「ＡＰＰＬＹ＿ＡＰＰ」、アプリケーション名「交通費申請アプリ」）。また、定義フォルダ表示欄３０１においては、定義フォルダが例えば「ｉｏ 入出力」、「ｍｓｇ メッセージ」などの定義ファイルの種類毎に用意されている。図３の例では、「ｉｏ 入出力」の中から「交通費申請リスト」の定義ファイル「ＡＰＰＬＹ＿ＬＩＳＴ」が選択されているが、定義ファイルは１つの画面に相当するものであり詳細は、詳細はファイル定義欄３０３に表示される。本実施形態の説明では、主に入出力定義ファイル「ＡＰＰＬＹ＿ＬＩＳＴ」を例として説明を進める。

ファイル定義欄３０３には、項目タイプ３０４、項目コード３０５、名前３０６などのデータ項目が表示されている。縦方向に複数行のデータが定義されているが、これらは１つの画面を構成する要素である。

項目タイプ３０４は、（該当する１行で定義される）データのタイプを表す。具体的には、アプリケーションのユーザにより入力される「入力」（Ｉ）、文字列を表示するための「出力」（Ｏ）、何らかの処理を実行するためのボタンなどを示す「アクション」（Ａ）などがある。

項目コード３０５は、「交通費申請リスト」の定義ファイル「ＡＰＰＬＹ＿ＬＩＳＴ」の中で該当する１行を一意的に特定するためのコードである。

名前３０６は、該当する行により定義される項目が「交通費申請リスト」画面において表示される際の文字列を定義する。例えば入力項目として「ステータス」（３０７）が表示されるように定義されている。

さらに、図３の例では、「ステータス」（３０７）の行がフォーカスされており、ファイル定義欄３０３の下側に、選択行詳細定義画面３０８が表示されている。選択行詳細定義画面３０８における選択リスト固定値３０９に選択肢を記載すると、対応する行はドロップダウンリストとなる。「ステータス」（３０７）の例では、「：すべて｜ｗａｉｔ＿ａｐｐｒｏｖｅ：承認待ち｜ｃｌｏｓｅｄ：完了」が指定されている。この定義は、デフォルトでは「すべて」（対応する項目コードなし）が表示されており、ユーザが「承認待ち」（対応する項目コードはｗａｉｔ＿ａｐｐｒｏｖｅ）、「完了」（対応する項目コードはｃｌｏｓｅｄ）を選択可能であることを示している。

以上で、図３のアプリケーション定義ＧＵＩ３００の構成と定義項目の内容についての説明を完了する。

図４は、プログラム自動生成装置で生成されたアプリケーションの一例として交通費申請リストの表示状態を示す図である。

交通費申請リスト画面４００は、画面のタイトル（４０１）、ドロップダウンリスト及び関連する項目（４０２）、データ項目の名前（４０３：「申請ＩＤ」〜「理由」など）、申請した交通費のデータ（４０３の下側の各行）から構成されている。

さらにドロップダウンリスト及び関連する項目（４０２）は、ドロップダウンリストのタイトルとなる文字列「ステータス」、ドロップリスト本体（デフォルトで「すべて」が表示されている）、ドロップダウンリストから項目選択後に押下するボタン（アクション「絞込み」）から構成されている。

また、Ａｐｐｌｉｃａｔｉｏｎ Ｌｉｓｔ画面４１０は、交通費申請リスト画面４００の英語版である。後述する方法でアプリケーション定義ファイルから、リソースファイルを生成し、人手により各国語に翻訳し、そのうちの日本語版（４００）、英語版（４１０）を表示したものが図４である。

図５は、アプリケーション定義ファイルの定義内容を説明するために使用する定義ファイルの一例である。本実施形態では、例としてＸＭＬ形式で構成されるが、あくまで一例であり他の形式で構成されていても良い。図３で説明した「ｉｏ 入出力」の中から「交通費申請リスト」に対応する入出力定義ファイル１１２に相当する。また、図４で説明した交通費申請リスト画面４００に相当する。図面の都合によりデータ項目およびデータ項目の内容のうち、一部を省略している。

５０２で囲まれた部分は、図３の「ｉｏ 入出力」のタイトル「交通費申請リスト」を定義する部分である。また図４の４０１に対応する。

また、図４の４０２（ドロップダウンリスト及び関連する項目）に対応する部分は、５０３、５０４で囲まれた部分で定義されている。ドロップダウンリストのタイトルとなる文字列「ステータス」は、５０３の「ｉｏ−ｉｔｅｍ」の「ステータス」（ｎａｍｅタグ）、ドロップダウンリスト本体は「ｃｈｏｉｃｅ−ｌｉｓｔ」タグ内の「ｆｉｘｅｄ」タグに記載された選択項目、ドロップダウンリストから項目選択後に押下するボタン（アクション「絞込み」）は５０４による。

さらに、５０５、５０６は、それぞれ図３の１行のデータ、図４の４０３の「申請ＩＤ」、「ステータス」に対応する項目の表示文字列の定義である。

以上で、定義ファイルの一例として、「交通費申請リスト」に対応する入出力定義ファイル１１２の一部について説明した。

図６は、翻訳文字列の対象となるリソースファイルを抽出するプログラムのメインＧＵＩ（リソーステンプレート出力先指定ＧＵＩ）の一例を示す図である。

対象アプリケーション６０１として、アプリケーションＩＤ「ＡＰＰＬＹ＿ＡＰＰ」、アプリケーション名「交通費申請アプリ」を指定している。具体的には、特定のアプリケーション（本例では「交通費申請アプリ」）として、図３の定義フォルダ表示欄３０１で一覧表示されている定義フォルダ群および定義フォルダ群に含まれる定義ファイル群を指定している。

また、出力先フォルダ６０２には、翻訳対象となるリソースキーとリソース値のペアを出力するリソーステンプレートファイルの出力先を指定する。出力先フォルダ６０２に出力ファイル名まで指定するようにしても良いし、フォルダだけ指定してファイル名はデフォルト値として生成されても良い。

図７は、リソースキーとリソース値のペアが出力されたリソーステンプレートのファイル一例を示す図である。図３の３０２、図４、図５で示すＡＰＰＬＹ＿ＬＩＳＴは、７００の部分に相当する。

アプリケーションの各種定義ファイル（入出力定義ファイル、メッセージ定義ファイルなど）が日本語で記載されているため、リソーステンプレートのファイルも日本語であり、そのまま日本語リソースファイルとして、アプリケーション実行時に使用される。

図８は、リソース値が、英語に翻訳された英語リソースファイルの一例を示す図である。図７の７００の部分は、例えば８００のように翻訳される。

＜第一の実施形態＞
次に図９から図１２を用いて、リソーステンプレート生成部１２０の処理と生成されるリソーステンプレートファイルの構造（図１１）について説明する。

図９は、本発明の実施形態に係わる翻訳対象となり得るリソースキーとリソース値（文字列）を取得するリソーステンプレート生成部１２０のフローチャートである。図９のフローチャートの各ステップは、情報処理装置１００上のＣＰＵ２０１で実行される。

Ｓ９０１においては、アプリケーションの定義フォルダ（例えば図３の３０１で一覧されるフォルダ群のすべて）を取得し、ＲＡＭ２０２における定義フォルダリスト記憶部（不図示）に格納する。

Ｓ９０２からＳ９０７における繰り返し処理では、前述の定義フォルダリスト記憶部に記憶された全定義フォルダに対する処理を繰り返す。

Ｓ９０３においては、定義フォルダリスト記憶部に記憶された全定義フォルダのうち、１つの定義フォルダに着目する。

Ｓ９０４においては、着目した定義フォルダが、翻訳対象となるリソースキーとリソース値（文字列）を取得する対象となるフォルダか否かを判定する。具体的には、定義フォルダに含まれる定義ファイルが翻訳対象となるかどうかであるが、フォルダ名が例えば図３の３０１の一覧のうち「ｉｏ 入出力」、「ｍｓｇ メッセージ」などの定義フォルダが翻訳対象となる定義ファイルを含む。「ｂｐ ビジネスプロセス」、「ｄｍ データモデル」などの定義フォルダには、翻訳対象となる定義ファイルを含まない。

いずれの定義フォルダが対象となるかは、リソーステンプレート生成部１２０のプログラムにロジックとして組み込まれていてもよいし、また翻訳対象定義フォルダ記憶部（不図示）に、翻訳対象となる定義フォルダ、あるいはならない定義フォルダの一覧として記憶されていても良い。着目中の定義フォルダが翻訳対象である場合（ＹＥＳの場合）には、Ｓ９０５に進む。翻訳対象でない場合（ＮＯの場合）には、Ｓ９０７に進む（次の定義フォルダがあればそのフォルダに対する処理を行う。なければ繰り返し処理を終了する）。

Ｓ９０５においては、定義フォルダ内の各々の定義ファイルから翻訳対象となるリソースキーとリソース値（文字列）を取り出して、定義フォルダリソース一覧を生成する。例えば、図３の定義フォルダ表示欄３０１の定義フォルダ「ｉｏ 入出力」には、「交通費申請フォーム」、「交通費申請リスト」など６つの定義ファイルが含まれるが、定義フォルダリソース一覧は、図１１の１１２０のようになる。更なる例として、定義フォルダ「ｍｓｇ メッセージ」の部分は、図１１の１１４０のようになる。詳細は、図１０のフローチャートにより説明する。

Ｓ９０６においては、定義フォルダリソース一覧を、アプリケーションリソース一覧（図１１の１１００に対応）に格納する。この場合、図１１の１１２０の定義フォルダリソース一覧の各要素「ＡＰＰＬＹ＿ＦＯＲＭ」、「ＡＰＰＬＹ＿ＬＩＳＴ」を、アプリケーションリソース一覧１１００にコピー（あるいは移動）などを行うことを想定しているが、もともと定義フォルダリソース一覧（１１２０など）とアプリケーションリソース一覧１１００が同一のＲＡＭ２０２上の記憶部であり、Ｓ９０６の処理が不要であるようにしても良い。

Ｓ９０８においては、アプリケーションリソース一覧１１００に格納した情報（翻訳対象となるリソースキーとリソース値（文字列））をファイルに出力する（詳細は図１２のフローチャートを用いて説明する）。出力するファイルは、図６のリソーステンプレート出力先指定ＧＵＩ６００の出力先フォルダ６０２で指定されたファイルである（図６の説明を参照）。
以上で、図９のフローチャートの処理の説明を完了する。

図１０は、定義フォルダ内の各々の定義ファイルから翻訳対象となるリソースキーとリソース値（文字列）を取り出して、定義フォルダリソース一覧を生成する処理を説明するフローチャートである。図１０のフローチャートの各ステップは、情報処理装置１００上のＣＰＵ２０１で実行される。

Ｓ１００１からＳ１０１２の繰り返し処理では、図９のＳ９０３にて着目した１つの定義フォルダに含まれる各々の定義ファイルに対して、処理を繰り返す。

Ｓ１００２においては、１つの定義ファイルに着目して内容を読み取る。ここで定義ファイルとは、例えば「ｉｏ 入出力」には、「交通費申請フォーム」、「交通費申請リスト」（図３の３０２）などであり、その内容は、図５のＸＭＬファイル（「交通費申請リスト」：ＡＰＰＬＹ＿ＬＩＳＴに対応する）のように定義されるものである。

Ｓ１００３においては、前述のＳ１００２において読み取った定義ファイル（本例ではＸＭＬファイル）を解析する。例えば、本実施形態におけるＸＭＬファイルの場合には、各情報に対応する要素はＸＭＬタグ要素として階層的に定義されているが、その構造を木構造（不図示）などでＲＡＭ２０２上に記憶する。以降、定義ファイルがＸＭＬファイルであり、各情報に対応する要素はＸＭＬタグ要素として階層的に定義されているとして説明するが、これはあくまで一例であり、同様の意味を定義できる構造であれば、例えば定義ファイルが表形式ファイルであって、ＲＡＭ２０２上ではリスト形式などで格納するなど、任意の構造であって良い。

Ｓ１００４からＳ１０１０の繰り返し処理では、ＸＭＬの先頭のタグ要素から最後のタグ要素まで、全てのタグ要素に対する繰り返し処理を行う。

Ｓ１００５においては、１つのタグ要素に着目する。以下、定義ファイルとして「ＡＰＰＬＹ＿ＬＩＳＴ」（図５のファイル）を例として説明を進める。また、以下の説明において、ＲＡＭ２０２上に記憶される定義フォルダリソース一覧、定義ファイルリソース一覧、リソースキー、リソース値（文字列）について図１１を用いてあわせて行う。

Ｓ１００６においては、着目中のタグ要素が翻訳対象となるタグ要素であるか否かを解析する。具体例を図５のＸＭＬファイル（ＡＰＰＬＹ＿ＬＩＳＴの定義ファイル）を参照し、幾つか挙げて説明する。

まず、リソース値（文字列）となるのは、ｎａｍｅタグに設定された値である。ｉｏタグ（５０１）の直下にあるタグを先頭から順に着目する。第１の例（点線（５０２）で囲まれた部分）においては、ｎａｍｅタグ（値は「交通費申請リスト」）が翻訳対象となるタグ要素であるかどうかを確認する。この場合には、同じくｉｏタグの直下にあるｉｏ−ｔｙｐｅタグの値を参照する。この値が、「ＩＯ」、「Ａ」、「Ｉ」のいずれかであれば、ｎａｍｅタグの値「交通費申請リスト」は翻訳対象となる。ここでは、ｉｏ−ｔｙｐｅの値が「ＩＯ」なので翻訳対象となる。ｎａｍｅタグ要素は、定義ファイル名およびルートタグから当該ｎａｍｅタグ要素に至るまでのタグ要素の階層により、一意的に「位置」を特定される。

第２の例（点線（５０３）で囲まれた部分）においては、ｉｏタグ（５０１）直下のｉｏ−ｉｔｅｍタグの内容を確認する。ｎａｍｅタグ（値は「ステータス」）のｉｔｅｍ−ｔｙｐｅタグの値を参照し、値が、「ＩＯ」、「Ａ」、「Ｉ」のいずれかであれば、ｎａｍｅタグの値「ステータス」は翻訳対象となる。ここでは、ｉｏ−ｉｔｅｍタグの値は「Ｉ」なので翻訳対象となる。同様に、ｎａｍｅタグの値、「絞込み」（５０４）、「申請ＩＤ」（５０５）、「ステータス」（５０６）も翻訳対象となる。

第３の例（点線（５０３）で囲まれた部分）においては、ｉｏ−ｉｔｅｍタグ、ｃｈｏｉｃｅ−ｌｉｓｔタグ、ｆｉｘｅｄタグ内の文字列（“｜”で区切られた文字から“：”を除く「すべて」、「承認待ち」、「完了」）も翻訳対象となる。ｉｏ−ｉｔｅｍタグ内のｉｏ−ｉｔｅｍタグの値が「Ｉ」である場合、その階層下にあるｃｈｏｉｃｅ−ｌｉｓｔタグ、ｆｉｘｅｄタグの中の文字列が翻訳対象になることによる。

これらの規則は、あくまで一例であり他の規則で指定されても良い。またこれらの規則は、リソーステンプレート生成部１２０のプログラムに組み込まれていてもよいし、あるいは規則記憶部に定義されており、その中に翻訳対象となる文字列にたどり着くまでのタグの階層が記載されていても良い。

例えば、翻訳対象の文字列を示すタグの階層構造については、プログラムロジックとして記述しても良いし、図１４に示すようにタグ階層構造を示すテーブルで管理しても良いこととする。この例のテーブルではレコードにある階層の組み合わせが翻訳対象となる。なお、図１４の１４０１は翻訳対処となるタグの階層構造を管理するＩＤであり、１４０２は第一階層であるタグの値、１４０３は第二階層であるタグの値、１４０４は第三階層であるタグの値、１４０５は第四階層であるタグの値が入る項目となる。

図１５は翻訳対象となるタグ要素であるか否かを判定するフローチャートである。

Ｓ１５０１ではＸＭＬで記載されたアプリケーション定義ファイル（画面である場合は入出力定義）をプログラムで扱いやすいように定義オブジェクトリストの形に変換して、メモリ上に読み込む。

Ｓ１５０２からＳ１５０５は、定義オブジェクトリストが存在する分の繰り返し処理を行う。

Ｓ１５０２では定義オブジェクトを階層化して、タグとして階層情報に変換する。

Ｓ１５０３では、図１４の翻訳対象テーブルを参照し、階層情報とテーブル内のレコードが一致するか確認する。Ｓ１５０３で一致すると判定した場合は、Ｓ１５０４へ処理を進める。Ｓ１５０３で一致すると判定しなかった場合、次の定義オブジェクトリストの処理を行うため、Ｓ１５０２に処理を戻す。また、タグの階層の位置およびタグの種別により、指定した言語の文字列に置き換えて表示する翻訳対象文字列を特定する。

Ｓ１５０４では特定の定義値が条件を満たすか確認する。例えば、ｎａｍｅタグと同階層にある、ｉｏ−ｉｔｅｍやｉｔｅｍ−ｔｙｐｅタグの値が「ＩＯ」（入出力項目）、「Ａ」（ボタンなどのアクション項目）、「Ｉ」（入力項目）であるかどうかで判定する。Ｓ１５０４で条件を満たすと判定した場合、Ｓ１５０５へ処理を進める。Ｓ１５０４で条件を満たすと判定しなかった場合、次の定義オブジェクトリストの処理を行うため、Ｓ１５０２に処理を戻す。

例えば、図５の点線（５０２）で囲まれた部分は、Ｓ１５０４においては、図１４の翻訳対象テーブルでいうと、ＩＤが１のレコード（第一階層が「ｉｏ」、第二階層が「ｎａｍｅ」）に合致がする。また、Ｓ１５０４においては、ｉｏ−ｔｙｐｅタグの値が「ＩＯ」であるため、翻訳対象となる。すなわち、ソースプログラムの動作時に翻訳対象となる翻訳対象文字列をアプリケーション定義ファイルから特定する。

Ｓ１５０５では、Ｓ１５０３とＳ１５０４の条件を満たす定義オブジェクトを翻訳対象定義オブジェクトのリスト（図１１に対応）に格納する。

以上の処理を行うことによって、翻訳対象定義オブジェクトのリストを確認すれば、翻訳対象の定義を読み出すことができる。

以上で、リソース値（文字列）として翻訳対象になるか否かの解析について説明した。

Ｓ１００７においては、Ｓ１００６における解析の結果、着目中のタグ要素が翻訳対象であるか否かを判断する。具体的には、Ｓ１００６で詳細に説明したようにｎａｍｅタグと同一階層にあるｉｏ−ｔｙｐｅタグ、またはｉｔｅｍ−ｔｙｐｅタグの値が「ＩＯ」、「Ａ」、「Ｉ」であるか否かにより判定する。また、ｃｈｏｉｃｅ−ｌｉｓｔタグ、ｆｉｘｅｄタグに含まれる値（文字列）は、１つ上位のｉｏ−ｉｔｅｍタグ内のｉｏ−ｉｔｅｍタグの値により同様に判定する。判定の結果、ｎａｍｅタグの値が翻訳対象である場合（ＹＥＳの場合）には、Ｓ１００８に進む。翻訳対象でない場合（ＮＯの場合）には、Ｓ１０１０に進む。

Ｓ１００８においては、翻訳対象となるリソース値に至までのＸＭＬのタグ要素の階層を、ＲＡＭ２０２上などの記憶部である定義ファイルリソース一覧に追加する。具体例として、上記Ｓ１００６で解析され翻訳対象と判定された３つの例を用いて説明する。

第１の例の値「交通費申請リスト」の場合においては、ｃｏｄｅタグの値「ＡＰＰＬＹ＿ＬＩＳＴ」と同一階層にあるため、まず、定義ファイルリソース一覧に「ＡＰＰＬＹ＿ＬＩＳＴ」を追加（１１２３）する。その後、ｉｏタグを「ＡＰＰＬＹ＿ＬＩＳＴ」に結合する（１１２４）。「ＡＰＰＬＹ＿ＬＩＳＴ」は、ｉｏタグの直下にあり以降の処理ではタグ要素を結合するためのルート要素となる。

第２の例の値「ステータス」の場合においては、同一階層（「ステータスを値とするｎａｍｅタグと同じｉｏ−ｉｔｅｍタグの中に定義された）ｃｏｄｅタグの値が「ＩＮＰＵＴ」であるため、前述の「ＡＰＰＬＹ＿ＬＩＳＴ」（１１２４）に、「ｉｏ−ｉｔｅｍ」（１１２６）、「ＩＮＰＵＴ」（１１２７）を順に結合する。「絞込み」については、前述の「ＡＰＰＬＹ＿ＬＩＳＴ」（１１２４）、「ｉｏ−ｉｔｅｍ」（１１２６）が既にあるため新たに作成せず、「ｉｏ−ｉｔｅｍ」（１１２６）に、対応するｃｏｄｅタグの値「ＦＩＬＴＥＲ」を結合する。

同様に、「申請ＩＤ」については、「ｉｏ−ｉｔｅｍ」（１１２６）に、対応するｃｏｄｅタグの値「ＩＤ」を、「ステータス」については、「ｉｏ−ｉｔｅｍ」（１１２６）に、対応するｃｏｄｅタグの値「ＳＴＡＴＵＳ」を結合する。第２の例ではｉｏタグに対応する要素は結合しなかったが、最終的にリソース値が一意に特定できるように記憶されればよい。従って、図１１はあくまで例であって、一意的にリソース値の位置を特定可能な範囲で異なる構造であっても良い。第１の例、第２の例においても同様である。以上により、第２の例の説明を完了する。

第３の例の場合には、ｃｈｏｉｃｅ−ｌｉｓｔタグ、ｆｉｘｅｄタグの階層下にある文字列として、リソース値はドロップダウンリストなどの文字列であると判断される（図４の４０２の中央の項目）。ｆｉｘｅｄタグがＩＮＰＵＴタグと同一階層のタグよりも１つ下の階層にあるため、図１１の「ＩＮＰＵＴ」（１１２７）に「ｆｉｘｅｄ」（１１２９）を結合する。

「ｆｉｘｅｄ」（１１２９）の階層化にはｆｉｘｅｄタグ内の文字列で“｜”で区切られた文字から“：”を除く「すべて」、「承認待ち」、「完了」をそれぞれ翻訳対象とするため、ドロップダウンリストの各選択要素となる「すべて」、「承認待ち」、「完了」を特定するためのタグを生成する。具体的には、“｜”で区切った後、「タグ：リソース値」となるようにする。「すべて」に対しては、“：”よりも前のタグがないため、「ｎｕｌｌ」（１１３０）というタグを生成し、「ｆｉｘｅｄ」（１１２９）に結合する。同様に、「ｗａｉｔ＿ａｐｐｒｏｖｅ：承認待ち」から「ｗａｉｔ＿ａｐｐｒｏｖｅ」を、「ｃｌｏｓｅｄ：完了」から「ｃｌｏｓｅｄ」を抽出して、「ｆｉｘｅｄ」（１１２９）に結合する。以上により第３の例の説明を完了する。また、Ｓ１００８の説明を完了する。

Ｓ１００９においては、Ｓ１００８で結合したタグ要素の階層の末端に対応するｎａｍｅタグの値をリソース値（文字列）として結合する。

なお、メッセージ要素については、各メッセージを特定するタグがあるため、そのタグを定義ファイルリソース一覧に格納し、そこに「ｍｓｇ」、末端にメッセージ本体を結合する。例として、図１１の点線（１１４０）における「ＩＮＳＥＲＴ＿ＦＡＩＬ」により特定されるタグ（１１４１）、「ｍｓｇ」（１１４２）、「申請ＩＤ：｛１｝申請失敗しました。」（１１４３）を結合する。なお、１１４３における「｛１｝」は、動作時の状態において異なる文字列が代入されるための定義である。

Ｓ１０１１においては、定義ファイルリソース一覧（ＡＰＰＬＹ＿ＬＩＳＴの例では図１１の１１２２に対応）を、定義フォルダリソース一覧（「ｉｏ 入出力」フォルダの例として図１１の１１２０に対応）に格納する。この場合、図１１の１１２２の定義ファイルリソース一覧の各要素を、定義フォルダリソース一覧１１２０にコピー（あるいは移動）などを行うことを想定しているが、もともと定義ファイルリソース一覧１１２２と定義フォルダリソース一覧１１２０が同一のＲＡＭ２０２上の記憶部であり、Ｓ１０１１の処理が不要であるようにしても良い。

以上で、図１０のフローチャートの処理の説明を完了する。また、以上で、図９、図１０のフローチャートの処理（Ｓ９０８の詳細を除く）と、当該処理で生成される図１１の構成についての説明を完了する。

図１２は、メモリ上に構成されたリソースキーとリソース値（文字列）を対応付けてリソーステンプレートファイルに出力するフローチャートの一例を示す図である。具体的には、図１１で説明した構成を、図７の形式のファイルに出力する処理の説明である。

Ｓ１２０１においては、出力先のファイルを生成する。このファイルが、リソーステンプレートファイルとなり、本実施形態においては、オリジナルのアプリケーション定義ファイル（図１の１１０、図３の定義フォルダ表示欄３０１内のファイル群など）における文字列（リソース値）が日本語で定義されているため日本語のリソースファイル１４２が出力されるためのファイルである。

Ｓ１２０２からＳ１２１１においては、アプリケーションリソース一覧（図１１の１１１１）に格納されたリソース値に対する処理を繰り返す。
Ｓ１２０３においては、１つのリソース値に着目する。

Ｓ１２０４からＳ１２０９の繰り返し処理においては、ルートのタグ要素からその結合の末端である着目中のリソース値までを用いて、リソースキーとリソース値の対応付けを生成する。例として、図１１の１１２２の部分から、図７の７００の部分が生成される処理として説明する。

Ｓ１２０５においては、処理対象がいずれのタグ要素であるか、またリソース値（文字列）であるかを判定する。判定結果によって、Ｓ１２０６からＳ１２０８のいずれかの処理が行われる。ルートの直下のタグ要素Ｓ１２０６に進む具体例としては、図１１のアプリケーションリソース一覧１１００に直接格納されているタグ要素「ＡＰＰＬＹ＿ＬＩＳＴ」（１１２３）の直下のｉｏタグ（１１２４）、ｉｏ−ｉｔｅｍ（１１２６）などのタグ要素の場合である。末端に結合されているリソース値（文字列）（例えば１１３１）であれば、Ｓ１２０８に進む。それ以外の場合にはＳ１２０７に進む。

Ｓ１２０６においては、リソースキーの最初のキーとしてルートのタグ要素の直下（前述の通り、ｉｏタグ（１１２４）、ｉｏ−ｉｔｅｍ（１１２６）などのタグ）を設定する。これが、リソースキーの先頭となる。ただしｉｏ−ｉｔｅｍは、便宜上「ｉｏＩｔｅｍ」に置き換えられているが、あくまで一例であり、必ずしも置き換える必要はない。

Ｓ１２０７においては、定義ファイル一リソース覧のルートタグと処理対象のタグを結合する。具体的には、オリジナルの定義ファイル「ＡＰＰＬＹ＿ＬＩＳＴ」に対応する場合には、定義ファイル一覧のルートタグとして「ＡＰＰＬＹ＿ＬＩＳＴ」が指定されているので、Ｓ１２０６で設定したタグ要素に“．”区切りで結合する。これにより、例えば「ｉｏ．ＡＰＰＬＹ＿ＬＩＳＴ」、「ｉｏＩｔｅｍ．ＡＰＰＬＹ＿ＬＩＳＴ」などのタグ要素の結合されたリソースキーができる。

Ｓ１２０７においては、同様にタグ要素の後にタグ要素がある場合はＳ１２０７の結合処理が繰り返され、Ｓ１２０６でルートとした図１１のタグ要素の後のタグ要素を結合する。「ｉｏＩｔｅｍ．ＡＰＰＬＹ＿ＬＩＳＴ．ＩＮＰＵＴ」（図１１の１１２６、１１２３、１１２７の結合）ができる。すなわち、翻訳対象文字列の翻訳語となるリソース値を取得するためのキーとなるリソースキーを生成する。また、アプリケーション定義ファイルのタグの階層における位置の情報および前記タグの種別を用いて、一意的に認識可能に前記リソースキーを生成する。

図１１の「ｆｉｘｅｄ」タグは、「ＡＰＰＬＹ＿ＬＩＳＴ」の直下ではないが、翻訳対象を特定するため直下と同様の処理対象となる。ｆｉｘｅｄの代わりに「ｆｉｘｅｄＬｉｓｔ」と置き換え、上記の処理同様「ＡＰＰＬＹ＿ＬＩＳＴ」と（ｉｏ−ｉｔｅｍはスキップして）「ＩＮＰＵＴ」タグを結合する。結果として「ｆｉｘｅｄＬｉｓｔ．ＡＰＰＬＹ＿ＬＩＳＴ．ＩＮＰＵＴ」などのタグ要素が結合されたリソースキーが生成できる。

上記の中で、「ｉｏ−ｉｔｅｍ」を「ｉｏＩｔｅｍ」に置き換えたり、「ｆｉｘｅｄ」をルートとしたり、またその処理をする際に「ｉｏ−ｉｔｅｍ」をスキップしたりしたが、これはあくまで一例である。必ずしもその通りの生成方法ではなくとも、結果として、異なるリソース値が一意に特定されるようにリソースキーが生成されるものであればよい。

さらに、ｆｉｘｅｄＬｉｓｔの場合には、各選択項目が区別できるように、「ｗａｉｔ＿ａｐｐｒｏｖｅ」（承認待ちの場合）、「ｃｌｏｓｅｄ」（完了の場合）を“．”で区切って結合する。「すべて」の場合は、対応するキー文字列がないため“．”のみを結合する。

以上で、Ｓ１２０６に始まり、Ｓ１２０７を繰り返すことによるリソースキーの生成について説明した。以上がリソースキーの生成に関する説明である。

次にリソース値の結合に関する説明を行う。Ｓ１２０８においては、処理対象がリソース値である場合に、その処理対象に対応するリソースキー（複数のタグ要素が“．”で結合されたもの）に「＝リソース値（文字列）」を結合する。具体的には、リソース値（文字列）は、図１１の構造の末端にあるため、リソース値（文字列）であると判断される。これにより「リソースキー」＝「リソース値」の対応付けが完成する。すなわち、生成されたリソースキーに対応する翻訳語となるリソース値を翻訳対象文字列から取得する。

Ｓ１２１０においては、「リソースキー」＝「リソース値」の対応付けをリソーステンプレートファイルに出力する。すなわち、リソースキーとリソース値を対応付けて、言語リソースファイルに出力する。出力結果の具体例は、図７のようになる。特に定義ファイル「ＡＰＰＬＹ＿ＬＩＳＴ」に対応するものは、点線（７００）で囲まれた部分である。

以上で、図１２のフローチャートの説明を完了する。なお、リソーステンプレートファイルは、アプリケーション定義と同じ言語（例えば日本語）であれば、そのまま（日本語の）リソースファイル１４２として使用可能である。その他の言語に関しては、本フローチャートで出力されたリソーステンプレートファイルをもとに、リソース値の部分を翻訳する。

以上、図７、図９〜図１２を用いて、リソーステンプレートファイルを生成する処理と、その生成結果についての説明を完了する。

図１３は、本発明の実施形態に係わるマルチ言語の中から特定の言語を用いてアプリケーションを動作させるフローチャートの一例を示す図である。図１２までの説明で生成された各言語のリソースファイルを用いて、マルチ言語のアプリケーションを実行する処理について説明する。図１３のフローチャートの各ステップは、アプリケーションサーバ１４０上のＣＰＵ２０１で実行される。

なお図１のプログラム生成部１３０で説明したように、アプリケーション１４３を生成する際に、前述の処理と同様にリソースキーが生成され、生成されるプログラムにおけるリソース値（文字列）のかわりに、対応するリソースキーが埋め込まれている必要がある。

その、対応するリソースキーの埋め込みの処理は、プログラム自動生成装置が画面プログラム（例えばＪＳＰ）を生成する際に行う。その処理については、図１６のＪＳＰへのリソースキーを埋め込む処理図において、説明を行う。

Ｓ１６０１において、例えば画面の入出力定義（例えば、図５）をメモリ内へ読み込む。画面の入出力定義はＸＭＬ構造で作成されていて、これをプログラムで扱いやすいようにオブジェクトに変換してメモリ内に格納する。

続いて、Ｓ１６０２において、プログラム自動生成装置が保持するＪＳＰテンプレートを読み込む。ＪＳＰテンプレートとは後続の処理でリソースキーを埋め込む変数を保有するＪＳＰの元となるファイルである。画面定義の中において翻訳対象となる各項目分、ＪＳＰテンプレートを使用して、変数に適切な値をＪＳＰテンプレートに対し埋め込むことで、最終的なＪＳＰが完成する。

ＪＳＰテンプレートの１例を図１７、１７００に示す。図１７、１７００のＪＳＰテンプレートには＜ｌａｂｅｌ＞タグがあり、そのリソースキー化を行う部分には＜％＝ＭｅｓｓａｇｅＲｅｓｏｕｒｃｅｓＰｒｏｐｅｒｔｉｅｓ．ｇｅｔＣｏｎｆｉｇ（）．ｇｅｔＦｏｒｍａｔＭｅｓｓａｇｅ（“ＩｏＩｔｅｍ．＄｛ｉｏ．ｃｏｄｅ｝．＄｛ｉｏＩｔｅｍ．ｃｏｄｅ}”）％＞といった記述がなされている。

＜％＝ＭｅｓｓａｇｅＲｅｓｏｕｒｃｅｓＰｒｏｐｅｒｔｉｅｓ．ｇｅｔＣｏｎｆｉｇ（）．ｇｅｔＦｏｒｍａｔＭｅｓｓａｇｅ（“ＩｏＩｔｅｍ．＄｛ｉｏ．ｃｏｄｅ｝．＄｛ｉｏＩｔｅｍ．ｃｏｄｅ}”）％＞の中のＩｏＩｔｅｍ．＄｛ｉｏ．ｃｏｄｅ｝．＄｛ｉｏＩｔｅｍ．ｃｏｄｅ}の部分は、リソースキー化する部分であり、ＭｅｓｓａｇｅＲｅｓｏｕｒｃｅｓＰｒｏｐｅｒｔｉｅｓ．ｇｅｔＣｏｎｆｉｇ（）．ｇｅｔＦｏｒｍａｔＭｅｓｓａｇｅ（“ＩｏＩｔｅｍ．＄｛ｉｏ．ｃｏｄｅ｝．＄｛ｉｏＩｔｅｍ．ｃｏｄｅ}”）はリソースキーに該当する文字列を該当するリソースファイルから取得するためのＡＰＩロジックである。

該当するリソースキーはこの例では入出力コードの＄｛ｉｏ．ｃｏｄｅ｝、および入出力項目コードの＄｛ｉｏＩｔｅｍ．ｃｏｄｅ}の組み合わせによって作成され、埋め込まれる（Ｓ１６０３）。なお、このＡＰＩの例では、言語コードはセッションなどのメモリ内にセットされている言語コードを参照するため、言語コードについてはＡＰＩの引数には出てこないが、もちろん、リソースキーと共に直接言語コードを指定できるＡＰＩを用意しても良いこととする。

なお、図１７、１７００のリソーステンプレートファイルはあくまで一例であり、ｄｉｖタグとｌａｂｅｌタグで構成される要素についてのテンプレートであって、別のタグで作成されている項目に適用するためのテンプレートファイルは別のテンプレートを用意することで対応をすることとする。また、＜％＝ＭｅｓｓａｇｅＲｅｓｏｕｒｃｅｓＰｒｏｐｅｒｔｉｅｓ．ｇｅｔＣｏｎｆｉｇ（）．ｇｅｔＦｏｒｍａｔＭｅｓｓａｇｅ（“ＩｏＩｔｅｍ．＄｛ｉｏ．ｃｏｄｅ｝．＄｛ｉｏＩｔｅｍ．ｃｏｄｅ}”）％＞の中のリソースキー化する部分となる（“ＩｏＩｔｅｍ．＄｛ｉｏ．ｃｏｄｅ｝．＄｛ｉｏＩｔｅｍ．ｃｏｄｅ}”）についても、別のリソースキーの構造で作成されても良いこととする。例えば、図７の７００に記載のリソースキーの中にｆｉｘｅｄＬｉｓｔ．ＡＰＰＬＹ＿ＬＩＳＴ．ＬＡＮＧ．ｊａがあるが、この形式のリソースキーは、プルダウンで固定値リストを表示するための項目であるため、データを表示するための項目である申請ＩＤとはキーの作成の仕方が異なる。このように、項目においては、項目タイプによってリソースキーの構成を異なるように作成しても良いこととする。

図１６の説明に戻る。し、入出力定義の読み込み（Ｓ１６０１）によって、得られた入出力項目で、翻訳対象となっている入出力項目が存在する間、その入出力項目に対し、Ｓ１６０３の処理を繰り返す。

Ｓ１６０４では、入出力項目の情報から入出力コードおよび入出力項目コードの情報を得て、図１７、１７００に示すＪＳＰテンプレートの変数部分＄｛ｉｏ．ｃｏｄｅ｝および＄｛ｉｏＩｔｅｍ．ｃｏｄｅ｝に埋め込むことによりＪＳＰを生成する。すなわち、アプリケーションの実行時に、指定した言語のリソースファイルに存在する、リソースキーに対応するリソース値を用いることにより、当該アプリケーションの翻訳対象文字列を指定した言語の文字列で表示可能にするために、ソースプログラムの翻訳対象文字列となる箇所に、言語表示を切り替えるためにリソースキーを埋め込んだプログラムを生成する。

例えば、図１７、１７１０は、項目ラベルの文字列を出力するＪＳＰのコードの一例である。図１７、１７１０の１７０２は、ＪＳＰのコードにおいてにおいて、ｉｏＩｔｅｍ．ＡＰＰＬＹ＿ＦＯＲＭ．ＩＤというリソースキーが埋め込まれている箇所である。

「ｉｏＩｔｅｍ．ＡＰＰＬＹ＿ＦＯＲＭ．ＩＤ」のうち、「ＡＰＰＬＹ＿ＦＯＲＭ」の部分は入出力コードである図３の３０２のより値を取得しており、「ＩＤ」の部分は入出力項目コードである、図３の３０５の項目コードから値を取得している。

なお、このリソースキーが、図１７、１７２０（図７の７００と同様）の１７０３、または、図１７、１７３０（図８の８００と同様）の１７０４で示したように、リソースファイルの中の同一のキーを参照することによって、そのリソーキーに対応するリソース値を取得することにより、言語切り替え処理を行う。

例えば、図１７、１７１０の１７０２の「ｉｏＩｔｅｍ．ＡＰＰＬＹ＿ＦＯＲＭ．ＩＤ」のリソースキーで、画面を日本語表示にしたい場合は、図１７、１７２０の日本語のリソースファイルの１７０３のリソースキー「ｉｏＩｔｅｍ．ＡＰＰＬＹ＿ＬＩＳＴ．ＩＤ」を参照し、そのリソース値の「申請ＩＤ」で表示を行う。

また、画面を英語表示にしたい場合は、図１７、１７３０の英語のリソースファイルの１７０４のリソースキー「ｉｏＩｔｅｍ．ＡＰＰＬＹ＿ＬＩＳＴ．ＩＤ」を参照し、そのリソース値の「Ａｐｐ ＩＤ」で表示を行う。すなわち、オペレーティングシステム、ブラウザの言語設定、ユーザの指定、生成されたソースプログラム、のいずれかにより指定された当該ソースプログラムの動作時の言語コードに対応付けられた言語リソースファイルを参照してソースプログラムに配置されたリソースキーにリソース値を対応付けて動作し、言語コードが異なる言語コードに切り替えられた場合には、異なる言語コードに対応するリソースファイルを参照して当該ソースプログラムに配置された当該リソースキーに当該リソース値を対応付けて動作するように切り替えるソースプログラムを生成する。

以上、生成するプログラムに対応するリソースキーを埋め込む処理の説明とする。

再び、図１３の処理の説明を行う。Ｓ１３０１においては、ユーザによりアプリケーションが起動される。本実施形態では、クライアント端末とアプリケーションサーバ１４０が異なる筐体であるとして説明しているが、実際には、同一の筐体で動作していても良い。

Ｓ１３０２においては、アプリケーションが動作する言語コードを取得する。具体的には、ＯＳが動作している言語設定、あるいはアプリケーションが動作しているＷｅｂブラウザの言語設定、またユーザが明示的に言語を指定した場合（図４の「言語」右にあるドロップダウンリストによる指定）、その言語コードを取得する。

Ｓ１３０３においては、取得された言語コードに応じたリソースファイルを読込む。ここで、言語コードとリソースファイルの対応付けは、アプリケーション内に組み込まれていてもよいし、また、言語コード記憶部（不図示）に対応付けを記憶しておき、必要に応じて言語ファイル対応機億部を言語コードで検索してリソースファイルを特定しても良い。アプリケーションに組み込まれている場合には、例えば、図３の３０１における「言語コード管理」に人手で定義を行い、図４の「言語」の右側のドロップダウンリストに必要な言語リストを用意して言語コードとリソースファイルの対応付けを記憶することが可能である。

Ｓ１３０４においては、アプリケーション内のリソースキーに対応するリソース値をリソースファイルから取得し、設定する。詳細を、Ｓ１３１１からＳ１３１４のサブフローチャートにより説明する。

Ｓ１３１１においては、前述で取得したリソースファイルに対応するリソース機があるか否かを判定する。リソースキーがある場合（ＹＥＳの場合）は、Ｓ１３１２に進む。ない場合（ＮＯの場合）は、Ｓ１３１３に進む。

Ｓ１３１２においては、リソースファイルからリソースキーに対応するリソース値を取得する。

Ｓ１３１３においては、アプリケーション定義ファイル（入出力定義ファイル、メッセージ定義ファイルなど）から、リソースキーに対応する文字列を抽出する。すなわち、ソースプログラムの動作時に、ソースプログラムに配置されたリソースキーが言語リソースファイルの中に存在しない場合には、アプリケーション定義ファイルを参照し、当該リソースキーに対応する当該アプリケーション定義ファイルにおける翻訳対象文字列を特定し、当該リソースキーに対応する文字列をリソース値として取得する。もともとリソースキーは、アプリケーション定義ファイルにしたがって、一意的にリソース値（文字列）の位置を特定できるように生成されているので対応するリソース値（文字列）を取得することが可能である。

Ｓ１３１４においては、Ｓ１３１２またはＳ１３１３において取得した文字列をリソース値として動作しているアプリケーションのリソースキーに設定する。

Ｓ１３０５においては、前記リソース値によりアプリケーション画面の表示を行う。

Ｓ１３０６においては、アプリケーションに対するユーザの操作指示を受け付ける。

Ｓ１３０７においては、前述の操作指示内容を判定する。操作内容が「終了指示」の場合には、アプリケーションを終了する。現在表示されている画面内で、言語切り替え以外の操作をした場合には、Ｓ１３０６に戻って操作を継続する。画面移行操作の場合には、Ｓ１３０４に戻って、その画面に含まれるリソースキーに対応するリソース値を取得して画面表示を行う。言語切り替え操作（図４の言語の後のドロップダウンリストで他の言語を選んで変更ボタンを押下）をユーザが行った場合には、Ｓ１３０２に戻り新たに指定された言語コードに対応するリソースファイルを読み込んで、画面の再表示をする。
以上で、図１３のフローチャートの説明を完了する。

続いて、図１８を用いて図１３の処理を詳しく説明する。図１８、１８００はアプリケーション画面の一例である。

言語選択のドロップダウン選択（図１８、１８１０）と選択言語に合わせた画面を表示するための表示ボタン（図１８、１８２０）、ユーザＩＤとユーザ名（図１８、１８３０）（英語の場合はＵｓｅｒ ＩＤ、Ｕｓｅｒｎａｍｅと表示する）をラベルとして持つ入力フィールドがある。

言語選択ドロップダウンからユーザが任意の言語を選択すると、図１８の１８４０に図示するように、言語コードパラメータとして、ｊａ、ｅｎ、ｚｈなどの言語コードがリクエストとしてアプリケーションサーバに送信される。

アプリケーションサーバはリクエストされた言語コードをセッションなどのメモリ内に格納する。次にアプリケーションサーバは表示リクエストに従い、ＪＳＰを画面として表示する。

ＪＳＰで作成した画面にはユーザＩＤ、ユーザ名のフィールド（図１８、１８５０）があり、それぞれのラベル（図１８、１８３０）にはリソースキーとして、ｉｏＩｔｅｍ．ＡＰＰＬＹ＿ＦＯＲＭ．ＵＳＥＲＩＤ、ｉｏＩｔｅｍ．ＡＰＰＬＹ＿ＦＯＲＭ．ＵＳＥＲＮＡＭＥが割り当てられているとする。

ＪＳＰの画面を表示する時には、言語コードの情報から対象となる言語リソースファイルを特定し、リソースキーの情報からその言語リソースファイル内のリソースキーに該当する値を取得し、ＪＳＰに表示する。

例えば、言語選択ドロップダウン（図１８、１８１０）からユーザが英語を選択すると、言語コード（図１８、１８４０）として「ｅｎ」がアプリケーションサーバへ送信され、図１８、１８６０のＡｐｐｌｉｃａｔｉｏｎＲｅｓｏｕｒｃｅｓ＿ｅｎ.ｃｏｎｆを対象となる言語リソースファイルとして使用することになる。

なお、ＡｐｐｌｉｃａｔｉｏｎＲｅｓｏｕｒｃｅｓのサフィックスに英語ならｅｎをつけてファイルがあるかを探索し、あればそれを表示するが、無い場合は、デフォルト値で表示するリソースファイルを表示する。例えば、図１８、１８７０に図示のＡｐｐｌｉｃａｔｉｏｎＲｅｓｏｕｒｃｅｓ．ｃｏｎｆがデフォルト値で表示するリソースファイルであるという設定であれば、こちらのファイルを使用して表示する。

なお、対応する言語リソースファイルが読み込めるか否かは、ユーザが例えばｊａやｅｎなどの言語コードを送信したなどのアクション以外の方法においては、ＯＳの言語設定やブラウザの言語表示設定によっても、判断可能であることとする。

以上で図１８の説明を終了する。
＜第二の実施形態＞

続いて、本発明の第二の実施形態を、図面を参照して説明する。第一の実施形態では、アプリケーションの画面定義の中より、翻訳対象となるリソースキーを翻訳語となるリソース値とともに抽出するまでを説明したが、アプリケーションの規模が大きくなり画面定義が増えると、異なるリソースキーに対して、同じ翻訳を行う箇所となるリソース値が重複して発生した場合に、無駄な翻訳作業が発生する可能性がある。

図１９の１９００は例として、従業員を管理するＥＭＰＬＯＹＥＥテーブル１９００（従業員テーブル）を示している。このテーブルは、ＩＤ（社員番号）、ＮＡＭＥ（社員名）、ＰＡＳＳＷＯＲＤ（社員パスワード）の項目からなるテーブルである。

このＥＭＰＬＯＹＥＥテーブル１９００のデータがいくつかの異なる画面で利用されることとする。例えば、図１９の１９１０は従業員を登録する画面の例である。図１９の１９２０は登録した従業員を検索し、一覧表示する画面の例である。図１９の１９３０は従業員を選択肢として選ぶ画面の例である。いずれも従業員テーブルのデータを利用した画面である。つまり、各画面における社員ＩＤ、社員名、社員パスワードの項目は、ＥＭＰＬＯＹＥＥテーブル１９００を構成する項目であるＩＤ、ＮＡＭＥ、ＰＡＳＳＷＯＲＤからなるものとする。

このような場合、各画面で使われる、ＩＤ（社員番号）、ＮＡＭＥ（社員名）、ＰＡＳＳＷＯＲＤ（社員パスワード）は各画面で同じ翻訳がされても良い箇所である。しかしながら、第一の実施形態によりリソースファイルを作成すると、画面や項目が画面定義上異なるため、異なるリソースとして扱う。そのため、異なるリソースキーごとに、同一のリソース値が割り当てられるため、別のリソースファイルを作成する場合は、リソースファイルに含まれるリソースキーの数ごとに翻訳箇所に対する翻訳を行わなくてはならないといったことになる。また、リソースファイルの中における同じリソース値を割り当てるリソースキーが多くなると、同じ翻訳をそのリソースキーに対して間違いなく行わなくてはならない、あるいは、翻訳を業者に外注する場合などは、その分翻訳料金が増すなどの課題が発生する。

この課題に対しては、リソースファイル内の同じリソース値が割り当てられる複数のリソースキーに対する重複対応の処理を入れることで解決する。そのため、図１０と、図１２の処理において、リソースの重複対応の処理を追加した内容を、図２１と図２５において説明する。

図２１は、定義フォルダ内の各々の定義ファイルから翻訳対象となるリソースキーとリソース値（文字列）を取り出して、重複するリソースを検出し、定義フォルダリソース一覧を生成する処理を説明するフローチャートである。図２１のフローチャートの各ステップは、情報処理装置１００上のＣＰＵ２０１で実行される。なお、図２１のＳ２１０１からＳ２１０９までの処理は、図１０のＳ１００１からは１００９までの処理、Ｓ２１１２からＳ２１１４までの処理は、図１０のＳ１０１０からＳ１０１２までの処理と同様であるため、その部分についての説明は省略する。したがって、図２１のＳ２１１０とＳ２１１１の処理について説明をする。

Ｓ２１１０は重複検出を行うか否かを判定するステップである。重複検出を行うか否かを判断する設定値はプログラム自動生成装置の重複管理部１２６に保存しておく。Ｓ２１１０で、重複検出を行うように設定されていると判定した場合は重複検出のステップ（Ｓ２１１１）を行う。なお、Ｓ２１１１の処理の説明は、図２２で説明を行う。なお、Ｓ２１１０において、重複検出を行わないように設定されていると判定した場合は、Ｓ２１１２へ進み、第一の実施形態と同じリソースファイルが作成されることになる。

重複管理部１２６には重複検出を行うか否かの設定を行うだけではなく、重複を検出するための条件も管理する。重複条件とはどのような場合にリソース値は重複しているとみなすかという条件である。

重複条件の一例として、入出力画面定義の項目に対して関連するデータモデルのコードと関連するデータモデルの中の項目コードが同じであれば、それは同じリソース値を割り当てられる重複項目とみなす、という例を挙げて説明をする。すなわち、リソースキーが作成された基となるアプリケーション定義ファイルの中の項目定義が共通のデータモデルにより作成された場合に、グローバルリソースキーを割り当るリソースキーである条件とする。

図２０は、ＥＭＰＬＯＹＥＥテーブル１９００のデータモデルである、ＥＭＰＬＯＹＥＥテーブルのデータモデル２０００の例を図２０、２０１０と２０２０とともに説明した図である。図２０、２０１０は、ＥＭＰＬＯＹＥＥテーブル１９００にアクセスするための、社員マスタ画面の入出力定義である。図２０、２０２０は、ＥＭＰＬＯＹＥＥテーブル１９００にアクセスするための、社員更新画面の入出力定義である。

図２０、ＥＭＰＬＯＹＥＥテーブルのデータモデル２０００は、データモデルコードが「ＥＭＰＬＯＹＥＥ（２００１）」、そのテーブルを構成する項目であるデータモデルの項目コードは、「ＩＤ（２００２）」、「ＮＡＭＥ（２００３）」、「ＰＡＳＳＷＯＲＤ（２００４）」からなる。

なお、図２０の２０１０と２０２０の入出力定義とも、図２０のＥＭＰＬＯＹＥＥテーブルのデータモデル２０００をもとに、作成した入出力定義であるものとする。したがって、図２０の２０１０と図２０の２０２０のいずれの入出力定義ともＥＭＰＬＯＹＥＥテーブルのデータモデル２０００と関連している。

例えば、図２０、２０１０の社員マスタの画面の入出力定義において、関連するデータモデルコード（関連ＤＭ）はＥＭＰＬＯＹＥＥ（２０１１）になり、項目コードＥＭＰ＿ＩＤ（２０１４）に関連する関連データモデル（ＤＭ）項目は、ＩＤ（２０１２）となる。また、項目コードＥＭＰ＿ＮＡＭＥ（２０１５）に関連する関連データモデル（ＤＭ）項目はＮＡＭＥ（２０１３）となる。

図２０、２０２０の社員更新の画面の入出力定義においても、関連するデータモデルコード（関連ＤＭ）はＥＭＰＬＯＹＥＥ（２０２１）になり、項目コードＥＭＰ＿ＩＤ（２０２５）に関連する関連データモデル項目（関連ＤＭ項目）はＩＤ（２０２２）となる。また、項目コードＥＭＰ＿ＮＡＭＥ（２０２６）に関連するデータモデル項目（関連ＤＭ項目）は、ＮＡＭＥ（２０２３）となる。さらに、項目コード、ＥＭＰ＿ＰＷＤ（２０２７）に関連するデータモデル項目（関連ＤＭ項目）はＰＡＳＳＯＷＲＤ（２０２４）となる。

このように、関連ＤＭと関連ＤＭ項目のコードが同じであることを重複条件の例とすると、この社員マスタの画面の入出力定義のＥＭＰ＿ＩＤ（２０１４）、ＥＭＰ＿ＮＡＭＥ（２０１５）と、社員更新の画面の入出力定義のＥＭＰ＿ＩＤ（２０２５）、ＥＭＰ＿ＮＡＭＥ（２０２６）から生成される項目のラベルに表示する文字列は関連するデータモデル、あるいはデータモデルの項目が共通のため重複リソースとみなすこととする。

なお、ここで説明した重複条件はあくまで一例であり、重複条件はこれ以外に、任意に定義することを可能する。すなわち、条件は、任意に変更可能であることとする。例えば、入出力定義の中の入出力項目コードのみ同じであれば、重複とみなす、といった条件にしても良いということである。

図２２は、重複検出の処理を説明した図である。この図で説明する重複条件も、関連ＤＭと関連ＤＭ項目のコードが同じである場合に重複とみなすルールで説明する。

Ｓ２２０１では対象となる入出力定義の情報（第一の実施形態でいうと図１１の定義ファイルリソース）を読み取り、その入出力項目に関連するデータモデル（関連ＤＭ）があるかどうかを判定する。なお、関連ＤＭがない場合、つまり、データベースと直接関連しない入出力項目である場合（Ｓ２２０１でＮＯ）は、何もしないで処理を終了する。

Ｓ２２０１で関連ＤＭがあると判定した場合（Ｓ２２０１でＹＥＳ）、Ｓ２２０２のステップでメモリ上に展開しているグローバルキーリソースマップに＿ＧＬＯＢＡＬ．関連ＤＭコード．関連ＤＭ項目コードをキーとするエントリがあるかチェックする。

グローバルリソースキーマップとは、図１１で作成された翻訳対象となる項目が、重複キーであるか否かを判定するためにメモリ上に展開する領域のことである。

なお、グローバルキーリソースマップのメモリ内のイメージを図２３に示す。グローバルキーリソースマップのグローバルリソースキー２３０１は、グローバルキーの値を設定する項目である。本実施形態では、＿ＧＬＯＢＡＬ．関連ＤＭコード．関連ＤＭ項目コードで作成することとする。

グローバルリソース値２３０２は、グローバルリソースキー２３０１に対するグローバルリソース値となりうる名称を、入出力定義の項目名より登録する項目である。例えば、図２３の２３１０のグローバルキーである＿ＧＬＯＢＡＬ．ＥＭＰＬＯＹＥＥ．ＩＤは、図２０の社員更新の入出力定義（２０１０）のＥＭＰ＿ＩＤの項目（２０１４）や図２０の社員更新の入出力定義（２０２０）のＥＭＰ＿ＩＤの項目（２０２５）の定義より作成しているが、この入出力定義に対応する２０２８と２０２９の項目名の値で登録することとする。なお、この場合入出力定義が複数のため項目名がそれぞれにおいて同一であることを条件とするが、仮に、同一でない場合は、名称を統一させる処理を行うことで対応することとする。

重複回数２３０３は、重複回数を示す項目である。１であれば、＿ＧＬＯＢＡＬ．関連ＤＭコード．関連ＤＭ項目コードで作成したグローバルキーリソースキーに重複はなく、２以上の値であれば、重複があることとなる。

Ｓ２２０２では、＿ＧＬＯＢＡＬ．関連ＤＭコード．関連ＤＭ項目コードで作成したグローバルキーリソースキーが、グローバルリソースマップ２３００に既に存在するか、否かを判定する。

例えば、入出力コードがＥＭＰ＿ＬＩＳＴ、入出力項目コードがＥＭＰ＿ＩＤの入出力項目のリソース値についてチェックする場合、図２０、２０２０より、関連ＤＭコードはＥＭＰＬＯＹＥＥ、関連ＤＭ項目コードはＩＤとなる。この場合のグローバルキーは＿ＧＬＯＢＡＬ．ＥＭＰＬＯＹＥＥ．ＩＤである。これと一致するエントリがグローバルリソースマップ２３００のグローバルリソースキー２３０１に存在するか否か、で判定するということである。

Ｓ２２０２でグローバルリソースマップ２３００に存在すると判定した場合、Ｓ２２０５の処理へ進む。Ｓ２２０２で、グローバルリソースマップ２３００に存在しないと判定した場合（Ｓ２２０２でＮＯ）は、Ｓ２２０３にて、＿ＧＬＯＢＡＬ．関連ＤＭコード．関連ＤＭ項目コードで作成したグローバルキーをマップに登録する。

Ｓ２２０３では、例えば、図２０の社員更新の入出力定義（２０２０）のＥＭＰ＿ＩＤの項目（２０２５）の場合、関連ＤＭコードが、ＥＭＰＬＯＹＥＥ（２０２１）、関連ＤＭ項目コードがＩＤ（２０２２）となるため、グローバルリソースキー２３０１へは、＿ＧＬＯＢＡＬ．ＥＭＰＬＯＹＥＥ．ＩＤで値を作成し登録する。

グローバルリソース値２３０２へは、図２０の社員更新の入出力定義（２０２０）のＥＭＰ＿ＩＤの項目（２０２５）に対応する２０２９の項目名の値である「社員番号」登録することとする。

重複回数２３０３は、重複回数を示す項目である。初回の登録であれば、１を登録する（Ｓ２２０４）。なお、既に同じリソースキーが存在している場合は、そのキーの重複回数２３０３に対して１追加した値で更新する（Ｓ２２０５）。

なお、図２０の２０１０と２０２０の入出力画面定義が存在する場合には、関連ＤＭのコードのＥＭＰＬＯＹＥＥと、関連ＤＭ項目コードのＩＤとＮＡＭＥが共通していて、それに関連するそれぞれの入出力定義における入出力項目コードのＥＭＰ＿ＩＤ、ＥＭＰ＿ＮＡＭＥより２回共通したことが確認されているため、作成するグローバルリソースキーの重複回数２３０３の値が２となりグローバルリソースマップ２３００が生成される（２３１０、２３２０）。一方、関連ＤＭ項目コードのＰＡＳＳＷＯＲＤについては、図２０の２０２０の社員更新の入出力定義においてのみ、それから作成された項目が存在するため、重複回数２３０３の値は１のままグローバルリソースキーが生成される（２３３０）。

Ｓ２２０５では、グローバルリソースマップ２３００の重複回数２３０３を１、カウントアップして更新する。重複がある場合は重複回数２３０３の値は１より大きい値になる。

続いて、Ｓ２２０６にてグローバルリソースキー使用情報２４００へ情報を追加する処理を行う。

グローバルリソースキー使用情報２４００のメモリ内のマップイメージを図２４に示す。グローバルリソースキー使用情報２４００とは、第一の実施形態の処理でも説明した、図１１で登録された定義リソースのそれぞれのリソースごとにグローバルリソースキーの値の割り当てを行っている領域のことを指す。これにより、該当リソースの該当するグローバルリソースキーの情報がわかる。

リソースキー２４０１は、第一の実施形態で作成するのと同様の方法で作成し、メモリ上に配置状態となっているリソースキーの情報である、また、グローバルリソースキー２４０２は、グローバルリソースキーの名称である。

なお、ここへは、既に翻訳対象となる項目のみの情報が入っていることとする。つまり、Ｓ２２０６では、例えば、図２０、２０２０の社員更新の入出力定義の項目コードがＥＭＰ＿ＩＤ（２０２５）の場合、リソースキー２４０１へは、「ｉｏＩｔｅｍ．ＥＭＰ＿ＤＴＬ．ＥＭＰ＿ＩＤ」の値を、グローバルリソースキー２４０２へは、Ｓ２２０３で作成したグローバルキーと同等の値である＿ＧＬＯＢＡＬ．ＥＭＰＬＯＹＥＥ．ＩＤの値を登録する（図２４の２４０３）。

なお、図２０の２０１０と２０２０の入出力画面定義が存在する場合には、データモデルに関連している項目コードは、図２０の社員マスタの入出力画面定義（２０１０）においては、ＥＭＰ＿ＩＤ（２０１４）と、ＥＭＰ＿ＮＡＭＥ（２０１５）であり、入出力コードがＥＭＰ＿ＬＩＳＴであるため、図２４の２４０４の線枠で示すようにリソースキーが作成され（作成方法は第一の実施形態を適応）、それに対応するグローバルリソースキー２４０２の値は、図２４の２４０６の線枠で示すように、作成される。

また、図２０の社員更新の入出力画面定義（２０２０）においてデータモデルに関連している項目コードは、ＥＭＰ＿ＩＤ（２０２５）と、ＥＭＰ＿ＮＡＭＥ（２０２６）、ＥＭＰ＿ＰＷＤ（２０２７）であり、入出力コードがＥＭＰ＿ＤＴＬであるため、図２４の２４０５の線枠で示すようにリソースキーが作成され（作成方法は第一の実施形態を適応）、それに対応するグローバルリソースキー２４０２の値は、は、図２４の２４０７の線枠で示すように作成される。

以上、図２２の重複検出の処理の説明を終了する。

次に、重複検出による結果を反映したリソースファイルテンプレートの出力処理について図２５を用いて説明する。

図２５は、メモリ上に構成されたリソースキーとリソース値（文字列）を対応付けて、重複対応を行ったリソーステンプレートファイルを出力するフローチャートの一例を示す図である。なお、図２５のＳ２５０１は図１２のＳ１２０１、図２５のＳ２５０３からＳ２５１０までの処理は図１２のＳ１２０２からＳ１２０９までの処理、図２５のＳ２５１２の処理は図１２のＳ１２１１の処理と同様であるため、この部分の処理の説明は省略する。したがって、図２５においては、Ｓ２５０２とＳ２５１１の処理について説明をする。

図２５のＳ２５０２は図２３で説明したグローバルリソースマップ２３００を読み、重複キーとなるグローバルリソースを抽出するステップである。詳細は後述の図２６で説明する。

図２５のＳ２５１１は最終的なリソースファイルを生成するにあたって、リソースファイルテンプレート内で、重複キーとなっているリソースキーのリソース値をグローバルリソースキーで差し替える処理になる。詳細は後述の図２８で説明する。

図２６はグローバルリソースを抽出する処理図である。この処理では、図２３のグローバルリソースマップ２３００を読み取り、重複しているとされているグローバルリソースキーのみを、グローバルリソースとしてメモリ上へ抽出する処理である。

なお、抽出されたグローバルリソースキーの情報は、後述の図２８でグローバルリソースでの差し替え処理が行われたリソースキーの情報と合体して、最終的なリソースファイルとして出力されることとなる。この方法でリソースファイルを作成すると、重複するリソース値に関しては、リソースファイル内のグローバルリソースキーに対するリソース値のみを翻訳対象とすればよいこととなる。すなわち、グローバルリソースキーに割り当てられた共通のリソース値のみを他言語へ翻訳することにより、異なる言語コードに対応するリソースファイルを作成可能になる。

Ｓ２６０１からＳ２６０２までは図２３で説明したグローバルリソースマップ２３００をメモリから読み出し、読み出したマップ内に存在するグローバルリソースキー分だけ繰り返し処理を行う。

グローバルリソースマップ２３００に存在する情報には図２３で示したように何回重複があったかを示す、重複回数２３０３で管理する値の情報がある。

Ｓ２６０１では、この重複回数２３０３の情報を見て判定する。重複回数２３０３の値が１の場合つまり重複はしていない場合（Ｓ２６０１で＝１の場合）、グローバルリソース出力は行わないため、グローバルリソースマップ２３００内の次の情報に対して、再度Ｓ２６０１の判定処理を進める。

Ｓ２６０１で重複回数が２以上であるグローバルキーと判定した場合、Ｓ２６０２においてグローバルリソースの抽出を行う。すなわち、共通のリソース値が割り当てられるリソースキーが複数生成される場合に、共通のリソース値を割り当てたグローバルリソースキーを作成する。

図２３のグローバルリソースマップ２３００に存在するグローバルリソースキーの例でいうと、重複回数２３０３の値が２以上であるものは、グローバルリソースキー２３０１が、＿ＧＬＯＢＡＬ．ＥＭＰＬＯＹＥＥ．ＩＤ（重複は２回）と、＿ＧＬＯＢＡＬ．ＥＭＰＬＯＹＥＥ．ＮＡＭＥ（重複は２回）のものであるため、これらのグローバルリソースキーがグローバルリソースとして抽出されることとなる。

また、そのグローバルリソースキーに対応するグローバルリソース値は、グローバルリソースキー２３０１に対応するグローバルリソース値２３０２より取得する。

抽出したグローバルリソースキーと、それに対応するグローバルリソース値をグローバルリソースとしてメモリ上に抽出した例を図２７に示す。例えば、図２３、２３１０の＿ＧＬＯＢＡＬ．ＥＭＰＬＯＹＥＥ．ＩＤからは図２７、２７０１に図示するようにグローバルリソースが抽出され、図２３、２３２０の＿ＧＬＯＢＡＬ．ＥＭＰＬＯＹＥＥ．ＮＡＭＥからは、図２７、２７０２に図示するようにグローバルリソースが抽出される。

グローバルリソースマップ２３００にあるすべてのグローバルリソースキーについてＳ２６０１からＳ２６０２までの処理を終えると、図２６の処理を終了する。

図２８は翻訳対象のリソース値のうち、重複しているリソース値について、グローバルリソースキー使用情報２４００を参照し、グローバルリソースキーで差し替える処理図である。本処理のＳ２８０１からＳ２８０３は、第一の実施形態と同様に作成された、通常のリソースキーとなる情報（図２５のＳ２５０１からＳ２５１０までの処理（ただし、Ｓ２５０２は除く）で、既にメモリ上に抽出してある、リソースキーに対応するリソース値の対応づけとして作成した図２９の情報）に対し、順番に１件ずつグローバルリソースで置き換え可能である場合に、置き換えを行う処理である。

図２９は、図２０の２０１０と２０２０の入出力画面定義が存在する場合に、第一の実施形態において翻訳対象となる項目をリソースキーとし、それに対するリソース値を設定した状態のファイルである。第一の実施形態によると、図２９に図示する形式でリソースファイルが作成されるが、第二の実施形態では、これに対し、重複するリソース値を、共通の翻訳語が設定されたグローバルリソースキーに置き換える処理を行う。

Ｓ２８０１で、図２９の該当リソースキーに対し、図２４のグローバルリソースキー使用情報２４００に合致するレコードが存在するかを判定する。合致するかの判断は、図２４のリソースキー２４０１の値に同じリソースキーが存在するか否かで判定する。

なお、図２４に存在する場合は、図２４は、ＤＭ関連項目コードを関連付けて抽出したメモリ情報であるため、処理対象のリソースキーはＤＭ関連項目コードということになる。Ｓ２８０１で図２４のグローバルリソースキー使用情報２４００に合致するレコードが存在する場合は（Ｓ２８０１でＹＥＳの場合は）、Ｓ２８０２へ処理を進める。Ｓ２８０１で存在しない場合、次のリソースキーが存在する場合は、そのリソースキーに対して、再びＳ２８０１の処理を行う。

Ｓ２８０２において、図２４で合致したリソースキーと同じ、図２３のグローバルリソースマップ２３００のリソースキーにおける重複回数２３０３において、１かそれとも２以上の値かを確認する。１の場合、重複値がないため、次のリソースキーが存在する場合は、そのリソースキーに対して再びＳ２８０１の処理を行う。２以上の場合は、重複値となるため、Ｓ２８０３へ処理を進める。

Ｓ２８０３では、図２５のＳ２５１０までの処理で、既にメモリ上に抽出してある、リソースキーに対応するリソース値を、Ｓ２８０２で重複回数を確認した図２３のグローバルリソースキー２３０１の値で差し替える。すなわち、共通のリソース値が割り当てられるリソースキーに、グローバルリソースキーをリソース値として割り当てる。

なお、Ｓ２８０１で、該当リソースキーに対し、図２４のグローバルリソースキー使用情報２４００に合致するレコードが存在しない場合（Ｓ２８０１でＮＯの場合）、また、Ｓ２８０２において、図２４で合致したリソースキーと同じ、図２３のグローバルリソースマップ２３００のリソースキーにおける重複回数２３０３が１の場合（Ｓ２８０２でＮＯの場合）は、図２５のＳ２５１０までの処理で、既にメモリ上にためてある、処理対象となっているリソースキーに対応するリソース値は、そのままの状態にしておく。

図２９のリソースキーに対する、Ｓ２８０１からＳ２８０３のグローバルリソースキーへの差し替え処理が完了した後は、Ｓ２８０４において、図２５のＳ２５０２（図２６）の処理で抽出していたグローバルリソースも含め、図３０に図示の、重複キー対応を行ったリソースファイルを出力する。

次に、その出力されるリソースファイルについて説明をする。図３０の３００１で図示する「＿ＧＬＯＢＡＬ．ＥＭＰＬＯＹＥＥ．ＩＤ＝社員」、「＿ＧＬＯＢＡＬ．ＥＭＰＬＯＹＥＥ．ＮＡＭＥ＝社員名」の部分については、図２５のＳ２５０２（図２６の処理）のグローバルリソース出力で抽出され、ファイルとなった内容である。

図３０の３００３で図示する、「ｉｏ．ＥＭＰ＿ＬＩＳＴ」以降、「ｉｏＩｔｅｍ．ＥＭＰ＿ＤＴＬ．ＵＰＤＡＴＥ」までの行は、図２８の処理で抽出され、ファイルとなった内容である。

再度、図２８の処理の流れを、図２９に図示する、図２０の社員マスタの入出力定義（２０１０）と図２０の社員更新の入出力定義（２０２０）から作成されたリソースキーをもとに説明をする。

図２９の中において、図２０の社員更新の入出力定義（２０２０）の項目コードがＥＭＰ＿ＩＤ（２０２５）から作成されたリソースキーである「ｉｏＩｔｅｍ．ＥＭＰ＿ＤＴＬ．ＥＭＰ＿ＩＤ」を例に挙げて説明をする。

Ｓ２８０１において、リソースキーの「ｉｏＩｔｅｍ．ＥＭＰ＿ＤＴＬ．ＥＭＰ＿ＩＤ」が、図２４のグローバルリソースキー使用情報２４００に合致するレコードがあるか否かを判定する。

このリソースキーは、図２４の２４０３のリソースキー２４０１に合致する（Ｓ２８０１においてＹＥＳ）。また、それに対応するグローバルリソースキー２４０２の値は、「＿ＧＬＯＢＡＬ．ＥＭＰＬＯＹＥＥ．ＩＤ」となる。

次ぎに、Ｓ２８０２において、リソースキーの「ｉｏＩｔｅｍ．ＥＭＰ＿ＤＴＬ．ＥＭＰ＿ＩＤ」は、リソース値が重複するものであるかを判定する。

Ｓ２８０１で確認した図２４のグローバルリソースキー２４０２の値である「＿ＧＬＯＢＡＬ．ＥＭＰＬＯＹＥＥ．ＩＤ」に対応する、図２３におけるグローバルリソースキーの情報を検索する。このとき、図２３の２３１０のグローバルリソースキー２３０１の値が、「＿ＧＬＯＢＡＬ．ＥＭＰＬＯＹＥＥ．ＩＤ」のレコードが合致する情報となる。また、図２３の２３１０のレコードの重複回数２３０３の値は「２」であるため、重複しているグローバルリソースキーであることが分かる。したがって、Ｓ２８０２において、リソースキーの「ｉｏＩｔｅｍ．ＥＭＰ＿ＤＴＬ．ＥＭＰ＿ＩＤ」は、リソース値が重複するものがあることになる（Ｓ２８０２において＞＝２）。

次に、Ｓ２８０３において、図２５のＳ２５１０までの処理で、既にメモリ上に抽出してある、リソースキー（図２９の「ｉｏＩｔｅｍ．ＥＭＰ＿ＤＴＬ．ＥＭＰ＿ＩＤ」）に対応するリソース値（図２９の社員番号）を、Ｓ２８０２で重複回数を確認した図２３のグローバルリソースキー２３０１の値（「＿ＧＬＯＢＡＬ．ＥＭＰＬＯＹＥＥ．ＩＤ」）で差し替える。したがって、最終的に、ｉｏＩｔｅｍ．ＥＭＰ＿ＤＴＬ．ＥＭＰ＿ＩＤ＝＿ＧＬＯＢＡＬ．ＥＭＰＬＯＹＥＥ．ＩＤというリソースキーとリソース値の組み合わせが作成されることになる。

同様の処理が、図２９の中における、図２０の社員更新の入出力定義（２０２０）の項目コードがＥＭＰ＿ＩＤ（２０２６）から作成されたリソースキーである「ｉｏＩｔｅｍ．ＥＭＰ＿ＤＴＬ．ＥＭＰ＿ＮＡＭＥ」、図２０の社員マスタの入出力定義（２０１０）の項目コードがＥＭＰ＿ＩＤ（２０１４）から作成されたリソースキーである「ｉｏＩｔｅｍ．ＥＭＰ＿ＬＳＴ．ＥＭＰ＿ＩＤ」、項目コードがＥＭＰ＿ＮＡＭＥ（２０１５）から作成されたリソースキーである「ｉｏＩｔｅｍ．ＥＭＰ＿ＬＳＴ．ＥＭＰ＿ＮＡＭＥ」も、重複キーとなっているため、同様の処理がされ、最終的に図３０の３００２に図示するリソースキーとリソース値の組み合わせが作成される。

以上で、重複リソースがある場合のリソースファイルテンプレート出力処理の説明を終了する。

以上、第１の実施形態に対して、第二の実施形態の処理を含めることにより、同じリソース値が割り当てられるリソースキーが複数存在した場合、そのリソースキーに割り当てる値をグローバルリソースキーとし、かつ、グローバルリソースキーへも共通となるリソース値を割り当て、リソースファイルを作成することで、共通する値が割り当てられるリソースキーに関しては、グローバルリソースキーに割り当てるリソース値を翻訳するだけで、他の言語切り替え処理用のリソースファイルを作成することが可能となる。

なお、上述した各種データの構成及びその内容はこれに限定されるものではなく、用途や目的に応じて、様々な構成や内容で構成されることは言うまでもない。

以上、二つの実施形態について示したが、本発明は、例えば、システム、装置、方法、コンピュータプログラムもしくは記録媒体等としての実施態様をとることが可能であり、具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。

また、本発明におけるコンピュータプログラムは、図９、図１０、図１２、図１３、図１５、図１６、図２１、図２２、図２５、図２６、図２８に示すフローチャートの処理方法をコンピュータが実行可能なコンピュータプログラムであり、本発明の記憶媒体は図９、図１０、図１２、図１３、図１５、図１６、図２１、図２２、図２５、図２６、図２８の処理方法をコンピュータが実行可能なコンピュータプログラムが記憶されている。なお、本発明におけるコンピュータプログラムは図９、図１０、図１２、図１３、図１５、図１６、図２１、図２２、図２５、図２６、図２８の各装置の処理方法ごとのコンピュータプログラムであってもよい。

以上のように、前述した実施形態の機能を実現するコンピュータプログラムを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に格納されたコンピュータプログラムを読出し実行することによっても、本発明の目的が達成されることは言うまでもない。

この場合、記録媒体から読み出されたコンピュータプログラム自体が本発明の新規な機能を実現することになり、そのコンピュータプログラムを記憶した記録媒体は本発明を構成することになる。

コンピュータプログラムを供給するための記録媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＤＶＤ−ＲＯＭ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＥＥＰＲＯＭ、シリコンディスク、ソリッドステートドライブ等を用いることができる。

また、コンピュータが読み出したコンピュータプログラムを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのコンピュータプログラムの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

さらに、記録媒体から読み出されたコンピュータプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのコンピュータプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

また、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用してもよい。また、本発明は、システムあるいは装置にコンピュータプログラムを供給することによって達成される場合にも適応できることは言うまでもない。この場合、本発明を達成するためのコンピュータプログラムを格納した記録媒体を該システムあるいは装置に読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。
さらに、本発明を達成するためのコンピュータプログラムをネットワーク上のサーバ、データベース等から通信プログラムによりダウンロードして読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。
なお、上述した各実施形態およびその変形例を組み合わせた構成も全て本発明に含まれるものである。

１００ 情報処理装置
１１０ アプリケーション定義ファイル記憶部
１１２ 入出力定義ファイル
１１３ メッセージ定義ファイル
１２０ リソーステンプレート生成部
１２１ リソーステンプレート出力先指定ＧＵＩ
１２２ 定義ファイル解析部
１２３ リソースキー生成部
１２４ リソース値取得部
１２５ リソーステンプレート出力部
１２６ 重複管理部
１３０ プログラム生成部
１４０ アプリケーションサーバ
１４１ リソースファイル記憶部
１４２ リソースファイル
１４３ アプリケーション

Claims (10)

1. 翻訳対象となる箇所をリソースキーに置き換え、翻訳後の文字列となるリソース値を前記リソースキーに代入することによって当該箇所を指定した言語の文字列で表示することを可能とするアプリケーションのソースプログラムを生成するプログラム生成装置において、
   前記アプリケーションを生成するための定義であるアプリケーション定義ファイルをアプリケーション定義ファイル記憶手段に登録するアプリケーション定義ファイル登録手段と、
   前記ソースプログラムの動作時に翻訳対象となる翻訳対象文字列を前記アプリケーション定義ファイルから特定するための翻訳対象文字列特定手段と、
   前記翻訳対象文字列の翻訳語となるリソース値を取得するためのキーとなるリソースキーを生成するリソースキー生成手段と、
   前記リソースキー生成手段により生成された前記リソースキーに対応する前記翻訳語となるリソース値を前記翻訳対象文字列から取得するリソース値取得手段と、
   前記リソースキーと前記リソース値を対応付けて、言語リソースファイルに出力するリソースファイル生成手段と、
   前記アプリケーションの実行時に、指定した言語の前記リソースファイルに存在する、リソースキーに対応するリソース値を用いることにより、当該アプリケーションの翻訳対象文字列を指定した言語の文字列で表示可能にするために、前記ソースプログラムの翻訳対象文字列となる箇所に、言語表示を切り替えるために前記リソースキーを埋め込んだソースプログラムを生成するソースプログラム生成手段
   を備えることを特徴とするプログラム生成装置。
2. 前記アプリケーション定義ファイルは、階層的なタグにより要素を特定することが可能な構成により定義されるものであって、
   前記翻訳対象文字列特定手段は、前記タグの階層の位置および前記タグの種別により、指定した言語の文字列に置き換えて表示する翻訳対象文字列を特定し、前記リソースキー生成手段は、前記アプリケーション定義ファイルの前記タグの階層における位置の情報および前記タグの種別を用いて、一意的に認識可能に前記リソースキーを生成するものであることを特徴とする請求項１に記載のプログラム生成装置。
3. 共通のリソース値が割り当てられる前記リソースキーが複数生成される場合に、前記共通のリソース値を割り当てたグローバルリソースキーを作成するグローバルリソースキー作成手段
   を更に備え、
   前記共通のリソース値が割り当てられる当該リソースキーに、前記グローバルリソースキーをリソース値として割り当てるグローバルリソースキー割当手段
   を備えること
   を特徴とする請求項１または請求項２に記載のプログラム生成装置。
4. 前記グローバルリソースキーに割り当てられた前記共通のリソース値のみを他言語へ翻訳することにより、異なる言語コードに対応するリソースファイルを作成可能であること
   を特徴とする請求項３に記載のプログラム生成装置。
5. 前記リソースキーが作成された基となる前記アプリケーション定義ファイルの中の項目定義が共通のデータモデルにより作成された場合に、前記グローバルリソースキーを割り当るリソースキーである条件とすること
   を特徴とする請求項３または請求項４に記載のプログラム生成装置。
6. 前記条件は、任意に変更可能であること
   を特徴とする請求項５に記載のプログラム生成装置。
7. 前記ソースプログラム生成手段は、オペレーティングシステム、ブラウザの言語設定、ユーザの指定、前記ソースプログラム生成手段により生成されたソースプログラム、のいずれかにより指定された当該ソースプログラムの動作時の言語コードに対応付けられた前記言語リソースファイルを参照して前記ソースプログラムに配置された前記リソースキーに前記リソース値を対応付けて動作し、言語コードが異なる言語コードに切り替えられた場合には、前記異なる言語コードに対応する前記リソースファイルを参照して当該ソースプログラムに配置された当該リソースキーに当該リソース値を対応付けて動作するように切り替えるソースプログラムを生成すること
   を特徴とする請求項１乃至請求項６のいずれか１項に記載のプログラム生成装置。
8. 前記ソースプログラム生成手段は、
   当該ソースプログラムの動作時に、前記ソースプログラムに配置された前記リソースキーが前記言語リ
   ソースファイルの中に存在しない場合には、前記アプリケーション定義ファイルを参照し、当該リソースキーに対応する当該アプリケーション定義ファイルにおける翻訳対象文字列を特定し、当該リソースキーに対応する文字列を前記リソース値として取得するように動作するソースプログラムを生成すること
   を特徴とする請求項１乃至請求項７に記載のプログラム生成装置。
9. 翻訳対象となる箇所をリソースキーに置き換え、翻訳後の文字列となるリソース値を前記リソースキーに代入することによって当該箇所を指定した言語の文字列で表示することを可能とするアプリケーションのソースプログラムを生成するプログラム生成装置の制御方法において、
   アプリケーション定義ファイル登録手段が、前記アプリケーションを生成するための定義であるアプリケーション定義ファイルをアプリケーション定義ファイル記憶手段に登録するアプリケーション定義ファイル登録ステップと、
   翻訳対象文字列特定手段が、前記ソースプログラムの動作時に翻訳対象となる翻訳対象文字列を前記アプリケーション定義ファイルから特定するための翻訳対象文字列特定ステップと、
   リソースキー生成手段が、前記翻訳対象文字列の翻訳語となるリソース値を取得するためのキーとなるリソースキーを生成するリソースキー生成ステップと、
   リソース値取得手段が、前記リソースキー生成手段により生成された前記リソースキーに対応する前記翻訳語となるリソース値を前記翻訳対象文字列から取得するリソース値取得ステップと、
   リソースファイル生成手段が、前記リソースキーと前記リソース値を対応付けて、言語リソースファイルに出力するリソースファイル生成ステップと、
   ソースプログラム生成手段が、前記アプリケーションの実行時に、指定した言語の前記リソースファイルに存在する、リソースキーに対応するリソース値を用いることにより、当該アプリケーションの翻訳対象文字列を指定した言語の文字列で表示可能にするために、前記ソースプログラムの翻訳対象文字列となる箇所に、言語表示を切り替えるために前記リソースキーを埋め込んだソースプログラムを生成するソースプログラム生成ステップ
   を含むことを特徴とするプログラム生成装置の制御方法。
10. 翻訳対象となる箇所をリソースキーに置き換え、翻訳後の文字列となるリソース値を前記リソースキーに代入することによって当該箇所を指定した言語の文字列で表示することを可能とするアプリケーションのソースプログラムを生成するプログラム生成装置において実行可能なプログラムであって、
    前記プログラム生成装置を、
    前記アプリケーションを生成するための定義であるアプリケーション定義ファイルをアプリケーション定義ファイル記憶手段に登録するアプリケーション定義ファイル登録手段と、
    前記ソースプログラムの動作時に翻訳対象となる翻訳対象文字列を前記アプリケーション定義ファイルから特定するための翻訳対象文字列特定手段と、
    前記翻訳対象文字列の翻訳語となるリソース値を取得するためのキーとなるリソースキーを生成するリソースキー生成手段と、
    前記リソースキー生成手段により生成された前記リソースキーに対応する前記翻訳語となるリソース値を前記翻訳対象文字列から取得するリソース値取得手段と、
    前記リソースキーと前記リソース値を対応付けて、言語リソースファイルに出力するリソースファイル生成手段と、
    前記アプリケーションの実行時に、指定した言語の前記リソースファイルに存在する、リソースキーに対応するリソース値を用いることにより、当該アプリケーションの翻訳対象文字列を指定した言語の文字列で表示可能にするために、前記ソースプログラムの翻訳対象文字列となる箇所に、言語表示を切り替えるために前記リソースキーを埋め込んだソースプログラムを生成するソースプログラム生成手段
    として機能させることを特徴とするコンピュータで読み取り実行可能なプログラム。

Images