Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

「外来語の表記に語尾の長音符号を省く場合の原則」に基づくルール・オプション #5

Open
kn1cht opened this issue Jan 5, 2020 · 5 comments
Labels
Status: Proposal Request for comments

Comments

@kn1cht
Copy link

kn1cht commented Jan 5, 2020

概要

JIS Z 8301:2011 表 G.3−外来語の表記に語尾の長音符号を省く場合の原則では、「長音符号は用いても略しても誤りでない」としながらも、長音記号を省く場合の原則が示されています。
この原則に従うと、elevatorは「エレベータ」、coverは「カバー」などとなります。

Microsoftが長音の省略を廃止するなど、世間一般の文章に適用する機会は少なくなりました。とはいえ、工学の論文等では長音を省く慣習が残っていることもあります。

いずれにせよ文献内で統一されていることが重要と思いますので、省略する場合のルールも実装し、オンオフできるようにするのが良いと考えます。

検討すべきこと

こちらのプリセットにあるkana-english-suffix-*系のルールとは矛盾してしまうので、それらに長音省略を許すオプションが必要です。

ただ、suffix系のルールにいちいちオプションをつけて回るのはユーザ側の負担になりそうです。
こちらのpresetとは別に、preset-foreign-language-writing-abbrev-cyouonのような省略優先のpresetを準備した方が使いやすいでしょうか?

@azu
Copy link
Member

azu commented Jan 5, 2020

ただ、suffix系のルールにいちいちオプションをつけて回るのはユーザ側の負担になりそうです。

ESLintだとShared Settingsという概念があって、ルール間で共通の設定を使えるようになってたりしますね。
textlintは設定がオブジェクトなのもあってまだこの仕組みはないですが…

各自のルールで長音のON/OFF出来るようなオプションの実装はどの場合でも必要になると思います。
(アルゴリズムが異なるならパッケージ自体を分けてしまうので良くて、presetが参照するパッケージ尾自体を分ける。)

spaceのルール(オプション分岐)を例にすると次のような感じですね。

space: "always" || "never"
-- https://github.com/textlint-ja/textlint-rule-spacing/tree/master/packages/textlint-rule-ja-space-between-half-and-full-width#options

https://github.com/textlint-ja/textlint-rule-spacing#%E3%83%87%E3%83%95%E3%82%A9%E3%83%AB%E3%83%88%E8%A8%AD%E5%AE%9A のpreset側で初期値を決めてる。

このデフォルトの違いをpresetとして用意するだけで、オプションを逐一設定しないと行けない問題は解決できると思います。
textlint-rule-preset-foreign-language-writing-XXX みたいなpresetパッケージを作って、そのpresetのオプションの初期値を変えるだけでいいと思います。
(monorepo内に同じにようにpresetパッケージ追加するだけで済むので扱いもシンプル)

こちらのpresetとは別に、preset-foreign-language-writing-abbrev-cyouonのような省略優先のpresetを準備した方が使いやすいでしょうか?

なので、解答としてはpresetを用意するがよさそうですね。

@azu
Copy link
Member

azu commented Jan 5, 2020

今の所のルールのアルゴリズムは、どちらかというと以下がベースですね。

https://www.jtca.org/standardization/katakana_guide_3_20171222.pdf
https://www.kyodo.co.jp/books/isbn/978-4-7641-0687-1/

かつ、あんまりロジカルに決まらないルール(辞書が大きなりそうなもの)は避けてます。

(2-1)「ウイ/ウィ」「ウエ/ウェ」「ウオ/ウォ」は「ウイ」「ウエ」「ウオ」を充てる。

とかはウィンドウとか人によって好みが分かれそうなルールは入れてないですね。
(統一はした方がいいけど、例外が多すぎて辞書にしかならないルールはプロジェクト内で辞書を持ったほうが柔軟に扱える感じがしている。英単語のスペルを元にしたルールは、古くからある慣用句だけが例外なので、無限に増えないイメージがある。統一に振りすぎると違和感がある例外がでてきて、それはfalse-positiveになりかねないというのを避けたい)

あと、発音をベースにした実装はまだないですね…
アメリカ英語とイギリス英語の問題とか、単語と発音の結びつけをやる仕組みが思いついてないのでまだないですね。。

@kn1cht
Copy link
Author

kn1cht commented Jan 5, 2020

ご回答ありがとうございます。
JISの原則は単語が2音以下か3音以上かで決まり、例外は「拗音を1音と数えない」だけなので、発音を考慮せずにカタカナ語抽出 & 形態素解析だけで実装できそうです。

monorepo内に同じにようにpresetパッケージ追加する

のは、こちらのリポジトリの構成を変えて対応することになりますか?

既に/packageがあるのを見落としておりました。無視してください。

@kn1cht
Copy link
Author

kn1cht commented Jan 5, 2020

JISの原則は単語が2音以下か3音以上かで決まり、例外は「拗音を1音と数えない」だけなので、発音を考慮せずにカタカナ語抽出 & 形態素解析だけで実装できそうです。

考えたら流石にそこまで単純ではありませんでした。

  1. 「コンピューター」を「コンピュータ」と修正させたいケース
    /[ア-ンー]*ー/を探してチェックするだけ
  2. 「カバ」を「カバー」と修正させたいケース
    元になった単語の綴り(cover)から、長音の要不要を判定する必要がある

後者にも対応するなら、

  • textlint-rule-kana-english-suffix-*の各ルールに「JISの長音ルールを適用するか」のオプションを付ける
    • オプション有効な時は「2音以下で長音がなかったらエラー」「3音以上で長音があったらエラー」とする
  • 音数を数える部分は共通なので、preset-foreign-language-writing-helperに実装して呼び出す

(「カバー」を「カバ」と書きたがる人はほとんどいない気もしますが……)

@azu
Copy link
Member

azu commented Jan 7, 2020

JISの原則は単語の音の数で決まるので、他のtextlint-rule-kana-english-suffix-*と共存することってあるんですかね?
@textlint-ja/textlint-rule-kana-english-suffix-ware は一緒に使えそうだけど、他の長音を扱う場合はJISルールが優先されて、そのJISルールだけで形が決まりそうな気もします。
なので、textlint-rule-kana-english-suffix-jis みたいなルールを作って、presetでは他のsuffix系ルールを入れないとかで対応した方がいいのかもしれないですね。
(各ルールにオプションを入れても、JISルールが強すぎるのであんまり共存してる意味がない気もします)

@azu azu added the Status: Proposal Request for comments label Jan 9, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: Proposal Request for comments
Projects
None yet
Development

No branches or pull requests

2 participants