argra****@users*****
argra****@users*****
2012年 8月 18日 (土) 16:59:08 JST
Index: docs/perl/5.12.1/perlpodspec.pod
diff -u docs/perl/5.12.1/perlpodspec.pod:1.14 docs/perl/5.12.1/perlpodspec.pod:1.15
--- docs/perl/5.12.1/perlpodspec.pod:1.14 Wed Aug 1 07:04:37 2012
+++ docs/perl/5.12.1/perlpodspec.pod Sat Aug 18 16:59:08 2012
@@ -1399,14 +1399,13 @@
もし層なら、パーサはこのファイルが UTF-8 で、そのファイルの全ての
最上位ビットが立った並びが UTF-8 であると結論づけてもかまいません(may)。
さもなければパーサはそのファイルを Latin-1 として扱うべきです (should)。
-In the unlikely circumstance that the first highbit
-sequence in a truly non-UTF-8 file happens to appear to be UTF-8, one
-can cater to our heuristic (as well as any more intelligent heuristic)
-by prefacing that line with a comment line containing a highbit
-sequence that is clearly I<not> valid as UTF-8. A line consisting
-of simply "#", an e-acute, and any non-highbit byte,
-is sufficient to establish this file's encoding.
-(TBT)
+真に 非 UTF-8 のファイルの最初の最上位ビットが立った並びがたまたま
+UTF-8 に見えるというのはありそうにない状況なので、明確に UTF-8 として
+有効 I<ではない>、最上位ビットが立った並びを含むコメント行を置くことで
+我々のヒューリスティック(およびさらに賢いヒューリスティック)を
+満たすことができます。
+単なる "#"、鋭アクセント e、最上位ビットが立っていないバイト、からなる
+行は、このファイルのエンコーディングを決定するのに十分です。
=for comment
If/WHEN some brave soul makes these heuristics into a generic
@@ -1524,14 +1523,11 @@
Pod パーサは警告やエラーメッセージ ("Unknown E code EE<lt>zslig>!") を
(STDERR に print するか C<warn> や C<carp> を使うか C<die> や C<croak> を
使うかに関わらず) STDERR に出力しても I<かまいません> (may) が、
-but I<must> allow
-suppressing all such STDERR output, and instead allow an option for
-reporting errors/warnings
-in some other way, whether by triggering a callback, or noting errors
-in some attribute of the document object, or some similarly unobtrusive
-mechanism -- or even by appending a "Pod Errors" section to the end of
-the parsed form of the document.
-(TBT)
+そのような全ての STDERR 出力を抑制して、代わりに、コールバックを
+引き起こすことによってか、エラーを文書オブジェクトの何らかの属性または
+同様の控えめな機構によって記録するか、あるいは文書のパースされた形式の
+末尾に "Pod Errors" 節を追加する方法でも、何らかの他の方法でエラー/警告を
+報告するためのオプションをI<認めなければなりません>(must)。
=item *
@@ -1573,16 +1569,15 @@
段落 (つまり、そのままの段落は I<含みません> が、通常の段落および
"=head1" のようなレンダリングされるテキストを出力するコマンド段落を
I<含みます>)では、リテラルな空白は一般的に「重要でない」と
-考えられるべきです(should);
-in that one literal space has the same meaning as any
-(nonzero) number of literal spaces, literal newlines, and literal tabs
-(as long as this produces no blank lines, since those would terminate
-the paragraph). Pod parsers should compact literal whitespace in each
-processed paragraph, but may provide an option for overriding this
-(since some processing tasks do not require it), or may follow
-additional special rules (for example, specially treating
-period-space-space or period-newline sequences).
-(TBT)
+考えられるべきです(should); 一つのリテラルな空白は任意の(非 0 の)
+数のリテラルな空白、リテラルな改行、リテラルなタブは
+(これにより空行(これは段落の終わりになるので)を出力しない限り)、
+同じ意味になります。
+Pod パーサはそれ園れの処理された段落でのリテラルな空白を
+詰めるべきです(should)が、(いくつかの処理タスクはこれを必要としないので)、
+これを上書きするオプションを提供してもかまいません(may)し、
+追加の特殊ルール(例えば、ピリオド-空白-空白やピリオド-改行の並びを
+特別扱いするなど)に従ってもかまいません(may)。
=item *
@@ -1643,17 +1638,16 @@
=end original
-Pod フォーマッタは、Perl コードの単語が行をまたがないように
-合理的な努力を行うべきです(should)。
-For example, "Foo::Bar" in some
-formatting systems is seen as eligible for being broken across lines
-as "Foo::" newline "Bar" or even "Foo::-" newline "Bar". This should
-be avoided where possible, either by disabling all line-breaking in
-mid-word, or by wrapping particular words with internal punctuation
-in "don't break this across lines" codes (which in some formats may
-not be a single code, but might be a matter of inserting non-breaking
-zero-width spaces between every pair of characters in a word.)
-(TBT)
+Pod フォーマッタは、Perl コードの単語が行をまたがないように合理的な努力を
+行うべきです(should)。
+例えば、一部のフォーマッティングシステムでの"Foo::Bar" は、
+"Foo::" 改行 "Bar" や、"Foo::-" 改行 "Bar" のように行をまたいで
+分割しても有効です。
+これは、可能なところでは、単語の途中での全ての行分割を無効にするか、
+特定の単語を「これは行をまたがない」コードの内部的な句読点
+(一部のフォーマットでは単一のコードではなく、非分割ゼロ幅空白を単語の文字の
+それぞれの組の間に挿入するという形かもしれません)で包むことで
+防ぐべきです(should)。
=item *
@@ -1684,11 +1678,10 @@
Pod パーサは、デフォルトでは、通常の段落とそのままの段落の末尾の
改行を、フォーマッタに渡す前に削除するべきです(should)。
-For example, while the paragraph you're reading now
-could be considered, in Pod source, to end with (and contain)
-the newline(s) that end it, it should be processed as ending with
-(and containing) the period character that ends this sentence.
-(TBT)
+例えば、今読み込んでいる段落が Pod ソースでは空行を含んでいて、
+それで終わっていると考えられる一方、
+この文を終わらせるピリオド文字を含んでいて、それで終わっているかのように
+処理するべきです(should)。
=item *
@@ -1726,8 +1719,8 @@
=end original
-Pod パーサは、連続したそのままの段落を処理するときには、
-たまたま空行を含んでいる大きな一つのそのままの段落として扱うべきです(should)。
+Pod パーサは、連続したそのままの段落を処理するときには、たまたま空行を
+含んでいる大きな一つのそのままの段落として扱うべきです(should)。
つまり、以下のような、空行を挟んだ 2 つの行は:
use Foo;
@@ -1753,8 +1746,8 @@
=end original
-これはイベントベースの Pod パーサを実装するには厄介すぎるかもしれない
-一方、パース木を返すパーサにとっては直感的です。
+これはイベントベースの Pod パーサを実装するには厄介すぎるかもしれない一方、
+パース木を返すパーサにとっては直感的です。
=item *
@@ -1918,15 +1911,14 @@
Pod パーサは、不明な "EE<lt>I<identifier>>" コードに出会ったとき、
(少なくともデフォルトでは)単にから文字列と置き換えるべきではなく
(should not)、リテラル文字 E、小なり、I<identifier>、大なりで構成される
-文字列として渡されるかもしれません(may)。
-Or Pod parsers may offer the
-alternative option of processing such unknown
-"EE<lt>I<identifier>>" codes by firing an event especially
-for such codes, or by adding a special node-type to the in-memory
-document tree. Such "EE<lt>I<identifier>>" may have special meaning
-to some processors, or some processors may choose to add them to
-a special error report.
-(TBT)
+文字列として渡されたものとしてもかまいません(may)。
+または、Pod パーサは、そのような不明な "EE<lt>I<identifier>>" コードを、
+特にそのようなコードのためのイベントを起動するか、メモリ内文書木に
+特別なノード型を追加することで処理する代替オプションを
+提供してもかまいません(may)。
+そのような "EE<lt>I<identifier>>" は一部のプロセッサでは特別な意味が
+あるかもしれませんし(may)、一部のプロセッサはこれを特別なエラー報告に
+加えることを選ぶかもしれません(may)。
=item *
@@ -2033,13 +2025,11 @@
このような「Unicode から何か」へのマッピングはおそらく一般的な
出力形式については既に広く利用可能です。
(このようなマッピングは不完全かも知れません!
-Implementers
-are not expected to bend over backwards in an attempt to render
-Cherokee syllabics, Etruscan runes, Byzantine musical symbols, or any
-of the other weird things that Unicode can encode.) And
-if a Pod document uses a character not found in such a mapping, the
-formatter should consider it an unrenderable character.
-(TBT)
+実装者は、チェロキー音節、エルトリア語のルーン、ビザンツの音楽記号、
+その他 Unicode がエンコード出来る変なものをレンダリングしようとして
+最大の努力をすることを想定しません。)
+そして、Pod 文書がこのようなマッピングにない文字が使うと、
+フォーマッタはこれをレンダリングできない文字として扱うべきです(should)。
=item *
@@ -2064,15 +2054,12 @@
ターゲット形式のエスケープへのマッピングに関する、満足できる既に存在する
表(例えば Unicode 文字から *roff エスケープへのまともな表) を
発見できない場合、そのような表を構築する必要があります。
-If you are in this circumstance, you should begin with the
-characters in the range 0x00A0 - 0x00FF, which is mostly the heavily
-used accented characters. Then proceed (as patience permits and
-fastidiousness compels) through the characters that the (X)HTML
-standards groups judged important enough to merit mnemonics
-for. These are declared in the (X)HTML specifications at the
-www.W3.org site. At time of writing (September 2001), the most recent
-entity declaration files are:
-(TBT)
+もしこのような状況にいるのなら、範囲 0x00A0 - 0x00FF の文字から
+始めるべきです; これはほとんどアクセント付きの文字が使われます。
+それから(忍耐が許して潔癖症が強いるなら)、(X)HTML 標準グループが、
+省略形を作る価値があるほど重要であると判断した文字に進みます。
+これらは www.W3.org のサイトの (X)HTML 定義で宣言されています。
+これを書いている時点(2001 年 9 月)で、もっとも新しい実体定義ファイルは:
http://www.w3.org/TR/xhtml1/DTD/xhtml-lat1.ent
http://www.w3.org/TR/xhtml1/DTD/xhtml-special.ent
@@ -2087,11 +2074,10 @@
=end original
-Then you can progress through any remaining notable Unicode characters
-in the range 0x2000-0x204D (consult the character tables at
-www.unicode.org), and whatever else strikes your fancy. For example,
-in F<xhtml-symbol.ent>, there is the entry:
-(TBT)
+それから範囲 0x2000-0x204D (www.unicode.org にある文字表を
+参照してください)の残りの注目するべき Unicode 文字と、あなたの
+興味を引いたものなんでもに進んでください。
+例えば、F<xhtml-symbol.ent> には、以下のようなエントリがあります:
<!ENTITY infin "∞"> <!-- infinity, U+221E ISOtech -->
@@ -2107,13 +2093,12 @@
=end original
"infin" から文字 "\x{221E}" へのマッピングは(できれば)既に Pod パーサによって
-扱われている一方、このファイルにこの文字があるということは
-it's reasonably important enough to
-include in a formatter's table that maps from notable Unicode characters
-to the codes necessary for rendering them.
+扱われている一方、このファイルにこの文字があるということは、
+注目すべき Unicode 文字からそれをレンダリングするために必要なコードへの
+マッピングを行うフォーマッタの表に含めることが十分に合理的なほど
+重要であることを意味します。
それで、例えば Unicode-to-*roff のマッピングのためには、これはエントリに
値します:
-(TBT)
"\x{221E}" => '\(in',
@@ -2126,11 +2111,10 @@
=end original
-It is eagerly hoped that in the future, increasing numbers of formats
-(and formatters) will support Unicode characters directly (as (X)HTML
-does with C<∞>, C<∞>, or C<∞>), reducing the need
-for idiosyncratic mappings of Unicode-to-I<my_escapes>.
-(TBT)
+将来、より多くの形式(とフォーマッタ)が((X)HTML が C<∞>, C<∞>,
+C<∞> で行うように) Unicode 文字を直接扱えるようになって、
+Unicode-to-I<私のエスケープ> への風変わりなマッピングの必要性が
+減少することが熱望されています。
=item *
@@ -2244,8 +2228,9 @@
Pod のレベルでは、どちらのコードもあり得ます: Pod は
(リテラル、"EE<lt>160>"、"EE<lt>nbsp>"という形で) NBSP 文字を
含めることもできます; そして Pod は "SE<lt>foo IE<lt>barE<gt> baz>" という
-コードを含むことができます; where "mere spaces" (character 32) in
-such codes are taken to represent non-breaking spaces. Pod
+コードを含むことができます; ここでそのようなコードでの「単なる空白」
+(文字 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
@@ -2268,14 +2253,14 @@
=end original
-Some processors may find that the C<SE<lt>...E<gt>> code is easiest to
-implement by replacing each space in the parse tree under the content
-of the S, with an NBSP. But note: the replacement should apply I<not> to
-spaces in I<all> text, but I<only> to spaces in I<printable> text. (This
-distinction may or may not be evident in the particular tree/event
-model implemented by the Pod parser.)
+一部のプロセッサは、C<SE<lt>...E<gt>> コードを最も簡単に実装するには
+S の内容のパース木の中にあるそれぞれの空白を NBSP に置き換えることで
+あることを発見するかもしれません。
+しかし注意してください: 変換は I<全て> のテキストの空白では I<なく>、
+I<表示される> テキストの空白 I<のみ> に適用するべきです(should)。
+(この区別は、その Pod パーサによって実装されている特定のツリー/イベント
+モデルによって明らかかもしれませんしそうではないかもしれません。)
例えば、次のような普通ではない場合を考えます:
-(TBT)
S<L</Autoloaded Functions>>
@@ -2380,14 +2365,12 @@
=end original
-These signal to a formatter that if it is to hyphenate "sigaction"
-or "manuscript", then it should be done as
-"sig-I<[linebreak]>action" or "manu-I<[linebreak]>script"
-(and if it doesn't hyphenate it, then the C<EE<lt>shyE<gt>> doesn't
-show up at all). And if it is
-to hyphenate "Jarkko" and/or "Hietaniemi", it can do
-so only at the points where there is a C<EE<lt>shyE<gt>> code.
-(TBT)
+これらは、もし "sigaction" や "manuscript" をハイフネーションするときは、
+"sig-I<[linebreak]>action" や "manu-I<[linebreak]>script" として
+行うべき(should)であることを示します(そしてもし
+ハイフネーションしないなら、 C<EE<lt>shyE<gt>> は全く現れません)。
+そして "Jarkko" や "Hietaniemi" をハイフネーションするときは、
+C<EE<lt>shyE<gt>> コードがある場所でのみ行えます。
=begin original
@@ -2971,18 +2954,18 @@
=end original
-Previous versions of perlpod allowed for a C<LE<lt>sectionE<gt>> syntax (as in
-C<LE<lt>Object AttributesE<gt>>), which was not easily distinguishable from
-C<LE<lt>nameE<gt>> syntax and for C<LE<lt>"section"E<gt>> which was only
-slightly less ambiguous. This syntax is no longer in the specification, and
-has been replaced by the C<LE<lt>/sectionE<gt>> syntax (where the slash was
-formerly optional). Pod parsers should tolerate the C<LE<lt>"section"E<gt>>
-syntax, for a while at least.
+以前のバージョンの perlpod では(C<LE<lt>Object AttributesE<gt>> のような)
+C<LE<lt>sectionE<gt>> 文法を許していました; これは
+C<LE<lt>nameE<gt>> 文法と簡単には区別できず、
+C<LE<lt>"section"E<gt>> とはほんの少しだけしか曖昧性が少なくなりません。
+この文法は現在の仕様には含まれず、C<LE<lt>/sectionE<gt>> 文法で
+置き換えられました(以前はスラッシュはオプションでした)。
+Pod パーサは、少なくともしばらくの間は、C<LE<lt>"section"E<gt>> 文法を
+許容するべきです(should)。
C<LE<lt>nameE<gt>> を C<LE<lt>sectionE<gt>> と区別するための推奨される
ヒューリスティックは、もし空白が含まれていれば、それは I<section> と
いうことです。
Pod プロセッサはこれらの廃止予定の文法に関して警告するべきです(should)。
-(TBT)
=back
@@ -3522,12 +3505,11 @@
=end original
さらなる例: これを書いている時点で、"biblio" 識別子には対応していませんが、
-but suppose some processor were written to recognize it as
-a way of (say) denoting a bibliographic reference (necessarily
-containing formatting codes in ordinary paragraphs). The fact that
-"biblio" paragraphs were meant for ordinary processing would be
-indicated by prefacing each "biblio" identifier with a colon:
-(TBT)
+一部のプロセッサがこれを(例えば、必然的に通常の段落に
+フォーマッティングコードを含んでいる)参考文献を示すものとして認識する
+ように書かれているとします。
+"biblio" 段落が通常通り処理されるということは、"biblio" 識別子にコロンが
+付いていることで示されています:
=begin :biblio
@@ -3934,17 +3916,18 @@
=end original
-This latter is improper because when the "=end outer" command is seen, the
-currently open region has the formatname "inner", not "outer". (It just
-happens that "outer" is the format name of a higher-up region.) This is
-an error. Processors must by default report this as an error, and may halt
-processing the document containing that error. A corollary of this is that
-regions cannot "overlap". That is, the latter block above does not represent
-a region called "outer" which contains X and Y, overlapping a region called
-"inner" which contains Y and Z. But because it is invalid (as all
-apparently overlapping regions would be), it doesn't represent that, or
-anything at all.
-(TBT)
+"=end outer" コマンドが現れたとき、現在開いている領域のフォーマット名は
+"outer" ではなく "inner" なので、これは不適切です。
+("outer" はより高いレベルの領域のフォーマット名です。)
+これはエラーです。
+プロセッサはデフォルトではこれをエラーと報告しなければならず(must)、
+エラーを含む文書の処理を停止してもかまいません(may)。
+ここから導かれる結論は、領域は「重複」できないということです。
+つまり、上述の後者のブロックは X と Y を含む "outer" と呼ばれる領域と、
+Y と Z を含む "inner" と呼ばれる重複した領域を表現しているわけではないと
+いうことです。
+しかし、これは (明らかに重複している領域全てのように) 不正なので、
+これは表現されなかったり、あるいはまったく表示されなかったりします。
=begin original
Index: docs/perl/5.12.1/perlunicode.pod
diff -u docs/perl/5.12.1/perlunicode.pod:1.1 docs/perl/5.12.1/perlunicode.pod:1.2
--- docs/perl/5.12.1/perlunicode.pod:1.1 Sat Jun 16 03:09:33 2012
+++ docs/perl/5.12.1/perlunicode.pod Sat Aug 18 16:59:08 2012
@@ -316,10 +316,9 @@
文字セマンティクスが適用されます。
そうでなければ、バイトセマンティクスが有効になります。
C<bytes> プラグマは Unicode データに対してバイトセマンティクスを
-強制するときに使うと良いでしょう、and the C<use feature
-'unicode_strings'> pragma to force Unicode semantics on byte data (though in
-5.12 it isn't fully implemented).
-(TBT)
+強制するときに使って、C<use feature 'unicode_strings'> プラグマを
+バイトデータで Unicode セマンティクスを強制するために使えます
+(しかし 5.12 ではこれは完全には実装されていません)。
=begin original
@@ -335,8 +334,8 @@
保ちます。
これは驚きを引き起こすかもしれません: 後述する L</BUGS> を
参照してください。
-You can choose to be warned when this happens. See L<encoding::warnings>.
-(TBT)
+これが起きたときに警告されるようにすることを選択できます。
+L<encoding::warnings> を参照してください。
=begin original
@@ -572,9 +571,7 @@
あったときに使用します。
C<uc()> や展開文字列中の C<\U> は大文字に変換し、C<ucfirst> や
展開文字列中の C<\u> はその言語で区別されているときに
-タイトルケースに変換します (which is equivalent to uppercase in languages
-without the distinction)。
-(TBT)
+タイトルケースに変換します (これは、区別がない言語では大文字と等価です)。
=item *
@@ -2152,9 +2149,8 @@
=end original
(真剣なハッカー専用)
-The above means you have to furnish a complete
-mapping; you can't just override a couple of characters and leave the rest
-unchanged.
+上述したことは、完全なマッピングを提供する必要があるということです;
+一部の文字を上書きして、残りを変更せずに残しておくことは出来ません。
C<$Config{privlib}>/F<unicore/To/> というディレクトリに全てのマッピングが
あります。
マッピングデータはヒアドキュメントとして返され、C<utf8::ToSpecFoo> は
@@ -2163,7 +2159,6 @@
そのディレクトリで見つけることのできる "Digit" と "Fold" のマッピングは
ユーザーがダイレクトにアクセスできず、C<Unicode::UCD> モジュールを使うか
大小文字を無視してマッピングします("Fold" マッピングが使われているとき)。
-(TBT)
=begin original
@@ -2639,10 +2634,10 @@
Unicode 文字でないということによって、C<0xFF 0xFE> という並びは紛れなく
"リトルエンディアンフォーマットの BOM" であって
"ビッグエンディアンの C<U+FFFE>" とはならないのです。
-(Actually, C<U+FFFE> is legal for use by your program, even for
-input/output, but better not use it if you need a BOM. But it is "illegal for
-interchange", so that an unsuspecting program won't get confused.)
-(TBT)
+(実際のところ、C<U+FFFE> は、あなたのプログラムで使う分には、たとえ
+入出力のためでも、合法です; しかし、BOM が必要な場合には使わないでください。
+しかしこれは "illegal for interchange" なので、疑うことを知らない
+プログラムを混乱させてはいけません。)
=item *