前のトピックを表示 :: 次のトピックを表示
著者
メッセージ
Tayu 登録日: 2003年8月 05日 記事: 117 所在地: 千葉県
件名: [草稿]エディターはどのように動作するか 投稿時間: 2008年1月15日(火) 18:04
こんにちは!たゆ です。
遅くなりました。二年かかっております…。
一通り草稿が出来上がりました。
以上です。
Tayu 登録日: 2003年8月 05日 記事: 117 所在地: 千葉県
件名: RE:[草稿]エディターはどのように動作するか 投稿時間: 2008年1月18日(金) 17:38
読み直して、以下のように校正を行いました。
XULエレメント → XUL要素
argsエレメント → args要素
インスタント化 → インスタンス化
KeyDown と KeyUp イベントは無視されます。 → KeyDown および KeyUp イベントは無視されます。
第二稿となります。
よろしくお願いします。
以上です。
濱崎 登録日: 2004年1月 27日 記事: 296 所在地: 静岡県
件名: Re: [草稿]エディターはどのように動作するか 投稿時間: 2008年1月19日(土) 00:13
3つめの節のタイトル
エディターの分解
は、エディタの片付け なんてどうでしょうか。エディタの取り壊し だと、建造物のような感じがしてしまうし。。
ぱっと見た目に、分解して細部を説明するように取れてしまったため修正案を出しています。
あ、細かいことですが、私はエディターよりエディタの方が好みです。以下また出てくるかもしれないので適宜読み替えてください。
Quote: メール作成ウィンドウにおける使い方と非常によく似ているので、殆どの組み込みアプリケーションに
ここは原文では、理由と事実 の関係にはなっていませんから、「ので」でつなぐのはやめたほうがいいです。
→・・・非常によく似ていて、殆どの組み込みアプリケーションに・・・
高レベルの図解 の節
用いられる がどこから出てきたのかよくわかりませんが、
some of the main parts of the editing system
は エディタシステムの中でいくつかの主要な部分 とでも訳しておけば良いでしょう。
この後ろは目を通せていません。今はここまでとさせてください。また時間ができたら見ます。
Tayu 登録日: 2003年8月 05日 記事: 117 所在地: 千葉県
件名: Re: [草稿]エディターはどのように動作するか 投稿時間: 2008年1月19日(土) 11:02
ご指摘を頂きましてありがとうございます。
濱崎 wrote: 3つめの節のタイトル
エディターの分解
は、エディタの片付け なんてどうでしょうか。エディタの取り壊し だと、建造物のような感じがしてしまうし。。
ぱっと見た目に、分解して細部を説明するように取れてしまったため修正案を出しています。
あ、細かいことですが、私はエディターよりエディタの方が好みです。以下また出てくるかもしれないので適宜読み替えてください。
teardownの訳については、解剖図といった位置づけではないので悩んでいました。助かります。
印刷機能を省いた文字入力アプリケーションはエディタといいますし、エディターと長く伸ばさないほうが
良いかもしれません。訂正しました。
濱崎 wrote:
Quote: メール作成ウィンドウにおける使い方と非常によく似ているので、殆どの組み込みアプリケーションに
ここは原文では、理由と事実 の関係にはなっていませんから、「ので」でつなぐのはやめたほうがいいです。
→・・・非常によく似ていて、殆どの組み込みアプリケーションに・・・
訂正しました。
濱崎 wrote:
高レベルの図解 の節
用いられる がどこから出てきたのかよくわかりませんが、
some of the main parts of the editing system
は エディタシステムの中でいくつかの主要な部分 とでも訳しておけば良いでしょう。
用いられる は意訳のしすぎかな、と自分でも思っていましたが、編集システムと訳すと、
Editor と editing を掛け合わせている文章冒頭の意味合いが出てこないので、
適切な訳を探していたところでした。エディタ・システムに訂正しました。
第三稿になります。
よろしくお願いします。
以上です。
濱崎 登録日: 2004年1月 27日 記事: 296 所在地: 静岡県
件名: Re: [草稿]エディタはどのように動作するか 投稿時間: 2008年1月23日(水) 02:16
また細切れになってしまいそうですが、あの後気付いたところを書きます。
・インスタント化 が残っています。
場所はエディタか何かの検索で探してください。1箇所ではないようです。
・エレメント も残っています。
・動きを修正するタイピング規則
原文は Quote: typing rules which modify behavior
ですね。
typing rules は、ここでは キーボードのタイピングに関するものではなくて、型の解釈について言及しているのではないでしょうか。1度、Google あたりで検索してみてください。
modify される前が誤っているわけではないので、修正する よりは 変更する の方がいいかもしれません。
動き を 動作 とするかどうかは、周囲の言葉とのバランスと好みですのでお任せします。
・この図解のいくつかの面
この 面 は、aspect から来ていますね。日本語であれば 点 とした方がすっきりと読み手の頭に入るでしょう。
・どの特定のフロントエンド、または環境に結び付けられているわけでもないのです
どの がどこまでかかるのか明確ではありません。
→ある特定のフロントエンドまたは環境に結び付けられているわけではないのです
・驚くには当たりませんが <editor> という名前の
少し砕けた言いかたにするなら、
→ありきたりですが <editor> という名前の
もありかなと思いました。
今夜はここまでにしておきます。
適宜取捨選択して修正していただき、1週間ほど待っても次の指摘がないようでしたら一度完成稿にしてしまってください。
Tayu 登録日: 2003年8月 05日 記事: 117 所在地: 千葉県
件名: Re: [草稿]エディタはどのように動作するか 投稿時間: 2008年1月23日(水) 18:20
ご指摘ありがとうございます。
濱崎 wrote:
・インスタント化 が残っています。
場所はエディタか何かの検索で探してください。1箇所ではないようです。
・エレメント も残っています。
" インスタント化 " については、訂正できていなかったようです。
二箇所とも変更されていなかったので、直しました。
<iframe> エレメント → <iframe> 要素
に訂正しました。
濱崎 wrote:
・動きを修正するタイピング規則
原文は Quote: typing rules which modify behavior
ですね。
typing rules は、ここでは キーボードのタイピングに関するものではなくて、型の解釈について言及しているのではないでしょうか。1度、Google あたりで検索してみてください。
modify される前が誤っているわけではないので、修正する よりは 変更する の方がいいかもしれません。
動き を 動作 とするかどうかは、周囲の言葉とのバランスと好みですのでお任せします。
typing rules は、「型付けルール」という訳語があったのでそちらに当てはめました。
動き、ふるまい、などのbehaviorですが、動作としたほうが明解なので、訂正しました。
→ 動作を変更する型付けルール
となります。
濱崎 wrote:
・この図解のいくつかの面
この 面 は、aspect から来ていますね。日本語であれば 点 とした方がすっきりと読み手の頭に入るでしょう。
点でよかったのですね。考えすぎました。
濱崎 wrote:
・どの特定のフロントエンド、または環境に結び付けられているわけでもないのです
どの がどこまでかかるのか明確ではありません。
→ある特定のフロントエンドまたは環境に結び付けられているわけではないのです
訂正しました。
濱崎 wrote:
・驚くには当たりませんが <editor> という名前の
少し砕けた言いかたにするなら、
→ありきたりですが <editor> という名前の
もありかなと思いました。
実は、<editor>というタグについては、読んでいて私は驚いてしまったので、
驚くことはありませんが <editor> という名前の
にしてみました。
第四稿になります。
よろしくお願いします。
以上です。
濱崎 登録日: 2004年1月 27日 記事: 296 所在地: 静岡県
件名: Re: [草稿]エディタはどのように動作するか 投稿時間: 2008年1月26日(土) 01:23
修正ありがとうございました。また続きから見ました。
Quote: window._content から取得したものと識別します。
このままだと、日本語として文の主語とつなげた時におかしくなります。(能動と受動が逆)
識別するのは、恐らく JavaScript の関数で、type属性は識別させる手掛かりとなるものですよね。
Quote: id 属性、 id="content-frame" を持てば、
出ている例の説明に特化していいと思うので、
→ id 属性、 id="content-frame" があるので
Quote: CSS からそのスタイルシートを定義できます。
CSS は定義されたスタイルシートそのものですから、なんとなくしっくりきません。
→ CSS を使ってスタイルを決められます。
くらいで軽く流してしまった方がいいかもしれません。
Quote: 呼び出し側が変数を新規ウィンドウに渡す方法で、これを使って読み出したい URL を取得します
原文にあった We を省略したので、後半の主語がありません。主語を補わずに済ますなら、末尾を
→ URL を指定します
とした方が自然です。
Quote: <editor> の遷移があるため、
→ <editor> タグへの遷移の途中ですから、
Quote: editorShell を手作業で make しなければなりません
こう書かれると、UNIX系統のOSを使っている人間は editorShell をコンパイルしにかかります。
# make というコマンドがあるので。
冗談はさておき、ここで言わんとしていることは、
→ editorShell を明示的に作成しなければなりません
ということだと思います。
Quote: 使用する webShellWindow で示して、
少し言葉足らずに感じます。前後とコードを見る限り、動作するべき window を webShellWindow を使って editorShellに指し示しているので、それがわかるような訳だといいと思います。
Quote: XUL が構文解析されると、コンテンツ・フレームにある src 属性は about:blank ( 標準の ' 空白ページの ' URL ) にセットされます。 XUL を構文解析する前にそれを設定することはできないので、 今すぐに編集したいページをわざわざ読み込むようにしなければなりません。
今すぐ というのが、ピンときませんが、言いたいことはよくわかります。
前の方の文の be 動詞は was, 過去形です。これを活かすようにすれば、
→XUL が構文解析された時、コンテンツ・フレームにある src 属性は about:blank ( 標準の ' 空白ページの ' URL ) に設定されました。XUL を構文解析する前にURLを設定することができなかったためです。ですから、 今ここで編集したいページを読み込む必要があります。
などのような訳が考えられます。
Quote: ウィンドウのデストラクト、それゆえにエディタの片付け
接続詞をなんとかしたいです。原文は and hence ですね。
→ とその後に続く
とか。大雑把には
→ つまり
で済ませてしまってもいいような気がします。
Tayu 登録日: 2003年8月 05日 記事: 117 所在地: 千葉県
件名: Re: [草稿]エディタはどのように動作するか 投稿時間: 2008年1月26日(土) 19:19
こんにちは。ご指摘ありがとうございます。
濱崎 wrote:
Quote: window._content から取得したものと識別します。
このままだと、日本語として文の主語とつなげた時におかしくなります。(能動と受動が逆)
識別するのは、恐らく JavaScript の関数で、type属性は識別させる手掛かりとなるものですよね。
以下のように訂正しました。
→属性 type="content-primary" はこれをウィンドウのコンテンツ要素であると識別します。つまり、 window._content から取得したものです。
濱崎 wrote:
Quote: id 属性、 id="content-frame" を持てば、
出ている例の説明に特化していいと思うので、
→ id 属性、 id="content-frame" があるので
訂正しました。
濱崎 wrote:
Quote: CSS からそのスタイルシートを定義できます。
CSS は定義されたスタイルシートそのものですから、なんとなくしっくりきません。
→ CSS を使ってスタイルを決められます。
くらいで軽く流してしまった方がいいかもしれません。
確かに、原文は to style とあるので、定義できます。と訳しすぎないほうが良いですね。
訂正しました。
濱崎 wrote:
Quote: 呼び出し側が変数を新規ウィンドウに渡す方法で、これを使って読み出したい URL を取得します
原文にあった We を省略したので、後半の主語がありません。主語を補わずに済ますなら、末尾を
→ URL を指定します
とした方が自然です。
以下のように、 We を含めるように訳し直しました。
→呼び出し側が変数を新規ウィンドウに渡す方法です-読み出したい URL を取得するときにはこれを使います
濱崎 wrote:
Quote: <editor> の遷移があるため、
→ <editor> タグへの遷移の途中ですから、
適訳をありがとうございます。訂正しました。
[quote="濱崎"]
Quote: editorShell を手作業で make しなければなりません
こう書かれると、UNIX系統のOSを使っている人間は editorShell をコンパイルしにかかります。
# make というコマンドがあるので。
冗談はさておき、ここで言わんとしていることは、
→ editorShell を明示的に作成しなければなりません
ということだと思います。
[/quote]
ここは誤訳ですね。 ごく普通に作成する、の意味でした。
明示的に
は省きましたが、以下のように訳し直しました。
→ <editor> タグがない場合には、 JavaScript を組んで editorShell を作成しなければなりません:
濱崎 wrote:
Quote: 使用する webShellWindow で示して、
少し言葉足らずに感じます。前後とコードを見る限り、動作するべき window を webShellWindow を使って editorShellに指し示しているので、それがわかるような訳だといいと思います。
以下のように訳し直しました。
→webShellWindow でポインタで示して使用できるようにして、
濱崎 wrote:
Quote: XUL が構文解析されると、コンテンツ・フレームにある src 属性は about:blank ( 標準の ' 空白ページの ' URL ) にセットされます。 XUL を構文解析する前にそれを設定することはできないので、 今すぐに編集したいページをわざわざ読み込むようにしなければなりません。
今すぐ というのが、ピンときませんが、言いたいことはよくわかります。
前の方の文の be 動詞は was, 過去形です。これを活かすようにすれば、
→XUL が構文解析された時、コンテンツ・フレームにある src 属性は about:blank ( 標準の ' 空白ページの ' URL ) に設定されました。XUL を構文解析する前にURLを設定することができなかったためです。ですから、 今ここで編集したいページを読み込む必要があります。
などのような訳が考えられます。
ここの部分はご指摘の訳を参考にして、訳し直しました。
→XUL が構文解析された時、コンテンツ・フレームにある src 属性は about:blank ( 標準の ' 空白ページの ' URL ) に設定されていました。 XUL を構文解析する前にそれを設定することはできないのです。そのため、今ここで編集したいページを強いて読み込む必要があります。
濱崎 wrote:
Quote: ウィンドウのデストラクト、それゆえにエディタの片付け
接続詞をなんとかしたいです。原文は and hence ですね。
→ とその後に続く
とか。大雑把には
→ つまり
で済ませてしまってもいいような気がします。
以下のように訳し直しました。
→ウィンドウのデストラクト、それに引き続くエディタの片付けは、以下に挙げた二つの方法で初期化されます。
第五稿になります。
以上です。
よろしくお願いします。
濱崎 登録日: 2004年1月 27日 記事: 296 所在地: 静岡県
件名: Re: [草稿]エディタはどのように動作するか 投稿時間: 2008年1月28日(月) 23:56
続きからいきましょう。
Quote: この例では、 <window> タグ上の onclose メソッドが 呼び出されます。
ここでの this case は、この場合 でいいでしょう。
Quote: nsTextEditorKeyListener ( nsIDOMKeyListener ひとつとして )
→ nsTextEditorKeyListener ( nsIDOMKeyListener として )
()内が型、()の前が実際に呼び出される関数ということでいいんではないでしょうか?
ここは、他の詳しい方に聞いた方がいいかもしれません。
Quote: ( つまり、テキスト・ウィジェットではなく )
→ つまり、テキスト・ウィジェット以外
としてみたらどうでしょう。
ここでの selection は、選択範囲 を指しているのだと思います。
Quote: このオブジェクトは単純に nsHTMLEditor::InsertText() を
オブジェクト に当たる原語はありません。敢えて補うなら このメソッド では?
Quote: バッチ処理によるタイピング・イベントが合わせて可能になる
ここの batch は動詞です。
→ タイピング・イベントをまとめることが可能になる
終わりの
Quote: Maintained by the editor team:
は、このままにしますか?
ここまでで、一応、最後まで目を通した事になります。
XUL と JavaScript がわからないと正否が判断できない部分はかなり読み飛ばしました。
特に、動作を詳しく説明している部分です。これらについては、他の方に譲ります。
Tayuさん、かなり分量のある文書の翻訳、大変だったと思います。ありがとうございました。
Tayu 登録日: 2003年8月 05日 記事: 117 所在地: 千葉県
件名: Re: [草稿]エディタはどのように動作するか 投稿時間: 2008年1月30日(水) 16:19
こんにちは。
全文チェックして頂きましてありがとうございます。
濱崎 wrote:
Quote: この例では、 <window> タグ上の onclose メソッドが 呼び出されます。
ここでの this case は、この場合 でいいでしょう。
訂正しました。
濱崎 wrote:
Quote: nsTextEditorKeyListener ( nsIDOMKeyListener ひとつとして )
→ nsTextEditorKeyListener ( nsIDOMKeyListener として )
()内が型、()の前が実際に呼び出される関数ということでいいんではないでしょうか?
ここは、他の詳しい方に聞いた方がいいかもしれません。
「ひとつ」まで訳す必要はありませんでしたね。
訂正しました。
()内はDOMが使われていると思います。
DOMの資料を読む前にこちらを訳してしまいました。
()の左側が型で、()内が実際に呼び出されたときに
ひとつひとつ作成されるのではないかと思うのですが
詳しい方、いらっしゃいましたら教えてくださると助かります。
濱崎 wrote:
Quote: ( つまり、テキスト・ウィジェットではなく )
→ つまり、テキスト・ウィジェット以外
としてみたらどうでしょう。
少し意訳になりますが、そのほうが分かりやすいと思います。
訂正しました。
濱崎 wrote:
ここでの selection は、選択範囲 を指しているのだと思います。
訂正しました。
濱崎 wrote:
Quote: このオブジェクトは単純に nsHTMLEditor::InsertText() を
オブジェクト に当たる原語はありません。敢えて補うなら このメソッド では?
このメソッド に訂正しました。
濱崎 wrote:
Quote: バッチ処理によるタイピング・イベントが合わせて可能になる
ここの batch は動詞です。
→ タイピング・イベントをまとめることが可能になる
別の概念を持ち込んでいたようです。
訂正しました。
濱崎 wrote:
終わりの
Quote: Maintained by the editor team:
は、このままにしますか?
ここは訳したほうがいい原文そのものではなく、
ドキュメント・ツリーの書き換え部分について注記されたものですから、
そのままにしたいんですが、コメントで訳をつけておきます。
濱崎 wrote:
ここまでで、一応、最後まで目を通した事になります。
XUL と JavaScript がわからないと正否が判断できない部分はかなり読み飛ばしました。
特に、動作を詳しく説明している部分です。これらについては、他の方に譲ります。
Tayuさん、かなり分量のある文書の翻訳、大変だったと思います。ありがとうございました。
こちらこそ、ありがとうございます。
この後一週間くらい経過してから、完成稿のほうに提出したいと思います。
#私はDOMとJavaScript、XULの資料を読み直そうと思います。
端から読まなくても訳せるかと思ったのですが、あいまいなところが残りました。
惜しいですが、一応、この時点で完成稿として公開しようと思っています。
他にも、ご指摘いただけるところがありましたら、よろしくお願いします。
第六稿になります。
以上です。
Tayu 登録日: 2003年8月 05日 記事: 117 所在地: 千葉県
件名: Re: [草稿]エディタはどのように動作するか 投稿時間: 2008年2月01日(金) 10:08
DOMの資料を読み直して、四箇所ほど訂正を加えました。
1.
コンテンツ → コンテント
2.
一番下の注釈をコメントではなく、直接訳し出しました。
Maintained by the editor team: mozilla-editor@mozilla.org
→エディタ・チームによって保守されています: mozilla-editor@mozilla.org
3.
文書 → ドキュメント
4.
レベル → 水準
以上です。
第七稿になります。
よろしくお願いします。
Tayu 登録日: 2003年8月 05日 記事: 117 所在地: 千葉県
件名: Re: [草稿]エディタはどのように動作するか 投稿時間: 2008年2月04日(月) 20:46
修正が続いていますが、よろしくお願いします。
5.
Quote:
このドキュメントでは、エディタがどのようにインスタンス化されて Composer ウィンドウのためにイベント処理するかを扱います。
→
このドキュメントでは、エディタがどのようにインスタンス化されて Composer ウィンドウのためにイベント処理をするかについて扱います。
6.
Quote:
テキスト・ウィジェットのためにエディタがどのように作成されるかについては、詳しくはテキスト・ウィジェット・ドキュメントを参照してください。
→
テキスト・ウィジェットのためにエディタがどのように作成されるかについては、詳しくはテキスト・ウィジェットのドキュメントを参照してください。
7.
Quote:
The webShellWindow (a settable attribute on nsIEditorShell) points to the top-level window element, from which the editorShell can get the XUL document in which it is living.
webShellWindow ( nsIEditorShell にセットできる属性 ) はウィンドウ属性の最高水準を 指します。そこからその中に editorShell が存続している XUL ドキュメントを editorShell が取得できるようになります。
画面のウィンドウそのものではなく、例に示されている window という名前の属性でした。
point to については、ポインタで示すと訳してしまっています。
↓
webShellWindow ( nsIEditorShell にセットできる属性 ) は window 属性の最高水準をポインタで示していて、そこからその中に editorShell が存続している XUL ドキュメントを editorShell が取得できます。
8.
Quote:
さて、 nsTextRulesInfo を挿入された文字列についての情報で初期化して、 現在の 編集規則 の上にある WillDoAction() を呼び出します。 テキスト挿入の実装は異なる規則 ( プレーンテキスト対 HTML 等 ) の間で異なっているため、 規則コード、 WillDoAction() 内の呼び出しによってもっぱら扱われます。
規則→ルール
としました。
→
さて、 nsTextRulesInfo を挿入された文字列についての情報で初期化して、 現在の 編集ルール の上にある WillDoAction() を呼び出します。 テキスト挿入の実装は異なるルール ( プレーンテキスト対 HTML 等 ) の間で異なっているため、 ルール・コード、 WillDoAction() 内の呼び出しによってもっぱら扱われます。
第八稿になります。
以上です。
濱崎 登録日: 2004年1月 27日 記事: 296 所在地: 静岡県
件名: top-level window について 投稿時間: 2008年2月06日(水) 14:43
7. に出てきた top-level window についてです。
top-level window というのは、GUI の API ドキュメントでは 親を持たないウィンドウ(とっても大雑把にいうと、アプリケーションを起動したときに最初に生成される基本的なウィンドウ。画面全体を root Window とすると、その直下の子供)のことで、トップレベルウィンドウ とカタカナ訳されることがあります。
ここでも、その意味で使われているようですよ。
なので、文の前半が言いたいことは、このトップレベルウィンドウを指す要素(element) を
webShellWindow ( nsIEditorShell にセットできる属性で、ウィンドウを指すことができるポインタ型)
が指している ということでしょう。
池田 登録日: 2003年5月 22日 記事: 408 所在地: 東京
件名: Re: [草稿]エディタはどのように動作するか 投稿時間: 2008年2月06日(水) 14:47
Tayu さん、池田です。長文の和訳、お疲れさまです。
に対して、主として日本語の読みやすさという点から、いくつか。
なお、コメントを何回かに分けて投稿せざるをえないので、そのつど新しい草稿にしなくて結構です。
冒頭部の表題ですが、意訳した方がいいかと。
→ このドキュメントの内容
Quote: このドキュメントでは、エディタがどのようにインスタンス化されて Composer ウィンドウのためにイベント処理をするかについて扱います。メール作成ウィンドウにおける使い方と非常によく似ていて、殆どの組み込みアプリケーションに関連してくるでしょう。
「"how the editor is instantiated, and handles events" を扱うんだけど、Composer の場合だよ。
でも、メールや組み込みアプリでもあんまし違わないよ」
という事が言いたいんじゃないかと。
→ このドキュメントでは、Composer ウィンドウにおいて、エディタがどのようにインスタンス化されイベント処理をするかについて扱います。エディタは、メール作成ウィンドウにおいても非常によく似た使い方をされており、また多くの組み込みアプリケーションでも参考になるでしょう。
"high-level picture" をどう訳すか悩ましいところです。
あくまでも参考程度ですが;
→ 上位レベルのフローチャート
Quote: この図では、 ユーザー・インターフェース ( 記述言語は XUL と JavaScript です ) 、 nsEditorShell ( ユーザー・インターフェースとエディタ・コア間のインターフェースとなります ) 、そして エディタそのものとの間の相互作用を、動作を変更する型付けルールとともに示しています。
"typing rules" は、HTML かプレーンテキストか、という事なのでは?
また、これは「エディタそのもの」にかかる筈です (つまり、nsHTMLEditRules)。
原文の構造から若干ずれますが;
→ この図では、 ユーザー・インターフェース ( 記述言語は XUL と JavaScript です ) 、 nsEditorShell ( ユーザー・インターフェースとエディタ・コア間のインターフェースとなります ) 、そしてエディタコア (文書の型によって動作が異なります) との間の相互作用を示しています。
Quote: そのときエディタは、編集されているドキュメント上で動作します。
"then" は「その時」ではなく「その後」ではないかと。
→ エディタが、編集されようとしているドキュメント上で動作するのは、この相互作用の後になります。
"Editor instantiation in a XUL window" 以下は、今日の夜か明日に。 ____________________ Mozilla Japan 翻訳部門 和訳アドバイザー
Tayu 登録日: 2003年8月 05日 記事: 117 所在地: 千葉県
件名: Re: [草稿]エディタはどのように動作するか 投稿時間: 2008年2月07日(木) 17:48
こんにちは。
ご指摘頂きましてありがとうございます。
訂正し直し、書き直しが多くてすみません。
かみくだいた分かりやすい文章を、と痛感しております。
池田 wrote:
冒頭部の表題ですが、意訳した方がいいかと。
→ このドキュメントの内容
訂正しました。
池田 wrote:
Quote: このドキュメントでは、エディタがどのようにインスタンス化されて Composer ウィンドウのためにイベント処理をするかについて扱います。メール作成ウィンドウにおける使い方と非常によく似ていて、殆どの組み込みアプリケーションに関連してくるでしょう。
「"how the editor is instantiated, and handles events" を扱うんだけど、Composer の場合だよ。
でも、メールや組み込みアプリでもあんまし違わないよ」
という事が言いたいんじゃないかと。
→ このドキュメントでは、Composer ウィンドウにおいて、エディタがどのようにインスタンス化されイベント処理をするかについて扱います。エディタは、メール作成ウィンドウにおいても非常によく似た使い方をされており、また多くの組み込みアプリケーションでも参考になるでしょう。
Composer ウィンドウ を前にもってきたほうが文章がすんなりしますね。
訂正しました。
池田 wrote:
"high-level picture" をどう訳すか悩ましいところです。
あくまでも参考程度ですが;
→ 上位レベルのフローチャート
フローチャートだとプログラミングの流れ図をまず思い浮かべて違和感を覚えてしまうので、
→上位レベルの関係図
にしてみました。
ですけど、オブジェクト指向プログラミングのフローチャートですよね、この図は。
ただ、水準、という単語は DOM Level1 の訳に第 1 水準と出てくるので、
取り入れてみたのですが、訳語だけを単独でもってくると、どうも日本語として
なじみにくいところがあるようです。
濱崎 wrote:
7. に出てきた top-level window についてです。
top-level window というのは、GUI の API ドキュメントでは親を持たないウィンドウ(とっても大雑把にいうと、アプリケーションを起動したときに最初に生成される基本的なウィンドウ。画面全体を root Window とすると、その直下の子供)のことで、トップレベルウィンドウ とカタカナ訳されることがあります。
ここでも、その意味で使われているようですよ。
こちらについても、ウィンドウのフレームそのものを指すこともあるのでしたら、
window 属性の最高水準
↓
トップレベルのウィンドウ属性
のほうが良さそうです。
以下、
より低い水準→より低いレベル
に戻しました。
池田 wrote:
Quote: この図では、 ユーザー・インターフェース ( 記述言語は XUL と JavaScript です ) 、 nsEditorShell ( ユーザー・インターフェースとエディタ・コア間のインターフェースとなります ) 、そして エディタそのものとの間の相互作用を、動作を変更する型付けルールとともに示しています。
"typing rules" は、HTML かプレーンテキストか、という事なのでは?
また、これは「エディタそのもの」にかかる筈です (つまり、nsHTMLEditRules)。
原文の構造から若干ずれますが;
→ この図では、 ユーザー・インターフェース ( 記述言語は XUL と JavaScript です ) 、 nsEditorShell ( ユーザー・インターフェースとエディタ・コア間のインターフェースとなります ) 、そしてエディタコア (文書の型によって動作が異なります) との間の相互作用を示しています。
この中で、
Quote:
"typing rules" は、HTML かプレーンテキストか、という事なのでは?
型付けルールですが、文が厳密な型に合っているかどうか、ということらしいのです。
cf.
http://www.j-tokkyo.com/2002/G06F/JP2002-073349.shtml
HTML でも strict かどうかというのがありますから、
タグなどの型付けを厳密にするかどうか、というのがあるかもしれません。
池田 wrote:
Quote: そのときエディタは、編集されているドキュメント上で動作します。
"then" は「その時」ではなく「その後」ではないかと。
→ エディタが、編集されようとしているドキュメント上で動作するのは、この相互作用の後になります。
訂正しました。
以上です。
池田 登録日: 2003年5月 22日 記事: 408 所在地: 東京
件名: Re: [草稿]エディタはどのように動作するか 投稿時間: 2008年2月07日(木) 21:29
続きです。
"Editor instantiation in a XUL window" の所から。
Quote: XUL の中でエディタは XUL 最上部の <iframe> 要素に存続しています。
"live on" を「存続」で訳してしまうとわかりにくくなると思います。
やや意訳入りますが;
→ エディタが仕事をするのは XUL 最上部の <iframe> 要素です。
Quote: <iframe> コンテントはそうすると編集可能になります。
→ これによって <iframe> コンテントは編集可能になるのです。
Quote: エディタ・シェルは正しい時間にエディタを作成して、
"when the time is right" で成句です。
英辞郎 wrote: (チャンスの)時が来たら、機が熟したら、そのときが来たら、頃合いになったら、しかるべき時が来たら
→ エディタ・シェルは、エディタを適切なタイミングで作成し、
Quote: 特別にエディタのための、驚くことはありませんが <editor> という名前のタグへと遷移していくところです
濱崎さんの「ありきたりですが <editor> という名前の」を推します。
→ エディタのための特別なタグ、ありきたりですが <editor> という名前のタグへと遷移していくところです
Quote: あるところで、あるものが、 Mozilla に composer ウィンドウを開くように指示を出します。
間違ってはいませんが(^^;
→ どこかの誰かが、Mozilla に composer ウィンドウを開くように指示を出します。
Quote: そのため、今ここで編集したいページを強いて読み込む必要があります。
"we have to force a load of the page" から「強いて」が出てきたんだろうと思います。
別の訳例として;
→ そのため、ここで編集したいページをあらためて読み込む必要があります。
Quote: 編集を開始することができるドキュメントをいつになったら保持できるのか知る必要があります。
→ いつドキュメントの読み込みが終了して編集を開始できるようになったかを知る必要があります。
とりあえず以上です。
適宜、取捨選択してください。
ご参考になれば幸いです。 ____________________ Mozilla Japan 翻訳部門 和訳アドバイザー
Tayu 登録日: 2003年8月 05日 記事: 117 所在地: 千葉県
件名: Re: [草稿]エディタはどのように動作するか 投稿時間: 2008年2月09日(土) 17:08
池田 wrote: 続きです。
"Editor instantiation in a XUL window" の所から。
Quote: XUL の中でエディタは XUL 最上部の <iframe> 要素に存続しています。
"live on" を「存続」で訳してしまうとわかりにくくなると思います。
やや意訳入りますが;
→ エディタが仕事をするのは XUL 最上部の <iframe> 要素です。
存続、もしくは生存で、キープアライブのことかと思っていました。
訂正しました。
池田 wrote:
Quote: <iframe> コンテントはそうすると編集可能になります。
→ これによって <iframe> コンテントは編集可能になるのです。
このほうが分かりやすいですね。採用させて頂きます。
池田 wrote:
Quote: エディタ・シェルは正しい時間にエディタを作成して、
"when the time is right" で成句です。
英辞郎 wrote: (チャンスの)時が来たら、機が熟したら、そのときが来たら、頃合いになったら、しかるべき時が来たら
→ エディタ・シェルは、エディタを適切なタイミングで作成し、
やってしまいました。
他のところに時間のことが書いてなかったので、少々訝しい思いもあったわけですが…。
wrote:
Quote: 特別にエディタのための、驚くことはありませんが <editor> という名前のタグへと遷移していくところです
濱崎さんの「ありきたりですが <editor> という名前の」を推します。
→ エディタのための特別なタグ、ありきたりですが <editor> という名前のタグへと遷移していくところです
確かに 驚くことはありませんが はそのままにしておくと違和感が残っていましたね。
池田 wrote:
Quote: あるところで、あるものが、 Mozilla に composer ウィンドウを開くように指示を出します。
間違ってはいませんが(^^;
→ どこかの誰かが、Mozilla に composer ウィンドウを開くように指示を出します。
意訳しすぎでしたか。
訂正しました。
池田 wrote:
Quote: そのため、今ここで編集したいページを強いて読み込む必要があります。
"we have to force a load of the page" から「強いて」が出てきたんだろうと思います。
別の訳例として;
→ そのため、ここで編集したいページをあらためて読み込む必要があります。
強いて だとぎこちないんですが、 あらためて だと二度目に読み込むという意味になるかもしれません。
と思ったのですが、この時点でコンテント・ノードの読み込みは進めてしまっているので、
あらためて全体を読み込む という意味になるかもしれません。
ということで、訂正しました。
池田 wrote:
Quote: 編集を開始することができるドキュメントをいつになったら保持できるのか知る必要があります。
→ いつドキュメントの読み込みが終了して編集を開始できるようになったかを知る必要があります。
こちらのほうがこなれた訳ですね。
ありがとうございます。