JP3963394B2 - ソフトウェア障害情報をレポートするための装置 - Google Patents

Description

本発明は、障害情報レポートシステムに関する。更に詳しくは、多言語に渡るユーザ、サポート、開発保守環境におけるソフトウェアの障害に関する障害レポートをするための装置、方法、およびプログラムに関する。

近年のグローバル化の流れにそって、コンピュータ・システム、特にソフトウェアにおいては、開発作業、保守作業、及びユーザに対するサポート窓口等の業務が、多国籍に渡る別個のチームにより協業して行われるようになってきた。また、ユーザ自身が国際化されたソフトウェアを各国の現地事業所でグローバルに使用することも珍しくない。しかし今日においても、このような多国籍、すなわち多言語に渡るソフトウェアの使用環境、サポート環境、開発、及び保守環境のもとでは、いったんソフトウェアに障害が発生した場合には、顧客サポート部門は、迅速な解決のために障害レポート等を翻訳し、適切な部署に伝える必要がある。例えば、ある国のユーザで障害が発生した場合、顧客サポート部門は、海外にある保守部門や、開発部門に障害の内容、再現方法等をその国の技術者等が理解できる言語に翻訳してレポートしなければならない。

ここで、文字（テキスト）の翻訳自体をサポートするシステムや方法は多数知られている（例えば、特許文献１の多言語マニュアルの作成装置、特許文献２の対訳表示方法、特許文献３の多言語文書作成システム、等）。また、文字だけでなく画像と文字が混在したデータから文字部分のみを認識し、翻訳する装置等も開示されている（例えば、特許文献４、５）。
特開２００４−２８０２７５号公報 特開２００１−３３７９５０号公報 特開２００１−２９７０８３号公報 特開２００３−１２２７５１号公報 特開２００２−１０８８５５号公報 特開２００２− ７３９５９号公報

しかしながら、上記の特許文献１〜５に開示された技術は、いずれも一般的な自然言語の翻訳の効率化を目指したものであり、多言語にわたる複雑な環境におけるソフトウェア障害レポートの効率化にはそのまま対処できるものではない。また、特許文献６に開示されているような障害受付システムも知られているが、このシステムでは、ユーザが希望する言語とともに障害受付センターにアクセスを要求する必要があり、ユーザの希望言語での受付は可能になっても、その後の多国籍に渡るサポート部門、保守部門、及び開発部門の間の情報伝達や障害解析に適用可能なものではない。

ソフトウェア製品のユーザからの障害報告やクレームは、通常、現地のカスタマサービスやコールセンター等が受け、米国や、昨今では、インド、中国等の開発元に伝えられる。この間のやりとりに、異なった国籍の担当者が、必然的に関わってくるため、言語障壁というボトルネックが常に存在する。例えば、インドに開発が外注された米国ソフトウェアベンダーの製品が日本で販売された場合、日本語、英語、印語といったリレーがなされる。

クレーム対応への早さ、すなわち障害修正のＴＡＴ（Ｔｕｒｎ Ａｒｏｕｎｄ Ｔｉｍｅ）は、顧客満足と直結しているため、この間の正確・迅速なやりとりが必須となる。しかし、製品機能に精通し、かつ、語学堪能な人的リソースは限られている場合や、不測の事態の余力を抱えていない場合も多い。従って、この間の処理を効率化する必要性がある。具体的には、ソフトウェア製品の障害対応は、例えば、以下の手順で行われる。日本の顧客は、日本にある販売代理店やカスタマーセンターに障害を報告する。日本の担当者は日本語オペレーティング・システムで障害を再現し、再現手順を英語で障害管理システムに入力する（英訳のため、英語版オペレーティング・システム上での問題再現もなされる）。米国の開発リード（チームリーダ）は、障害の性質を評価し、プログラミング上のバグであれば、インド開発者に障害修正作業を割り振る。

昨今では、ＣＲＭ（Ｃｕｓｔｏｍｅｒ Ｒｅｌａｔｉｏｎｓｈｉｐ Ｍａｎａｇｅｍｅｎｔ）ソフトウェアの導入や、ＩＢＭ（登録商標）製品では、ＣＬＥＡＲＱＵＥＳＴ（登録商標）という障害追跡、管理を行うツールを用い、顧客の問題処理を効率化しているが、これら製品には、顧客満足の定量的分析機能、ナレッジデータベース機能、問題分類機能、応答メール自動化機能等の効率化を助ける機能は多くあるが、実務上、最大のボトルネックとなることが多い異なった言語間リレーを効率化する機能は存在しない。

図１は、現在のソフトウェア障害レポートの典型例を示している。ここでは、障害レポート１０には、障害発生までの手順の他、製品Ａの起動後選択されたメニューＢの画面コピー１１（スクリーンショット）、エラーメッセージの表示画面１２、及びユーザまたはサポート部門の見解１３が記述されている。このような障害レポートは、ユーザの使用した環境における言語でまず作成されるのが通常であり（この例では日本語）、サポート部門はこれを解析し適切な言語に翻訳して適切な部署に報告する必要がある。例えば、英語でレポートするためには、障害が実際に再現するかを確認するためにユーザが使用している環境と同等な英語環境を構築しなければならない。また、日本語環境で再現しても、英語環境で再現するとは限らないので動作環境の設定等にも細心の注意が必要である。仮に、再現に成功したとしても、スクリーンショットの取り直し、更に、メニュータイトル（この例ではメニューＢ）をそのソフトウェアが使用している適切な技術用語で正確に英語に翻訳しなければならず、このことは、多くのソフトウェア製品をサポートし、障害をレポートする側にとって大きな労力を必要とする。

本発明は、上記のような様々な課題を解決するためになされたものであり、グローバルなユーザ環境からの、再現手順、問題発生箇所判別のためのソフトウェア障害レポートの自動化を行うシステム等を提供することを目的とする。

本発明は、様々な実施形態において実現可能であるが、以下、主な実施形態についての解決手段について説明する。

第一の実施形態では、
（Ａ）複数の言語に渡るソフトウェア障害レポートのための装置であって、
（Ｂ）障害サポート対象のソフトウェア、および該ソフトウェアの実行のために使用され、複数の言語に対応した、複数のリソースファイルを探索し、前記リソースファイルのそれぞれからメッセージキーと該メッセージキーに対応する文字列を抽出してこれらを収集し、ならびに、前記文字列を翻訳するための手がかりを与える前記文字列に対する付加属性を抽出する、リソース探索部と、
（Ｃ）前記リソース探索部によって抽出された前記文字列および前記付加属性を記憶する、リソース・データベースと、
（Ｄ）前記障害サポート対象のソフトウェアに対する障害を記述した障害レポートから翻訳が必要な文字列を抽出し、前記リソース・データベースを参照して、前記障害レポートに前記文字列を翻訳して埋め込む、翻訳アダプタ部と、
を備える装置を提供する。

また、上記装置は、
前記障害レポートに画像が含まれる場合に、該画像から文字列と文字列以外の画像を分離し、前記文字列に対する翻訳文字列を前記分離された画像に埋め込む画面変換部を更に備えることができる。

第二の実施形態では、
（Ａ）複数の言語に渡るソフトウェア障害レポートのための方法であって、
（Ｂ）障害サポート対象のソフトウェア、および該ソフトウェアの実行のために使用され、複数の言語に対応した、複数のリソースファイルを探索し、前記リソースファイルからメッセージキーと該メッセージキーに対応する文字列を抽出してこれらを収集し、ならびに、前記文字列を翻訳するための手がかりを与える前記文字列に対する付加属性を抽出するステップと、
（Ｃ）前記抽出するステップによって抽出された前記文字列、および前記付加属性をリソース・データベースに記憶するステップと、
（Ｄ）前記障害サポート対象のソフトウェアに対する障害を記述した障害レポートから翻訳が必要な文字列を抽出し、前記リソース・データベースを参照して、前記障害レポートに前記文字列を翻訳して埋め込むステップと、
を含む方法を提供する。

上記方法は、
前記障害レポートに画像が含まれる場合に、該画像から文字列と文字列以外の画像を分離し、前記文字列に対する翻訳文字列を前記分離された画像に埋め込むステップを更に含むことができる。

また、上記の方法は、コンピュータに上記機能を実行させるコンピュータ・プログラムとしても提供可能である。このコンピュータ・プログラムは、通信媒体を経由して提供されるか、あるいはそのプログラムを格納したコンピュータ可読の記録媒体としても提供される。

更に別の実施形態では、
（Ａ）複数の言語環境で使用されるソフトウェアを含むコンピュータ・システム・メンテナンスの方法であって、
（Ｂ）一つの言語によるソフトウェア障害レポートを他の言語に翻訳する際に、
（Ｃ）障害サポート対象のソフトウェアに関する情報からメッセージキーと該メッセージキーに対応する文字列を抽出してこれらを収集し、ならびに、前記文字列を翻訳するための手がかりを与える前記文字列に対する付加情報を抽出するステップと、
（Ｄ）前記抽出するステップによって抽出された文字列、および前記付加情報をデータベースに記憶するステップと、
（Ｅ）前記障害サポート対象のソフトウェアに対する障害レポートに含まれた翻訳が必要な文字列を抽出し、前記データベースを参照して、前記障害レポートに前記文字列を翻訳して埋め込むステップと、
を含む方法を提供する。

以上の本発明の解決手段から得られる作用効果をまとめると以下のようになる。
（１）国際化対応で用いるソフトウェアのリソースファイルから各言語に割り振られた各種のメッセージを含む情報を抜き出し、言語間の対応をつけた形で付加属性と共にリソ−ス・データベースとして格納する。ここで、リソースファイルとは、一般的には、ソフトウェアと共に論理的に配置される動作のために必要な文字列、アイコンやイメージなどの実行不可能なデータ（リソース）を格納したファイルをいう。ここで、メッセージを含む情報を抜き出す際にメッセージキーが利用される。メッセージキーとは、ソフトウェアが表示する各種メッセージを特定するキーとなるもので、通常リソースファイルに含まれるが、リソースファイル名がメッセージキーとなることもある。
（２）障害再現シナリオ、障害報告、スクリーンショットやその他機能に対して、上記（１）で用意されたリソース・データベースを用いてテキスト翻訳や画像情報の翻訳等の処理を行う。各処理機能は、既存の障害管理ツールと有機的に結合する。これにより、ソフトウェアサポート業務におけるデータのやり取りにおいて、適時、情報の言語を切り替えることを可能とする装置、方法、およびプログラムを提供する。

ソフトウェアの多言語サポートのため、ＪＡＶＡ（登録商標）のリソースバンドルのようにソフトウェアと翻訳情報を分離する方法は一般的になっているが、この情報は該当ソフトウェアでの翻訳にのみ用いられている。本発明ではここに格納されている各言語翻訳を抽出し、言語間に対応付けた形で格納する。これにより、ソフトウェアに表示されるメッセージの一覧、およびその正確な多言語表現が、他のソフトウェアから利用可能となる。この方法は該当ソフトウェアのソースコード（ソースコード・ファイル）へアクセスする必要が無い。

障害再現シナリオや、レポート、スクリーンキャプチャ等は、担当者の使用言語により作成・利用される。異なる国籍に情報が渡されるときには、翻訳をする必要があり、ある種の情報は新たな言語環境で再度作成する必要が生じる。本発明では、再現シナリオやスクリーンキャプチャ等に内在する言語固有の情報を、リソースから抽出した情報で動的に置き換える。これにより再度作業を行う手間を軽減するとともに、単一の情報に正確な翻訳を加えた形で切り替えることにより正確な情報伝達を可能とする。

本発明によれば、国際化対応ソフトウェアに備わっている情報を利用して、障害報告作業を自然な形で異なる言語へリレーすることが可能となる。これは従来のソフトウェアや手法、コンピュータ・システム・メンテナンスのサービス手法には備わっていない機能である。多国言語に渡るソフトウェア障害レポートにおいても、障害再現用に多言語を切り替えたマシンを用意しなくとも済み、障害レポート等に含まれる言語依存の部分を一々異なる言語用に新規作成する必要がなくなるようなシステム等を構築できる。本発明により、ソフトウェアの国際化対応に利用される各言語のリソースを利用して、製品に関する情報伝達や障害再現における言語障害を軽減させることができる。

以下、本発明を代表的な実施形態に則して図を参照しながら説明する。以降の説明では前述のリソース探索部をリソース・クローラ部、画面変換部をスクリーンキャプチャ・トランスレータ部、及び翻訳アダプタ部をトランスレーション・アダプタ部と呼ぶことにする。

図２は、本発明の一つの実施形態として、ソフトウェア障害レポート装置２０の機能ブロック図を示したものである。本実施形態におけるソフトウェア障害レポート装置２０は、入力データとして、障害レポート２１、各言語のリソースファイル２２（以下単にリソースファイル２２と言う）を扱い、主に、リソース・クローラ部２３、リソース・データベース２４、スクリーンキャプチャ・トランスレータ部２５、トランスレーション・アダプタ部２６から構成される。また、既に製品化されている公知の障害管理ツール２７を含んでよい。更に、キーボードやマウス等の一般的な入力部２８ａ、ＣＲＴや液晶画面等の出力部２８ｂ、イーサーネット（登録商標）アダプタ等を備えた通信部２９を含んでよい。また、入出力すべても通信回線を通じて他のシステムとデータ交換を行うようにしてもよい。

上記の構成は、一例を示した過ぎずこれに限定されるものではない。同等な機能を備えたものであれば他の構成であってもよい。以下、本装置の各部についての機能を説明する。

リソース・クローラ部２３は、障害時にサポート対象となるソフトウェア・プログラムが持つ翻訳可能な文字列を、そのプログラムを構成するファイル、またはプログラムのソースファイルから抽出する機能を有する。具体的には、以下の機能を持つ。
（１）ソフトウェア・プログラムおよび実行環境から各言語のリソースファイル２２を探索する。
（２）各言語のリソースファイル２２から各国語のメッセージキーとそれに対応する文字列を抽出、リソース・データベース２４に格納する。
（３）ソフトウェア・プログラムのソースファイルが入手可能ならばこれを走査し、付加属性をリソース・データベース２４に格納する。ここで付加属性（付加情報）とは、翻訳時に訳文を正しく判断する手がかりを与える属性（情報）を言う。
（４）ソフトウェア・プログラム実行時のウィンドウＩＤ、使用ファイル（ソフトウェアが読み込んでいるクラスファイル等）を取得し、付加属性をリソース・データベース２４に格納する。

リソース・データベース２４は、リソース・クローラ部２３によって収集された翻訳文字列を保持するデータベースであり、具体的には以下の情報を保持する。
（１）リソース・クローラ部２３が収集した翻訳文字列、および、付加属性を保持する。
（２）システムにおける標準的なボタン、アイコン等の情報を保持する。
（３）一般的なリソースファイルにおける命名規則を保持する。
（４）リソースファイル２２の変更履歴を保持する。

トランスレーション・アダプタ部２６は、動的翻訳実行時に使用される、障害レポートの翻訳機能、具体的には以下の機能を有する。トランスレーション・アダプタ部２６は、レポートの形式（テキスト形式、画像形式、再現シナリオ・スクリプト形式）ごとに複数存在してもよい。
（１）テキストから翻訳が必要な文字列（原文）を抽出する。
（２）原文から訳文を取得する。
（３）訳文から曖昧性を除去する。ここで曖昧性を除去とは、訳文が一意に定まらない場合に、誤った判断をひきおこさない最も確かな訳文候補を選出することをいう。
（４）訳文を元のテキストに埋め込む。

スクリーンキャプチャ・トランスレータ部２５は、レポートに画像が含まれる場合、トランスレーション・アダプタ部２６または障害管理ツール２７から呼ばれ、障害レポートの中に含まれる画像から文字列を切り出す、または、画像に文字列を埋め込む。具体的には以下の機能を有する。
（１）画像（ビットマップ）から、テキスト部分と、それ以外の部分を分離する。
（２）抽出されたテキスト部分は、バイト列に変換する（ＯＣＲ機能）。
（３）画像に文字列を埋め込む。
（４）画像に含まれるアイコン等を判別する。
また、スクリーンキャプチャ・トランスレータ部２５は、オプションとして備えられた翻訳辞書２６ａを参照して翻訳を行う。翻訳辞書２６ａ自体は、公知の技術を用いてよい。

障害管理ツール２７は、障害レポート管理、障害解決状況トラッキング、責任担当部門ヘの情報伝達等を総合的にサポートするツールである。図２では簡単化のため、障害管理ツール２７がソフトウェア障害レポート装置２０に含まれる場合を示しているが、障害管理ツール２７は、通信部２９を介して通信回線経由で中央サーバ等に備えるようにしてもよい。

図３は、本発明の第二の実施形態であるソフトウェア障害レポートシステム３０の全体を示す図である。本実施形態においては、前述のソフトウェア障害レポート装置２０の主要部である、リソース・クローラ部２３、スクリーンキャプチャ・トランスレータ部２５、トランスレーション・アダプタ部２６を、個別の装置（典型的にはネットワーク３８で接続されたクライアント装置やサーバ装置）で構成されたコンピュータ・システムとして実現したものである。特に図示していないが、各装置はネットワーク３８に接続されたコンピュータで実現できる。この図では、各装置は個別にそれぞれ独立してネットワーク３８に接続されたものとして示しているが、典型的には、リソース・データベース３４、トランスレーション・アダプタ３６、障害管理ツール３９は、保守管理部門のセンターサーバ内に装備されることが考えられる。これらのサーバは複数あってよいし、国毎、プロジェクト毎、部門毎等の別個のロケーションに個別に備えられてもよい。また、リソース・クローラ３２、サポート対象ソフトウェア３１、およびソフトウェア毎の各言語リソース３３ａ、３３ｂ、３３ｃ（リソースファイル）は、解析の便宜のために開発部門やテスト部門のクライアント装置またはサーバ装置に備えられてもよい。各装置の機能については、ソフトウェア障害レポート装置２０で説明した各機能部と同等であるので、ここでは説明を省略する。

図４は、障害管理ツール３９がサポートする動作ログ、画面イメージ、再現スクリプト等の障害管理レポートに含まれる情報が各国の担当部門が希望する言語で（典型的にはリソース・データベースから）取り出される様子を示している。ここでは、ユーザからの障害等を受付けるサポート部門が日本のシステム４１にあり、開発部門が英語圏のシステム４４、テスト部門が韓国のシステム４３および中国語圏のシステム４２にある場合を示している。ただし、障害管理ツール３９自体には障害レポートの翻訳機能は備えられていない。また、既に述べたように、障害管理ツールは、ＣＬＥＡＲＱＵＥＳＴ（登録商標）等の公知の製品を使用することができる。

本明細書では、リソース・クローラ３２、リソース・データベース３４、スクリーンキャプチャ・トランスレータ３５、トランスレーション・アダプタ３６、障害管理ツール３９等の主要部については、一つの装置内の機能部である場合と、別々のサーバ装置内の機能である場合と、および方法の各ステップを表す場合とがある。従って、特に区別する必要がない限り、以下、単にリソース・クローラ等のように符号番号を省略して表記することにする。続いて各部の処理を更に、詳しく説明する。

図５は、リソース・クローラとリソース・データベースの概念図を示す図である。リソース・クローラは、サポート対象ソフトウェア、ＯＳ（オペレーティング・システム）やＪＡＶＡ（登録商標）等の実行環境の各言語のリソースファイルを探索する。各言語リソースには、言語毎にメッセージキーとそれに対応する文字列を保持している。リソース・クローラは、リソース・データベースにメッセージキーを元に各言語の対応をつけた表を作成する。

図６は、リソース・クローラの処理フローを示す図である。まず、ステップＳ８００において、リソースファイルを探索する。次にステップＳ８０１において、可読形式（すなわち圧縮されたファイルやバイナリ形式でない）であるかどうかを判断し、可読形式でなければ、解凍等必要な処理を行い可読形式に変換する（ステップＳ８０２）。可読形式であれば、ステップＳ８０３においてリソースファイルから各国語メッセージを抽出する。更にステップＳ８０４において、メッセージをＤＢ（リソース・データベース）に登録する。次にステップＳ８０５において、付加属性を取得可能かどうか判断し、付加属性が取得可能であれば、付加属性をＤＢに登録してステップＳ８０７へ進む（ステップＳ８０６）。付加属性が取得可能でなければ、他のリソースファイルが存在するかどうかを判断し（ステップＳ８０７）、他のリソースファイルについてステップＳ８０１〜Ｓ８０６の処理を繰り返す。次に、ステップＳ８０８において、ソースファイルが参照可能かどうかを判断し、参照可能であればソースファイルから付加属性を抽出し、ＤＢに登録してステップＳ８１１に進む（ステップＳ８０９、Ｓ８１０）。ソースファイルに対する処理が終わった後、ステップＳ８１１では、ソフトウェアを実行して更に付加属性を取得できるかを判断する。最後に、付加属性が取得可能な場合は、対象ソフトウェアを実行して実行情報から付加属性を抽出し、ＤＢに登録して全ての処理を終了する（ステップＳ８１２〜Ｓ８１４）。

図７は、スクリーンキャプチャ・トランスレータの処理の流れを示す図である。この図で示すように、スクリーンキャプチャ・トランスレータは、障害時に表示されたメッセージ画面（パネル５０）を解析し、翻訳すべき文字列のみを各国語に翻訳し、更に、元の画面イメージに埋め込む機能を有する。ここでは、画面５７が英語、画面５８がドイツ語、画面５９が韓国語に翻訳されて出力された例を示している。

図８は、図７の処理を更に詳しく説明したものである。すなわち、処理すべきパネル５０をフォント・データ５１から得られるフォントパターンから画像と文字を分離する。パネルに表示される文字はおおよそ決まっているのであらかじめ使用される頻度が高い文字等は登録しておくことでフォントパターンの比較が効率化される。ここで、ＯＣＲ（Ｏｐｔｉｃａｌ Ｃｏｄｅ Ｒｅａｄｅｒ）等の公知の文字認識技術を利用してよい。パネル５０から文字と画像が分離された結果、空白画像５１と文字部５２のようになる。文字部５２には、リソース・データベースを参照して（リソース・データベースにない場合は、公知の翻訳辞書を用いて）他の言語５３〜５５に翻訳する。

ここで、ソフトウェアのコードやバイナリ（実行ファイルや圧縮ファイル等はバイナリ形式で提供されることも多い）から直接文字列を抽出することで翻訳の精度を飛躍的に向上させることができる。これは、文単位の比較（リソース・データベースを用いて）による翻訳なので、単語や形態素解析に依存する曖昧性がないこと、同一パネルから複数の文字列を抽出することで翻訳対象のパネルを的確に特定できること、によるものである。また、パネルに使用されているアイコン情報もメッセージの種類とパネルを特定するための有力な情報となる。

最後に、翻訳された空白画像５６と翻訳済み文字列５３〜５５から各言語用の画像を作成する。以上の結果、５７〜５９のような画面データが得られる。ここで、翻訳後の文字列が画像に収まらないような場合は、更に次のような調整を自動的に行うこともできる。
（１）文字列を折り返す。
（２）文字列のフォントを小さくする。
（３）画像を拡大する。
また、言語によっては（アラビア語のように）文字列を右から左に書くものもあり、その場合が画像を左右反転させた後、文字列を埋め込むことも可能である。

