PostgreSQL 16-17翻訳スケジュール（提案）

[noborus]

重要度

高

問題点

PostgreSQL 16.4が最優先です。

マニュアル翻訳のissueが溜まっていますが、新しいバージョン対応に追われてissue対応が少しづつしか進んでません。
16.4対応はリリースノート以外は分量が多くなく比較的早く終わると思いますが、17.0が出てしまうと17.0対応にかかりきりになってしまいます。
一方で、ある程度方針も決まって訳語を統一しても手戻りが起こりにくいようになってきたため、訳語の置き換えができる環境は整ってきたと思います。また、その変更をバージョン間でバックポート、フォワードポートできるようになってきと思います。

そこで、

• 16.4の対応が（リリースノート以外）だいたい終わったら、改善期間にして訳語の統一等をおこなう。
• 16.4対応が終わったらリリースして、その後も継続して16ブランチで改善する置き換えをおこなう。
• ある程度終わったら公開版の16.4の更新する
• 並行して17.0が出る前でもbeta版の翻訳を開始する
• 17.0がリリースされたらbeta版の対応は終了して17.0の翻訳に切り替える
• 17.0で翻訳完了したファイルから順次16ブランチの翻訳改善の内容を取り込む
• 17.0の翻訳リリース時にも16ブランチの成果を取り込む

というスケジュールを提案します

gantt
    title PostgreSQLマニュアル翻訳
    dateFormat  YYYY-MM-DD
    section 16
    16.4翻訳           :a1, 2024-08-15, 30d
    翻訳改善     :after a1, 2024-09-05, 60d
    section 17
    17beta翻訳      :2024-09-05  , 10d
    17.0翻訳     : 60d

Loading

背景

No response

解決方法

No response

注意点

No response

貢献者として記載可否

以前の記載名を使用

貢献者名

No response

[tatsuo-ishii]

私は翻訳作業の優先順位は高い順に、

1. 翻訳漏れがないこと
2. 誤訳がないこと
3. 日本語としての自然さ
4. 訳語の統一

だと思っています。ユーザがマニュアルを読む場合、必要な箇所だけを探して読むのがほとんどだと思うので、4で問題があっても、実際には気にならないはずです。ですので、4の優先順位は低いと考えます。
16.3マニュアルの現在のステータスはよくわからないのですが、4にこだわらなければ今すぐリリースできる状態なら、今すぐリリースするのが最優先事項だと思います。
その後で、4あるいは16.4の作業に入るのが順当なのではないでしょうか？

17以降の作業に関しては、「並行作業」が色々あるのが気になります。並行作業を行えば、同じ期間の工数は増えるはずなので、翻訳メンバー数が固定の状態で、どうやって工数増加に対応するのでしょうか？

[noborus]

ありがとうございます。案としては、
16.4の日本語マニュアルリリース前に翻訳改善はスタートしますが、
その修正が終わる前（ある意味関係なく）、16.4の翻訳がでそろったら日本語マニュアルをリリースします。
その後も16ブランチで改善、修正を続けましょうというのが一番の趣旨です。

これまでは16.4が終わるとすぐに17.0が出てしまって、翻訳に追われ、多くのファイルにまたがる修正が出しづらくなってました。
17ブランチで翻訳を進めるのと並行して、16のブランチで既存訳の改善、修正するためのスケジュール案です。

16.3に関しては、現在もう出せる状態だと思います。
16.4はすでにリリースされているため、改善修正は見送って16.4を優先し16.4の翻訳めどがたったときのスケジュール案です。

作業量の増大に関しては、 17.0の翻訳は時間がかかるため、17.0の翻訳だけよりも翻訳とは別で16ブランチに修正をコミットしておくような作業があって、たまにそっちをやるという感じでも良いと思います。
また17.0で既存訳の修正をしたくなっても別ファイルも絡む場合は、issueにあげて終わりになってますが、16ブランチで修正して、後で17ブランチに反映できればスッキリします。手元にはリリースが遅れないように送ってない修正がいくつかあったりますし。

また、新たに参加する人が新しい翻訳を担当するのは敷居が高いので、issueや複数の訳語を見つけて修正するというところから参加して感じを掴んでから翻訳を担当してもらうことが出来れば参加してもらいやすくなります。

また、訳語を統一して、さらにNG語の追加までできると今後の翻訳で特にカタカナがあらかじめ決まってくるので、調べる手間やレビューの手間が減って全体の効率化に繋がります。

特に最後の「翻訳メモリ」的に自動でできる部分を増やして、人がやらなけれならない翻訳に注力するために訳語の統一が重要だと思っています。

[tatsuo-ishii]

16.3に関しては、現在もう出せる状態だと思います。

@KenichiroTanaka 16.3のリリースをどうするか、判断をお願いします。
ちなみに、16.4もそうですが、16.3にも脆弱性対応が含まれており、ユーザにとっては迅速な情報提供が望ましいです。

[KenichiroTanaka]

@noborus
@tatsuo-ishii
16.3は出せる状態になったと思います。この後公開作業をします。

@noborus
スケジュール案ありがとうございます。

並行して17.0が出る前でもbeta版の翻訳を開始する

