コンテンツにスキップ

Wiktionary:編集室

出典: フリー多機能辞典『ウィクショナリー日本語版(Wiktionary)』

ウィクショナリーにお越しの皆様、ようこそ! ここはウィクショナリー日本語版についての様々な事柄について、皆様と一緒に話し合う、ウィキペディアでいう井戸端に相当する場所になります。告知や意見募集を行いたい場合はWiktionary:おしらせもご利用ください。


This page is used to ask, propose and discuss the operations, policies and new ideas of Japanese Wiktionary. If you just want to inform Japanese Wiktionary editors of something such as a proposal in other place, you can use Wiktionary:おしらせ.


以下ここに書きこむ場合の注意事項です。

  • 自分の意見を述べた場合、文章の最後に署名をしてください(~~~~と打ち込んでください)。
  • 新しい議題を持ち上げるときは、節を使用してください。下のリンクをクリックすると、新しく議題を作ることができます。

ログ

[編集]


近頃の作成されてるアカウントについて。

[編集]

近頃、よくアカウントが作成されています。それはとても良いことなんですが、よく日本語名のアカウントが作成されているんですよ。まあ、それもよいことなんですけど、たまによく似た名前のアカウントが作成されています。(例 利用者:三浦昌子と利用者:三浦晶子など)それらはソックパペットとみてもよいのでしょうか?(確定ではないですが、可能性が高ければブロックしたほうがよさそうです。)特別:ログ/newusersバスかるぱーんトークページも参照--バスかるぱーん (トーク) 2025年4月8日 (火) 03:27 (UTC)[返信]

まだ荒らしていないようだし、無害と見られているので問題ないかと(有害ならすでにここかmetaかでブロックされているはず)「姓名のアカウントは禁止されてはいない(ただし要注意→w:WP:利用者名)」「編集をしない読むだけアカウントは禁止されてはいない」 --Vcvfou698069 (トーク) 2025年4月8日 (火) 09:14 (UTC)[返信]
ですが、「類似する利用者名」で、(荒らしの被害などを避けるために、既存の利用者名とよく似た利用者名も管理者にしか作成することが出来ません。)とあります。--バスかるぱーん (トーク) 2025年4月9日 (水) 05:48 (UTC)[返信]
・w:WP:利用者名に書いてあるのは、”ある程度の”似たような名前はシステムで取れないようになっていることかと
・日本の日本人同士は結婚するときに名字を揃える(変える)しなければいけない
・日本語圏で命名のときに親の名前から1文字取ったりして揃えることはよくあること
言いたいことが伝わったかどうかは不安だが --Vcvfou698069 (トーク) 2025年4月9日 (水) 21:33 (UTC)[返信]

「ソックパペット」に引っ掛かったので言及しておきますが、そもそも「ソックパペット」だとかいう概念も用語も、ウィクショナリーなどのウィキペディア以外の姉妹プロジェクトには存在しない。複数のアカウントがあって健全に利用している分には何ら問題がないし、「投稿履歴の分断」などという訳の分からない投稿ブロック理由は、ない。Wiktionary:アカウント作成者の権限を持った利用者以外でも、一般利用者は1日に最大6アカウントまで作成できますし、不審な動静かは差し置いて、そういう仕様です。--Charidri (トーク) 2025年4月18日 (金) 12:26 (UTC)[返信]

承知しました。取り敢えず「ソックパペット」という言葉はウィキペディア以外では存在しないので、ブロックするは必要ない、ということですね。--バスかるぱーん (トーク) 2025年4月21日 (月) 06:44 (UTC)[返信]
ついでにいうと「多重アカウント」などという まるで不正であるかのような 人の印象を操作する用語は使いませんので、あなたが作ろうとしている「Wiktionary:多重アカウント」は作成しないで下さい。--Charidri (トーク) 2025年4月25日 (金) 15:44 (UTC)[返信]
分かりました。--バスかるぱーん (トーク) 2025年5月2日 (金) 00:29 (UTC)[返信]

「カテゴリ:漢字」のソートキーのルール

[編集]

「カテゴリ:漢字」のソートキーですが、字によって音読みのかなであったりピンインであったりユニコードの番号であったりバラバラなのですが、何か一貫したルールはあるのでしょうか?Wiktionary:カテゴリの付け方#ソートキーには漢字に関する記載が無いのでどなたか漢字のソートキーに関するルールをご存じの方いらっしゃいますでしょうか? --M-30722 (トーク) 2025年4月15日 (火) 16:30 (UTC)[返信]

日本語の音読み(漢音)優先というのが規則だったと認識していますが、どこでそれが決まったのかは分かりません。個人的には、「漢字」だけだと特定の言語に依存していない概念なので、日本語のソートキーを付けるなら「日本の漢字」みたいなサブカテゴリが有用だと思っています。その場合「漢字」カテゴリはUnicode順とか部首順みたいな漢字自体の特徴でソートできるでしょう。なおカテゴリメンバーはUnicode順に並ぶので、Unicode順に並べたいならソートキーを指定する意味はあまりありません。--Naggy Nagumo (トーク) 2025年4月15日 (火) 21:53 (UTC)[返信]
これまでよく見てきた項目では基本的に音読みでソートされていたので慣例でそうなっていたのかも知れません。最近の項目はユニコードでソートされるものが多くなっており統一感が無くなってきているのでしっかりルール化した方が良いかも知れません。日本語以外の言語で使われている簡体字やチュノムについてもソートキーの付け方がバラバラな気がしますのでこれも一緒に決めていくのが良いかと思います。
チュノムについては@Kuroco2kさんがよく投稿してくださっておりますが、私としてはチュ・クォック・グーでソートするのが良いかと考えておりますが、ユニコードの番号順の方がよろしいでしょうか? --M-30722 (トーク) 2025年4月16日 (水) 15:34 (UTC)[返信]
(正直、ソートキーのルールについてよく知らなかったのでとりあえずUnicodeの番号で配列してましたが)確かにチュノムではTemplate:contextとの兼ね合い上、チュ・クォック・グーでソートしたほうが良い時があるので、それを考慮すると変えていくべきでしょう。
その上では、などの朝鮮の国字や、𮆩などの古壮字はもちろん(前者はハングル、後者は古壮字字典のローマ字表記でどうにかなりそうですが)、𨮁のような音未詳の字についても考慮する必要があります。--Kuroco2k (トーク) 2025年4月17日 (木) 08:06 (UTC)[返信]
それではチュノムについてはチュ・クォック・グーをデフォルトでソートすることとしましょう。また、朝鮮の国字と古壮字についてもそれぞれハングルと古壮字字典のローマ字表記で問題ないと思います。音未詳についてはユニコードでのソートにするしかなさそうでしょうか。 --M-30722 (トーク) 2025年4月17日 (木) 12:04 (UTC)[返信]
提案 提案 それでは、改めまして「カテゴリ:漢字」のソートキーについて以下のように提案します。
  • 日本語の音読みがあれば音読みをソートキーとして用いる。
  • 日本語が無く、中国語があれば普通話のピンイン
  • 朝鮮の国字はハングル
  • チュノムはチュ・クォック・グー
  • 古壮字は古壮字字典のローマ字表記
  • 読み方不詳の字はユニコードの番号
以上のルールでいかがでしょうか? --M-30722 (トーク) 2025年4月17日 (木) 13:14 (UTC)[返信]
それでは繁文縟礼です。そして言語横断的でなく恣意的になります。「デフォルトの」ソートキーは Unicode の番号としてください。各個別の言語等のカテゴリではパイプを使って読み方でソートしてください。データベースでいう主キー(プライマリキー)の役割を果たし、16進数のUnicode番号はユニーク(一意)この上ないものです。これ以上優れたものはありません。ソートキーを指定しない場合でも Unicode の配列にはなりますが、カテゴリページが極めて冗長になります(縦長になります)。
ついでに指摘しておくと、テンプレート:kana-DEFAULTSORTはテンプレートであって、{{DEFAULTSORT:}}のようなマジックワードではないので、{{カナ-デフォルトソート|}}のようなことが柔軟にできないことと、日本語の項目に利用するものなので、単漢字には不向きです。単漢字はいわば記号と同じようなもので、言語一般のソートキーとは埒外と考えます。一つのカテゴリにハングルやらローマンアルファベットやらカタカナやらが混在する状況はひじょうに見ぐるしいです。単漢字項目にテンプレート:kana-DEFAULTSORTを使用してしまわないようにしてください
重要なことなのでもう一度書きますが、「デフォルトの」ソートキーとしては Unicode の番号としてください。これは、単漢字のみならず、Unicode上のほかの全ての言語の単一の文字や記号の項目についても適用されます。--Charidri (トーク) 2025年4月18日 (金) 12:26 (UTC)[返信]
私はCharidriさんに同意します。既存の項目は日本語でソートしているものが多いですが、変えられるなら変えたいですね。言語に依存した並べ方をしたいなら、言語ごとのサブカテゴリが有効です。またソートキー指定なしのときに漢字一字ごとにカテゴリページの見出しができてしまって鬱陶しいことについても認識していますが、一方でひとつひとつ異なるソートキーを指定する意味は見いだせずにいます(たとえばソートキーを「*」で統一すればUnicode順に並ぶ)。保守性を考えれば、カテゴライズをテンプレート経由で行うことを徹底するのが役立つかもしれません。--Naggy Nagumo (トーク) 2025年4月18日 (金) 22:45 (UTC)[返信]
それでは、Unicode順に並べる方向で考えていきましょう。テンプレートとしては先日、Vinegar03さんによる大規模な編集により付けられたテンプレート:kanji headerで「カテゴリ:漢字」が付与される仕組みになっているようですが、このテンプレートを編集して「カテゴリ:漢字」に「*」をソートする仕様にすることで容易に出来そうです。 --M-30722 (トーク) 2025年4月21日 (月) 13:30 (UTC)[返信]
テンプレート:kanji headerを編集して「カテゴリ:漢字」に「*」がソートされるようにしてみましたがいかがでしょうか? --M-30722 (トーク) 2025年4月21日 (月) 17:21 (UTC)[返信]
あれは、まず、活動実績が無かった利用者が、突然に、承認のないままテンプレートを適用して標準の内容とは大きく異なるレイアウト改変を決行したことと、あくまで投稿済みの既存の項目を編集しただけにすぎないことが指摘事項として挙げられます。
レイアウトの変更そのものは、目を瞠るものがあり、大きく改善できていると評価できる一方で、既存の文字情報の文字コードを幾つか大量に独断で削ってしまっている点や、テンプレート:unicode code   で囲われた数値参照(これは user:MysteryPedia の顕著な功績と評価できる)を削ってしまっている点など、幾らかは改悪も目立っているものです。ボット的に一挙に変えられてしまったので今更元に戻すのはきびしいです。
そしてもう一つは、投稿済みの項目を編集するのではなく、新たに項目を作成する立場としては、特に私Charidriのような大量作成者の視点としては、テンプレートなどで構造化され過ぎると、ローカル環境で自分が何を書いているのか、ローカル環境で後で見返したときに何を書いたのか、オンラインのコンピューターに移動して投稿する段階でも何を投稿すればよいのか、大量に書いてあるからわからなくなりまちがいのもとになります。そうでなくてもページ上部の記述を「*」等の記号にするよう強制されたら、私はついていけないかもしれません。あくまで私たちが見て書いているのはソースであって、アウトプットされたものを見ながら書くのではないので、デフォルトソートが U+xxxxx の Hex になっていないと識別できないし、デフォルトソートとカテゴリの直書きがある御蔭で、厖大な情報から項目を識別している。あとついでにいうと、もしテンプレート:codepointを強制されたらめいわくです。だいたいからして議論で短いうちにころころ書き方を変えられるのは安定性がなく作り溜めている側からすればいちばんこまる。しかも不在でよくわからないうちに。--Charidri (トーク) 2025年4月25日 (金) 15:44 (UTC)[返信]
何の事前の声掛けも無くあのような大規模な改変が突然行われたのには正直私も困惑しました(pron引数や壊れたファイルの除去については評価できますが)。ただ、テンプレート:kanji headerが非常に多くの項目に使われてしまった以上はこのテンプレートを(想定通りのソートされるよう)調整していかざるを得ないかも知れません。私は漢字項目については専ら加筆に携わっておりますのでソート方法としては作成者側がやりやすいやり方でしていただくのが良いかと思いますが、編集者間でソートのルールがバラバラでは困りますのでそこの統一さえしていただければと思います。
あと、「テンプレート:unicode code」は非推奨のテンプレートではないので許容されているかと思いますが、テンプレート:codepointの使用が義務になっているのですか? --M-30722 (トーク) 2025年4月28日 (月) 06:05 (UTC)[返信]
@Charidri ローカル環境で項目を識別するためにソートキーをご利用とのこと、興味深い運用方法だと感じました。一方で、一般的なソートキーの目的とはやや異なる使い方でもあるため、すべての利用者に同様の形式を維持させることには慎重であるべきかと思います。ローカル作業中に項目を識別しやすくするためには、たとえばHTMLコメント(<!-- -->)を用いて補助情報を挿入する方法も考えられます。この方法であれば、ページの出力結果やカテゴリソートに影響を与えることなく、個別のニーズにも対応できると思いますが、いかがでしょうか。--Naggy Nagumo (トーク) 2025年4月28日 (月) 22:40 (UTC)[返信]
特に異議が無ければユニコード順の並びで具体的なソートを決めていこうと思いますが、Kuroco2kさんの利用者ページを見たところ、ユニコード順の配列をあまり好ましく思われていないようですが、@Kuroco2kさん、ユニコード順の配列にすることに対して特に異論はございませんでしょうか? --M-30722 (トーク) 2025年5月10日 (土) 14:34 (UTC)[返信]
  • ユニコード順の配列にすることに対して異論はないか
    • 構いません。むしろ、それが望ましいと感じます。
  • 「ユニコード順の配列をあまり好ましく思われていないよう」
    • この点について一つ気になりました。どのあたりを見てそう思われましたか?
--Kuroco2k (トーク) 2025年5月10日 (土) 14:41 (UTC)[返信]
ちょっとこの辺に困るなというところで、「Unicode順に整列されてしまうので、意図した並びが崩れてしまう」と書かれておりましたのでUnicode順に並ぶことに困っているのではと思いました。それでは、Unicode順に並べるということで確定し、以後具体的なやり方について話していければと思います。 --M-30722 (トーク) 2025年5月10日 (土) 15:30 (UTC)[返信]
具体的なソートとして、私としては{{kanji header}}に実装するにあたって「*」がシンプルに記述出来る為良いかと思いますがいかがでしょうか?@Charidriさんとしてはどうしても「U+xxxxx」の形のソートキーにしないと都合悪いでしょうか?またもし「U+xxxxx」の形とするなら{{kanji header}}への実装は可能でしょうか? --M-30722 (トーク) 2025年5月23日 (金) 16:40 (UTC)[返信]
  • 単にカテゴリページの仕様としてソートされる(並び替えられる)というだけであって、ページ情報の基本情報の表の既定のソートキーが全て*になってしまいデータとして用をなしません。データに誠実性がありません。
  • テンプレート:kanji headerの使用は承認して(されて)いません。U+書いてページ名を16進数に変換すればできるんじゃないですか。誰かがやるならまだしも、私はやりませんが。
  • テンプレート:unicode_codeからテンプレート:codepointに嫌がらせのように(けちをつけるように)書き換えられている。ほかにも効果が同じなのにソースが見苦しくなる意味のない書き換えが多い。
  • あと、ついでだから指摘しておきますが CJKV+ は全て「漢字」を基本とする「漢字」のフォーマットであって、字喃や岱喃などの擬似漢字も全て「漢字」としてのフォーマットで本来統一するものであるから、「漢字」のフォーマットではテンプレート:kana-DEFAULTSORTを使用しないことと同じように、テンプレート:vi-DEFAULTSORTを使用せず、大見出しも言語名ではなく本来「漢字」です。言語名よりも「漢字」の見出しが優先されます。「峠」や「麿」などが「漢字」ではないわけがないのと同じです。
--Charidri (トーク) 2025年5月25日 (日) 02:15 (UTC)[返信]
もし{{kanji header}}を非推奨にするとして、ざっと数えてみたとこと約7500項目で使用されているようで、これらを全て引っ剥がす労力は私はかけたくないです(誰かがやってくれるならともかく)。なのでこのテンプレートにソートキーを組み込むしかないかな、と考えております。また、ソートキーにUnicodeの数字を使う場合、「U+xxxxx」の「U+」部分を省いて「xxxxx」と数字だけのソートにするのはどうでしょうか?こうすることで目次テンプレート(categoryTOC)を使用でき、途中のページに飛べるので閲覧側にとって便利になると思います。
特にチュノムについてよく見受けられますが、部首や画数等の情報がベトナム語見出しの中に入っているのが気になっているのでこれらの情報を分離して漢字見出しのところに書くのが良いと思います。 --M-30722 (トーク) 2025年5月25日 (日) 13:48 (UTC)[返信]
Unicodeの番号がソートキーとなる仕様に出来ました。例えば「」なら「842c」となります。これはカテゴリ:Unicode CJK Unified Ideographs等Unicode関連のカテゴリと同じ方式です。私としましてはこのような方式であれば千の位をもとにしてcategoryTOCで途中のページに飛ばすことが出来るので閲覧の際に便利(「u+」を入れてしまうと全ての語が「u」に並んで途中のページに飛べない)なのでこの方式でいきたいですが、特に異議はございませんでしょうか? --M-30722 (トーク) 2025年6月9日 (月) 17:37 (UTC)[返信]
この方式だと「U+10000」以降の文字が正しくソートされないと思います。ソートキーを「*」などにすれば「U+41」でも「U+12345」でも「U+10FFFF」でも正しく並ぶ保証がありますよ。どうしてもこの方式にしたいならゼロ埋めして六桁にしたほうがいいのでは?
あと補足ですがカテゴリの特定のソートキーに飛ばす機能は、二文字目以降も指定できます。「U+1」を指定すればソートキーが「U+1」以降の先頭に飛ぶわけです。--Naggy Nagumo (トーク) 2025年6月13日 (金) 22:55 (UTC)[返信]
編集者間の意見が分かれて平行線になり、決まりそうにありませんので一旦投票しようと思います。以下の2パターンのソートキーのうちどちらが良いか皆さんにお伺いします。
  • A: 「*」を用いる
  • B: 「12345」、「U+12345」等といった具体的な番号を入力する
