カタカナの長音ルール #2617
Comments
|
一応ルールはまだ変わっていないという認識です。 他のプロジェクトでは長音を付けるように変更されているため、ほっておくとどんどん長音の有る無し両方混在した状態になってしまいますが、 それで、省くように統一しても結局は変更せざるをえないので長音を付けるように統一するように合意が取れると解決になるのですが、どうでしょうか？ 現在PostgreSQL文書内で使用されている対象の語は以下です。 |
|
すべて長音を付けるのはマイクロソフトが言い出したルールで、マイクロソフトの影響力が大きいのでデファクトになってしまった感がありますが、すべてのメーカがそれに追従しているわけではありません。たとえば富士通やNEC、それにAppleは今でも「コンピュータ」です。将来は「長音ルールはいずれ省くのを止めて付けるように変更せざるをえない」かもしれませんし、そうではないかもしれませんが、こうした現状を踏まえると、今すぐルールを変更する必要はないと思います。まあ、ユーザから「コンピューター」が「コンピュータ」になっていないのが気になってしょうがない、みたいな苦情が殺到すれば別ですが。 |
|
私は、先に一般用語として長音をつけていたけど、IT業界では省くようになっていたのを止めたという認識です。 逆に、長音を省くのをPostgreSQLのマニュアルで初めて見たという人が、そろそろ出てくるのではないないかと思ってます。 |
|
ワープロやその他の個人用のツールのマニュアルなら、長音を省かないカタカナの方が違和感はないでしょう。 |
私もPostgreSQLがそこまで先行する必要はないと考えていましたが、結局変えることになる流れだと思ってます。 |
そういう人はPostgreSQLマニュアルの読者としては少数派だと思います（多分そういう人たちは、まず入門書だったり、ブログを主に読むと思います）。私は以下のような人読者層が圧倒的に多いと思っています。
こういう人たちの読む書籍や論文、マニュアルは、ほとんどがJIS式のカタカナ長音表記のはずです。そういう人たちにとって、PostgreSQLの現在のカタカナ表記の方が馴染みがあり、違和感がないはずです。 あと、そもそもPostgreSQLマニュアルは、リファレンスマニュアルであり、入門初心者が学習する教材として考えるのはちょっと違うような気がします。初学者の入門書であれば、斎藤さんの考え方に一理あると思いますが、リファレンスマニュアルに対して適用するのが良いかどうかは疑問です。 |
|
まず、情報の非対称性があります。 そして、PostgreSQLマニュアルの読者を想定はしても限定はしていないので、検索エンジンに引っかかったから一部分だけ読むでも構わないですし、 |
私は「長音ありをほとんど見たことがない」とは書いていないのですが。
PostgreSQLマニュアルの読者層をできるだけ広げてカバーしたいという気持ちはわかりますが、この文書を真剣に読む人（つまり私が言っている読者層）と、検索してちょっと一部だけ読む読者では、どちらを重視あるいは気にかけるべきかは、自ずと違ってくるでしょう。
さすがにそれはないでしょう。単にPostgreSQLマニュアル同様、JIS式表記にあわせている、と考えたほうが自然です。 |
書いていたと言いたいわけではなくて、言いたかったことは非対称性だということです。
さすがにその抜き出し方はないでしょう。 JISの長音省略の根拠はすでに改定されていて、平成3.6.28 内閣告示第2号 によるとされていて、 PostgreSQL関連の書籍も長音省略なので、慣用が長音省略だからマニュアルも長音省略とするのは逆で、マニュアルが長音省略なので、PostgreSQL入門書を書くときも合わせたと考える方が自然です。 IT関連やソフトウェア業界の慣用が長音省略とするのは既に苦しくなってきているので、 ということで、前提としたのをもう一度取り出させてもらうと、 |
そうなんですか？何か具体的な根拠があれば教えて頂けると助かります。商業出版や、商業ソフトの世界では、利益=読者や顧客が第一なので、そういう状態なのであればとっくに長音ありにしていると思いますが。
どう考えてもPostgreSQLのマニュアルの影響を受けそうにないOracleのマニュアルもJIS式ですし、最近読んだRDBMS関連の書籍「データ指向アプリケーションデザイン(Martin Keleppmann著、斉藤太郎監訳」、「リレーショナルデータベース入門(斉藤良文)」でも、JIS式でした。 |
|
JISで「長音ありでも良い」と決まったのが2005年、MSが長音付きにすると宣言したのが2008年です。それから20年近く経ってもRDBMS界では依然として長音なしが主流です。 ちなみにこれは個人的見解なのでどうでも良い話ですが、私自身はJISの長音に関するルールは割とよくできていると思っています。その理由は、長音付きのカタカナに比べると、まだしも英語の発音に近いと感じるからです。五十歩百歩だという人もいるかもしれませんが。 |
2008年以前は IT関連やソフトウェア業界では長音省略が慣用といって問題なかったですが、それ以降は両方使われるというのが適切だと思います。両方使われるがさらに苦しくなってきたのですが、これは後述します。
1行前に「データベース界隈では長音省略が慣用となっているというのは確かにあると思いますが」 PostgreSQL関連本はPostgreSQLの記述に従いますし、Oracleの関連本は、Oracleのドキュメントに従います、特定のデータベースではない、例えばSQL入門の本であっても長音を省略していたら、
私の見解は違います。私の見解とGoogleトレンドの傾向が近いので、そのグラフを利用させてもらいます。 2006年から現在までのサーバ、サーバーの比較です。インターネット、通信事業を選択しています。
傾向は根拠有ると思いますが、これから書く解説は個人の見解です。数値はピークが100としたときの相対評価らしいです。 2008年までは長音省略の方が主流でしたが、それ以降は両方ある状態になります。 私は、調べる前は2010年代と変わらない認識でしたが、どうもしきい値を下回りはじめたようだと考えを変えました。 長音ありへの変更は、エンドユーザーに近いところから変えるだろうと考えていましたので、PostgreSQLが先行する必要はないと思っていましたが、 |
|
つまり、現在のDBMS界の出版文書(マニュアル、書籍、資格試験の問題文などを含む）で実際のカタカナ長音の記法がどうであれ、インターネットの検索傾向で長音ありが増えているから、率先してPostgreSQLマニュアルを長音ありにしよう、ということですか。
1であると言うならまだわかりますが、2であるとすると、私はちょっと賛同しかねます。 |
これは見逃せないので反論しておきます。データベース研究論文、著作ではほぼ全てでJIS式のカタカナ記法を採用していると思います。その事実を無視して、推測で語るのはいかがなものかと思います。 |
|
私も長音省略が主流だと信じていましたが、 https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/CHAP_Aurora.html もちろんMSも長音有りです。 最近のマニュアルではRDBMS業界でも長音有りが普通になってきているのでそろそろPostgreSQLも |
URLのOraleのドキュメントを見てみました。しかし、一方で、「セキュリティ」というのもありますね。（斉藤さん案では「セキュリティー」）。「ユーティリティ 」「コンピュータ」も同様（斉藤さん案では「ユーティリティ ー」「コンピューター」）。必ずしも長音ありではないようです。 |
|
既に何度も書いていますが、ソフトウェア分野において長音省略は苦しくなっており、JISの原則からも外れています。
失礼しました。私が上に上げたのは、「JTF日本語標準スタイルガイド」がベースになっていると思います。 この違いがある用語については、今後もどちらを使用して問題ないままだと予想されますが、それ以外は認識されづらくなっていくだろうと予想してます。 |
これは誤解を招く言い方ではないですか？JISは「長音は用いても省いても誤りではない」と言っているだけで、「長音を付けるのが原則」とは言っていないです。 MSが巨大企業でユーザが多いからそのルールに従うという考えもあるでしょうが、そもそもMSは長音に関するルールを自分たちの製品の中で使うために決めているだけで、それを世の中の標準にしたいという意図は無いはずです。Oracleやその他の企業もMSルールに右に習えになるところまでくればいわゆるデファクトスタンダードになるので、採用の検討もあり得ると思いますが、そうはなっていないし、将来そうなると言う見通しもないように思えます。 そうすると、このグループで、MSにせよ、JTFにせよ、独自ルールを決めるにせよ、どれを選んでも業界の他とは違うルールを選ぶことになるわけです。（デファクトスタンダードがないので）それで良いのですかね。 |
JIS Z 8301 : 2019）で「外来語の表記は、主として”外来語の表記（平成3.6.28 内閣告示第２号)”による。」
ということで原則は長音符号をつけると解釈しています。
最初からの主張ですが、長音を付ける用語は違和感があるという人でも避けるのが難しいレベルで目に入るぐらい使用されていて、 書くのは負担なので統一されずに残そうとするのは、止めた方が良いと主張はしていきたい... |
|
A.長音をつけることはすでに受け入れらている方向にある という点は共通認識になった理解で合っているでしょうか。 あとは、長音ありに変更するとして、OSS-DBSilverを提供しているLPIや各社PostgreSQL関連のサービスを提供しているのドキュメント、教育コンテンツ、GUIツールへの影響の考慮は必要ではないでしょうか。基本はマニュアルに合わせてもらう方向になると思いますが、突然変わるのは困るのではないかと思います。 |
誰が受け入れているかの主語を明示しないと、一概に言えないという認識です。
はい、その認識です。 |
まず、バージョンで分けると15と16で対応を変えたりと書き手に負担がかかるので、時期で分けるようにしてこれ以降に更新するものは変更するようにしたほうが良いと思います。 ということで、変更できるときに変更して、 |
|
変換準備が整ってきました。 単語を統一するというのは合意されていると思います。 対象は以下です。数字は文書内に含まれている数です。１回で変換するのは多いですが、数回に分けてPRを出せば可能な数です。 逆に長音を付けるように変更する場合は、数千（万？）箇所の変換になるので、計画立てて実行する必要があります。 |
. pgsql-jp#2617 の対応です。
|
JTF日本語標準スタイルガイドにあった単語は統一しましたが、その他に長音の統一が出来ていない単語があります。 サブスクライバー以外は長音を省くほうが多いので省く方に統一するで良いと思いますが、 サブスクライバーは長音ありで統一する方が良さそうです。 |
トリガ、スカラに統一。 . pgsql-jp#2617 のコメントの対応第三弾です。 NGリストの順番を少し変更して長音の単語を追加しました。
|
現時点では src/backend/catalog/sql_features.txt.ja は対象外なので、エラーになっていないのですが、「ラッパ」となっているようです。 |
|
対象を広げて修正します。 diff --git a/doc/src/sgml/Makefile b/doc/src/sgml/Makefile
@@ -286,7 +286,7 @@ check-tabs:
# words to avoid as pgsql-jp
check-ng:
@ln -sf $(top_builddir)/.ng.list .ng.list
- @if git --no-pager grep -E --color=always -f .ng.list *sgml ref/*sgml; \
+ @if git --no-pager grep -E --color=always -f .ng.list $(srcdir)/*.sgml $(srcdir)/ref/*.sgml $(top_builddir)/src/backend/catalog/*.txt.ja; \
then \
echo "使用NGな語が見つかりました。";\
false;\ |
#3124 で修正しました |
|
一応統一の対応が終わって、この後の変更をどするかは #3107 に移動しようと思います。 |
重要度
高
問題点
カタカナの末尾に付ける長音「ー」の有無について、統一されたルールが現状無いようです。その結果、ルールに基づくのではなく、何となくその時に長音有無の多数派に寄せましょう、的なpull requestが乱立し、翻訳のブラッシュアップが終わりの見えない作業になってしまっています。
背景
以前はJISに基づく基準で長音の有無を決めていたのでルールの曖昧さはなかったのですが...
解決方法
個人の好みや、「多数派に寄せる」といった曖昧なものではなく、ルールの確立が必要だと考えます。
注意点
No response
貢献者として記載可否
記載（貢献者欄に書いてください）
貢献者名
No response
The text was updated successfully, but these errors were encountered: