text = text.replace(/フォルダ/g, "フォルダー");
	text = text.replace(/フォルダーー/g, "フォルダー"); //長音の重複を正す

	text = text.replace(/フォルダー?/g, "フォルダー");

とすれば一発でいけるかもしれません。

//長音の重複を正す

長音2つ（ーー）をまず1つに置換してから、それぞれの単語を置換した方が処理はすっきりする気がしました。
目視で置換部分を全部見ながら置換しないと余計な部分を置換しそうですけど。

@k-takata @arigayas
コメントありがとうございます。
「何をして」「何が注意点なのか」を明示するために、意図的に正規表現を最適化しておりません。
例示が冗長なのはそのとおりで申し訳ないですが、マクロの処理内容を議論しても問題は解決しません。

表記の問題を解決したいのであって、これに対応するのかについて検討いただきたく思います。

はじめまして。

以下はGrepダイアログの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音と数えるのかな？

日本語というか「カタカナ」ね。

脱線だけど、主観的におもしろかったので色々考察。

@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 は内閣告示に従っている、にも疑問符が付くと思います。
「何かの規格に従ってないといかんのか？」というとそうてはないです。
個人的には「○○の規格に準拠してます。」と言えたほうがラクじゃね？と思いますが、必須じゃないです。

オトシドコロとして、個々の単語について１つずつ
「これはキモいよね？」とやっていくのが合意しやすそうに思いました。
数が多いと表示の影響確認がキツいですし、「ここは表示しないから修正不要」の判断もツラいです。

日本工業規格(JIS)には次のような規定があるそうです。

アルファベットをカタカナで表記する場合、
「2音の用語は長音符号を付け、3音以上の用語の場合は長音符号を省く」

JIS Z 8301の附属書ですね。
ただ、この規格は2019年に改定されており、最新の版ではそのような規定はなくなりました。

外来語の表記は最新の JIS Z 8301:2019で次のように規定されています。

JIS Z 8301:2019 規格票の様式及び作成方法
附属書H（規定）文章の書き方並びに用字，用語，記述符号及び数字

H.6 外来語の表記

外来語の表記は，主として“外来語の表記（平成3.6.28 内閣告示第2号）”による。

この附属書においては、上記のほかに外来語表記に関するルールは設けられていません。

規格で引用されている告示は文化庁のホームページで読めます。
文化庁 | 国語施策・日本語教育 | 国語施策情報 | 内閣告示・内閣訓令 | 外来語の表記

内閣告示では「慣例によって長音符を省くことができる」となっていますが、マイクロソフトは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さんから指摘されています（ #1836 (comment) ）が、

#1822 では「インタープリター」を正しい表記としているので、「インタープリタ」に統一するのが正しいのかどうか判断が付きません。
カタカナ表記 Google検索
インタープリター 1,170,000
インタープリタ 78,300
インタプリター 97,100
インタプリタ 590,000

このissueについてはどの表記で統一するかのコンセンサスが得られていません。
この状況下で作業を行っても、レビューは困難かと思います。

@Rukoto さん
sanomari さんも述べていますが、元の提案と異なる表記に統一することになるかもしれません。
ご希望に添えないことをご了承願います。

@berryzplus
あれから考えてみましたが、Microsoftスタイル案は同意を得られそうにないので採用しない方向で行きます。
現時点では一般的な辞書の表記に合わせるのが良いと思っているのですがいかがでしょう。

あれから考えてみましたが、Microsoftスタイル案は同意を得られそうにないので採用しない方向で行きます。
現時点では一般的な辞書の表記に合わせるのが良いと思っているのですがいかがでしょう。

Microsoftスタイルは、WindowsをどういうOSにしていきたいかを表明したものなので、現在のサクラエディタの開発速度が非常に遅いことを考えると容易には追従できないように思っています。

「一般的な辞書」が具体的に決められるなら「辞書の表記に合わせる」で異論ないです。

• Wikipedia日本語版
• Weblio辞書
• イミダス 現代人のカタカナ語辞典

インタープリタのとこで書きましたが、Wikipediaには「曖昧さ回避」のページがあるので使いやすいと思います。

実際のところ、語句によって「絶対に直すべき」「どっちでも可」「統一を優先」など、スタンスが微妙に異なります。
@sanomari さんの指示を受け、個別のPRに意見を書いておきます。

例え希望と違う結果になっても、「これがサクラエディタだ」という結果が残るだけで、
私は本件にそれ以上を望みませんし、代理で対応いただいている皆様に感謝するのみです。

PRの代理を願ったのは、rebase等が発生した場合に小生のスキル不足でご迷惑をかけたくない為で、ご容赦ください…。

ソースコード上のコメントの表記については態度保留です。

一点「ヘッダー」「フォルダー」など長音が付加される場合について、ダイアログ上の表示を修正することがあったら見切れてしまわないかの確認だけは、したほうがいいかな、と思います。
修正の際には考慮していただきたく、よろしくお願いします。
欲をいえば可能であればDPIが120%のとき限定で見切れることもあるため、注意してほしいです。

長音記号が増減（特に付加）する場合は UI が崩れないかの確認が必要になります。

一応、名誉のために書いておきますが、最初から提案者のRukotoさんがこのように書いてあるので、既出でした。すみません、見逃してました。

一般的な辞書の表記

翻訳作業向きといわれる（最終改定年が新しめの）英和大辞典を引きましたが、このような表記がなされていました。