図９は、スクリーンキャプチャ・トランスレータが文字列を抽出する際の、別の例を示したものである。ここでは障害時の初期画面９１（ここではダイアログを例にする）がある場合、次の情報を用いて、文字列部分を分離する。
ａ）ダイアログの既定色情報
ｂ）ダイアログの既定フォント情報
ただし，ダイアログの色とフォントの情報は，既定値と異なる場合もあるので，次の方法も活用する。
ｃ）ＯＳに存在するフォントから適当な文字を選びパターンを比較する。
物の画像が日本語の場合、ひらがなや句読点等の使用頻度の高い文字が効率的である。これは、言語ごとに最適化された文字を選ぶ。
ｄ）輝度、彩度等の色調情報を活用して、輝度や彩度が離れている色の組み合わせから、ダイアログの背景色と文字色を推測する。
文字列を抽出する過程をイメージにすると図中の９２のようになり、６組の文字が抽出できる。画像だけのデータ９３も保持する。

図１０は、トランスレーション・アダプタと、他との関係を示す図である。既に説明したように、トランスレーション・アダプタは、翻訳すべき再現シナリオ・スクリプト３７ａ、テキスト形式レポート３７ｂ、及び画像形式レポート３７ｃを入力データとする。このうち画像形式レポート３７ｃは、そのままスクリーンキャプチャ・トランスレータに引き渡してもよいし、トランスレーション・アダプタからスクリーンキャプチャ・トランスレータを呼び出す形にしてもよい。

図１１は、トランスレーション・アダプタに対する再現シナリオ・スクリプトの簡単な例を示す図である。オリジナルの再現シナリオ・スクリプトに含まれる翻訳すべき文字列のあるフィールド６０〜６２を、スクリプト構文にしたがって識別し、リソース・データベース上の各言語の対応表６３を参照して、翻訳すべき文字列と指定の言語の翻訳後の文字列を抽出する。抽出して翻訳された文字列は６４〜６６に示すように再現シナリオ・スクリプトに埋め込まれる。

図１２〜図１７は、以上説明した、障害発生でユーザサポートが行う行為、リソース・クローラ、リソース・データベース、及びスクリーンキャプチャ・トランスレータの一連の動きをまとめたものである。以下、一部重複になるが簡単に説明する。

図１２は、障害発生時の、典型的にはサポート部門の報告者が行う、障害パネル（障害発生時に、障害を示す情報を切り取ったもの、多くの場合、障害ウィンドウや障害ダイアログボックスが該当する）作成の処理フローを示す図である。多くの場合、障害発生時（ステップＳ１１１）に、スクリーンキャプチャ（スクリーンショット）を行い（ステップＳ１１２）、障害パネルを作成する（ステップＳ１１３）必要がある。

図１３は、リソース・クローラが行うリソース・データベース３４の作成処理フローを示す図である。ＯＳ依存言語情報１３０、ＪＡＶＡ（登録商標）言語依存情報１３１、アプリケーション言語依存情報１３２はリソースファイルの一例である。図示するように、リソース・クローラは該当ソフトウェアの全てのサポートしている言語についてリソースファイルを探索し、翻訳に有用な情報をリソース・データベース３４に蓄積する。詳細については、図６を参照。

図１４は、障害パネルの分類の処理フローを示す図である。ここでは障害レポートが画像データの場合を想定している。まず、対象画面のタイトル（パネル・タイトル）を判別し（ステップＳ１３１）、パネル・タイトルがない場合は、未登録のパネルであると判断して、未登録パネルの翻訳へ処理を渡す（ステップＳ１３４）。パネル・タイトルがある場合は、画像から文字列抽出サブルーチンを呼び出し（ステップＳ１６０）、文字列をここで実際に抽出する。パネル・タイトル、及び抽出された文字列からリソース・データベース３４を参照して既に障害パネルが登録されているかを判断する（ステップＳ１３２）。障害パネルが登録されていれば、登録パネルの翻訳処理（ステップＳ１３３）へと処理を移す。

図１５は、登録パネルの翻訳の処理フローを示す図であり、図１６は、未登録パネルの翻訳の処理フローを示す図である。登録パネル処理と未登録パネル処理共に、対象とする障害パネル３４ａから翻訳すべき文字列をステップＳ１６０において抽出するまでは共通である。登録パネルの場合は、リソース・データベース３４を参照して文字列の翻訳を効率的に行えるが、未登録パネルの場合は、リソース・データベース３４に必要な情報がないので、公知の翻訳辞書を備えた翻訳サーバを呼び出し（ステップＳ１５１）、必要な翻訳を行う。その後、翻訳された文字列の画像への埋め込みの処理については、共通である。

図１７は、文字列抽出サブルーチン（ステップＳ１６０）の処理フローを示す図である。文字列抽出サブルーチンは、スクリーンキャプチャ・トランスレータの中核をなす部分である。この処理は既に概略は説明済みであるが更に、詳しく説明すると、ステップＳ１６１において文字列の色調を推測し、ステップＳ１６２において、フォント・データ５１を参照して特定色調とフォント（パターン）を照合し、文字列抽出ができるかを判断する。この判断がＹｅｓの場合は、文字列を抽出する（ステップＳ１６４）。この判断がＮｏの場合は、予め試行錯誤のトライアル回数を定めておき、その試行回数までは色調データの推測条件等を変化させてステップＳ１６１、Ｓ１６２を繰り返す。試行回数を超えた場合は、文字列の抽出ができないと判断し、エラー用代替文字列を出力する（ステップＳ１６５）。

＜１．方法の概要＞
図１８は、本発明の他の実施形態としてのソフトウェア障害レポート方法について概要をまとめたものである。すなわち、本実施形態では、以下の４つの処理を行う。
（１）原本となる障害レポートを取得する（ステップＳ１８１）。
登録されている障害レポートを取り出す。
（２）テキストデータから翻訳が必要な部分を抽出する。
また、画像データから文字部分を認識、文字列を抽出。文字列を除く画像部
分を抽出する（ステップＳ１８２）。
（３）原文と訳文の対応関係取得する（ステップＳ１８３）。
すなわち、ユーザの望む言語への訳文を取得する。
（４）訳文による障害レポートを作成する（ステップＳ１８４）。
すなわち、（２）で切り出された部分に適当な訳文を挿入する。（２）で作成され
た画像に訳文を埋め込み、画像を再構成する。

以下、上記の（１）〜（４）のステップについて更に説明する。
（１）訳文を得るまでの流れ
大きく分けて、次の３つの流れがある。
１）一致する候補がない。
２）一致する候補が一つだけ存在する（訳が一意に決定できる）。
３）一致する候補が複数存在する。
ここで言う「候補」とは、「リソース・データベースに格納されている、原文と同じ言語の文字列」で、検索時に見つかる文字列のことを指す。

図１９にこの処理フローを示した。ステップＳ１９１において、リソース・データベースから候補を取得する。次に、ステップＳ１９２において、完全一致候補があるかどうか判断する。Ｎｏの場合は、ステップＳ１９３において、複合文処理、変数部分処理を行い、その後ステップＳ１９１に戻る。ステップＳ１９２においてＹｅｓの場合は、その完全一致候補が複数あるかを判断し（ステップＳ１９４）、複数あれば、ステップＳ１９５において、追加情報を用いて候補の絞込みを行い、ステップＳ１９６に処理を移す。また、ステップＳ１９４でＮｏの場合も同様にステップＳ１９６に処理が移り、候補に対応する訳文でユーザが望む言語のものを取得する。

（２）訳が必要となる原文の切り出し
画面の場合は、例えば、スクリーンキャプチャ・トランスレータのような方法を用いて、画面から文字列と画面を分離する。分離された文字列が原文となる（図２０参照）。テキスト形式の場合は、例えばトランスレーション・アダプタのような方法を用いて、翻訳が必要な文字列とそれ以外を分離する（図２１参照）。

