search

textlint-ja / textlint-rule-preset-foreign-language-writing

[WIP] 外来語（カタカナ）の書き方を扱うtextlintルールプリセット
MIT License
16 stars 2 forks source link

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

Open kn1cht opened 4 years ago

kn1cht commented 4 years ago

概要

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

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

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

検討すべきこと

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

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

azu commented 4 years ago

ただ、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 commented 4 years ago

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

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

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

（２－１）「ウイ／ウィ」「ウエ／ウェ」「ウオ／ウォ」は「ウイ」「ウエ」「ウオ」を充てる。

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

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

kn1cht commented 4 years ago

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

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

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

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

kn1cht commented 4 years ago

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

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

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

後者にも対応するなら、

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

azu commented 4 years ago

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ルールが強すぎるのであんまり共存してる意味がない気もします)