訳語を統一するように修正

[noborus]

スタンドアロン → スタンドアローン
☓ エグゼキュータ → エクゼキュータ
○ エクゼキュータ → エグゼキュータ

参照: #2418 #1278 #1526

[noborus]

これにより上記２つの語が見つかった場合はテストに失敗するようになります。

[koizumistr]

エグゼキュータ だと思ってました、、、、orz

[noborus]

一応多数派に統一しただけで、根拠があれば変更することもあるかと思います。

[koizumistr]

根拠があれば

いえ、まったく根拠はありませんX-(

[tatsuo-ishii]

これをコミットしても、pull requestがなかったファイルについては訳語が不統一のままで残ってしまいますね。
むしろ、すべての訳が完了してから、まとめてsedなどで一括置換したほうが効率が良いようなきがします。

[noborus]

これをコミットしても、pull requestがなかったファイルについては訳語が不統一のままで残ってしまいますね。 むしろ、すべての訳が完了してから、まとめてsedなどで一括置換したほうが効率が良いようなきがします。

チェックするのは、変更されたファイルではなく、レポジトリ内のファイル全部です。
そのため、これがマージされると、その語があれば以降のテストは失敗するようになります。

含まれるpull requestがすでに出ていた場合は、マージしたときにテストが走って失敗します。
というか同じ行の修正のためコンフリクトが発生するはずです。
それを解決するようにすれば翻訳途中でも訳語の統一修正ができるというお願いです。

[tatsuo-ishii]

すみません。基本的なことがわかっていないのですが、

チェックするのは、変更されたファイルではなく、レポジトリ内のファイル全部です。
そのため、これがマージされると、その語があれば以降のテストは失敗するようになります。

「チェックする」というのは、誰がどのタイミングで行うのですか？
また、「以降のテスト」というのはどのテストのことでしょう？pull requestが出された時に行われるチェックのことですか？

[tatsuo-ishii]

チェックするのは、変更されたファイルではなく、レポジトリ内のファイル全部です。

もしかして、あるファイルAに関するpull requestを出しても、A以外のファイル（たとえばB)に違反訳語が含まれていた場合、それが原因でAのpull requestがエラーになる、ということでしょうか？であれば、尚更まずは違反訳語を一括置換で取り除く作業を行わないと、pull requestを出しても不毛にエラー判定されてしまうような気がしますが、理解が違っているでしょうか？

[noborus]

チェックするのは、変更されたファイルではなく、レポジトリ内のファイル全部です。

もしかして、あるファイルAに関するpull requestを出しても、A以外のファイル（たとえばB)に違反訳語が含まれていた場合、それが原因でAのpull requestがエラーになる、ということでしょうか？であれば、尚更まずは違反訳語を一括置換で取り除く作業を行わないと、pull requestを出しても不毛にエラー判定されてしまうような気がしますが、理解が違っているでしょうか？

基本的には、プログラムのテスト（regression test）と同じです。github actionsでのテストに訳語のチェックが追加されました。
このテストはローカルでも doc/src/sgml/でmake checkで実行できます。

pull requestを出した時点では、出した時点のレポジトリの内容でテスト（訳語のチェック）が行われます。
そのため開発の最新ではスタンドアロンがNGになっていても、
pull requestのブランチでの.ng.listに、その語が含まれてNGになっていなければテストは成功してそのまま通ります。

マージするときには、マージ先側でテストが走るので、関係ない変更なら（例えば「スタンドアロン」が含まれた変更でなければ）、そのままマージが成功してテストも成功します。
「スタンドアロン」が含まれた変更行が入ったファイルをマージしようとするとテストに失敗して修正が必要になります。
この場合はテストの前に同じ行の修正のためにコンフリクトが発生するはずです。
修正が必要になるのはこのときのみです。

[noborus]

ファイル的には、それぞれ１箇所のみの変更ですが、「スタンドアロン」と「エグゼキュータ」はそれぞれ１箇所のみ残っていただけで、全部の置き換えが終了しています。

[tatsuo-ishii]

なるほどよくわかりました。ご説明ありがとうございます。

[tatsuo-ishii]

エグゼキュータ だと思ってました、、、、orz

私も。
「エグゼキュータ」の方が英語の発音に近いですし、検索すると、エグゼキュータの方が多いです（23800 vs. 6570)。

[noborus]

エグゼキュータ だと思ってました、、、、orz

私も。 「エグゼキュータ」の方が英語の発音に近いですし、検索すると、エグゼキュータの方が多いです（23800 vs. 6570)。

おーなるほど。変更しますか。エクゼキュータの根拠が他になければ検索件数が上が一番根拠になりますし。

[noborus]

この場合はテストの前に同じ行の修正のためにコンフリクトが発生するはずです。

はずってこともなかったですね。コンフリクトが発生しないケースはたくさんあります。

翻訳の途中でも変更したい理由は翻訳が落ち着いたときには、別の一括変換と次のマージ準備で変更する場合が多くあり、
その変更と訳語の一括変換を並列でやるほうがコンフリクトの解決が大変で（なので #2280 の変更を見送りました) 、
１ファイルの翻訳のコンフリクトの方が解決が簡単というのがあります。

エグゼキュータに変更した場合は、多くのファイルの修正が入るため、これまでと違ったところでエラーになる可能性がありますが、
うまくいけば他の修正も入れやすくなります。

[noborus]

エグゼキュータに修正しました。変更ファイルが多くなっています。

[koizumistr]

確認しました。なんか私が言い出したことをきっかけに変更点が多くなってしまい申し訳ない気もします。

念のため確認ですが、

• これが入ると、更新されたチェックが動作し、今回の変更自体はそのチェックに合格する。
• これ以降のコミットで例えば「エクゼキュータ」とかやってしまうと、チェックに引っ掛かりPR時にシステムに怒られる

って理解であってますよね。

[noborus]

確認しました。なんか私が言い出したことをきっかけに変更点が多くなってしまい申し訳ない気もします。

念のため確認ですが、

• これが入ると、更新されたチェックが動作し、今回の変更自体はそのチェックに合格する。
• これ以降のコミットで例えば「エクゼキュータ」とかやってしまうと、チェックに引っ掛かりPR時にシステムに怒られる

って理解であってますよね。

はい。そうです。チェック自体はもうマージされていますので、NGな語が追加されることになります。
https://github.com/pgsql-jp/jpug-doc/pull/2423/files#diff-86126af2890c6a30212c475b4781ed24356687f0ba891ef838170c5e6075169fR31
actions のmake testを見ていただければわかると思いますが、変更があると、その都度チェックされます。

[KenichiroTanaka]

斉藤さん、詳細な解説ありがとうございました。
既存の訳には影響出ませんのであとは運用しながら改善していくで良いように思っています。

問題なければ本PRもマージしたいと思います（本PRの変更点は確認しました）。

[KenichiroTanaka]

マージします。