（３）原文と訳文の対応関係取得
１）与えられた原文と完全一致する文字列をリソース・データベースから検索する。
２）一致する文字列を発見した場合には、それに対応する求める言語の訳文を取得する。
３）一致する文字列が複数あり、それに対応する訳文が異なる場合には、曖昧性除去処理を行う。

（単一一致の例）
図２２（ａ）に示すようなリソース・データベース内のデータから日本語の「警告形式のウィンドウ」を検索する。
一致した文字列が発見されたので、対応する訳文を取得する。例えば、英語の場合「警告形式のウィンドウ」→「Ｗａｒｎｉｎｇ Ｗｉｎｄｏｗ」と翻訳する。

（複数一致の例）
図２２（ｂ）に示すようなリソース・データベース内のデータから日本語の「エラーが起きました。」を検索する。
一致した文字列が発見されたので、対応する訳文を取得する。例えば英語の場合
「エラーが起きました。」→「Ｅｒｒｏｒ ｈａｐｐｅｎｅｄ．」、 「Ｅｒｒｏｒ ｏｃｃｕｒｒｅｄ．」と二つとなる。
また、一致する文字列が複数あり、それに対応する訳文が異なるので、曖昧性除去処理を行う。詳しくは後述の、（２−３）訳文の候補が複数存在する場合を参照されたい。

一致する文字列が発見できない場合は、原文が複数の文字列から構成されている可能性や、動的に与えられる文字列が組み込まれている可能性が高い。原文を分割、変数部分を除いて文字列を検索することにより、訳文を取得する。詳しくは、後述の、（２−２）訳文の候補が存在しない場合を参照されたい。
（４）訳文による障害レポートの作成
画面の場合は、得られた訳文と画面を再構成する（図２３参照）。
テキスト形式の場合は、得られた訳文を翻訳が必要な場所に挿入する（図２４参照）。

＜２．訳文を得る流れの詳細＞
以下、訳文を得る流れについて詳細に説明する。

（２−１）訳文の候補が一つだけ存在する場合
原文に一致するものがリソース・データベース中に一つしか存在しない場合、それに対する訳文は一意に定まる。図２５にこの処理フローを示した。ステップＳ２５１において、リソース・データベースから訳文の候補を取得する。次にステップＳ２５２において、取得した候補と原文が完全一致でかつ唯一である場合（ステップＳ２５４：Ｙｅｓ）、候補に対応する利用者が求める言語の訳文を取得する（ステップＳ２５４）。ステップＳ２５２がＮｏの場合は、複合文・変数部分処理や候補の絞込み（ステップＳ２５３）を行う。
（２−２）訳文の候補が存在しない場合
リソース・データベースはアプリケーションにおいて表示されるメッセージ等の情報をすべて持つが、その中に原文と一致する文字列が存在しない場合には、原文が複数の文字列から構成されている可能性がある。すなわち以下の二つの場合がある。
１）原文が一つの文章ではなく、複数文字列の組み合わせからできている場合
２）原文の中に、動的に与えられる文字列が組み込まれている場合
これらの場合には、文の境界で分割することや、変数部分を別に切り出すことで、一致する訳文を探すことができる。

図２６にこの処理フローを示す。ステップＳ２６１において、リソース・データベースから変数を含む候補を取得する。変数以外が一致する場合（ステップＳ２６２：Ｙｅｓ）、変数部分を切り出し（ステップＳ２６３）、終了する。変数以外が一致しない場合（ステップＳ２６２：Ｎｏ）、境界があるかどうかを判断し、ある場合は（ステップＳ２６４：Ｙｅｓ）、ステップＳ２６５において境界を分割して終了する。境界がない場合は（ステップＳ２６４：Ｎｏ）、そのまま終了する。

１）の場合：
文字列の境界を認識し、文字列を分割する。文字列の境界は改行、スペース、句読点等の情報を利用することにより認識することが出来る。また形態素解析を用いると、意味のある単位での文字列の分割が可能である。

２）の場合：
リソース・データベースに変数を含む文字列が存在する場合、その変数部分を除いて一致する文章を取得する。また変数部分に対応する訳文がリソース・データベースから出来る場合は、得られた文章に挿入する。

（２−３）訳文の候補が複数存在する場合
一つの翻訳対象文に対し複数の翻訳候補文がリソース・データベースに存在する場合がある。例えば、「エラーが起きました。」といった比較的単純な文の場合、訳文の候補として、「Ｅｒｒｏｒ ｏｃｃｕｒｅｄ．」や「Ｅｒｒｏｒ ｈａｐｐｅｎｅｄ．」等、複数存在する場合が考えられる。そこで、どの訳文を採用するかを決定する必要がある。その判断においては、該当文が「どの“文脈”により表示されたか」が重要な手がかりとなる。訳文を正しく選択する手がかりを与える属性をここでは、付加属性と呼んでいる。付加属性を用いれば翻訳の精度を向上させることができる。

ソフトウェア・プログラムにおいて、文字列への付加属性は数多く考えられる。適切な訳文選択のための、精度の高い情報を与えるものとして以下のようなものが考えられる。それぞれ、次のような情報を提供する。
１）ウィンドウタイプ
ａ）「警告」、「エラー」、「情報」といった、メッセージの趣旨
ｂ）「ＹＥＳ／ＮＯ」、「ＯＫ」等、どのようなレスポンスが求められるか
ｃ）ウィンドウＩＤ
ｄ）どういう処理シーケンスで表示されたメッセージ
ｅ）その文字列はどのウィンドウに所属するか
ｆ）所属するウィンドウの親子関係
２）命名規則
ｇ）メッセージの趣旨
ｈ）出現場所のカテゴリー
ｉ）メッセージが存在するクラス名
３）画面情報
ｊ）メッセージの趣旨
ｋ）どのようなレスポンスが求められているか
ｌ）ボタン、メニュー、メッセージ文といったメッセージの出現場所のカテゴリー

これら付加属性は、それぞれ単独で用いてもよいし、併用してもよい。以下、これらの各付加属性については、実施例１〜３として説明する。

［ウィンドウタイプを付加属性とする方法］
通常、ソフトウェア・プログラムでは、メッセージウィンドウは、ソフトウェアプログラマーが、初めからプログラミングするのではなく、既存のカスタムウィンドウを用いる。カスタムウィンドウは、ＯＳが初めから備えているもので、それを使用したい場合、プログラマーは、ウィンドウのタイトルと、メッセージ文、ウィンドウのタイプを指定するだけでよい。このことは、Ｃ／Ｃ＋＋、ＪＡＶＡ（登録商標）、ＶＩＳＵＡＬＢＡＳＩＣ（登録商標）等、ＧＵＩを備えたプログラムを作成するプログラミング言語に共通に当てはまる。

＜リソース・クローラが走査する情報＞
リソース・クローラは、ウィンドウタイプを取得するために、プログラムのソースコードを走査する。以下では、簡単のため、ＶＩＳＵＡＬＢＡＳＩＣ（登録商標）を用いたプログラムサンプルを図２７に示す。関数ＭｓｇＢｏｘは、メッセージウィンドウを表示し、引数１は、メッセージ文、引数２は、メッセージウィンドウのタイプ、引数３は、メッセージウィンドウのタイトルである。なお、このプログラムは、コマンドプロンプトより、ｃｓｃｒｉｐｔ ｍｅｓｓａｇｅｓ．ｖｂｓとタイプすることにより動作させることができる。

上記のプログラムを実行すると、図２８のようなメッセージウィンドウが表示される。メッセージウィンドウのタイプにより、そのメッセージが「重大エラー」として発せられ、その対応としては「ＯＫ」ボタンしか押せないもの（２８１）、そのメッセージが「警告」として発せられ、その対応としては「ＯＫ」ボタンしか押せないもの（２８２）、そのメッセージに対し、「はい」、「いいえ」で答えるもの（２８３）、複数のアクションを選択できるもの（２８４）といった形で、メッセージウィンドウタイプは、多くの情報を保持する。メッセージウィンドウタイプは、十数個存在し、かつ、応答ボタンとの組み合わせを考慮すると数十となる。従って、訳文を一意に決定するための重要な付加属性とすることができる。

