php/doc-ja

Japanese translation of the PHP documentation

doc-ja's Issues

textlint の導入検討

現状は複数名でアクティブにメンテナンスしている状態ではないのですぐには必要ないが、表記ゆれを検知/修正するツールとしてtextlint の導入を必要に応じて検討する。

活用例: https://buildersbox.corp-sansan.com/entry/2022/04/18/110000

PCRE の \x{XXXX} に関する記述について、英語版の sync が漏れている

https://twitter.com/masakielastic/status/1643768348201873408

表記揺れ: サーバー / サーバ

#21, #23, #24, #26, #42, #44 があったため、こちらの表記揺れについても Issue を発行しました。
対応不要であればお手数ですがクローズをお願いいたします。

kangetsu@ubuntu20:~/work/doc-ja$ grep -rn サーバー ./ | wc -l
1232
kangetsu@ubuntu20:~/work/doc-ja$ grep -rn サーバ[^ー] ./ | wc -l
279
kangetsu@ubuntu20:~/work/doc-ja$ 

textlint を使うと表記揺れなどについてルールを設けることができるので、必要であれば導入を検討してもよいかもしれません。
活用例: https://buildersbox.corp-sansan.com/entry/2022/04/18/110000

static 関連 の日本語訳を統一する

static variable を「静的変数」と訳している箇所が多くあるが、「static 変数」と訳している箇所もある。
これを後者に置き換える。

表記揺れ: ビルトイン関数 / 組み込み関数

先人は「ビルトイン関数」としているが、「組み込み関数」となっている箇所がある。前者に統一する方向で。

function.define.php 誤訳

From manual page: https://php.net/function.define

---

英語文
`
Warning

Defining case-insensitive constants is deprecated as of PHP 7.3.0.
`

誤
大文字小文字を区別 する 定数を定義するのは、PHP 7.3.0 以降では推奨されなくなりました。

正
大文字小文字を区別 しない 定数を定義するのは、PHP 7.3.0 以降では推奨されなくなりました。

表記揺れ: 参照して下さい / 参照下さい

「XXXX を見て下さい」という意味の訳に、以下の2種類が混在している。
「ください」についても、漢字の「下さい」と「ください」が混在している。

• 参照して下さい
• 参照ください

表記揺れ: オーバーライド / 上書き

継承の文脈で使われる override の訳が、「オーバーライド」「上書き」の2つでブレているので、どちらかに統一する。

Typo at /ldap.examples-controls.php

doc-ja/reference/ldap/examples.xml

Line 91 in ec8e6e4

echo "Ppolicy error code: ".$value['error'];

this was particaly fixed via commit bcac9e9

極めてどうでも良いが

From manual page: https://php.net/function.imagecreatefromstring

---

Not "認識できない書式のデータを受け取った場合に、 imagecreatefromstring() は E_WARNING レベルのエラーを発酵します。 " but "認識できない書式のデータを受け取った場合に、 imagecreatefromstring() は E_WARNING レベルのエラーを発行します。" in Japanese site.

DOMDocumentFragment::appendXML generates a warning appending a data including "&".

From manual page: https://php.net/domdocumentfragment.appendxml

---

DOMDocumentFragment::appendXML generates a warning in my environment (PHP 8.1.6 with Windows 10)
when appending an "a" tag data including multiple queries (including "&") as a link destination.

Try below.

$doc = new DOMDocument();
$doc->loadHTML('links', LIBXML_NOERROR);
$f = $doc->createDocumentFragment();
$data0 = 'Foo Manual';
$data1 = 'Foo Manual';
$data2 = 'Foo Manual';
$f->appendXML($data0); // no error
$f->appendXML($data1); // no error
$f->appendXML($data2); // warning

echo $doc->saveHTML();

statically call の日本語訳

static メソッドや static プロパティは、スコープ定義演算子で以下のようにアクセスする

<?php

class Test {
    public static int $prop = 1;
    public static function testMethod() : int { return 2; }
};

var_dump(Test::$prop);     //  1
var_dump(Test::testMethod());   //  2

上記の呼び方を statically call と呼んでいる箇所がかなりある。日本語版では「静的にコールする(呼び出す) 」と訳しているのだが、正直意味がわからない。静的にってどういうこと！？ そのまま statically を置き換えただけである。

これについては、 (インスタンス化せずに)スコープ定義演算子を使ってアクセスする という意味なので、適切なタイミングで置き換える。

