charset.sgmlのPostgreSQL 17.0対応です。 by tatsuo-ishii · Pull Request #3173 · pgsql-jp/jpug-doc

tatsuo-ishii · 2024-12-01T08:05:27Z

No description provided.

noborus · 2024-12-11T03:08:33Z

doc/src/sgml/charset.sgml

    collations and character classifications.
 -->
-《機械翻訳》ロケールプロバイダは、照合と文字分類のライブラリ動作を定義するロケールを指定します。
+ロケールプロバイダは、照合と文字分類のロケール動作を定義するライブラリを指定します。


照合順序で統一で良いのではないでしょうか。

でも、"collation order"っていうのも出てくるんですよね。"collation"も"collation order"も「照合順序」と訳してしまうと区別がつかなくなるので、単独の"collation"をここでは「照合」と訳しています。

確かに"collation"を照合"collation order"を照合順序とした方がすっきりしますが、
他で統一されてなくて"collation"を照合順序としている場合が多いです。
統一されていないのでissueを立てます。

noborus · 2024-12-11T03:09:59Z

doc/src/sgml/charset.sgml

-《機械翻訳》<literal>C</literal>と<literal>POSIX</literal>の照合は、<quote>従来のC</quote>の動作に基づいています。
-ソート言語のバイトではなくオーダー値で照合され、ASCII文字<quote><literal>A</literal></quote>から<quote><literal>Z</literal></quote>までのみが文字として扱われます。
-この動作は効率的であり、特定のデータベースエンコーディングのすべてのバージョンで安定(stable)ですが、動作はデータベースのエンコーディングによって異なる場合があります。
+<literal>C</literal>と<literal>POSIX</literal>の照合は、<quote>従来のC</quote>の動作に基づいています。


ここの照合順序で良いと思います。

同上です。

noborus · 2024-12-11T03:10:46Z

doc/src/sgml/charset.sgml

        at database creation time.
 -->
-《機械翻訳》<literal>デフォルト</literal>照合順序は、ロケールの作成時に指定したデータベースを選択します。
+<literal>デフォルト</literal>照合順序は、データベース作成時に指定したロケールを選択します。


ここは<literal>default</literal>のままで良いのでは？

おっと、そうですね。

noborus · 2024-12-11T03:11:34Z

doc/src/sgml/charset.sgml

 -->
-《機械翻訳》オペレーティングシステムサポートによっては、追加の照合を使用できる場合があります。
+オペレーティングシステムサポートによっては、追加の照合を使用できる場合があります。
 これらの追加の照合の効率性と安定度は、照合順序プロバイダ、プロバイダバージョン、およびロケールによって異なります。


ここも照合順序。

noborus

一通り確認しました。
照合→照合順序への統一と<literal>default</literal>の確認をお願いします。

"collation order"と"collation" (oderなし)をどうするかを除き、対応しています。

noborus

ありがとうございます。確認しました。
collationは全体で見直して修正するということでここではおいておきます。

KenichiroTanaka

いくつか気づいたところがありますので見ていただいてもいいでしょうか。

KenichiroTanaka · 2024-12-16T22:59:20Z

doc/src/sgml/charset.sgml

-《機械翻訳》<literal>C.UTF-8</literal>ロケールは、データベースエンコーディングが<literal>UTF-8</literal>であり、動作がUnicodeに基づいている場合にのみ使用できます。
+<literal>C.UTF-8</literal>ロケールは、データベースエンコーディングが<literal>UTF-8</literal>であり、動作がUnicodeに基づいている場合にのみ使用できます。
 照合順序はコードポイント値のみを使用します。
 正規表現文字クラスは"POSIX Compatible"セマンティクスに基づいており、ケースマッピングは"シンプル"バリアントです。


機械翻訳の箇所ですがvariantがカタカナのままですがどうしましょう。
他では亜種、変種などと訳されています（これも統一したいですね）。

$find . -name ".sgml"|xargs grep 亜種|wc -l
26
$find . -name ".sgml"|xargs grep 変種|wc -l
17

あまり差がないですが亜種に揃えるといいでしょうか？
（文脈で変種が良いケースはパッと見つけられませんでした）