＜リソース・クローラの実装法＞
メッセージ画面を表示するＡＰＩは、非常に限定的であるので、リソース・クローラは、簡単なテキスト処理を行うプログラムによって実現できる。具体的には、正規表現関数を用いた、シェルスクリプト等で実装できる。ここで、正規表現関数とは、必要とする文字列のみをテキストファイルから抽出するために利用できるパターン処理関数群である。上述のＶｉｓｕａｌＢａｓｉｃ（登録商標）プログラム例では、“ＭｓｇＢｏｘ”が出現する行から、ダブルクオート（“）で囲われた文字列、および、ウィンドウタイプとして、ｖｂＸＸＸ（ウィンドウタイプの書式）で始まる文字列を抽出するという処理により実装できる。

＜リソース・データベース＞
リソース・データベースは、メッセージウィンドウタイプ、および、そのメッセージウィンドウのタイトルを含む。図２９は、メッセージタイプを保持したリソース・データベースの例を示したものである。

＜翻訳決定アルゴリズム＞
「エラーが起きました。」というメッセージが障害レポート内にあるとする。そして、そのメッセージを表示するメッセージウィンドウのタイプ、および、ダイアログタイトルが、それぞれ、ｖｂＥｘｃｌａｍａｔｉｏｎ、「警告形式のウィンドウ」とすると、訳文は「Ｅｒｒｏｒ ｈａｐｐｅｎｅｄ．」と決定することができる。

障害レポートからメッセージウィンドウタイプとダイアログタイトルは以下のように判定する。以下の２パターンが考えられる。

障害報告レポートがテキストで記述されている場合： ダイアログのタイトルが記述されているため、それを元に翻訳を決定する。またレポート中の「警告」「情報」等のキーワードからも、メッセージウィンドウタイプがわかる。

スクリーンキャプチャで障害報告がされている場合： 画面に現れるメッセージの他に、画像が持つ文字以外の部分から付加属性を取り出し利用する。詳しくは、後述の実施例３で示す［補足：スクリーンキャプチャ・トランスレータからのアイコン抽出］を参照されたい。

［ウィンドウＩＤを付加属性とする方法］
ここでは、翻訳文字列をウィンドウＩＤと関連付けると、訳文の選択を正しく行えることを示す。まず、図３０のダイアログ・ウィンドウを例にとる。

このダイアログ・ウィンドウは、テキストラベル、入力フィールド、ボタン等によって構成されている。プログラム内部では、これら全ての構成要素には、固有のＩＤが割り振られており、プログラムは、このＩＤを手がかりに構成要素を識別する。例えば、ユーザがこのダイアログ・ウィンドウに対して行った処理は、イベントとしてプログラムに渡される。「実行」ボタンがクリックされた場合を例にとる。実行ボタンにＩＤ番号１００が割り振られていたとすると、「要素１００上でクリックボタンが押された」というメッセージがオペレーティング・システムから飛ばされる。その際の処理は、プログラムコード内に（Ｃａｓｅ文等で）定義する。つまり、このＩＤ番号は、完全な精度で要素を特定する手段といえる。

＜リソース・クローラが走査する情報＞
図３１は、Ｗｉｎｄｏｗｓ（登録商標）オペレーティング・システム上のプログラムで、ダイアログ・ウィンドウの形状、および、それを構成する構成要素のＩＤを定義しているリソースファイルと呼ばれるソースコード（ｓａｍｐｌｅ．ｒｃ）の一部を示したものである。

先頭行のＬＡＮＧＵＡＧＥ宣言３１１は、以下の定義がどの言語用かを示す。それに続く＃ｄｅｆｉｎｅ宣言３１２が、構成要素のＩＤを定義する。そして、構成要素の文字列とＩＤとの関連付け等の情報が以下に続く。
ＩＤＤ＿ＴＥＳＴ ＤＩＡＬＯＧＥＸ ２２，１７，２５７，１３０―――３１３
ＣＡＰＴＩＯＮ “ｗｉｎ３２アプリケーションテスト” ―――３１４
は、このダイアログ・ウィンドウ自体のＩＤ、および、ダイアログタイトル（“ｗｉｎ３２アプリケーションテスト”）である。（＃ｄｅｆｉｎｅ宣言より、ＩＤＤ＿ＴＥＳＴが１００とされていることから）ＩＤは１００とわかる。（続く数字は、ウィンドウの配置であり、座標（２２、１７）を起点とし、横長２５７、縦長１３０であることを示す。）そして、ＢＥＧＩＮ３１５以下のステートメントは、そのダイアログ・ウィンドウ上の構成要素上の文字列とＩＤの関連付け等を示す。

例えば、ＬＴＥＸＴ “データ（＆Ｄ）：”、ＩＤＣ＿ＳＴＡＴＩＣ＿１、６、９、５０、８は、”データ（＆Ｄ）”という文字列は、ＩＤ番号は１０２であることを示す。

＜リソース・クローラの実装法＞
プログラムソースにアクセスできる場合：
リソース・クローラは、上述のファイルを走査し、リソース・データベースを作成することになる。その流れは以下のようになる。
１）ＬＡＮＧＵＡＧＥ宣言を発見し、言語をリソース・データベースに保管する。
２）ダイアログ・ウィンドウのＩＤおよび、タイトル文列を保管する。
３）各構成要素のＩＤ、および、関連付けされた文字列を保管する。

これは、簡単なテキスト処理を行うプログラムによって実現できる。具体的には、正規表現関数を用いた、シェルスクリプト等で実装できる。正規表現関数は、必要とする文字列のみをテキストファイルから抽出するために利用できるパターン処理関数郡である。

プログラムソースにアクセスできない場合：
リソース・データベースは、ソースコードに直接アクセスした場合のほうが、より容易に作成できるため、（障害レポートの）対象となるソフトウェア・プログラムの開発者によって提供されることを想定している。しかし、ソースコードへのアクセスができない状況、つまり、実行形式（バイナリ形式）のみで提供されたプログラムにおいても、ウィンドウＩＤ、文字列を取得することが可能である。

＜リソース・データベース＞
リソース・データベースに保管されたデータは、図３２に示すウィンドウＩＤを保持したリソース・データベースで整理される。各文字列の対訳に加えて（ウィンドウ）ＩＤ３３０、および、親（ウィンドウ）ＩＤ３３１が保管されている。例えば、「データ」および「フォルダ」は、ウィンドウＩＤが１００であるウィンドウ・タイトル「Ｗｉｎ３２アプリケーション」というウィンドウに所属することがわかる。この情報保持方法により、階層構造になった構成要素もチェーン形式で紐付けがわかる。

＜翻訳決定アルゴリズム＞
通常、障害レポートは、メニュー選択→表示画面→画面上での処理、といった一連の操作によって説明される。たとえば、「ファイル選択」画面より、「選択」ボタンを押す。従って、同じウィンドウに所属する翻訳文字列が近傍に出現するのが通常である。従って、近傍の例えば、数個の翻訳をバッファリングしておき、翻訳候補が複数存在する場合、共通の親ＩＤに属する翻訳文字列を優先して選択することにより翻訳精度を高めることができる。

［ファイル構造・メッセージキーを付加属性とする方法］
リソースファイルは、プログラム実行時に挿入されるメッセージとメッセージを一意にあらわすメッセージキーの組み合わせを保持している。リソースファイルは一定の規則に沿ってファイルに梱包されている。配置されるファイル構造も規則に沿ったものである。またメッセージキーの命名にも規則性が容易に見つけられる。これらリソースファイルに関する陰的陽的な規則を利用し、付加属性とする。

