"ロケールに応じた複数の画面構成ファイルを含むアプリケーションを実行するアプリケーション部から前記各画面構成ファイルを指定するパスの入力を受け付けると、当該パスを前記アプリケーションの利用者のロケールに応じて変換し、当該変換されたパスを前記アプリケーション部に送出するパス変換装置であって、前記利用者のロケールを管理するロケール管理手段と、前記各画面構成ファイルを個別に示す各パスのリスト情報を記憶するパスリスト記憶手段と、前記パスの一部である変換対象と、当該変換対象が変換される変換文字列であってロケールを示す変数を含む前記変換文字列とを定義した複数の変換ルールからなるパス変換ルールを記憶する変換ルール記憶手段と、前記アプリケーション部からパスの入力を受け付けると、ロケール管理手段からロケールを取得するロケール取得手段と、前記入力を受け付けたパスの一部を前記パス変換ルール内の各々の変換ルールに基づいて個別に前記変換文字列に変換し、当該変換文字列内の変数を前記取得されたロケールに置換することにより、当該入力を受け付けたパスを複数のパスに変換し、当該複数のパスからなるパス変換候補を生成するパス変換手段と、当該パス変換候補内の各パスについて前記リスト情報内に存在するかをチェックするパス存在チェック手段と、前記パス存在チェック手段によるチェックの結果、前記リスト情報内に存在するパスを前記変換されたパスとして前記アプリケーション部に送出するパス送出手段と、を備えたことを特徴とするパス変換装置。請求項1に記載のパス変換装置において、前記パス存在チェック手段によるチェックの結果、前記パス変換候補内の全てのパスが前記リスト情報内に存在しない場合、前記入力を受け付けたパスを前記変換されたパスとして前記アプリケーション部に送出する手段、を更に備え、前記入力を受け付けたパスは、前記ロケールを含まないパスであって、英語圏に対応した画面構成ファイルを示すことを特徴とするパス変換装置。ロケールに応じた複数の画面構成ファイルを含むアプリケーションを実行するアプリケーション部から前記各画面構成ファイルを指定するパスの入力を受け付けると、当該パスを前記アプリケーションの利用者のロケールに応じて変換し、当該変換されたパスを前記アプリケーション部に送出し、且つパスリスト記憶手段及び変換ルール記憶手段を備えたパス変換装置に用いられるプログラムであって、前記パス変換装置を、前記利用者のロケールを管理するロケール管理手段、前記各画面構成ファイルを個別に示す各パスのリスト情報を前記パスリスト記憶手段に書込む手段、前記パスの一部である変換対象と、当該変換対象が変換される変換文字列であってロケールを示す変数を含む前記変換文字列とを定義した複数の変換ルールからなるパス変換ルールを前記変換ルール記憶手段に書込む手段、前記アプリケーション部からパスの入力を受け付けると、ロケール管理手段からロケールを取得するロケール取得手段、前記入力を受け付けたパスの一部を前記パス変換ルール内の各々の変換ルールに基づいて個別に前記変換文字列に変換し、当該変換文字列内の変数を前記取得されたロケールに置換することにより、当該入力を受け付けたパスを複数のパスに変換し、当該複数のパスからなるパス変換候補を生成するパス変換手段、当該パス変換候補内の各パスについて前記リスト情報内に存在するかをチェックするパス存在チェック手段、前記パス存在チェック手段によるチェックの結果、前記リスト情報内に存在するパスを前記変換されたパスとして前記アプリケーション部に送出するパス送出手段、として機能させるためのプログラム。請求項3に記載のプログラムにおいて、前記パス存在チェック手段によるチェックの結果、前記パス変換候補内の全てのパスが前記リスト情報内に存在しない場合、前記入力を受け付けたパスを前記変換されたパスとして前記アプリケーション部に送出する手段、を更に備え、前記入力を受け付けたパスは、前記ロケールを含まないパスであって、英語圏に対応した画面構成ファイルを示すプログラム。しかしながら、以上のようなリソースバンドルやOSSのフレームワークは、通常は何の問題もないが、本発明者の検討によれば、第1及び第2の点で改良の余地がある。第1の点は、切替える対象が、文字列単位や入力項目単位という画面内の1要素である点である。実際のシステム開発では、1要素単位の切替えで済まず、画面の構成レイアウトや入力項目数の数をロケール毎に切替える必要に迫られることがある。例えば、ロケールが日本語の画面と英語の画面では、同じ内容の文であっても文を構成する文字列の文字数が大幅に異なるため、ロケールに応じて画面の構成を切り替える必要がある。また例えば、名前を入力するフォームの場合、ロケールが日本語の画面では、姓、名の順にフォームが配置された構成に加え、漢字とフリガナの入力項目が必要になる。しかしながら、ロケールが英語の画面では、名、姓の順にフォームが配置された構成だけで済み、漢字とフリガナの入力項目が不要となる。従って、画面の構成や入力項目数をロケール毎に切替えるためには、個々のアプリケーション毎に仕組みを作成する必要がある。第2の点は、ロケール毎に切替える対象を管理する必要がある点である。例えば、リソースバンドルであれば、ロケールと文字列の対応を定義し管理する必要がある。また、バリデーションであれば、ロケールとバリデーションルールの関係を定義し管理する必要がある。そのため、切替え対象を追加/変更する場合、切替え対象の作成作業と関係定義の更新作業という2段階の作業が必要になる。本発明が解決しようとする課題は、アプリケーション毎に仕組みを作成せずに画面の構成や入力項目の数をロケール毎に切替え可能であることに加え、ロケール毎に切り替える対象を管理する必要を無くし得るパス変換装置及びプログラムを提供することである。実施形態のパス変換装置は、ロケールに応じた複数の画面構成ファイルを含むアプリケーションを実行するアプリケーション部から前記各画面構成ファイルを指定するパスの入力を受け付ける。前記パス変換装置は、当該入力を受け付けたパスを前記アプリケーションの利用者のロケールに応じて変換し、当該変換されたパスを前記アプリケーション部に送出する。前記パス変換装置は、ロケール管理手段、パスリスト記憶手段、変換ルール記憶手段、ロケール取得手段、パス変換手段、パス存在チェック手段及びパス送出手段を備えている。前記ロケール管理手段は、前記利用者のロケールを管理する。前記パスリスト記憶手段は、前記各画面構成ファイルを個別に示す各パスのリスト情報を記憶する。前記変換ルール記憶手段は、前記パスの一部である変換対象と、当該変換対象が変換される変換文字列であってロケールを示す変数を含む前記変換文字列とを定義した複数の変換ルールからなるパス変換ルールを記憶する。前記ロケール取得手段は、前記アプリケーション部からパスの入力を受け付けると、ロケール管理手段からロケールを取得する。前記パス変換手段は、前記入力を受け付けたパスの一部を前記パス変換ルール内の各々の変換ルールに基づいて個別に前記変換文字列に変換し、当該変換文字列内の変数を前記取得されたロケールに置換することにより、当該入力を受け付けたパスを複数のパスに変換し、当該複数のパスからなるパス変換候補を生成する。前記パス存在チェック手段は、当該パス変換候補内の各パスについて前記リスト情報内に存在するかをチェックする。前記パス送出手段は、前記パス存在チェック手段によるチェックの結果、前記リスト情報内に存在するパスを前記変換されたパスとして前記アプリケーション部に送出する。以下、各実施形態について図面を用いて説明するが、その前に各実施形態に共通する概要を述べる。各実施形態は、ロケール毎に切替える対象を画面の要素単位だけではなく、利用するファイル自体を切替える仕組みを述べている。切り替え対象は、画面構成ファイルHTMLやJSP等の画面ファイルや画面から参照されるスタイルシート、画像ファイル、JavaScript登録商標ファイル等である。切替える方法として、画面構成ファイルへのパスを、ロケール情報を含めたパスへ自動で変換する仕組みを述べている。このような各実施形態によれば、画面構成ファイルを切替える構成により、画面の構成レイアウト,入力項目の増減、画面上で動作するロジックJavascriptなどをロケール毎に変更することが可能となる。また、各実施形態によれば、ロケールと切替え対象の画面構成ファイルの関係を、パス変換ルールとアプリケーション内の構造により管理する構成により、個々の画面構成ファイルとロケールの対応関係を別途管理する必要を無くすことができる。従って、各実施形態によれば、アプリケーション毎に仕組みを作成せずに画面の構成や入力項目の数をロケール毎に切替え可能であることに加え、ロケール毎に切り替える対象を管理する必要を無くすことができる。以上が各実施形態に共通する概要である。続いて、各実施形態について具体的に説明する。<第1の実施形態>図1は第1の実施形態に係るパス変換装置が適用されたクライアントサーバシステムの構成を示す模式図である。このクライアントサーバシステムは、複数のクライアント装置Cjp,...,Cus,...,Csr,...がネットワークを介してサーバ装置Svに接続されている。なお、各クライアント装置Cjp,...,Cus,...,Csr,...の添字{jp},{us},{sr}は、それぞれ設定されたロケールが日本、米国及びセルビア語を示すことを表している。また、各クライアント装置Cjp,...,Cus,...,Csr,...は、ロケールが示す内容を除き、互いに同一構成のブラウザを有するため、ここでは日本を示すロケールがブラウザに設定されたクライアント装置Cjpを代表例に挙げて説明する。クライアント装置Cjpは、通常のブラウザを有する通常のコンピュータであり、具体的には例えば、ユーザの操作により、ロケールを含むリクエストをサーバ装置Svに送信する機能と、ロケールを表すリンクやボタンの選択操作により、当該選択されたロケールをサーバ装置Svに送信する機能と、サーバ装置Svから画面構成ファイルの内容を示す画面構成データを受けると、この画面構成データに基づいて画面を表示する機能とを備えたブラウザを有している。なお、ロケールを含むリクエストをサーバに送信することは、HTTPHyperTextTransferProtocolに定められている。一方、サーバ装置Svは、パス変換装置100及びアプリケーション部200を備えている。パス変換装置100は、ロケールに応じた複数の画面構成ファイルを含むアプリケーションを実行するアプリケーション部200から当該各画面構成ファイルを指定するパスの入力を受け付けると、当該パスを当該アプリケーションの利用者のロケールに応じて変換し、当該変換されたパスをアプリケーション部200に送出する機能をもっている。補足すると、パス変換装置200は、利用者の国際化に対応し、画面構成ファイルへのパスを国際化したパスに変換する装置である。国際化したパスとは、パス内にロケール情報を含んだパスを意味する。例えばアプリケーション部200から入力されたパスがindexjspとした場合、国際化したパスは、indexjaJPjspやjaJPindexjspのようにロケールを表すjaJPをパスに含めたものである。アプリケーション部200から入力されるパスをどのように国際化したパスに変換するかのルールはパス変換ルール131に定義される。なお、国際化したパスは、ロケールに応じたパスと呼んでもよい。このようなパス変換装置100は、具体的には、パス生成部110、ロケール管理部120、パス変換部130及びパス存在チェック部140を備えている。パス生成部110は、アプリケーション部200からの入力であるパスを受付け、適切に国際化したパスを返却する部分である。適切に国際化したパスとは、パス変換ルール131に定義されたルールにより変換され、且つアプリケーション内にそのパスが示す画面構成ファイルが存在するものである。このようなパス生成部110は、具体的には例えば、以下の機能~をもっている。アプリケーション部200からパスの入力を受け付けると、ロケール管理部120からロケールを取得する機能。当該取得したロケールと、当該入力を受け付けたパスとをパス変換部130に送出し、パス変換部130から変換後の複数のパスからなるパス変換候補を受ける機能。なお、この機能は必須ではなく、例えば、パス生成部110とパス変換部130とを一体的に設けることにより、省略可能である。当該パス変換候補をパス存在チェック部140に送出する機能。パス存在チェック部140によるチェックの結果、パスリスト各パスのリスト情報141内に存在するパスを、パス変換装置100により変換されたパスとしてアプリケーション部200に送出するパス送出機能。また、パス変換部110は、さらに、以下の機能を備えてもよい。パス存在チェック部140によるチェックの結果、パス変換候補内の全てのパスがパスリスト141内に存在しない場合、アプリケーション部200から入力を受け付けたパスを、パス変換装置100により変換されたパスとしてアプリケーション部200に送出する機能。ここで、入力を受け付けたパスは、ロケールを含まないパスであって、例えば、英語圏に対応した画面構成ファイルを示している。なお、この英語圏に対応した画面構成ファイルは、英語圏のみに対応したものでもよく、英語圏に加えて他の所望の言語圏に対応したものでもよい。ロケール管理部120は、アプリケーション部200を利用するアプリケーション利用者のロケールを管理する機能をもっている。ロケールとは、アプリケーション利用者が扱う言語、所属する国や地域を表すものである。Javaでは通常、言語国バリアントという形式で扱われる。日本語であればja、英語であればenと表現され、日本であればjaJP、米国であればenUSと表現される。バリアントまで表すものとしては、セルビア語のsrBALATNがある。ロケールはクライアント装置Cjp,...に利用されるブラウザに設定されており、ブラウザからリクエストをサーバ装置Svに送信する際にロケールも送信される。なお、図1には、日本を表すロケールが設定されたクライアント装置Cjpと、米国を表すロケールが設定されたクライアント装置Cusと、セルビア語を表すロケールが設定されたクライアント装置Csrとを示している。また、アプリケーションによってはブラウザに設定されたロケールではなく、アプリケーションの画面上に日本語English等が記述されたボタンやリンクが表示され、このボタンやリンクをアプリケーション利用者が選択することにより、クライアント装置Cjp,...が利用するロケールをアプリケーション部200に送信する方法をとるものも多く見られる。ロケール管理部120が管理するロケールは、上記ブラウザに設定されたロケールと、ボタンやリンクにより選択されるロケールの両方である。ロケールの管理方法としてはアプリケーションのセッション領域を使用することが可能である。セッションはアプリケーション部200の利用者個々に割り当てられる領域である。セッション領域を利用してロケールを管理することにより、様々な言語を利用する不特定多数の利用者がアプリケーション部200を利用したとしても、各々の利用者のロケールを適切に管理することが可能である。パス変換部130は、パス生成部110により入力を受け付けたパスの一部をパス変換ルール131内の各々の変換ルールに基づいて個別に変換文字列に変換し、当該変換文字列内の変数を、パス生成部110により取得されたロケールに置換することにより、当該入力を受け付けたパスを複数のパスに変換し、当該複数のパスからなるパス変換候補を生成するパス変換機能をもっている。補足すると、変換後のパスは1つではなく複数である。例えば、変換対象のパスがcssappstylecssで、ロケールがjaJPの場合、cssappstylejaJPcsscssappstylejacsscssappstylecssのように変換後のパスが3種類作成される。変換後のパスが複数であることは、ロケールが階層的な意味を持っていることと、javaでロケールを扱う場合にはより狭いロケールの階層から優先的に扱うことに由来する。ロケールがjaJPの場合、第1にjaJPが優先され、次にjaが、その後にロケール情報無しが適用される。このような優先度があることから、変換後のパスを複数作成しておき、パス存在チェック部140でのチェック結果に基づいて、実際に利用するパスを決める方式としている。パス変換ルール131は、ロケールを使いパスをどのように変換するかを定義した情報であり、具体的には、パスの一部である変換対象と、当該変換対象が変換される変換文字列であってロケールを示す変数を含む当該変換文字列とを定義した複数の変換ルールからなる情報である。パス変換部130はこのパス変換ルール131に定義された各変換ルールに基づきパスを変換する。パス変換ルール131は、図2に例を示すように、パス中の変換対象と変換文字列を定義している。変換ルール例1では、パス内のをlocaleに変換するというルールである。localeが変数でありロケールに置換される。パス変換ルール131としては、3つの例を示したが、これに限らず、パス上の一部の文字を、ロケールを含めた文字列に変換する変換ルールであれば、任意の変換ルールを定義可能となっている。図2のパス変換ルール131を用いて、パス変換部130がパスを変換する例を図3に示す。図3はロケールがjaJPの場合のパス変換例を示している。パス変換部130は、予め定義されたパス変換ルール131をメモリ図示せずに書込む機能を有するが、このメモリは、パス変換部130の内部に限らず、パス変換部130の外部にあってもよい。パス存在チェック部140は、パス変換部130により変換された複数のパスからなるパス変換候補内の各パスについてパスリスト141内に存在するかをチェックする機能をもっている。補足すると、パス存在チェック部140は、パスリスト141を利用して、国際化したパスが示す画面構成ファイルが、アプリケーション内に存在するかをチェックするものである。パスリスト141は、各画面構成ファイルを個別に示す各パスのリスト情報であり、図4に示すように、アプリケーションの構造から作成される。パスリスト141は、パス存在チェック部140がパスの存在チェックをする際に、毎回アプリケーション内のパスチェックをする負荷を無くす役割をもっている。パス存在チェック部140は、予め画面構成ファイルの情報をパスリスト141としてメモリ図示せずに書込むことで、パスチェックの効率化を図っている。パスリスト141を書込む構築するタイミングは、アプリケーション起動時もしくは、パス存在チェック部140が最初にパスチェックをするタイミングのいずれかである。なお、パスリスト141が書込まれるメモリは、パス存在チェック部140の内部に限らず、パス存在チェック部140の外部にあってもよい。また、アプリケーション内には画面構成ファイルではないファイルも存在する。たとえばjarファイル等のライブラリファイルやロジックを構成するclassファイルである。JavaEEアプリケーションの場合、これら画面構成ファイルではないファイルの構成が規定されている。JarファイルはAppContextWEBINFlibに配置されることが一般的であり、classファイルはAppContextWEBINFclassesに配置されることが一般的である。パスリスト141を作成する際に、これら画面構成ファイル以外のファイルが配置されるパスをパスリスト141に含めない構成により、パスリスト141の構築とパスのチェックとの効率化を図ることが可能である。なお、以上のようなパス変換装置100は、ハードウェア構成、又はハードウェア資源とソフトウェアとの組合せ構成のいずれでも実施可能となっている。組合せ構成のソフトウェアとしては、予めネットワーク又は記憶媒体からコンピュータにインストールされ、当該コンピュータにパス変換装置100の機能を実現させるためのプログラムが用いられる。また、パス変換装置100は、例えば、パス生成装置、パス管理装置又はリソース管理装置のような他の名称に読み替えてもよい。一方、アプリケーション部200は、国際化に対応したパス変換装置100を利用するアプリケーションプログラムを実行するプロセッサの一機能として実現される。アプリケーション部200のアプリケーションとしては、JavaEEアプリケーションを前提にしている。アプリケーション部200は、クライアント装置Cjpから受けたリクエストに基づいて、国際化に対応したパス変換装置100に対し、国際化未対応ロケールに未対応のパスを入力する機能と、パス変換装置100によりロケールに対応して変換されたパスを受ける機能と、当該受けたパスに基づく画面構成ファイルをクライアント装置Cjpに送信する機能とをもっている。次に、以上のように構成されたパス変換装置が適用されたクライアントサーバシステムの動作を図5のシーケンス図及び図6のフローチャートを用いて説明する。アプリケーション部200は、クライアント装置Cjpから受けたリクエストに基づいて、国際化未対応のパス変換対象パスを含むパス生成依頼メッセージをパス生成部110に入力するST101。パス生成部110は、パス生成依頼メッセージに含まれる変換対象パスの入力を受け付けると、ロケール取得メッセージをロケール管理部120に送出することにより、ロケール管理部120から、現在アプリケーションを利用しているアプリケーション利用者のロケールを取得するST102。パス生成部110は、当該取得したロケールと、当該入力を受け付けた変換対象パスとを含むパス変換候補取得メッセージをパス変換部130に送出するST103。パス変換部130は、パス変換ルール131に定義された各々の変換ルールを取得するST104。パス変換部130は、パス変換候補取得メッセージ内の変換対象パスの一部をパス変換ルール131内の各々の変換ルールに基づいて個別に変換文字列に変換し、当該変換文字列内の変数をパス変換候補取得メッセージ内のロケールに置換することにより、当該変換対象パスを複数のパスに変換し、当該複数のパスからなるパス変換候補リストを生成するST105。これにより、パス生成部110は、ステップST103のパス変換候補取得メッセージに対する戻り値として、変換後の複数のパスからなるパス変換候補リストを取得する。パス生成部110は、当該取得したパス変換候補リスト内の各パスのうち、適切なパスを決定するST106。適切なパスとはアプリケーション内に存在するパスを意味する。ステップST106においては、ロケールの優先度を考慮し、図6のステップST106-1~ST106-8に示すように、優先度の高いものからパス存在チェック部140によるチェックを実行し、存在を確認できたパスを適切なパスとしてアプリケーション部200に返却する。例えば、ステップST106-1において、パス生成部140は、パス変換候補内で最高の優先度をもつパス{言語国バリアント}が付与されたパスを含む存在確認依頼メッセージをパス存在チェック部140に送出する。パス存在チェック部140は、存在確認依頼メッセージを受けると、パスリスト141を参照し、存在確認依頼メッセージ内のパスが当該パスリスト141内に存在するかをチェックしST107,ST108、存在するtrueか否falseかを示すチェック結果をパス生成部140に送出する。ここで、パス存在チェック部140によるチェックの結果、パスリスト141内に存在する場合ST106-2;trueには、パス生成部140は、当該存在するパス{言語国バリアント}が付与されたパスを、変換されたパスとしてアプリケーション部200に送出するST106-8一方、パス存在チェック部140によるチェックの結果、パスリスト141内に存在しない場合ST106-2;falseには、ステップST106-3において、パス生成部110は、次に優先度の高いパス{言語国}が付与されたパスを含む存在確認依頼メッセージをパス存在チェック部140に送出する。パス存在チェック部140は、前述同様に、存在確認依頼メッセージ内のパスをチェックしST107,ST108、チェック結果をパス生成部140に送出する。パス存在チェック部140によるチェックの結果、パスリスト141内に存在する場合ST106-4;trueには、パス生成部140は、当該存在するパス{言語国}が付与されたパスを、変換されたパスとしてアプリケーション部200に送出するST106-8また一方、パス存在チェック部140によるチェックの結果、パスリスト141内に存在しない場合ST106-4;falseには、ステップST106-5において、パス生成部110は、次に優先度の高いパス{言語}が付与されたパスを含む存在確認依頼メッセージをパス存在チェック部140に送出する。パス存在チェック部140は、前述同様に、存在確認依頼メッセージ内のパスをチェックしST107,ST108、チェック結果をパス生成部140に送出する。パス存在チェック部140によるチェックの結果、パスリスト141内に存在する場合ST106-6;trueには、パス生成部140は、当該存在するパス{言語}が付与されたパスを、変換されたパスとしてアプリケーション部200に送出するST106-8また一方、パス存在チェック部140によるチェックの結果、パスリスト141内に存在しない場合ST106-6;falseには、パス生成部110は、ステップST101で入力された変換対象パスロケールを含まないパスを、変換されたパスとしてアプリケーション部200に送出するST106-7,ST106-8。なお、ロケールを含まないパスは、例えば、英語圏に対応した画像構成ファイルを示している。ステップST106-8の完了後、アプリケーション部200は、ステップST101のパス生成依頼メッセージに対する戻り値として、変換されたパスを取得する。アプリケーション部200は、取得したパスに指定された画面構成ファイルの内容を示す画面構成データをリクエストに対するレスポンスとして、クライアント装置Cjpに送信する。クライアント装置Cjpでは、この画面構成データに基づいて画面を表示する。この画面は、画面構成ファイルが利用者のロケールに応じたものであるため、同様に、利用者のロケールに応じた内容が表示される。上述したように本実施形態によれば、入力を受け付けたパスの一部を、利用者のロケールを含む変換文字列に個別に変換することにより、当該入力を受け付けたパスを複数のパスからなるパス変換候補に変換し、当該パス変換候補内の各パスについてパスリスト141内に存在するかをチェックし、存在するパスを変換されたパスとしてアプリケーション部200に送出する構成により、アプリケーション毎に仕組みを作成せずに画面の構成や入力項目の数をロケール毎に切替え可能であることに加え、ロケール毎に切り替える対象を管理する必要を無くすことができる。補足すると、本実施形態によれば、ロケールに合わせて利用する画面構成ファイルを切替える仕組みをアプリケーションにコーディングする必要がなく、開発効率と保守性を向上させることができる。また、本実施形態によれば、アプリケーションの実際の構造を元にロケールと画面構成ファイルの対応を判断するため、別途テーブルなどによりロケールと画面構成ファイルの関係を管理することによる不整合実構成とテーブルの不整合がなく、品質を向上させることができる。さらに、本実施形態によれば、アプリケーションとして対応するロケールの追加が画面構成ファイルの追加だけで済むため、アプリケーションの拡張性を向上させることができる。<第2の実施形態>図7は第2の実施形態に係るパス変換装置が適用されたクライアントサーバシステムの構成を示す模式図であり、図1と同一部分には同一符号を付してその詳しい説明を省略し、ここでは異なる部分について主に述べる。なお、以下の各実施形態も同様にして重複した説明を省略する。すなわち、第2の実施形態は、第1の実施形態の適用例であり、アプリケーション部200における画面遷移に適用した場合、表示する画面がロケール毎に切替え可能となっている。画面遷移を行なう場合、通常、アプリケーション部200を実行するアプリケーションサーバ部400に対して次に表示する画面を指示する。指示は、通常、画面ファイルへのパスを用いる。このとき、アプリケーション部200とアプリケーションサーバ部400の間にパス変換装置100を介在させることで、アプリケーションのコード内に国際化に対応した切替え処理のコードが不要となる。アプリケーションを開発する場合、アプリケーション部200とアプリケーションサーバ部400との間の層にフレームワークというソフトウェアを導入するのが一般的であり、例えば、このフレームワークの実行により実現される機能部がパス変換装置100を含んでいる。これに伴い、本実施形態のサーバ装置Svは、図1に示したアプリケーション部200とパス変換装置100との間に画面遷移パス処理部300が配置され、画面遷移パス処理部300にはアプリケーションサーバ部400が接続されている。ここで、画面遷移パス処理部300は、例えば、フレームワークの1機能として組み込まれて実装される。画面遷移パス処理部300は、アプリケーション部200により次の画面が指定された場合に実行される。画面遷移パス処理部300は、アプリケーション部200が指定した次の画面のパスを、パス変換装置100によって、国際化したパスに変換する。画面遷移パス処理部300は、国際化したパスを次の画面としてアプリケーションサーバ部400に通知する。補足すると、アプリケーション部200とアプリケーションサーバ部400との間に画面遷移パス処理部300が介在することで、アプリケーション部200が、次の画面を指定するパスに対し、ロケールによる切替えを意識することがない。アプリケーションサーバ部400は、アプリケーションを動作させるミドルウェアアプリケーションサーバの実行により実現される機能部である。アプリケーションサーバ部400は、画面遷移パス処理部300が指定するパス上にある画面ファイルをクライアント装置Cjpに表示させる。次に、以上のように構成されたクライアントサーバシステムの動作を図8のシーケンス図を用いて説明する。なお、ステップST101’,ST108’は、前述したステップST101,ST108と同様の処理であるが、入出力先などが前述とは異なるため、’の符号をステップ番号に付している。アプリケーション部200は、次に表示する画面のパスを指定するメッセージを画面遷移パス処理部300に送出するST10。JavaEEアプリケーションでは、通常、画面の指定にはパスを利用する。本実施形態でも、通常のJavaEEアプリケーションと同様に、パスにより次の画面を指定する。例えば、menuhtmlのように指定する。画面遷移パス処理部300は、指定された次の画面のパスを含む国際化依頼メッセージパス変換依頼メッセージをパス変換装置100に入力するST101’。パス変換装置100は、前述したステップST102~ST107と同様に、入力を受け付けたパスを、国際化したパスに変換しST102~ST107、当該変換されたパスを画面遷移パス処理部300に送出するST108’。例えば、アプリケーションの構造が図4に示す構造で、利用者のロケールが日本の場合は、国際化した次の画面のパスとしてmenujahtmlが生成される。利用者のロケールが米国などの英語圏の場合は、国際化した次の画面のパスとしてmenuenhtmlが生成される。利用者のロケールが日本でも英語圏でもない場合は、menuhtmlが国際化した次の画面のパスとして生成される。画面遷移パス処理部300は、パス変換装置100により、国際化した次の画面のパスを指定するメッセージをアプリケーションサーバ部400に送出するST110。アプリケーションサーバ部400は、ステップST110で指定されたパスに基づいて、当該パスが示す画面構成ファイルの内容を含む画面構成データを作成し、この画面構成データを、次の画面としてクライアント装置Cjpに表示させる。上述したように本実施形態によれば、第1の実施形態の効果に加え、アプリケーション部200における画面遷移に適用した場合であっても、表示する画面をロケール毎に切替えることができる。<第3の実施形態>図9は第3の実施形態に係るパス変換装置が適用されたクライアントサーバシステムの構成を示す模式図である。第3の実施形態は、第1の実施形態の他の適用例であり、画面ファイルから参照されるファイルの指定に適用した場合、参照されるファイルがロケール毎に切替え可能となっている。画面ファイルから参照されるファイルとしては、画像ファイル、スタイルシート、JavaScriptファイル等がある。これらファイルを参照する場合、画面ファイル内に参照するファイルへのパスを記述する。参照するファイルへのパスの部分にパス変換装置100を適用することで、記述するファイルへのパスに対して国際化を意識しなくても、実際に参照されるパスが国際化されたパスになる。JavaEEアプリケーションでは、画面ファイルは、JSPJavaServerPagesで記述されることが一般的である。JSPを記述する技術としてタグライブラリという技術がある。本実施形態は、パス変換装置100の技術をタグライブラリが利用する例を示す。これに伴い、本実施形態のサーバ装置Svは、図1に示したアプリケーション部200に代えて、画面アプリケーション部500及び参照パス国際化部600を備えている。ここで、画面アプリケーション部500は、画面ファイルにより画面を生成する画面アプリケーションを実行する機能部である。JavaEEアプリケーションでは、通常、JSPとして画面ファイルが作成されるが、JSP以外の技術で画面ファイルを作成してもよい。参照パス国際化部600は、画面アプリケーション部500の画面ファイル内に指定されるパスを国際化する機能部である。画面ファイルをJSPとして作成した場合、参照パス国際化部600は、タグライブラリという形式を用いることが一般的であるが、タグライブラリ以外の形式を用いてもよい。次に、以上のように構成されたクライアントサーバシステムの動作を図10のシーケンス図を用いて説明する。なお、ステップST101,ST108は、前述したステップST101,ST108と同様の処理であるが、入出力先などが前述とは異なるため、の符号をステップ番号に付している。画面アプリケーション部500は、参照するファイルを示す参照パスを指定するメッセージを参照パス国際化部600に送出するST20。JavaEEアプリケーションでは、例えばcssappstylecssのように、参照パスを指定する。参照パス国際化部600は、指定された参照パスを含む国際化依頼メッセージパス変換依頼メッセージをパス変換装置100に入力するST101。パス変換装置100は、前述したステップST102~ST107と同様に、入力を受け付けたパスを国際化したパスに変換しST102~ST107、当該変換されたパスを参照パス国際化部600に送出するST108。例えば、アプリケーションの構造が図4に示す構造で、利用者のロケールが日本の場合は、国際化した参照パスとしてcssappstylejacssが生成される。利用者のロケールが日本以外の場合は、cssappstylecssが国際化した参照パスとして生成される。ここで、国際化した参照パスは、アプリケーションの内部構造に基づくものである。画面ファイルから参照するパスは、パス指定の仕方によっては内部構造のパスだけではなく、アプリケーションのルートアプリケーションコンテキストから指定する必要がある。図4に示す構成の場合、参照パス国際化部600は、参照パスcssappstylejacssを参照パスAppContextcssappstylejacssのように先頭にアプリケーションコンテキストを付与するST120。本処理は必須ではなくオプションである。画面アプリケーション部500は、国際化した参照パスを画面に設定画面構成データに設定するST122。国際化した参照パスが設定された画面構成データは、クライアント装置Cjpに送信される。クライアント装置Cjpは、この画面構成データに基づいて、国際化した画面を表示する。図11は画面構成ファイル内のパスの変換例を示す模式図である。図11上側に示す変換前の画面構成ファイルf1において、というタグライブラリのバリューvalueには、国際化されていない参照パスが定義されている。この参照パスを含むのタグの部分は、図11下側の変換後の画面構成ファイルf1jp,f1enに示すように、前述した処理によって、国際化した参照パスに変換される。上述したように本実施形態によれば、第1の実施形態の効果に加え、画面ファイルから参照されるファイルの指定に適用した場合、参照されるファイルをロケール毎に切替えることができる。以上説明した少なくとも一つの実施形態によれば、パス変換装置100が、入力を受け付けたパスを、アプリケーション利用者のロケールを含むパスに変換し、当該変換したパスを送出する構成により、アプリケーション毎に仕組みを作成せずに画面の構成や入力項目の数をロケール毎に切替え可能であることに加え、ロケール毎に切り替える対象を管理する必要を無くすことができる。なお、上記の各実施形態に記載した手法は、コンピュータに実行させることのできるプログラムとして、磁気ディスクフロッピー登録商標ディスク、ハードディスクなど、光ディスクCD-ROM、DVDなど、光磁気ディスクMO、半導体メモリなどの記憶媒体に格納して頒布することもできる。また、この記憶媒体としては、プログラムを記憶でき、かつコンピュータが読み取り可能な記憶媒体であれば、その記憶形式は何れの形態であっても良い。また、記憶媒体からコンピュータにインストールされたプログラムの指示に基づきコンピュータ上で稼働しているOSオペレーティングシステムや、データベース管理ソフト、ネットワークソフト等のMWミドルウェア等が上記実施形態を実現するための各処理の一部を実行しても良い。さらに、各実施形態における記憶媒体は、コンピュータと独立した媒体に限らず、LANやインターネット等により伝送されたプログラムをダウンロードして記憶または一時記憶した記憶媒体も含まれる。また、記憶媒体は1つに限らず、複数の媒体から上記の各実施形態における処理が実行される場合も本発明における記憶媒体に含まれ、媒体構成は何れの構成であっても良い。なお、各実施形態におけるコンピュータは、記憶媒体に記憶されたプログラムに基づき、上記の各実施形態における各処理を実行するものであって、パソコン等の1つからなる装置、複数の装置がネットワーク接続されたシステム等の何れの構成であっても良い。また、各実施形態におけるコンピュータとは、パソコンに限らず、情報処理機器に含まれる演算処理装置、マイコン等も含み、プログラムによって本発明の機能を実現することが可能な機器、装置を総称している。なお、本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。"