第21章の文章表現を見直しました。 #2664

pato-taityo · 2023-07-07T09:48:44Z

・冗長表現の見直し（例：することができます⇒できます）
・（）を全角に統一した
・漢字の開きの見直し（例：下さい⇒ください）
・助詞の繰り返しの見直し
・送り仮名の見直し（例：行なわれます⇒行われます）
・稼動⇒稼働
・読点の統一（,⇒、）

・冗長表現の見直し（例：することができます⇒できます）・（）を全角に統一した・漢字の開きの見直し（例：下さい⇒ください）・助詞の繰り返しの見直し・送り仮名の見直し（例：行なわれます⇒行われます）・稼動⇒稼働・読点の統一（,⇒、）

noborus · 2023-07-08T03:06:13Z

doc/src/sgml/client-auth.sgml

@@ -2071,7 +2071,7 @@ realmをユーザプリンシパル名に一致するように設定します。
 <productname>SSPI</productname>は、シングルサインオンで安全な認証を行うための<productname>Windows</productname>の技術です。
 <productname>PostgreSQL</productname>は、<literal>negotiate</literal>モードにおいてSSPIを使用します。
 これは、可能な場合は<productname>Kerberos</productname>を使用し、他の場合については自動的に<productname>NTLM</productname>を使用することを意味しています。
-<productname>SSPI</productname>認証は、サーバ、クライアントが共に<productname>Windows</productname>上もしくは<productname>GSSAPI</productname>が利用可能な場合はWindowsではないプラットフォームで稼動しているときにのみ動作します。
+<productname>SSPI</productname>認証は、サーバ、クライアントが共に<productname>Windows</productname>上もしくは<productname>GSSAPI</productname>が利用可能な場合はWindowsではないプラットフォームで稼働しているときにのみ動作します。


稼働/稼動の修正します？するなら稼働で統一にしても良いかもしれませんが...

コメントをありがとうございました。コメントを受けて再考し、どちらに判断すべきか悩んでいます。これまでのポリシーや対応を踏まえ、どちらのほうが適切か、ご教示ください。

まず、当初変更した経緯について説明します。

校正ツールで「稼動」は間違えた表記であるとして、「稼働」への修正を提案されました。これを受けて修正しました。

ただ、コメントをいただいて、改めて辞書でも確認しました。すると、「稼動」と「稼働」は併記されており、いずれかが間違いとの記述はありませんでした。
・新明解国語辞典
・デジタル大辞泉

ネットの記事でこの2つの使い分けについて調べましたが、判断に使えるほど根拠があるものは見つかりませんでした。

ここまでを踏まえ、「稼動」と「稼働」は同じ意味ととらえて良いのでは、と考えました。

さらに、現在の翻訳での使い分けを確認しました。登場件数は以下のとおりです。
稼動：59件
稼働：72件
同じ sgml ファイル内でも両方登場しているケースが見られました。

まとめると、「稼動」と「稼働」は同じ意味と考えています。また、翻訳の中では混在しているようです。
このような場合、これまではどのような対応をしてきたのでしょうか？統一していくのか。それとも同じ意味なので許容するのか。

同じ意味なのに意図無くブレている場合はどちらかに決めて統一してきたかと思います。
そして、これは意図なくブレているケースかと思います。
（どなたか使い分けされていましたでしょうか。私は使い分けていません）
漢字としては私も稼働が正しいように思いますので、反対意見がなければ本件は稼働でマージしつつ、
残りは一括変換が良いかと思います。

ご意見・提案をありがとうございました。

反対意見が無ければ、これを機に稼動⇒稼働の変更でIssueを作成したいと思います。

今は皆さんが翻訳作業を進めている最中だと思いますので、翻訳対象外のファイルを直しつつ、翻訳作業の区切りがついたタイミングで一括変換しようかと考えています。

確認ありがとうございます。
では一括変換しちゃいましょう。
ISSUESをお願いしてしまってもいいでしょうか。

KenichiroTanaka

対応ありがとうございます。
いくつかコメントしましたので見ていただいてもいいでしょうか。

KenichiroTanaka · 2023-07-15T13:46:54Z

doc/src/sgml/client-auth.sgml