＜リソース・クローラが走査する情報＞
リソース・クローラは、アプリケーション本体および実行環境で取得できるリソースファイルを探索し、リソースファイルから各国語のメッセージを抽出し、データベースに格納する。その際、対象文だけではなく、メッセージキーや文を取得したファイル名、ファイル構造等から取得可能な情報もあわせて格納する。

図３３に、ＪＡＶＡ（登録商標）が保持するプロパティ・リソースファイルの例を示す。プロパティ・リソースファイルはｊａｒファイル（プログラムを構成する実行ファイルを圧縮したもの）に梱包されているか、フォルダの中に格納されている。ｊａｒファイル等に梱包されている場合には、これを展開する。このとき、このプロパティファイルが存在するディレクトリ構造、ディレクトリ名、またｊａｒファイル内の構造を取得する。

これらの情報は、このメッセージを出力するアプリケーションの名前、関連するクラス名、またバージョン番号等を含んでおり、それらを付加属性とする。またメッセージに対応するメッセージキーも取得し、同一のメッセージキーで同様の付加属性を持つものを組とする。

＜リソース・クローラの実装法＞
リソース・クローラは、アプリケーションや実行環境で取得できるリソースファイルを探索する。またこの際にｊａｒファイルのような圧縮形式の場合にはこれを展開し、中身を走査する。バイナリ形式のものである場合には、可読な形式に変換する。この仕組みはウイルススキャナやＯＳに付随するファイル検索機能と同等のもので実現できる。リソースファイルは、一定の書式に従って記述されているため、簡単な正規表現処理を用いることにより、メッセージやキー、また付加属性を抽出することができる。それらをデータベースに格納する。

＜リソース・データベース＞
リソース・データベースには図３４で示すようにメッセージキー（ｍｅｓｓａｇｅｋｅｙ）３５０と付加属性３５１〜３５３（ｃｌａｓｓ ｎａｍｅ，Ｖｅｒｓｉｏｎ，ｆｏｌｄｅｒ）が、整理されて格納される。各国語メッセージは同一行に保持される。

＜翻訳決定アルゴリズム＞
「中止」という「ボタン」が現れたとする。これに対する英語訳文の候補としては、リソース・データベースからは「Ａｂｏｒｔ」と「Ｂｒｅａｋ」の両方が取得される。この場合、付加属性を利用し、どちらの訳文がふさわしいか決定する。

メッセージキーの命名規則を用いる場合：
メッセージキーには、暗黙、明示ともに命名規則が適応されるのが普通である。この規則を用いて、メッセージキーからそのメッセージの利用箇所や状態にあたる情報を得る。「中止」の例では規則から、片方はボタンの名前、片方はウインドウメニューの項目と判断し、「Ａｂｏｒｔ」を英語訳文の候補とする。命名規則はそのプロダクトやプロジェクトに応じて定められているため、一般的な命名規則に即したものは容易に対応できる。製品ごとに、一定のルールを規定することで精度を高めることもできる。

クラス名やフォルダ名を用いる場合：
アプリケーションのプロセスＩＤや、プロセスが利用しているファイル名は、公知のツールを用いて取得することができる。この情報とリソース・データベースが持つクラス名、フォルダ名を照合することにより、最も確かな候補を選出する。

許諾可能文字列を選択する場合：
もし確率の高い候補が絞り込めなかった場合には、その両方を併記することが許容されるかどうかを確認する。再現シナリオ・スクリプトでは自動実行においても失敗がないと判断できる場合、両方を並列表記し、スクリプト実行時に自動判断する。例えば、同一画面にｂｒｅａｋ、ａｂｏｒｔ両方の候補が出現しないことが（他メッセージやボタンの翻訳の結果）確認できる場合には、ｂｕｔｔｏｎ［Ａｂｏｒｔ：Ｂｒｅａｋ］と並列表記することにより、スクリプトの実行を可能とする。

［補足：スクリーンキャプチャからのアイコン抽出］
ソフトウェアが表示するメッセージ、特にユーザに注意の喚起を行うメッセージ画面においては、システム特有の状態を表すアイコンが表示される。図３５にそのアイコンが表示された画面例３７１〜３７４を示す。これらのアイコンはそのウィンドウが発するメッセージの性質を現すもので、訳文を一意に決定する付加属性とすることができる。また、その画面に存在する、入力部、ボタンの数等の情報も他の情報と紐付けることにより付加属性となりうる。また、アイコンは国ごとに異なることもあるので、訳文決定の際にアイコン自体をその国に適したものに変更することもある。

＜スクリーンキャプチャ・トランスレータでの実装＞
画面に現れるアイコン、ボタン等の表示はシステムによって標準化されているものが多い。そのためシステム標準のアイコンをあらかじめリソース・データベースに保持しておくことにより、簡単なパターンマッチングにより、画面上に現れている情報の性質、求められているアクションの種別等が高い精度で得られる。ここで、パターンマッチングとは、入力画像の中にあらかじめ標準パターンと同じものがあるか、あるいは近いものがあるかを検出することをいう。また、あらかじめ用意した標準パターンをテンプレートと呼び、入力画像にテンプレートを重ねながら移動し、２つの画像が画素データレベル対応の相関を調べることをテンプレートマッチングという。

以上、本発明を実施形態、および実施例を用いて説明したが、本発明の技術的範囲は上記実施形態に記載の範囲に限定されない。上記実施形態に多様な変更または改良を加えることが可能である。また、そのような変更または改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。

本発明における一つの実施形態として説明したソフトウェア障害レポート装置２０、またはその機能は、コンピュータ上のシステムまたはコンピュータにその機能を実行させるコンピュータ・プログラムによって実現可能である。コンピュータ・プログラムはそれを格納したコンピュータ可読の記録媒体としても提供され得る。媒体は、電子的、磁気的、光学的、電磁的、赤外線または半導体システム（または、装置または機器）あるいは伝搬媒体であることができる。コンピュータ可読の記録媒体の例には、半導体またはソリッド・ステート記憶装置、磁気テープ、取り外し可能なコンピュータ可読の媒体の例には、半導体またはソリッド・ステート記憶装置、磁気テープ、取り外し可能なコンピュータ・ディスケット、ランダム・アクセス・メモリ（ＲＡＭ）、リードオンリー・メモリ（ＲＯＭ）、リジッド磁気ディスクおよび光ディスクが含まれる。現時点における光ディスクの例には、コンパクト・ディスク−リードオンリー・メモリ（ＣＤ−ＲＯＭ）、コンパクト・ディスク−リード／ライト（ＣＤ−Ｒ／Ｗ）およびＤＶＤが含まれる。

本発明の課題に係るソフトウェア障害レポートの典型例を示す図である。 本発明の一つの実施形態であるソフトウェア障害レポート装置の機能ブロックを示す図である。 本発明の他の実施形態であるソフトウェア障害レポートシステムの概要を示す図である。 障害管理ツールを経由して翻訳された様々な情報レポートを各担当部署が得られる様子を示した図である。 リソース・クローラとリソース・データベースの概念図である。 リソース・クローラの処理フローを示す図である。 スクリーンキャプチャ・トランスレータの処理の概念図である。 スクリーンキャプチャ・トランスレータの処理のフローを示す図である。 スクリーンキャプチャ・トランスレータによる画像と文字列とを分離を示す図である。 トランスレーション・アダプタの概念図である。 再現シナリオ・スクリプトの簡単な一例を示す図である。 障害パネルの作成処理フローを示す図である。 リソース・データベースの作成処理フローを示す図である。 障害パネルの分類の処理フローを示す図である。 登録パネルの翻訳の処理フローを示す図である。 未登録パネルの翻訳の処理フローを示す図である。 文字列抽出サブルーチンの処理フローを示す図である。 ソフトウェア障害レポート方法の簡単な処理フローを示す図である。 訳文を得るまでの流れを示す図である。 画面形式の場合の訳文が必要となる原文の切り出しを示す図である。 テキスト形式の場合の訳文が必要となる原文の切り出しを示す図である。 原文と訳文の対応関係取得を示す図である。 画面形式の場合の訳文による障害レポートの作成を示す図である。 テキスト形式の場合の訳文による障害レポートの作成を示す図である。 訳文の候補が一つだけ存在する場合の訳文を得る処理フローを示す図である。 訳文の候補が存在しない場合の訳文を得る処理フローを示す図である。 リソース・クローラが走査するプログラムのソースコードの例を示す図である。 図２７のプログラムを実行した際のメッセージウィンドウの例を示す図である。 メッセージタイプを保持したリソース・データベースを示す図である。 ダイアログ・ウィンドウの例を示す図である。 ダイアログ・ウィンドウの形状、およびそれを構成する構成要素のＩＤを定義するソースコードの一部を示す図である。 ウィンドウＩＤを保持したリソース・データベースを示す図である。 ＪＡＶＡ（登録商標）が保持するプロパティ・リソースファイルの例を示す図である。 メッセージキーと付加属性が格納されたリソース・データベースを示す図である。 ユーザに注意の喚起を行うメッセージ画面におけるシステム特有の状態を表すアイコンを示す図である。