他に「異型」という訳も使われています。
find . -name '*.sgml'|xargs grep 異型|wc -l
5
出現数としては少ないので、「亜種」に統一します。

KenichiroTanaka · 2024-12-16T23:06:17Z

doc/src/sgml/charset.sgml

 -->
-《機械翻訳》<literal>icu</literal>プロバイダーは、外部ICU<indexterm><primary>ICU</primary></indexterm>ライブラリを使用します。
+<literal>icu</literal>プロバイダは、外部ICU<indexterm><primary>ICU</primary></indexterm>ライブラリを使用します。
 <productname>PostgreSQL</productname>サポートが設定されている必要があります。


機械翻訳の箇所ですが、これはinitdb時に--locale-provider=icuがつけられてる必要があることを指しているのかと思います。
ですので、
「PostgreSQLがサポート付きで設定されている必要があります。」
もう少し意訳して
「PostgreSQLがICUサポート付きで設定されている必要があります。」
(やりすぎかもです)
などとするのはどうでしょうか。

「PostgreSQLがサポート付きで設定されている必要があります。」はちょっと意味がよくわからないので、「PostgreSQLがICUサポート付きで設定されている必要があります。」に賛成です。

KenichiroTanaka · 2024-12-16T23:17:22Z

doc/src/sgml/charset.sgml

 すべてのエンコーディングで使用できます。
 この照合順序を使用するにはICUサポートが必要であり、PostgresがICUの別のバージョンで構築されている場合は動作が変更される可能性があります（この照合順序はICUルートロケールと同じ動作をします。
-<xref linkend="collation-managing-predefined-icu-und-x-icu"/>を参照してください。）
+（この照合順序は、ICU rootロケールと同じ動作をします。<xref linkend="collation-managing-predefined-icu-und-x-icu"/>を参照してください。）


直前の行でicu root localeはカタカナで「ICUルートロケール」とされています。
こちらもカタカナが良いかと思います。

「ICUルートロケール」としました。

KenichiroTanaka · 2024-12-17T00:00:17Z

doc/src/sgml/charset.sgml

-《機械翻訳》この照合順序は、自然言語のコードポイントではなく、Unicodeのオーダー値でソートされます。
+この照合順序による並べ替えでは、自然言語の並び順ではなく、Unicodeのコードポイント値を使用してソートされます。
 関数<function>lower</function>、<function>initcap</function>、<function>upper</function>には、Unicodeシンプルケースマッピングを使用します。
 パターンマッチ（正規表現を含む）の場合は、POSIX互換のUnicode<ulink url="https://www.unicode.org/reports/tr18/#Compatibility_Properties">互換性プロパティを使用します</ulink>。


POSIX Compatible variantのvariantを訳出すべきか判断できていません。
互換に亜種のニュアンスを含むのでこのままでもいい気がしています。
（どなたかご意見いただけないでしょうか）

リンク先の表Annex C: Compatibility Propertiesを見ると、Unicode標準とPOSIX標準を対比させる形で解説しており、ここではPostgreSQLはUnicode標準ではなく、POSIX標準の方を使っているという意図が込められていると思います。だとすると、variantを訳出した方がよいと思い、variantを訳すように修正してみました。

tatsuo-ishii

レビューありがとうございます。

tatsuo-ishii · 2024-12-31T01:51:18Z

doc/src/sgml/charset.sgml

-《機械翻訳》<literal>C.UTF-8</literal>ロケールは、データベースエンコーディングが<literal>UTF-8</literal>であり、動作がUnicodeに基づいている場合にのみ使用できます。
+<literal>C.UTF-8</literal>ロケールは、データベースエンコーディングが<literal>UTF-8</literal>であり、動作がUnicodeに基づいている場合にのみ使用できます。
 照合順序はコードポイント値のみを使用します。
 正規表現文字クラスは"POSIX Compatible"セマンティクスに基づいており、ケースマッピングは"シンプル"バリアントです。


他に「異型」という訳も使われています。
find . -name '*.sgml'|xargs grep 異型|wc -l
5
出現数としては少ないので、「亜種」に統一します。

tatsuo-ishii · 2024-12-31T01:53:28Z

doc/src/sgml/charset.sgml

 -->