@@ -2905,7 +2905,7 @@ RADIUSアカウントのサポートはありません。
 サーバから負の応答があると、認証は失敗します。
 サーバから応答がない場合は、リスト内の次のサーバが試されます。
 複数のサーバを指定するには、サーバ名をカンマで区切り、リストを二重引用符で囲みます。
-複数のサーバを指定した場合は、別のRADIUSオプションをカンマ区切りのリストとして指定して、各サーバの値を個別に指定することもできます。
+複数のサーバを指定したい場合は、別のRADIUSオプションをカンマ区切りのリストとして指定して、各サーバの値を個別に指定することもできます。


ここは原文が
If multiple servers are specified,
なので、元のまま、もしくは直訳して「複数のサーバが指定された場合は」などになるかと思います。

コメントに従い、元のままにします。
原文とのチェックが甘かったです。ありがとうございました。

KenichiroTanaka · 2023-07-15T13:53:06Z

doc/src/sgml/client-auth.sgml

@@ -2453,7 +2453,7 @@ LDAP認証は2つのモードで動作します。1つ目のモードでは、
    in where the user objects are located in the directory, but will cause
    two separate connections to the LDAP server to be made.
 -->
-2つ目のモードでは、それはsearch+bindモードを呼び出すもので、サーバは最初に<replaceable>ldapbinddn</replaceable>と<replaceable>ldapbindpasswd</replaceable>で指定された、
+2つ目のモードでは、それはsearch+bindモードを呼びだすもので、サーバは最初に<replaceable>ldapbinddn</replaceable>と<replaceable>ldapbindpasswd</replaceable>で指定された、


「呼び出す」は今までのままの方が良いように思います。
これまで他の漢字の開きと違い、「出す」にも意味があるからだと理解しています(が、そう主張する根拠に自信がありません)。
ご意見いただけると助かります！

「呼び出す」に戻します。

https://www.bunka.go.jp/seisaku/bunkashingikai/kokugo/hokoku/pdf/92968501_01.pdf
こちらの資料では「呼び出す」という記載が使われていました。

また、修正した根拠のスタイルガイドを再度確認しました。
https://www.jtf.jp/pdf/jtf_style_guide.pdf
「〜だす」：「〜し始める」の意味の場合。
「〜出す」：「出す」の意味を含む場合。
どちらでも説明できそうですが、"call" の元の意味を考えると、「呼び出す」が良いのではと考えました。

KenichiroTanaka · 2023-07-15T13:56:16Z

doc/src/sgml/client-auth.sgml

@@ -2071,7 +2071,7 @@ realmをユーザプリンシパル名に一致するように設定します。
 <productname>SSPI</productname>は、シングルサインオンで安全な認証を行うための<productname>Windows</productname>の技術です。
 <productname>PostgreSQL</productname>は、<literal>negotiate</literal>モードにおいてSSPIを使用します。
 これは、可能な場合は<productname>Kerberos</productname>を使用し、他の場合については自動的に<productname>NTLM</productname>を使用することを意味しています。
-<productname>SSPI</productname>認証は、サーバ、クライアントが共に<productname>Windows</productname>上もしくは<productname>GSSAPI</productname>が利用可能な場合はWindowsではないプラットフォームで稼動しているときにのみ動作します。
+<productname>SSPI</productname>認証は、サーバ、クライアントが共に<productname>Windows</productname>上もしくは<productname>GSSAPI</productname>が利用可能な場合はWindowsではないプラットフォームで稼働しているときにのみ動作します。


同じ意味なのに意図無くブレている場合はどちらかに決めて統一してきたかと思います。
そして、これは意図なくブレているケースかと思います。
（どなたか使い分けされていましたでしょうか。私は使い分けていません）
漢字としては私も稼働が正しいように思いますので、反対意見がなければ本件は稼働でマージしつつ、
残りは一括変換が良いかと思います。

KenichiroTanaka · 2023-07-15T13:59:47Z

doc/src/sgml/client-auth.sgml

@@ -1581,7 +1581,7 @@ peer認証は、通常ローカル接続に推奨されますが、trust認証
    configuration parameter to place the socket file in a suitably
    restricted directory.
 -->
