argra****@users*****
argra****@users*****
2012年 7月 8日 (日) 17:53:21 JST
Index: docs/perl/5.14.1/perllocale.pod
diff -u docs/perl/5.14.1/perllocale.pod:1.1 docs/perl/5.14.1/perllocale.pod:1.2
--- docs/perl/5.14.1/perllocale.pod:1.1 Sun Jun 24 03:28:31 2012
+++ docs/perl/5.14.1/perllocale.pod Sun Jul 8 17:53:20 2012
@@ -20,9 +20,9 @@
=end original
-Locales these days have been mostly been supplanted by Unicode, but Perl
-continues to support them. See L</Unicode and UTF-8> below.
-(TBT)
+最近ではロケールはほとんど Unicode に取って代わられていますが、
+Perl はこれに対応し続けています。
+後述の L</Unicode and UTF-8> を参照してください。
=begin original
@@ -244,16 +244,15 @@
=end original
-The current locale is set at execution time by
-L<setlocale()|/The setlocale function> described below. If that function
-hasn't yet been called in the course of the program's execution, the
-current locale is that which was determined by the L<"ENVIRONMENT"> in
-effect at the start of the program, except that
-C<L<LC_NUMERIC|/Category LC_NUMERIC: Numeric Formatting>> is always
-initialized to the C locale (mentioned under L<Finding locales>).
-If there is no valid environment, the current locale is undefined. It
-is likely, but not necessarily, the "C" locale.
-(TBT)
+現在のロケールは、後述する
+L<setlocale()|/The setlocale function> 関数によって実行時に設定されます。
+プログラム実行の過程でこの関数がまだ呼び出されていないとき、現在の
+ロケールはプログラムの開始時に有効な L<"ENVIRONMENT"> によって
+決定されますが、
+C<L<LC_NUMERIC|/Category LC_NUMERIC: Numeric Formatting>> は
+常に C ロケールに初期化されます (L<Finding locales> で言及しています)。
+有効な環境がない場合、現在のロケールは未定義となります。
+これは、おそらく "C" ロケールになりますが、かならずそうとは限りません。
=begin original
@@ -261,8 +260,7 @@
=end original
-The operations that are affected by locale are:
-(TBT)
+ロケールによって影響を受ける処理は:
=over 4
@@ -614,9 +612,10 @@
プログラム起動時の B<デフォルトのロケール> です
(I<デフォルトの> デフォルトロケールです)。
その言語は (アメリカ)英語であり、そのキャラクターセットは ASCII となります。
-B<Warning>. The C locale delivered by some vendors may not
-actually exactly match what the C standard calls for. So beware.
-(TBT)
+B<警告>。
+一部のベンダによって提供されている C ロケールは実際には C 標準が要求している
+ものに正確に一致していないかもしれません。
+注意してください。
=begin original
@@ -2368,10 +2367,11 @@
=end original
-The support of Unicode is new starting from Perl version 5.6, and more fully
-implemented in version 5.8 and later. See L<perluniintro>. Perl tries to
-work with both Unicode and locales--but of course, there are problems.
-(TBT)
+Unicode 対応は Perl バージョン 5.6 から始まり、バージョン 5.8 以降でより
+完全に実装されました。
+L<perluniintro> を参照してください。
+Perl は Unicode とロケールを同時に動作させようとします -- しかし、
+問題があります。
=begin original
@@ -2383,12 +2383,11 @@
=end original
-Perl does not handle multi-byte locales, such as have been used for various
-Asian languages, such as Big5 or Shift JIS. However, the increasingly common
-multi-byte UTF-8 locales, if properly implemented, tend to work
-reasonably well in Perl, simply because both they and Perl store
-characters that take up multiple bytes the same way.
-(TBT)
+Perl は、Big5 や Shift JIS のような、様々なアジア言語で使われているような
+マルチバイトロケールは扱いません。
+しかし、徐々に一般的になっているマルチバイトロケールは、適切に
+実装されていれば、Perl で十分にうまく動く蛍光があります; 単にこれらと
+Perl はマルチバイトになる文字を同じ方法で保管するからです。
=begin original
@@ -2404,16 +2403,17 @@
=end original
-Perl generally takes the tack to use locale rules on code points that can fit
-in a single byte, and Unicode rules for those that can't (though this wasn't
-uniformly applied prior to Perl 5.14). This prevents many problems in locales
-that aren't UTF-8. Suppose the locale is ISO8859-7, Greek. The character at
-0xD7 there is a capital Chi. But in the ISO8859-1 locale, Latin1, it is a
-multiplication sign. The POSIX regular expression character class
-C<[[:alpha:]]> will magically match 0xD7 in the Greek locale but not in the
-Latin one, even if the string is encoded in UTF-8, which would normally imply
-Unicode semantics. (The "U" in UTF-8 stands for Unicode.)
-(TBT)
+Perl は一般的にシングルバイトに合う符号位置のロケールルールを使い、
+とり、それが出来ないときは Unicode のルールを使う方針をとります
+(しかしこれは Perl 5.14 以前には一様に適用されません)。
+これは UTF-8 でないロケールでの多くの問題を防ぎます。
+ロケールがギリシャ語の ISO8859-7 であると仮定します。
+0xD7 の文字は capital Chi です。
+しかし Latin1 である ISO8859-1 ロケールでは、これは乗算記号です。
+POSIX 正規表現文字クラス C<[[:alpha:]]> はマジカルに、ギリシャ語ロケールでは
+0xD7 にマッチングするけれども Latin ロケールではマッチングしません;
+たとえ文字列が、通常は Unicode の意味論を暗示する UTF-8 で
+エンコードされていてもです (UTF-8 の "U" は Unicode から来ています。)
=begin original
@@ -2428,15 +2428,16 @@
=end original
-However, there are places where this breaks down. Certain constructs are
-for Unicode only, such as C<\p{Alpha}>. They assume that 0xD7 always has its
-Unicode meaning (or the equivalent on EBCDIC platforms). Since Latin1 is a
-subset of Unicode and 0xD7 is the multiplication sign in both Latin1 and
-Unicode, C<\p{Alpha}> will never match it, regardless of locale. A similar
-issue occurs with C<\N{...}>. It is therefore a bad idea to use C<\p{}> or
-C<\N{}> under C<use locale>--I<unless> you can guarantee that the locale will
-be a ISO8859-1 or UTF-8 one. Use POSIX character classes instead.
-(TBT)
+しかし、これを分解してみます。
+C<\p{Alpha}> のような一部の構造は Unicode のみです。
+これらは 0xD7 は常に Unicode での意味 (あるいは EBCDIC プラットフォームでの
+等価物) を持つと仮定します。
+Latin1 は Unicode の部分集合でであり、0xD7 は Latin1 と Unicode の両方で
+乗算記号なので、ロケールに関わらず C<\p{Alpha}> はマッチングしません。
+同じような問題は C<\N{...}> で起こります。
+従って C<use locale> で C<\p{}> や C<\N{}> を使うのは悪い考えです --
+ロケールが ISO8859-1 または UTF-8 であることを I<保証できないかぎり> です。
+代わりに POSIX 文字クラスを使ってください。
=begin original
@@ -2454,18 +2455,17 @@
=end original
-The same problem ensues if you enable automatic UTF-8-ification of your
-standard file handles, default C<open()> layer, and C<@ARGV> on non-ISO8859-1,
-non-UTF-8 locales (by using either the B<-C> command line switch or the
-C<PERL_UNICODE> environment variable; see L<perlrun>).
-Things are read in as UTF-8, which would normally imply a Unicode
-interpretation, but the presence of a locale causes them to be interpreted
-in that locale instead. For example, a 0xD7 code point in the Unicode
-input, which should mean the multiplication sign, won't be interpreted by
-Perl that way under the Greek locale. Again, this is not a problem
-I<provided> you make certain that all locales will always and only be either
-an ISO8859-1 or a UTF-8 locale.
-(TBT)
+同じ問題は、(B<-C> コマンドラインオプションか C<PERL_UNICODE> 環境変数を
+使って (L<perlrun> を参照してください)) ISO-8859-1 でも UTF-8 でもない
+ロケールの標準ファイルハンドル、デフォルト C<open()> 層、C<@ARGV> の
+自動 UTF-8 化を有効にしている場合にも起こります。
+これらは UTF-8 として読み込まれ、普通は暗黙に Unicode として
+解釈されますが、ロケールの存在によって、代わりにそのロケールとして
+解釈されます。
+例えば、Unicode 入力での符号位置 0xD7 は、乗算記号を意味するべきですが、
+ギリシャ語ロケールでは Perl はそのようには解釈しません。
+これもまた、全てのロケールが常に ISO-8859-1 か UTF-8 ロケールの
+どちらかだけであることが I<確実なら> 問題ではありません。
=begin original
@@ -2481,16 +2481,14 @@
=end original
-Vendor locales are notoriously buggy, and it is difficult for Perl to test
-its locale-handling code because this interacts with code that Perl has no
-control over; therefore the locale-handling code in Perl may be buggy as
-well. But if you I<do> have locales that work, using them may be
-worthwhile for certain specific purposes, as long as you keep in mind the
-gotchas already mentioned. For example, collation runs faster under
-locales than under L<Unicode::Collate> (albeit with less flexibility), and
-you gain access to such things as the local currency symbol and the names
-of the months and days of the week.
-(TBT)
+ベンダロケールはバグ持ちで悪名高く、これは Perl が制御できないコードと
+相互作用するので、Perl がロケール操作コードをテストするのは困難です;
+従って Perl のロケール操作コードは同様にバグ持ちかもしれません。
+しかし動作するロケールが I<ある> なら、それを使うことは、既に言及した
+コツを心に留めている限りは、ある種の特定の用途には価値があるかもしれません。
+例えば、ロケール下での照合は(柔軟性は少ないですが)
+L<Unicode::Collate> 下でのロケールよりも高速に実行され、
+ローカルな通貨記号、月や週の名前のようなものへのアクセスを得ます。
=head1 BUGS
@@ -2552,7 +2550,7 @@
Translate: KIMURA Koichi
Update: SHIRAKATA Kentaro <argra****@ub32*****> (5.8.8-)
-Status: in progress
+Status: completed
=end meta