XPCOM Component Reuseを草稿にする-05

本日も難しい内容ですが、継続します。(^_^;)

/*翻訳作業につきましては、本日の作業対象部分のみを以下に表示しておりますが、全体の原文と翻訳文（翻訳作業が完了している部分まで）は、直下のリンクをご参照ください。*/

原題: XPCOM Component Reuse
訳題: XPCOM コンポーネントの再使用

原文：　 青色表示
訳文：　 黒色表示
*n(=int)校正コメント:赤色表示

Putting it all together

If you are building an XPCOM component or embedding Gecko, linking to the glue static library and string library will reduce the dependancies which you may have on XPCOM. In this case be aware you will also have to link to NSPR.

When building, make sure that the build define XPCOM_GLUE is defined. This will ensures that the proper calling convention is used on the functions in the glue library. If you forget this step, you may have troubles linking.

すべてを統合する

XPCOM 部品を構築したり、Gecko を埋め込んでいるなら、glue スタティック・ライブラリやストリング・ライブラリへリンクすることは、XPCOM への依存関係を弱めることになります。この場合また、 NSPR(Netscape ポータブル・ランタイム)へのリンクが必要になることに注意してください。

作業時に、XPCOM_GLUE というビルド定義が、かならず定義されるようにしてください。こうすると、glue ライブラリの関数に、正しい呼出し規則がかならず使われることになります。この措置を忘れると、リンクに問題が発生します。

//→以下画像は省略：冒頭のリンクでご参照ください//

If you use this method, you should double-check all of the dll imports from your component or application. On Windows, for example, run: "dumpbin /imports ". This will produce a listing of all the code required to run your component or application. If you see that you require symbols from XPCOM, make sure that they are listed in nsXPCOM.h. If the function is not listed there, chances are you should not be using it.

この方法を使うなら、部品やアプリケーションからのすべてのインポートを二重チェックするべきです。例えば、Windows では、"dumpbin /imports <file>" を動作させてください。そうすれば、部品やアプリケーションを動作させるのに必要なコードすべての一覧が提示されます。XPCOM の記号が必要であることが分かるなら、nsXPCOM.h に記号がかならずリストアップされるようにしてください。もしその機能がそこにリストアップされなければ、多分それが使えないということです//草稿訳注：the function = symbols と解釈でいいか？//。

Below is a snapshot of the xpcom includes from an embedding example. Clearly, this embedding example must ship its own copy of XPCOM to maintain compatibility.

埋め込み例から xpcom の include のスナップショットを以下に示します。この埋め込み例は、互換性を維持するのに xpcom の自分自身のコピーを送る必要があります。