-《機械翻訳》<literal>icu</literal>プロバイダーは、外部ICU<indexterm><primary>ICU</primary></indexterm>ライブラリを使用します。
+<literal>icu</literal>プロバイダは、外部ICU<indexterm><primary>ICU</primary></indexterm>ライブラリを使用します。
 <productname>PostgreSQL</productname>サポートが設定されている必要があります。


「PostgreSQLがサポート付きで設定されている必要があります。」はちょっと意味がよくわからないので、「PostgreSQLがICUサポート付きで設定されている必要があります。」に賛成です。

tatsuo-ishii · 2024-12-31T01:54:44Z

doc/src/sgml/charset.sgml

 すべてのエンコーディングで使用できます。
 この照合順序を使用するにはICUサポートが必要であり、PostgresがICUの別のバージョンで構築されている場合は動作が変更される可能性があります（この照合順序はICUルートロケールと同じ動作をします。
-<xref linkend="collation-managing-predefined-icu-und-x-icu"/>を参照してください。）
+（この照合順序は、ICU rootロケールと同じ動作をします。<xref linkend="collation-managing-predefined-icu-und-x-icu"/>を参照してください。）


「ICUルートロケール」としました。

tatsuo-ishii · 2024-12-31T02:04:03Z

doc/src/sgml/charset.sgml

-《機械翻訳》この照合順序は、自然言語のコードポイントではなく、Unicodeのオーダー値でソートされます。
+この照合順序による並べ替えでは、自然言語の並び順ではなく、Unicodeのコードポイント値を使用してソートされます。
 関数<function>lower</function>、<function>initcap</function>、<function>upper</function>には、Unicodeシンプルケースマッピングを使用します。
 パターンマッチ（正規表現を含む）の場合は、POSIX互換のUnicode<ulink url="https://www.unicode.org/reports/tr18/#Compatibility_Properties">互換性プロパティを使用します</ulink>。


リンク先の表Annex C: Compatibility Propertiesを見ると、Unicode標準とPOSIX標準を対比させる形で解説しており、ここではPostgreSQLはUnicode標準ではなく、POSIX標準の方を使っているという意図が込められていると思います。だとすると、variantを訳出した方がよいと思い、variantを訳すように修正してみました。

KenichiroTanaka

対応ありがとうございました。
いただいている修正で問題ないかと思いますのでこの辺りでマージします。

charset.sgmlのPostgreSQL 17.0対応です。

bbb0bf8

github-actions bot added the レビュー待ち label Dec 1, 2024

並び替え -> 並べ替え

bf7b157

noborus reviewed Dec 11, 2024

View reviewed changes

noborus added 指摘事項あり and removed レビュー待ち labels Dec 11, 2024

noborus mentioned this pull request Dec 12, 2024

collationの訳語が統一されていない #3181

Open

斉藤さんの指摘事項に対応しました。

335f2e2

"collation order"と"collation" (oderなし)をどうするかを除き、対応しています。

github-actions bot added 再レビュー待ち and removed 指摘事項あり labels Dec 13, 2024

noborus approved these changes Dec 13, 2024

View reviewed changes

noborus added 他にも誰か見て（レビュー済み） and removed 再レビュー待ち labels Dec 13, 2024

KenichiroTanaka requested changes Dec 17, 2024

View reviewed changes

KenichiroTanaka added 指摘事項あり and removed 他にも誰か見て（レビュー済み） labels Dec 17, 2024

田中さんの指摘に対応しました。

1656dd6

github-actions bot added 再レビュー待ち and removed 指摘事項あり labels Dec 31, 2024

tatsuo-ishii commented Dec 31, 2024

View reviewed changes

KenichiroTanaka approved these changes Jan 5, 2025

View reviewed changes

KenichiroTanaka merged commit 0dbbf3a into pgsql-jp:doc_ja_17 Jan 5, 2025
2 checks passed

tatsuo-ishii deleted the charset170 branch October 4, 2025 06:55

Conversation

tatsuo-ishii commented Dec 1, 2024

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

noborus left a comment

Choose a reason for hiding this comment

Uh oh!

noborus left a comment

Choose a reason for hiding this comment

Uh oh!

KenichiroTanaka left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tatsuo-ishii left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

KenichiroTanaka left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants