sakura
sakura copied to clipboard
古い表記のテキストを動作環境のOSとある程度同等にしたい
問題内容
動作環境が Windows 10 であるのに対して UI やヘルプのテキスト表記が古いままで、 現行の OS 標準の表記との差異はあるために操作中に違和感を感じることがあります。 フォルダ/フォルダーなど、多用されるテキストは目立ってきたので修正したいです。
修正対象と考えているテキストは、後述のマクロ内に記載したもののみです。 (目立つ部分のみをピックアップしており、スタイルガイドに準拠せよという意味ではないです。)
関連して表記誤りや表記の混在も一部修正対象に含めています。
再現手順
印刷プレビューで [プリンタ] ボタンを押すと、 ウィンドウタイトルが「プリンターの設定」となり、 プリンタ/プリンターの表記の差異が不整合であるように「見える」、など…
問題のカテゴリ
- 仕様の問題
- ドキュメントの問題
サクラエディタ自体が長きに渡り開発されていることもあり、 改定された MS のスタイルガイドから逸脱している部分が相当数存在しています。 (フォルダ/フォルダーの表記改定は Vista 以降であり、時間も十分に経過している)
環境情報
- OS バージョン Windows 10 Pro 64bit
- サクラエディタバージョン サクラエディタ開発版32bit Ver. 2.4.2.0 Build 4099
修正手順(例)
スマートでない書き方で申し訳ないですが、マクロ(.js)調で記述しています。 PR ではなく Issue としたのは当方にコード修正・管理スキル的に自信がないからです。 もし修正となった場合には、お手数おかけすること申し訳なく思います。
マクロ調で記載してはいるものの、所定のソースディレクトリ以下に対して 上の行から順にGrep置換を手動で行えば修正完了、となるはずです。 (ヘルプ等に改訂履歴があれば避ける必要があるかもしれませんが)
長音記号が増減(特に付加)する場合は UI が崩れないかの確認が必要になります。
(function(){
if(Editor.IsTextSelected() == 0) Editor.SelectAll();
var text = Editor.GetSelectedString(0);
//修正が必須と考えるテキスト (長音付加)
text = text.replace(/フォルダ/g, "フォルダー");
text = text.replace(/フォルダーー/g, "フォルダー"); //長音の重複を正す
text = text.replace(/コンピュータ/g, "コンピューター");
text = text.replace(/コンピューターー/g, "コンピューター"); //長音の重複を正す
text = text.replace(/ユーザ/g, "ユーザー");
text = text.replace(/ユーザーー/g, "ユーザー"); //長音の重複を正す
text = text.replace(/ユーザービリティ/g, "ユーザビリティ"); //直前の変更による誤爆を修正
text = text.replace(/サーバ/g, "サーバー");
text = text.replace(/サーバーー/g, "サーバー"); //長音の重複を正す
text = text.replace(/ブラウザ/g, "ブラウザー");
text = text.replace(/ブラウザーー/g, "ブラウザー"); //長音の重複を正す
text = text.replace(/ヘッダ/g, "ヘッダー");
text = text.replace(/ヘッダーー/g, "ヘッダー"); //長音の重複を正す
text = text.replace(/フッタ/g, "フッター");
text = text.replace(/フッターー/g, "フッター"); //長音の重複を正す
text = text.replace(/エンコーダ/g, "エンコーダー");
text = text.replace(/エンコーダーー/g, "エンコーダー"); //長音の重複を正す
text = text.replace(/デコーダ/g, "デコーダー");
text = text.replace(/デコーダーー/g, "デコーダー"); //長音の重複を正す
text = text.replace(/ドライバ/g, "ドライバー");
text = text.replace(/ドライバーー/g, "ドライバー"); //長音の重複を正す
text = text.replace(/プリンタ/g, "プリンター");
text = text.replace(/プリンターー/g, "プリンター"); //長音の重複を正す
text = text.replace(/モニタ/g, "モニター");
text = text.replace(/モニターー/g, "モニター"); //長音の重複を正す
text = text.replace(/インストーラ/g, "インストーラー");
text = text.replace(/インストーラーー/g, "インストーラー"); //長音の重複を正す
// text = text.replace(/アンインストーラ/g, "アンインストーラー"); //直前の変更で置換済み
//修正必須と考えるテキスト (長音削除)
text = text.replace(/メモリー/g, "メモリ");
text = text.replace(/エントリー/g, "エントリ");
text = text.replace(/キャプチャー/g, "キャプチャ");
text = text.replace(/プロパティー/g, "プロパティ");
//表記の修正
text = text.replace(/アンダーバー/g, "アンダースコア"); //アンダーラインとは別
text = text.replace(/プロクシ/g, "プロキシ");
//混在しているテキストの統一
text = text.replace(/インターフェイス/g, "インタフェース"); //インタフェース(誤)に仮置き換えして対象統一
text = text.replace(/インタフェイス/g, "インタフェース"); //インタフェース(誤)に仮置き換えして対象統一
text = text.replace(/インターフェース/g, "インタフェース"); //インタフェース(誤)に仮置き換えして対象統一
text = text.replace(/インタフェース/g, "インターフェイス"); //インターフェイス(正)に置き換え
text = text.replace(/インタープリター/g, "インタプリタ"); //インタプリタ(誤)に仮置き換えして対象統一
text = text.replace(/インタープリタ/g, "インタプリタ"); //インタプリタ(誤)に仮置き換えして対象統一
text = text.replace(/インタプリター/g, "インタプリタ"); //インタプリタ(誤)に仮置き換えして対象統一
text = text.replace(/インタプリタ/g, "インタープリター"); //インタープリター(正)に置き換え
Editor.InsText(text);
})();
text = text.replace(/フォルダ/g, "フォルダー"); text = text.replace(/フォルダーー/g, "フォルダー"); //長音の重複を正す
text = text.replace(/フォルダー?/g, "フォルダー");
とすれば一発でいけるかもしれません。
//長音の重複を正す
長音2つ(ーー)をまず1つに置換してから、それぞれの単語を置換した方が処理はすっきりする気がしました。 目視で置換部分を全部見ながら置換しないと余計な部分を置換しそうですけど。
@k-takata @arigayas コメントありがとうございます。 「何をして」「何が注意点なのか」を明示するために、意図的に正規表現を最適化しておりません。 例示が冗長なのはそのとおりで申し訳ないですが、マクロの処理内容を議論しても問題は解決しません。
表記の問題を解決したいのであって、これに対応するのかについて検討いただきたく思います。
はじめまして。
以下はGrepダイアログのUIリソース定義の一部です。 https://github.com/sakura-editor/sakura/blob/b5d590011f05e93ec423f5d3fe03dcbae1849eef/sakura_core/sakura_rc.rc#L147 このようなUI上の「サブフォルダ」表記などを最新のスタイルガイドに準拠するよう修正して欲しい、という要望で正しいでしょうか?
MS のスタイルガイド
これかな? ローカライゼーションスタイルガイド https://www.microsoft.com/ja-jp/language/styleguides
@kazasaku 要望としては概ねそのとおりですが、ヘルプやソース内コメントも含めた全体に適用して構わないという認識です。 ただし、「改版履歴」などは期待する変更を受けてはならない部分なので除外されます。
MSのスタイルガイドについては、まさにこのページからダウンロードできるPDFです。 ただし、直してほしい個々テキストについての言及は、さらに参考文献として位置づけられています。 具体的には、PDF内で「内閣告示」を検索して頂ければ、いつの告示に従って表記が改定されてかがわかり、 マイクロソフトはOSレベルにおいてはVistaと同時に内閣告示に従ったという流れになります。 それらの背景に関する「読み物」としての参考リンクを貼っておきます。 https://toyokeizai.net/articles/-/166386
その内閣告示に従ったマイクロソフトは訳語を検索できるデータベースを公開しています。 @kazasaku 様の挙げたページからダウンロードもできますが Web上で訳語の検索が可能になっています。 https://www.microsoft.com/ja-jp/language/
さて、サクラエディタ内にはガイド(内閣告示)に沿っていないテキストが多数あるわけですが、 本Issueでは「フォルダ/フォルダー」のように多用されるテキストにある程度限定して修正したく、 サクラエディタ内で置き換えるべきテキストを私の判断で抽出しましたものが、後述にて列挙したものです。
修正作業を最も簡潔に書くならばば、「レポジトリ全体を以下のテキストに限定して置換できませんか?」です。 先に指摘のある通り、改版履歴を改ざんしたり、関係ないテキスト(「ユーザビリティ(正)」等)に影響を与えないように作業する必要はあります。
//修正が必須と考えるテキスト (長音付加) フォルダ→フォルダー コンピュータ→コンピューター ユーザ→ユーザー ユーザービリティ→ユーザビリティ //直前の変更による誤爆を修正
サーバ→サーバー ブラウザ→ブラウザー ヘッダ→ヘッダー フッタ→フッター エンコーダ→エンコーダー デコーダ→デコーダー ドライバ→ドライバー プリンタ→プリンター モニタ→モニター インストーラ→インストーラー
//修正必須と考えるテキスト (長音削除) メモリー→メモリ エントリー→エントリ キャプチャー→キャプチャ プロパティー→プロパティ
//表記の修正 アンダーバー→アンダースコア //アンダーラインとは別 プロクシ→プロキシ
//混在しているテキストの統一 インタフェイス→インターフェイス インタフェース→インターフェイス インターフェース→インターフェイス
インタープリタ→インタープリター インタプリター→インタープリター インタプリタ→インタープリター
総合的に考えて「やらなくていい」と思いました。
ユーザーが認識できるなら表記はなんであっても構わない、が自分の見解です。
長音記号があったりなかったりすると「ユーザーが認識できないか?」というと「No」になると考えるからです、
ただ、「表記ゆれがあるとキモい」には同意します。
参考まで。 Google検索「カタカナ 末尾 長音記号 規格」
サクラエディタの歴代開発者は「それなりに文化人」なので、上記参考URLで出てくる日本工業規格による推奨事項を認識したうえで作ってる場合が多いと思います。
マイクロソフト日本法人による日本語翻訳が「おかしい」のは周知の事実だと思っています。 (この点を突っ込むと「そこは機械翻訳です。」と回答されますね・・・本当か?)
おかしい可能性が高いガイドラインに合わせて修正を行う、はあり得ないです。
表記がブレてるのがキモいんじゃ~!には大賛成ですが、issueの趣旨と違う気がします。
@berryzplus ご意見ありがとうございます。貴殿が前向きでないことは非常に残念です。 本Issueは要するに「品質の向上」であって、機能的な問題ではないし、使用上問題ないという意見は理解できます。 ですが逆説的には「表記が改まっても使用上問題なければ直しても構わない」とも私には読めます。
「表記ゆれがあるとキモイ」を解決するのに、それほど労力(修正コスト)がかからないことは、改めて強調したいです。
他のコントリビューターの方はいかがでしょうか?
おかしい可能性が高いガイドラインに合わせて修正を行う、はあり得ないです。
私は海外製ソフトウェアのアマチュア翻訳を行っている者ですが、その経験と立場からの見地を申しますと、 趣旨は「ガイドラインに合わせよ」ではなくて、OSの表記と目立つ部分で違うのは「キモイ」ので直そうという話です。
個々のソフトウェアごとに表現の文化はあり、当方の作成物でもそれを尊重しているのですが、 頻出語がブレているのは文化とか関係ないレベルの話なので、直せるなら直したほうがいいという考えです。
説明する上で MS スタイルガイドを持ち出さなければならないので混同されそうですが、当方の意図とは違うことは明言します。
- 表記ゆれを直したい、はagreeです。
- Windowsの類似機能と表記を合わせたい、は(モノによりますが)agreeです。
日本工業規格(JIS)には次のような規定があるそうです。
アルファベットをカタカナで表記する場合、 「2音の用語は長音符号を付け、3音以上の用語の場合は長音符号を省く」
JIS規格に従うと、以下の整理となります。
誤記 | 規格準拠 |
---|---|
ヘッダ | ヘッダー |
フォルダー | フォルダ |
なんとなく否定的な書きっぷりにしてある理由は、 修正案の例示がJIS規格とズレているように感じたからです。
マイクロソフトのガイドラインは所詮「日本誤訳」だと思っとります。。。
ん?日本語は表音文字だから「ヘッダ」は3音と数えるのかな?
日本語というか「カタカナ」ね。
脱線だけど、主観的におもしろかったので色々考察。
誤記(?) | JIS規格準拠(?) | JIS規格準拠 |
---|---|---|
レバー | レバー | レバー |
ヘッダー | ヘッダ | ヘッダー(撥音は数えない) |
メニュー | メニュ | メニュー(拗音は数えない) |
ツールバー | ツールバ | ツールバー(単語区切りを考慮する) |
@berryzplus 私のリストの右側は内閣告示に従ったものになっております。自信を持って告示準拠かつWindows10と同等と主張しますが、 個々の根拠を明示するのは非常に大変なので、私を信用してほしい、というのが本音です。 結果として、すべて Windows 10 の表記に合致しますので、リストの右側への変更をお願いする要望となります。
ご考察まで頂いており大変申し訳ないのですが、そこに「JISでは~」、とかを考慮する余地がまったくなくなってしまうのです。 MSのガイド・JIS規格・JTF・どれが正解とも言えず、目立つ部分で動作環境OSに合致してないことが明確な問題です。 故に修正対象を20個程度に絞っています。厳密なガイドやJIS準拠だと矛盾が発生し、ゴールが闇に埋もれてしまうので。
先に挙げた「読み物」のリンクの3ページ目は読まれましたでしょうか? この記事を100%信用しろとは言いません。ですが、考慮いただきたいことはこの記事に書いてある、まさにそのとおりなのです。 時代や影響の範囲を鑑みてJISも柔軟な対応をとっていることが、今回のIssue化した根拠であり、後ろ盾でもあります。
https://toyokeizai.net/articles/-/166386?page=3
一般的には内閣告示に従い、音引きは省略しませんが、工業系・通信IT系分野ではJIS規格に従い、特定条件でカタカナ語句の音引きを省略します。その理由は、初期のコンピューター上で扱えるデータ量が非常に小さく、1文字でも削ってデータ量を減らしたかったためだといわれています。
しかし、音引きを省かない記述のほうがメジャーである今、そうした書き方は文章上での言葉の揺らぎを生む原因になります。
近年ではJIS規格もこうした事情を勘案し、内閣告示のルールに準拠することも認めるとしています。
正直、音引きの省略は時代遅れだと思います。Windows 10で使うアプリなのでOSの表記に合わせた方がよいという主張もその通りだと思います。Windows 10の表記に合わせるのに1票。
僕も「OSの表記に合わせる」に賛同します。 OSの表記との違いが気になるという話でJIS規格を持ち出されても、じゃあ「OSの表記はJISに準拠しているのか」という疑問が生じます。 この疑問を晴らせない限りは「JISにあわせる」では解決できないでしょう。
スタイルガイドは英語版がオリジナルのソフトウェアを日本語版に翻訳する場合に参照されている、という理解でいますが、Windowsのオリジナルは英語版だと思うので、日本語版Windowsに合わせてスタイルガイド準拠にする、という方向でも良いでしょう。 もちろん、そのときは英語版サクラエディタも英語のスタイルガイドに準拠させるべきだと思います。
ただし、一般ユーザーから直接見えないソースコードやリソース定義中のコメントまで直す必要は感じられません。
「古い」と「悪い」は同義ではないと考えています。
実装に関する話題では「レガシーコード」を排除しようと動いています。 レガシーコードは文字通り「負のコード資産」です。 単に「古い」ではなく「検証できない」をレガシーコードと呼んでいます。 コードの正当性が確認できるなら、20年間触っていない超古いコードであっても触る気ないです。 古いコードを駆逐してるように見えるかも知れませんが、実はそんなことはしてないつもりです。
文言に関しても、単に「古臭い」は「改修すべき」の直接理由にはならないと思っています。
で、このissueの話。
- サクラエディタの中ではJIS規格に従い(?)、「printer」を「プリンタ」と表示している。
- Windows 10 では近年の内閣告示に従い(?)、「printer」を「プリンター」と表示している。
- サクラエディタ内でOSのダイアログを表示した場合、表示文言がズレる。👈これがキモい。
表記ゆれがキモいので直したい、はagreeです。 「プリンタ」を「プリンター」にするのはagreeです。 明確な根拠を持って設定された誤記でないOSの記載と合わせに行くのは「正しい」と思います。 ※内閣告示の妥当性に疑問符が付く点は置いておきます。 スマホすら使ったことない爺ちゃんが発令した告示を尊重すべき理由が不明瞭だと思います。 政治屋は、政治でしか解決できない課題の解決に尽力してほしいです。コロナ問題とかウクライナ侵攻とか。 (日本工業規格が「政治でしか変えられない」としたら、ぼくらの業界ヤヴァいですね・・・)
サクラエディタはJIS規格に従っている、に疑問符が付くのと同様に、 Windows 10 は内閣告示に従っている、にも疑問符が付くと思います。 「何かの規格に従ってないといかんのか?」というとそうてはないです。 個人的には「○○の規格に準拠してます。」と言えたほうがラクじゃね?と思いますが、必須じゃないです。
オトシドコロとして、個々の単語について1つずつ 「これはキモいよね?」とやっていくのが合意しやすそうに思いました。 数が多いと表示の影響確認がキツいですし、「ここは表示しないから修正不要」の判断もツラいです。
日本工業規格(JIS)には次のような規定があるそうです。
アルファベットをカタカナで表記する場合、 「2音の用語は長音符号を付け、3音以上の用語の場合は長音符号を省く」
JIS Z 8301の附属書ですね。 ただ、この規格は2019年に改定されており、最新の版ではそのような規定はなくなりました。
外来語の表記は最新の JIS Z 8301:2019で次のように規定されています。
JIS Z 8301:2019 規格票の様式及び作成方法 附属書H(規定)文章の書き方並びに用字,用語,記述符号及び数字
H.6 外来語の表記
外来語の表記は,主として“外来語の表記(平成3.6.28 内閣告示第2号)”による。
この附属書においては、上記のほかに外来語表記に関するルールは設けられていません。
以前の版(JIS Z 8301:2008)での規定
JIS Z 8301:2008 規格票の様式及び作成方法 附属書G(規定)文章の書き方,用字,用語,記述符号及び数字
G.6.2 外来語の表記
G.6.2.1 一般
外来語の表記は,主として 外来語の表記(平成 3.6.28 内閣告示第二号) による。片仮名書きの外来語を用語にすることは極力避けなければならないが,やむを得ず採用する外来語の表記に一般的に用いる仮名(長音記号を含む。)は,表 G.1 の中から選び,その外来語に最も近い音(以下,外来音という。)に対応する仮名は,表 G.2 から選ぶ。ただし,慣用が定まっている場合には,それぞれの慣用による(G.6.2.2参照)
G.6.2.2 英語の語尾に対応する長音符号の扱い
英語の語尾に対応する長音符号の扱いは,通常,次による。 なお,英語の語末の -er,-or,-ar などは,ア列の長音とし,長音符号を用いて表すものに当たるとみなす。
a) 専門分野の用語の表記による。 b) 規格の用語及び学術用語にない用語の語尾に付ける長音符号は,表 G.3 による。
上記文中の表は次のものを指しています。
- 表 G.1−外来語の表記に一般的に用いる仮名
- 表 G.2−外来語を原音・原つづりに近く書き表そうとする場合に用いる仮名
- 表 G.3−外来語の表記に語尾の長音符号を省く場合の原則
表 G.3
原則 | 例 |
---|---|
a) その言葉が3音以上の場合には,語尾に長音符号を付けない。 | エレベータ(elevator) |
b) その言葉が2音以下の場合には,語尾に長音符号を付ける。 | カー(car), カバー(cover) |
c) 複合の語は,それぞれの成分語について,上記 a)又は b)を適用する。 | モータカー(motor car) |
d) 上記 a)~c)による場合で,長音符号を書き表す音(例1),はねる音(例2),及びつまる音(例3)は,それぞれ1音と認め,よう(拗)音(例4)は1音と認めない。 | 1 テーパ(taper) 2 ダンパ(damper) 3 ニッパ(nipper) 4 シャワー(shower) |
規格で引用されている告示は文化庁のホームページで読めます。 文化庁 | 国語施策・日本語教育 | 国語施策情報 | 内閣告示・内閣訓令 | 外来語の表記
内閣告示では「慣例によって長音符を省くことができる」となっていますが、マイクロソフトはVistaの翻訳以降省かない選択をしたようです。
日本工業規格は、昔の規定を破棄していて、 公文書を作成するための「法律」に従え、 と言ってるわけですね。工業規格なのに。
つまり「ぼくらの業界ヤヴァい」ってことですね(笑
全然笑えないです。 こういうやり取りをしているから関わりたくないと思う人が増えていくんだろうなと思いました。
@kazasaku 概ね修正の方向でご対応いただいていること、感謝申し上げます。 コメント部分を修正しないことについては消極的な印象はありますが、小生の立場からはこれ以上申し上げることはありません。 メンテナの方々に遺恨の残らぬよう改善が進むのであれば、ユーザーの身としては何の不満もありません。 ご対応のほど、よろしくお願いします。
真面目な話、古いから修正すべき、には同意したくないです。
ただし、アプリが表示する「OSのUI」とアプリの間で差異があることは「不適切だ」と考えるので、 このissueで提案している修正の「大部分」に賛成できると思います。 PRは「賛成できない部分」がなくなるまで通らないので、この修正案を一括でPRにすることはお勧めしません。
issueの本文では「ヘルプファイル」も修正すべき対象に挙げていることから、 UI表示しないソースコード中のコメントを除外する気はないことが見てとれます。
実際のところ、機能を作った人にヘルプファイルを整備する責任はないので、 ヘルプファイルは後世の有志によって作られてきた経緯があると思っています。 コメントは、その際に機能の概要を把握するために使われますから、 対応するなら同時に直したほうがより良い対応になると思います。
同意してはマズいと思った項目を列挙しておきます。
text = text.replace(/メモリー/g, "メモリ");
memory を「メモリ」とすると「目盛」と区別しにくくなって困ります。 これはWindows 10の表記とは関係ない、サクラエディタ内部の都合です。
Windows 10のカタカナ英語は「工業用語はJIS方式、一般化したものは末尾長音を付ける」でやってそうなので、現状の「メモリ」は「メモリー」に、遷移的に置換される可能性があると思います。
既にWindows用語として定着している「プロパティ」を変更することはないと予想するので「プロパティー」を「プロパティ」に変えるのは容認です。
「フォルダ」を「フォルダー」に変えてしまっているので絶対に「プロパティー」にはならないと言い切れませんが。
text = text.replace(/アンダーバー/g, "アンダースコア"); //アンダーラインとは別
記号の名前としては under score
が正しいです。
しかし、「アンダーバー」はアンダースコアを指す和製英語なので、
誤訳や表記ミスを直す修正とは意味合いが違います。
個人的に「言葉狩り」はしたくないので同意しません。
text = text.replace(/インタフェース/g, "インターフェイス"); //インターフェイス(正)に置き換え
interface
のカタカナ表記はインターフェースが正しいと思います。
既に定着している日本語読みを覆そうとする試みは「概ね正しくない」と思います。
Windows 10 が「インターフェイス」と表示しているなら「日本語的に正しくない」と思うので、
マイクロソフトに修正提案したほうがよい気がします。
詳細は各変更のPRで個別に確認するので、 提示された変更理由によっては結論が覆る可能性はあります。
「インターフェース」に関しては利用箇所がかなり多いので、慎重に判断すべきと思います。
PRは「変更したい人」が作成するのが「筋」だと思います。 どんな感じに?のイメージを持ちづらい場合はメンバーが代わりにPRを作ったりもします。 代行で作ると発案者の意図と微妙に異なる提案になってしまうので、可能ならPR作成までお願いしたいです。
気になっていたので、表記ゆれの是正に関してPR作ってみました。 コードを書く人にとって、簡単に作成できる内容です。 レビューする人にとって、簡単に可否判断できる内容です。 「個別にPRして欲しい」はこういうことなんだと思います。
@Rukoto さん 元の提案と異なる修正を提案していることについてなにかご意見あれば、該当PRにコメントお願いしたいです。 あと、表記合わせについても私がPR作成したほうが良いでしょうか?
@sanomari
beruさんから指摘されています( https://github.com/sakura-editor/sakura/pull/1836#issuecomment-1115885531 )が、
#1822 では「インタープリター」を正しい表記としているので、「インタープリタ」に統一するのが正しいのかどうか判断が付きません。 カタカナ表記 Google検索 インタープリター 1,170,000 インタープリタ 78,300 インタプリター 97,100 インタプリタ 590,000
このissueについてはどの表記で統一するかのコンセンサスが得られていません。 この状況下で作業を行っても、レビューは困難かと思います。
@Rukoto さん sanomari さんも述べていますが、元の提案と異なる表記に統一することになるかもしれません。 ご希望に添えないことをご了承願います。
@berryzplus あれから考えてみましたが、Microsoftスタイル案は同意を得られそうにないので採用しない方向で行きます。 現時点では一般的な辞書の表記に合わせるのが良いと思っているのですがいかがでしょう。
あれから考えてみましたが、Microsoftスタイル案は同意を得られそうにないので採用しない方向で行きます。 現時点では一般的な辞書の表記に合わせるのが良いと思っているのですがいかがでしょう。
Microsoftスタイルは、WindowsをどういうOSにしていきたいかを表明したものなので、現在のサクラエディタの開発速度が非常に遅いことを考えると容易には追従できないように思っています。
「一般的な辞書」が具体的に決められるなら「辞書の表記に合わせる」で異論ないです。
インタープリタのとこで書きましたが、Wikipediaには「曖昧さ回避」のページがあるので使いやすいと思います。
実際のところ、語句によって「絶対に直すべき」「どっちでも可」「統一を優先」など、スタンスが微妙に異なります。 @sanomari さんの指示を受け、個別のPRに意見を書いておきます。
例え希望と違う結果になっても、「これがサクラエディタだ」という結果が残るだけで、 私は本件にそれ以上を望みませんし、代理で対応いただいている皆様に感謝するのみです。
PRの代理を願ったのは、rebase等が発生した場合に小生のスキル不足でご迷惑をかけたくない為で、ご容赦ください…。
ソースコード上のコメントの表記については態度保留です。
一点「ヘッダー」「フォルダー」など長音が付加される場合について、ダイアログ上の表示を修正することがあったら見切れてしまわないかの確認だけは、したほうがいいかな、と思います。 修正の際には考慮していただきたく、よろしくお願いします。 欲をいえば可能であればDPIが120%のとき限定で見切れることもあるため、注意してほしいです。
長音記号が増減(特に付加)する場合は UI が崩れないかの確認が必要になります。
一応、名誉のために書いておきますが、最初から提案者のRukotoさんがこのように書いてあるので、既出でした。すみません、見逃してました。