[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[gentoojp-docs 410] Re: Gentoo Linux XML Guide(was Re:ËÝÌõ¤ÎͽÌó)
萩原です。
読んでみました。
のでツッコミです。
==========================================================================
<全体>
・「一つ、二つ」と「１つ、２つ」と「1つ、2つ」
いずれかで。
<1.ガイドの基本方針>
・Gentoo Linuxではxsltprocという変換ツールを使っており、それはlibxsltパッケ
ージに含まれています。
「それは」は不要かなと思います。
・これで道具は手に入りました、今度は
「、」→「。」
・「tarballs」→「tarball」
・Gentoo Linux webサイト全体
「ウェブ」という表記が採用されているようなので、
「ウェブサイト」で。
・不可能なことに注意してください、ですから
「、」→「。」
・このtarballに含まれるドキュメントで変換することは不可能な
ことに注意してください
ちょっとよくわかりませんでした。
と思って原文見てもこれまたよくわかりませんでした(笑)。
たぶんguide.xslがないから「変換」できないということだと思うので、
多少、それを訳注ででも補ってあげると良いかなと思いました。
・web tarball
なんとなく「一つめのweb tarball」とか書いた方が、
わかりやすいのではないかと。
・Gentoo Linux CD Installation Guideを使うでしょう。
「使ってみましょう」とかにした方が良さそうです。
・もしすべてがうまくいけば、gentoo-x86-install.htmlの/tmp/install.htmlでウェ
ブ表示可能なバージョンを得られるはずです。
もしすべてがうまくいけば、gentoo-x86-install.htmlのウェブ表示可能なバージ
ョンが、/tmp/install.htmlにできているはずです。
のような感じでどうでしょうか。
・ウェブブラウザに適切に表示できるこのドキュメントについては、
このドキュメントをウェブブラウザで適切に表示するためには、
という感じだと思います。
<2.ガイドのXML>
・もうガイドXMLを変換する方法を知っていますので、あなたがガイドXML構文の学
習をスタートする準備は整いました。
なんか、どうも気になります。
「知っています」の主語が省略されてるから？(自問自答)
うーん。というわけで、考えてみたのが以下です。
さて、あなたはXMLを変換する方法がわかったわけですから、これでXML構文の学
習をスタートする準備は整ったことになります。
・著者のドキュメント(著者、共同執筆者、エディタなど)との関係
カッコの位置は、
著者のドキュメントとの関係(著者、共同執筆者、エディタなど)
の方が良いと思います。
あと、この部分は翻訳でも訳してないところなので、
著者のドキュメントとの関係(Author、Co-author、Editorなど)
とかの方が良いかもしれません。
・<abstract>, <version>
<abstract>、<version>
・<abstract>, <version>および<date>らのタグに
「ら」は不要？
・これらはドキュメント、現行版番号および現行版期日(DD MMM YYYYフォーマット
で)の要約をそれぞれ指定するために使用されています。
これらはドキュメントの要約、〜をそれぞれ〜。
だと思います。
それから、
「現行版番号」→「現行版のバージョン」
「現行版期日」→「現行版の日付」
かなと。
・この完成させたタグは、ガイド・ドキュメントの初めに現われるべきものです。
これらのタグが先頭に置かれることで、ガイド・ドキュメントは完成します。
かなと思います。
・<title>および<mail>のタグを除いて、直ち<guide>タグの内部でという点を除い
て、これらのものは、他のいかなる場所にも現われてはなりません。
<title>および<mail>のタグを除いて、これらのタグは<guide>タグ直後以外の、
いかなる場所にも現われてはなりません。
という感じだと思います。
・あなたはドキュメントの構造のエレメントを加えていく準備ができています。
ドキュメントにエレメントを追加して構造化していく準備ができています。
とかかなあと。
僕、XMLはこのガイドXMLで勉強したような人だったりするので、
専門用語とかあまり知らないのですが、
structural elementsに対応するタームがあるなら、
それを使っても良いかなと思いました。
・XMLにこのXMLに前の抜粋を追加して、またそのファイルの終わりへ</guide>を追
加することで、有効な(最小の場合)ガイド・ドキュメントを得ることができます。
このXMLを先程抜粋したXMLに追加して、そのファイルの末尾に</guide>を追加す
れば、(最低限の内容ではありますが)有効なガイド・ドキュメントの完成です。
という感じかと。
・理解して頂けるとおもいます。
思います。
・そして私たちは、<body>エレメントの内側で使用が許される小さなタグを見つけ
ることができます。
それから<body>エレメントの内側で使用できるタグもちょっとだけ見えますね。
という風じゃないかと。
個人的な趣味嗜好で柔くなりすぎてるとは思いますが。
・しかしながら<section>エレメントは<body>エレメントを一つしか含むとができ
ません。
〜含むことが〜
・さてここらで、実際の内容をマークする方法を学習しましょう。
さてここらで、実際の内容をマークアップする方法を学習しましょう。
もしくは。
さてここらで、実際の内容を記述する方法を学習しましょう。
のような感じだと思います>mark up
・ここに、<body>エレメントのための例としてXMLコードがあります。
以下は<body>エレメントのためのXMLコードの例です。
かなと。
・HTML/XMLを選択的強調の使用により読むことをさらに容易にしてください。
ある部分を選択して強調することで、HTML/XMLをより読みやすくしてください。
という感じだと思います。
・私たちは前のセクションで多くの新しいタグを導入しました。
この前の部分で「節」という用語を使っているので、
「セクション」→「節」だと思います。
また、「導入」は紹介で良いような気がします。
・ここには、あなたが知っておくべきことがあります。
次のことを覚えておいてください。
のような感じの方が自然かなあと。
・<table>エレメントを除いて(私たちは一口でカバーするでしょう)
<table>エレメント(すぐに説明します)を除いて
という感じだと思います。
・これらは<body>の内部で直ちに現われるべき、ただ一つのタグです。
これらのタグ以外のものが<body>の内部に最初に現れてはいけません。
とかでどうでしょう。
・別のものをこれらのタグに積み重ねてはいけません。
また、これらのタグは積み重ねてはいけません。
かなと思います。
・<path>, <c>および<e>
「,」→「、」
・<path>エレメントは、on-disk fileを参照するマーク・テキストに使用されます。
<path>エレメントは、ディスク上のファイルを表わすテキストをマークアップす
るために使用されます。
のような感じじゃないかと思います。
・絶対または相対パス
絶対パスまたは相対パス
の方が良いかなと思いました。
・単純なファイル名
「ただのファイル名」もしくは「ファイル名のみ」の方が良いかなあと。
・この要素は一般的に標準の段落タイプからそれを除外して、一定間隔で配置され
たフォントを与えられます。
少し意訳入ってますが、
この要素は一般的に、標準の段落の中で目立たせるために等幅フォントで表示さ
れます。
という感じじゃないかと思います。
・<c>エレメントはコマンドあるいはユーザ入力をマークするために使用されます。
ユーザ入力をマークアップするために
のような感じで。
・タイプイン
「入力」とか「タイプ」とかで良いのではないでしょうか。
・<c>について考えると、読み手にそれをタイプインすることができること、ある
いはある種類のアクションを実行するものだと、警告を出す方法であると言えま
す。
<c>については、読み手に何らかの結果を伴う入力が促されていることを警告す
る方法だと考えてください。
という感じだと思います。
・さらに、<c>エレメントは、規則的なテキストから既に削除されます、ダブルク
ォートでユーザ入力を囲むようなサポートはめったに必要としません。
さらに、<c>エレメントは、もともと通常のテキストとは違うフォントで表示さ
れるようになっているわけですから、ダブルクォートでユーザ入力を囲んだりす
る必要がほとんどないというわけです。
のような感じかと。
・例えば、"<c>"のようなエレメントの参照なしで文を作成しました。
例えば、いま私がこの文で"<c>"エレメントなどと書いているような注目のさせ
かたは必要ないのです。
という感じだと思います。
・不必要なダブルクォートの使用の回避はドキュメントをより判読可能にします、
そして愛用しましょう!
「、」→「。」
あと、「より判読しやすくします」の方が良さそうです。
・たとえば私は、実際にはセミコロンより頻繁に使用するべきと思っています。
たとえば、私はセミコロンの方を多く使うべきだと<e>本当に</e>思います。
という感じかなと。
・このテキストは強調のための規則的な段落のタイプから切り離されます。
このテキストは通常の段落のフォントより目立ちます。
という感じだと思います。
・それは2つの形式を持っており、 1つはhttp://www.gentoo.orgへリンクのような;
テキスト本体に実際のURIを表示したい場合に使用することができます。
もともとは、
「http://www.gentoo.orgへリンクのような」;
という部分が気になったのですが、
原文を見て、
このタグは2つの使われ方があります。まず1つ目は、たとえばhttp://www.gento
o.orgへリンクするこのテキストのように、テキスト本体に実際のURIを表示した
い場合です。
のような感じじゃないかなと思いました。
・別の形式は、たとえばthe Gentoo Linux websiteのように、
もひとつは、たとえばGentoo Linuxのウェブサイトのように、
これはひとつ前の行を直してみたのでそのついでにという感じです。
あと、ここを英語のままにする意味はないかなと。
うしろの方で同様な部分、タグに囲まれてても訳されてるので。
・あなたが他のあるテキストにURIを関連させたい場合です。
他のテキストにURIを関連させたい場合です。
という感じじゃないかと。
・体裁
「図」ですね、これは。
・ここに、ドキュメントに図を挿入する方法があります。
では、ドキュメントに図を挿入する方法を紹介しましょう。
という感じかと思います。
・short=属性が指定する短い記述(現在イメージのHTMLalt=属性のために使用され
た、およびキャプション。決して難しくありません:)
short=属性には短い説明(今回は画像にHTMLのalt=属性を付けるために使用され
ています)やキャプションを指定します。決して〜
という感じだと思います。
・ガイドはHTMLのそれに似ている単純化されたテーブル構文をサポートします。
ガイドXMLはHTMLのテーブリやリストと同様の、より単純化されたテーブルの構
文をサポートしています。
という感じだと思います。
・代わりに、<ti>を使用してください。ヘッダーを挿入していれば<th>、通常の情
報のブロックを挿入していれば<ti>を使用してもよく、とくに要求されることは
ありません。<th>エレメントは第1列にのみ現われます。
代わりに、ヘッダーを入力するときは<th>を、通常の情報のブロックを入力して
いるときは<ti>を使用してください。<th>は、<ti>が使えるところならどこでも
使えます。もちろんそうしなければいけないというわけではなく、いずれにせよ
<th>エレメントは第1列にしか表示されません。
という感じだと思います。
挿入はそのまでも良いと思うんですが、なんとなく趣味で入力に。
・規律リストあるいは無規則リストを作成するためには、単にHTMLスタイルの<ol>,
<ul>および<li>タグを使用してください。
順序付きのリストあるいは順序無しのリストを作成〜<ol>、<ul>および〜。
かなと。
・リスト・タグは <p>, <ti>,<note>, <warn>または<impo>タグの内で単独で現わ
れるべきです。
リスト・タグは<p>、<ti>、<note>、<warn>または<impo>タグの中でのみ使って
ください。
だと思います。
・ガイドは、ハイパーリンクを使用してドキュメントの他の部分に参照を付けるこ
とを実に簡単におこなえます。
〜行なえます。
あと、「ガイド」→「ガイドXML」にした方が良いと思います。
・リンクは第1章を<uri link="#doc_chap1">第1章</uri>のようにタイプして指し
示すことで作成することができます。
「リンク」と「作成」が遠すぎると思うので、
第1章を<uri link="#doc_chap1">第1章</uri>のようにタイプして指し示すこと
で、リンクを作成することができます。
ではどうかなと。
「タイプ」→「入力」のような気もします。
・第1章2節を指し示すためには、<uri link="#doc_chap1_sect2">第1章2節</uri>
と入力します図3を参照するために、
〜と入力します。図3を〜
・私たちは他の自動リンク機能(テーブル・サポートのような)をすぐに加えるでし
ょう。
私たちは他の自動リンク機能(たとえばテーブルへのリンクのサポート)を近いう
ちに追加する予定です。
みたいな感じでどうでしょうか。
<3.資料について>
・資料について
参考資料？
いっそ「リソース」でも良いような気がしますが。
・記述の開始
書き始めましょう
かなと。
・ガイドは、特に"少数精鋭"であることを目指した結果、開発者は実際のXML構文
を少ない時間で学習し、ドキュメンテーションにより多くの時間を過ごすことが
できます。
ガイドXMLは、とにかく"すっきりさっぱり"を念頭に作られていますから、XMLを
作成する人は、実際のXMLの構文をお勉強することに時間を費すことなく、どん
どんドキュメントを書いてみることができます。
という感じかなと思いました。
"lean and mean"というのが折角の成句なんで、
日本語もそれっぽい方が良いかなというのもあって。
・希望としては、これが異常に熱心な"文献学者"でない開発者にGentoo Linuxドキ
ュメンテーションを書き始めることの促進剤となればと思ってます。
うまく行けば、"ドキュメントの達人"というわけではない人たちでも、上質なGe
ntoo Linuxドキュメントを書き始めることができるでしょう。
ひとつ前のもそうしたのですが、「開発者」としてしまうと、
ドキュメント(というかXML)を書く人というイメージが薄れるかなと。
ので、あえてその部分はちゃんと訳さない方針でどうだろうと。
==========================================================================
そんな感じでございます。
--
萩原佳明(hagi@xxxxxxx)