16.4が完了しなければ17.0を開始できないと思います。
並列稼働でリソースが分散し16.4が遅れると17.0の開始が遅れますので、
17.0betaの開始は16.4が完了してからでも良いように思いますがどうでしょう？

他は良いように思います（提案ありがとうございます）

[noborus]

16.4の担当リストにない、または完了しているファイルは17.0の翻訳を開始しても支障はないと思います。
16.4の担当リストは比較的早く埋まると思いますが、リリースノートの量が多く完了までには時間がかかります。
その間、担当したいと思っても担当できるファイルがない状態になりますので、そのために用意しても良いと思いました。

[KenichiroTanaka]

確かにリリースノートはどうしても量が多いのでその間の時間を有効利用できますね。
理解しました。ご説明ありがとうございます。

[noborus]

16.4が完了したようなので REL_17_BETA3 の内容で doc_ja_17 ブランチを用意しました。
9/5にRC1が出るようなので、出たら更新します。

doc_ja_16 既存訳の修正
doc_ja_17 更新箇所の翻訳

ですすめていくことになります。

注意点としては、doc_ja_16,doc_ja_17で内容が変わってないパラグラフの修正は doc_ja_16を（も）修正しないと、
いずれdoc_ja_16の内容でdoc_ja_17に上書きしてしまうことになります。
17で原文に変更がある箇所は上書きされません。

[tatsuo-ishii]

doc_ja_16,doc_ja_17で内容が変わってないパラグラフ

これ、機械的に判定しているのだという前提での質問ですが、「内容が変わっていないパラグラフ」ってどういうアルゴリズムで判断しているのですか？PostgreSQLのドキュメントには「パラグラフ番号」のようなものが存在するわけではないので、diffのように、前後関係で判断しているのではないかと推測しますが、たとえばA, B, Cをパラグラフだとして、

PostgreSQL 16
A
B
：
C

PostgreSQL 17
A
C
：
B

のように、パラグラフを入れ替えたとえしたら、C, Bは内容が変わったと判定されるのでしょうか？

[noborus]

これは jpug-doc-tool でおこなっています。
詳しくは　jpug-doc-tool.pdf を参照していただきたいですが、doc_ja_16とdoc_ja_17のdiffをとっているわけではなく REL_16_3 と doc_ja_16のdiffから解析して英語と日本語のリストを作ってます。
以下のようになるのでパースが可能です。

+<!--
  英語原文1          →    en
  英語原文2
+-->
+ 日本語翻訳1        →    ja
+ 日本語翻訳2

同様にREL_17_BETA3とdoc_ja_17で英語原文を抽出して、16で抽出したリストファイルのの英語をキーとして比較して一致したら日本語が一致するかどうかで判定しています。
このリストはファイル単位で作っているので、順番が変わっても英語が一致すれば比較可能です。

リストはCSV的なファイル（Unicodeの区切り文字を使用してエスケープはしないで済むようになっています）なので、ファイル名の変更や分割は、リストファイルをコピーすれば対応できてしまいます。

[tatsuo-ishii]

+<!--
  英語原文1          →    en
  英語原文2
+-->

実際には<!--から-->までをパラグラフと見なしているということですね。

注意点としては、doc_ja_16,doc_ja_17で内容が変わってないパラグラフの修正は doc_ja_16を（も）修正しないと、
いずれdoc_ja_16の内容でdoc_ja_17に上書きしてしまうことになります。

今までは、翻訳箇所の前後にたまたま誤訳などを見つけて、ついで同じPRの中で修正することがありましたが、今後はそれをしてしまうと無駄になり、修正がいつの間にか消えてしまうので、「ついでに修正」はしないほうが良い、ということになりますね。

また、マージミスで必要な修正が入っていない箇所を修正するケースも同様に要注意です。

[tatsuo-ishii]

確認ですが、
#3055
のようなケースでは、

注意点としては、doc_ja_16,doc_ja_17で内容が変わってないパラグラフの修正は doc_ja_16を（も）修正しないと、
いずれdoc_ja_16の内容でdoc_ja_17に上書きしてしまうことになります。
17で原文に変更がある箇所は上書きされません。

の判定はどうしているのでしょう？「内容が変わっていないパラグラフ」の判定対象外なのでしょうか？

[noborus]

の判定はどうしているのでしょう？「内容が変わっていないパラグラフ」の判定対象外なのでしょうか？

はい。対象外です。
コメント化された英語のブロック内で１文字でも変更があれば、対象外になります。

entryのような形でも英語に変更がなければ、 英語の完全一致により対象化できます。
これは、その英語のブロックをファイル内から単純に探しているためです。
コメント化された英語のブロックを抽出しているので、そのブロックがファイル内に含まれるかどうかで変わります。

英語のブロックが含まれる　->　日本語訳の比較

英語のブロックが含まれない->　対象外

このロジックは新しいバージョンのマージを用意するときと同じです。

英語のブロックが含まれる　->　日本語訳の適用

英語のブロックが含まれない->　もとのファイルから英語のブロック範囲が

決まる　 →　マッチ度、機械翻訳を挿入
決められない →　何もできない

[noborus]

doc_ja_17をRC1に更新しました。
doc_ja_16の修正をdoc_ja_17に反映する #3061 を送りました。