argra****@users*****
argra****@users*****
2012年 8月 19日 (日) 21:51:38 JST
Index: docs/perl/5.12.1/perlpodspec.pod
diff -u docs/perl/5.12.1/perlpodspec.pod:1.15 docs/perl/5.12.1/perlpodspec.pod:1.16
--- docs/perl/5.12.1/perlpodspec.pod:1.15 Sat Aug 18 16:59:08 2012
+++ docs/perl/5.12.1/perlpodspec.pod Sun Aug 19 21:51:38 2012
@@ -269,7 +269,7 @@
=end original
-しかし複数の (非空行の) 行にわたるかもしれません(may):
+しかし複数の (非空行の) 行にわたってもかまいません(may):
=for comment
Hm, I wonder what it would look like if
@@ -756,7 +756,7 @@
行があった場合) エラーにするべきです(should)。
BOM を認識する Pod プロセッサは、BOM と矛盾する "=encoding" 行がある場合
(例えば、文書が UTF-16LE BOM で始まっていて "=encoding shiftjis" 行がある
-場合)、エラーにするかもしれません(may)。
+場合)、エラーにしてもかまいません(may)。
=back
@@ -1027,8 +1027,8 @@
=end original
このコードは特殊で、内容はなしであるべきです(should)。
-つまり、プロセッサが C<ZE<lt>potatoesE<gt>> を見ると異常とみなすかも
-しれません(may)。
+つまり、プロセッサが C<ZE<lt>potatoesE<gt>> を見ると異常とみなしても
+かまいません(may)。
異常とみなすかどうかに関わらず、I<potatoes> という文字は
無視されるべきです(should)。
@@ -1277,7 +1277,7 @@
Pod フォーマッタは、たとえテキストがページからはみ出すのを避けるために
(とても長い行に対しては複数回)分割しないといけないとしても、
任意の長さのそのままのブロックの行を許容するべきです(should)。
-Pod フォーマッタはそのような行分割に対して警告を出すかもしれません(may)。
+Pod フォーマッタはそのような行分割に対して警告を出してもかまいません(may)。
この警告は特に、(普通は意図したものではない) 100 文字以上の行に対して
出すのが適切です。
@@ -1544,7 +1544,7 @@
極端に異常な文書の場合は、Pod パーサはパースを中断してもかまいません(may)。
それでも、C<die>/C<croak> の使用は避けます; 可能なら、パーサは単に
入力ファイルを閉じて、メモリにある文書(の一部)の末尾に
-"*** Formatting Aborted ***" のような文章を追加できます(may)。
+"*** Formatting Aborted ***" のような文章を追加してもかまいません(may)。
=item *
@@ -1916,9 +1916,9 @@
特にそのようなコードのためのイベントを起動するか、メモリ内文書木に
特別なノード型を追加することで処理する代替オプションを
提供してもかまいません(may)。
-そのような "EE<lt>I<identifier>>" は一部のプロセッサでは特別な意味が
-あるかもしれませんし(may)、一部のプロセッサはこれを特別なエラー報告に
-加えることを選ぶかもしれません(may)。
+そのような "EE<lt>I<identifier>>" は一部のプロセッサでは特別な意味を
+持たせてもかまいませんし(may)、一部のプロセッサはこれを特別なエラー報告に
+加えることを選んでもかまいません(may)。
=item *
@@ -2134,19 +2134,18 @@
=end original
-It is up to individual Pod formatter to display good judgement when
-confronted with an unrenderable character (which is distinct from an
-unknown EE<lt>thing> sequence that the parser couldn't resolve to
-anything, renderable or not). It is good practice to map Latin letters
-with diacritics (like "EE<lt>eacute>"/"EE<lt>233>") to the corresponding
-unaccented US-ASCII letters (like a simple character 101, "e"), but
-clearly this is often not feasible, and an unrenderable character may
-be represented as "?", or the like.
+レンダリングできない文字(これは、レンダリング出来るかどうかに関わらず
+パーサが解決できない、不明な EE<lt>thing> 並びとは異なります)に
+直面したときに良い判断を表示するのは個々の Pod 次第です。
+("EE<lt>eacute>"/"EE<lt>233>" のような)ダイアクリティカルマーク付きの
+Latin 文字を、(単純な文字 101, "e" のような)対応するアクセントなしの
+US-ASCII 文字にマッピングするのはよいプラクティスですが、明らかに
+これはしばしば実行不可能で、レンダリングできない文字は "?" のようなもので
+表現されるかもしれません(may)。
(EE<lt>233> から "e" のような) 健全なフォールバックのために、
Pod フォーマッタは、もし利用可能なら L<Pod::Escapes|Pod::Escapes> または
L<Text::Unidecode|Text::Unidecode> にある %Latin1Code_to_fallback テーブルを
つかってもかまいません(may)。
-(TBT)
=begin original
@@ -2180,7 +2179,7 @@
=end original
Pod フォーマッタは、レンダリングできない文字に出会ったときのリストを
-コメントや警告の形で記してもかまいません (may)。
+コメントや警告の形で記してもかまいません(may)。
=item *
@@ -2194,7 +2193,7 @@
=end original
EE<lt>...> は (他の EE<lt>...> および ZE<lt>> の中を除く) 任意の
-フォーマッティングコードの中に自由に現れることができます(may)。
+フォーマッティングコードの中に自由に現れてもかまいません(may)。
つまり、"XE<lt>The EE<lt>euro>1,000,000 Solution>" は、
"LE<lt>The EE<lt>euro>1,000,000 Solution|Million::Euros>" と同様
有効ということです。
@@ -2230,14 +2229,12 @@
含めることもできます; そして Pod は "SE<lt>foo IE<lt>barE<gt> baz>" という
コードを含むことができます; ここでそのようなコードでの「単なる空白」
(文字 32)は非分割空白を表現します。
-Pod
-parsers should consider supporting the optional parsing of "SE<lt>foo
-IE<lt>barE<gt> baz>" as if it were
-"fooI<NBSP>IE<lt>barE<gt>I<NBSP>baz", and, going the other way, the
-optional parsing of groups of words joined by NBSP's as if each group
-were in a SE<lt>...> code, so that formatters may use the
-representation that maps best to what the output format demands.
-(TBT)
+Pod パーサは、"SE<lt>foo IE<lt>barE<gt> baz>" を
+"fooI<NBSP>IE<lt>barE<gt>I<NBSP>baz" であるかのように、
+また NBSP で連結された単語のグループを それぞれのグループが
+SE<lt>...> コードで囲まれているかのようにパースするオプションに
+対応することを考慮するべきです(should); これによりフォーマッタは
+出力形式が要求する最良のものにマッピングされる表現を使えるかもしれません。
=item *
@@ -2744,7 +2741,7 @@
フォーマッタはリンクを解決する目的でマークアップを無視して、
以下のようにセクション名としてレンダリング可能な文字だけを使うことを
-選択できます(may):
+選択してもかまいません(may):
<h1><a name="About_the_-M_Operator">About the <code>-M</code>
Operator</h1>
@@ -2841,7 +2838,7 @@
=end original
"name|" 部分のない C<LE<lt>...E<gt>> コードでは、
-C<EE<lt>...E<gt>> と C<ZE<lt>E<gt>> のコードのみが使えます(may)。
+C<EE<lt>...E<gt>> と C<ZE<lt>E<gt>> のコードのみ使ってもかまいません(may)。
つまり、著者は "C<LE<lt>BE<lt>Foo::BarE<gt>E<gt>>" を使うべきではありません
(should not)。
@@ -2878,7 +2875,7 @@
=end original
Pod 著者は "LE<lt>text|name>" (および LE<lt>text|/"sec">)の "text" 部分には
-フォーマッティングコードを使ってもよい(may)ことに注意してください。
+フォーマッティングコードを使ってもかまわない(may)ことに注意してください。
=begin original
@@ -3014,7 +3011,7 @@
4 の場合と等価です。
Pod プロセッサは、I<indentlevel> が存在するけれども
C<m/\A(\d*\.)?\d+\z/> にマッチングする正数ではない場合に警告を
-出すかもしれません(may)。
+出してもかまいません(may)。
=item *
@@ -3152,14 +3149,11 @@
=end original
-An "=over" ... "=back" region containing no "=item" paragraphs at
-all, and containing only some number of
-ordinary/verbatim paragraphs, and possibly also some nested "=over"
-... "=back" regions, "=for..." paragraphs, and "=begin"..."=end"
-regions.
+"=item" 段落がまったくなく、いくつかの普通/そのままの段落と、
+おそらくはいくつかのネストした "=over" ... "=back" 領域、"=for..." 段落、
+"=begin"..."=end" 領域のみがある "=over" ... "=back" 領域。
Pod にあるこのような item なしの "=over" ... "=back" 領域は、HTML での
"<blockquote>...</blockquote>" 要素と等価な意味を持ちます。
-(TBT)
=back
@@ -3245,7 +3239,7 @@
=end original
"=over" ... "=back" 領域に見出しを含めることはできません。
-プロセッサはそのような見出しをエラーとして扱うことができます(may)。
+プロセッサはそのような見出しをエラーとして扱ってもかまいません(may)。
=item *
@@ -3400,15 +3394,14 @@
=end original
-That is, there should be (at least roughly) equal spacing between
-items as between paragraphs (although that spacing may well be less
-than the full height of a line of text). This leaves it to the reader
-to use (con)textual cues to figure out whether the "Qui dolorem
-ipsum..." paragraph applies to the "Quisquam Est" item or to all three
-items "Neque", "Porro", and "Quisquam Est". While not an ideal
-situation, this is preferable to providing formatting cues that may
-be actually contrary to the author's intent.
-(TBT)
+つまり、(少なくともおおよそは)アイテム間の空白は段落間の空白と
+同じであるべきです(should)(しかしこの空白はテキストの行の高さより
+少なくてもかまいません(may))。
+これにより、"Qui dolorem ipsum..." 段落が "Quisquam Est" アイテムのみと
+"Neque", "Porro", "Quisquam Est" の三つのアイテム全てのどちらに
+掛かるのかを判断する文脈上の手がかりを使えるように読者に残しておきます。
+理想的な状況ではありませんが、実際には著者の意図に反した
+フォーマッティングの手がかりを提供するよりは好ましいです。
=back
@@ -3527,11 +3520,11 @@
=end original
-This would signal to the parser that paragraphs in this begin...end
-region are subject to normal handling as ordinary/verbatim paragraphs
-(while still tagged as meant only for processors that understand the
-"biblio" identifier). The same effect could be had with:
-(TBT)
+これはパーサに、この begin...end 領域は普通の/そのままの段落として
+通常通り扱われることを前提としていることを示します (一方
+"biblio" 識別子を理解するプロセッサのみのためのものであるという
+意味も持ちます)。
+同じ効果は以下のようにしても得られます:
=for :biblio
Wirth, Niklaus. 1976. I<Algorithms + Data Structures =
@@ -3548,13 +3541,12 @@
=end original
-The ":" on these identifiers means simply "process this stuff
-normally, even though the result will be for some special target".
-I suggest that parser APIs report "biblio" as the target identifier,
-but also report that it had a ":" prefix. (And similarly, with the
-above "html", report "html" as the target identifier, and note the
-I<lack> of a ":" prefix.)
-(TBT)
+これらの識別子の ":" は単に「結果が特別なターゲットのためのものであっても、
+この内容を通常通り処理する」ことを意味します。
+私はパーサ API が "biblio" をターゲット識別子として報告するだけでなく、
+":" 接頭辞があることも報告することを推奨します。
+(そして同じように、上述の "html" では、"html" をターゲット識別子として、
+また ":" 接頭辞が I<ない> ことを報告します。)
=begin original
@@ -3694,17 +3686,16 @@
=end original
-The contents of the above "=begin :yetanotherformat" ...
-"=end :yetanotherformat" region I<aren't> data paragraphs, because
-the immediately containing region's identifier (":yetanotherformat")
-begins with a colon. In practice, most regions that contain
-data paragraphs will contain I<only> data paragraphs; however,
-the above nesting is syntactically valid as Pod, even if it is
-rare. However, the handlers for some formats, like "html",
-will accept only data paragraphs, not nested regions; and they may
-complain if they see (targeted for them) nested regions, or commands,
-other than "=end", "=pod", and "=cut".
-(TBT)
+上述の "=begin :yetanotherformat" ... "=end :yetanotherformat" 領域の
+内容はデータ段落 I<ではありません>; なぜなら 領域の識別子
+(":yetanotherformat") がコロンで始まっているからです。
+実際のところ、データ段落を含んでいる領域のほとんどはデータ段落
+I<のみ> を含んでいます; しかし、上述のようなネスティングは(稀で
+あるとしても)文法的にはPod として正当です。
+しかし、"html" のような一部の形式のハンドラは、データ段落のみをつけつけ、
+ネストした領域を受け付けません; また、ネストした領域や、
+"=end", "=pod", and "=cut" 以外のコマンドを(ターゲットとしている中に)
+発見すると、エラーとなるかもしれません。
=begin original
@@ -3756,12 +3747,10 @@
=end original
-There, the "=begin html"..."=end html" region is nested inside
-the larger "=begin :biblio"..."=end :biblio" region. Note that the
-content of the "=begin html"..."=end html" region is data
-paragraph(s), because the immediately containing region's identifier
-("html") I<doesn't> begin with a colon.
-(TBT)
+ここで、"=begin html"..."=end html" 領域は、より大きい
+"=begin :biblio"..."=end :biblio" 領域の内側にネストしています。
+"=begin html"..."=end html" 領域の内容はデータ段落です; なぜなら
+直接含んでいる領域の識別子 ("html") はコロンで始まって I<いない> からです。
=begin original
@@ -3777,16 +3766,13 @@
=end original
-Pod parsers, when processing a series of data paragraphs one
-after another (within a single region), should consider them to
-be one large data paragraph that happens to contain blank lines. So
-the content of the above "=begin html"..."=end html" I<may> be stored
-as two data paragraphs (one consisting of
-"<img src='wirth_spokesmodeling_book.png'>\n"
-and another consisting of "<hr>\n"), but I<should> be stored as
-a single data paragraph (consisting of
-"<img src='wirth_spokesmodeling_book.png'>\n\n<hr>\n").
-(TBT)
+Pod パーサは、(一つの領域に含まれた)連続したデータ段落を処理するときには、
+たまたま空行を含んでいる一つの大きなデータ段落として考えるべきです(should)。
+それで上述の "=begin html"..."=end html" の内容は二つのデータ段落
+(一つは "<img src='wirth_spokesmodeling_book.png'>\n" で、もう一つは
+"<hr>\n") として保管しても I<かまいません> が(may)、一つの大きな
+データ段落 ("<img src='wirth_spokesmodeling_book.png'>\n\n<hr>\n") として
+保管される I<べき> です(should)。
=begin original
@@ -3985,7 +3971,7 @@
=begin meta
Translate: SHIRAKATA Kentaro <argra****@ub32*****>
-Status: in progress
+Status: completed
=end meta