符号の説明

１０ 障害レポートの典型例と課題
２０ ソフトウェア障害レポート装置
２１ 障害レポート
２２ リソースファイル
２３ リソース・クローラ部
２４ リソース・データベース
２５ スクリーンキャプチャ・トランスレータ部
２６ トランスレーション・アダプタ部
２７ 障害管理ツール
２８ａ 入力部
２８ｂ 出力部
２９ 通信部
３１ サポート対象ソフトウェア
３２ リソース・クローラ
３３ａ、３３ｂ、３３ｃ 各言語リソース
３４ リソース・データベース
３４ａ 障害パネル
３５ スクリーンキャプチャ・トランスレータ
３６ トランスレーション・アダプタ
３７ａ 再現シナリオ・スクリプト
３７ｂ テキスト形式レポート
３７ｃ 画像形式レポート
３９ 障害管理ツール
４１ サポート
４２、４３ テスター
４４ 開発者
５０ パネル
５１ フォント・データ
５６ 空白画面
５７、５８、５９ 翻訳後画面
１３０ ＯＳ依存言語情報
１３１ ＪＡＶＡ（登録商標）言語依存情報
１３２ アプリケーション言語依存情報

Claims (19)

1. 複数の言語に渡るソフトウェア障害レポートのための装置であって、
   障害サポート対象のソフトウェアを構成する複数の言語に対応したリソースファイルを入力とし、前記リソースファイルのそれぞれからメッセージキーと該メッセージキーに対応する文字列を抽出してこれらを収集し、前記文字列を翻訳するために利用できる付加属性を前記リソースファイルから抽出する、リソース探索部と、
   前記リソース探索部によって抽出された複数の言語の文字列および前記付加属性を記憶する、リソース・データベースと、
   前記障害サポート対象のソフトウェアに対する障害を記述した障害レポートを入力とし、該障害レポートから翻訳が必要な文字列を抽出し、前記リソース・データベースに記憶された前記複数の言語の文字列と前記付加属性を参照して、前記障害レポートに翻訳文字列を埋め込む、翻訳アダプタ部と、
   を備える装置。
2. 前記障害レポートに画像が含まれる場合に、該画像から文字列と文字列以外の画像を分離し、前記文字列に対する翻訳文字列を前記分離された画像に埋め込む画面変換部を更に備える、請求項１に記載の装置。
3. 前記リソース探索部は、前記付加属性を更に該ソフトウェアのソースコード・ファイルを走査することによって取得する、請求項１に記載の装置。
4. 前記リソース探索部は、該ソフトウェアが実行時に表示するウィンドウに対して設計時に定められたウィンドウＩＤを抽出し、前記リソース・データベースに格納する、請求項１に記載の装置。
5. 前記リソース・データベースは、前記画面変換部によって分離された文字列以外の画像として該ソフトウェアが使用する標準ボタン、アイコンに関する情報を保持する、請求項２に記載の装置。
6. 前記翻訳アダプタ部は、前記障害レポートの前記翻訳が必要な文字列に対する翻訳文字列が一意に定まらない場合の曖昧性を除去する、請求項１に記載の装置。
7. 前記翻訳アダプタ部は、前記障害レポートに画像が含まれることを判断し、画像が含まれる場合に前記画面変換部に該画像から文字列と文字列以外の画像とを分離させる、請求項２に記載の装置。
8. 前記翻訳アダプタ部は、前記障害レポートとして再現シナリオスクリプトとテキスト形式レポートを入力として受け付ける、請求項１に記載の装置。
9. 前記画面変換部は、該画像から文字列を分離するためのＯＣＲ機能を含む、請求項２に記載の装置。
10. 前記画面変換部は、ダイアログの既定色情報、またはダイアログの既定フォント情報の少なくとも一つを用いて該画像から文字列を抽出する、請求項２に記載の装置。
11. 前記画面変換部は、該画像に含まれるアイコンを判別する、請求項５に記載の装置。
12. 前記画面変換部は、翻訳後の文字列が画像に収まらない場合に微調整を行う、請求項２に記載の装置。
13. 前記画面変換部は、文字列を右から左に書く言語に対応して該画像を左右反転させた後に翻訳後の文字列を埋め込む、請求項２に記載の装置。
14. 前記画面変換部は、フォントデータから言語によって使用頻度の高い文字を選びパターンを比較することによって文字列を抽出する、請求項２に記載の装置。
15. 前記画面変換部は、色調情報を用いて輝度や彩度が離れている色の組み合わせからダイアログの背景色と文字色を推測することによって文字列を抽出する、請求項２に記載の装置。
16. 複数の言語に渡るソフトウェア障害レポートのための方法であって、
    コンピュータが、
    障害サポート対象のソフトウェアを構成する複数の言語に対応したリソースファイルを入力とし、前記リソースファイルのそれぞれからメッセージキーと該メッセージキーに対応する文字列を抽出してこれらを収集し、前記文字列を翻訳するために利用できる付加属性を前記リソースファイルから抽出するステップと、
    前記抽出するステップによって抽出された複数の言語の文字列および前記付加属性をリソース・データベースに記憶するステップと、
    前記障害サポート対象のソフトウェアに対する障害を記述した障害レポートを入力とし、該障害レポートから翻訳が必要な文字列を抽出し、前記リソース・データベースに記憶された前記複数の言語の文字列と前記付加属性を参照して、前記障害レポートに翻訳文字列を埋め込むステップと、
    を含む方法。
17. 前記障害レポートに画像が含まれる場合に、該画像から文字列と文字列以外の画像を分離し、前記文字列に対する翻訳文字列を前記分離された画像に埋め込むステップを更に含む請求項１６に記載の方法。
18. 複数の言語に渡るソフトウェア障害レポートのためのコンピュータ・プログラムであって、
    コンピュータに、
    障害サポート対象のソフトウェアを構成する複数の言語に対応したリソースファイルを入力とし、前記リソースファイルのそれぞれからメッセージキーと該メッセージキーに対応する文字列を抽出してこれらを収集し、前記文字列を翻訳するために利用できる付加属性を前記リソースファイルから抽出するステップと、
    前記抽出するステップによって抽出された複数の言語の文字列および前記付加属性をリソース・データベースに記憶するステップと、
    前記障害サポート対象のソフトウェアに対する障害を記述した障害レポートを入力とし、該障害レポートから翻訳が必要な文字列を抽出し、前記リソース・データベースに記憶された前記複数の言語の文字列と前記付加属性を参照して、前記障害レポートに翻訳文字列を埋め込むステップと、
    を実行させる、コンピュータ・プログラム。
19. 前記障害レポートに画像が含まれる場合に、該画像から文字列と文字列以外の画像を分離し、前記文字列に対する翻訳文字列を前記分離された画像に埋め込むステップを更に前記コンピュータに実行させる、請求項１８に記載のコンピュータ・プログラム。

Images