期間は一週間程度で考えております。なお、私はA案を支持しますが、現時点ではNaggy NagumoさんがA案、CharidriがB案支持ということで問題ないでしょうか? --M-30722 (トーク) 2025年6月14日 (土) 03:48 (UTC)[返信]
カテゴリページでの「並び順」「並び方がどうなるか」ばかりに目がいっているような話の流れになっていますが、論点がちがいますよ。ユニーク性をすっ飛ばしていますよ。まぁこれで仮に*を使うような話の流れで決まったとしても、火種を残すだけで、とても合意とは程遠いことになるだけでしょうが。
それに漢字項目約2万7000のうち、テンプレート:kanji headerが無断で使われているのは8000項目にも満たないので、その8000のために1万9000を犠牲にするのかという問題もありますし。
とんでもない地雷を掘り起こしたようなトピックですよ。--Charidri (トーク) 2025年6月21日 (土) 12:28 (UTC)[返信]
一つ確認なのですが、8000ってかなり多いように感じるのですが、その8000項目の{{kanji header}}は全て除去しなければならないのでしょうか? --M-30722 (トーク) 2025年6月21日 (土) 13:16 (UTC)[返信]
カテゴリ:漢字を確認してみたところ、「」(U+3400)が「𲎯」(U+323AF)よりも後に並んでおり、U+XXXXの形でソートされている項目がそもそもUnicode順に並んでいないことが判明しました。果たしてUnicode順に並べているようでちゃんと並んでいない中途半端なものを採用することが正しいのでしょうか?また、27,000の内の8,000って実に3割近くにもなり、別件で「たくさん項目がありますが、いまさら全部書き直しますか」とCharidriさんが指摘された537件の約15倍の規模になります。その「たくさん」の15倍を無視して進めるのが正しいのでしょうか? --M-30722 (トーク) 2025年6月28日 (土) 18:31 (UTC)[返信]
「㐀」( U+3400 )はCJK統合漢字拡張A( U+3400から U+4DBF )の最初で、「𲎯」( U+323AF )はCJK統合漢字拡張H( U+31350 から U+323AF )の最後だから、機械的にはこう並びますよね。U+32xx の次に U+34xxx の順で。 CJK統合漢字拡張A のレンジはそうなります。そういうものですが、どうしても「㐀」( U+3400 )を「𲎯」( U+323AF )より前にソートしたいなら5桁にすれば変わります。U+3400 を U+03400 のように。ただ、CJK統合漢字拡張A はそういうものです。
テンプレート:kanji header 自体は改善と評価できますので、現在貼られているぶんについては、べつに剝がさなくてもよいとはおもいますよ。詮方なく。テンプレートの問題点の洗い出しがされておらず、使用の推奨はしませんが。
User:Vinegar03 にはめちゃくちゃに書き換えられていて、たとえば𨨩の項目は私Charidriが作成しましたが、後から「テンプレート適用」と称して、どさくさに紛れて デフォルトソート:U+28A29 を除去されています。--Charidri (トーク) 2025年6月29日 (日) 07:30 (UTC)[返信]
@Naggy Nagumo @Charidri {{kanji header}}を編集し、Unicode番号が4桁の場合にゼロ埋めをして5桁に揃える仕組みに出来たかと思います。しばらく時間を置いてみて確認してみないとまだ正しく動作してくれるかは分かりませんが、例えば「佔」(4F54)であれば「04F54」、「𠀋」(2000B)であれば「2000B」とソートされるであろうと期待しております。また、Unicode番号のソートキーを手打ちで行うと人によって桁数等の入力規則のゆれ(例えば「佔」なら「4F54」「04F54」「U+4F54」「U+04F54」等が考えられる)が生じがちになると思いますので[[カテゴリ:漢字]]のような手打ちでカテゴリ付けするのではなく、テンプレート(ここでいうテンプレートはkanji header以外のものでも構わない)を用いて自動でソートする形にすれば統一は容易かと思いますがいかがでしょうか? --M-30722 (トーク) 2025年7月2日 (水) 18:22 (UTC)[返信]
テンプレート:kanji header が貼られている範囲内に限定された話ですが、よく改善されているようです。
いっそのこと
[[カテゴリ:漢字|{{#ifeq:{{#expr: 131072 > {{hex2dec|{{#invoke:jawikt|unicode|{{PAGENAME}}}}}}}}|0|{{#invoke:jawikt|unicode|{{PAGENAME}}}}|0{{#invoke:jawikt|unicode|{{PAGENAME}}}}}}]]
から
[[カテゴリ:漢字]]{{デフォルトソート:U+{{#ifeq:{{#expr: 131072 > {{hex2dec|{{#invoke:jawikt|unicode|{{PAGENAME}}}}}}}}|0|{{#invoke:jawikt|unicode|{{PAGENAME}}}}|0{{#invoke:jawikt|unicode|{{PAGENAME}}}}}}}}
のようにしてもらったほうが話が早い。
にせよ𠀋にせよ𨨩にせよ、ページ情報を確認すると既定のソートキーがいまだに仮名のままで、期待通りの U+xxxxx になっていません。--Charidri (トーク) 2025年7月4日 (金) 15:43 (UTC)[返信]
@Charidri 実際にそのコードを{{kanji header}}に適用してプレビューするとどうなるか確認されましたか?例えば「𨨩」でそのコードを適用してプレビューすると「警告: 既定のソートキー「U+28A29」が、その前に書かれている既定のソートキー「たた ただ」を上書きしています。」という警告メッセージが出ます。このように既にデフォルトソートが設定されている項目に警告メッセージが表示されるので具合が悪いです。また、日本語カテゴリや{{タグ}}を用いたカテゴリでデフォルトソートを利用しているものがあり、もしこの点を考慮せずにUnicode番号をデフォルトソートにする処理を行うと「カテゴリ:日本語」等で(本来かなでソートされるべきものが)Unicode番号でソートされてしまうおそれがあり危険です。
あと質問なのですが、「𨨩」の場合のソートは「28A29」で良さそうに思うのですが、「U+」はわざわざ付ける必要ありますか? --M-30722 (トーク) 2025年7月5日 (土) 12:49 (UTC)[返信]
箇条書き
  1. そういえば発火しましたね。まぁ所詮 テンプレート:kanji header が貼ってある項目に限定される前提の話ですからね。ただ、既定のソートキーが「たた ただ」になっているのは芳しくない。
  2. となると「日本語」のセクションで 日本語の よみ で カテゴリ:日本語 のソートをする仕組みはできませんかね。日本語の発音(よみ)を書いているわけだから。
  3. 良くない。この業界のプロパーは、明示的に「U+」を付けます。フォーマルには「U+28A29」です。全部「U+」で並べます。--Charidri (トーク) 2025年7月5日 (土) 16:11 (UTC)[返信]
{{ja-kanji}}で引数「常用」や「施策=表外字体:」を用いた場合に{{kana-DEFAULTSORT}}を適用する機能はあるものの、「カテゴリ:日本語」を付与する機能はないようです。いっそ中国語みたいに「テンプレート:ja-cat」のようなものを作って日本語関連のカテゴリをまとめて付けるようにするのも一つの手かも知れません。次に「U+」で並べるにあたってですが、テンプレートを用いて「カテゴリ:漢字」等を付けているものに関してはテンプレートやモジュールをいじることでソートキーの一斉変更が可能ですので意図した並び方には比較的すぐ出来るかと思います。一方、現在手打ちでソートキーを付けているものについてですが、Unicode番号が4桁のものは「U+xxxx」、5桁のものは「U+xxxxx」と(恐らく)なっており、先述の事象(U+3400がU+323AFよりも後に並ぶ)が発生しており正しくならんでいないのでこれを「U+0xxxx」のように桁を合わせて解決する必要がありそうです。数が多いのでbotで出来れば一番良いと思うのですが…。 --M-30722 (トーク) 2025年7月5日 (土) 16:55 (UTC)[返信]
やはりそうだ。話が噛み合ってないことを確信した。途中から何だか話がすれ違っているなとは思っていましたが。
あなたはテンプレートを使って並び方その他をどうしようこうしようと話を進めていますが、私がいっているのはそこではない。純粋に、真のソートキーをどう書くのか、という単純なことをいっている。それは、既定のソートキーは U+ ではじまる hex がユニークだといっている。
テンプレートの話にずるずると付き合わされて話が長々と変な方向にいっちゃってる。私は、テンプレートを使わないやりかたの、既存の項目をみている。テンプレートでやらない。
正規には(というのも語弊があるかもしれませんが、Unicode Consortium の公式では)、4桁のものはゼロパディングせずに4桁ですし、5桁のものは5桁です。私も最近作った BMP 領域の記号などの項目で、ニーズに応じて(アリかなとおもって)ゼロパティングでいこうかと考えていますが、BMP の領域は、正規には全部4桁です。ボットで5桁にするのは構いませんが。何が何でもブロックごとの並び順を優先するというならば。--Charidri (トーク) 2025年7月6日 (日) 06:07 (UTC)[返信]
ソートキーの話をさせていただきますが、もしUnicode順にきっちり並べるのであれば4桁(U+3400 等)と5桁(U+03400 等)が混在するのはいけないのでどちらかに統一すべきと思います。この点についていかがでしょうか?--M-30722 (トーク) 2025年7月6日 (日) 06:37 (UTC)[返信]
ある程度まとまってきましたので、「カテゴリ:漢字」のソートキーは「u+XXXXX」(「X」の部分にはUnicode番号が入る)の形の5桁の番号(4桁の場合は0を挿入して「u+03400」のように表す)とするで合意としたいと思いますがよろしいでしょうか?また、ソートキーの付け方としては原則{{kanji header}}{{漢字}}といったテンプレートにより付与(手打ちは桁やコードそのものの間違いのおそれがある為)することとしたいと思いますが、どうしても手打ちにこだわり且つ正確にソート出来る自信のある場合は手打ち入力も可としようと思います。特に異議はありませんでしょうか? --M-30722 (トーク) 2025年7月8日 (火) 15:39 (UTC)[返信]
特に異議が無ければ「u+」に続けて5桁の番号(4桁の場合は0を挿入)で合意したいと思いますが、@Kuroco2kさんは「」等の編集からして4桁の場合に0を挿入して「U+06CEB」とするのではなく、挿入せずに「U+6CEB」とした方が良いという考えでしょうか?なお、0を挿入しない場合はUnicode番号順に並ばないという短所があります。 --M-30722 (トーク) 2025年7月17日 (木) 14:53 (UTC)[返信]
単に今までの慣習上から、まだ不慣れなだけです。それ自体は悪くないと思います。--Kuroco2k (トーク) 2025年7月17日 (木) 23:11 (UTC)[返信]
終了 それでは、「カテゴリ:漢字」のソートキーは「u+XXXXX」(「X」の部分はUnicode番号)の形の5桁の番号とし、4桁の場合は0を挿入して「u+0XXXX」とすることとします。なお、デフォルトソートに関して思うところがありますので、その件につきましては近々Wiktionary:編集室/2025年Q3#単漢字項目にてお話させていただこうと思います。 --M-30722 (トーク) 2025年7月18日 (金) 14:24 (UTC)[返信]

漢語の新字体/旧字体表記

[編集]

日本語における漢語の旧字体・新字体表記について、{{zh-ts}}のように運用できるテンプレート{{ja-ts}}(仮)が欲しいです。

現状私は{{alter}}を用いて、

===={{alter}}====
*[[]]([[旧字体/新字体]]表記)

のように表記してますが、
旧字体/新字体以外の異表記が存在しない場合に態々これを書くのは面倒なので、上記のように要望します。--2400:4051:3B61:7F00:8144:DB0B:99F6:FEA2 2025年5月3日 (土) 10:50 (UTC)[返信]

コメント そもそも旧字体表記自体が現在、日本語版ウィクショナリーには収録されていないのではないでしょうか(例えば、「學校」は中国語、朝鮮語、ベトナム語はあるが日本語は収録なし)。旧字体表記のテンプレートを作る前にまずは日本語の旧字体表記そのものを導入するか否かの議論が先ではないでしょうか? --M-30722 (トーク) 2025年5月3日 (土) 13:14 (UTC)[返信]
聯関」「弁明」のように旧字体表記の導入を前提として記述されたページ、「缺格」のように旧字体表記とは明記されずとも日本語の単語として記述されたページ、「機轉」「南無阿彌豆腐」のように日本語における旧字体表記と明記されたページが確認できること、旧字体表記は戦後に当用漢字制限が行われるまでは現代(近代?)日本語の一部として普通に用いられていたことから、無条件で旧字体表記の追加をしてよいものだと認識していました(実際に立項したページもいくつかある)。認識の擦り合わせを行うため、以下に立項します。--2400:4051:3B61:7F00:8144:DB0B:99F6:FEA2 2025年5月3日 (土) 13:47 (UTC)[返信]
旧字体表記導入に関する議論が落ち着きましたので改めてこちらの議論を再開致しますが正直私は新しいテンプレートは不要かと思います。理由としてはja-noun等の見出し語テンプレートで引数「kyu」を用いることで事足りるからです。使用例として「庁舎」をご覧下さい。 --M-30722 (トーク) 2025年5月19日 (月) 15:48 (UTC)[返信]
{{ja-noun}}等の引数「kyu」と{{kyujitai of}}により、私の求めていた機能は代替されました。そのため、新たなテンプレートの導入については取り下げたいと思います。--2400:4051:3B61:7F00:616F:8E70:1D2B:5E18 2025年5月19日 (月) 16:17 (UTC)[返信]
却下 取り下げに伴い、当議論は却下となりました。 --M-30722 (トーク) 2025年5月19日 (月) 16:20 (UTC)[返信]

日本語における旧字体表記

[編集]

上の節におけるM-30722様の提言により、日本語の旧字体表記の掲載可否について議論したいと思います。

私は旧字体表記の掲載に賛成です。理由は上の節にコメントした内容の通りで、掲載を拒否する理由はないと思います。 同音書き換え前の表記の掲載が認められるのならば、旧字体表記も同様に認められて然るべきだと考えます。--2400:4051:3B61:7F00:8144:DB0B:99F6:FEA2 2025年5月3日 (土) 13:57 (UTC)[返信]

賛成 賛成寄り 日本語以外の言語ではベトナム語のチュノムの表記であったりマレー語のジャウィ文字等かつて用いられた表記に関する項目があるので日本語の旧字体表記も認めて問題はないと思います。現在用いられている新字体の項目をメインとして、旧字体はサブリダイレクトの形をとるのが良いかと思います。 --M-30722 (トーク) 2025年5月3日 (土) 14:02 (UTC)[返信]
賛成 賛成 異表記の一つとして、ある方が自然です。ただ、旧字体で表記されたことがなさそうな新しめの語句(例えば「断捨離」)に旧字体が必要かどうかは、自身がないです。私としては語句が登場した時代に関わらずシステマティックにぜんぶ作っちゃえばいいと思いますが。 --Naggy Nagumo (トーク) 2025年5月6日 (火) 09:02 (UTC)[返信]
反対無しなので旧字体表記導入の方向で進めたいと思います。時期を区切るとしたら当用漢字表の告示が1946年なのでそれ以前から存在した語を対象にするのが良いと思います。漢字のみの項目はこれでよしとして、漢字かな混じりのものについてはどうしましょうか?と言うのも歴史的仮名遣から現代仮名遣への切り替えもほぼ同時期に行われておりますので旧字体表記には歴史的仮名遣を使うのが自然かも知れません。例えば、「会う」の旧字体表記は「會う」「會ふ」どちらが良いでしょうか? --M-30722 (トーク) 2025年5月10日 (土) 14:29 (UTC)[返信]
旧字体表記は歴史的仮名遣いで良いと思いますが、新字体表記の歴史的仮名遣いの扱いをどうするか考えねばなりません。一応、日本国憲法のように新字体で歴史的仮名遣いを用いている例もありますが、そのような例は希少だと思うので「新字体は現代仮名」「旧字体は歴史的仮名」ときっぱり分けてしまうのが良いと思います。現在存在する「新字+歴史的仮名」や「旧字+現代仮名」というページはリダイレクト化するのがよろしいかと。--2400:4051:3B61:7F00:901B:16BD:7BA2:3BB1 2025年5月11日 (日) 01:41 (UTC)[返信]
では、仮名混じりの場合は歴史的仮名遣いを使う方向で考えたいと思います。異議が無ければ日本語の旧字体表記を掲載し、もしかな混じりであれば歴史的仮名遣いを用いることで決定したいと思います。とりあえず漢語について「聽取」を試作してみましたがいかがでしょうか? --M-30722 (トーク) 2025年5月14日 (水) 04:04 (UTC)[返信]
あとは例えば「カテゴリ:日本語 旧字体表記」のようなカテゴリを作るかどうかですが、あった方が良いでしょうか? --M-30722 (トーク) 2025年5月14日 (水) 04:21 (UTC)[返信]
はい。--Praqimu (トーク) 2025年5月14日 (水) 04:24 (UTC)[返信]
それでは、カテゴリ付与のためのテンプレートを作ろうと思います。「テンプレート:kangokana of」や「テンプレート:wagokanji of」のようなイメージで「テンプレート:kyuji of」といったものはどうでしょうか? --M-30722 (トーク) 2025年5月14日 (水) 04:35 (UTC)[返信]
賛成です。カテゴリ付与は{{ja-noun}}で行う感じですか?--49.98.211.196 2025年5月14日 (水) 04:38 (UTC)[返信]
語の響きとしては「テンプレート:kyuji of」より「テンプレート:kyujitai of」の方が好ましいかなと思います(もし名前がほんの少し長いことによって面倒に感じるなら前者を後者のリダイレクトにすればよいだけですし)。--Praqimu (トーク) 2025年5月14日 (水) 04:50 (UTC)[返信]
カテゴリ付与は「テンプレート:kyuji of」で行う(このテンプレートを付けるとカテゴリが自動付与される)のが都合良いかと考えております。 --M-30722 (トーク) 2025年5月14日 (水) 04:43 (UTC)[返信]
それでは、「テンプレート:kyujitai of」を作成することとします。 --M-30722 (トーク) 2025年5月14日 (水) 05:15 (UTC)[返信]
和語の旧字体を用いた漢字表記については{{ja-wagokanji}}/{{ojp-wagokanji}}{{kyujitai of}}を併用する形が良いでしょうか?--2400:4051:3B61:7F00:AC37:87BA:DCB3:1B70 2025年5月16日 (金) 10:36 (UTC)[返信]
{{ja-wagokanji}}{{kyujitai of}}を用いるのが良いかと考えております。なお、古典日本語に関してはその言語が使われていた時代には新字体/旧字体という区別がなかったため「kyujitai of」を使用するのは適切でないかと思います。強いていうなら「別表記」という扱いになるかと思いますが、古典日本語の別表記を考えるとなると変体仮名も考慮に入れなければなりそうでかなり複雑な問題になってきそうなのでとりあえず現代日本語について考えていただければと思います。 --M-30722 (トーク) 2025年5月16日 (金) 15:27 (UTC)[返信]
終了 皆様ご意見ありがとうございました。議論の内容をWiktionary:スタイルマニュアル/日本語に反映致しました。 --M-30722 (トーク) 2025年5月19日 (月) 15:43 (UTC)[返信]
「サブリダイレクト」という用語はありません。「ソフトリダイレクト」の誤りです。修正してください。--Charidri (トーク) 2025年5月25日 (日) 02:15 (UTC)[返信]
失礼しました。以上、「ソフトリダイレクト」に読み替えて下さい。 --M-30722 (トーク) 2025年5月25日 (日) 13:37 (UTC)[返信]

単漢字記事での記載の仕方

[編集]

」や「」など、異体字のところに「(語義◯)」と記載されている場合がありますが、単漢字記事の「意義」の節で説明されているのは語義ではなく字義なので、「(字義◯)」と書いた方が適切だと思うのですが、どうでしょうか?--ら゚いと (トーク) 2025年6月9日 (月) 10:01 (UTC)[返信]

ここで合意は得られていないようですが、@Kuroco2kさんが最近の編集(具体的には「𠱷」など)で「字義◯」の書き方にしているので良いかと思われます
また、「字義◯」の書き方にするなら、節「意義」も「字義」に改めた方がわかりやすくなるかと。--14.13.231.128 2025年6月21日 (土) 10:56 (UTC)[返信]
異体字の節中に「語義2」と最初に書き始めたのは私Charidriです。たくさん項目がありますが、いまさら全部書き直しますか。慎重に考えてください。それと、あくまで標準の内容は意義節であって字義節ではないです。字義ではなく意義です。字義に書き換えようとすると、ウィクショナリーの全部書き換えないといけなくなります。あまり字義に書き換えようとせず、そのままでいいじゃないですか。
あと、細かいことをいうようですけど、ウィキペディア日本語版ではないので、「記事」ではなく「項目」という用語を使用します。市販の国語辞典を引いて○○という言葉の「記事」とは普通いわないでしょ。それと同じです。単漢字記事ではなく単漢字項目です。--Charidri (トーク) 2025年6月21日 (土) 12:28 (UTC)[返信]
意義節を字義節にするのは流石に私もどうかと思いますが、「語義◯」を「字義◯」に書き換えるのはそんなにまずいでしょうか?私はあまり適切でない記載の仕方をしている方が問題があると思います。
また、いまさら全部書き直すのかと仰っていますが、「これらの単語を含む:異体字、語義」「ページのカテゴリ:漢字」で検索をかけたところ見つかった項目は537件です。まだ頑張れば直せる数じゃないですか?--ら゚いと (トーク) 2025年6月21日 (土) 12:59 (UTC)[返信]
私は「語義◯」を「字義◯」に書き換えるのは賛成です。また、合意が取れれば意義節を字義節に変更するべきだと思います。
漢字一字のページ、特に漢字節で解説されるのはその漢字についてです。漢字節内の意義解説なので字義節を収めるべきであり、語義節に当たるのは日本語節や中国語節内の名詞節等だと思われます。そして「字義◯」と整合性、可視性を取るために意義節は字義節とするべきです。--TAKA647 (トーク) 2025年6月21日 (土) 15:43 (UTC)[返信]
前記管見のとおりですが、異体字の括弧書きを「語義◯」から「義◯」に変えるのはアリかもしれません。私は協力しませんが。ウィクショナリーの用語集的には語義なので伝統的に「語義」を使っているのですけれども。可視性は可読性のことですかね。--Charidri (トーク) 2025年6月29日 (日) 07:30 (UTC)[返信]
そもそもウィクショナリーの用語集での「語義」の扱い方があまり良くないように感じるのですが…
「語義」と「字義」は分けるべきであり、字義を語義に含めるのにはとても違和感があります--14.13.231.128 2025年6月29日 (日) 08:52 (UTC)[返信]
漢字の項目は独立したスタイルマニュアルとして字義節(ないし意義節)を用いると取り決めていいと思います。
すみません。可読性と読み替えてください。--TAKA647 (トーク) 2025年6月30日 (月) 00:36 (UTC)[返信]
字義節にするとしたら、問題は「全ての単漢字項目の"意義"の部分を"字義"に書き換えないといけないこと」でしょうか(何故かごく一部の項目は既に字義節となっていますが)。"語義◯"を"字義◯"にするのはできると思います。
ですが@Charidriさんとしてはやはり"字義◯"の形にするのには反対でしょうか?--ら゚いと (トーク) 2025年6月30日 (月) 11:20 (UTC)[返信]

(インデント戻す)字義節。都合よく綺麗に全ての漢字に字義があるわけではないでしょ。見渡してください。字義にすると記述の可能性を狭めます。意義であるからこそ、その文字が持つポテンシャルを引き出すことができるのです。その文字が持つ意義を。

これは一般論ですが、伝統的な積み上げをガン無視して、基幹部分を後からそうコロコロ変えられては安定性を失って困ります。まさか標準の内容が字義節には変更されるわけは絶対にないとは思いますが。

以前は管理者Mtodoさんがいて、強烈なストッパーとなって、この手の議論で矢面に立ってくれていましたが、現在は不在のため、放置すると、知らないうちに決まってしまい、どんどん安定性が失われていき、やりづらくなります。はぁ疲れますわ。--Charidri (トーク) 2025年7月4日 (金) 15:43 (UTC)[返信]

ではやはり"意義◯"にするのが一番良いでしょうか。字義がない漢字ってのは「」みたいなやつのことですかね?
@TAKA647さん、どうでしょうか?--ら゚いと (トーク) 2025年7月5日 (土) 00:23 (UTC)[返信]
まず、伝統を守るのは大事ですが「伝統であること」のみを理由に意見を棄却するのは違うと思います。安定性も大事ですが変更案が有意義かどうかはこの場の合議によって決まるべきです。
さて。流れを見るに「語義◯」をどうにかするのは一致してそうですが、私は引き続き「字義◯」及び「字義節」への変更を主張します。「字義意義」だとは思いますが、やはり漢字についての項目に置く以上「意義」よりも「字義」とした方がまとまりがあります。スタイルマニュアルの変更と流布を適切に行えば新規項目については問題ありません。2.7万の漢字項目全てを直すのか、という意見に関しては気づいた人が直すようにすればいいと考えます。過程で多少の混乱は生まれるかと思いますが、この力技ができるのがwikiの強みです。@Charidriさんの言う字義がない漢字というものはよくわかりませんが「」ならば「音訳字の一つ」というのは立派な字義ですし、音義未詳の漢字ならば「音義未詳」を字義節に収めるのは妥当です。「𬑢」のような歌舞伎の外題のみに使われる漢字も「歌舞伎の外題に使われる字」というのは紛うことなき漢字の義ですし、連綿語のみに使われる漢字であっても「(連綿語)に使われる字」というのは字義以外の何者でもありません。仮にチュノムや古壮字以外で使わない字をを漢字節に収めることがあっても「チュノム/古壮字に用いられる字」と字義節に書けばいい話です。繰り返しになりますが漢字と紐づけられるのは語でありその語の意味が漢字の「語義」です。これは上記の漢字を含め例外はありません。
ここまで長々と書いておいてなんですが、私は「語義◯」から「意義◯」への変更を求める人が大多数を占ていることを投票などで明示されれば主張を取り下げるつもりです。「語義◯」が残っている方が問題ですし。とはいえまだまだ浮動票はありそうなので現状維持のつもりです(投票自体があまりよろしくないという話もありますが→参照)。--TAKA647 (トーク) 2025年7月5日 (土) 15:50 (UTC)[返信]

ある文字を含む記事名の検索について

[編集]

ある文字をページタイトルに使っているページを調べようと思った際に、全てを網羅する方法はあるのでしょうか。条件をつけない通常の検索、書式→ページタイトルに含まれるもの(intitle:を付与)を用いた検索、特別:先頭が同じ全ページでの検索のいずれかのみに表示されるページがあり、一発で全てを調べることができませんでした。どなたかご存知の方はいらっしゃいますか。--TAKA647 (トーク) 2025年6月20日 (金) 10:12 (UTC)[返信]

私の場合は右上の虫眼鏡マークを押して特別ページの検索へ飛び、そこでキーワードを入力して検索しておりますが、いかがでしょうか? --M-30722 (トーク) 2025年6月20日 (金) 14:02 (UTC)[返信]
それがそうもいかないのです。たとえば「確」という文字をページ名に使っているページを調べようとします。①条件をつけない通常の検索、②書式→ページタイトルに含まれるもの(intitle:を付与)を用いた検索、③特別:先頭が同じ全ページでの検索の3条件を使いますと、
①のみ表示:精確確証(ほかcheck up onまこと)など
②のみ表示:なし(①の検索に全て含まれる、私の勘違いでした)
③のみ表示:確定申告確かめるなど
表示されない:未確認飛行物体気道確保など
唯一、のリンク元を辿れば網羅できてそう(上の条件で表示されない확정しっかりなども表示)ですが、特定文字をページタイトルを使っているページのみを一覧で表示することはできないのでしょうか。--TAKA647 (トーク) 2025年6月21日 (土) 02:01 (UTC)[返信]
確かにある漢字を項目名使っている項目を調べるにはその字のリンク元を見るのが確実かも知れません(漢熟語の項目は漢字へのリンクが付けられている為)が、例えば「確率分布」のようにリンクが単漢字ではなく熟語単位で行われている(この場合「確率」と「分布」にリンク)ものは拾えないという欠点があります。私が知る限りではリンク元が完全ではないが最も確実でありますが、どなたかより良い方法をご存じの方はおられますでしょうか? --M-30722 (トーク) 2025年6月21日 (土) 13:25 (UTC)[返信]
正規表現を使って intitle:/確/ のようにすれば、通常の部分一致よりも広くヒットすると思いますが、そのぶん検索の制限が緩くなってタイムアウトや上限到達が起こりやすくなります。確実にすべて拾いたいのであれば、メイン名前空間の全ページタイトルを取得し、「確」が含まれるものだけをフィルタする方法があります(プログラミングが必要です)。--Naggy Nagumo (トーク) 2025年6月30日 (月) 14:53 (UTC)[返信]
返信ありがとうございます。なるほど、プログラミングですか。テンプレートがどのようにして動いているのかすら理解していない私にとってはちょっとハードルが高いですね…。--TAKA647 (トーク) 2025年7月3日 (木) 01:31 (UTC)[返信]

編集室やトークページでの:の使い方について(注意喚起)

[編集]

コロンで機械的に毎回1字分下げてつなげていく人が最近多過ぎですが、Wiki文法では、コロンはスレッド形式のツリーと同じですから、インデントを意識してくださいよ。見えないツリーがあることを意識してください。これを守らないと、違う人にレスしてしまうことになり、誰の投稿に対するレスなのか関係が分かりにくくなります。--Charidri (トーク) 2025年6月21日 (土) 12:28 (UTC)[返信]

複数の事柄を列挙するときや話題の節目のタイミングで改行を使っていましたが(編集中はコロンを意識しませんが)、使用しない方が良いのでしょうか。もしそうならばWiktionary:編集室の冒頭に明記するべきだと思いますが、いかがお考えですか。--TAKA647 (トーク) 2025年6月21日 (土) 15:11 (UTC)[返信]
字下げのことをいっています。至極当たり前のことですので、どこどこに明記するものではありません。--Charidri (トーク) 2025年6月29日 (日) 07:30 (UTC)[返信]
コロンを一つ余計に増やしてしまっている、ということでしょうか。具体例を示していただけますか。--TAKA647 (トーク) 2025年6月30日 (月) 01:05 (UTC)[返信]
自己レスしている場合とか、違う利用者にレスする格好になっている場合とかをいっています。あなたはちゃんとできているようです。御心配なく。--Charidri (トーク) 2025年7月4日 (金) 15:43 (UTC)[返信]

単漢字項目

[編集]

その編集ちょっと待った。慎重に。

単漢字項目に テンプレート:kana-DEFAULTSORT を使用することの影響

[編集]

カテゴリ:Unicode CJK Unified Ideographs Extension A が分かりやすいですが、次のページで送って後ろのほうを見ると、いま現在、1文字ずつ見出しができて不細工になっています。単漢字項目には、そもそもテンプレート:kana-DEFAULTSORTを貼り付けることは馴染まないのですが、このような影響があることが考慮されないまま貼り付けられています。単漢字項目には テンプレート:kana-DEFAULTSORT を貼り付けないでください。いま貼られているものは全て剝がして下さい。--Charidri (トーク) 2025年7月4日 (金) 16:00 (UTC)[返信]

本当に{{kana-DEFAULTSORT}}のせいでそのようになっているのか、もう少し因果関係を詳しく検証する必要があると思います。もしkana-DEFAULTSORTが原因なのであれば(このテンプレートはかな文字をソートキーに指定する為)見出しは必ずかなになる筈です。従って「か」になっている「」や「よ」になっている「」はkana-DEFAULTSORTの影響によるものですが(手打ちで入力されていた[[Category:Unicode CJK Unified Ideographs Extension A‎]]を外してみたところ正しくソートされました。)、見出しが単漢字になっているものはこのテンプレートによりソートされたものとは直ちに断定出来ないかと思います(詳しく調査する必要があるかと思います)。また、「」のようにkana-DEFAULTSORTが使われていながら正しくソート出来ているものもあり、その一方でDEFAULTSORTがUnicode番号になっている(kana-DEFAULTSORTは使用されていない)「」が正しくソートされていないようです。 --M-30722 (トーク) 2025年7月5日 (土) 11:26 (UTC)[返信]
まぁこのカテゴリで信じられるのは私が初版を作成してその後大きく書き換えられていない項目だけですね。規則正しく「U」で並ぶものは。--Charidri (トーク) 2025年7月5日 (土) 16:06 (UTC)[返信]
カテゴライズしている {{codepoint}}, {{character info}} を確認してください。--Naggy Nagumo (トーク) 2025年7月5日 (土) 22:40 (UTC)[返信]
問題に関しては解消されました。なお、{{kana-DEFAULTSORT}}の使用禁止及びそれを全て剥がすことに関しては反対 反対です。デフォルトソートに仮名を指定するのは十数年前から行われており(例えば「」は2009年よりデフォルトソートに仮名が適用されております)、特に問題視されることなく今日まで使われておりました。また、日本語関連のカテゴリがデフォルトソートによってソートされているものも非常に多く、安易に剥がすことで今度は日本語関連のカテゴリへの影響が出るおそれがありますカテゴリ:Unicode CJK Unified Ideographs Extension Aの問題が解消された以上、これまで問題視されていなかった仮名のデフォルトソートを剥がす必要は無いのでは? --M-30722 (トーク) 2025年7月18日 (金) 17:07 (UTC)[返信]
「テンプレート:kana-DEFAULTSORT」の使用禁止の撤回を要望します。当議題の問題は解決済で、むしろUnicode番号をデフォルトソートに使うことの影響が出ております。𲡫で「カテゴリ:日本語」のソートキーの指定が正しく行われておらず、あるべき並び方になっておりません。日本語のソートキールールは少々複雑で、「テンプレート:kana-DEFAULTSORT」を使用すると読み通りに指定すれば良いのでこのような間違いを防ぐことができます。よって「テンプレート:kana-DEFAULTSORT」禁止を 却下したいと思いますが宜しいでしょうか? --M-30722 (トーク) 2025年9月14日 (日) 14:15 (UTC)[返信]
(追記)コード番号が4桁のものは「+」の後に「0」を加えて5桁にするルールになりましたが、「」のようにデフォルトソートが「U+5046」と0が挿入出来ていないものが見られます。やはりUnicode番号をデフォルトソートでルール通りに指定するのは難しい(編集者間でルールの共有が徹底しにくい)のではと考えますがいかがでしょうか? --M-30722 (トーク) 2025年9月15日 (月) 10:13 (UTC)[返信]
現時点で「テンプレート:kana-DEFAULTSORT」使用禁止の却下について異議は出ておりませんが、@Nazrattさんは使用禁止にすべきという考えでしょうか? --M-30722 (トーク) 2025年10月19日 (日) 12:49 (UTC)[返信]
却下 異議が出なかった為{{kana-DEFAULTSORT}}の使用禁止の意見を却下します。従って、漢字項目への{{kana-DEFAULTSORT}}の使用は可能です。 --M-30722 (トーク) 2025年10月23日 (木) 13:52 (UTC)[返信]

単漢字項目で テンプレート:unicode_code を テンプレート:codepoint に書き換え、カテゴリの直書きを除去してしまうことの影響

[編集]

カテゴリ:Unicode CJK Unified Ideographs Extension D が分かりやすいですが、カテゴリページの見出しが、いま現在、「2」のものと「U」ものがあります。本来もともと「U」で規則正しく並ぶところ、 テンプレート:unicode_codeテンプレート:codepoint に書き換えられてしまったため、「U」から「2」に変わってしまっています。分断が生じてしまっています。影響をよく考えず、安易に テンプレート:unicode_code を テンプレート:codepoint に書き換え、カテゴリの直書きを除去してしまわないよう注意してください。極力、正しく元に戻してください。--Charidri (トーク) 2025年7月4日 (金) 16:00 (UTC)[返信]

{{codepoint}}を犯人と決めつけるのは早計であると考えます。いくつか実験を行ったところ以下の結果となりました。
  • 𫝆」でテンプレートをcodepontからunicode_codeに変更→ソートは「2」のまま
  • 𫝑」(unicode_codeを使用)でテンプレートはunicode_codeのままで手打ちの「カテゴリ:Unicode CJK Unified Ideographs Extension D」を除去→ソートは「U」から「2」に変わった
  • 𫠗」(codepointを使用)でテンプレートはcodepointのままで「カテゴリ:Unicode CJK Unified Ideographs Extension D」を手打ちで追加→ソートは「2」から「U」に変わった
以上より、犯人はunicode_codeではなく手打ちの「カテゴリ:Unicode CJK Unified Ideographs Extension D」であると推定されます。 --M-30722 (トーク) 2025年7月5日 (土) 11:26 (UTC)[返信]
なるほど。では カテゴリを直書きしないと期待通り正しく「U」で並びませんか。欠陥です。 --Charidri (トーク) 2025年7月5日 (土) 16:06 (UTC)[返信]
モジュール:UnicodeCategoryを編集し、ソートキーの調整を行ったので意図した並びになったと思われます(しばらく更新が完了するのを待ってから確認しないと断定は出来ませんが)。--M-30722 (トーク) 2025年7月5日 (土) 17:07 (UTC)[返信]
(追記)@Charidri 問題が解消され、また、{{codepoint}}が今回の問題の原因ではないことが分かりましたので{{codepoint}}の使用を禁じる指示を撤回していただきたく思います。{{codepoint}}の使用禁止に反対 反対です。{{unicode_code}}ではいちいちコード番号を調べなければならず不便です。 --M-30722 (トーク) 2025年7月18日 (金) 17:07 (UTC)[返信]
特に異議が無ければこの意見についても 却下としたいと思いますがよろしいでしょうか?(そもそもcodepointのせいで影響が出たという主張自体が誤りな為即却下でも良さそうですが) --M-30722 (トーク) 2025年10月23日 (木) 13:54 (UTC)[返信]

カテゴリ:朝鮮の国字 に含まれる単漢字項目のデフォルトソート

[編集]

デフォルトソートをハングルにしてしまっている項目がたくさんありますが、そうしてしまうとカテゴリ:漢字でもハングル字母の順で並んでしまいます。デフォルトソートをハングルにしてしまうと、様々なカテゴリでハングル順になってしまうことになるため不都合を生じます。カテゴリ:朝鮮の国字でハングル順にソートされるよう、このカテゴリへのリンクにパイプを付けてハングルでソートしてください。単漢字項目のデフォルトソートに、ハングルや仮名などを用いないでください。他の単漢字項目との整合性が取れません。--Charidri (トーク) 2025年7月4日 (金) 16:00 (UTC)[返信]

{{kanji header}}を使用した場合、デフォルトソートよりもUnicode番号を優先してソートされ、正しくソートされることが確認出来ました。必ずしもデフォルトソートだけの影響とは言えず、複数の条件が重なった結果(今回検証を行った「」の場合、ハングルのデフォルトソートでなおかつ「カテゴリ:漢字」が手打ちでソート指定無しで付けられていた)ハングルのソートになったと見られます。なお、「カテゴリ:朝鮮の国字」を{{ko-han}}を用いて付与出来るよう改良を行いました。 --M-30722 (トーク) 2025年7月5日 (土) 11:26 (UTC)[返信]
カテゴリ:朝鮮の国字 が消えています。テンプレート:kanji header頼りですか。--Charidri (トーク) 2025年7月5日 (土) 16:06 (UTC)[返信]
」にはちゃんと「カテゴリ:朝鮮の国字」が付いております。もしかするとページの更新がされていないだけかも知れないので更新ボタンを押すか空編集をしてみて下さい。また、「カテゴリ:朝鮮の国字」の付与を行うテンプレートは{{kanji header}}ではなく{{ko-han}}です。--M-30722 (トーク) 2025年7月5日 (土) 16:10 (UTC)[返信]
対処ハングルでソートされている問題を解消しました。なお、{{ko-han}}を使う場合はデフォルトソートの影響を受けないのでデフォルトソートを設定しても意味ないです(ハングルのデフォルトソートは必要ありません)。 --M-30722 (トーク) 2025年7月18日 (金) 17:07 (UTC)[返信]

デフォルトソートをピンインにすることの影響

[編集]

カテゴリ:漢字などでローマンアルファベット順にソートされてしまうため、他の単漢字項目との整合性が取れません。カテゴリ:簡体字などへのリンクにパイプを付けて個別にソートしてください。--Charidri (トーク) 2025年7月4日 (金) 16:00 (UTC)[返信]

で手打ちの「カテゴリ:漢字」を使用しない形にすると問題なくソートされることが確認できました。 --M-30722 (トーク) 2025年7月5日 (土) 11:26 (UTC)[返信]
これも テンプレート:kanji header頼りですか。--Charidri (トーク) 2025年7月5日 (土) 16:06 (UTC)[返信]

単漢字項目に テンプレート:vi-DEFAULTSORT を使用することの影響

[編集]

カテゴリ:漢字などでローマンアルファベット順にソートされてしまうため、他の単漢字項目との整合性が取れません。カテゴリ:チュノムカテゴリ:タイーノムなどへのリンクにパイプを付けて個別にソートしてください。--Charidri (トーク) 2025年7月4日 (金) 16:00 (UTC)[返信]

𠀧のように手打ちの「カテゴリ:漢字」を使用しない形になっているものは問題なくソートされているようです。
@Charidri 全体的に何が影響を与えているのかの検証が足りず、特定のテンプレート等に冤罪をかけている形になっております。他の利用者への指示は因果関係の確認をしっかり行ってからにして下さい。 --M-30722 (トーク) 2025年7月5日 (土) 11:26 (UTC)[返信]
これも テンプレート:kanji header に書き換えられましたが、テンプレート:kanji header を使っていない通常の項目だとどうですか。テンプレート:kanji header の使用が前提ですか。
純粋に 上記節に書いた編集が1つでもされていない 私が作った(私を真似て作った)項目は、基本的に規則正しく並ぶようになっています。
カテゴリ:漢字 の後ろのほうに吹き溜まっている項目をどうするかです。手間掛けてすみませんね。--Charidri (トーク) 2025年7月5日 (土) 16:06 (UTC)[返信]
Wiktionary:編集室/2025年Q2#「カテゴリ:漢字」のソートキーのルールでの私のコメントはちゃんと読まれましたか?私は「テンプレート(ここでいうテンプレートはkanji header以外のものでも構わない)を用いて自動でソートする形にすると統一が容易に出来て良いのではないか」と提言しており、「{{kanji header}}のみに拘る必要はない」としております。但し現状、「カテゴリ:漢字」を自動出力するテンプレートがこれしかないので仕方なく{{kanji header}}を用いてテストを行っております(「kanji header」を使わなくとも「カテゴリ:漢字」に自動でUnicode番号のソートを行えるテンプレートを近いうちに作成予定です)。
あと、「規則正しくUに並ぶかどうか」についてですが、これについては上記の「「カテゴリ:漢字」のソートキーのルール」の議論にて「「U+xxxxx」の「U+」部分を省いて「xxxxx」と数字だけのソートにするのはどうか」と提案(5月25日 (日) 13:48 (UTC))させていただいたり「「U+」はわざわざ付ける必要があるのか?」と質問(7月5日 (土) 12:49 (UTC))させていただいたりしておりますが、それに対する回答が無く「U+xxxxxの形での並び方こそが正しい。そう並ばないものは欠陥である」という一方的な主張されても納得いきません。ソートキーを単に「28A29」のような番号だけではいけなくて、わざわざ「U+」のような余計に思えるものを付けなければならない理由を説明して下さい。理由がよく分からないままでは合意しかねますので、「U+」が必要な理由を理解した上で合意形成をしたいと考えております。 --M-30722 (トーク) 2025年7月5日 (土) 16:27 (UTC)[返信]
(追記){{漢字}}を作成しました。このテンプレートでは引数不要で「カテゴリ:漢字」の自動付与を行い、ソートキーもその文字に割り当てられたUnicode番号を自動で適用します。{{kanji header}}を使用しない場合は{{漢字}}を使用することで「カテゴリ:漢字」を付与出来ます。 --M-30722 (トーク) 2025年7月6日 (日) 04:56 (UTC)[返信]
(進捗報告)カテゴリ:Unicode CJK Unified Ideographs Extension Aカテゴリ:Unicode CJK Unified Ideographs Extension D→解消済、カテゴリ:漢字のソートがハングル字母になっているもの→個別対応必要(数は多くないので手動対応可能)、ローマンアルファベット順にソートされているもの→個別対応必要(少々数が多いので時間かかるかも)。@ Charidri その他、問題点はありますか? --M-30722 (トーク) 2025年7月6日 (日) 05:31 (UTC)[返信]
まぁ、いままで問題点の認識がされず、いろいろな利用者に、漫然と、常態的に上記節のような編集で後から書き換えられて、私が作成した項目がおかしくなって迷惑だったのが、おかげですこしは解決に向かっています。
問題点。ぱっと見た限り、オンライン環境を前提に作られているので、私のローカルなタスク環境では不向きですね。ソースを見ただけでは項目の識別が困難。ローカルのエディタに不向き。私の活動を排除するならこれでもいいのかもしれませんが。--Charidri (トーク) 2025年7月6日 (日) 06:09 (UTC)[返信]
一つ理解していただきたいのは、WiktionaryをはじめWikimediaプロジェクトは多くの人の共同作業によって成り立っております。従って、一個人の都合にのみに合わせる訳にはいかない(ある程度考慮に入れることなら可能ですが)と考えます。漢字項目の編集にはCharidriさん以外にも多くの人が携わっており、多くの人にとって編集しやすい(ミスを少なく出来る 等)のは何かを考えていく必要があるかと思います。Charidriさんのコメントを読んでいると自分の編集環境の都合を一方的に押し付けて「こっちの編集環境の都合にお前らが合わせろ」といったようにどうしても感じてしまいます。共同作業である以上、他の人の環境の事も考慮に入れていただければと思いますがよろしいでしょうか(もちろんローカルなタスク環境で編集するにあたって都合の悪い部分については出来る限りの考慮はさせていただきます)?--M-30722 (トーク) 2025年7月6日 (日) 06:40 (UTC)[返信]

漢字の文字情報の位置に関する提案

[編集]

提案 提案 現在、漢字項目の見出しは上から漢字→各言語の情報(五十音順)→文字情報(コード番号等)の順に並べられておりますが、文字情報の記述を漢字見出しに移動することを提案します。理由としましては以下の二つです。

  1. ラテン文字、ハングル、アラビア文字、ギリシア文字等漢字以外の文字は文字の見出し内にコードの情報が書かれているのでそれらと仕様を合わせる。
  2. 漢字見出しに書かれている部首・総画・意義等の情報がそもそも文字情報であるのでこれらとコード等その他の文字情報の見出しを分けるのは違和感がある。

見本として「」を編集し、コード番号を漢字見出しに入れる形にしています。どなたかご意見等ありますでしょうか? --M-30722 (トーク) 2025年7月20日 (日) 03:37 (UTC)[返信]

中国語版みたいに{{character info}}が上部に来た方が見やすいとは思ってたので賛成です。--2400:4051:3B61:7F00:AC94:D205:F51B:D95D 2025年7月20日 (日) 04:05 (UTC)[返信]
言うなればハングルの項目みたいにするわけですかね?
昨今の編集で漢字項目の半分くらいにはUnicode等の文字コードにプラスで検字表(文字入力法と字典掲載と)が含まれるようになっています。「喻」はその編集の手が加わっていない項目のようですが、例えばこれが適用されている「」とかに行われたら、前置きが長すぎて「本文に意識がいきにくくなる」のが予想されます。ですから、積極的な肯定とは言い難いです。--Kuroco2k (トーク) 2025年7月20日 (日) 04:37 (UTC)[返信]
(賛成)一貫性があります。 --Naggy Nagumo (トーク) 2025年7月20日 (日) 21:51 (UTC)[返信]
皆さんご意見有難うございます。指摘されている懸念点についてですが、統合により漢字見出しの内容量が多くなったとしてもデスクトップ版の画面なら左側の目次から目当ての見出しをクリックすることで見たい場所に飛べますし、モバイル版の画面なら最初から畳まれている状態になっているので目的の見出しをタップして開けば良いだけなので特に問題ないかなと思います。また、そもそも「前置き」とは何を指し「本文」とは何を指すのかですね、漢字の項目なので字義の部分は明らかに本文と言えるでしょうし、何なら部首や画数の情報の部分から既に本文が始まっているとも見ることが出来ると思います。Wiktionary:編集室/2024年Q3#レイアウト破壊にて指摘されている事柄は{{character info}}の存在自体の話(これが従来通り下側に配置されてようが漢字見出しに統合することで上側に配置されようが)なので(当議論とは分けて){{character info}}のトークページで議論すべき問題かなと考えます。 --M-30722 (トーク) 2025年7月21日 (月) 13:44 (UTC)[返信]
@Kuroco2k もし{{character info}}で表示される表が上に来ることがネックなのであれば統合の際に{{codepoint}}へ置き換えさせていただきますがいかがでしょうか?また、従来の書式を維持して漢字見出しと分けて書にせよ「文字情報」という見出しは見直す必要がある(部首や意義は文字情報ではないのか?という事になりますので)かと思います。 --M-30722 (トーク) 2025年7月23日 (水) 14:03 (UTC)[返信]
(どこか話が合っていないような気がしましたが){{character info}}というよりは、同じ節にある{{文字コード}}とか、{{字典}}とかが長大なので、できれば末尾に載せたいという話です。info自体は上にあっても良いと思います。ただ、少なくとも{{codepoint}}に置き換えるのは避けたいです。--Kuroco2k (トーク) 2025年7月24日 (木) 00:51 (UTC)[返信]
Wiktionary:編集室/2024年Q3#レイアウト破壊で問題視されているのが{{character info}}なので、このテンプレートを取り上げさせていただきました。それでは、もし{{文字コード}}{{字典}}を折り畳み式にするとしたらいかがでしょうか?これらがスペースを取る問題は解決出来るかと思います。 --M-30722 (トーク) 2025年7月24日 (木) 14:31 (UTC)[返信]
実際にどうなるか見てみないとどうにもわかりませんが、とりあえずはそれであれば賛成出来るかな、という感じです。--Kuroco2k (トーク) 2025年7月24日 (木) 14:41 (UTC)[返信]
イメージとしては語形変化表が折りたたまれているような状態です。例えば、amüsantの格変化表の畳まれてる状態をイメージしてもらえると分かりやすいかと思います。 --M-30722 (トーク) 2025年7月24日 (木) 14:53 (UTC)[返信]
統合に関しまして、条件付きではありますが賛同頂けたかと思いますので、続いて{{文字コード}}及び{{字典}}を折り畳む仕様に変更することについて皆様のご意見を伺いたく思います。上記の通り、語形変化表等に用いられている表の右側の「表示」ボタンを押すと展開されるものをイメージしてもらえれば分かりやすいと思います。これに関してご意見等ある方はいらっしゃいますでしょうか? --M-30722 (トーク) 2025年7月24日 (木) 15:55 (UTC)[返信]
遅れて失礼します。編集されたものを見てみないとなんとも言い難いですが、私は文字情報の記述を漢字見出しに移動することに反対です。理由は二つあります。
第一に、漢字項目は漢字の説明から始まるべきという点です。漢字項目に求められているのは漢和辞典としての役割、国語・中日・韓日…辞典としての役割、そしてその一文字の文字情報でしょう。初めに漢和辞典としての性格が強い漢字節、続いて字音と言語別の単語の意味を述べる各言語節、最後に文字情報節とした方がまとまりがあります。
第二に、漢字節が圧迫されるという点です。{{character info}}はページの右に詰めて表示されますが、互換漢字が複数ありそれぞれに画像がある場合は縦に長くなります。そうなると{{字源}}が下に行ったり、「(固定リンク)」のような関連字節の表が圧迫され見辛くなります。
以上の理由から、文字情報の記述を漢字見出しに移動することに反対です。文字情報は「(固定リンク)」や「🌈(固定リンク)」のように項目下部に収めるべきです。--TAKA647 (トーク) 2025年7月25日 (金) 10:15 (UTC)[返信]
一つ目についてですが、今回の統合案は漢字見出しの位置は従来通り最上部で変わりありません。なので今回の案も漢字の説明から始まります。二つ目の圧迫されることについてですが、「」でコード等の情報を漢字見出しの語源の下に配置してプレビューをしてみたところ、特に漢字見出しの表との干渉はありませんでした。記述の位置を考慮すると問題無く表示されるはずです。
また、コード等の見出し名が現在、「文字情報」となっておりますが私は漢字見出しにある情報も文字情報と考えております。なので漢字見出しとは別に「文字情報」という名前の見出しを設けることに違和感があります。もし現行のコードと漢字の見出しを分ける書式を維持するのであれば、例えば「コード等」といった文字情報とは別の名称の見出しにすべきと思いますが、この点はいかがでしょうか? --M-30722 (トーク) 2025年7月25日 (金) 10:30 (UTC)[返信]
一つ目については文字情報節は各言語節の後に置くべきということです。少し書き方が良くなかったですね。漢字節の次は漢和辞典と国語辞典双方の性質を持つ日本語節が置かれ、その後に各言語節が、最後に文字情報節が置かれるべきということです。
二つ目の圧迫については{{character info}}を語源節の下に置くなら(表の圧迫は少し気になりますが)問題ないですね。今度は日本語節まで伸びてきそうですが。
文字情報節について私は「(情報通信技術としての)文字情報節」であり漢和辞典としての説明を収める漢字節とは別物と解釈していましたが、言われてみるとすべて文字情報と言えなくもないですね。節の名前を変えてもいいかもしれません。--TAKA647 (トーク) 2025年7月25日 (金) 13:00 (UTC)[返信]
本提案のきっかけとして、コード番号の書き位置が文字の種類(漢字、ハングル、ラテン文字等)によって異なるので統一を図りたいというのと、コード番号を「文字情報」と呼ぶのは「部首や意義の情報は文字情報ではないのか」といった混乱を招くおそれがあるので解消したいという2点で、これらが解消されるのであれば漢字見出しに統合でも従来通りの配置を維持でも私としてはどちらでも構いません。ただ、従来通りの配置を維持する場合はハングル文字等コード番号が上部に書かれているものについては(書式を統一する観点から)分割をする必要があるかなと考えております。「𒁞」のような楔形文字では楔形文字見出しにコード番号しか書かれていないものもありますのでこれをどう書き換えるか(単にコード番号を分割するだけでは楔形文字見出しが空になってしまう)も考えなければならないですね。
とりあえず、この議論は長期化の可能性があり、かつ現在漢字項目の新規作成が活発なので暫定的に現行の順番(コードが一番下)で、見出しを「文字情報」→「コード等」に変更することとしたいと思いますが、この暫定的な措置に関しては皆さん異論は無いでしょうか? --M-30722 (トーク) 2025年7月25日 (金) 16:25 (UTC)[返信]
@TAKA647さん 一つ目の反対意見に関しては、一般的な漢和辞典の伝統的な構造を維持したいという意見でしょうか?これはコード情報を折りたたむという方法では納得できませんか?私自身は漢和辞典に詳しくないため、どうしてこれで困ることになるのか理解できていません。この変更がどのように問題を引き起こすと考えられているのか、具体的にお伺いできればと思います。私としては、情報を意味的に構造化し、より使いやすく、統一感のある形にしたいと考えています。TAKA647さんが感じる懸念点について具体的に理解できれば、より良い解決策を共に見つけられると思いますので、詳細をお聞かせいただけると嬉しいです。--Naggy Nagumo (トーク) 2025年7月25日 (金) 23:17 (UTC)[返信]
@TAKA647さん 表示に関する補足ですが、日本語節に伸びることもないです。万が一下の節に表が伸びて干渉しそうな場合があったとしても{{-}}を使えば簡単に解消出来ます。 --M-30722 (トーク) 2025年7月26日 (土) 03:24 (UTC)[返信]
文字情報節の改名に関しては編集の手間を考えるとわざわざ変える必要がないとは思いつつも、変更を望む意見が集まれば変えてもいいと思います。正直今のままでも違和感はありませんが、変更後がよくない理由もないので。(そういえばいつの間にか改名されてましたね)
コード番号の位置の統一は私も行われたほうがいいと思いますが、私としてはページ下部に記述する方向で統一したいですね。多数の言語で使われる文字は最初の節で字源や原義を述べ、最後の節にコード番号の記述を載せる形です。楔形文字は詳しくないのでわかりませんが、仮名やハングルなどの字源は日本語節や韓国語節に入れればいいと思います。
私が漢字→各言語→文字情報の順にこだわる理由は、一つは上記のように他の文字体系の項目もこの順にしたいため、もう一つはコード情報はそれ以外の(文字本来の)情報と分けて記述した方がまとまりがあるためです。他のコード情報と{{character info}}は近接させたいですが、下記のように{{character info}}は冒頭への配置と相性が悪いです。漢字という文字体系の特殊性から独自のフォーマットが構築されていますが、こちらの方が多くの文字体系に対応できると思います。他の文字体系を話題に出さないために漢和辞典を交えた説明になってしまいましたが、冒頭に文字本来の情報を置きつつコード情報を離したい({{character info}}を下部に持っていきたい)、他の文字体型にも通用する順にしたい(あわよくば統一させたい)の二点が主な理由です。漢字節を漢和辞典としての役割に特化させたいと言う理由もありますが。
私の環境だと「」のような{{character info}}が縦に長かったり漢字節が短い項目で同様の編集を行うと日本語節を突き抜け中国語節まで到達します。{{-}}を使うにしても漢字節に不自然な空白ができてしまいます。この状態は避けたいです。--TAKA647 (トーク) 2025年7月26日 (土) 15:29 (UTC)[返信]
@TAKA647 実際に「」で漢字見出しに情報をまとめた場合にどうなるか見てもらうのが手っ取り早いかと思いますのでこれを見本項目として編集してみました。コード等の情報を漢字見出しに持ってきたとしても特に日本語節に突き抜けることもなく、また、不自然な空白も出来ておりません(なお、文字コードと字典掲載を折り畳む形にすると空白が生じた為折り畳み無しとしました)。この書式に関してTAKA647さんの環境では懸念されているような問題は生じてますでしょうか?また、もし漢字見出しとコードの見出しを分ける場合、漢点字と六点漢字は漢字見出し側に配置すべきかと思いますが、この点字の位置に関してはどのようなご見解でしょうか?--M-30722 (トーク) 2025年8月6日 (水) 08:28 (UTC)[返信]
折り畳みはなくしたんですね。私としてはやはり、文字コード・字典掲載と{{character info}}の長短によってレイアウトに問題が生じるものは避けるべきだと思います。前者はカテゴリ:Unicode CJK Unified Ideographs Extension Iをはじめとして極端に短いものがありますし、後者は「」や「」、「」など互換漢字が多いものもあります。この互換漢字のほとんどは字形が同一で画像を載せる必要はないかもしれません(個人的には載せたい)が、「」や「」は字形が異なる3つの互換漢字が紐づけられているため将来的に右側が長大になることが確定しています。
あと、これは主観的な意見ですが、第一節の情報量が多くてぐちゃぐちゃしている印象を受けました。やはりこれらの情報は下部にまとめて置きたいですね。
点字に関してはネットにある情報が少ないのでよくわからないというのが本音です。個人的には表記法の話なのでコード等節に置くのがよいと考えますが、他の文字体系の一文字項目と揃えたほうがよいと思うのでここで最終的な結論を出す必要はないと思います。
ちょっと見ないうちに{{文字コード}}{{字典}}の内容が増えましたね。扱う情報についてまた別で議論が必要かもしれません。--TAKA647 (トーク) 2025年8月7日 (木) 16:29 (UTC)[返信]
私としましてはそもそも{{character info}}が邪魔な気がします。字形を示す機能が{{kanji header}}と重複しており、それがぐちゃぐちゃした印象を与えているのではないかと考えております。またこのテンプレートがレイアウトの問題を引き起こす主な元凶になっていますので「character info」は取っ払った方が良いかもしれません。字形を示すのは「kanji header」等に任せて「character info」を使わない形にすると良いかと思うのですが、この点はいかがでしょうか?(レイアウトの問題はこのテンプレートを使わないことで概ね解決出来るかと思います)--M-30722 (トーク) 2025年8月7日 (木) 16:46 (UTC)[返信]
(追記){{character info}}を使わない形に「」を更新しました。これが無ければ折り畳みも行うことが出来、すっきりとした見た目になったかと思いますが@TAKA647さんいかがでしょうか? --M-30722 (トーク) 2025年8月7日 (木) 16:55 (UTC)[返信]
私としては{{character info}}は消さないほうが良いと思います。漢字項目に互換漢字を紐づける仕組みは他にありませんし、典拠Tや典拠KPの互換漢字はフォントが正しく表示されないこともあるため、画像を表示させる意義はあります。個人的にはユニコードのブロック名や前後の文字が見れるのはいいと思いますし、他の一文字項目と合わせた仕組みの方が良いとも思います。
むしろ{{kanji header}}をIVDや互換漢字を使ってやたらと多く載せるのは、閲覧側の環境によって表示される字形が変わってしまうので、避けるべきだと思います。--TAKA647 (トーク) 2025年8月10日 (日) 06:08 (UTC)[返信]
互換漢字などの字形を表示する用途で{{character info}}を使うとすると、コード見出しよりも漢字見出しに配置する方が適切ではないかと思うのですが、この点いかがでしょうか?漢字項目で漢字の字形を確認するのに一番下の見出しまで移動しなければならないというのは変な話かと思いますがいかがでしょうか?--M-30722 (トーク) 2025年8月17日 (日) 05:42 (UTC)[返信]
{{kanji header}}を用いた互換漢字の表示は典拠Jがある漢字のみに留めておけばいいと思います。他の互換漢字は字形被りも多いですし、表示できる環境も限られるので。互換漢字の情報はコード位置やブロックの話なので{{character info}}の位置は末尾のままでいいでしょう。
個人的には{{kanji header}}の大きく漢字が表示されている部分は明朝体フォントではなく画像を置きたいですが、(画像を用意するのが)ちょっと技術的に厳しいので諦めています。漢字の典拠画像とIVDの典拠画像を表示できるテンプレートが欲しいですね。(結構な大きさになると思うので、置くなら項目末尾です)--TAKA647 (トーク) 2025年8月21日 (木) 14:43 (UTC)[返信]
漢字の新規作成を積極的にされている@Kuroco2kさんにも暫定的な措置として行う文字情報節の改名に関するご意見を伺いたいと思いますが、見出しを「文字情報」→「コード等」に変更することに同意はいただけますでしょうか? --M-30722 (トーク) 2025年7月27日 (日) 08:03 (UTC)[返信]
暫定的なものとしては賛成 賛成です。
ただ、個人的に「等」という表記が個人的に若干気に入らず(具体的でないというか、そういう風に見える)、積極的に推し進めよう、というものではないです。例えば、『漢字辞典オンライン』では「文字コード」と「検字番号」というように分けていますから、最終的には例えば「文字コード・検字表」みたいに表記出来たほうが、読者には分かり易いかなと感じます。--Kuroco2k (トーク) 2025年7月27日 (日) 08:18 (UTC)[返信]
それでは、「文字コード・検字表」でいけそうであればこの名称でいきましょうか。もし後でもっと適切な名称を思い付いた時に一斉変更を行えるようにテンプレートを用いて見出しを付けると良いと思います(テンプレートの名称をどうするかですね)。 --M-30722 (トーク) 2025年7月27日 (日) 08:37 (UTC)[返信]
(追記)とりあえず、「テンプレート:コード」という名称でいかがでしょうか? --M-30722 (トーク) 2025年7月27日 (日) 08:46 (UTC)[返信]
{{ja}}{{noun}}みたいなものですか?--TAKA647 (トーク) 2025年7月27日 (日) 09:45 (UTC)[返信]
@TAKA647 はい、そのようなものです。 --M-30722 (トーク) 2025年7月27日 (日) 09:54 (UTC)[返信]
文字情報→コード等の改名に賛成します。テンプレートの名称は他の物に合わせて「about code」とかにするといいかもしれません。--TAKA647 (トーク) 2025年7月29日 (火) 15:45 (UTC)[返信]
@ら゚いと 𠄿でコード番号等を扱う見出しを「文字情報」とされておりますが、この見出しを「コード等」に改名することに反対でしょうか? --M-30722 (トーク) 2025年7月28日 (月) 12:35 (UTC)[返信]
ごめんなさい、この議論を見ていませんでした。改名に賛成です。--ら゚いと (トーク) 2025年7月28日 (月) 15:47 (UTC)[返信]
これまでの議論をを通して、そもそも{{character info}}{{kanji header}}の使用の是非の点から意見が割れており全くまとまっていない状況です。これらのテンプレートはある一人の編集者により合意も事前の周知も無く大規模に行われたもので、まずはこれらのテンプレートの使用の是非から決める必要があるのではと思いました。そこでこの議論は一旦中断してWiktionary:編集室/2024年Q3#レイアウト破壊の方でテンプレートの使用方針を決めたいと思います。 --M-30722 (トーク) 2025年8月24日 (日) 06:59 (UTC)[返信]
上記議論にて暫定的な扱いが決まったので見本項目「」を再編集しましたが、この書式案については皆さんいかがでしょうか? --M-30722 (トーク) 2025年8月31日 (日) 15:05 (UTC)[返信]
点字と文字コード、字典掲載を維持しつつ以前のフォーマットに戻したというとことですね。文字情報以外の要素に触れずにコメントすると、個人的には点字はいらないと思いますが、やはりコード情報等は項目末尾に欲しいですね。あと、{{character info}}はやはりあった方がよいと考えます。--TAKA647 (トーク) 2025年9月1日 (月) 06:51 (UTC)[返信]
直接的に思うのは「改変後のものを全部排斥する必要はない」という点です。例えば{{検字}}はもともとのフォーマットを踏襲しており、使用に問題がないと考えます。それに、私はアルファベットで示すものはいくつか存じておりますが、漢字併記するものは少なくとも私は存じておらず、専門的な知識がある(か、覚えている)人でないと掲載に手間がかかるものと推察されます。
{{文字コード}}が元のフォーマットとテンプレートとで一長一短というところで、テンプレートにはCNとKRのEUCが書かれていません。逆に、今のフォーマットにはMJ文字図形やKSX、全字庫の指定がありません。(これを書いてるうちに気づいたのですが、カテゴリ:符号化文字集合という放置されてるだろうカテゴリを発見しました。可能なら入れたいところですが...これもこれで{{文字コード}}を大幅にいじることになりそうです。)
コードや{{character info}}の位置の是非についてはひとまず判断しません。--Kuroco2k (トーク) 2025年9月1日 (月) 07:28 (UTC)[返信]
皆さんにお願いなのですが、議論する上での前提条件を揃えたいので「テンプレート:標準の内容/漢字」の書式をベースに考えていただき、この書式で「コード等」見出しの位置をどこにするかについて議論していただきたく思います。個別のテンプレートの使用是非については各テンプレートのトークページにてお願いします。 --M-30722 (トーク) 2025年9月1日 (月) 10:24 (UTC)[返信]
(追記)誤解のないよう申しますと、特定のテンプレートを排斥する意図は一切ありませんし、むしろ有用なテンプレートであればどんどん使用すべきという考えです。Vinegar03氏により大規模に付与されたテンプレート等には合意なく大規模な改変が行われ、必要な手順が踏まれていない為使用するにあたってまずはきちんと手順を踏みましょうという事で、各テンプレートについてそれぞれ合意形成をお願いしたく思います。 --M-30722 (トーク) 2025年9月1日 (月) 10:32 (UTC)[返信]
特に新たなコメントは無く、全会一致は厳しそうなので投票を行って多数決を取ろうと思いますが他にご意見等はございませんでしょうか? --M-30722 (トーク) 2025年9月3日 (水) 18:08 (UTC)[返信]
それでは、投票を行います。提案の通り「コード等」見出しの情報を漢字見出しに移動して統合することを指示する場合は賛成 賛成、現状の形式(「コード等」見出しを言語毎の情報の後、つまり一番下に記載)を維持する場合は反対 反対でお願いします。その他ご意見がありましたら コメントでご意見を記載いただければと思います。投票は2週間(日本時間の9月19日まで)としたいと思います。 --M-30722 (トーク) 2025年9月5日 (金) 13:41 (UTC)[返信]
賛成 賛成 提案者票。今のように分ける形の場合、漢点字が漢字見出し、コード見出しどちらに該当するかがグレーで、漢字以外の文字にも適用する場合の事を考えると例えばかな文字の点字・モールス信号、手話等の情報を「ひらがな」「コード等」どちらの見出しに入れるべきか曖昧なものが生じるおそれがあるが、一つの見出しに統合するとそのような問題が発生しない為。また、楔形文字のような文字の見出しにコード情報しか記載されていないものは分けてしまうと文字の見出しが空になっていまうおそれがある為。
なお、投票の際には理由を記載していただいても構いませんし、単に「賛成」「反対」のみでも大丈夫です。 --M-30722 (トーク) 2025年9月5日 (金) 13:50 (UTC)[返信]
賛成 賛成 意味的な一貫性向上のため。 --Naggy Nagumo (トーク) 2025年9月5日 (金) 22:48 (UTC)[返信]
反対 反対 ここに至るまで長く議論してきましたが、依然として反対です。仮に現在項目下部に置かれている情報をすべて第一節に持ってくると、項目冒頭の情報が過多となってしまいます。字源や字義に直接関連しない文字コードや点字表記、モールス符号は項目下部に持ってくるべきです(漢点字は削ってもいいと思いますが)。情報が一目でわからない{{NavTopL}}も使わないに越したことはないでしょう。今後典拠やIVD等の情報が増えたときに項目上部が長大になるのは避けたいです。また、個人的に一文字項目に置きたいと思っている{{character info}}が冒頭への記述と相性が悪いことも理由の一つです。他の文字体系の一文字項目で文字コードしか第一節の内容がない項目は{{NavTopL}}だけの項目になってしまうなら、文字見出し無しでいいんじゃないでしょうか。--TAKA647 (トーク) 2025年9月8日 (月) 16:33 (UTC)[返信]
反対 反対 遅れましたが。言いたい(が、うまく言葉にできなかった)ことの多くはTAKA647さんが代弁してくれたので多くは語りません。--Kuroco2k (トーク) 2025年9月10日 (水) 10:52 (UTC)[返信]
残り1週間となりましたが、現時点で賛否が半々の状況です。今後の皆さんの投票次第で結果が変わってきますのでより多くの方の意見を反映出来ればと思いますので是非よろしくお願いします。特にコメント無ければ単に「賛成」「反対」のみ表明していただいても大丈夫です。 --M-30722 (トーク) 2025年9月11日 (木) 17:17 (UTC)[返信]
本日いっぱい(日本時間)で投票を締め切りますので賛否表明される方は今日じゅうにお願いします。 --M-30722 (トーク) 2025年9月18日 (木) 16:16 (UTC)[返信]
却下 賛成2票、反対2票で、賛成票が過半数に満たなかった為本提案は否決となりました。
終了 また、最下部に設ける見出しを「文字情報」→「コード等」に変更する件については可決とします。もしより良い名称を思い付いた方がおられましたら改めて議論していただけると幸いです。

水平線の利用方針について

[編集]

現在、水平線(----)の利用方針は決まっていないかと思います。私の考えとしましては、少なくともLevel 2見出し(ハイフン2個で挟むやつ)の直前の水平線は不要であり見つけ次第削除したいとは考えておりますが、積極的に水平線を追加している編集者もおり、このままではイタチごっこになってしまうでしょう。以上より、私はLevel 2見出しの直前の水平線は非推奨とする裁定を提言します。--TAKA647 (トーク) 2025年7月25日 (金) 09:17 (UTC)[返信]

コメント 過去の議論ではWiktionary:編集室/2007年#漢字フォーマット改正案についてにて水平線に関する言及はあります。この時は特に結論は出ていませんが、水平線を入れる理由として例えば用例の下に次の言語見出しが来る場合に「用例を列挙後、他の言語セクションが来ると、タイトルと用例が接近しすぎていて、見づらい」という意見が出ており見やすさを確保するために入れられているようです。現在では慣例的に用いられておりますが、水平線を不要とする理由について詳しく聞かせていただけませんか?(理由次第で賛否を判断します) --M-30722 (トーク) 2025年7月25日 (金) 10:37 (UTC)[返信]
水平線を不要とする理由は、煩雑になるためです。少なくとも現在のページの外装ではLevel 2見出しに水平線が付属しており、ここにさらに水平線を加えると横線が2本隣接し煩雑であり、短い節が続けば尚更です。わざわざ節のタイトルを水平線で挟む必要はありません。
先の議論について言うなら、現在は本文と節が隣接し可読性を損なうことはありません。--TAKA647 (トーク) 2025年7月25日 (金) 13:45 (UTC)[返信]
分かりました。それでは他の編集者の意見を聞いた上で意見の多い方を採用しようと思います。 --M-30722 (トーク) 2025年7月25日 (金) 16:27 (UTC)[返信]
水平線無しの表示を確認したところ、特に見にくい感じはなさそうなので無しでも問題はないかと思います。 --M-30722 (トーク) 2025年7月26日 (土) 16:00 (UTC)[返信]
私が普段利用している環境(スマホ、モバイルビュー)では、水平線を入れずに本文とレベル2見出しが近くなっている状態であっても、そこまで可読性を損なうことはありません。しかし、これをデスクトップビューにすると、本文の文字の大きさとレベル2見出しの文字の大きさがほとんど同じであるため、本文と見出しを区切る水平線がないと少しではありますが可読性を損ないます。少なくとも、私のスマートフォンではそのような表示になります。このような環境にも配慮するため、水平線を入れた方が良いかなと考えております。--ら゚いと (トーク) 2025年7月26日 (土) 16:14 (UTC)[返信]
デスクトップビューの場合でもLevel 2見出しに付属する編集ボタンと直下の水平線の存在により区別はつくと思います。節内の文が2、3行しかない場合は水平線が近接することになり、かえって見づらくなることも考えられます。--TAKA647 (トーク) 2025年7月27日 (日) 10:11 (UTC)[返信]
確かに内容の少ない節が連続すると見づらくなるかもしれませんね。「可読性を損ないます」とは書いたものの、ほんのちょっと見づらくなるかな程度ですし、水平線を入れなくてもそこまで問題はないと思います。--ら゚いと (トーク) 2025年7月28日 (月) 09:32 (UTC)[返信]
提案 提案 Wiktionary:スタイルマニュアルにLevel 2見出し直前の水平線を非推奨とする文言の追加、およびリンク先のテンプレート内のLevel 2見出し直前の水平線の削除を提案します。なお、水平線の使用自体を非推奨とするものではありません。
日本時間8月6日0:00までに反対意見がなかった場合、十分な期間を掛けたと見做し同意を得られたものとします。--TAKA647 (トーク) 2025年7月29日 (火) 16:12 (UTC)[返信]
それで問題ないです。 --M-30722 (トーク) 2025年7月29日 (火) 16:32 (UTC)[返信]
反対するわけではありませんが、公式スキン全種類(Vector, Vector 2022, Monobook, Timeless, Minervaなど)について、デスクトップビュー・モバイルビューのそれぞれで確認されていますでしょうか。すでに確認済みでしたら失礼しました。提案内容自体には特に問題を感じませんが、理由の部分がやや主観的で、私にとっては是非を判断しにくいと感じます。--Naggy Nagumo (トーク) 2025年8月1日 (金) 23:22 (UTC)[返信]
すでに書いたつもりですっかり忘れていました。5種類の外観およびモバイルビューでの表示は確認済みであり、問題はないかと思います(モバイルビューは外観変更できないんですかね)。
理由は上記の通り横棒が過剰になってしまう点と、Level 2見出しに付属する水平線や編集ボタンの存在により節の判別は容易であるためです。また、水平線に関する方針がWiktionary内で存在しないために水平線を記入する編集と記入しない編集が共存している現状を打破する意図もあります。--TAKA647 (トーク) 2025年8月2日 (土) 16:11 (UTC)[返信]
終了 期日までに反対意見が付かなかったため、編集しました。--TAKA647 (トーク) 2025年8月5日 (火) 15:58 (UTC)[返信]
@鍼灸 南窓北窓で水平線を使用されておりますが、廃止に反対でしょうか? --M-30722 (トーク) 2025年8月17日 (日) 15:04 (UTC)[返信]
反対というよりは言語が嵩張らないようにして頂ければ何でも良いです。--鍼灸 (トーク) 2025年8月18日 (月) 04:45 (UTC)[返信]
皆さんの指示に従います。--鍼灸 (トーク) 2025年8月18日 (月) 04:45 (UTC)[返信]

熟語で異体字セレクタを使うか

[編集]

規矩󠄁準繩の項目を見ていて思ったのですが、異体字セレクタを用いて熟語項目を作るべきでしょうか。以前単字についてどうするべきか聞いた時は「単項目としてあってよい」との回答をいただきましたが、熟語となれば少し話が変わってくると感じます。いわゆる正字の表記を優先するべきなのでしょうか?--Kuroco2k (トーク) 2025年7月25日 (金) 10:05 (UTC)[返信]

異体字セレクタを項目名に使うのはやめた方がいいと思います。仮に異体字セレクタで旧字体を表現するにしてもフォントが対応してなければ違いがわかりませんし、Adobe-Japan1コレクションとMoji_Johoコレクションのどちらを使うのかということになってしまいます。現状異体時セレクタに関する指針は存在していませんが、きちんと決める必要があるでしょう。(正直私は異体字セレクタを用いた漢字項目も必要ないと考えていますが。)--TAKA647 (トーク) 2025年7月25日 (金) 12:35 (UTC)[返信]
私が熟語について異体字セレクタを用いて改変&作成している本人です。
私は異体字セレクタを用いての熟語項目を作ることを希望します。
1
私が編集している記事は,「〜の旧字体表記」とあるものであり,それら記事内で注目されているものは表記についてです。なので優先されるべきは表記だと思います。
2
もし用いることが可能な場合にはどちらを使うかについてなどは新たに指針を定めればよいと思います。
----
ですので用いての表記に賛成します。--ダイタクヘリオス (トーク) 2025年7月25日 (金) 13:13 (UTC)[返信]
@ダイタクヘリオスさん ここまで技術的な観点からの反対がありましたが、なにか意見はありますでしょうか。--TAKA647 (トーク) 2025年7月29日 (火) 16:34 (UTC)[返信]
異体字セレクタを日本語項目に用いることに反対します。以下に理由を列挙します。
第一に、フォントが対応していなければ区別がつかない点です。現在はAdobe-Japan1コレクションに対応したフォントもある程度あるようですが、閲覧するブラウザのフォントが異体字セレクタに対応していなければ異体字セレクタを用いていない項目名と区別することができません。また、項目名が異体字セレクタの字形になっていても本文で対応できてない場合もあります。これは閲覧、管理の双方から不便です。
第二に、テンプレートが対応しきれない点です。私が確認した限りでは{{ja-kanjitab}}は異体字セレクタを適用しない文字が表示され、{{ja-noun}}では本文は異体字セレクタに対応した文字ですが、リンク先は異体字セレクタが外れた文字になっています。これらの他にも対応できていないテンプレートがあることが予想されます。
第三に、カテゴリが氾濫する点です。異体字セレクタを適用した項目はその性質から漢字と異体字セレクタを混ぜ書きしていると見做されるため、カテゴリ:日本語 字種混合表記へ入れられるようです。これはこのカテゴリの本来の意味に反しており不都合です。
第四に、旧字体の定義が不明確な点です。旧字体と言うものは定義が曖昧であり、JIS漢字であれば新字体・旧字体の対応はある程度定まっていると思いますが、これを異体字セレクタまで拡張すると雲行きが怪しくなります。八屋根は区別するのか、筆押さえは区別するのか、表外漢字に適用するのか、JIS外漢字に適用するのかなど、考慮すべき点が大量に出てきます。これらを体系的に整理する方法はないですし、コミュニティで合意を得るには苦労するでしょう。
以上より、私は異体字セレクタを日本語項目に用いることに反対します。なお、漢字項目については別の場所に議論を譲ることにします。--TAKA647 (トーク) 2025年7月25日 (金) 15:13 (UTC)[返信]
TAKA647さんとと同意見で、私は異体字セレクタを項目名に使用することは反対です。異体字セレクタは同じ文字を異なる表示にする技術です。TAKA647さんが述べた通り、フォントがなければ区別できないというのは非常に正確です。さらにフォントが存在し異体字が表示される場合でも、データとしては同じ文字です。これを区別して運用するのは、混乱を引き起こすだけでなく、データベースやシステムの整合性に問題を生じさせる可能性がないでしょうか?さらに、異体字セレクタが適切に表示されない場合、表示環境依存で一貫性のない結果が得られ、ユーザーが誤解する恐れもあります。このような不確実性がある中で異体字セレクタを使用するのは、非常に難しい選択だと思います。--Naggy Nagumo (トーク) 2025年7月25日 (金) 23:35 (UTC)[返信]
最近コメントがされていないので結論を出したいと思いますが、当議論については反対意見が優勢なので 却下ということで締めて良いでしょうか? --M-30722 (トーク) 2025年9月11日 (木) 17:12 (UTC)[返信]
長期間経ちましたがこれ以上の票が付く見通しもないので、 却下としてよいでしょう。利用者:ダイタクヘリオスさんの作ったそれに該当する項目を一斉リバートする必要性がありそうです。--Kuroco2k (トーク) 2025年11月27日 (木) 07:55 (UTC)[返信]

画期的でこのテンプレートを使用してみたところ、カテゴリ:日本語 接尾辞"的"ではなくカテゴリ:日本語 接尾辞 的が付与されました。私には直し方が分からないので、ここで報告だけさせていただきます。--240B:253:E780:DC10:4EF3:B2DB:80BC:4C1C 2025年8月1日 (金) 10:20 (UTC)[返信]

対処「〇〇的」の形のものは{{-的}}を使えば簡単です。このテンプレートを使って「画期的」を編集してみたのでご確認下さい。 --M-30722 (トーク) 2025年8月1日 (金) 14:17 (UTC)[返信]

質問です

[編集]

単漢字の項目において中国語の熟語の漢字に中国語のフォントを適用することがあるのですが、適用するフォントに何かしらの基準はあるのでしょうか?簡体字と繁体字でZHsimとtraで使い分けるのか、あるいは無条件でzh-lを適用するのか、それともそもそも中国語のフォント適用自体するべきでないのかを一応お聞きしたいです。--Jiba1219 (トーク) 2025年8月3日 (日) 05:55 (UTC)[返信]

ユーザーは見た目(フォント)を直接指定するのではなく、意味に基づいてテンプレートを使い分けることを意識してほしいです。ZHsimとZHtraはそういうノウハウがあまりなかった古い時代のテンプレートなので、より良いスタイルを保てる新しいテンプレートに置換することはよい選択でしょう。ただ{{zh-l}}に説明が全くなく、どう使えばいいのか判断が難しい状況です。よくある作り方であれば記法(よく引数sc=で実装されてるやつ)を指定できれば情報を失わずに置換できるのですが、使えるかどうかよくわかりません。--Naggy Nagumo (トーク) 2025年8月9日 (土) 06:45 (UTC)[返信]

項目の削除に関する要望

[編集]

管理者様におかれましては日々の管理活動ありがとうございます。さて、現在Wiktionary:削除依頼Wiktionary:正確性検証中において長期間削除待ちのものが複数存在します。文法関連のカテゴリは削除確定から5ヶ月、あはるに至っては検証不能となってから1年近くも削除が行われていない状況となっております。削除依頼や正確性検証は即時削除や荒らし対応に比べると優先順位が低く急ぎの案件とまでは言えない事は承知しておりますが、それでも1年近く未対応のものがあるのはあまり好ましい状況と言えないかなと感じております。管理者の方どなたでも構いませんので速やかに対応していただけますと幸いです。また、即時削除についても2ヶ月程対応されていないものが複数ありますのでご対応の程お願いします。 --M-30722 (トーク) 2025年8月9日 (土) 17:35 (UTC)[返信]

「関連語」節

[編集]

現在、「関連語」「類義語」「対義語」は才子危険の項目のようにそれぞれ別々の節とするのが主流かと思われます。それらを全て「関連語」節にまとめることを提案します。理由は以下のとおりです。

  • それぞれで節を分けていると、節が多くなり逆に見づらい。
  • 「類義語」「対義語」は「関連語」の下位語であり、節を分けるのは適切とは言い難い。

形としては長身の項目のようなものを想定しております。--240B:253:E780:DC10:4C1E:558C:3865:BD8A 2025年8月16日 (土) 07:43 (UTC)[返信]

コメント 節が多くなることが問題なのであれば{{syn}}{{ant}}の引数2以降を使って「減弱」のような形にする方法もありますが、これではいけないでしょうか? --M-30722 (トーク) 2025年8月17日 (日) 04:59 (UTC)[返信]
その形にした場合、「関連語」と「類義語」「対義語」が同列になってしまう点が解決できません。先ほども言いましたが、類義語・対義語は関連語に含まれるので、関連語節の下に類義語・対義語をあなたの言ったようにテンプレートの引数2を用いて配置し、それ以外の関連語は普通に書けばいいと思います。--240B:253:E780:DC10:E246:512B:A689:420B 2025年8月18日 (月) 05:08 (UTC)[返信]
短命の項目を編集してみましたが、いかがでしょうか?--240B:253:E780:DC10:E246:512B:A689:420B 2025年8月18日 (月) 05:22 (UTC)[返信]
これらのテンプレートはobsidereのように語義ごとに類義語や対義語を示すことが出来ますが、関連語に縛り付けてしまうとこのような事がしにくくなります。関連語節でこれをやろうとするとdrehenのように「類義語: 1.」「類義語: 2.」みたいな書き方をしなければならず場合によってはこちらの方が見にくくなります。なので関連語節にまとめることを義務付けるのには反対 反対です。また、類義語や対義語以外にも「派生語」「上位語」「下位語」「同族語」「部分語」といったものもありますがこれらの扱いについてはどのような考えでしょうか? --M-30722 (トーク) 2025年8月20日 (水) 17:30 (UTC)[返信]
他の方は関連語見出しに関して何かご意見ございますでしょうか? --M-30722 (トーク) 2025年8月28日 (木) 15:22 (UTC)[返信]
特に他の意見も反論も無さそうなので本提案は 却下とのことで締めたいと思いますがご意見等はありますでしょうか? --M-30722 (トーク) 2025年8月31日 (日) 15:08 (UTC)[返信]
却下 それでは、本提案は却下とします。 --M-30722 (トーク) 2025年9月11日 (木) 17:13 (UTC)[返信]

以前削除されたページについて

[編集]

2006年に「ネット右翼」のページが「ごく狭い集団で用いられていると思われる新語・俗語」とされ削除されていますが、現在では、当時と比べてはるかに認知度が高まり、英語版やマレーシア語版にも記事が存在することから改めて作成したいのですがどうでしょうか。--Jiba1219 (トーク) 2025年8月25日 (月) 14:59 (UTC)[返信]

賛成 賛成 Wiktionary:編集方針を満たしているものと思います。 --M-30722 (トーク) 2025年8月25日 (月) 15:52 (UTC)[返信]
特に反対意見はなさそうなので作成します。--Jiba1219 (トーク) 2025年8月27日 (水) 15:40 (UTC)[返信]

{{cmn-pron}}について

[編集]

héyīと入力するとエラーが出るのですが自分だけでしょうか?--Jiba1219 (トーク) 2025年8月27日 (水) 15:42 (UTC)[返信]

どうやらこのテンプレートが使用されている他のページでも起きているようです。(すべてではありませんが)--Jiba1219 (トーク) 2025年8月27日 (水) 15:51 (UTC)[返信]
テンプレート・トーク:cmn-pronでその話題が出ていますね。何か情報等ありましたらこちらにお願いします。--ら゚いと (トーク) 2025年8月27日 (水) 16:09 (UTC)[返信]

見出しの並び順

[編集]

文字情報関連の議論で結論が出て、文字等に関する情報のうち、ページ最上部に書くべきものと最下部に書くべきものを区別する必要がありますので見出しの全体的な並び順について議論したいと思います。議論の結果、並び順としては上から文字に関する情報→日本語→その他言語(五十音順)→情報通信技術関連の情報(コード等)となると思います(言語の並びについてはWiktionary:編集室/2018年Q1#言語の排列についてで決定済)が、文字に関する情報に入れるべきかコード等の情報に入れるべきか迷うものもありますのでどちらに入れるべきかを決めていきたいと思います。以下のものについて皆さんのご意見を伺いたく思います。

  • 点字、指文字(手話)、通話表、モールス信号(項目例:
  • 数学・音楽・化学・物理学等で用いられる記号、言語コード(項目例:sin

私の意見としましては点字、指文字、数学等の記号は最上部の見出し(これらは通信情報技術関連ではないと思う為)、通話表、モールス信号、言語コードは通信情報技術関連なので最下部の見出しになるかなと思いますがいかがでしょうか? --M-30722 (トーク) 2025年9月19日 (金) 16:03 (UTC)[返信]

文字見出しとコード等の見出しの区別について@TAKA647に伺いたいのですが、コード等見出しの対象は情報通信技術関連のもので、それ以外は文字見出しという認識で問題ないでしょうか? --M-30722 (トーク) 2025年9月23日 (火) 14:44 (UTC)[返信]
私が想定しているのは、①言語横断的な情報は冒頭(記号・略称としての用法、画数、書き順、異体字、関連字、字源、由来、部首、関連字)、②それ自体が意味を持たない情報は末尾(符号位置、モールス符号、点字、手話、輸入法、通話表、検字番号)、といった具合です(漢点字はいらないと思っていますが)。仮名の前後の文字は関連字でありますし、楔形文字のSign Numberは検字番号とみなせるでしょう。あまり無いとは思いますが、特定の文字体系特有の分類が難しい情報を載せることになった時は議論ののちスタイルマニュアルに記載するのが良いでしょう。--TAKA647 (トーク) 2025年9月24日 (水) 02:20 (UTC)[返信]
冒頭の情報についてはenwiktのTranslingual見出しのようなイメージでしょうか?但しenwiktではUnicode番号もTranslingual見出しで扱われているのでjawiktの冒頭部分とは少々扱いが異なるかも知れませんが。例えばsinの場合は数学の正弦であるという情報は言語横断的なので冒頭、シンハラ語のISO 639-2/3言語コードであるという情報は(それ自体意味を持たないと判断して良いかは自信ありませんが)末尾となるでしょうか?--M-30722 (トーク) 2025年9月24日 (水) 13:34 (UTC)[返信]
まさしくTranslingual節のようなものです。sinの件はおっしゃる通りですが、シンハラ語の件は略称に近いので冒頭をがよいかと思います。最初のコメントで項目例にsinが出されているのを見落としていましたが、コード等節は一文字項目と一部の合成文字項目のみに置く想定でした。手話は文字列ではなく語に対応するらしいので、各言語節に配置する方がいいかもしれません(点字は専門外です)。--TAKA647 (トーク) 2025年9月25日 (木) 05:19 (UTC)[返信]
(コメント及び進捗状況)分け方のルールについては多くの編集者にとって分かりやすいようになるべくシンプルにしたいところです。いっそコード番号と字典掲載をコード等見出し、その他は文字見出しとしても良いかも知れません。また、漢点字については日本の漢字について用いるもののようなので日本語見出し内に置くのが良いのかも知れません。続いて現在の対応状況についてですが、ハングル文字の項目について「」で始まる文字は文字見出しとコード見出しの分離が完了しました(新書式での編集をしやすいテンプレートも作成・導入しました)。 --M-30722 (トーク) 2025年10月7日 (火) 13:31 (UTC)[返信]
四角号碼や倉頡輸入法はUnihanや古今文字集成など多数のサイトで確認できますが、漢点字・六点漢字の具体的な符号はアーカイブ化されたサイトや個人のものと思われるサイトのものしか確認できず、使用実態に疑問が残ります(日本漢点字協会は2020年3月に解散)。今後これらを多くの項目に適用するとなれば参照元となる確かな出典が必要となりますが、現状それらを見つけることができていません。この状況では検証可能性に支障をきたすと思われるため、漢点字・六点漢字の記述を全廃するべきであると考えています。--TAKA647 (トーク) 2025年10月8日 (水) 08:43 (UTC)[返信]
使用実態が疑われるものとしては過去にはインドネシアで話されるチアチア語のハングル表記に関して正確性検証が出された前例がありますが、その時はラテン文字表記の項目のみを残してハングル表記はリダイレクト化することで決着しました。個人的な使用に留まっているとのことであればチアチア語のハングル表記以上に使用実態に疑問が生じてきますので廃止が妥当かも知れません(なお、漢点字の執筆者を調べたところ例の大規模編集を行なった編集者でした)。--M-30722 (トーク) 2025年10月8日 (水) 15:53 (UTC)[返信]

質問です

[編集]

訳語の節にあるt+|zh|马耳他の+や-にはどういった意味があるのですか?--Jiba1219 (トーク) 2025年9月23日 (火) 13:48 (UTC)[返信]

「+」は他言語版にその記事があることを表し言語間リンク(訳語右上の括弧)を青で表示し、「-」は他言語版に記事が無いことを表し言語間リンクを赤で表示します。例えば植物学のドイツ語の訳語に着目すると、ドイツ語版に記事のあるBotanikには「t+」、記事の無いPflanzenkundeには「t-」がそれぞれ使われております。 --M-30722 (トーク) 2025年9月23日 (火) 14:15 (UTC)[返信]
ありがとうございます。--Jiba1219 (トーク) 2025年9月23日 (火) 15:18 (UTC)[返信]

漢字項目の作成に関して

[編集]

新規作成される項目の中に合意に沿わない形のものが散見されますが、現在合意形成されているスタイルは{{標準の内容/漢字}}の書式です。特に以下の点ご注意下さい。

  • {{kanji header}}及び{{character info}}は合意形成不十分かつ使用に関して賛否が分かれているテンプレートなので現在使用を停止しています(非推奨のレンプレートに指定しました)。なのでこれらのテンプレートは合意が確立するまで使用しないで下さい
  • コード番号等を記載するページ最下部の見出しの名称は「文字情報」ではなく「コード等」です。

以上よろしくお願いします。 --M-30722 (トーク) 2025年9月23日 (火) 14:59 (UTC)[返信]

合意が形成されるまではそれでいいと思います。一つお尋ねしますが、@M-30722さんは{{ja-kanji}}の使用についてはどうお考えでしょうか。私の考えでは、特に常用音訓周りの見た目が整うので積極的な使用を求めたいです。--TAKA647 (トーク) 2025年9月24日 (水) 02:28 (UTC)[返信]
表が見やすいですし概ね良いかと思いますが、{{kana-DEFAULTSORT}}の自動適用機能は要らないのでは(通常通りページ最上部にDEFAULTSORTを指定する方式にすべき)と思います。この機能があると意図しない読みがデフォルトに指定され、誤ったソートキーの付与に繋がる恐れがあるかと考えています。--M-30722 (トーク) 2025年9月24日 (水) 13:25 (UTC)[返信]
返信ありがとうございます。なるほど。ソートキーの仕様はあまり詳しくないので、他の方々に任せたいですね。
重ねての質問失礼します。{{kanji variants}}についてはどうお考えでしょうか。私としては、従来の記法が長ったらしいため積極的に使用したいです。並び順がユニコード順になる点は、一意に定まると考えるとメリットだと思います。チュノムの多読字に関しては考えあぐねていますが、チュノム用の新しいテンプレートを作ってもいいかと思います。--TAKA647 (トーク) 2025年9月25日 (木) 05:01 (UTC)[返信]
{{kanji variants}}については特に私としては反対意見はありませんが、並び順を気にしている人が居る為議論を経た方が良いかもしれません。 --M-30722 (トーク) 2025年9月25日 (木) 17:07 (UTC)[返信]

カテゴリー付与について

[編集]

たとえばおおおびの場合は「衣類」のカテゴリが適切かと存じますが、その和語に対する漢字表記である「大帯」あるいはその旧字体表記である「大帶」、この三つのすべてに「衣類」のカテゴリを付与すべきでしょうか。あるいは語の解説が直接載っている「おおおび」のみに付与すべきでしょうか。現在では和語の平仮名表記のページのみにカテゴリが付与されている場合と、漢字、あるいはその異表記を含めて付与されている場合が混在している状態ですが何かしらの基準はあるのでしょうか。--Jiba1219 (トーク) 2025年9月26日 (金) 12:19 (UTC)[返信]

個人的な意見としてはメインのページに付いていればOKかなと思います。「大帯」や「大帶」はソフトリダイレクトで、メインのページである「おおおび」に誘導する役割であるので特に必要ないかなと思います。ソフトリダイレクトへのカテゴリ付与について具体的な取り決めは無かったかと思いますのでこれを機に決めていくのが良いかなと思います。 --M-30722 (トーク) 2025年9月26日 (金) 13:15 (UTC)[返信]
ありがとうございます。ついでに確認させていただきたいのですが、中国語の簡体字表記や、朝鮮語の漢字表記といった異表記についてはどのように扱うのが望ましいか、皆さんのお考えも伺いたいです。--Jiba1219 (トーク) 2025年9月26日 (金) 13:51 (UTC)[返信]

テンプレート:kanji variantsの利用について

[編集]

単漢字項目における{{kanji variants}}の積極的使用を提言します。現在の基本フォーマットでは異体字を列挙するために「<span style="font-size:250%">[[●]]</span>」を連続して書いていますが、この記述方法ではソースコードが長大になってしまいます。一方で{{kanji variants}}を用いれば遥かに短い文字数で同様に列挙させることが可能です。相違点を挙げるとするならば異体字がUnicode順に並ぶことですが、文字の順番が一意に定まるという点はメリットであると考えます。以上より、今後は異体字を列挙するために{{kanji variants}}を使用していくと取り決めたいです。ご意見のほど、よろしくお願いします。--TAKA647 (トーク) 2025年10月7日 (火) 05:04 (UTC)[返信]

賛成 賛成 「字義の違い等で同じ文字を複数入れたい」場合は、各異体字の説明で「繁体字/簡体字・別字衝突」などを両立しているように、説明欄に「字義○, △, □」などと記せばよいと思います。--~2025-27136-46 (会話) 2025年10月7日 (火) 05:41 (UTC)[返信]
単漢字項目を数多く立項している@Kuroco2kさん、@Aaaa!₃.₁₄さんの意見もお聞きしたいです。--TAKA647 (トーク) 2025年10月11日 (土) 03:49 (UTC)[返信]
コメント 明確に賛否を示せるところでないのでコメントにとどめますが。
  1. 例えば「異体字の異体字」というケースがありますが、いわゆる正字のコードの前にも後ろにも異体字がある場合、「B(同字), A(正字), C(同字)」といった形になり、あまり好ましい配置ではなくなります(基本正字を先頭に、異体字をその後ろに配列したいです)。
    • 」が多分その顕著な例でしょうか。編集画面で実際にいじっていただくと分かると思います。
  2. それにプラスで、語義A、語義B、語義C...と続くと、まあ異体字の欄がぐっちゃぐちゃで、大変見づらいです。「あ(語義3), い(同字), う(古字)、え(語義1)...」という風に書けばいいじゃないかと言われるかもしれません(実際にそう書かれている項目もあります)が、個人的には、集約できるものは一か所に集約したいものです。
  3. 一方、項目の主軸をラテン文字に置き、古字や俗字などの概念が今はない、チュノムや古壮字ではまあ実用的であると感じます。ただしどちらにしても同音異義というケースが多発するので、一列に並列させるのは厳しいかと思います(𠡚などのように音ごとに分けるのが現実的な範囲でしょうか)。
--Kuroco2k (トーク) 2025年10月11日 (土) 06:00 (UTC)[返信]
コメントありがとうございます。なるほど、1、2については私の意見と対立しますね。2に関しては括弧の無い字と後ろで纏めている字の区別がつきづらかったり、別字衝突などで一つの括弧に複数の情報を入れたりすると崩れるので、括弧内の内容を纏めないほうがよいと考えています(並べ方に気をつければ何とかなりそうではありますが)。チュノムと古壮字に関してはあまり詳しくないのですが、異体字の情報は和語の項目と同様にアルファベットの項目に集約できませんかね(からす】みたいに)。--TAKA647 (トーク) 2025年10月12日 (日) 07:53 (UTC)[返信]
提案 提案 反対意見が挙がらないため、一週間ほど後の日本時間10月3日0時までに追加の反対意見がなかった場合十分な時間を掛けたと見做し、{{kanji variants}}の積極的使用についての同意を得られたものとします。--TAKA647 (トーク) 2025年10月25日 (土) 02:10 (UTC)[返信]
終了 期日までに反対意見が上がらなかったため、議題が適用されます。以降は漢字項目の異体字欄に{{kanji variants}}を用いることとします。--TAKA647 (トーク) 2025年11月3日 (月) 02:56 (UTC)[返信]

繁体字について

[編集]

繁体字とは一般的に台湾の正体字を指していますが、大陸基準の辞書を引いていただければわかるように、大陸で定められた繁体字と台湾の正体字には若干の差異が認められます。例えば“為什麼”は大陸では“爲什麽”です。そのため日本語の旧字体のように「大陸繁体字(仮称)」のテンプレートとページを作成することが望ましいと思われますがいかがでしょうか。--Jiba1219 (トーク) 2025年10月9日 (木) 17:56 (UTC)[返信]

コメント それであれば「本末顛倒」のように「〇〇の別表記」のような形でも良さそうですがいかがでしょうか? --M-30722 (トーク) 2025年10月14日 (火) 10:18 (UTC)[返信]
できれば熟語にはなくとも単漢字のページだけでもそうした記述があるべきだと考えます。日常ではまず使われないですが確かに存在はする概念ですので。--Jiba1219 (トーク) 2025年10月14日 (火) 11:15 (UTC)[返信]

カテゴリ:中国語 国際音声記号あり 系統について

[編集]

現状、中国語系の「国際音声記号あり」カテゴリはその記事全体としてのソートキー(記事名、日本語のソートキー、北京官話のソートキー)で並べられていると思いますが、ソートキーを他の中国語系カテゴリと統一したいです。そのためには{{IPA}}にソートキーを指定する仕様を加える必要がありますが、いかがでしょうか。--~2025-27136-46 (会話) 2025年10月10日 (金) 08:59 (UTC)[返信]

対処 以前中国語の同音異義カテゴリ用に作ったソートキー自動生成機能を転用して引数から自動でソートキーを付与する機能を実装しました。従って、ソートキーを手動で指定する必要なくピンインでソートされるようになったと思います。 --M-30722 (トーク) 2025年10月14日 (火) 10:13 (UTC)[返信]
すみません。分かりにくかったかもしれませんが、これは中国語の下位方言(広東語、客家語、閩南語etc.)を含めて書いたつもりでした。広東語はイェール式変換機能をそのまま用いれるので簡単に実装できますが、他の方言については難しいでしょうか?--~2025-27136-46 (会話) 2025年10月14日 (火) 10:28 (UTC)[返信]
{{cmn-pron}}の四川語ブロックのスクリプトエラーが消えたので、これで英語版・中国語版に発音関係モジュールの存在する方言に就て発音テンプレートの整備及びソートキーの実装が(古語を除き)全て完了となります。それに伴い、あとは客家語・閩南語・閩北語・呉語のソートキーを実装できれば表題は達成されます。--~2025-27136-46 (会話) 2025年11月6日 (木) 13:14 (UTC)[返信]
引数2が入力されている場合に動作していない可能性があるのでご確認願いたいです。--Jiba1219 (トーク) 2025年10月15日 (水) 07:52 (UTC)[返信]
引数2を使用した際にソートキーが上書きされていたようなので修正しました。なお、引数2使用時もソートキーは引数1のものになります。
方言のソートキーにつきましてはモジュールを上手く編集出来れば自動出力出来るようになります(但し標準中国語のシステム作りの際にはかなり苦労しましたので出来る確証はありません)。手動での入力で良ければ「sort={{{sort|}}}」のように書けば手動での指定機能は作れると思います。 --M-30722 (トーク) 2025年10月16日 (木) 13:43 (UTC)[返信]

漢字項目における日本語カテゴリのソートキーについて

[編集]

Wiktionary:編集室/2025年Q2#「カテゴリ:漢字」のソートキーのルールでは「カテゴリ:漢字」のソートキーについて決めましたが、日本語関連のカテゴリ(具体的には「カテゴリ:日本語」や常用漢字、教育漢字関連のカテゴリ)のソートキーについても具体的に詰めていきたく思います。日本語のカテゴリとしては「日本語の音読みがあれば音読みをソートキーとして用いる。」と提案させていただきましたが音読みにも呉音、漢音等種類がありますのでどれを優先的に指定すべきかを決めたく思います。私としては呉音(最も古い時期に伝わった発音)か漢音(呉音には音のあいまいさがあるそうなので)が適当かと思いますがいかがでしょうか? --M-30722 (トーク) 2025年10月23日 (木) 14:04 (UTC)[返信]

あまりないとは思いますが、最初から常用漢字のみが対象のカテゴリなら常用漢字表の掲載順が好ましいでしょう。
表外字も入ってくるなら音読みに統一するのがスッキリすると思います。
ですが呉音、漢音どらかに統一するのは実用性に欠けると思います。
呉音:円(オン)
漢音:手(シュウ)
なんて全然聞いたこともないので探し出せませんし、時に呉音でも漢音でもない慣用音が最も一般的な字もあります。
熟語などを調べれば、大抵の字では最も優勢な読みは一つに決まると思いますのでそれを採用、決めがたい時は漢音を採用、でいかがでしょうか。--Nazratt (トーク) 2025年10月27日 (月) 13:37 (UTC)[返信]
それでは、常用漢字に関しては常用漢字表に掲載されている読みを優先することとしたいと思いますが、例えばのように掲載されているものが訓読みで、音読みは常用漢字表外の場合は訓読み「かい」と音読み「ハイ」「バイ」どれを優先することとしましょうか?--M-30722 (トーク) 2025年10月31日 (金) 13:20 (UTC)[返信]
Category:常用漢字Category:教育漢字 第1学年なら絶対に常用漢字しか入らないので常用漢字表の掲載順で並べる、つまり「」は訓読みの「かい」でソートし、表外字も入ってくるカテゴリなら常用漢字表は無視して音読みに統一しようということです。音読みの中では最も一般的な読み方を優先します。「貝貨」などの熟語からして「貝」の音読みの代表は明らかに「バイ」でしょう。
つまりはカテゴリごとにソートキーを変えるという意見です。--Nazratt (トーク) 2025年10月31日 (金) 14:34 (UTC)[返信]
カテゴリごとに異なるソートですか… それはややこしいですね。ソートミスを減らす為にルールをなるべくシンプルにしたいところですが、カテゴリごとに別々のルールで運用するとなると、手打ちでのソートは危ない(ソートミスを誘発する)ので常用漢字や教育漢字のカテゴリについては{{ja-kanji}}で自動ソートするシステムにするのが現実的でしょうか。--M-30722 (トーク) 2025年10月31日 (金) 14:48 (UTC)[返信]
@Nazratt 常用漢字と教育漢字のカテゴリは{{ja-kanji}}で付けられておりますのでもしカテゴリごとにソートを分けるのならモジュール:jawiktを編集して{{ja-kanji}}の引数「常用」から自動ソートする仕様にする必要がありそうですが、出来ますでしょうか?もしそれが出来ればカテゴリ別にソートキーを分けることは可能かと思います。なお、先ほど私がモジュールの編集を試みてみましたが上手くいきませんでした。もし仕様変更出来ない場合は「カテゴリ:日本語」と常用漢字や教育漢字のカテゴリでソートのルールを統一する必要があるかと思われます。 --M-30722 (トーク) 2025年11月1日 (土) 09:24 (UTC)[返信]
モジュールを編集して自動ソートは私には難しいですね、できる人がいればいいのですが
自動ソートだと常用=の引数を並べ替えて希望の読みを先頭に持ってくればいいでしょうか
ソートのルールを統一するとすれば一律音読みでいいでしょう--Nazratt (トーク) 2025年11月10日 (月) 14:43 (UTC)[返信]
それでは、音読みでソートすることにしようと思いますが、優勢な読みはかなり主観的なもので編集者によりソートが異なる場合も出てくることが予想されますが、その点は大丈夫でしょうか?それで良ければ「音読みがあるものについては音読みでソートすることとし、複数の読みがある場合は最も一般的と思われる読みが望ましい」としたいと思いますがいかがでしょうか? --M-30722 (トーク) 2025年11月11日 (火) 16:55 (UTC)[返信]
私の意見はそれでいいです。大抵の漢字では1通りに決まると思いますので。漢検漢字辞典は表外字について最も一般的な音読みの順に配列するという方針を取っているので参考になるかと思います。--Nazratt (トーク) 2025年11月16日 (日) 04:44 (UTC)[返信]
終了 それでは、他に意見も無さそうなので音読みがあるものは最も一般的な音読みでソートすることとします。Wiktionary:カテゴリの付け方#漢字に反映しましたのでご確認下さい。 --M-30722 (トーク) 2025年11月16日 (日) 05:22 (UTC)[返信]

広東語の発音について

[編集]

テンプレート:yue-pronにおいて単に粤拼を入力した場合、発音が広州語 - 香港語のものであるとと表示されるのですが、香港において使用されない簡体字の単語のページでこのテンプレートは使用をやめるべきでしょうか?--Jiba1219 (トーク) 2025年10月30日 (木) 19:09 (UTC)[返信]

{{cmn-pron}}の「z=n」のように簡体字表記の際に用いられない要素を出力しない仕様にすると問題無いと思います。 --M-30722 (トーク) 2025年10月31日 (金) 13:15 (UTC)[返信]
「h=n」で「広州語」のみ表示する仕様にしました。--~2025-27136-46 (会話) 2025年10月31日 (金) 15:00 (UTC)[返信]
対応有難うございます。 --M-30722 (トーク) 2025年10月31日 (金) 15:13 (UTC)[返信]

テンプレート:character infoの使用について

[編集]

単漢字項目での{{character info}}の積極的使用を提言します。現在暫定的に非推奨とされているこのテンプレートですが、これを単漢字項目において標準のものとしたいです。なお、モバイル表示で崩れないのは確認済みです。

想定する利用方法は、コード等節(==={{コード}}===)の直後の行に引数なしで配置します。見出しの漢字に互換文字が存在する場合、改行して追加します。この時の引数は互換文字の文字実体参照です。

今回の提言に至った理由は二点あります。第一に、現状の単漢字項目には互換文字を表示する仕組みがないためです。異体字欄に置こうにも、字形が同一のものや文字化けしてしまうものが多々あり、十分に列挙することができません。それに対し{{character info}}を用いれば、各互換文字をコードポイントとともに並べることができます。第二に、前後のコードポイントの文字へのリンクがある点です。これによって前後の文字に移動したり、項目の作成状況を確認することができます。これは地味ですが、便利な機能であると感じます。

このテンプレートの欠点を挙げると、日本語版で使用されないwikipedhiaのList of XML and HTML character entity referencesへのリンクとwiktionaryのUnicode付録ページへのリンクがある点、Unicode Utilities: Character Propertiesへのリンクが{{文字コード}}と被る点ですが、これらはテンプレートを編集することで解決できると思われるため、あまり問題にはならないです。

以上より、私は単漢字項目での{{character info}}の標準搭載を提言します。また、単漢字項目のでの使用の合意を得たのち、一文字項目全体に範囲を拡張し再提言します。--TAKA647 (トーク) 2025年11月3日 (月) 03:40 (UTC)[返信]

コメント 互換文字の表示に関しまして、具体的な見本項目を何か示していただけますと分かりやすいと思いますので何か互換文字の表示が必要な項目を示していただけますでしょうか。また、現在確認出来ている不具合としてはUnicode CJK Unified Ideographs Extension HUnicode CJK Unified Ideographs Extension Jで「スクリプトに割り当てた時間が終了しました。」と表示されて表が出ない事象を確認しており、これ以外でも𱍊で同様の事象を確認しております。--M-30722 (トーク) 2025年11月3日 (月) 14:20 (UTC)[返信]
本人ではなく申し訳ありませんが。
--Kuroco2k (トーク) 2025年11月3日 (月) 14:44 (UTC)[返信]
リンクの掲示並びにモジュールの更新、誠にありがとうございます。--TAKA647 (トーク) 2025年11月4日 (火) 09:46 (UTC)[返信]
互換漢字の観点ですと、や、あたりですね。いずれも互換漢字が3つ結び付けられていますが、それぞれいくつかのの互換漢字が独自の字形を持っています。--TAKA647 (トーク) 2025年11月4日 (火) 09:45 (UTC)[返信]
私の環境で確認してみたところ、は全ての字形が表示出来ましたがでは下2つ、では一番下がそれぞれ表示出来ませんでした。他の人の環境ではどのようになっているでしょうか?--M-30722 (トーク) 2025年11月5日 (水) 14:35 (UTC)[返信]
フォントが対応していないのでしょう。私の環境でもSafariでは者と懲の下2つが表示されませんが、外部フォントを導入したChromeでは表示されます(U+2F97Aは仕様書通りではない)。CJK互換漢字補助に至っては表示するのはおそらく無理なので、字形は画像が頼りになります。あくまでコードポイントの表示がメインです。--TAKA647 (トーク) 2025年11月6日 (木) 01:52 (UTC)[返信]
このテンプレートに関しては全ての字形が表示される事を期待しておりましたのでそれは残念です。それでは互換文字を表示する仕組みが充分機能しているとは言えないのではないでしょうか?字形の表示機能が完全であればレイアウトが乱れるリスクを指摘されているテンプレートを使用する価値も無くはないかも知れませんが、そうでないならデメリットが大きいかと思います。また、他の点について見ると、各互換文字のUnicode番号は{{unicode code}}を使えば(任意のコード番号を指定出来るので)表示可能ですし、もしくは{{文字コード}}を編集し、互換文字のコード番号も併記出来るようにする手もあります。前後のコードポイントの文字へのリンクについてはまず閲覧者側にとってそれは需要のあるものなのか疑問です。編集者側にとっても各カテゴリのトークページ(カテゴリ・トーク:Unicode CJK Unified Ideographs/U+4E0X等)に一覧表が掲載されているのでそれを見ると前後どころか広範囲の作成状況を一気に確認することが出来、作成状況の確認はこれで事足りるかと思うのですが、この一覧表ではいけないのでしょうか?従って、現状では反対 反対です。また、字形の表示は漢字見出し、コード番号はコード等見出しにそれぞれ有るべきかと思います。--M-30722 (トーク) 2025年11月6日 (木) 15:40 (UTC)[返信]
実際、全ての字形をテキストとして完璧に表現するというのは究極的には不可能という結論になります。特にCJK互換漢字補助には典拠Tや典拠KP、典拠H、典拠Mといった日本のフォントで適切に表示するのが難しい文字が大半を占めます。ゆえに私は、字形を適切に表示するには画像を使う必要があると考えます。このテンプレートはWikidataのページにある字形画像を表示することができるので、それによって互換漢字の字形を示すことができます。
レイアウトが乱れるという意見は互換漢字が複数存在する項目の冒頭に配置した場合に日本語節や中国語節まで貫通してしまうおそれがあるという点であり、これはコード等節に配置することで防ぐことができます。前後のコードポイントへのリンクについてはおっしゃる通りですが、少なくとも減点要素にはならないと考えています。--TAKA647 (トーク) 2025年11月7日 (金) 15:00 (UTC)[返信]
字形を表示するテンプレートを漢字見出しではなくコード等見出しに配置するのには違和感があります。また、CJK統合漢字に関しては既存の記述と重複しており、同じ事を2度書いている状態になっており(字形は漢字見出しで、コードは文字コードの欄でそれぞれ記述済)完全に蛇足かと思います。その他に関しても文字コードの表内にUnicode番号を記すことで事足りる(それぞれの字形を確認したい場合は文字コードのリンクに飛ぶことで確認可能)のでわざわざ癖の強いテンプレートを導入する必要は無いはずです。--M-30722 (トーク) 2025年11月8日 (土) 16:17 (UTC)[返信]
まず、文字コードのリンク先でも字形はテキストとして示されており、どの環境でも十全に字形を確認するためにはUnicodeの仕様書を見るほかありません。確かにこのテンプレートは既存の記述と重複する要素もありますが、現状このテンプレートにしかない要素もあります。CJK統合漢字と互換文字それぞれの文字実体参照や字形画像、Unicode文字名は現状のフォーマットでは表示されません(既存のテンプレートを編集すれば別ですが)。また、字形で判断することが不可能な互換漢字もテキストとして表示されるため、単に文章として記述するよりも視覚的にわかりやすく、編集上のミスも防ぐことができます。個人的には、漢字節に配置する互換文字は広く取っても典拠Jが存在する文字のみにし、互換文字全体の列挙はコード等節で行うべきだと考えます。--TAKA647 (トーク) 2025年11月10日 (月) 04:25 (UTC)[返信]
結局{{character info}}でも全ての字形の確認が出来てないじゃないですか。字形画像は画像を直接貼れば表示可能です。Unicode文字名はブロック名のことでしょうか?{{文字コード}}を編集してブロック名は出るようにしました。文字の表示については漢字見出しにするのが好ましいと考えます。漢字とコードを分ける以上はきっちりと分けた方が良いですし、もし文字の表示とコード番号の表示を同じ場所でするのであればやはり漢字見出しとコード等見出しを統合すべきであったのではないでしょうか?--M-30722 (トーク) 2025年11月11日 (火) 17:26 (UTC)[返信]
Unicode文字名はでいう「HIRAGANA LETTER NA」のことです(なぜかCJK統合漢字は翻訳されていますが)。また、この提言の目的は統合漢字の字形表示を画像で行うことではなく、あくまで互換漢字を適切に区別して列挙すること及び上で挙げた通りです。互換漢字には字形が統合漢字と同一のものがあり、互換漢字の字形提示を漢字節で行うと項目冒頭の情報が嵩張ってしまいます。互換漢字の字形画像はWikidataに追加するほうが簡便ですし、現在画像添付の方針が存在しないためフォーマットが乱れる可能性があります。--TAKA647 (トーク) 2025年11月13日 (木) 05:15 (UTC)[返信]
私の意見としては今のところ以上の内容ですので他の方の意見も踏まえて議論の結論が出ればと思います。
@RoKouKok {{character info}}を使われておりますが、まだ合意された訳でないのでここで議論して頂きたいのですが、RoKouKokはこのテンプレートを導入すべきと考えられておりますでしょうか? --M-30722 (トーク) 2025年11月13日 (木) 15:55 (UTC)[返信]
すみません。他の漢字ページからコピーしてページを作成してしまっているので、合意された訳ではないということが頭から抜けていました。私としましては、このテンプレートは導入して問題ないと考えております。--RoKouKok (トーク) 2025年11月13日 (木) 16:01 (UTC)[返信]
RoKouKokさん、ありがとうございます。この件に関しては特に漢字項目をよく作成されている@Kuroco2kさんやWiktionary:編集室/2024年Q3#レイアウト破壊にてこのテンプレートに対して反対表明をされていた@Charidriさんの意見を改めて聞きたいと思いますが、いかがでしょうか?--M-30722 (トーク) 2025年11月13日 (木) 16:40 (UTC)[返信]
正直自分としては「あってもなくてもどっちでも良い」とは思っていますが…。
単に複数のコードポイントが統合されていることを示すなら{{文字コード}}の編集で引数を追加すれば事足りますが、標準の形と差異がある場合は、まあ字形は表示できた方が良いと思っています。異体字セレクタとかを用いて表示する方法もあるでしょうが、最も環境依存しないのは画像ですから、そこを考慮したら{{character info}}に任せたい節があります。--Kuroco2k (トーク) 2025年11月14日 (金) 01:46 (UTC)[返信]
コードに対応した字形の表示が必要であるのであれば、{{文字コード}}の表のUnicode番号の横に字形を表示するようにすれば済むのではと思うのですが、いかがでしょうか? --M-30722 (トーク) 2025年11月14日 (金) 10:17 (UTC)[返信]
その字形の表示というのは今入力して、表示されているような文字の形式でということですか?それとも画像にて行うものでしょうか?--Kuroco2k (トーク) 2025年11月14日 (金) 10:36 (UTC)[返信]
やるのであれば画像ですね、文字の形式のものはリンク先からでも確認可能なので画像の方が価値があると思います。導入出来るかどうか試みてみます。--M-30722 (トーク) 2025年11月14日 (金) 14:06 (UTC)[返信]
{{character info}}を使っている項目を幾つか見てみましたが、意外と画像データが貼られているものは少数派のようです。@TAKA647さんが求められている字形の表示は今入力して表示される文字の形式なのか、画像なのかどちらでしょうか?--M-30722 (トーク) 2025年11月14日 (金) 14:24 (UTC)[返信]
画像ですね。テキストですと環境によって文字化けしたり不適切な字形になったりしてしまうため、字形を示すにはやはり画像が最適だと思います。画像が紐づけられていないWikidata項目のうち、統合漢字項目はひとまず無いままで良いと考えています。互換漢字項目のうち統合漢字と同じ字形のものは後回しでもいいですが、異なる字系のものは早急の紐付けが必要でしょう。--TAKA647 (トーク) 2025年11月14日 (金) 17:10 (UTC)[返信]
{{文字コード}}を編集して複数のUnicode番号に対応し、画像が有る場合は画像を出力するようにしてみました。見本として「」を編集してみました(比較の為に{{ character info}}をあえて残しています)がいかがでしょうか?--M-30722 (トーク) 2025年11月14日 (金) 18:11 (UTC)[返信]
これはすごいですね。互換漢字の字形と符合位置を表示する役割は十分に果たせていると思います。欲を言えばテキストとしての互換文字も欲しいです。私としてはUnicode文字名と文字参照、隣の符号へのリンクにも価値があると思っていますので、変わらず{{character info}}の積極的使用を主張させていただきます。
一点勘違いをしておりましたが、{{character info}}にて表示される画像はWikidataに紐づけられたものではなく「ファイル:U(符合位置).svg」という名前の画像なのですね(つまりGliphWikiから移入した画像)。--TAKA647 (トーク) 2025年11月16日 (日) 03:32 (UTC)[返信]
テキストの表示は可能です。例えば画像データが有る場合は画像、無い場合はテキストの形で出力というのはどうでしょうか?Unicode文字名は「モジュール:Unicode data」に収録されているので{{文字コード}}への紐付けを試みてみましたがどうも上手くいきません。ただ、漢字の場合は「(ブロック名)-(Unicode番号)」の形式になっていそうなのでブロック名を使った形での出力で良ければ可能です。「文字参照」は「&#(10進数の数字);」の形のものでよろしいでしょうか?16進数を10進数に変換する形で出力して記述するだけで良ければこれも{{文字コード}}の編集で対応可能です。隣接する符号へのリンクはカテゴリのトークページにある一覧表では不十分でしょうか? --M-30722 (トーク) 2025年11月16日 (日) 06:34 (UTC)[返信]
私の考えとしましては、{{character info}}は表が乱立してレイアウトが汚くなりがちなので{{文字コード}}一つにまとめられるのであればそこにまとめてしまってすっきりした形に出来ればと思います。 --M-30722 (トーク) 2025年11月16日 (日) 17:29 (UTC)[返信]
文字参照についてはおっしゃる通り10進法の形が望ましいです。隣の符合位置へのリンクについては確かにカテゴリのノートページでも同様の機能は果たせますが、そこへの移動が少し手間であると感じます。項目の作成状況や文字の確認、移動の利便性を考慮し隣の符合位置へのリンクは存在する方が良いと考えます(というより私が欲しいです)。
私は逆に{{文字コード}}の内容が長大になってしまうよりは{{character info}}を用いて右側のボックスにまとめてしまった方がスッキリした印象を受けます。{{点字}}も現状のフォーマットには無いためレイアウトはあまり汚くならないと考えます。ただ、このような話は個人の好みに依るため、最終的に多数に受け入れられるフォーマットに決まることが望ましいです。--TAKA647 (トーク) 2025年11月17日 (月) 05:16 (UTC)[返信]
個人的に各符号のリンクページへの移動を容易にしたいのであれば自分の利用者ページに各カテゴリのノートページを貼る事も出来ます。例えば、私は特別ページに行きやすくしたいので自分の利用者ページに特別ページへのリンクを貼り付けています。他の編集者や閲覧者の視点等を考慮した際に隣の符合位置へのリンクの需要がどれ程あるのかは疑問な所があります(もちろん高い需要が有るのであれば設ける価値はあるかも知れません)。ある程度議論が進みましたので{{character info}}を使うのが良いか、{{文字コード}}に情報を集約するのが良いかについて多数決を取りたいと思いますが、その形でよろしいでしょうか?--M-30722 (トーク) 2025年11月17日 (月) 10:06 (UTC)[返信]
現状、漢字項目の赤リンクは異体字節かUnicodeノートページ、索引ページくらいにしかなく、言ってしまえば見に行かなければ見れない状態です。隣の符合位置へのリンクの存在によって新規漢字項目の立項を後押しできるほか、項目の孤立度も減らすことができます。
お互い議論も拮抗してきましたし、多数決をとりましょうか。--TAKA647 (トーク) 2025年11月17日 (月) 15:18 (UTC)[返信]
それでは「単漢字項目に{{character info}}を標準搭載する」ことについて多数決をとります。反対多数の場合は「{{文字コード}}に機能を集約させる」という方向で議論を進めます。
期日は2週間後の日本時間12月2日00:00とします。--TAKA647 (トーク) 2025年11月17日 (月) 15:19 (UTC)[返信]
反対 反対 文字コードに集約を支持します。なお、前後のコードの文字についても需要があるのであれば文字コードの表内に表示することも可能です。--M-30722 (トーク) 2025年11月17日 (月) 16:13 (UTC)[返信]
この提案は漢字項目のフォーマットを大きく変えるものであるため広く意見を募りたいと考えております。つきましては、漢字項目の編集を多く行なっている@Kuroco2kさん、@RoKouKokさん、@㌧ネルさんへ僭越ながらメンションさせていただきます。コメントのほど、お待ちしています。--TAKA647 (トーク) 2025年11月25日 (火) 04:31 (UTC)[返信]
反対 反対 {{文字コード}}に集約させることができるのであれば、わざわざ{{character info}}を搭載する必要がないので、その方がよいと思います。--RoKouKok (トーク) 2025年11月25日 (火) 04:38 (UTC)[返信]
後から異議を出されないためにも、なるべく多くの方に議論に参加していただきたいと考えます。よって、@असत्यमेव जयतेさん、@がんばるぞさん、@ダイタクヘリオスさんに追加のメンションをさせていただきます。コメントのほど、お待ちしております。--TAKA647 (トーク) 2025年11月29日 (土) 02:05 (UTC)[返信]
(コメント)詳しいことはよくわかりませんが、統一できるのであれば統一した方がよいのではと思う。--がんばるぞ (トーク) 2025年11月29日 (土) 03:52 (UTC)[返信]
反対 反対 無暗に枠を増やすよりはまとめたほうがいいと思う。--㌧ネル (トーク) 2025年12月1日 (月) 06:34 (UTC)[返信]
賛成 賛成 提案者票--TAKA647 (トーク) 2025年11月29日 (土) 01:53 (UTC)[返信]
反対 反対 文字参照を{{文字コード}}に追加するのであれば集約を支持します。前後位置へのリンクも(強くは主張しませんが)あると良いと思っております。--ふゆくれ (トーク) 2025年11月29日 (土) 03:30 (UTC)[返信]
終了 投票の結果、反対多数のため否決となります。今後は{{character info}}は用いないこととします。--TAKA647 (トーク) 2025年12月2日 (火) 03:14 (UTC)[返信]
対処 {{文字コード}}に文字名、文字参照、隣のコードへのリンクを追加して集約を行いました。また、{{character info}}は記号(等)やハングル文字(等)にも使われているようですが、漢字以外への使用についてはどうしましょうか? --M-30722 (トーク) 2025年12月2日 (火) 11:08 (UTC)[返信]
同じ一文字項目でありながら漢字項目だけは使わないというのも不統一なので、全面的な廃止もありだと考えます。その場合、字形画像と字形名、前後の符号位置へのリンクがなくなるため、需要が確認でき次第導入方法を考える必要があります。--TAKA647 (トーク) 2025年12月4日 (木) 03:54 (UTC)[返信]
{{文字コード}}を漢字項目以外にも使用すれば」と思いましたが、現状だと例えば「ナブラ)」では{{文字コード}}で表示される文字名が「Unicode Mathematical Operators-2207」で{{character info}}で表示される文字名が「NABLA」と食い違っているので、少し考え物ですね。--ふゆくれ (トーク) 2025年12月4日 (木) 07:43 (UTC)[返信]
テストを兼ねて¿をいじってみました。文字名の部分が本来「INVERTED QUESTION MARK」とあるべきところ、「Unicode Latin-1 Supplement-BF」となっている点を除けば殊更の問題はないかと思いますが、いかがでしょう。--Kuroco2k (トーク) 2025年12月4日 (木) 08:06 (UTC)[返信]
{{文字コード}}内で{{character info}}の処理を再現しました。これで文字名表示が同一になっているはずです。--ふゆくれ (トーク) 2025年12月4日 (木) 09:52 (UTC)[返信]
ありがとうございます。文字名に関しては上手くいかず苦労していたので大変助かります。--M-30722 (トーク) 2025年12月4日 (木) 13:58 (UTC)[返信]

朝鮮語の動詞における見出しについて

[編集]

カテゴリ・トーク:朝鮮語 動詞にて、現在は「自動詞」および「他動詞」が見出しに用いられていますが、他の言語に合わせて、朝鮮語においても見出しを「動詞」とすることを提案していますので、念の為、こちらでお知らせしておきます。ご意見のある方は、当該トークページにコメントをお願いいたします。--20041027 tatsu (トーク) 2025年11月23日 (日) 17:13 (UTC)[返信]

終了 上記議論にて今後は見出しを「動詞」とすることで合意がなされました。 --M-30722 (トーク) 2025年12月7日 (日) 10:23 (UTC)[返信]

旧字体のページについて

[編集]

旧字体の読み仮名の書き方についてですが、例えば「瘴氣」の旧字体項目では現代仮名遣いの「しょうき」か、あるいは旧仮名遣いの「しやうき」のどちらを表記することが望ましいでしょうか?--Jiba1219 (トーク) 2025年12月16日 (火) 05:56 (UTC)[返信]

確かに、Wiktionary:編集室/2025年Q2#日本語における旧字体表記では漢字仮名混じりのケースにおいて「かな混じりであれば歴史的仮名遣いを用いる」としましたがそれに従うと読みの部分も旧仮名遣いにした方が整合性が取れるのかも知れません。なので旧字体表記の読み仮名部分には旧仮名遣いを使った方が良いかなと個人的には思いますが、これについて他の方のご意見も伺いたいです。 --M-30722 (トーク) 2025年12月21日 (日) 08:10 (UTC)[返信]
特に意見が無さそうなので、旧字体表記の読みは旧仮名遣いとしたいと思いますが、異議等はございませんでしょうか?--M-30722 (トーク) 2026年1月4日 (日) 16:32 (UTC)[返信]
読みはそれで問題ないですが、ソート順で見た時に旧字体表記と新字体表記が並んでいないのは変に感じます。--Praqimu (トーク) 2026年1月5日 (月) 09:30 (UTC)[返信]
ソートキーと読みで別のものを指定する運用となるとより複雑になり、編集者間のルール共有が難しい印象を持ちますが、皆さんのソートキーについての考えを伺いたく思います。--M-30722 (トーク) 2026年1月6日 (火) 16:07 (UTC)[返信]
他のみなさんもご意見をどうぞよろしくお願いいたします。--Praqimu (トーク) 2026年1月6日 (火) 16:15 (UTC)[返信]

文字情報見出しについて

[編集]

漢字に関しては以前の議論で「文字情報」見出しを「コード等」に変更することで合意しましたが、かな文字や絵文字、数学記号など漢字以外のものについても「コード等」に変更することを提案します。理由としては、これらの文字や記号についても文字情報見出し以外に書かれていることも文字に関する情報なので例えば「𛁇」の変体仮名見出しに書かれた情報な文字情報ではないのか?といった疑問を抱き得る名称であると感じますし、また、漢字項目と名称を統一した方が一貫性もあるかと思います。 --M-30722 (トーク) 2026年1月9日 (金) 15:21 (UTC)[返信]

@ふゆくれ 等の編集を見るに、ふゆくれさんは記号に関しては「文字情報」見出しを「コード等」に変更することに反対 反対の立場でしょうか? --M-30722 (トーク) 2026年2月1日 (日) 07:32 (UTC)[返信]
結論が確定していない事項なので暫定で既存項目通り「文字情報」見出しを採用しています。私自身はどちらでも良い派なので、この議論の結論が出たらそれに従います。--ふゆくれ (トーク) 2026年2月1日 (日) 07:54 (UTC)[返信]
特に異議が出なければ漢字項目同様の形で統一したいと思いますが、そもそも「記号」に対して「文字」情報と呼ぶのが適切なのかが疑問なところですが、「記号」も「文字」と言って差し支えないでしょうか?--M-30722 (トーク) 2026年2月1日 (日) 08:05 (UTC)[返信]
記号(意味・機能を表す)⊂文字(意味・発音・語・機能などを表す)というイメージなので個人的には言って差し支えないと思います。--ふゆくれ (トーク) 2026年2月1日 (日) 08:19 (UTC)[返信]
分かりました。それでは、漢字以外の項目についても見出しを「文字情報」→「コード等」に変更することの賛否を1週間程度投票したいと思います。--M-30722 (トーク) 2026年2月1日 (日) 08:37 (UTC)[返信]
賛成 賛成 --M-30722 (トーク) 2026年2月1日 (日) 08:38 (UTC)[返信]

終了 それでは、異議無しにつき漢字以外の項目についても「文字情報」見出しを「コード等」に変更することとします。以後は「コード等」で統一したいと思います。 --M-30722 (トーク) 2026年2月9日 (月) 11:58 (UTC)[返信]

「八」の字源テンプレートについて

[編集]

ご覧いただければ分かる通り、「」の字源テンプレートに問題があるようです。当方では解決できないため、どなたか修正をお願いいたします。--Jpnbcl (トーク) 2026年1月11日 (日) 05:50 (UTC)[返信]

Wikipediaへの移行について

[編集]

先ほど別の仮アカウントユーザーが編集された特別:差分/2181862について、明らかにWikipediaマターだと思われます。私自身は異なるサービス間で移動処理をした経験がないのですが、どなたか代行していただけませんか?--~2026-67957-3 (会話) 2026年1月31日 (土) 14:46 (UTC)[返信]

沖縄弁をできる人があるですか?

[編集]

こんにちは、私は外国人です。<海東諸国記>を読んでいたのですが、琉球語をハングルで書き写した部分がありました。理解するのに助けが必要です。

その一:「우라ᄌᆞ마피츄」 (君はどこからの人?)/u.ra.tsɒ.ma.pʰi.tsʰʲu/

우라: うら (君)/u.ra/

ᄌᆞ:???/tsɒ/

마: まー (どこ)/ma/

피츄: 人 (ひと)/pʰi.tsʰʲu/

「ᄌᆞ/tsɒ/」の意味はなんですか?私は「では」の意味と思います。--Blahhmosh (トーク) 2026年2月7日 (土) 05:05 (UTC)[返信]

その二:「우라리아리」 (妹があるか?)/u.ra.ri.a.ri/
우라:うら(君)/u.ra/
리:???/ri/
아리:あり(ある)/ri/
明らかに,「리/ri/」は「妹」の意味ですが、辞書 (https://www.jlect.com/) には載っていません。
別の解釈としては:
우라리:(妹)/u.ra.ri/
아리:あり(ある)/ri/
でも、辞書 (https://www.jlect.com/) に載っていません。--Blahhmosh (トーク) 2026年2月7日 (土) 05:16 (UTC)[返信]

一部の項目で語義説明の末尾に「漢字源」と記述されている

[編集]

語義説明の末尾に「漢字源」と書いてあります。ひょっとして著作権侵害だったりしないでしょうか?確認できる方はいますか?--Naggy Nagumo (トーク) 2026年2月8日 (日) 11:19 (UTC)[返信]

確認してきました。結論、 (ほぼ) そのままです[1]。たいへん→大変になっている程度です。安全側に倒すなら削除に移すべきでしょう。--雛宮黒狐Talk2026年2月13日 (金) 06:51 (UTC)[返信]
辞書項目の説明は短い文のことが多いので、少数の例が一致したからといって即著作権侵害とはみなされない可能性もありますが、この書き方だと明らかにコンテンツを剽窃したと表明しているようなものです。許容されないような気がします。同じユーザーによるほかの編集についても、どうなんでしょう。疑いの目で見ざるを得ません。--Naggy Nagumo (トーク) 2026年2月15日 (日) 11:25 (UTC)[返信]

脚注

  1. 藤堂明保; 松本昭; 竹田晃; 加納吉光 (2004). 漢字源 改訂新版 (5 ed.). p. 479. →ISBN.

アルファベットのソート規則を言語ごと個別に定めませんか?

[編集]

Wiktionary:カテゴリの付け方」によれば、アルファベット項目について、なぜか「ダイアクリティカルマークを除いた基本字母順で並べる」ことになっています。確かに英語・ドイツ語・フランス語などでは、一般的な辞書でもそうなっています。でもほかの多くの言語はそうではなく、ダイアクリティカルマーク付きの字は独立した字として扱っていているものが多いです。例えばスウェーデン語ではa-zの後にåäöを並べます。チェコ語・トルコ語・ハンガリー語なんかも同様に、英語的な並べ方ではないらしい。ウィクショナリーにおけるソート規則がどうやって決まったのか経緯を知りませんが、正直今の規則はあり得ないと思います。言語ごとに最も自然なソート規則で並べるように変更しませんか?--Naggy Nagumo (トーク) 2026年2月15日 (日) 11:21 (UTC)[返信]

コメント やるとするならば、手動で言語ごとにルールを分けてソートするのはあまりにも複雑になって編集者が対応し切れないので自動でそれぞれの言語のルールに合わせたソートがされるような仕様にする必要があると思います。例えば漢字項目が言語ごとに異なるルールでソートされておりますが、{{kana-DEFAULTSORT}}で日本語、{{ko-head}}で朝鮮語、{{vi-head}}でベトナム語のソートが自動で割り当てられる仕様となっており、一つ一つのルールを覚える必要がありません(中国語もそうしたいですが、(標準中国語に関してはやろうと思えばすぐ出来るものの)各方言毎のソートキー自動付与のシステムがまだ整っておりません)。 --M-30722 (トーク) 2026年2月15日 (日) 12:24 (UTC)[返信]
はい。M-30722さんのおっしゃる通り、ひとつひとつのソート規則はそこまで複雑ではありませんが、言語ごとに様々なバリエーションがあり、手入力はつらいと思っています。なので今デフォルトソートでテキトーに並べられているものはすぐに直すつもりはなく、テンプレートでソートキーを自動生成する運用にしたいと考えています。それは追い追いやるとして、まずはコミュニティとして言語ごとにソート規則を分けるかどうか、という是非を問いたいです。--Naggy Nagumo (トーク) 2026年2月15日 (日) 12:40 (UTC)[返信]
各言語の辞書に沿った並べ方が出来るのならそれが理想と思いますので自動ソート可能であれば賛成 賛成です。但し手動対応しか出来ない場合は編集者によってソートがバラバラになり、かえって統一感が失われるリスクが高い為現状のルールがベターかも知れません。--M-30722 (トーク) 2026年2月15日 (日) 14:46 (UTC)[返信]

やろうとしていることは、「Wiktionary:カテゴリの付け方」のうち「ソートキー」節の書き換えです。詳細に説明します。

  1. 「アルファベット表記の項目」節を削除します。言語個別のソート規則と競合する記述を削除して、混乱を避ける狙いです。基本字母のデフォルトソートを即座に非推奨化するものではありません。
  2. 「日本語」・「中国語」などの言語ごとの節を削除し、代わりに個別言語ごとにソート規則をまとめたページを作成します(「Wiktionary:カテゴリの付け方/日本語のソートキー」など)。
  3. テンプレートを通してカテゴライズする場合に、ソートキーが自動生成されることがある旨を記述します。ソートキー自動生成機能を持つテンプレートを例示します。

前提として、将来的にすべてのカテゴリについてテンプレートを通して付与、ソートキーを自動生成することを目指しています。まだその対応は完全ではありませんが、先に足枷となる規則を削除したいという思いです。2026/3/22までに反対意見がなければ合意と見なし、記述を変更します。 --Naggy Nagumo (トーク) 2026年3月8日 (日) 08:52 (UTC)[返信]

以前削除された項目について

[編集]

「東大」は2019年に編集方針を満たしていないとして削除されましたが、「掲載可能な項目」の4の2を満たしており、細則の「人名・団体名及び芸術作品名の扱い」の基本方針も満たしていると思います。また、英語版・中国語版・ロシア語版・マレーシア語版にも項目が存在し、大辞林や日本国語大辞典にも記載があるため、改めて項目を作成したいのですがどうでしょうか。--ねこ8 (トーク) 2026年2月18日 (水) 07:38 (UTC)[返信]

この方針は2019年当時から変わっていないので、当時の削除判断が誤りでなければ、今投稿しても削除されると思います。「Wiktionary:編集方針」の解釈が難しく、掲載可能かどうかわかりません。「掲載可能な項目」節の例外に当てはまりそうなのでOKに見えますが、ただし、上記に該当していても、#細則の規定に沿わない場合は削除されることがあります。とも書かれています。さらに細則のほうには一切の掲載を認めない。と書かれています。結局どちらが優先なのかわかりません。もし当時の削除判断が誤りである場合、新規で作成するよりも、削除されたページの復活が妥当だと思います。--Naggy Nagumo (トーク) 2026年2月18日 (水) 10:43 (UTC)[返信]
「細則の規定に沿わない場合は削除されることがあります」とのことなので掲載可能な項目の要件と細則の規定の両方を満たす必要があります。この文面は少々分かりにくいので両方満たす必要がある旨を分かりやすく伝えられるよう文面を改善する必要があるかも知れません。細則の規定については何か満たしていそうなものはありますでしょうか?--M-30722 (トーク) 2026年2月18日 (水) 14:01 (UTC)[返信]
規定を満たしていそうな細則は見つけられず、また作成しても削除されそうなので作成は控えようと思います。--ねこ8 (トーク) 2026年2月22日 (日) 06:06 (UTC)[返信]

スクリプトエラーはできるだけ避けて、発生してもすぐに解消させてください

[編集]

カテゴリ:スクリプトエラーがあるページは常にカテゴリメンバーがゼロになるよう心掛けてください。モジュールを編集する方は、自分が編集した後しばらくは このカテゴリを監視してください。原則、互換性を保ってください。もしスクリプトエラーを避けられないことが事前にわかっている場合は、計画を立てて全体にアナウンスしてから編集するようにしてください。--Naggy Nagumo (トーク) 2026年2月18日 (水) 11:26 (UTC)[返信]

今回のエラーはいつ直りますか?エラーになっていないものでも動作が変わってしまっているものが多数あるようです。どういう方針で進めていますか? --Naggy Nagumo (トーク) 2026年2月21日 (土) 07:32 (UTC)[返信]
@Kuroco2k, @M-30722, @Praqimu, @20041027 tatsu 状況を知っていたら教えてください。どうやって直そうとしていますか?直る見込みはありますか? --Naggy Nagumo (トーク) 2026年2月21日 (土) 07:58 (UTC)[返信]
モジュールに関する知識がないため、私は基本モジュールの編集をしていませんが、10万を超える項目でエラーが発生していたため、一部のモジュールは以前の版に差し戻しました。現在も残っているドイツ語やスウェーデン語の項目におけるエラーは、手動で設定されているデフォルトソートを削除すれば解消されるようです。また、フィンランド語の格変化のテンプレートに伴うエラーは英語版に合わせると直りました。--20041027 tatsu (トーク) 2026年2月21日 (土) 08:55 (UTC)[返信]
今回の大規模なモジュールの改変に関わっていない為詳しい事は分かりかねますが、現在確認している事象として{{kana-DEFAULTSORT}}{{vi-DEFAULTSORT}}といったデフォルトソート関連のものが正常に働いておらず、並びがおかしくなっております。今回大量のモジュールが編集されている為、これらの不具合を直す方針や見込みは編集者である@Praqimuさんにしか分からないかと思われます。--M-30722 (トーク) 2026年2月21日 (土) 13:45 (UTC)[返信]
(追記)新たに分かったこととして、[[カテゴリ:(言語名)_〇〇]]のように手動でカテゴリ付けがされているものはデフォルトソートを使用しても正常にソートされているようです。--M-30722 (トーク) 2026年2月21日 (土) 13:52 (UTC)[返信]
急に大規模改編が進められてエラーが多発していたため、応急措置としてひとまず無いモジュールを導入しているのみで、あまり大きいことはわかってないです。
モジュール:headword/dataを差し戻せばfågelskrämmors(と併せてこれも)などのエラーは治るようですが、それをすること自体がリスクを産む危険があるので、進んでやろうにやれない状態です。--雛宮黒狐Talk2026年2月22日 (日) 06:24 (UTC)[返信]
(メンション外失)モジュール:string utilitiesモジュール:funのように、編集前後で消えていた処理を復活させることで{{文字コード}}など一部のエラーは解消できました。しかし、大胆に変えられたものだと「処理を復活してもその前段階の処理が大きく変わっていて解消が困難である」ものが(パッと見た感じ)多くあります。また、モジュールの差し戻しに起因するエラーも発生しているようです({{syn-saurus}}を使用しているページ)。--ふゆくれ (トーク) 2026年2月22日 (日) 07:18 (UTC)[返信]
皆さんご意見ありがとうございます。事情を最もよく知っていると思われる方は現れないですが、このエラーを対処するための方針を決めたいです。これまでの編集傾向を考えると、Praqimuさん自身にこのエラーに対処する忍耐力がない可能性を考えています。20041027 tatsuさんやKuroco2kさんにより一定の効果がある修正を加えていただきましたが、根本解決には至っていません。
さて、モジュールを修正する方針ですが、私一人では決めかねています。私自身はモジュールの変更内容を把握していないためです。今の状態から直すとするなら、以下のどちらが良いと思いますか?
  1. ある時点までモジュール群を差し戻しする(おそらく最近の大改造を戻せば解決?)
  2. 現在の状態をベースに動くように修正する
①を選ぶ場合は私がやりましょう。②を選ぶ場合は、できる人がやってください(協力はしますが主導はしません)。 --Naggy Nagumo (トーク) 2026年2月22日 (日) 11:21 (UTC)[返信]
Praqimuさんが返事いただければ良いのですが、今回の編集範囲があまりにも広範囲で②はほぼ困難かと思いますので本人が対処を行わない限りは①しか安全な方法は無いかも知れません。なお、このような大量のエラー長期間に及び発生する編集は過去にもあり、要注意かと思われます。--M-30722 (トーク) 2026年2月22日 (日) 13:38 (UTC)[返信]
返信が遅くなって申し訳ございません。こちらの返信から失礼します。どのテンプレートか忘れてしまいましたが、あるものを編集した際に日本語版に存在しないモジュールを作成する必要が出てきたために、それに属するモジュールを最新のものに更新していった結果としてこのような事態となってしまいました。お手数をおかけして申し訳なく思います。Naggy Nagumoさんはこういった分野に明るいと存じ上げてありますので、ひとまず1.でお願いします。--Praqimu (トーク) 2026年2月23日 (月) 16:30 (UTC)[返信]
それでは、ある時点の状態に戻すということでコミュニティの合意があると見做しますので、時間がある時にモジュール群を差し戻しします。あまり深く考えずに差し戻しを行いますので、皆さんの問題ない編集も一時的に失われるかもしれませんが、なにとぞご容赦ください。ひとまず2026年2月12日の状態まで戻してみます。
@Kuroco2k, @M-30722, @Praqimu, @20041027 tatsu, @ふゆくれ 相談です。問題を複雑にしないために、この場所で解決を宣言するまではテンプレートやモジュールの編集を控えてほしいです。もっとはっきり言えば、一切編集しないでほしいです。--Naggy Nagumo (トーク) 2026年2月24日 (火) 10:27 (UTC)[返信]
分かりました。その間は基本的にテンプレート等の編集の必要無い範囲での編集を行う予定ですが、万一(確実に影響を及ぼさない範囲で)テンプレート等の編集が必要になった時は事前に相談させていただく場合はあるかも知れませんが極力無いようにします。--M-30722 (トーク) 2026年2月24日 (火) 14:29 (UTC)[返信]
かしこまりました。--Praqimu (トーク) 2026年2月24日 (火) 16:00 (UTC)[返信]

2026年2月12日以降に変更されたモジュールのうち、明らかに問題ないもの以外は戻しました。エラーは減りましたが、依然として残っています。この時点で壊れているテンプレートが多数あったようですね。ここからは一つずつ丁寧にエラーを修正していく作業になりそうです。可能な限り、エラーの数がゼロになるまでエラーが増える可能性のある活動はしないでください。エラーを減らす作業は歓迎します。 --Naggy Nagumo (トーク) 2026年2月25日 (水) 13:09 (UTC)[返信]

皆さんご協力ありがとうございました。以下のように残件はありますが、今できることはやりました。
  • rikinkpa」のエラーが未解決。直すためにはアイヌ語の知識が必要です。期待する動作内容を教えていただければモジュールは直せます。
  • テンプレート:de-adecl」のプログラム文法エラーは取り除いたが、正しく動作していない。
  • テンプレートページのエラーは、includeonlyタグを使うことでエラーを隠した。この対応がベストとは言えないが、優先度は低いためこれで済ました。
  • 利用者ページは、その利用者のトークページでエラーを取り除いてもらうよう依頼しました。反応がなければ私が代わりに対処することにします。
これでひとまず片付いたので、もうテンプレート・モジュールを編集していただいて構いません。でも、覚えておいてください。スクリプトエラーが既に発生している状況では、モジュールの編集を避けてください。警告を無視するようになると、収集がつかなくなります。誰かの編集がきっかけでエラーが増えた場合は、その人に知らせてください。もうこんな作業を私にさせないでください。--Naggy Nagumo (トーク) 2026年2月28日 (土) 13:06 (UTC)[返信]
対応ありがとうございました。今回モジュールの改変をされました@Praqimuさんに関しましては以前{{pt-IPA}}で大量エラーを発生した際も自分で直せずに他の人に対処してもらっていた経緯がありますので3度目は無いようにしていただきたく思います。テンプレートやモジュールは複数の項目で使われているものなので目の前の項目だけでなく他の項目の事も考慮して編集する必要があり、エラーを確認した場合はすみやかに解消を試み、どうしても無理そうなら自分で直せなくなる前に元の状態に戻して下さい。--M-30722 (トーク) 2026年3月1日 (日) 14:51 (UTC)[返信]
はい。--Praqimu (トーク) 2026年3月1日 (日) 18:00 (UTC)[返信]
対応ありがとうございました。--Praqimu (トーク) 2026年3月1日 (日) 18:00 (UTC)[返信]

見出しは構造を示すものではないんですか?

[編集]

」などのページで「教育漢字 (第1学年)」という見出しが立てられています。こんなことしていいんですか?見出しは構造を示すものであって、内容を示す部分ではないと思うんですけど。--Naggy Nagumo (トーク) 2026年2月22日 (日) 11:01 (UTC)[返信]

これは例の漢字項目の大規模な改変を行なった@Vinegar03さんが作成した{{ja-kanji}}によるものですね。このテンプレートで出力される表そのものは後に使用する上での合意はされていたかと思うので表示の修正を試みてみます。--M-30722 (トーク) 2026年2月22日 (日) 13:15 (UTC)[返信]
対処 モジュール:jawiktを編集して表の調整を行いました。ご確認の程よろしくお願い致します。--M-30722 (トーク) 2026年2月22日 (日) 13:32 (UTC)[返信]
完璧、素晴らしいです。このスタイルのほうがずっと意味的に整っています。テンプレート内部で見出しを生成しているという問題も解消して一石二鳥です。--Naggy Nagumo (トーク) 2026年2月22日 (日) 13:51 (UTC)[返信]

現代日本語項目における歴史的仮名遣いの規定

[編集]

以前旧字体表記についてはWiktionary:編集室/2025年Q2#日本語における旧字体表記にて規定を定めましたが、歴史的仮名遣いについてはまだ定めていなかったので議論したく思います。旧字体表記に合わせて1946年時点で存在していた語を歴史的仮名遣いを付ける対象としたいと思いますがいかがでしょうか?--M-30722 (トーク) 2026年3月1日 (日) 14:44 (UTC)[返信]

反対 反対 旧字体に関する議論に意見を述べた記憶はありますが、「1946年時点で存在していた語」に限定するという話は賛同した覚えがありません。ほかの人も賛同しているようには見えません。いちいち「この語は1946年に存在していましたか?」と訊いていくつもりですか?ひとつひとつの語句の成立年代を調査して、年代に応じて旧字体の使用可否を管理し、歴史的仮名遣いの妥当性を検証するのは、参加者にとって過剰な負担になる懸念があります。--Naggy Nagumo (トーク) 2026年3月1日 (日) 14:58 (UTC)[返信]
旧字体表記の議論では「旧字体で表記されたことがなさそうな新しめの語句(例えば「断捨離」)に旧字体が必要かどうかは自信がない」という話をいただいたこともあり、新しい語句に関しては採用を保留しております(もし古い新しいに関わらず旧字体や歴史的仮名遣いが必要であるという意見が出てきた際は解禁する議論をしても良いと思います)。また、現代日本語の項目において必要なのは新字体表記及び現代仮名遣いであり、旧字体表記や歴史的仮名遣いの記載はあくまで書きたいのであれば書いても良い程度のものかと思いますし、成立年代の判定に関しては新語の投稿で既に行われている(5年以上経過した語)ことを考えますとその負担を求めても問題ない(分からなければ新字体と現代仮名遣いだけ付けておけばよい)かなと考えております。--M-30722 (トーク) 2026年3月1日 (日) 15:15 (UTC)[返信]
それは「積極的に作成すべきか?万人に受け入れられるか?」という観点で懸念を述べただけであり、私の意見はそのあとに書いた「システマティックに全部作っちゃえばいい」の部分です。旧字体や歴史的仮名遣いは重要な情報ではなく、書きたい人が書けばいい、というのは同感です。でも、2021年に存在したかを調べるのと1946年に存在したかを調べるのは同程度の負担だとする主張は信じがたいです。そもそも1946年にいきなり全て新しい書き方に置き換わったわけではなく、公示から長い期間を経て徐々に古い書き方が駆逐されていったわけです。そう考えると1946年という境界自体、人工的で確実とは言えません。このような制限は、あいまいな根拠に基づくものであり、編集負担が大きく、検証困難であると思うのです。制度史を重視するよりも、持続可能な編集モデルのほうが役に立つとは思いませんか?--Naggy Nagumo (トーク) 2026年3月2日 (月) 13:04 (UTC)[返信]
であれば、そもそも現代日本語において歴史的仮名遣いは基本的に不要であると思うので一律に書かない(古典日本語に任せる)という判断もあるのではと思います。例えば、「小泉進次郎構文」のように明らかに近年出来た言葉に歴史的仮名遣いが付けられています(そもそも「こいづみしんじう」ではなく「こいづみしんじう」では)がこれはかなり違和感があります。実際に使われ得ないような有り得ない表記を辞書として扱う必要があるのでしょうか?そのような表記を書くくらいなら最初から書かない方がマシかと考えます。--M-30722 (トーク) 2026年3月2日 (月) 13:36 (UTC)[返信]
確かにこれはひどいですね。間違っているのもそうですが、この種の語句は歴史的仮名遣いを扱うべきではありません。これは近年のインターネット文化発祥の語句であり新字体・現代仮名遣い環境を前提にしています。さらに人名は史料に存在しない限りは古い形にすること自体不可能です。
主張がぶれて恐縮ですが、確かにすべてを受け入れるのはリスクがあるようです。辞書は、存在しない形を創作する場ではありませんよね。でも最初の1946年ルールは運用不可能だという気持ちは変わりません。どんな規則であれば無意味な記載を避けつつ、意味のある表記を受け入れられるでしょうか?一律で書かないというのも一案だとは思います。--Naggy Nagumo (トーク) 2026年3月2日 (月) 14:45 (UTC)[返信]
日本語版Wiktionaryには日本語とは別に「古典日本語」という言語が設けられておりますので歴史的仮名遣いに関しては完全にそちらに任せてしまえば良いのではと思います。その場合のデメリットとしては明治以降に作られた和製漢語に対応出来ないというものがありますが、そもそも現代日本語の歴史的仮名遣いにどれほどの需要があるのかが疑問なところではあります。--M-30722 (トーク) 2026年3月2日 (月) 15:03 (UTC)[返信]