-<literal>trust</literal>認証はユーザが1人のみのワークステーション上でローカル接続を行う場合は適切であると同時に非常に便利です。
+<literal>trust</literal>認証はユーザが1人のみのワークステーション上でローカル接続を行う場合には適切であると同時に非常に便利です。


他の箇所では「には」は「は」と修正いただいていたように思いますが、ここは逆にように見えます。
何か意図がありますでしょうか。

ここは今もちょっと悩んでます。

元の文章の
「認証はユーザが1人のみのワークステーション上でローカル接続を行う場合は適切である」
だと「は」が2箇所に出て、文章の構成がちょっと分かり辛く感じました。

「は」を「に」に代えたかったのですが、
『ローカル接続を行う場合に適切であると同時に非常に便利です』
だと「に」が連続してしまい、これも分かり辛い気がしました。

ただ、修正したバージョンの「には」だとシチュエーションを限定した印象が出ます。
原文だとそこまで言っていないので、やりすぎな気がしています。

素直に元の文章に直そうかと思いますが、いかがでしょうか？

レスありがとうございます。
原文を読んでみると、「と同時に」の原文は　andかと思います。必ずしも「と同時に」とする必要もないため、
ご指摘の読みづらさはこちらを解消しても良いかと思います。
例えば、

<literal>trust</literal>認証はユーザが1人のみのワークステーション上でローカル接続を行う場合に適切で非常に便利です。

などとするのはどうでしょうか。

ありがとうございます！
ご提案いただいた文章はすっきり読みやすかったので、そのまま採用させていただきました。

・「複数のサーバを指定したい場合は」⇒「複数のサーバを指定した場合は」・「呼びだす」⇒「呼び出す」

pgsql-jp#2664 (comment)

KenichiroTanaka

ひととおり確認しました。マージします。

github-actions bot added the レビュー待ち label Jul 7, 2023

noborus reviewed Jul 8, 2023

View reviewed changes

KenichiroTanaka requested changes Jul 15, 2023

View reviewed changes

KenichiroTanaka added 指摘事項あり and removed レビュー待ち labels Jul 15, 2023

PullRequestに対するご指摘に対応しました。

d79b867

・「複数のサーバを指定したい場合は」⇒「複数のサーバを指定した場合は」・「呼びだす」⇒「呼び出す」

github-actions bot added 再レビュー待ち and removed 指摘事項あり labels Jul 16, 2023

KenichiroTanaka added 指摘事項あり and removed 再レビュー待ち labels Jul 17, 2023

PullRequestに対するコメントに対応しました。

77bd9f4

pgsql-jp#2664 (comment)

github-actions bot added 再レビュー待ち and removed 指摘事項あり labels Jul 18, 2023

KenichiroTanaka approved these changes Jul 24, 2023

View reviewed changes

KenichiroTanaka merged commit 87ca461 into pgsql-jp:doc_ja_15 Jul 24, 2023

This was referenced Jul 25, 2023

稼動⇒稼働の一括変換 #2678

Closed

Issues #2678 の対応をしました。 #2680

Closed

pato-taityo mentioned this pull request Aug 7, 2023

Issues #2678 の対応をしました #2688

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

第21章の文章表現を見直しました。 #2664

第21章の文章表現を見直しました。 #2664

pato-taityo commented Jul 7, 2023

noborus Jul 8, 2023

pato-taityo Jul 8, 2023

KenichiroTanaka Jul 15, 2023

pato-taityo Jul 24, 2023

KenichiroTanaka Jul 24, 2023

KenichiroTanaka left a comment

KenichiroTanaka Jul 15, 2023

pato-taityo Jul 16, 2023

KenichiroTanaka Jul 15, 2023

pato-taityo Jul 16, 2023

KenichiroTanaka Jul 15, 2023

KenichiroTanaka Jul 15, 2023

pato-taityo Jul 16, 2023

KenichiroTanaka Jul 17, 2023

pato-taityo Jul 18, 2023

KenichiroTanaka left a comment

第21章の文章表現を見直しました。 #2664

第21章の文章表現を見直しました。 #2664

Conversation

pato-taityo commented Jul 7, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

KenichiroTanaka left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

KenichiroTanaka left a comment

Choose a reason for hiding this comment