mysli_driver/report-mode.xml: missing translation

The title of the third example isn't translated.

Relative callables の訳は直訳すると正しくない

https://www.php.net/manual/ja/migration82.deprecated.php#migration82.deprecated.core.relative-callables

Relative callables は、特定のクラスから見て、相対的な位置にあるメソッドを呼ぶ際の callable という意味である。これが PHP 8.2.0 からは deprecated になる。

sqlite3.openblob 誤字

From manual page: https://php.net/sqlite3.openblob

---

誤: BLOG
正: BLOB

誤: ストリームしロース
正: ストリームリソース

引数(arguments)とパラメータ の区別

「引数」と「パラメータ」は、関数やメソッドの文脈で混同されやすい。

• 「関数やメソッドを呼び出す時に渡す arguments」
• 「関数やメソッドに渡すべき値の仕様としての parameters」

これらがもし混同されている事例が確認された場合、この issue で対応する。

stream_isatty 関数が未訳

https://www.php.net/manual/ja/function.stream-isatty.php

htmlspecialchars 関連の関数で、`flags` パラメータのデフォルト値の説明に不整合がある

https://www.php.net/manual/ja/function.htmlspecialchars.php

PHP 8.1 で、htmlspecialchars 関連の関数のデフォルト値は、ENT_COMPAT から ENT_QUOTES | ENT_SUBSTITUTE に変更され、マニュアルにもそれが反映されている。

だが、flags パラメータのデフォルト値の説明は、以下のように ENT_QUOTES | ENT_SUBSTITUTE | ENT_HTML401 となっている。

(binary) キャストや b プレフィックスのサンプルは意味がないのではないか

https://www.php.net/manual/ja/language.types.type-juggling.php

現状のマニュアルには、上記のように何の処理も行われない b プレフィックスや、(string) キャストと等価なサンプルがいかにも意味があるように記述されており、ユーザー視点から混乱を招くという指摘がある

表記揺れ: serialize の対義語 -> デシリアライズ / アンシリアライズ

PHP Manual 日本語版における unserialize の訳語が、以下の2通りでブレており、どうするかが問題になる。

• アンシリアライズ
• デシリアライズ

まず、シリアライズされた PHP の値を復元する処理として、unserialize() というインターフェイスが存在する。一方、シリアライズの対義語として、deserialize という語も存在するので、PHP Manual では、上記の2つが表記揺れの形で存在する。

https://en.wikipedia.org/wiki/Serialization を見てもわかる通り、上記はどちらも正しい。よって、決めの問題であるかもしれないが、既存の文脈も一応見直し、修正を行う必要がある。

This process of serializing an object is also called marshalling an object in some situations.
The opposite operation, extracting a data structure from a series of bytes, is deserialization, 
(also called unserialization or unmarshalling).

SJIS-win などのエンコーディングが mb_list_encodings の一覧から消えているが、マニュアルには残っている

refs: php/php-src@e245985

• A) PHP 8.1 から、SJIS-win, SJIS-open, SJIS-ms は、 CP932 のエイリアスとして扱われるようになった
• B) A) のエンコーディングが、mb_list_encodings の出力から消えた
• C) だが、マニュアルには残っているので、修正すべき
  • migration guide も修正対象に含めるべきと考えられる
  • 但し、mbstring の関数でこれらのエンコーディングが使えなくなったわけではない
    • おそらくは mb_list_encodings の例だけをまずは修正することになると考えられる。

そもそも A) や B) が php-src 的に正しい修正かが判断できないので、まずは、日本語版の issue に記録しておく。
現状が追認されるようなら、英語版も含めたマニュアルそのものの修正も視野に入れる。

表記揺れ: 言語構造 / 言語構成要素

language construct の訳が揺れているので、「言語構造」で統一する

https://www.php.net/manual/ja/function.array.php
https://www.php.net/manual/ja/function.print.php

誤訳?: crc32() の警告文の一節

crc32() 関数のドキュメントにおける警告文中の一節について、誤訳ではないかと思われる箇所を発見したためご報告します。

原文 より引用:

Having 64bit installations also return negative integers for higher result values was considered but would break the hexadecimal conversion as negatives would get an extra 0xFFFFFFFF######## offset then. As hexadecimal representation seems to be the most common use case we decided to not break this even if it breaks direct decimal comparisons in about 50% of the cases when moving from 32 to 64bits.

