パス変換装置及びプログラム
【課題】 アプリケーション毎に仕組みを作成せずに画面の構成や入力項目の数をロケール毎に切替え可能である上、ロケール毎に切り替える対象を管理する必要を無くす。
【解決手段】 実施形態のパス変換装置は、パス変換手段、パス存在チェック手段及びパス送出手段を備えている。前記パス変換手段は、前記入力を受け付けたパスの一部を前記パス変換ルール内の各々の変換ルールに基づいて個別に前記変換文字列に変換し、当該変換文字列内の変数を前記取得されたロケールに置換することにより、当該入力を受け付けたパスを複数のパスに変換し、当該複数のパスからなるパス変換候補を生成する。前記パス存在チェック手段は、当該パス変換候補内の各パスについて前記リスト情報内に存在するかをチェックする。前記パス送出手段は、前記チェックの結果、前記存在するパスを前記変換されたパスとして前記アプリケーション部に送出する。
【解決手段】 実施形態のパス変換装置は、パス変換手段、パス存在チェック手段及びパス送出手段を備えている。前記パス変換手段は、前記入力を受け付けたパスの一部を前記パス変換ルール内の各々の変換ルールに基づいて個別に前記変換文字列に変換し、当該変換文字列内の変数を前記取得されたロケールに置換することにより、当該入力を受け付けたパスを複数のパスに変換し、当該複数のパスからなるパス変換候補を生成する。前記パス存在チェック手段は、当該パス変換候補内の各パスについて前記リスト情報内に存在するかをチェックする。前記パス送出手段は、前記チェックの結果、前記存在するパスを前記変換されたパスとして前記アプリケーション部に送出する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、国際化に対応した画面表示のためのパス変換装置及びプログラムに関する。
【背景技術】
【０００２】
アプリケーションの国際化とは、利用者のロケール（言語・国・地域を表すもの）に合わせて、画面の表示内容や処理を切替えることである。
【０００３】
Java（登録商標） EEアプリケーションを国際化する場合、リソースバンドルという技術が一般的に用いられる。リソースバンドルは、文字列をロケール毎に管理する機能である。リソースバンドルによれば、利用者のロケールに合わせて、画面に表示される文字列を切替可能となる。例えば、日本語の利用者に対しては画面内の文字列を日本語に切り替え、英語の利用者に対しては画面内の文字列を英語に切り替えることが可能となる。
【０００４】
また、Java EEアプリケーションの分野で活動が活発なＯＳＳ（Open Source Software）のフレームワークには、文字列だけでなく、利用者が入力したデータのバリデーションや、日付、数値、通貨のフォーマットを切替える仕組みを持つものも存在する。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０００−１１２７０８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、以上のようなリソースバンドルやＯＳＳのフレームワークは、通常は何の問題もないが、本発明者の検討によれば、第１及び第２の点で改良の余地がある。
【０００７】
第１の点は、切替える対象が、文字列単位や入力項目単位という画面内の１要素である点である。実際のシステム開発では、１要素単位の切替えで済まず、画面の構成（レイアウト）や入力項目数の数をロケール毎に切替える必要に迫られることがある。例えば、ロケールが日本語の画面と英語の画面では、同じ内容の文であっても文を構成する文字列の文字数が大幅に異なるため、ロケールに応じて画面の構成を切り替える必要がある。
【０００８】
また例えば、名前を入力するフォームの場合、ロケールが日本語の画面では、姓、名の順にフォームが配置された構成に加え、漢字とフリガナの入力項目が必要になる。
【０００９】
しかしながら、ロケールが英語の画面では、名、姓の順にフォームが配置された構成だけで済み、漢字とフリガナの入力項目が不要となる。従って、画面の構成や入力項目数をロケール毎に切替えるためには、個々のアプリケーション毎に仕組みを作成する必要がある。
【００１０】
第２の点は、ロケール毎に切替える対象を管理する必要がある点である。例えば、リソースバンドルであれば、ロケールと文字列の対応を定義し管理する必要がある。また、バリデーションであれば、ロケールとバリデーションルールの関係を定義し管理する必要がある。そのため、切替え対象を追加／変更する場合、切替え対象の作成作業と関係定義の更新作業という２段階の作業が必要になる。
【００１１】
本発明が解決しようとする課題は、アプリケーション毎に仕組みを作成せずに画面の構成や入力項目の数をロケール毎に切替え可能であることに加え、ロケール毎に切り替える対象を管理する必要を無くし得るパス変換装置及びプログラムを提供することである。
【課題を解決するための手段】
【００１２】
実施形態のパス変換装置は、ロケールに応じた複数の画面構成ファイルを含むアプリケーションを実行するアプリケーション部から前記各画面構成ファイルを指定するパスの入力を受け付ける。前記パス変換装置は、当該入力を受け付けたパスを前記アプリケーションの利用者のロケールに応じて変換し、当該変換されたパスを前記アプリケーション部に送出する。
【００１３】
前記パス変換装置は、ロケール管理手段、パスリスト記憶手段、変換ルール記憶手段、ロケール取得手段、パス変換手段、パス存在チェック手段及びパス送出手段を備えている。
【００１４】
前記ロケール管理手段は、前記利用者のロケールを管理する。
【００１５】
前記パスリスト記憶手段は、前記各画面構成ファイルを個別に示す各パスのリスト情報を記憶する。
【００１６】
前記変換ルール記憶手段は、前記パスの一部である変換対象と、当該変換対象が変換される変換文字列であってロケールを示す変数を含む前記変換文字列とを定義した複数の変換ルールからなるパス変換ルールを記憶する。
【００１７】
前記ロケール取得手段は、前記アプリケーション部からパスの入力を受け付けると、ロケール管理手段からロケールを取得する。
【００１８】
前記パス変換手段は、前記入力を受け付けたパスの一部を前記パス変換ルール内の各々の変換ルールに基づいて個別に前記変換文字列に変換し、当該変換文字列内の変数を前記取得されたロケールに置換することにより、当該入力を受け付けたパスを複数のパスに変換し、当該複数のパスからなるパス変換候補を生成する。
【００１９】
前記パス存在チェック手段は、当該パス変換候補内の各パスについて前記リスト情報内に存在するかをチェックする。
【００２０】
前記パス送出手段は、前記パス存在チェック手段によるチェックの結果、前記リスト情報内に存在するパスを前記変換されたパスとして前記アプリケーション部に送出する。
【図面の簡単な説明】
【００２１】
【図１】第１の実施形態に係るパス変換装置が適用されたクライアントサーバシステムの構成を示す模式図である。
【図２】同実施形態におけるパス変換ルールの例を示す模式図である。
【図３】同実施形態におけるパスを変換する例を示す模式図である。
【図４】同実施形態におけるパスリストを説明するための模式図である。
【図５】同実施形態における動作を説明するためのシーケンス図である。
【図６】同実施形態における動作の一部を説明するためのフローチャートである。
【図７】第２の実施形態に係るパス変換装置が適用されたクライアントサーバシステムの構成を示す模式図である。
【図８】同実施形態における動作を説明するためのシーケンス図である。
【図９】第３の実施形態に係るパス変換装置が適用されたクライアントサーバシステムの構成を示す模式図である。
【図１０】同実施形態における動作を説明するためのシーケンス図である。
【図１１】同実施形態における画面構成ファイル内のパスの変換例を示す模式図である。
【発明を実施するための形態】
【００２２】
以下、各実施形態について図面を用いて説明するが、その前に各実施形態に共通する概要を述べる。
【００２３】
各実施形態は、ロケール毎に切替える対象を画面の要素単位だけではなく、利用するファイル自体を切替える仕組みを述べている。切り替え対象は、画面構成ファイル（HTMLやJSP等の画面ファイルや画面から参照されるスタイルシート、画像ファイル、JavaScript（登録商標）ファイル等）である。切替える方法として、画面構成ファイルへのパスを、ロケール情報を含めたパスへ自動で変換する仕組みを述べている。
【００２４】
このような各実施形態によれば、画面構成ファイルを切替える構成により、画面の構成（レイアウト，入力項目の増減）、画面上で動作するロジック（Javascript）などをロケール毎に変更することが可能となる。
【００２５】
また、各実施形態によれば、ロケールと切替え対象の画面構成ファイルの関係を、パス変換ルールとアプリケーション内の構造により管理する構成により、個々の画面構成ファイルとロケールの対応関係を別途管理する必要を無くすことができる。
【００２６】
従って、各実施形態によれば、アプリケーション毎に仕組みを作成せずに画面の構成や入力項目の数をロケール毎に切替え可能であることに加え、ロケール毎に切り替える対象を管理する必要を無くすことができる。以上が各実施形態に共通する概要である。続いて、各実施形態について具体的に説明する。
【００２７】
＜第１の実施形態＞
図１は第１の実施形態に係るパス変換装置が適用されたクライアントサーバシステムの構成を示す模式図である。このクライアントサーバシステムは、複数のクライアント装置Ｃjp，…，Ｃus，…，Ｃsr，…がネットワークを介してサーバ装置Ｓｖに接続されている。なお、各クライアント装置Ｃjp，…，Ｃus，…，Ｃsr，…の添字｛jp｝，｛us｝，｛sr｝は、それぞれ設定されたロケールが日本、米国及びセルビア語を示すことを表している。また、各クライアント装置Ｃjp，…，Ｃus，…，Ｃsr，…は、ロケールが示す内容を除き、互いに同一構成のブラウザを有するため、ここでは日本を示すロケールがブラウザに設定されたクライアント装置Ｃjpを代表例に挙げて説明する。
【００２８】
クライアント装置Ｃjpは、通常のブラウザを有する通常のコンピュータであり、具体的には例えば、ユーザの操作により、ロケールを含むリクエストをサーバ装置Ｓｖに送信する機能と、ロケールを表すリンクやボタンの選択操作により、当該選択されたロケールをサーバ装置Ｓｖに送信する機能と、サーバ装置Ｓｖから画面構成ファイルの内容を示す画面構成データを受けると、この画面構成データに基づいて画面を表示する機能とを備えたブラウザを有している。なお、ロケールを含むリクエストをサーバに送信することは、ＨＴＴＰ（HyperText Transfer Protocol）に定められている。
【００２９】
一方、サーバ装置Ｓｖは、パス変換装置１００及びアプリケーション部２００を備えている。
【００３０】
パス変換装置１００は、ロケールに応じた複数の画面構成ファイルを含むアプリケーションを実行するアプリケーション部２００から当該各画面構成ファイルを指定するパスの入力を受け付けると、当該パスを当該アプリケーションの利用者のロケールに応じて変換し、当該変換されたパスをアプリケーション部２００に送出する機能をもっている。
【００３１】
補足すると、パス変換装置２００は、利用者の国際化に対応し、画面構成ファイルへのパスを国際化したパスに変換する装置である。
【００３２】
国際化したパスとは、パス内にロケール情報を含んだパスを意味する。例えばアプリケーション部２００から入力されたパスが”/index.jsp”とした場合、国際化したパスは、”/index_ja_JP.jsp”や”/ja_JP/index.jsp”のようにロケールを表す”ja_JP”をパスに含めたものである。アプリケーション部２００から入力されるパスをどのように国際化したパスに変換するかのルールはパス変換ルール１３１に定義される。なお、国際化したパスは、ロケールに応じたパスと呼んでもよい。
【００３３】
このようなパス変換装置１００は、具体的には、パス生成部１１０、ロケール管理部１２０、パス変換部１３０及びパス存在チェック部１４０を備えている。
【００３４】
パス生成部１１０は、アプリケーション部２００からの入力であるパスを受付け、適切に国際化したパスを返却する部分である。適切に国際化したパスとは、パス変換ルール１３１に定義されたルールにより変換され、且つアプリケーション内にそのパスが示す画面構成ファイルが存在するものである。
【００３５】
このようなパス生成部１１０は、具体的には例えば、以下の機能(f110-1)〜(f110-3)をもっている。
【００３６】
(f110-1) アプリケーション部２００からパスの入力を受け付けると、ロケール管理部１２０からロケールを取得する機能。
【００３７】
(f110-2) 当該取得したロケールと、当該入力を受け付けたパスとをパス変換部１３０に送出し、パス変換部１３０から変換後の複数のパスからなるパス変換候補を受ける機能。なお、この機能(f110-2)は必須ではなく、例えば、パス生成部１１０とパス変換部１３０とを一体的に設けることにより、省略可能である。
【００３８】
(f110-3) 当該パス変換候補をパス存在チェック部１４０に送出する機能。
【００３９】
(f110-4) パス存在チェック部１４０によるチェックの結果、パスリスト（各パスのリスト情報）１４１内に存在するパスを、パス変換装置１００により変換されたパスとしてアプリケーション部２００に送出するパス送出機能。
【００４０】
また、パス変換部１１０は、さらに、以下の機能(f110-5)を備えてもよい。
【００４１】
(f110-5) パス存在チェック部１４０によるチェックの結果、パス変換候補内の全てのパスがパスリスト１４１内に存在しない場合、アプリケーション部２００から入力を受け付けたパスを、パス変換装置１００により変換されたパスとしてアプリケーション部２００に送出する機能。ここで、入力を受け付けたパスは、ロケールを含まないパスであって、例えば、英語圏に対応した画面構成ファイルを示している。なお、この英語圏に対応した画面構成ファイルは、英語圏のみに対応したものでもよく、英語圏に加えて他の所望の言語圏に対応したものでもよい。
【００４２】
ロケール管理部１２０は、アプリケーション部２００を利用するアプリケーション利用者のロケールを管理する機能をもっている。ロケールとは、アプリケーション利用者が扱う言語、所属する国や地域を表すものである。Javaでは通常、「言語_国_バリアント」という形式で扱われる。日本語であれば「ja」、英語であれば「en」と表現され、日本であれば「ja_JP」、米国であれば「en_US」と表現される。バリアントまで表すものとしては、セルビア語(ボスニア・ヘルツェゴビナ、ラテン)の「sr_BA_LATN」がある。
【００４３】
ロケールはクライアント装置Ｃjp，…に利用されるブラウザに設定されており、ブラウザからリクエストをサーバ装置Ｓｖに送信する際にロケールも送信される。なお、図１には、日本を表すロケールが設定されたクライアント装置Ｃjpと、米国を表すロケールが設定されたクライアント装置Ｃusと、セルビア語を表すロケールが設定されたクライアント装置Ｃsrとを示している。
【００４４】
また、アプリケーションによってはブラウザに設定されたロケールではなく、アプリケーションの画面上に「日本語」「English」等が記述されたボタンやリンクが表示され、このボタンやリンクをアプリケーション利用者が選択することにより、クライアント装置Ｃjp，…が利用するロケールをアプリケーション部２００に送信する方法をとるものも多く見られる。
【００４５】
ロケール管理部１２０が管理するロケールは、上記ブラウザに設定されたロケールと、ボタンやリンクにより選択されるロケールの両方である。ロケールの管理方法としてはアプリケーションのセッション領域を使用することが可能である。セッションはアプリケーション部２００の利用者個々に割り当てられる領域である。セッション領域を利用してロケールを管理することにより、様々な言語を利用する不特定多数の利用者がアプリケーション部２００を利用したとしても、各々の利用者のロケールを適切に管理することが可能である。
【００４６】
パス変換部１３０は、パス生成部１１０により入力を受け付けたパスの一部をパス変換ルール１３１内の各々の変換ルールに基づいて個別に変換文字列に変換し、当該変換文字列内の変数を、パス生成部１１０により取得されたロケールに置換することにより、当該入力を受け付けたパスを複数のパスに変換し、当該複数のパスからなるパス変換候補を生成するパス変換機能をもっている。
【００４７】
補足すると、変換後のパスは１つではなく複数である。例えば、変換対象のパスが「/css/app-style.css」で、ロケールが「ja_JP」の場合、「/css/app-style_ja_JP.css」「/css/app-style_ja.css」「/css/app-style.css」のように変換後のパスが３種類作成される。
【００４８】
変換後のパスが複数であることは、ロケールが階層的な意味を持っていることと、javaでロケールを扱う場合にはより狭いロケールの階層から優先的に扱うことに由来する。ロケールが「ja_JP」の場合、第１に「ja_JP」が優先され、次に「ja」が、その後に「ロケール情報無し」が適用される。このような優先度があることから、変換後のパスを複数作成しておき、パス存在チェック部１４０でのチェック結果に基づいて、実際に利用するパスを決める方式としている。
【００４９】
パス変換ルール１３１は、ロケールを使いパスをどのように変換するかを定義した情報であり、具体的には、パスの一部である変換対象と、当該変換対象が変換される変換文字列であってロケールを示す変数を含む当該変換文字列とを定義した複数の変換ルールからなる情報である。パス変換部１３０はこのパス変換ルール１３１に定義された各変換ルールに基づきパスを変換する。パス変換ルール１３１は、図２に例を示すように、パス中の変換対象と変換文字列を定義している。変換ルール例１では、パス内の”.”を”_${locale}.”に変換するというルールである。”${locale}”が変数でありロケールに置換される。パス変換ルール１３１としては、３つの例を示したが、これに限らず、パス上の一部の文字を、ロケールを含めた文字列に変換する変換ルールであれば、任意の変換ルールを定義可能となっている。図２のパス変換ルール１３１を用いて、パス変換部１３０がパスを変換する例を図３に示す。図３はロケールが「ja_JP」の場合のパス変換例を示している。パス変換部１３０は、予め定義されたパス変換ルール１３１をメモリ（図示せず）に書込む機能を有するが、このメモリは、パス変換部１３０の内部に限らず、パス変換部１３０の外部にあってもよい。
【００５０】
パス存在チェック部１４０は、パス変換部１３０により変換された複数のパスからなるパス変換候補内の各パスについてパスリスト１４１内に存在するかをチェックする機能をもっている。補足すると、パス存在チェック部１４０は、パスリスト１４１を利用して、国際化したパスが示す画面構成ファイルが、アプリケーション内に存在するかをチェックするものである。
【００５１】
パスリスト１４１は、各画面構成ファイルを個別に示す各パスのリスト情報であり、図４に示すように、アプリケーションの構造から作成される。パスリスト１４１は、パス存在チェック部１４０がパスの存在チェックをする際に、毎回アプリケーション内のパスチェックをする負荷を無くす役割をもっている。パス存在チェック部１４０は、予め画面構成ファイルの情報をパスリスト１４１としてメモリ（図示せず）に書込むことで、パスチェックの効率化を図っている。パスリスト１４１を書込む（構築する）タイミングは、アプリケーション起動時もしくは、パス存在チェック部１４０が最初にパスチェックをするタイミングのいずれかである。なお、パスリスト１４１が書込まれるメモリは、パス存在チェック部１４０の内部に限らず、パス存在チェック部１４０の外部にあってもよい。
【００５２】
また、アプリケーション内には画面構成ファイルではないファイルも存在する。たとえばjarファイル等のライブラリファイルやロジックを構成するclassファイルである。Java EEアプリケーションの場合、これら画面構成ファイルではないファイルの構成が規定されている。JarファイルはAppContext/WEB-INF/libに配置されることが一般的であり、classファイルはAppContext/WEB-INF/classesに配置されることが一般的である。パスリスト１４１を作成する際に、これら画面構成ファイル以外のファイルが配置されるパスをパスリスト１４１に含めない構成により、パスリスト１４１の構築とパスのチェックとの効率化を図ることが可能である。
【００５３】
なお、以上のようなパス変換装置１００は、ハードウェア構成、又はハードウェア資源とソフトウェアとの組合せ構成のいずれでも実施可能となっている。組合せ構成のソフトウェアとしては、予めネットワーク又は記憶媒体からコンピュータにインストールされ、当該コンピュータにパス変換装置１００の機能を実現させるためのプログラムが用いられる。また、パス変換装置１００は、例えば、パス生成装置、パス管理装置又はリソース管理装置のような他の名称に読み替えてもよい。
【００５４】
一方、アプリケーション部２００は、国際化に対応したパス変換装置１００を利用するアプリケーション（プログラム）を実行するプロセッサの一機能として実現される。アプリケーション部２００のアプリケーションとしては、Java EEアプリケーションを前提にしている。アプリケーション部２００は、クライアント装置Ｃjpから受けたリクエストに基づいて、国際化に対応したパス変換装置１００に対し、国際化未対応（ロケールに未対応）のパスを入力する機能と、パス変換装置１００によりロケールに対応して変換されたパスを受ける機能と、当該受けたパスに基づく画面構成ファイルをクライアント装置Ｃjpに送信する機能とをもっている。
【００５５】
次に、以上のように構成されたパス変換装置が適用されたクライアントサーバシステムの動作を図５のシーケンス図及び図６のフローチャートを用いて説明する。
【００５６】
アプリケーション部２００は、クライアント装置Ｃjpから受けたリクエストに基づいて、国際化未対応のパス（変換対象パス）を含むパス生成依頼メッセージをパス生成部１１０に入力する（ＳＴ１０１）。
【００５７】
パス生成部１１０は、パス生成依頼メッセージに含まれる変換対象パスの入力を受け付けると、ロケール取得メッセージをロケール管理部１２０に送出することにより、ロケール管理部１２０から、現在アプリケーションを利用しているアプリケーション利用者のロケールを取得する（ＳＴ１０２）。
【００５８】
パス生成部１１０は、当該取得したロケールと、当該入力を受け付けた変換対象パスとを含むパス変換候補取得メッセージをパス変換部１３０に送出する（ＳＴ１０３）。
【００５９】
パス変換部１３０は、パス変換ルール１３１に定義された各々の変換ルールを取得する（ＳＴ１０４）。
【００６０】
パス変換部１３０は、パス変換候補取得メッセージ内の変換対象パスの一部をパス変換ルール１３１内の各々の変換ルールに基づいて個別に変換文字列に変換し、当該変換文字列内の変数をパス変換候補取得メッセージ内のロケールに置換することにより、当該変換対象パスを複数のパスに変換し、当該複数のパスからなるパス変換候補リストを生成する（ＳＴ１０５）。
【００６１】
これにより、パス生成部１１０は、ステップＳＴ１０３のパス変換候補取得メッセージに対する戻り値として、変換後の複数のパスからなるパス変換候補リストを取得する。
【００６２】
パス生成部１１０は、当該取得したパス変換候補リスト内の各パスのうち、適切なパスを決定する（ＳＴ１０６）。適切なパスとはアプリケーション内に存在するパスを意味する。ステップＳＴ１０６においては、ロケールの優先度を考慮し、図６のステップＳＴ１０６−１〜ＳＴ１０６−８に示すように、優先度の高いものからパス存在チェック部１４０によるチェックを実行し、存在を確認できたパスを適切なパスとしてアプリケーション部２００に返却する。
【００６３】
例えば、ステップＳＴ１０６−１において、パス生成部１４０は、パス変換候補内で最高の優先度をもつパス（｛言語_国_バリアント｝が付与されたパス）を含む存在確認依頼メッセージをパス存在チェック部１４０に送出する。
【００６４】
パス存在チェック部１４０は、存在確認依頼メッセージを受けると、パスリスト１４１を参照し、存在確認依頼メッセージ内のパスが当該パスリスト１４１内に存在するかをチェックし（ＳＴ１０７，ＳＴ１０８）、存在する（true）か否（false）かを示すチェック結果をパス生成部１４０に送出する。
【００６５】
ここで、パス存在チェック部１４０によるチェックの結果、パスリスト１４１内に存在する場合（ＳＴ１０６−２；true）には、パス生成部１４０は、当該存在するパス（｛言語_国_バリアント｝が付与されたパス）を、変換されたパスとしてアプリケーション部２００に送出する（ＳＴ１０６−８）
一方、パス存在チェック部１４０によるチェックの結果、パスリスト１４１内に存在しない場合（ＳＴ１０６−２；false）には、ステップＳＴ１０６−３において、パス生成部１１０は、次に優先度の高いパス（｛言語_国｝が付与されたパス）を含む存在確認依頼メッセージをパス存在チェック部１４０に送出する。
【００６６】
パス存在チェック部１４０は、前述同様に、存在確認依頼メッセージ内のパスをチェックし（ＳＴ１０７，ＳＴ１０８）、チェック結果をパス生成部１４０に送出する。
【００６７】
パス存在チェック部１４０によるチェックの結果、パスリスト１４１内に存在する場合（ＳＴ１０６−４；true）には、パス生成部１４０は、当該存在するパス（｛言語_国｝が付与されたパス）を、変換されたパスとしてアプリケーション部２００に送出する（ＳＴ１０６−８）
また一方、パス存在チェック部１４０によるチェックの結果、パスリスト１４１内に存在しない場合（ＳＴ１０６−４；false）には、ステップＳＴ１０６−５において、パス生成部１１０は、次に優先度の高いパス（｛言語｝が付与されたパス）を含む存在確認依頼メッセージをパス存在チェック部１４０に送出する。
【００６８】
パス存在チェック部１４０は、前述同様に、存在確認依頼メッセージ内のパスをチェックし（ＳＴ１０７，ＳＴ１０８）、チェック結果をパス生成部１４０に送出する。
【００６９】
パス存在チェック部１４０によるチェックの結果、パスリスト１４１内に存在する場合（ＳＴ１０６−６；true）には、パス生成部１４０は、当該存在するパス（｛言語｝が付与されたパス）を、変換されたパスとしてアプリケーション部２００に送出する（ＳＴ１０６−８）
また一方、パス存在チェック部１４０によるチェックの結果、パスリスト１４１内に存在しない場合（ＳＴ１０６−６；false）には、パス生成部１１０は、ステップＳＴ１０１で入力された変換対象パス（ロケールを含まないパス）を、変換されたパスとしてアプリケーション部２００に送出する（ＳＴ１０６−７，ＳＴ１０６−８）。なお、ロケールを含まないパスは、例えば、英語圏に対応した画像構成ファイルを示している。
【００７０】
ステップＳＴ１０６−８の完了後、アプリケーション部２００は、ステップＳＴ１０１のパス生成依頼メッセージに対する戻り値として、変換されたパスを取得する。
【００７１】
アプリケーション部２００は、取得したパスに指定された画面構成ファイルの内容を示す画面構成データをリクエストに対するレスポンスとして、クライアント装置Ｃjpに送信する。
【００７２】
クライアント装置Ｃjpでは、この画面構成データに基づいて画面を表示する。この画面は、画面構成ファイルが利用者のロケールに応じたものであるため、同様に、利用者のロケールに応じた内容が表示される。
【００７３】
上述したように本実施形態によれば、入力を受け付けたパスの一部を、利用者のロケールを含む変換文字列に個別に変換することにより、当該入力を受け付けたパスを複数のパスからなるパス変換候補に変換し、当該パス変換候補内の各パスについてパスリスト１４１内に存在するかをチェックし、存在するパスを変換されたパスとしてアプリケーション部２００に送出する構成により、アプリケーション毎に仕組みを作成せずに画面の構成や入力項目の数をロケール毎に切替え可能であることに加え、ロケール毎に切り替える対象を管理する必要を無くすことができる。
【００７４】
補足すると、本実施形態によれば、ロケールに合わせて利用する画面構成ファイルを切替える仕組みをアプリケーションにコーディングする必要がなく、開発効率と保守性を向上させることができる。
【００７５】
また、本実施形態によれば、アプリケーションの実際の構造を元にロケールと画面構成ファイルの対応を判断するため、別途テーブルなどによりロケールと画面構成ファイルの関係を管理することによる不整合（実構成とテーブルの不整合）がなく、品質を向上させることができる。
【００７６】
さらに、本実施形態によれば、アプリケーションとして対応するロケールの追加が画面構成ファイルの追加だけで済むため、アプリケーションの拡張性を向上させることができる。
【００７７】
＜第２の実施形態＞
図７は第２の実施形態に係るパス変換装置が適用されたクライアントサーバシステムの構成を示す模式図であり、図１と同一部分には同一符号を付してその詳しい説明を省略し、ここでは異なる部分について主に述べる。なお、以下の各実施形態も同様にして重複した説明を省略する。
【００７８】
すなわち、第２の実施形態は、第１の実施形態の適用例であり、アプリケーション部２００における画面遷移に適用した場合、表示する画面がロケール毎に切替え可能となっている。
【００７９】
画面遷移を行なう場合、通常、アプリケーション部２００を実行するアプリケーションサーバ部４００に対して次に表示する画面を指示する。指示は、通常、画面ファイル(HTMLやJSP等)へのパスを用いる。このとき、アプリケーション部２００とアプリケーションサーバ部４００の間にパス変換装置１００を介在させることで、アプリケーションのコード内に国際化に対応した切替え処理のコードが不要となる。
【００８０】
アプリケーションを開発する場合、アプリケーション部２００とアプリケーションサーバ部４００との間の層にフレームワークというソフトウェアを導入するのが一般的であり、例えば、このフレームワークの実行により実現される機能部がパス変換装置１００を含んでいる。
【００８１】
これに伴い、本実施形態のサーバ装置Ｓｖは、図１に示したアプリケーション部２００とパス変換装置１００との間に画面遷移パス処理部３００が配置され、画面遷移パス処理部３００にはアプリケーションサーバ部４００が接続されている。
【００８２】
ここで、画面遷移パス処理部３００は、例えば、フレームワークの１機能として組み込まれて実装される。画面遷移パス処理部３００は、アプリケーション部２００により次の画面が指定された場合に実行される。画面遷移パス処理部３００は、アプリケーション部２００が指定した次の画面のパスを、パス変換装置１００によって、国際化したパスに変換する。画面遷移パス処理部３００は、国際化したパスを次の画面としてアプリケーションサーバ部４００に通知する。
【００８３】
補足すると、アプリケーション部２００とアプリケーションサーバ部４００との間に画面遷移パス処理部３００が介在することで、アプリケーション部２００が、次の画面を指定するパスに対し、ロケールによる切替えを意識することがない。
【００８４】
アプリケーションサーバ部４００は、アプリケーションを動作させるミドルウェア（アプリケーションサーバ）の実行により実現される機能部である。アプリケーションサーバ部４００は、画面遷移パス処理部３００が指定するパス上にある画面ファイルをクライアント装置Ｃjpに表示させる。
【００８５】
次に、以上のように構成されたクライアントサーバシステムの動作を図８のシーケンス図を用いて説明する。なお、ステップＳＴ１０１’，ＳＴ１０８’は、前述したステップＳＴ１０１，ＳＴ１０８と同様の処理であるが、入出力先などが前述とは異なるため、「’」の符号をステップ番号に付している。
【００８６】
アプリケーション部２００は、次に表示する画面のパスを指定するメッセージを画面遷移パス処理部３００に送出する（ＳＴ１０）。Java EEアプリケーションでは、通常、画面の指定にはパスを利用する。本実施形態でも、通常のJava EEアプリケーションと同様に、パスにより次の画面を指定する。例えば、「/menu.html」のように指定する。
【００８７】
画面遷移パス処理部３００は、指定された次の画面のパスを含む国際化依頼メッセージ（パス変換依頼メッセージ）をパス変換装置１００に入力する（ＳＴ１０１’）。
【００８８】
パス変換装置１００は、前述したステップＳＴ１０２〜ＳＴ１０７と同様に、入力を受け付けたパスを、国際化したパスに変換し（ＳＴ１０２〜ＳＴ１０７）、当該変換されたパスを画面遷移パス処理部３００に送出する（ＳＴ１０８’）。
【００８９】
例えば、アプリケーションの構造が図４に示す構造で、利用者のロケールが日本(ja_JPまたはja)の場合は、国際化した次の画面のパスとして「/menu_ja.html」が生成される。利用者のロケールが米国などの英語圏(en_US、en_GB、en等)の場合は、国際化した次の画面のパスとして「/menu_en.html」が生成される。利用者のロケールが日本でも英語圏でもない場合は、「/menu.html」が国際化した次の画面のパスとして生成される。
【００９０】
画面遷移パス処理部３００は、パス変換装置１００により、国際化した次の画面のパスを指定するメッセージをアプリケーションサーバ部４００に送出する（ＳＴ１１０）。
【００９１】
アプリケーションサーバ部４００は、ステップＳＴ１１０で指定されたパスに基づいて、当該パスが示す画面構成ファイルの内容を含む画面構成データを作成し、この画面構成データを、次の画面としてクライアント装置Ｃjpに表示させる。
【００９２】
上述したように本実施形態によれば、第１の実施形態の効果に加え、アプリケーション部２００における画面遷移に適用した場合であっても、表示する画面をロケール毎に切替えることができる。
【００９３】
＜第３の実施形態＞
図９は第３の実施形態に係るパス変換装置が適用されたクライアントサーバシステムの構成を示す模式図である。
【００９４】
第３の実施形態は、第１の実施形態の他の適用例であり、画面ファイルから参照されるファイルの指定に適用した場合、参照されるファイルがロケール毎に切替え可能となっている。
【００９５】
画面ファイルから参照されるファイルとしては、画像ファイル、スタイルシート、JavaScriptファイル等がある。これらファイルを参照する場合、画面ファイル内に参照するファイルへのパスを記述する。参照するファイルへのパスの部分にパス変換装置１００を適用することで、記述するファイルへのパスに対して国際化を意識しなくても、実際に参照されるパスが国際化されたパスになる。
【００９６】
Java EEアプリケーションでは、画面ファイルは、ＪＳＰ（Java Server Pages）で記述されることが一般的である。ＪＳＰを記述する技術としてタグライブラリという技術がある。本実施形態は、パス変換装置１００の技術をタグライブラリが利用する例を示す。
【００９７】
これに伴い、本実施形態のサーバ装置Ｓｖは、図１に示したアプリケーション部２００に代えて、画面アプリケーション部５００及び参照パス国際化部６００を備えている。
【００９８】
ここで、画面アプリケーション部５００は、画面ファイルにより画面を生成する画面アプリケーションを実行する機能部である。Java EEアプリケーションでは、通常、ＪＳＰとして画面ファイルが作成されるが、ＪＳＰ以外の技術で画面ファイルを作成してもよい。
【００９９】
参照パス国際化部６００は、画面アプリケーション部５００の画面ファイル内に指定されるパスを国際化する機能部である。画面ファイルをＪＳＰとして作成した場合、参照パス国際化部６００は、タグライブラリという形式を用いることが一般的であるが、タグライブラリ以外の形式を用いてもよい。
【０１００】
次に、以上のように構成されたクライアントサーバシステムの動作を図１０のシーケンス図を用いて説明する。なお、ステップＳＴ１０１”，ＳＴ１０８”は、前述したステップＳＴ１０１，ＳＴ１０８と同様の処理であるが、入出力先などが前述とは異なるため、「”」の符号をステップ番号に付している。
【０１０１】
画面アプリケーション部５００は、参照するファイルを示す参照パスを指定するメッセージを参照パス国際化部６００に送出する（ＳＴ２０）。Java EEアプリケーションでは、例えば「/css/app-style.css」のように、参照パスを指定する。
【０１０２】
参照パス国際化部６００は、指定された参照パスを含む国際化依頼メッセージ（パス変換依頼メッセージ）をパス変換装置１００に入力する（ＳＴ１０１”）。
【０１０３】
パス変換装置１００は、前述したステップＳＴ１０２〜ＳＴ１０７と同様に、入力を受け付けたパスを国際化したパスに変換し（ＳＴ１０２〜ＳＴ１０７）、当該変換されたパスを参照パス国際化部６００に送出する（ＳＴ１０８”）。
【０１０４】
例えば、アプリケーションの構造が図４に示す構造で、利用者のロケールが日本(ja_JPまたはja)の場合は、国際化した参照パスとして「/css/app-style_ja.css」が生成される。利用者のロケールが日本以外の場合は、「/css/app-style.css」が国際化した参照パスとして生成される。
【０１０５】
ここで、国際化した参照パスは、アプリケーションの内部構造に基づくものである。画面ファイルから参照するパスは、パス指定の仕方によっては内部構造のパスだけではなく、アプリケーションのルート（アプリケーションコンテキスト）から指定する必要がある。図４に示す構成の場合、参照パス国際化部６００は、参照パス「/css/app-style_ja.css」を参照パス「/AppContext/css/app-style_ja.css」のように先頭にアプリケーションコンテキストを付与する（ＳＴ１２０）。本処理は必須ではなくオプションである。
【０１０６】
画面アプリケーション部５００は、国際化した参照パスを画面に設定（画面構成データに設定）する（ＳＴ１２２）。国際化した参照パスが設定された画面構成データは、クライアント装置Ｃjpに送信される。クライアント装置Ｃjpは、この画面構成データに基づいて、国際化した画面を表示する。
【０１０７】
図１１は画面構成ファイル内のパスの変換例を示す模式図である。図１１上側に示す変換前の画面構成ファイルｆ１において、<i18n:url>というタグライブラリのバリュー（value）には、国際化されていない参照パスが定義されている。この参照パスを含む<i18n:url>のタグの部分は、図１１下側の変換後の画面構成ファイルｆ１jp，ｆ１en”に示すように、前述した処理によって、国際化した参照パスに変換される。
【０１０８】
上述したように本実施形態によれば、第１の実施形態の効果に加え、画面ファイルから参照されるファイルの指定に適用した場合、参照されるファイルをロケール毎に切替えることができる。
【０１０９】
以上説明した少なくとも一つの実施形態によれば、パス変換装置１００が、入力を受け付けたパスを、アプリケーション利用者のロケールを含むパスに変換し、当該変換したパスを送出する構成により、アプリケーション毎に仕組みを作成せずに画面の構成や入力項目の数をロケール毎に切替え可能であることに加え、ロケール毎に切り替える対象を管理する必要を無くすことができる。
【０１１０】
なお、上記の各実施形態に記載した手法は、コンピュータに実行させることのできるプログラムとして、磁気ディスク（フロッピー（登録商標）ディスク、ハードディスクなど）、光ディスク（ＣＤ−ＲＯＭ、ＤＶＤなど）、光磁気ディスク（ＭＯ）、半導体メモリなどの記憶媒体に格納して頒布することもできる。
【０１１１】
また、この記憶媒体としては、プログラムを記憶でき、かつコンピュータが読み取り可能な記憶媒体であれば、その記憶形式は何れの形態であっても良い。
【０１１２】
また、記憶媒体からコンピュータにインストールされたプログラムの指示に基づきコンピュータ上で稼働しているＯＳ（オペレーティングシステム）や、データベース管理ソフト、ネットワークソフト等のＭＷ（ミドルウェア）等が上記実施形態を実現するための各処理の一部を実行しても良い。
【０１１３】
さらに、各実施形態における記憶媒体は、コンピュータと独立した媒体に限らず、ＬＡＮやインターネット等により伝送されたプログラムをダウンロードして記憶または一時記憶した記憶媒体も含まれる。
【０１１４】
また、記憶媒体は１つに限らず、複数の媒体から上記の各実施形態における処理が実行される場合も本発明における記憶媒体に含まれ、媒体構成は何れの構成であっても良い。
【０１１５】
なお、各実施形態におけるコンピュータは、記憶媒体に記憶されたプログラムに基づき、上記の各実施形態における各処理を実行するものであって、パソコン等の１つからなる装置、複数の装置がネットワーク接続されたシステム等の何れの構成であっても良い。
【０１１６】
また、各実施形態におけるコンピュータとは、パソコンに限らず、情報処理機器に含まれる演算処理装置、マイコン等も含み、プログラムによって本発明の機能を実現することが可能な機器、装置を総称している。
【０１１７】
なお、本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【符号の説明】
【０１１８】
１００…パス変換装置、１１０…パス生成部、１２０…ロケール管理部、１３０…パス変換部、１３１…パス変換ルール、１４０…パス存在チェック部、１４１…パスリスト、２００…アプリケーション部、３００…画面遷移パス処理部、４００…アプリケーションサーバ部、５００…画面アプリケーション部、６００…参照パス国際化部、Ｃjp，Ｃus，Ｃsr，…クライアント装置、Ｓｖ…サーバ装置。
【技術分野】
【０００１】
本発明の実施形態は、国際化に対応した画面表示のためのパス変換装置及びプログラムに関する。
【背景技術】
【０００２】
アプリケーションの国際化とは、利用者のロケール（言語・国・地域を表すもの）に合わせて、画面の表示内容や処理を切替えることである。
【０００３】
Java（登録商標） EEアプリケーションを国際化する場合、リソースバンドルという技術が一般的に用いられる。リソースバンドルは、文字列をロケール毎に管理する機能である。リソースバンドルによれば、利用者のロケールに合わせて、画面に表示される文字列を切替可能となる。例えば、日本語の利用者に対しては画面内の文字列を日本語に切り替え、英語の利用者に対しては画面内の文字列を英語に切り替えることが可能となる。
【０００４】
また、Java EEアプリケーションの分野で活動が活発なＯＳＳ（Open Source Software）のフレームワークには、文字列だけでなく、利用者が入力したデータのバリデーションや、日付、数値、通貨のフォーマットを切替える仕組みを持つものも存在する。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０００−１１２７０８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、以上のようなリソースバンドルやＯＳＳのフレームワークは、通常は何の問題もないが、本発明者の検討によれば、第１及び第２の点で改良の余地がある。
【０００７】
第１の点は、切替える対象が、文字列単位や入力項目単位という画面内の１要素である点である。実際のシステム開発では、１要素単位の切替えで済まず、画面の構成（レイアウト）や入力項目数の数をロケール毎に切替える必要に迫られることがある。例えば、ロケールが日本語の画面と英語の画面では、同じ内容の文であっても文を構成する文字列の文字数が大幅に異なるため、ロケールに応じて画面の構成を切り替える必要がある。
【０００８】
また例えば、名前を入力するフォームの場合、ロケールが日本語の画面では、姓、名の順にフォームが配置された構成に加え、漢字とフリガナの入力項目が必要になる。
【０００９】
しかしながら、ロケールが英語の画面では、名、姓の順にフォームが配置された構成だけで済み、漢字とフリガナの入力項目が不要となる。従って、画面の構成や入力項目数をロケール毎に切替えるためには、個々のアプリケーション毎に仕組みを作成する必要がある。
【００１０】
第２の点は、ロケール毎に切替える対象を管理する必要がある点である。例えば、リソースバンドルであれば、ロケールと文字列の対応を定義し管理する必要がある。また、バリデーションであれば、ロケールとバリデーションルールの関係を定義し管理する必要がある。そのため、切替え対象を追加／変更する場合、切替え対象の作成作業と関係定義の更新作業という２段階の作業が必要になる。
【００１１】
本発明が解決しようとする課題は、アプリケーション毎に仕組みを作成せずに画面の構成や入力項目の数をロケール毎に切替え可能であることに加え、ロケール毎に切り替える対象を管理する必要を無くし得るパス変換装置及びプログラムを提供することである。
【課題を解決するための手段】
【００１２】
実施形態のパス変換装置は、ロケールに応じた複数の画面構成ファイルを含むアプリケーションを実行するアプリケーション部から前記各画面構成ファイルを指定するパスの入力を受け付ける。前記パス変換装置は、当該入力を受け付けたパスを前記アプリケーションの利用者のロケールに応じて変換し、当該変換されたパスを前記アプリケーション部に送出する。
【００１３】
前記パス変換装置は、ロケール管理手段、パスリスト記憶手段、変換ルール記憶手段、ロケール取得手段、パス変換手段、パス存在チェック手段及びパス送出手段を備えている。
【００１４】
前記ロケール管理手段は、前記利用者のロケールを管理する。
【００１５】
前記パスリスト記憶手段は、前記各画面構成ファイルを個別に示す各パスのリスト情報を記憶する。
【００１６】
前記変換ルール記憶手段は、前記パスの一部である変換対象と、当該変換対象が変換される変換文字列であってロケールを示す変数を含む前記変換文字列とを定義した複数の変換ルールからなるパス変換ルールを記憶する。
【００１７】
前記ロケール取得手段は、前記アプリケーション部からパスの入力を受け付けると、ロケール管理手段からロケールを取得する。
【００１８】
前記パス変換手段は、前記入力を受け付けたパスの一部を前記パス変換ルール内の各々の変換ルールに基づいて個別に前記変換文字列に変換し、当該変換文字列内の変数を前記取得されたロケールに置換することにより、当該入力を受け付けたパスを複数のパスに変換し、当該複数のパスからなるパス変換候補を生成する。
【００１９】
前記パス存在チェック手段は、当該パス変換候補内の各パスについて前記リスト情報内に存在するかをチェックする。
【００２０】
前記パス送出手段は、前記パス存在チェック手段によるチェックの結果、前記リスト情報内に存在するパスを前記変換されたパスとして前記アプリケーション部に送出する。
【図面の簡単な説明】
【００２１】
【図１】第１の実施形態に係るパス変換装置が適用されたクライアントサーバシステムの構成を示す模式図である。
【図２】同実施形態におけるパス変換ルールの例を示す模式図である。
【図３】同実施形態におけるパスを変換する例を示す模式図である。
【図４】同実施形態におけるパスリストを説明するための模式図である。
【図５】同実施形態における動作を説明するためのシーケンス図である。
【図６】同実施形態における動作の一部を説明するためのフローチャートである。
【図７】第２の実施形態に係るパス変換装置が適用されたクライアントサーバシステムの構成を示す模式図である。
【図８】同実施形態における動作を説明するためのシーケンス図である。
【図９】第３の実施形態に係るパス変換装置が適用されたクライアントサーバシステムの構成を示す模式図である。
【図１０】同実施形態における動作を説明するためのシーケンス図である。
【図１１】同実施形態における画面構成ファイル内のパスの変換例を示す模式図である。
【発明を実施するための形態】
【００２２】
以下、各実施形態について図面を用いて説明するが、その前に各実施形態に共通する概要を述べる。
【００２３】
各実施形態は、ロケール毎に切替える対象を画面の要素単位だけではなく、利用するファイル自体を切替える仕組みを述べている。切り替え対象は、画面構成ファイル（HTMLやJSP等の画面ファイルや画面から参照されるスタイルシート、画像ファイル、JavaScript（登録商標）ファイル等）である。切替える方法として、画面構成ファイルへのパスを、ロケール情報を含めたパスへ自動で変換する仕組みを述べている。
【００２４】
このような各実施形態によれば、画面構成ファイルを切替える構成により、画面の構成（レイアウト，入力項目の増減）、画面上で動作するロジック（Javascript）などをロケール毎に変更することが可能となる。
【００２５】
また、各実施形態によれば、ロケールと切替え対象の画面構成ファイルの関係を、パス変換ルールとアプリケーション内の構造により管理する構成により、個々の画面構成ファイルとロケールの対応関係を別途管理する必要を無くすことができる。
【００２６】
従って、各実施形態によれば、アプリケーション毎に仕組みを作成せずに画面の構成や入力項目の数をロケール毎に切替え可能であることに加え、ロケール毎に切り替える対象を管理する必要を無くすことができる。以上が各実施形態に共通する概要である。続いて、各実施形態について具体的に説明する。
【００２７】
＜第１の実施形態＞
図１は第１の実施形態に係るパス変換装置が適用されたクライアントサーバシステムの構成を示す模式図である。このクライアントサーバシステムは、複数のクライアント装置Ｃjp，…，Ｃus，…，Ｃsr，…がネットワークを介してサーバ装置Ｓｖに接続されている。なお、各クライアント装置Ｃjp，…，Ｃus，…，Ｃsr，…の添字｛jp｝，｛us｝，｛sr｝は、それぞれ設定されたロケールが日本、米国及びセルビア語を示すことを表している。また、各クライアント装置Ｃjp，…，Ｃus，…，Ｃsr，…は、ロケールが示す内容を除き、互いに同一構成のブラウザを有するため、ここでは日本を示すロケールがブラウザに設定されたクライアント装置Ｃjpを代表例に挙げて説明する。
【００２８】
クライアント装置Ｃjpは、通常のブラウザを有する通常のコンピュータであり、具体的には例えば、ユーザの操作により、ロケールを含むリクエストをサーバ装置Ｓｖに送信する機能と、ロケールを表すリンクやボタンの選択操作により、当該選択されたロケールをサーバ装置Ｓｖに送信する機能と、サーバ装置Ｓｖから画面構成ファイルの内容を示す画面構成データを受けると、この画面構成データに基づいて画面を表示する機能とを備えたブラウザを有している。なお、ロケールを含むリクエストをサーバに送信することは、ＨＴＴＰ（HyperText Transfer Protocol）に定められている。
【００２９】
一方、サーバ装置Ｓｖは、パス変換装置１００及びアプリケーション部２００を備えている。
【００３０】
パス変換装置１００は、ロケールに応じた複数の画面構成ファイルを含むアプリケーションを実行するアプリケーション部２００から当該各画面構成ファイルを指定するパスの入力を受け付けると、当該パスを当該アプリケーションの利用者のロケールに応じて変換し、当該変換されたパスをアプリケーション部２００に送出する機能をもっている。
【００３１】
補足すると、パス変換装置２００は、利用者の国際化に対応し、画面構成ファイルへのパスを国際化したパスに変換する装置である。
【００３２】
国際化したパスとは、パス内にロケール情報を含んだパスを意味する。例えばアプリケーション部２００から入力されたパスが”/index.jsp”とした場合、国際化したパスは、”/index_ja_JP.jsp”や”/ja_JP/index.jsp”のようにロケールを表す”ja_JP”をパスに含めたものである。アプリケーション部２００から入力されるパスをどのように国際化したパスに変換するかのルールはパス変換ルール１３１に定義される。なお、国際化したパスは、ロケールに応じたパスと呼んでもよい。
【００３３】
このようなパス変換装置１００は、具体的には、パス生成部１１０、ロケール管理部１２０、パス変換部１３０及びパス存在チェック部１４０を備えている。
【００３４】
パス生成部１１０は、アプリケーション部２００からの入力であるパスを受付け、適切に国際化したパスを返却する部分である。適切に国際化したパスとは、パス変換ルール１３１に定義されたルールにより変換され、且つアプリケーション内にそのパスが示す画面構成ファイルが存在するものである。
【００３５】
このようなパス生成部１１０は、具体的には例えば、以下の機能(f110-1)〜(f110-3)をもっている。
【００３６】
(f110-1) アプリケーション部２００からパスの入力を受け付けると、ロケール管理部１２０からロケールを取得する機能。
【００３７】
(f110-2) 当該取得したロケールと、当該入力を受け付けたパスとをパス変換部１３０に送出し、パス変換部１３０から変換後の複数のパスからなるパス変換候補を受ける機能。なお、この機能(f110-2)は必須ではなく、例えば、パス生成部１１０とパス変換部１３０とを一体的に設けることにより、省略可能である。
【００３８】
(f110-3) 当該パス変換候補をパス存在チェック部１４０に送出する機能。
【００３９】
(f110-4) パス存在チェック部１４０によるチェックの結果、パスリスト（各パスのリスト情報）１４１内に存在するパスを、パス変換装置１００により変換されたパスとしてアプリケーション部２００に送出するパス送出機能。
【００４０】
また、パス変換部１１０は、さらに、以下の機能(f110-5)を備えてもよい。
【００４１】
(f110-5) パス存在チェック部１４０によるチェックの結果、パス変換候補内の全てのパスがパスリスト１４１内に存在しない場合、アプリケーション部２００から入力を受け付けたパスを、パス変換装置１００により変換されたパスとしてアプリケーション部２００に送出する機能。ここで、入力を受け付けたパスは、ロケールを含まないパスであって、例えば、英語圏に対応した画面構成ファイルを示している。なお、この英語圏に対応した画面構成ファイルは、英語圏のみに対応したものでもよく、英語圏に加えて他の所望の言語圏に対応したものでもよい。
【００４２】
ロケール管理部１２０は、アプリケーション部２００を利用するアプリケーション利用者のロケールを管理する機能をもっている。ロケールとは、アプリケーション利用者が扱う言語、所属する国や地域を表すものである。Javaでは通常、「言語_国_バリアント」という形式で扱われる。日本語であれば「ja」、英語であれば「en」と表現され、日本であれば「ja_JP」、米国であれば「en_US」と表現される。バリアントまで表すものとしては、セルビア語(ボスニア・ヘルツェゴビナ、ラテン)の「sr_BA_LATN」がある。
【００４３】
ロケールはクライアント装置Ｃjp，…に利用されるブラウザに設定されており、ブラウザからリクエストをサーバ装置Ｓｖに送信する際にロケールも送信される。なお、図１には、日本を表すロケールが設定されたクライアント装置Ｃjpと、米国を表すロケールが設定されたクライアント装置Ｃusと、セルビア語を表すロケールが設定されたクライアント装置Ｃsrとを示している。
【００４４】
また、アプリケーションによってはブラウザに設定されたロケールではなく、アプリケーションの画面上に「日本語」「English」等が記述されたボタンやリンクが表示され、このボタンやリンクをアプリケーション利用者が選択することにより、クライアント装置Ｃjp，…が利用するロケールをアプリケーション部２００に送信する方法をとるものも多く見られる。
【００４５】
ロケール管理部１２０が管理するロケールは、上記ブラウザに設定されたロケールと、ボタンやリンクにより選択されるロケールの両方である。ロケールの管理方法としてはアプリケーションのセッション領域を使用することが可能である。セッションはアプリケーション部２００の利用者個々に割り当てられる領域である。セッション領域を利用してロケールを管理することにより、様々な言語を利用する不特定多数の利用者がアプリケーション部２００を利用したとしても、各々の利用者のロケールを適切に管理することが可能である。
【００４６】
パス変換部１３０は、パス生成部１１０により入力を受け付けたパスの一部をパス変換ルール１３１内の各々の変換ルールに基づいて個別に変換文字列に変換し、当該変換文字列内の変数を、パス生成部１１０により取得されたロケールに置換することにより、当該入力を受け付けたパスを複数のパスに変換し、当該複数のパスからなるパス変換候補を生成するパス変換機能をもっている。
【００４７】
補足すると、変換後のパスは１つではなく複数である。例えば、変換対象のパスが「/css/app-style.css」で、ロケールが「ja_JP」の場合、「/css/app-style_ja_JP.css」「/css/app-style_ja.css」「/css/app-style.css」のように変換後のパスが３種類作成される。
【００４８】
変換後のパスが複数であることは、ロケールが階層的な意味を持っていることと、javaでロケールを扱う場合にはより狭いロケールの階層から優先的に扱うことに由来する。ロケールが「ja_JP」の場合、第１に「ja_JP」が優先され、次に「ja」が、その後に「ロケール情報無し」が適用される。このような優先度があることから、変換後のパスを複数作成しておき、パス存在チェック部１４０でのチェック結果に基づいて、実際に利用するパスを決める方式としている。
【００４９】
パス変換ルール１３１は、ロケールを使いパスをどのように変換するかを定義した情報であり、具体的には、パスの一部である変換対象と、当該変換対象が変換される変換文字列であってロケールを示す変数を含む当該変換文字列とを定義した複数の変換ルールからなる情報である。パス変換部１３０はこのパス変換ルール１３１に定義された各変換ルールに基づきパスを変換する。パス変換ルール１３１は、図２に例を示すように、パス中の変換対象と変換文字列を定義している。変換ルール例１では、パス内の”.”を”_${locale}.”に変換するというルールである。”${locale}”が変数でありロケールに置換される。パス変換ルール１３１としては、３つの例を示したが、これに限らず、パス上の一部の文字を、ロケールを含めた文字列に変換する変換ルールであれば、任意の変換ルールを定義可能となっている。図２のパス変換ルール１３１を用いて、パス変換部１３０がパスを変換する例を図３に示す。図３はロケールが「ja_JP」の場合のパス変換例を示している。パス変換部１３０は、予め定義されたパス変換ルール１３１をメモリ（図示せず）に書込む機能を有するが、このメモリは、パス変換部１３０の内部に限らず、パス変換部１３０の外部にあってもよい。
【００５０】
パス存在チェック部１４０は、パス変換部１３０により変換された複数のパスからなるパス変換候補内の各パスについてパスリスト１４１内に存在するかをチェックする機能をもっている。補足すると、パス存在チェック部１４０は、パスリスト１４１を利用して、国際化したパスが示す画面構成ファイルが、アプリケーション内に存在するかをチェックするものである。
【００５１】
パスリスト１４１は、各画面構成ファイルを個別に示す各パスのリスト情報であり、図４に示すように、アプリケーションの構造から作成される。パスリスト１４１は、パス存在チェック部１４０がパスの存在チェックをする際に、毎回アプリケーション内のパスチェックをする負荷を無くす役割をもっている。パス存在チェック部１４０は、予め画面構成ファイルの情報をパスリスト１４１としてメモリ（図示せず）に書込むことで、パスチェックの効率化を図っている。パスリスト１４１を書込む（構築する）タイミングは、アプリケーション起動時もしくは、パス存在チェック部１４０が最初にパスチェックをするタイミングのいずれかである。なお、パスリスト１４１が書込まれるメモリは、パス存在チェック部１４０の内部に限らず、パス存在チェック部１４０の外部にあってもよい。
【００５２】
また、アプリケーション内には画面構成ファイルではないファイルも存在する。たとえばjarファイル等のライブラリファイルやロジックを構成するclassファイルである。Java EEアプリケーションの場合、これら画面構成ファイルではないファイルの構成が規定されている。JarファイルはAppContext/WEB-INF/libに配置されることが一般的であり、classファイルはAppContext/WEB-INF/classesに配置されることが一般的である。パスリスト１４１を作成する際に、これら画面構成ファイル以外のファイルが配置されるパスをパスリスト１４１に含めない構成により、パスリスト１４１の構築とパスのチェックとの効率化を図ることが可能である。
【００５３】
なお、以上のようなパス変換装置１００は、ハードウェア構成、又はハードウェア資源とソフトウェアとの組合せ構成のいずれでも実施可能となっている。組合せ構成のソフトウェアとしては、予めネットワーク又は記憶媒体からコンピュータにインストールされ、当該コンピュータにパス変換装置１００の機能を実現させるためのプログラムが用いられる。また、パス変換装置１００は、例えば、パス生成装置、パス管理装置又はリソース管理装置のような他の名称に読み替えてもよい。
【００５４】
一方、アプリケーション部２００は、国際化に対応したパス変換装置１００を利用するアプリケーション（プログラム）を実行するプロセッサの一機能として実現される。アプリケーション部２００のアプリケーションとしては、Java EEアプリケーションを前提にしている。アプリケーション部２００は、クライアント装置Ｃjpから受けたリクエストに基づいて、国際化に対応したパス変換装置１００に対し、国際化未対応（ロケールに未対応）のパスを入力する機能と、パス変換装置１００によりロケールに対応して変換されたパスを受ける機能と、当該受けたパスに基づく画面構成ファイルをクライアント装置Ｃjpに送信する機能とをもっている。
【００５５】
次に、以上のように構成されたパス変換装置が適用されたクライアントサーバシステムの動作を図５のシーケンス図及び図６のフローチャートを用いて説明する。
【００５６】
アプリケーション部２００は、クライアント装置Ｃjpから受けたリクエストに基づいて、国際化未対応のパス（変換対象パス）を含むパス生成依頼メッセージをパス生成部１１０に入力する（ＳＴ１０１）。
【００５７】
パス生成部１１０は、パス生成依頼メッセージに含まれる変換対象パスの入力を受け付けると、ロケール取得メッセージをロケール管理部１２０に送出することにより、ロケール管理部１２０から、現在アプリケーションを利用しているアプリケーション利用者のロケールを取得する（ＳＴ１０２）。
【００５８】
パス生成部１１０は、当該取得したロケールと、当該入力を受け付けた変換対象パスとを含むパス変換候補取得メッセージをパス変換部１３０に送出する（ＳＴ１０３）。
【００５９】
パス変換部１３０は、パス変換ルール１３１に定義された各々の変換ルールを取得する（ＳＴ１０４）。
【００６０】
パス変換部１３０は、パス変換候補取得メッセージ内の変換対象パスの一部をパス変換ルール１３１内の各々の変換ルールに基づいて個別に変換文字列に変換し、当該変換文字列内の変数をパス変換候補取得メッセージ内のロケールに置換することにより、当該変換対象パスを複数のパスに変換し、当該複数のパスからなるパス変換候補リストを生成する（ＳＴ１０５）。
【００６１】
これにより、パス生成部１１０は、ステップＳＴ１０３のパス変換候補取得メッセージに対する戻り値として、変換後の複数のパスからなるパス変換候補リストを取得する。
【００６２】
パス生成部１１０は、当該取得したパス変換候補リスト内の各パスのうち、適切なパスを決定する（ＳＴ１０６）。適切なパスとはアプリケーション内に存在するパスを意味する。ステップＳＴ１０６においては、ロケールの優先度を考慮し、図６のステップＳＴ１０６−１〜ＳＴ１０６−８に示すように、優先度の高いものからパス存在チェック部１４０によるチェックを実行し、存在を確認できたパスを適切なパスとしてアプリケーション部２００に返却する。
【００６３】
例えば、ステップＳＴ１０６−１において、パス生成部１４０は、パス変換候補内で最高の優先度をもつパス（｛言語_国_バリアント｝が付与されたパス）を含む存在確認依頼メッセージをパス存在チェック部１４０に送出する。
【００６４】
パス存在チェック部１４０は、存在確認依頼メッセージを受けると、パスリスト１４１を参照し、存在確認依頼メッセージ内のパスが当該パスリスト１４１内に存在するかをチェックし（ＳＴ１０７，ＳＴ１０８）、存在する（true）か否（false）かを示すチェック結果をパス生成部１４０に送出する。
【００６５】
ここで、パス存在チェック部１４０によるチェックの結果、パスリスト１４１内に存在する場合（ＳＴ１０６−２；true）には、パス生成部１４０は、当該存在するパス（｛言語_国_バリアント｝が付与されたパス）を、変換されたパスとしてアプリケーション部２００に送出する（ＳＴ１０６−８）
一方、パス存在チェック部１４０によるチェックの結果、パスリスト１４１内に存在しない場合（ＳＴ１０６−２；false）には、ステップＳＴ１０６−３において、パス生成部１１０は、次に優先度の高いパス（｛言語_国｝が付与されたパス）を含む存在確認依頼メッセージをパス存在チェック部１４０に送出する。
【００６６】
パス存在チェック部１４０は、前述同様に、存在確認依頼メッセージ内のパスをチェックし（ＳＴ１０７，ＳＴ１０８）、チェック結果をパス生成部１４０に送出する。
【００６７】
パス存在チェック部１４０によるチェックの結果、パスリスト１４１内に存在する場合（ＳＴ１０６−４；true）には、パス生成部１４０は、当該存在するパス（｛言語_国｝が付与されたパス）を、変換されたパスとしてアプリケーション部２００に送出する（ＳＴ１０６−８）
また一方、パス存在チェック部１４０によるチェックの結果、パスリスト１４１内に存在しない場合（ＳＴ１０６−４；false）には、ステップＳＴ１０６−５において、パス生成部１１０は、次に優先度の高いパス（｛言語｝が付与されたパス）を含む存在確認依頼メッセージをパス存在チェック部１４０に送出する。
【００６８】
パス存在チェック部１４０は、前述同様に、存在確認依頼メッセージ内のパスをチェックし（ＳＴ１０７，ＳＴ１０８）、チェック結果をパス生成部１４０に送出する。
【００６９】
パス存在チェック部１４０によるチェックの結果、パスリスト１４１内に存在する場合（ＳＴ１０６−６；true）には、パス生成部１４０は、当該存在するパス（｛言語｝が付与されたパス）を、変換されたパスとしてアプリケーション部２００に送出する（ＳＴ１０６−８）
また一方、パス存在チェック部１４０によるチェックの結果、パスリスト１４１内に存在しない場合（ＳＴ１０６−６；false）には、パス生成部１１０は、ステップＳＴ１０１で入力された変換対象パス（ロケールを含まないパス）を、変換されたパスとしてアプリケーション部２００に送出する（ＳＴ１０６−７，ＳＴ１０６−８）。なお、ロケールを含まないパスは、例えば、英語圏に対応した画像構成ファイルを示している。
【００７０】
ステップＳＴ１０６−８の完了後、アプリケーション部２００は、ステップＳＴ１０１のパス生成依頼メッセージに対する戻り値として、変換されたパスを取得する。
【００７１】
アプリケーション部２００は、取得したパスに指定された画面構成ファイルの内容を示す画面構成データをリクエストに対するレスポンスとして、クライアント装置Ｃjpに送信する。
【００７２】
クライアント装置Ｃjpでは、この画面構成データに基づいて画面を表示する。この画面は、画面構成ファイルが利用者のロケールに応じたものであるため、同様に、利用者のロケールに応じた内容が表示される。
【００７３】
上述したように本実施形態によれば、入力を受け付けたパスの一部を、利用者のロケールを含む変換文字列に個別に変換することにより、当該入力を受け付けたパスを複数のパスからなるパス変換候補に変換し、当該パス変換候補内の各パスについてパスリスト１４１内に存在するかをチェックし、存在するパスを変換されたパスとしてアプリケーション部２００に送出する構成により、アプリケーション毎に仕組みを作成せずに画面の構成や入力項目の数をロケール毎に切替え可能であることに加え、ロケール毎に切り替える対象を管理する必要を無くすことができる。
【００７４】
補足すると、本実施形態によれば、ロケールに合わせて利用する画面構成ファイルを切替える仕組みをアプリケーションにコーディングする必要がなく、開発効率と保守性を向上させることができる。
【００７５】
また、本実施形態によれば、アプリケーションの実際の構造を元にロケールと画面構成ファイルの対応を判断するため、別途テーブルなどによりロケールと画面構成ファイルの関係を管理することによる不整合（実構成とテーブルの不整合）がなく、品質を向上させることができる。
【００７６】
さらに、本実施形態によれば、アプリケーションとして対応するロケールの追加が画面構成ファイルの追加だけで済むため、アプリケーションの拡張性を向上させることができる。
【００７７】
＜第２の実施形態＞
図７は第２の実施形態に係るパス変換装置が適用されたクライアントサーバシステムの構成を示す模式図であり、図１と同一部分には同一符号を付してその詳しい説明を省略し、ここでは異なる部分について主に述べる。なお、以下の各実施形態も同様にして重複した説明を省略する。
【００７８】
すなわち、第２の実施形態は、第１の実施形態の適用例であり、アプリケーション部２００における画面遷移に適用した場合、表示する画面がロケール毎に切替え可能となっている。
【００７９】
画面遷移を行なう場合、通常、アプリケーション部２００を実行するアプリケーションサーバ部４００に対して次に表示する画面を指示する。指示は、通常、画面ファイル(HTMLやJSP等)へのパスを用いる。このとき、アプリケーション部２００とアプリケーションサーバ部４００の間にパス変換装置１００を介在させることで、アプリケーションのコード内に国際化に対応した切替え処理のコードが不要となる。
【００８０】
アプリケーションを開発する場合、アプリケーション部２００とアプリケーションサーバ部４００との間の層にフレームワークというソフトウェアを導入するのが一般的であり、例えば、このフレームワークの実行により実現される機能部がパス変換装置１００を含んでいる。
【００８１】
これに伴い、本実施形態のサーバ装置Ｓｖは、図１に示したアプリケーション部２００とパス変換装置１００との間に画面遷移パス処理部３００が配置され、画面遷移パス処理部３００にはアプリケーションサーバ部４００が接続されている。
【００８２】
ここで、画面遷移パス処理部３００は、例えば、フレームワークの１機能として組み込まれて実装される。画面遷移パス処理部３００は、アプリケーション部２００により次の画面が指定された場合に実行される。画面遷移パス処理部３００は、アプリケーション部２００が指定した次の画面のパスを、パス変換装置１００によって、国際化したパスに変換する。画面遷移パス処理部３００は、国際化したパスを次の画面としてアプリケーションサーバ部４００に通知する。
【００８３】
補足すると、アプリケーション部２００とアプリケーションサーバ部４００との間に画面遷移パス処理部３００が介在することで、アプリケーション部２００が、次の画面を指定するパスに対し、ロケールによる切替えを意識することがない。
【００８４】
アプリケーションサーバ部４００は、アプリケーションを動作させるミドルウェア（アプリケーションサーバ）の実行により実現される機能部である。アプリケーションサーバ部４００は、画面遷移パス処理部３００が指定するパス上にある画面ファイルをクライアント装置Ｃjpに表示させる。
【００８５】
次に、以上のように構成されたクライアントサーバシステムの動作を図８のシーケンス図を用いて説明する。なお、ステップＳＴ１０１’，ＳＴ１０８’は、前述したステップＳＴ１０１，ＳＴ１０８と同様の処理であるが、入出力先などが前述とは異なるため、「’」の符号をステップ番号に付している。
【００８６】
アプリケーション部２００は、次に表示する画面のパスを指定するメッセージを画面遷移パス処理部３００に送出する（ＳＴ１０）。Java EEアプリケーションでは、通常、画面の指定にはパスを利用する。本実施形態でも、通常のJava EEアプリケーションと同様に、パスにより次の画面を指定する。例えば、「/menu.html」のように指定する。
【００８７】
画面遷移パス処理部３００は、指定された次の画面のパスを含む国際化依頼メッセージ（パス変換依頼メッセージ）をパス変換装置１００に入力する（ＳＴ１０１’）。
【００８８】
パス変換装置１００は、前述したステップＳＴ１０２〜ＳＴ１０７と同様に、入力を受け付けたパスを、国際化したパスに変換し（ＳＴ１０２〜ＳＴ１０７）、当該変換されたパスを画面遷移パス処理部３００に送出する（ＳＴ１０８’）。
【００８９】
例えば、アプリケーションの構造が図４に示す構造で、利用者のロケールが日本(ja_JPまたはja)の場合は、国際化した次の画面のパスとして「/menu_ja.html」が生成される。利用者のロケールが米国などの英語圏(en_US、en_GB、en等)の場合は、国際化した次の画面のパスとして「/menu_en.html」が生成される。利用者のロケールが日本でも英語圏でもない場合は、「/menu.html」が国際化した次の画面のパスとして生成される。
【００９０】
画面遷移パス処理部３００は、パス変換装置１００により、国際化した次の画面のパスを指定するメッセージをアプリケーションサーバ部４００に送出する（ＳＴ１１０）。
【００９１】
アプリケーションサーバ部４００は、ステップＳＴ１１０で指定されたパスに基づいて、当該パスが示す画面構成ファイルの内容を含む画面構成データを作成し、この画面構成データを、次の画面としてクライアント装置Ｃjpに表示させる。
【００９２】
上述したように本実施形態によれば、第１の実施形態の効果に加え、アプリケーション部２００における画面遷移に適用した場合であっても、表示する画面をロケール毎に切替えることができる。
【００９３】
＜第３の実施形態＞
図９は第３の実施形態に係るパス変換装置が適用されたクライアントサーバシステムの構成を示す模式図である。
【００９４】
第３の実施形態は、第１の実施形態の他の適用例であり、画面ファイルから参照されるファイルの指定に適用した場合、参照されるファイルがロケール毎に切替え可能となっている。
【００９５】
画面ファイルから参照されるファイルとしては、画像ファイル、スタイルシート、JavaScriptファイル等がある。これらファイルを参照する場合、画面ファイル内に参照するファイルへのパスを記述する。参照するファイルへのパスの部分にパス変換装置１００を適用することで、記述するファイルへのパスに対して国際化を意識しなくても、実際に参照されるパスが国際化されたパスになる。
【００９６】
Java EEアプリケーションでは、画面ファイルは、ＪＳＰ（Java Server Pages）で記述されることが一般的である。ＪＳＰを記述する技術としてタグライブラリという技術がある。本実施形態は、パス変換装置１００の技術をタグライブラリが利用する例を示す。
【００９７】
これに伴い、本実施形態のサーバ装置Ｓｖは、図１に示したアプリケーション部２００に代えて、画面アプリケーション部５００及び参照パス国際化部６００を備えている。
【００９８】
ここで、画面アプリケーション部５００は、画面ファイルにより画面を生成する画面アプリケーションを実行する機能部である。Java EEアプリケーションでは、通常、ＪＳＰとして画面ファイルが作成されるが、ＪＳＰ以外の技術で画面ファイルを作成してもよい。
【００９９】
参照パス国際化部６００は、画面アプリケーション部５００の画面ファイル内に指定されるパスを国際化する機能部である。画面ファイルをＪＳＰとして作成した場合、参照パス国際化部６００は、タグライブラリという形式を用いることが一般的であるが、タグライブラリ以外の形式を用いてもよい。
【０１００】
次に、以上のように構成されたクライアントサーバシステムの動作を図１０のシーケンス図を用いて説明する。なお、ステップＳＴ１０１”，ＳＴ１０８”は、前述したステップＳＴ１０１，ＳＴ１０８と同様の処理であるが、入出力先などが前述とは異なるため、「”」の符号をステップ番号に付している。
【０１０１】
画面アプリケーション部５００は、参照するファイルを示す参照パスを指定するメッセージを参照パス国際化部６００に送出する（ＳＴ２０）。Java EEアプリケーションでは、例えば「/css/app-style.css」のように、参照パスを指定する。
【０１０２】
参照パス国際化部６００は、指定された参照パスを含む国際化依頼メッセージ（パス変換依頼メッセージ）をパス変換装置１００に入力する（ＳＴ１０１”）。
【０１０３】
パス変換装置１００は、前述したステップＳＴ１０２〜ＳＴ１０７と同様に、入力を受け付けたパスを国際化したパスに変換し（ＳＴ１０２〜ＳＴ１０７）、当該変換されたパスを参照パス国際化部６００に送出する（ＳＴ１０８”）。
【０１０４】
例えば、アプリケーションの構造が図４に示す構造で、利用者のロケールが日本(ja_JPまたはja)の場合は、国際化した参照パスとして「/css/app-style_ja.css」が生成される。利用者のロケールが日本以外の場合は、「/css/app-style.css」が国際化した参照パスとして生成される。
【０１０５】
ここで、国際化した参照パスは、アプリケーションの内部構造に基づくものである。画面ファイルから参照するパスは、パス指定の仕方によっては内部構造のパスだけではなく、アプリケーションのルート（アプリケーションコンテキスト）から指定する必要がある。図４に示す構成の場合、参照パス国際化部６００は、参照パス「/css/app-style_ja.css」を参照パス「/AppContext/css/app-style_ja.css」のように先頭にアプリケーションコンテキストを付与する（ＳＴ１２０）。本処理は必須ではなくオプションである。
【０１０６】
画面アプリケーション部５００は、国際化した参照パスを画面に設定（画面構成データに設定）する（ＳＴ１２２）。国際化した参照パスが設定された画面構成データは、クライアント装置Ｃjpに送信される。クライアント装置Ｃjpは、この画面構成データに基づいて、国際化した画面を表示する。
【０１０７】
図１１は画面構成ファイル内のパスの変換例を示す模式図である。図１１上側に示す変換前の画面構成ファイルｆ１において、<i18n:url>というタグライブラリのバリュー（value）には、国際化されていない参照パスが定義されている。この参照パスを含む<i18n:url>のタグの部分は、図１１下側の変換後の画面構成ファイルｆ１jp，ｆ１en”に示すように、前述した処理によって、国際化した参照パスに変換される。
【０１０８】
上述したように本実施形態によれば、第１の実施形態の効果に加え、画面ファイルから参照されるファイルの指定に適用した場合、参照されるファイルをロケール毎に切替えることができる。
【０１０９】
以上説明した少なくとも一つの実施形態によれば、パス変換装置１００が、入力を受け付けたパスを、アプリケーション利用者のロケールを含むパスに変換し、当該変換したパスを送出する構成により、アプリケーション毎に仕組みを作成せずに画面の構成や入力項目の数をロケール毎に切替え可能であることに加え、ロケール毎に切り替える対象を管理する必要を無くすことができる。
【０１１０】
なお、上記の各実施形態に記載した手法は、コンピュータに実行させることのできるプログラムとして、磁気ディスク（フロッピー（登録商標）ディスク、ハードディスクなど）、光ディスク（ＣＤ−ＲＯＭ、ＤＶＤなど）、光磁気ディスク（ＭＯ）、半導体メモリなどの記憶媒体に格納して頒布することもできる。
【０１１１】
また、この記憶媒体としては、プログラムを記憶でき、かつコンピュータが読み取り可能な記憶媒体であれば、その記憶形式は何れの形態であっても良い。
【０１１２】
また、記憶媒体からコンピュータにインストールされたプログラムの指示に基づきコンピュータ上で稼働しているＯＳ（オペレーティングシステム）や、データベース管理ソフト、ネットワークソフト等のＭＷ（ミドルウェア）等が上記実施形態を実現するための各処理の一部を実行しても良い。
【０１１３】
さらに、各実施形態における記憶媒体は、コンピュータと独立した媒体に限らず、ＬＡＮやインターネット等により伝送されたプログラムをダウンロードして記憶または一時記憶した記憶媒体も含まれる。
【０１１４】
また、記憶媒体は１つに限らず、複数の媒体から上記の各実施形態における処理が実行される場合も本発明における記憶媒体に含まれ、媒体構成は何れの構成であっても良い。
【０１１５】
なお、各実施形態におけるコンピュータは、記憶媒体に記憶されたプログラムに基づき、上記の各実施形態における各処理を実行するものであって、パソコン等の１つからなる装置、複数の装置がネットワーク接続されたシステム等の何れの構成であっても良い。
【０１１６】
また、各実施形態におけるコンピュータとは、パソコンに限らず、情報処理機器に含まれる演算処理装置、マイコン等も含み、プログラムによって本発明の機能を実現することが可能な機器、装置を総称している。
【０１１７】
なお、本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【符号の説明】
【０１１８】
１００…パス変換装置、１１０…パス生成部、１２０…ロケール管理部、１３０…パス変換部、１３１…パス変換ルール、１４０…パス存在チェック部、１４１…パスリスト、２００…アプリケーション部、３００…画面遷移パス処理部、４００…アプリケーションサーバ部、５００…画面アプリケーション部、６００…参照パス国際化部、Ｃjp，Ｃus，Ｃsr，…クライアント装置、Ｓｖ…サーバ装置。
【特許請求の範囲】
【請求項１】
ロケールに応じた複数の画面構成ファイルを含むアプリケーションを実行するアプリケーション部から前記各画面構成ファイルを指定するパスの入力を受け付けると、当該パスを前記アプリケーションの利用者のロケールに応じて変換し、当該変換されたパスを前記アプリケーション部に送出するパス変換装置であって、
前記利用者のロケールを管理するロケール管理手段と、
前記各画面構成ファイルを個別に示す各パスのリスト情報を記憶するパスリスト記憶手段と、
前記パスの一部である変換対象と、当該変換対象が変換される変換文字列であってロケールを示す変数を含む前記変換文字列とを定義した複数の変換ルールからなるパス変換ルールを記憶する変換ルール記憶手段と、
前記アプリケーション部からパスの入力を受け付けると、ロケール管理手段からロケールを取得するロケール取得手段と、
前記入力を受け付けたパスの一部を前記パス変換ルール内の各々の変換ルールに基づいて個別に前記変換文字列に変換し、当該変換文字列内の変数を前記取得されたロケールに置換することにより、当該入力を受け付けたパスを複数のパスに変換し、当該複数のパスからなるパス変換候補を生成するパス変換手段と、
当該パス変換候補内の各パスについて前記リスト情報内に存在するかをチェックするパス存在チェック手段と、
前記パス存在チェック手段によるチェックの結果、前記リスト情報内に存在するパスを前記変換されたパスとして前記アプリケーション部に送出するパス送出手段と、
を備えたことを特徴とするパス変換装置。
【請求項２】
請求項１に記載のパス変換装置において、
前記パス存在チェック手段によるチェックの結果、前記パス変換候補内の全てのパスが前記リスト情報内に存在しない場合、前記入力を受け付けたパスを前記変換されたパスとして前記アプリケーション部に送出する手段、
を更に備え、
前記入力を受け付けたパスは、前記ロケールを含まないパスであって、英語圏に対応した画面構成ファイルを示すことを特徴とするパス変換装置。
【請求項３】
ロケールに応じた複数の画面構成ファイルを含むアプリケーションを実行するアプリケーション部から前記各画面構成ファイルを指定するパスの入力を受け付けると、当該パスを前記アプリケーションの利用者のロケールに応じて変換し、当該変換されたパスを前記アプリケーション部に送出し、且つパスリスト記憶手段及び変換ルール記憶手段を備えたパス変換装置に用いられるプログラムであって、
前記パス変換装置を、
前記利用者のロケールを管理するロケール管理手段、
前記各画面構成ファイルを個別に示す各パスのリスト情報を前記パスリスト記憶手段に書込む手段、
前記パスの一部である変換対象と、当該変換対象が変換される変換文字列であってロケールを示す変数を含む前記変換文字列とを定義した複数の変換ルールからなるパス変換ルールを前記変換ルール記憶手段に書込む手段、
前記アプリケーション部からパスの入力を受け付けると、ロケール管理手段からロケールを取得するロケール取得手段、
前記入力を受け付けたパスの一部を前記パス変換ルール内の各々の変換ルールに基づいて個別に前記変換文字列に変換し、当該変換文字列内の変数を前記取得されたロケールに置換することにより、当該入力を受け付けたパスを複数のパスに変換し、当該複数のパスからなるパス変換候補を生成するパス変換手段、
当該パス変換候補内の各パスについて前記リスト情報内に存在するかをチェックするパス存在チェック手段、
前記パス存在チェック手段によるチェックの結果、前記リスト情報内に存在するパスを前記変換されたパスとして前記アプリケーション部に送出するパス送出手段、
として機能させるためのプログラム。
【請求項４】
請求項３に記載のプログラムにおいて、
前記パス存在チェック手段によるチェックの結果、前記パス変換候補内の全てのパスが前記リスト情報内に存在しない場合、前記入力を受け付けたパスを前記変換されたパスとして前記アプリケーション部に送出する手段、
を更に備え、
前記入力を受け付けたパスは、前記ロケールを含まないパスであって、英語圏に対応した画面構成ファイルを示すプログラム。
【請求項１】
ロケールに応じた複数の画面構成ファイルを含むアプリケーションを実行するアプリケーション部から前記各画面構成ファイルを指定するパスの入力を受け付けると、当該パスを前記アプリケーションの利用者のロケールに応じて変換し、当該変換されたパスを前記アプリケーション部に送出するパス変換装置であって、
前記利用者のロケールを管理するロケール管理手段と、
前記各画面構成ファイルを個別に示す各パスのリスト情報を記憶するパスリスト記憶手段と、
前記パスの一部である変換対象と、当該変換対象が変換される変換文字列であってロケールを示す変数を含む前記変換文字列とを定義した複数の変換ルールからなるパス変換ルールを記憶する変換ルール記憶手段と、
前記アプリケーション部からパスの入力を受け付けると、ロケール管理手段からロケールを取得するロケール取得手段と、
前記入力を受け付けたパスの一部を前記パス変換ルール内の各々の変換ルールに基づいて個別に前記変換文字列に変換し、当該変換文字列内の変数を前記取得されたロケールに置換することにより、当該入力を受け付けたパスを複数のパスに変換し、当該複数のパスからなるパス変換候補を生成するパス変換手段と、
当該パス変換候補内の各パスについて前記リスト情報内に存在するかをチェックするパス存在チェック手段と、
前記パス存在チェック手段によるチェックの結果、前記リスト情報内に存在するパスを前記変換されたパスとして前記アプリケーション部に送出するパス送出手段と、
を備えたことを特徴とするパス変換装置。
【請求項２】
請求項１に記載のパス変換装置において、
前記パス存在チェック手段によるチェックの結果、前記パス変換候補内の全てのパスが前記リスト情報内に存在しない場合、前記入力を受け付けたパスを前記変換されたパスとして前記アプリケーション部に送出する手段、
を更に備え、
前記入力を受け付けたパスは、前記ロケールを含まないパスであって、英語圏に対応した画面構成ファイルを示すことを特徴とするパス変換装置。
【請求項３】
ロケールに応じた複数の画面構成ファイルを含むアプリケーションを実行するアプリケーション部から前記各画面構成ファイルを指定するパスの入力を受け付けると、当該パスを前記アプリケーションの利用者のロケールに応じて変換し、当該変換されたパスを前記アプリケーション部に送出し、且つパスリスト記憶手段及び変換ルール記憶手段を備えたパス変換装置に用いられるプログラムであって、
前記パス変換装置を、
前記利用者のロケールを管理するロケール管理手段、
前記各画面構成ファイルを個別に示す各パスのリスト情報を前記パスリスト記憶手段に書込む手段、
前記パスの一部である変換対象と、当該変換対象が変換される変換文字列であってロケールを示す変数を含む前記変換文字列とを定義した複数の変換ルールからなるパス変換ルールを前記変換ルール記憶手段に書込む手段、
前記アプリケーション部からパスの入力を受け付けると、ロケール管理手段からロケールを取得するロケール取得手段、
前記入力を受け付けたパスの一部を前記パス変換ルール内の各々の変換ルールに基づいて個別に前記変換文字列に変換し、当該変換文字列内の変数を前記取得されたロケールに置換することにより、当該入力を受け付けたパスを複数のパスに変換し、当該複数のパスからなるパス変換候補を生成するパス変換手段、
当該パス変換候補内の各パスについて前記リスト情報内に存在するかをチェックするパス存在チェック手段、
前記パス存在チェック手段によるチェックの結果、前記リスト情報内に存在するパスを前記変換されたパスとして前記アプリケーション部に送出するパス送出手段、
として機能させるためのプログラム。
【請求項４】
請求項３に記載のプログラムにおいて、
前記パス存在チェック手段によるチェックの結果、前記パス変換候補内の全てのパスが前記リスト情報内に存在しない場合、前記入力を受け付けたパスを前記変換されたパスとして前記アプリケーション部に送出する手段、
を更に備え、
前記入力を受け付けたパスは、前記ロケールを含まないパスであって、英語圏に対応した画面構成ファイルを示すプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【公開番号】特開２０１２−１９８８１０（Ｐ２０１２−１９８８１０Ａ）
【公開日】平成２４年１０月１８日（２０１２．１０．１８）
【国際特許分類】
【出願番号】特願２０１１−６３２７０（Ｐ２０１１−６３２７０）
【出願日】平成２３年３月２２日（２０１１．３．２２）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【出願人】（３０１０６３４９６）東芝ソリューション株式会社 (1,478)
【Ｆターム（参考）】
【公開日】平成２４年１０月１８日（２０１２．１０．１８）
【国際特許分類】
【出願日】平成２３年３月２２日（２０１１．３．２２）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【出願人】（３０１０６３４９６）東芝ソリューション株式会社 (1,478)
【Ｆターム（参考）】
[ Back to top ]