BGM を聞きながら翻訳をする人も多いと思います。私も主にクラッシクのピアノ曲を BGM にしております。ところで、この BGM ですが、IT の恩恵を多いに授かっています。私は、学生時代からのクラッシク音楽のファンですが、当時音楽は 30 センチLP盤に収められておりました。バッハの平均律クラビアを、バルヒャという盲目のチェンバリストの演奏で聞いておりましたが、LP 盤で 5 枚に入っていました。全曲を通して聞こうとすると、裏表合わせて10面ほとレコード針を走らせる必要がありました。今であれば、MP3で全曲１枚のCDに収まります。3時間ほどノンストップで BGM として流すことが可能です。まさに隔世の感じがします。本当に便利になりましたね。3時間はまとまった翻訳をするには丁度いい時間なので、BGM がタイムキーパの役割も果たしています。
さて、MSAA の世界へ今日も BGM を聞きながら優雅に旅立つことにします。
原題: Implementing an MSAA Server
訳題: MSAA サーバーを実装する
原文： 青色表示
訳文： 黒色表示
校正文： 赤色表示
校正対象範囲： 黒色太字表示
Not all MSAA objects implemented by 3rd party vendors
Problem: As described above, screen readers tend to look first for window classes they know, such as Button, ListBox, ComboBox, msctls_statusbar32, msctls_trackbar32, #32770 (dialog class), SysTreeView32, Static, Edit and RichEdit. AT vendors have typically spent the most time making windows with these classes work, so they are fully debugged. In addition, the user comes to expect appropriate behavior for status bars, dialog boxes and tree views based on the fact that most apps use the standard control. Unfortunately, the MSAA implementation often lags. For example, tree views will probably not be accessible with most assistive technologies even if you have a perfect MSAA implementation. Automatic screen reading of dialog boxes and status bars will often not work just because you're using the wrong class name, even if your MSAA implementation is perfect, and everything else about the objects is completely normal.
全てがサードパーティーベンダーによって実装されるわけでない MSAA オブジェクト
問題: 上記で説明しましたように//→上述しましたように//、スクリーンリーダは、ボタン、リストボックス、コンボボックス、msctls_statusbar32、 msctls_trackbar32、#32770 (ダイアログクラス)、SysTreeView32、Static、Edit および RichEdit など、最初に自分が知っているウィンドウクラスを探す傾向があります//→ボタン、リストボックス、コンボボックス、msctls_statusbar32、 msctls_trackbar32、#32770 (ダイアログクラス)、SysTreeView32、Static、Edit 、RichEdit など、スクリーンリーダは、最初に自分が知っているウィンドウクラスを探す傾向があります//。//挿入：→補助テクノロジー//ベンダーではこれらのクラスの働きによってウィンドウを機能させることに//→作ることに//時間のほとんどを費やし//→費やするので//、ウィンドウは完全にバクとりされます。さらに、ユーザーは、多くのアプリケーションが標準的な制御を使うという事実に基づいて、ステータスバー、ダイアローグボックス、ツリービューが正しく動作することを期待するようになります。不幸にして//→残念ながら//、 MSAA の実装は遅れ勝ちです。例えば、ツリービューは、完全な MSAA の実装が存在してるにのにおそらくほとんどの補助テクノロジーでアクセシビリティとして使えないでしょう。ダイアログボックスとステータスバーの自動スクリーン読み上げは、MSAA の実装が完ぺきで、オブジェクトに関して他の全てが完全に正常であるにもかかわらず、間違ったクラス名が使われているという理由のためだけに、しばしば//→ほとんど//動作しません。
Solution: There are three things you can do: 1) try to use the standard class names, 2) pressure the screen reader vendor to fix their MSAA implementation or use better heuristics, and 3) get around the problem with 3rd party scripts for those AT's that can use them.
解決方法: 出来ることが三つあります//→三つの対応が可能です。//：１）標準のクラス名を使うようにする。２）スクリーンリーダのベンダーにプレッシャーをかけて、 MSAA の実装を修正して//→修正したり//よりよい経験則を使うようにさせる。３）サードパーティーのスクリプトを使用している補助テクノロジー用のスクリプトの問題を解決する//→サードパーティーのスクリプトを使用することで、補助テクノロジーのスクリプトの問題を解決する//。
続きはまた明日。
さて、MSAA の世界へ今日も BGM を聞きながら優雅に旅立つことにします。
原題: Implementing an MSAA Server
訳題: MSAA サーバーを実装する
原文： 青色表示
訳文： 黒色表示
校正文： 赤色表示
校正対象範囲： 黒色太字表示
Not all MSAA objects implemented by 3rd party vendors
Problem: As described above, screen readers tend to look first for window classes they know, such as Button, ListBox, ComboBox, msctls_statusbar32, msctls_trackbar32, #32770 (dialog class), SysTreeView32, Static, Edit and RichEdit. AT vendors have typically spent the most time making windows with these classes work, so they are fully debugged. In addition, the user comes to expect appropriate behavior for status bars, dialog boxes and tree views based on the fact that most apps use the standard control. Unfortunately, the MSAA implementation often lags. For example, tree views will probably not be accessible with most assistive technologies even if you have a perfect MSAA implementation. Automatic screen reading of dialog boxes and status bars will often not work just because you're using the wrong class name, even if your MSAA implementation is perfect, and everything else about the objects is completely normal.
全てがサードパーティーベンダーによって実装されるわけでない MSAA オブジェクト
問題: 上記で説明しましたように//→上述しましたように//、スクリーンリーダは、ボタン、リストボックス、コンボボックス、msctls_statusbar32、 msctls_trackbar32、#32770 (ダイアログクラス)、SysTreeView32、Static、Edit および RichEdit など、最初に自分が知っているウィンドウクラスを探す傾向があります//→ボタン、リストボックス、コンボボックス、msctls_statusbar32、 msctls_trackbar32、#32770 (ダイアログクラス)、SysTreeView32、Static、Edit 、RichEdit など、スクリーンリーダは、最初に自分が知っているウィンドウクラスを探す傾向があります//。//挿入：→補助テクノロジー//ベンダーではこれらのクラスの働きによってウィンドウを機能させることに//→作ることに//時間のほとんどを費やし//→費やするので//、ウィンドウは完全にバクとりされます。さらに、ユーザーは、多くのアプリケーションが標準的な制御を使うという事実に基づいて、ステータスバー、ダイアローグボックス、ツリービューが正しく動作することを期待するようになります。不幸にして//→残念ながら//、 MSAA の実装は遅れ勝ちです。例えば、ツリービューは、完全な MSAA の実装が存在してるにのにおそらくほとんどの補助テクノロジーでアクセシビリティとして使えないでしょう。ダイアログボックスとステータスバーの自動スクリーン読み上げは、MSAA の実装が完ぺきで、オブジェクトに関して他の全てが完全に正常であるにもかかわらず、間違ったクラス名が使われているという理由のためだけに、しばしば//→ほとんど//動作しません。
Solution: There are three things you can do: 1) try to use the standard class names, 2) pressure the screen reader vendor to fix their MSAA implementation or use better heuristics, and 3) get around the problem with 3rd party scripts for those AT's that can use them.
解決方法: 出来ることが三つあります//→三つの対応が可能です。//：１）標準のクラス名を使うようにする。２）スクリーンリーダのベンダーにプレッシャーをかけて、 MSAA の実装を修正して//→修正したり//よりよい経験則を使うようにさせる。３）サードパーティーのスクリプトを使用している補助テクノロジー用のスクリプトの問題を解決する//→サードパーティーのスクリプトを使用することで、補助テクノロジーのスクリプトの問題を解決する//。
続きはまた明日。