2022-09-20 現在の日本語版 の対応箇所より引用:

64 ビット環境でも、戻り値が大きくなると負の整数を返すことが考えられます。 その場合は十六進変換がうまくいかないので、負の整数については オフセット 0xFFFFFFFF######## を与えます。 十六進表現は最もよく使われる形式なので、この処理が壊れないようにしました。 32 ビット環境から 64 ビット環境に移したときに ほぼ 50% の確率で十進形式での比較が失敗してしまいますが、 それよりも十六進表記のほうを優先したのです。

このうち「64 ビット環境でも、戻り値が大きくなると負の整数を返すことが考えられます」という部分は、少し上にある

PHP の整数型は符号付きで、多くの crc32 チェックサムは 32 ビットシステム上では負の整数になります。 しかし、64 ビット環境では crc32() の結果はすべて正の整数となります。

という文と矛盾しています。後者の文にあるように、64 ビット環境において、32 ビットの整数は必ず正になり、「戻り値が大きくなると負の整数を返す」ことはありません。

それを踏まえると、原文の "Having 64bit installations ... was considered" の部分は、「64 ビット環境でも、大きな戻り値に対して負の整数を返すことが検討されました」とするのがよいのではないでしょうか。

また、この次の文「その場合は十六進変換がうまくいかないので、負の整数については オフセット 0xFFFFFFFF######## を与えます」は、原文における "as" が、理由を表す節として訳されていないように思いました。

こちらについても、「しかしその場合、負の整数には余計な オフセット 0xFFFFFFFF######## が付くので、十六進変換が壊れてしまいます」とするとよいのではないでしょうか。

2点をまとめると、次のようになります:

64 ビット環境でも、大きな戻り値に対して負の整数を返すことが検討されました。 しかしその場合、負の整数には余計な オフセット 0xFFFFFFFF######## が付くので、十六進変換が壊れてしまいます。 十六進表現は最もよく使われる形式なので、この処理が壊れないようにしました。 32 ビット環境から 64 ビット環境に移したときに ほぼ 50% の確率で十進形式での比較が失敗してしまいますが、 それよりも十六進表記のほうを優先したのです。

PHP 8.1以降、 mb_strwidth() が実態に即していない

refs php/php-src@d8c785b

文字幅に関する仕様はPHP: mb_strwidth - Manualで説明されている通りUnicodeのTR-11 EAST ASIAN WIDTHに準拠していますがeaw_table.hは2011年から更新されておらず、PHP 8.1リリース前のmbstringのオーバーホールによってUnicode 14.0に追従しました。

その際、てきめんさん @youkidearitai が指摘するように、2011年以降に追加されたEAWプロパティがFかWの文字に関する計算が変わってしまっています。

PHP: mb_strwidth - Manual に関して、以下の対応が必要になりそうです。

• 対象文字に関する記述を調整する
• 変更履歴にPHP 8.1でUnicode 14.0.0準拠になったことを明記する

列挙型 (Enum) のページのコードコメントに一部おかしい部分がある

https://www.php.net/manual/ja/language.enumerations.php

PHP Manual は chunked HTML という、ページがセクションごとに分割される形式で表示される。
そのため、このページ の以下の表示はおかしい。

また、このページには以下の通り typo も存在するが、 5cc30e3 で修正済み。

表記揺れ: 拡張機能 / エクステンション / 拡張モジュール

PHP は、ext/ 以下に、PHP コアの機能を使って関数やクラスなどの機能を追加できるようになっており、これを「拡張機能」または「エクステンション」「拡張モジュール」と呼んでいる。

原文では、extension ではあるが、PHP Manual 日本語版では上記の表記が混在している。

language.operators.precedence.phpの日本語訳に誤訳がある可能性

お世話になっております。issueに登録すること自体が初めてなので、なにか不手際があったら申し訳ありません。

元ページ：
https://www.php.net/manual/en/language.operators.precedence.php
該当ページ：https://www.php.net/manual/ja/language.operators.precedence.php

演算子の優先順位の表の7行目あたりで、
演算子（+ - .）の追加情報のところに「(単項の + と -),」
とありますが、元ページだと、ここが、
(binary + and -)に対応しているので、2項演算子的な意味が正しい情報ではないでしょうか？

+,-が単項の演算子として用いられる場合と、2項演算子的に用いられる場合に優先順位が異なるということだと思います。

よろしくお願いいたします。