"capture"と"usability"に対するカタカナ語での翻訳例は掲載されていませんので他の辞書から：

もちろん（専門家の監修を受けた）その他の辞書を参考にしても良いでしょう。

僕以外の方が動いているのでアサインを外しました。

表記ゆれのPRをマージしました。
レビュー参加していただいた方々ありがとうございました。

表記をOSと合わせる修正として以下が残っています。

フォルダとプリンターが重たいので、PR作成しようと思います。

一般的な辞書の表記

翻訳作業向きといわれる（最終改定年が新しめの）英和大辞典を引きました

「翻訳作業向き」に少し引っ掛かりました。
欲しいのはたぶん「英単語に対応するカタカナ表記（≒日本語）」です。

「翻訳と何が違うの？」と聞かれるとキビしいですが、
たとえばprinterに対しては、訳語「印刷機」じゃなく「プリンター」が欲しいわけです。
この種の用途に耐える辞書は「カタカナ語辞典」とか「新語辞典」とかになる気がします。
本当言うと「IT用語辞典」が一番よいように思うんですが、IT用語辞典は廃止された古いJIS規格の影響を強く受けてる気がするので「あえて選択肢から外す」のかな、と思います。

テキストの表記を合わせる変更をする事に抵抗は無いですが、全てのPRの変更でテキストの表記がきちんと合っているかを毎回確認出来るかというと、校正作業になってしまいそうで（自分には）難しそうです。

表記が合っていない箇所や表記ゆれがある事に気づいたらコメントをする事はあるかもしれませんが、それだけを持ってしてPRをApproveしないという事は（自分は）しません。

本来は余地がある事に関して厳密に基準を設けてそれをクリアしていないと通らないようにする、だと身動きが取りづらいかなと思います。他の人がそれぞれの基準で確認する事は構わないと思いますが、それが全体に適用されると大変そうかなと思うので。

一点「ヘッダー」「フォルダー」など長音が付加される場合について、ダイアログ上の表示を修正することがあったら見切れてしまわないかの確認だけは、したほうがいいかな、と思います。 修正の際には考慮していただきたく、よろしくお願いします。 欲をいえば可能であればDPIが120%のとき限定で見切れることもあるため、注意してほしいです。

これについては問題がある事に気づいた時に誰かが直せば良いんじゃないかと思います。

PR作成する人が色々なDPIできちんとチェックが出来るかというと現実的には厳しいかなと…。PRのコメントで指摘された場合には直すべきだとは思います。

「プリンター」と「ドライバー」、「フォルダー」の表記合わせをマージしてきました。
これで、issueの問題提起に対して「修正したい」と思った修正の対応がすべて完了しました。
beruさんberryzplusさんレビューありがとうございました。

issueを分けたほうが良いかも知れませんが、「プロパティー」(長音記号削除)の提案についてのコメントです。

該当箇所は1つだけで、こんなんなので、誤記として訂正すべきと思われます。

誤： PlatformToolset 指定をプロパティーシートに分離して
正： PlatformToolset 指定をpropsファイルに分離して

propsファイル とは、MsBuildターゲットのビルドプロパティを定義するXMLファイルです。
targetsファイルと同様に、プロジェクトファイルの一部を外部化したものです。
Win32開発者が思い浮かべる「プロパティシート」とは関係ないので、
「プロパティシートファイル」と呼称するのには違和感があります。

ビルドプロパティは当初、本当に「プロパティシート」で編集させていたので一概に「間違い」とは言えないです。
あと、すっごく頑張ればビルド設定のプロパティシート的UIに表示する選択肢を制御できるので、
Windowsをよく知らない人にとっては「プロパティーシートファイル」で良いような気もします。

言いたかったのはつまり「プロパティー」は誤記なので、
issueとは関係なく対処すべきなんじゃないか？
ということでした。

issueを分けたほうが良いかも知れませんが、「プロパティー」(長音記号削除)の提案についてのコメントです。

#866 (comment)

PRのタイトル名に プロパティーシート を入れるように提案したのは自分ですね。

props ファイルはVisual StudioのGUIのProperty Managerで追加したり内容をダイアログで編集する事が出来るものですね（Visual StudioのGUIはなるべく使わずにCLIでビルドする人もいると思いますが）。で、Property Sheet という表記がされていてMicrosoftのサイトでも プロパティ シート と書かれています。なので間違いというわけではなく公式でもそういうように呼ばれているものです。

多分Win32プログラミングのコモンコントロールのプロパティシートと名前が同じなので違和感があるという事なのかなと思います。

https://docs.microsoft.com/en-us/windows/win32/controls/property-sheet-reference

個人的にはあまり意味のある事とは思えないですが、何かを変えたいなら変えればよいと思います。

PRのタイトル名に プロパティーシート を入れるように提案したのは自分ですね。

たまたまだと思いますが、変更前にapproveしてますね。

beruさんが提案した通りに修正してるので、まぁそういうことですな...。

日本語ドキュメントの記載は「プロパティシートファイル」なので、
変更に気付いていたら 「プロパティーシート」ぢゃねーよ と突っ込んだかも知れません。

どうだったか記憶にないのですが、
気付いたとしてもPRタイトルを元に戻す意義を感じられないので放置する気がします。

個人的にはあまり意味のある事とは思えないですが、何かを変えたいなら変えればよいと思います。

PRタイトルがそうなった経緯を知らずに「対応すべき」と書きましたが、
事情を知ったら修正する意義を感じられなくなったので
「プロパティー」の修正は不要と思います。