途中ですが、以下次回にします。(-_-;(-_-;(-_-;(-_-;

Aaron Leventhal からの返信

本日は、アーロンさんからの返信の内容をご紹介します。

背景：昨年11月に Mozilla Japan のために翻訳を開始してから、アーロンさん→Aaron Leventhal という人（アクセシビリティ　USA)のアクセシビリティ関係の文書を合計８つ和訳しております。すべてがアクセシビリティ関連の文書です。これらは、 Mozilla Org. で公開されているアーロンさんの主要文書です。このたび、８文書の翻訳を終えて（一部草稿公開中）、その旨をアーロンさんにご報告したところ、下記のような内容で返信をいただきました。
ついでに、私の報告文も一緒に紹介いたします。-下手な英文で恐縮ですが(^_^;)-


//→アーロンさんからの返信文//
Date: Tue, 10 May 2005 16:33:16 -0400
From: "Aaron Leventhal" <aaronleventhal@moonset.net>
To: "Yamamoto Nobuyuki" <nobu586@yahoo.co.jp>
Subject: Re: Translation into Japanese almost finised; accessibilty

Thank you for doing this! I don't read Japanese, but am very interested in Japanese culture.

Hopefully one of the Japanese screen reader vendors will find this information useful. Perhaps you could find their information on the web and send the information to them. They may be interested in supporting Firefox.

一部割愛・・・・・・・・

- Aaron

//→アーロンさんへの送信文//
Yamamoto Nobuyuki wrote:

> Dear Aaron, I am Nobuyuki Yamamoto, translator working voluntarily for Mozilla Japan org. Do you remember me? I have sent a mail before to ask you about the meaning of a passage in the document, "Accessibility API cross-reference " I suppose. Today, I am writing to tell good news for you. I have finished translating into Japanese most of your documents about accessibility. I was really impressed and interested by an article of the interview where you mentioned why you began to be involved in accessibility, telling the experience in your school days in Wisconsin. The article was also translated by Mr. Yamaguchi of Mozilla Japan and reading it made me decide to translate all of your documents, which I found on the bulletin board required for translation into Japanese. I started to translate for Mozilla Japan in November last year. Since then, I have finished my work on the following documents; all of them were written by you.
-Accessibility: Future UI Planning
-Accessibility API cross-reference
-Accessible Toolkit Checklist
-Mozilla Accessibility Architecture
-Embedding API for Accessibility Software
-Accessibility - Where Are We Today?
-Gecko Info for Windows Accessibility Vendors
-Implementing an MSAA Server
By the way, it was not easy for me to translate them because I am not a programmer nor system engineer. I felt myself short of knowledge about coding. I managed to, however, get over the difficulty by exposing my drafts open to people of Mozilla Japan in order to obtain suggestion or correction on them. Therefore, the above Japanese documents are the result of the collaborative work by related people in Mozilla Japan. I am very proud of that.(．_．、 I hope you can read them in Japanese. Don't worry, however, I know all of American do not read Japanese. If you have any suggestion, please feel free to contact me, and that you have any documents besides the above yet to be translated, I will be happy to translate them to Japanese as well. Best Regards Nobuyuki Yamamoto.　　
>

注記：アーロンさんへの送信文に記した内容は、上記リンク→ Aaron Leventhal という人（アクセシビリティ　USA)に記した内容をご本人に対して説明しております。文中に登場する Mozilla Japan の山口さんとは、アーロンさんの心を打つ内容のインタービュー記事を和訳された方です。この記事も上記のリンクでご紹介しております。

さて、アーロンさんの返信にある日本のスクリーン・ベーンダーにアーロンさんの記事を紹介して欲しいとうご希望は、出来る範囲で尽力してみたいと思います。そのために、自分のホームページに→IT 翻訳 Nobuyuki の仕事部屋アーロンさんコーナーを設置して、その文書を一覧で参照できるようにまとめてみるつもりです。

最後にアクセシビリティについて思うことは、それが今の社会においては次第に重要な考えになりつつあるのではないかと言う事です。もともと、身体にハンディキャップを抱えた方に向けられた便宜であるアクセシビリティが、健常者も含めて必要なものになりつつあるのではないかと思います。その背景には、世の中の老齢化ということが関係しています。類似の概念にユニーバーサル・ディザインがあり、子供や老人も含めた万人に優しい配慮は、今の社会の要請と考えることができます。日本では、団塊の世代の老齢化ということで 2007 年問題などが話題となっていますが、くしくも米国でもべービーブーマー世代の老齢化がアクセシビリティの必要性に関連していることを、アーロンさんの文書が→アクセシビリティソフトウェア ： 現在どこまで来ているか？指摘しています。さらに同文書のなかで、アーロンさんの主張が色濃く出ていると思うのは、IT の恩恵はアクセシビリティが必要な人も含め万人に等しく提供されるべきという考えです。確かに IT のお陰で、個人生活、ビジネスを問わず世の中が便利になっています。卑近な例で、翻訳作業について考えても、訳語を調べる作業でいえば、昔に比べると短時間で色々な情報が入手できるようになりました。こういう恩恵は、すべての人間が等しく享受できるべきだとアーロンさんは言います。そのための、コストは社会全体が負担すべきものなのでしょう。アクセシビリティの便宜の提供が一部の零細なベンダーに依存している現状に対してアーロンさんは、現場経験の豊富な立場から警鐘を鳴らしています。

さて、 Mozilla Japan の文書の翻訳を始めてたまたま翻訳したアーロンさんの文書ですが、色々勉強することが出来ました。アーロンさんの活動に関しては、自分としても出来る範囲でやれることは支援を継続して行きたいと考えています。(^-^)

XPCOM Component Reuseを草稿にする-04

本日はとても嬉しいニュースがあります。以前にこのブログで紹介いたしました、Aaron Leventhal さん→Aaron Leventhal という人（アクセシビリティ　USA)へメールを送り、同氏の文書の翻訳の完了を報告しましたところ、返信をいただき翻訳に関する感謝のお言葉をいただきました。その内容は別途機会を設けてご紹介いたしますが、翻訳していてつくづく良かったと思いました。同時に同氏の文書をできるだけ多くの人たち、特に日本のアクセシビリティのベンダーの関係者に読んでいただきたいと思います。それは、アーロンさんご本人も希望されていることです。

＼(^^＼) (／^^)／
さて本日も張り切って頑張りましょう。

/*翻訳作業につきましては、本日の作業対象部分のみを以下に表示しておりますが、全体の原文と翻訳文（翻訳作業が完了している部分まで）は、直下のリンクをご参照ください。*/

原題: XPCOM Component Reuse
訳題: XPCOM コンポーネントの再使用

原文：　 青色表示
訳文：　 黒色表示
*n(=int)校正コメント:赤色表示

The "Glue" Library

The XPCOM "glue" library (lxr) is built as a normal part of XPCOM. But by linking a standalone version of this into your application or component, you, in essence, get a snapshot copy of this code. While it is a bit expensive in terms of footprint, it does allow you to work in any Mozilla 1.0 environment with confidence. If footprint is of concern, you can trim out the pieces that you do not need. The string library can and should be used in the same manner with the same caveats. The current string code is built without any dependencies on XPCOM. This means that it can be directly included into your component or embedding application.

"Glue" ライブラリ

XPCOM "glue" ライブラリ (lxr) は XPCOM の通常部分として構築されています。しかし、XPCOM のスダンドアロンなバージョンをアプリケーションや部品にリンクとして取り込むことで、実際にこのコードのスナップショットが得られます。専有領域について少々高価すぎる事はあるものの、すべての Mozilla 1.0 の環境で確実に機能させることができます。もし専有領域が気になるなら、不要な部分を切り捨てることが可能です。ストリングライブラリは、同じ点に注意を払うことで同じように使用できますし、使用すべきです。現在の文字列コードは XPCOM との依存関係なしに作られます。ということは、部品や埋め込みアプリケーションに直接取り込めます。//→以下画像は省略：冒頭のリンクでご参照ください//

The glue library consists of commonly requested helper classes. Although this article isn't meant as a complete description of how to use the classes in the glue library, here is an overview:

* Smart pointers
o See nsCOMPtr User's Manual.
o Support in the glue library also includes:.
+ do_QueryInterface
+ do_CreateInstance
+ do_GetService
+ do_GetInterface


glue ライブラリは共通に必要なヘルパークラスから構成されます。当文書は glue ライブラリのクラスの使用法について完全な解説を目指しているわけではありませんが、以下がその概要になっています:

* スマートポインタ
o nsCOMPtr ユーザマニュアルを参照ください。
o glue ライブラリのサポートには下記も含まれます:.
+ do_QueryInterface
+ do_CreateInstance
+ do_GetService
+ do_GetInterface


# Weak References

* See nsIWeakReference documentation.
* Support in the glue library also includes:.
o do_QueryReferent

# nsISupports Support

* Macros for various implementions of nsISupports.
* Macros for handling reference counting, and object instantation.

# nsMemory

* A static class wrapper around the global nsIMemory implemention.

# nsDebug

* A static class which provides basic assertion and pre/post condition checking.

# Generic Module Support

* See generic factories documentation.


# ウィーク・リファレンス//草稿訳注：”弱参照”という訳語を google で見かけたが、それを作用するべきか？ウーン・・・//

* nsIWeakReference 文書を参照ください。
* glue ライブラリのサポートには以下も含まれます:.
o do_QueryReferent

# nsISupports のサポート

* nsISupports の様々な実装用のマクロ
* 参照カウント処理、オブジェクトインスタンス化用のマクロ

# nsMemory

* グローバルな nsIMemory の実装を包むスタティックなクラスのラッパー

# nsDebug

* 基本的アサーション、前後条件のチェックを提供するスタティックなクラス

# 汎用モジュールのサポート

* generic factories の文書を参照してください


本日はここまでです。

XPCOM Component Reuseを草稿にする-03

本日も結構 heavy な節です。(・_・、　しかしそれにめげずに break through! (^-^; "アセアセ"

/*翻訳作業につきましては、本日の作業対象部分のみを以下に表示しておりますが、全体の原文と翻訳文（翻訳作業が完了している部分まで）は、直下のリンクをご参照ください。*/

原題: XPCOM Component Reuse
訳題: XPCOM コンポーネントの再使用

原文：　 青色表示
訳文：　 黒色表示
*n(=int)校正コメント:赤色表示


But even if you commit to using by strong preference interfaces that have been frozen, it is simply a fact that in some cases, you will need to do something which is not supported by a frozen interface. The code underlying nsCOMPtr, for example, is not frozen, but using this "smart pointer" is highly recommended, as it automates some of the more burdensome and error-prone aspects of COM reference counting. There are a number of XPCOM utility classes, such as nsDebug, that are also not represented through a frozen interface, but which are, nonetheless, close to being essential in many aspects of developing with Mozilla. The string classes also belong to this set of extremely useful but not frozen components. And you may find other examples for your particular situation. In these cases you have basically three options: you can simply manually copy the code into your own application; you can try to convince the Mozilla module owner that the functionality is of such widespread use that it should be exposed through a frozen interface (be aware, though, the process for arriving at the frozen state is often long and complex); or, in the case of the XPCOM utilities and the string classes, you can use a workaround employing special libraries that now exist in the code.

しかし、強い意志で凍結されたインターフェイスだけを使うことにしても、凍結インターフェイスによってサポートされない事をしなくてはならない場合もあるでしょう。例えば、nsCOMPtr を含むコードは凍結されていませんが、COM の参照カウントのもっと大変なエラーを誘発しがちな部分を自動化するので、このスマートポインタの使用は強く推奨されます。また、nsDebug のように凍結インターフェイスによって代表されないが、それでも Mozilla による開発の多くの局面でかなり重要であるような XPCOM のユーティリティクラスが数多くあります。ストリングクラスも大変有益ですが、凍結部品ではない組に属しています。さらに個々の状況に応じてそのほかにも役立つ例があるかもしれません。この場合、基本的に 3 つの選択肢があります。自分自身のアプリケーションにただマニュアル作業でコードをコピーすることができます。機能が広範囲に渡って使用されている場合は、その機能が凍結インターフェイスを通して公開されるべきこと（この場合凍結状態に至る手順は時として長く複雑であることに注意）を、Mozilla のモジュールオーナに説得を試みることができます。最後に、XCOM ユーティリティとストリングクラスの場合、現在コード中に存在する特別ライブラリを使用するという回避策を講じることができます。

(-_-; "フウーツ、疲れた。本日はここまでとするか"

XPCOM Component Reuseを草稿にする-02

本日は結構難しい事を言っておりますので、じっくりと読んでみる必要があります。修飾語が多い文章で、直訳すると日本語として、あまり読みやすいものとならないのが、難点です。工夫を凝らして翻訳しましたが、満足のいく文章になっていません。m(__)m

/*翻訳作業につきましては、本日の作業対象部分のみを以下に表示しておりますが、全体の原文と翻訳文（翻訳作業が完了している部分まで）は、直下のリンクをご参照ください。*/

原題: XPCOM Component Reuse
訳題: XPCOM コンポーネントの再使用

原文：　 青色表示
訳文：　 黒色表示
*n(=int)校正コメント:赤色表示

As useful as these two projects undoubtedly will be, they do increase substantially the likelihood that components from different versions of Mozilla will at some point be required to interact with each other, raising significant issues of compatibility. The following notes are designed to help the developer who may be interested in taking advantage of this new, componetized Mozilla development environment to write code that is less likely to run into problems caused by version and/or compiler incompatibilties. If you are building an application that ships its own internal copy of all necessary Mozilla components, which have been built as a unit, these suggestions may be of less significance.

これら 2 つのプロジェクトが間違いなく役に立つようになるのと同程度に、Mozilla の異なるバージョンに使われている部品が、実際、ある時点でお互いに作用しあう必要が発生する可能性が増大します。そして、互換性という重要な問題が提起されます。以下に続く記述は、コンポーネント化されたこの新しい Mozilla の開発環境を活用する気のある開発者が、バージョンやコンパイラーの非互換性のために問題に遭遇する可能性を幾分でも減らすことになります。ただし、アプリケーションを作成して、それが自身の、単体として構築されている必要な Mozilla　部品すべての内部 コピーを提供するならば、これらの提言はそれほど重要でなくなるかもしれません。</p>

The first and most important step you can take is to use, whenever possible, XPCOM interfaces instead of their supporting implemented classes. Because the codebase is open, and because there are a large number of seemingly useful classes already written and easily available (all you need to instantiate an object at runtime is an ID), the temptation to utilize those classes is great. But no implemented class in Mozilla is guarenteed to stay the same from one version to the next. A number of interfaces, on the other hand, are guarenteed not to change in the future. These are interfaces which have been marked @status FROZEN. By designing your code to use by strong preference only those interfaces which have been marked frozen, you increase considerably the chances that a component that you write today will be able to interact seamlessly with a component written six months from now. The public interfaces that have been frozen are listed in the Gecko Embedding API Reference. So the best way to ensure continuing syntactic compatibility of components from one version to the next is to use only frozen interfaces. And because interfaces are, in essence, pure abstract classes, using them also promotes longterm binary compatibility.

必要なときは必ず XPCOM のインターフェイスを使い、インターフェイスがサポートする実装クラスを使わないことを、最初のもっとも重要な措置とすることができます。というのは、コードベースはオープンであり、既成の使いやすい、一見便利そうなクラスがたくさんありますので、これらのクラスを使いたい気持ちはやまやまです。しかし Mozilla に実装されているクラスはバージョンが変わっても同じである保証はありません。一方で、将来も変わらないことが保証されているインターフェイスはたくさんあります。これらのインターフェイスには @status FROZEN と印がついています。できるなら是非とも”凍結”された印があるこれらのインターフェイスだけを使ってコーディングすることによって、今日作成した部品が、6ヶ月後に書かれた部品と変更なしに接続できる機会ははるかに多くなるでしょう。凍結された public なインターフェイスの一覧は Gecko Embedding API Reference にあります。従ってバージョンが変わっても継続的な部品の総合的互換性を確保する最良の方法は、凍結されたインターフェイスだけしか使わないことです。しかも、インターフェイスは本質的に、純粋な抽象クラスですから、それらを使用することで、長期的にバイナリーな互換性を促進することにもなります。

以上

XPCOM Component Reuseを草稿にする-01

さて、本日から新しい文書の翻訳にとりかかりたいと思います。内容は、前回翻訳しました文書Gecko Runtime Environment(GRE) の中にありました、リンク先の文書で、XPCOM Component Reuseです。まだ和訳されていない文書らしいので、これを訳することにします。

それでは、早速初回の作業にとりかかりましょう。


/*翻訳作業につきましては、本日の作業対象部分のみを以下に表示しておりますが、全体の原文と翻訳文（翻訳作業が完了している部分まで）は、直下のリンクをご参照ください。*/

原題: XPCOM Component Reuse
訳題: XPCOM コンポーネントの再使用

原文：　 青色表示
訳文：　 黒色表示
*n(=int)校正コメント:赤色表示

XPCOM Component Reuse
By Doug Turner, and Ellen Evans

Overview

Historically if you were a developer who wanted to use some or all of the Mozilla codebase in your own application, you were required to download, build the entire Mozilla tree, and distribute your own copy of Mozilla. While this may have been tedious, it did guarentee that all the components that you acquired in this way were binarily and syntactically compatible.

XPCOM コンポーネントの再使用
著者： Doug Turner、Ellen Evans

概要

従来、開発者が自分のアプリケーションに Mozilla のコードベースの一部、あるいは全部を使いたい場合、 Mozilla ツリー全部をダウンロードし、ビルドして自分の Mozilla コードを配布する必要がありました。このことは退屈な作業であったかもしれませんが、こうして得られた部品はすべてバイナリー形式で構文的に、互換性が確保されていました。

Now, however, there are two projects underway at mozilla.org designed to streamline the process through which Mozilla code can be acquired, built, and distributed to end users. On the one hand, mechanisms are being put together to make it possible to download and build limited subsets of the codebase instead of the entire tree. For more information on this effort, see bootstrap.pl: Embed/REQUIRES-based build mechanism.

しかし、現在 mozilla.org では 2 つのプロジェクトが進行中であり、 Mozilla コードを取得し、ビルドし、エンドユーザーへ配布する工程を整流化することを目指しています。一方で、ツリーすべてではなく、コードベースのサブセットを限定してダウンロードしビルドすることが可能なように、メカニズムが統合されつつあります。この計画の詳細は bootstrap.pl: Embed/REQUIRES-based build mechanism をご参照ください。

On the other hand, mechanisms are also being crafted to allow a single set of core components, the Gecko Runtime Environment (formally MRE), stored in a central place on an end-user's machine, to be used as the support for any number of Gecko-based applications, shrinking application file size and simplifying user installation.

その一方で、エンドユーザのマシンに格納された Gecko ランタイム環境(公式名称:MRE) という一セットの重要部品が、アプリケーションのファイルのサイズをシュリンクし、ユーザの設定を簡略化することによって、すべの Gecko ベースのアプリケーションをサポートするのに使われることも可能になります。

本日は節の途中ですが、第一回目ということで、ここまでにしておきます。

Gecko Runtime Environment(GRE) を和訳する -7

本日は、最後まで行くつもりです。一見長いように見えますが、コードのスナップショットが挿入されているので、そうでもないでしょう。(^-^;　

/*翻訳作業につきましては、本日の作業対象部分のみを以下に表示しておりますが、全体の原文と翻訳文（翻訳作業が完了している部分まで）は、直下のリンクをご参照ください。*/

原題: Gecko Runtime Environment(GRE)
訳題: Gecko ランタイム環境 (GRE)

原文：　 青色表示
訳文：　 黒色表示
*n(=int)校正コメント:赤色表示


#
GRE Installation on Windows platforms

The GRE for Windows platforms will be bundled with it's own installer program. This installation program will use the Windows registry to record key information such as the GRE version number and the GRE's installation path.

When installed, the GRE installer creates the following Windows registry key:

HKEY_LOCAL_MACHINESoftwareMozillaGRE

In addition, identical registry subkeys are created using both the major/minor versions for each version of GRE installed:

HKEY_LOCAL_MACHINESoftwareMozillaGRE1.0
# HKEY_LOCAL_MACHINESoftwareMozillaGRE1.1

Each of these keys will contain the following string values which give additional information about a specific version of the GRE:

#
Windows プラットフォームへの GRE インストール

Windows プラットフォーム用の GRE は、GRE 自体のインストールプログラムとバンドルされます。このインストールプログラムは、Windows レジストリを使って、GRE バージョン情報、GRE の設定パスなどの重要情報を記録します。

インストールされる時、GRE インストラーは、下記の Windows レジストリ・キーを作成します:

HKEY_LOCAL_MACHINESoftwareMozillaGRE

さらに、インストールされた GRE の各バージョンの major/minor 2つのバージョンを使い、レジストリの同じサブキーが作成されます:

HKEY_LOCAL_MACHINESoftwareMozillaGRE1.0
# HKEY_LOCAL_MACHINESoftwareMozillaGRE1.1

これらのキーの各々は、GRE の固有のバージョンについての追加情報を提供する下記のような文字列の値を保持します。


Name 　　　　　　　　Default Value
Version 　　　　1.0
GreHome 　　　　C:Program FilesCommon Filesmozilla.orgGRE1.0
GreComponentsDir C:Program FilesCommon Filesmozilla.orgGRE1.0Components


名称 　　　　　　　デフォルト値
Version 　　　　1.0
GreHome 　　　　C:Program FilesCommon Filesmozilla.orgGRE1.0
GreComponentsDir C:Program FilesCommon Filesmozilla.orgGRE1.0Components

Embedding applications can use this information in the Windows registry to determine the path of the GRE version they are compatible with and use it to set their own PATH environment var. accordingly. Doing so will ensure that the embedding application picks up the correct GRE components the application is compatible with - when there are several versions of GRE's installed on a machine.

The same registry information can also be used by embedding application installer programs to determine whether or not to install a GRE as part of the application installation. This is described in more detail in the Installing a GRE based Application section above.

Here is a code snippet to find all versions of the GRE installed

埋め込みアプリケーションは、自分が、互換性のある GRE のバージョンのパスを決めるのに、Windows レジストリ内のこれらの情報を使用することで、自分の環境パス変数を設定できます。それによって、マシン上に複数の GRE のバージョンが存在する時、アプリケーションと互換性のある正しい GRE コンポーネントを間違えることなく選定します。

同じレジストリ情報は、埋め込みアプリケーションのインストラープログラムを埋め込むことで、アプリケーションの設定の一部として GRE をインストールするかどうか決定するのにも使われます。この事は、上記の GRE をベースとしたアプリケーションをインストールするの節で詳細に説明されています。

下記のコードでインストールされている GRE のすべてのバージョンを調べることができます。

//→コードのスナップショットは省略。冒頭のリンクを参照のこと//

And here is a snippet that returns the location of the GRE directory given a version string:

バージョンの文字列を備えた GRE ディレクトリのロケーションを返すのは以下のコードです:

//→コードのスナップショットは省略。冒頭のリンクを参照のこと//

Note that this code probably should just be used in an installer as the generic GRE startup code we mentioned above already does this for you.

上述した汎用的 GRE 立ち上げコードがすでにそうなっているように、おそらくこのコードは、インストラーで使われるべきことに注意してください。

やれやれ、とりあえず訳し終えました＼(~o~)／。この原稿は、これから Mozilla Japan において、草稿として公開することになります。また、当翻訳について、何かご意見があれば、是非コメントを書き込んでください。よろしくお願いしますm(__)m。

Gecko Runtime Environment(GRE) を和訳する -6

昨日の続きです。

/*翻訳作業につきましては、本日の作業対象部分のみを以下に表示しておりますが、全体の原文と翻訳文（翻訳作業が完了している部分まで）は、直下のリンクをご参照ください。*/

原題: Gecko Runtime Environment(GRE)
訳題: Gecko ランタイム環境 (GRE)

Deploying a GRE based application
Once a GRE based application has been developed and tested you can deploy it using existing Windows based installer technology or Mozilla's XPI technology. In addition to copying the application's executable you must also copy the following "resources" into appropriate directories under the application install directory:

GRE をベースとしたアプリケーションを配置する
GRE ベースのアプリケーションの開発とテストが完了すると、Windows ベースのインストラーや Mozilla の XPI などの現行技術を使って配置できます。アプリケーション・インストール・ディレクトリ下の正しいディレクトリに、アプリケーションの executable だけでなく、以下の「リソース」もコピーしなければいけません:

# chrome - Default chrome required for any embedding application
# components - Place any app specific XPCOM components under this directory. If there are no custom XPCOM components that you have written, create an empty directory named "components"
# default prefs - Create the default pref directory hierarchy with the appropriate files in them.
# plugins - Place any plugins your application requires under the "plugins" directory. Create an empty "plugins" directory if there are no plugins which the application uses
# Other resources - Create a "res" directory which will have the appropriate .css, .properties, .gif files, entity tables, dtds etc.

# chrome - 埋め込みアプリケーションに必要なデフォルトの chrome
# コンポーネント - このディレクトリ下にアプリケーション本体の XPCOM コンポーネントを置く。カスタムな XPCOM コンポーネント が作られていないなら、"components" と言う名前の空ディレクトリを設定する。
# デフォルトの環境設定 - 適当なファイルによってディレクトリに、デフォルトの環境設定ディレクトリ階層を作成する。
# プラグイン - アプリケーションが必要とするすべてのプラグインを "plugins" ディレクトリ下に設置する。アプリケーションがプラグインを使用しなければ、空の "plugins" ディレクトリを作成する。
# その他のリソース - .css、.properties、.gif ファイル、エンティティ表、dtds 等を保持する "res" ディレクトリを作成する。

How do I make an XPCOM component available only to my GRE application?

The components that are part of a GRE installation are accesible to all GRE based applications, for ex, the HTML parser, image decoders etc. are common components that every GRE based application on the same machine can share. However, there are instances when you want to create and use an XPCOM component which is relevant to (and accessible only from) your GRE based application. You can achieve this by placing your application specific XPCOM component in the *application's* "components" directory.

自分の GRE に対してのみ有効な XPCOM 部品の作り方

GRE の設定の一部を構成する部品群は、GREベースのアプリケーションすべてにアクセスできます。例えば、HTML パーサー、画像デコーダーなどは、同じマシン上の GRE ベースのアプリケーションすべてが共用する共通部品です。しかし、自分の GRE ベースのアプリケーションに関連する（かつアプリケーションからのみアクセス可能な） XPCOM 部品を作成たり使用したい時、インスタンスが存在します。そこで*1、*アプリケーションの* "components" ディレクトリに自分のアプリケーション本体の XPCOM 部品を設置することで、この事は達成できます。


*1→「そこで」：この語は原文にないが、文意を分かり易くするために補った

本日はここまでとします。
もうじきこの翻訳も完成です。(^◇^)

Gecko Runtime Environment(GRE) を和訳する -5

本日は寒い日です。
朝、暖かいコーヒー（^_^）に、バケットをこんがりと焼いて、バターをたっぷり塗って食べました。私にとっては、最高の朝食ですね。毎朝ほとんど、このパターンです。さて、部屋に戻っておもむろに翻訳作業を開始します；

/*翻訳作業につきましては、本日の作業対象部分のみを以下に表示しておりますが、全体の原文と翻訳文（翻訳作業が完了している部分まで）は、直下のリンクをご参照ください。*/

原題: Gecko Runtime Environment(GRE)
訳題: Gecko ランタイム環境 (GRE)

原文：　 青色表示
訳文：　 黒色表示
*n(=int)校正コメント:赤色表示


Developing an application to use a GRE

In order to use a GRE, one must take care to avoid linking directly to any library in the GRE. The reason for this is that the location of the GRE is determined at runtime. Of course, your applicaiton may know ahead of time where the GRE will be placed. This would be the case if you installed a copy of the GRE in a well known place for your application. However, when using the publically available GRE, the location is not known.

In order to break yourself from dependencies in Gecko, you can start by linking against the XPCOM Glue library instead of the XPCOM library.

GRE を使用するアプリケーションを開発する

GRE を使用するために注意しなければいけないのは、GRE の中で直接ライブラリーにリンクしない事です。その訳は、GRE のロケーションが 実行時に決定されるためです。もちろん、アプリケーションが前もって GRE の場所を知ることもあります。アプリケーションにとっておなじみの場所に、GRE のコピーをインストールすれば、この事は可能でしょう。しかし、公開されている GRE を使う時は、ロケーションは分かりません。

Gecko で依存関係を断ち切るのに、XPCOM ライブラリー ではなく、まず最初に XPCOM Glue ライブラリー に対してリンクします。

Once dependencies are removed from your application, you can start up Gecko by using the generic GRE startup code found in the Glue library. This startup code should be customized to your emebbeding applications requirements. The basic functionality that this code implements is to find where the GRE directory is, then startup XPCOM. There are a few places that this code will look at for the location of GRE. First of all, if there isn't a GRE installed, the code expected there to exist all of the gecko libraries next to the application. If there is a GRE installed, then that installer would have placed a configuration file somewhere on the system (or in the Windows Registry on windows). This data in that configuration file points the Mozilla client to where it can find the GRE. You may wish to change this ordering or add to it.

アプリケーションで、依存関係が断ち切られると、Glue ライブラリーにある汎用的（草稿訳注：generic= 汎用的で正しいか　）GRE 立ち上げコードを使うことで、Gecko を立ち上げることができます。この立ち上げコードは埋め込みアプリケーションの要件に合わせてカスタマイズされるべきです。このコードが実装する基本的な働きは、GRE のディレクトリの場所を見つけ、XPCOM を立ち上げることです。GRE のロケーションを探すのに、コードが確認する場所がいくつかあります。まず最初に、 GRE コードがインストールされていないと、アプリケーションのとなりにすべての gecko ライブラリーが存在するものと、コードは予測します。GRE がインストールされていると、インストラーがシステムのどこか（あるいは、ウィンドウ上の Windows Registry の中）に構成ファイルを設定しているものと予測します。構成ファイルの中のデータは、 Mozilla クライアントに GRE が在る場所を指示します。順番の追加や変更は可能です。

See you tomorrow!

Gecko Runtime Environment(GRE) を和訳する -4

昨日の続きです。m(__)m→Gecko 小劇場　Gecko1、　→2、　→3、 →4、 →完

/*翻訳作業につきましては、本日の作業対象部分のみを以下に表示しておりますが、全体の原文と翻訳文（翻訳作業が完了している部分まで）は、直下のリンクをご参照ください。*/

原題: Gecko Runtime Environment(GRE)
訳題: Gecko ランタイム環境 (GRE)



原文：　 青色表示
訳文：　 黒色表示
*n(=int)校正コメント:赤色表示

Installing a GRE based Application

The embedding application's installer must follow the process described in the previous section to determine whether or not to install a GRE. If a GRE must be installed the applications installer will invoke the GRE installer to install the appropriate GRE version the applicationis compatible with.

When it's time to install the application specific files the application's installer must install those files in a location outside that of the the GRE.

After the application specific files are installed the "AppCount" value (under the GRE version registry subkey) must be incremented by one indicating that it is using that GRE version.

Please see the "Deploying a GRE based Application" section below for more info. on what files must be copied (and directories created) in addition to the GRE based application executable.

GRE をベースとしたアプリケーションをインストールする

埋め込みアプリケーションのインストラーは、GRE をインストールするかどうかを決めるのに前節で説明した手順に従う必要があります。インストールする必要があるなら、アプリケーションのインストラーは GRE のインストラーを起動して、アプリケーションと互換性のある正しい GRE のバージョンをインストールします。

アプリケーション本体のファイルをインストールする時が来ると、アプリケーションのインストラーは GRE のロケーションの外部にそれらをインストールする必要があります。

アプリケーション本体のファイルがインストールされた後で、GRE バージョンのレジストリのサブキーである "AppCount" 値を一つ増やして、インストールされたバージョンを使っていることを明らかにする必要があります。

GRE ベースのアプリケーションの executable 以外にコピーされるべきファイル(作成されたディレクトリも含めて）の詳細については、"GRE をベースとしたアプリケーションを配布する" の節をご参照ください。

Uninstalling a GRE based Application

When the user chooses to uninstall the GRE based embedding application it will remove the application specific code and reduce the "AppCount" value by one. It then calls on the GRE unistaller program for the deletion of a GRE.

GRE をベースとしたアプリケーションをアンインストールする

ユーザが GRE をベースとしたアプリケーションのアンインストールを選択すると、アプリケーション本体のコードが削除され、"AppCount" 値が一つ減じられます。その時、GRE の削除用の GRE アンインストールプログラムが呼び出されます。

Uninstalling a GRE

When the user chooses to explicitly uninstall a GRE or when an application specific uninstaller calls on the GRE unistaller, the GRE uninstaller must first check the GRE's "AppCount" value. The GRE files must be deleted if and only if the "AppCount" value is zero. If the value is not zero then the user should be warned and given the appropriate options to proceed from.

GRE をアンインストールする

ユーザが GRE のアンインストールを明示的に選択したり、アプリケーション本体のアンインストラーが GRE のアンインストラーを呼び出す時、GRE のアンインストラーは、最初に GRE の "AppCount" 値を確認する必要があります。"AppCount" 値が 0 なら、それだけで*1、GRE ファイルは削除される必要があります。値が 0 でなければ、警告表示され、ユーザは次に処理すべき適当なオプションを示されます。

*1→if and only if が訳しずらいようです; ここは条件が 2 つ重なっているのであとの方の only if を「それだけで」としました

To be continued till tomorrow・・・・・・・・・・・・