Wiktionary:編集室

ショートカット
WT:ER
WT:VP

ウィクショナリーにお越しの皆様、ようこそ！ここはウィクショナリー日本語版についての様々な事柄について、皆様と一緒に話し合う、ウィキペディアでいう井戸端に相当する場所になります。告知や意見募集を行いたい場合は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:おしらせ.

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

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

新しい議題を作る/Create a new discussion

ログ

単漢字項目

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

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

カテゴリ:Unicode CJK Unified Ideographs Extension A が分かりやすいですが、次のページで送って後ろのほうを見ると、いま現在、１文字ずつ見出しができて不細工になっています。単漢字項目には、そもそもテンプレート: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 の使用が前提ですか。

純粋に上記節に書いた編集が１つでもされていない私が作った（私を真似て作った）項目は、基本的に規則正しく並ぶようになっています。

カテゴリ:漢字の後ろのほうに吹き溜まっている項目をどうするかです。手間掛けてすみませんね。--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)[返信]

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

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

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

見本として「喻」を編集し、コード番号を漢字見出しに入れる形にしています。どなたかご意見等ありますでしょうか？ --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見出し(ハイフン２個で挟むやつ)の直前の水平線は不要であり見つけ次第削除したいとは考えておりますが、積極的に水平線を追加している編集者もおり、このままではイタチごっこになってしまうでしょう。以上より、私は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)[返信]

`{{ja-compound}}`

画期的でこのテンプレートを使用してみたところ、カテゴリ:日本語接尾辞"的"ではなくカテゴリ:日本語接尾辞的が付与されました。私には直し方が分からないので、ここで報告だけさせていただきます。--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)[返信]

コメント 明確に賛否を示せるところでないのでコメントにとどめますが。

例えば「異体字の異体字」というケースがありますが、いわゆる正字のコードの前にも後ろにも異体字がある場合、「B（同字）, A（正字）, C（同字）」といった形になり、あまり好ましい配置ではなくなります（基本正字を先頭に、異体字をその後ろに配列したいです）。
- 「枣」が多分その顕著な例でしょうか。編集画面で実際にいじっていただくと分かると思います。
それにプラスで、語義A、語義B、語義C...と続くと、まあ異体字の欄がぐっちゃぐちゃで、大変見づらいです。「あ（語義3）, い（同字）, う（古字）、え（語義1）...」という風に書けばいいじゃないかと言われるかもしれません（実際にそう書かれている項目もあります）が、個人的には、集約できるものは一か所に集約したいものです。
一方、項目の主軸をラテン文字に置き、古字や俗字などの概念が今はない、チュノムや古壮字ではまあ実用的であると感じます。ただしどちらにしても同音異義というケースが多発するので、一列に並列させるのは厳しいかと思います（𠡚などのように音ごとに分けるのが現実的な範囲でしょうか）。

--Kuroco2k (トーク) 2025年10月11日 (土) 06:00 (UTC)[返信]

コメントありがとうございます。なるほど、１、２については私の意見と対立しますね。２に関しては括弧の無い字と後ろで纏めている字の区別がつきづらかったり、別字衝突などで一つの括弧に複数の情報を入れたりすると崩れるので、括弧内の内容を纏めないほうがよいと考えています(並べ方に気をつければ何とかなりそうではありますが)。チュノムと古壮字に関してはあまり詳しくないのですが、異体字の情報は和語の項目と同様にアルファベットの項目に集約できませんかね(からす【鴉・烏】みたいに)。--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 HやUnicode CJK Unified Ideographs Extension Jで「スクリプトに割り当てた時間が終了しました。」と表示されて表が出ない事象を確認しており、これ以外でも𱍊で同様の事象を確認しております。--M-30722 (トーク) 2025年11月3日 (月) 14:20 (UTC)[返信]

本人ではなく申し訳ありませんが。

表示項目についてはカテゴリ:Unicode CJK Compatibility Ideographs、カテゴリ:Unicode CJK Compatibility Ideographs Supplementにすべてが網羅されているかと思います。
表が出ないのは単に更新不足です。モジュール:Unicode dataを少し更新しました。現状の漢字項目は（更新したせいで別個のエラーが出てない限り）すべてこれで表示できるでしょう。

--Kuroco2k (トーク) 2025年11月3日 (月) 14:44 (UTC)[返信]

リンクの掲示並びにモジュールの更新、誠にありがとうございます。--TAKA647 (トーク) 2025年11月4日 (火) 09:46 (UTC)[返信]

互換漢字の観点ですと、樂や、者、懲あたりですね。いずれも互換漢字が３つ結び付けられていますが、それぞれいくつかのの互換漢字が独自の字形を持っています。--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]。たいへん→大変になっている程度です。安全側に倒すなら削除に移すべきでしょう。--雛宮黒狐（Talk） 2026年2月13日 (金) 06:51 (UTC)[返信]

辞書項目の説明は短い文のことが多いので、少数の例が一致したからといって即著作権侵害とはみなされない可能性もありますが、この書き方だと明らかにコンテンツを剽窃したと表明しているようなものです。許容されないような気がします。同じユーザーによるほかの編集についても、どうなんでしょう。疑いの目で見ざるを得ません。--Naggy Nagumo (トーク) 2026年2月15日 (日) 11:25 (UTC)[返信]

脚注

↑ 藤堂明保; 松本昭; 竹田晃; 加納吉光 (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)[返信]

ハンガリー語の辞書順についての文書を仮に作成するとすれば、合字などを反映した以下のような内容になると思われます。借用語にしか現れない4字を括弧で閉じています。

(例示ここから)

ハンガリー語の見出し語は、ラテンアルファベットに基づく辞書順で配列される。基本的な順序は以下の通りである。

A, Á, B, C, Cs, D, Dz, Dzs, E, É, F, G, Gy, H, I, Í, J, K, L, Ly, M, N, Ny, O, Ó, Ö, Ő, P, (Q,) R, S, Sz, T, Ty, U, Ú, Ü, Ű, V, (W, X, Y,) Z, Zs

この順序はハンガリー語の辞書において一般的に用いられるものであり、以下の特徴を持つ。

Á, Cs, Dz, Dzs, É, Gy, Í, Ly, Ny, Ó, Ö, Ő, Sz, Ty, Ú, Ü, Ű, Zs はそれぞれ独立した文字として扱われる
大文字・小文字は区別しない（A と a は同一とみなす）
Q, W, X, Y は他言語から借用された語およびその複合語にしか現れない
Cs, Dz, Dzs, Gy, Ly, Ny, Sz, Ty, Zs は合字であり、1文字として扱われる(まれに使用される Cz, Ds, Th, Ts は合字として扱わない)
ダイアクリティカルマーク付きの文字は Á, É, Í, Ó, Ö, Ő, Ú, Ü, Ű のみ区別される。まれに使用されるその他のダイアクリティカルマーク付き文字(Ä, Ÿ)は、対応する基本字母と同一視される。

(例示ここまで)

数字・スペース・記号については他のラテンアルファベットの言語のものと同じ扱いで問題ないと思われます。--NekoyamaWataru (トーク) 2026年4月13日 (月) 03:12 (UTC)[返信]

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

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

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

合意と見なしたので、ソート規則をまとめたサブページを作り始めています。ある程度サブページを作ったら「Wiktionary:カテゴリの付け方」から該当する記述を削除します。--Naggy Nagumo (トーク) 2026年4月11日 (土) 13:06 (UTC)[返信]

対処個別言語のソートキーについてはサブページに内容を移動し、アルファベット項目を基本字母で並べるという規則は削除しました。とりあえず書いてあった内容を適宜補足しながら作ったつもりですが、知らない言語（ドイツ語、フランス語、中国語のうち標準中国語以外、ベトナム語）についてはインターネットで調べながら書いたので、間違いが含まれているかもしれません。余力があればチェックしてほしいです。--Naggy Nagumo (トーク) 2026年4月12日 (日) 04:54 (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（と併せてこれも）などのエラーは治るようですが、それをすること自体がリスクを産む危険があるので、進んでやろうにやれない状態です。--雛宮黒狐（Talk） 2026年2月22日 (日) 06:24 (UTC)[返信]

（メンション外失）モジュール:string utilitiesやモジュール:funのように、編集前後で消えていた処理を復活させることで{{文字コード}}など一部のエラーは解消できました。しかし、大胆に変えられたものだと「処理を復活してもその前段階の処理が大きく変わっていて解消が困難である」ものが（パッと見た感じ）多くあります。また、モジュールの差し戻しに起因するエラーも発生しているようです（{{syn-saurus}}を使用しているページ）。--ふゆくれ (トーク) 2026年2月22日 (日) 07:18 (UTC)[返信]

皆さんご意見ありがとうございます。事情を最もよく知っていると思われる方は現れないですが、このエラーを対処するための方針を決めたいです。これまでの編集傾向を考えると、Praqimuさん自身にこのエラーに対処する忍耐力がない可能性を考えています。20041027 tatsuさんやKuroco2kさんにより一定の効果がある修正を加えていただきましたが、根本解決には至っていません。

さて、モジュールを修正する方針ですが、私一人では決めかねています。私自身はモジュールの変更内容を把握していないためです。今の状態から直すとするなら、以下のどちらが良いと思いますか？

ある時点までモジュール群を差し戻しする（おそらく最近の大改造を戻せば解決？）
現在の状態をベースに動くように修正する

①を選ぶ場合は私がやりましょう。②を選ぶ場合は、できる人がやってください（協力はしますが主導はしません）。 --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)[返信]

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

なぜこれが守られないのでしょうか？いい加減にしてほしい。 --Naggy Nagumo (トーク) 2026年3月14日 (土) 14:51 (UTC)[返信]

Praqimuさんに関しましては、先日もグルジア語の格変化表テンプレートでもエラー解消が何ヶ月経っても進まなかった事例がありましたのでこれ以上待ち続ける訳に行かないのでどこかで区切りを付けて対処しようと思います。従いまして、3月20日までにエラーが解消されない場合はエラーが発生しているフィンランド語の格変化表テンプレートの除去を行おうと思いますので@Praqimuさん至急対処願います。--M-30722 (トーク) 2026年3月14日 (土) 15:03 (UTC)[返信]

現在やってはいるんですが、時間が本当にないです。3月20日までには確実に無理なのでM-30722さん、期限を過ぎましたらお願いしたく思います。作業内容としては単純でして「テンプレート:fi-decl-〇〇」を現在のスタイルに合わせるだけです。--Praqimu (トーク) 2026年3月14日 (土) 18:15 (UTC)[返信]

時間がないと言っておきながら全く関係ないテンプレートやモジュールを編集しているように見えます。あなたは言動と行動が滅茶苦茶ですよ。今見たらスクリプトエラーがまた増えていますが、あなたがやったことですか？--Naggy Nagumo (トーク) 2026年3月17日 (火) 14:28 (UTC)[返信]

少しフィンランド語の名詞の格変化表で発生しているモジュール fi-nominals についてのエラーを見てみましたが、母音調和の選別などに必要なパラーメータが不足して発生しているように見えます。

hutu の場合 {{fi-decl-valo|hut|||u}} を {{fi-decl-valo|hut|||u|a}} という5番目のパラーメータに母音調和に基づいてaもしくはäを設定するとモジュールの183行目のエラーが解消されます。

osto の場合語末母音の設定も不足しているので{{fi-decl-valo|ost|||o}} を {{fi-decl-valo|ost|||o|a}} という最後の2つのパラメータを設定するとモジュールの183行目のエラーが解消されます。--NekoyamaWataru (トーク) 2026年3月18日 (水) 00:12 (UTC)[返信]

フィンランド語の格変化表で表示されていたエラー表示はrock以外は一覧表が表示されるように調整しました。rockについては他の言語版からのテンプレートの移植が必要かもしれませんので、そのままにしてあります。--NekoyamaWataru (トーク) 2026年3月18日 (水) 09:23 (UTC)[返信]

お疲れ様です。rockは私が修正します。NekoyamaWataruさん、そして20041027 tatsuさん、本当にありがとうございました。--Praqimu (トーク) 2026年3月18日 (水) 14:30 (UTC)[返信]

今回も他の人がエラーを解消してくれましたが、ポルトガル語等の発音の件といいグルジア語の格変化表の件といい、自分で出したエラーを解消し切れず他の人が代わりに解消したのは（私が把握している限りでも）3回目ですよ。Naggy Nagumoさんから指摘があった通りエラーの解消を最優先とせず全く関係のない編集を行っていたのは「どうせ誰かがエラーを解消してくれるであろう」とエラーの解消を他人に丸投げしたのでしょうか？このようなエラー放置を繰り返されますと他の編集者を疲弊させることになりますので「誰かがやってくれる」という認識があるのであれば即刻そのような認識は捨てて下さい。発生したエラーは速やかに解消する（解消できなければ元に戻す）、新規のモジュール等でエラーが出て使えないのであればそのモジュールは使用しない。ここを徹底して下さい。もし自身の編集に責任を持てないのであればモジュールの編集には関わるべきでないです。以後責任持ってできますでしょうか？--M-30722 (トーク) 2026年3月21日 (土) 18:14 (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)[返信]

もし歴史的仮名遣いを扱うのであれば編集者間で認識を共有する為にどこかで線引きを決める必要が生じてきます。「具体的にこの時期で線引きする」という納得のいく境界が存在しないのであれば一律に扱わないとするのが最善かと考えますがいかがでしょうか？もしそれで問題無ければ現代日本語における歴史的仮名遣いは廃止（古典日本語に任せる）にしようと思います。--M-30722 (トーク) 2026年3月14日 (土) 13:42 (UTC)[返信]

時期ではなく史料の有無を基準とするのであれば、運用可能ではないでしょうか。昔の辞書に載っていればいいでしょうし、そうでなくても用例があれば掲載可能でしょう。--Naggy Nagumo (トーク) 2026年3月14日 (土) 14:59 (UTC)[返信]

それでは、出典もしくは用例を明記することで記載可というのはどうでしょうか？--M-30722 (トーク) 2026年3月19日 (木) 09:38 (UTC)[返信]

ごく一般的な語にまで証拠を求められると、ちょっと大変かもしれません。この種の語句だけ典拠の明記を必須とするより、史料の存在が必要条件であることを「Wiktionary:編集方針」に書いておいて、存在しなければ「Wiktionary:正確性検証中」による審議を経て削除くらいの運用がよくないですか？--Naggy Nagumo (トーク) 2026年3月19日 (木) 14:50 (UTC)[返信]

私としましては管理上、具体的かつ分かりやすいルールになれば問題ないです。「史料」とは具体的にどのようなものが該当するのか例を挙げて記載しておくと多くの編集者にとって分かりやすいかなと思います。--M-30722 (トーク) 2026年3月20日 (金) 15:15 (UTC)[返信]

OKです、運用可能であれば、これ以上こだわりはありません。載せないほうがいい情報を排除できるルールが必要です。--Naggy Nagumo (トーク) 2026年4月11日 (土) 11:13 (UTC)[返信]

ご相談

偉大のページに派生語として掲載されている「中華民族偉大復興」のようなスローガンの類は編集方針に沿うものでしょうか？--Jiba1219 (トーク) 2026年3月17日 (火) 19:24 (UTC)[返信]

スローガン（標語）に関しては、現在ウィクショナリーに存在するものとしては安全第一などが挙げられますが、編集方針の項目ではWiktionary:編集方針#複合語の扱いあたりが適用されそうに思います。なので要件3の「用語として定着し、十分熟していると見做せるもの」を満たしているかどうかがポイントになってくるかなと思います。--M-30722 (トーク) 2026年3月19日 (木) 10:11 (UTC)[返信]

和製英語

和製英語の単語の説明がバラバラなので{{wasei}}のようなもので{{wasei|和製|英語}}のようにすれば、「和製 + 英語の和製英語」のように表示できるテンプレートが欲しいです。--ねこ8 (トーク) 2026年3月21日 (土) 06:14 (UTC)[返信]

対処既存テンプレートの{{和製英語}}に機能を追加しました（使い方は左記テンプレートのリンク参照）。「ラブホテル」にて使用してみましたがいかがでしょうか？--M-30722 (トーク) 2026年3月21日 (土) 18:34 (UTC)[返信]

ありがとうございます。とても良いです。--ねこ8 (トーク) 2026年3月22日 (日) 02:15 (UTC)[返信]

ご相談

日本語の接尾辞"的"というカテゴリがすでに存在していますが、共産主義や修正主義などの「主義」は「的」と同様の接尾辞とみなしてカテゴリとして作成できるものなのでしょうか？--Jiba1219 (トーク) 2026年3月25日 (水) 17:53 (UTC)[返信]

「主義」は接尾辞ではないと思います。--Naggy Nagumo (トーク) 2026年3月31日 (火) 12:44 (UTC)[返信]

確かに「主義」は単独で名詞として用いられる語であり、純粋な接尾辞とは性質が異なる点は理解しております。ただ一方で、「共産主義」「修正主義」のように、他の語に後接して一定の意味（思想・立場）を付与するという点では、接尾辞に類似した語形成的機能を持っているとも考えられます。Wiktionaryにおいて「的」がカテゴリ化されているのも、このような語形成上の共通性を整理する意図によるものと理解しておりますが、同様に「〜主義」という形で多数の語が体系的に存在する以上、それらを一つのカテゴリとして整理することにも一定の意義があるのではないでしょうか。--Jiba1219 (トーク) 2026年4月4日 (土) 10:10 (UTC)[返信]

カテゴリは良いと思いますが、「接尾辞」という言葉を避けて説明するほうが無難だと思います。たとえば「"主義"がつく語句」みたいなカテゴリ名なら突っ込まれないと思います（この例だと語源を扱っていることを表現しきれていない感がありますが）。--Naggy Nagumo (トーク) 2026年4月4日 (土) 11:02 (UTC)[返信]

ご指摘ありがとうございます。接尾辞と断定することには確かに議論の余地があるため、その点は避けた方がよいという点は納得いたしました。一方で、「主義」が語形成上一定の役割を果たしていること自体は整理の価値があると考えているため、例えば「造語成分」といった形で位置づけることで、過度な断定を避けつつ整理することは可能ではないかと思いました。カテゴリ名としては、たとえば「日本語造語成分"主義"」のような形であれば、語形成の観点もある程度反映できるかと考えていますが、いかがでしょうか。--Jiba1219 (トーク) 2026年4月4日 (土) 13:39 (UTC)[返信]

Bot Flag Request for 利用者:SchlurcherBot

Appologies for posting in English. Also, I could not locate a dedicated page for bot request in 日本語 Wiktionary, so I am posting here. Please direct me to the correct page if one exists. Thank you.

Bot name: 利用者:SchlurcherBot
Bot operator: commons:User:Schlurcher
Bot task: Automatically convert links from http:// to https:// (secure protocol migration)
Technical details: Please see meta:User:SchlurcherBot for full details, including the expected number of affected URLs on 日本語 Wiktionary.
Bot flags on other projects:: Global bot status granted. Also flagged on English Wikipedia, German Wikipedia, French Wikipedia, Italian Wikipedia, Polish Wikipedia, Portuguese Wikipedia, and Commons. For a full list, see: sulutil:SchlurcherBot
Comment: The bot is globally approved and active on the top 10 Wikipedia projects. As this wiki has opted out of the global bot policy, I am requesting permission to perform these link updates on 日本語 Wiktionary as well. Please let me know if a local bot flag can be granted or if you have any questions. Thank you. --Schlurcher (トーク) 2026年3月26日 (木) 22:22 (UTC)[返信]

Schlurcher, did you mean to put yourself in the Bot operator column instead of your bot account? Tenshi Hinanawi (トーク) 2026年3月26日 (木) 23:35 (UTC)[返信]

Thanks. Yes, now corrected. --Schlurcher (トーク) 2026年3月27日 (金) 08:30 (UTC)[返信]

@Kanjy Let me know if bot status can be granted. --Schlurcher (トーク) 2026年4月17日 (金) 06:46 (UTC)[返信]

@Schlurcher ボット申請の場所はここです→「Wiktionary:ボット/使用申請」--Naggy Nagumo (トーク) 2026年4月28日 (火) 09:06 (UTC)[返信]

Thanks for highliting the page. I will include this in the second round of approval. This can be closed for now. --Schlurcher (トーク) 2026年4月28日 (火) 11:54 (UTC)[返信]

XXBlackburnXxさんが行ったブロックについて 260327

日本語版ウィクショナリーでは、日本の大手通信会社の広いIPアドレス帯域となんの編集もない見てるだけのたくさんの姓名のアカウントが再度user:XXBlackburnXxさんによってブロックされたようですが、ウィキメディアでは姓名のアカウントは作ってはいけないのですか？--~2026-19007-83 (トーク) 2026年3月27日 (金) 08:35 (UTC)[返信]

姓名のアカウントを作成すること自体は問題ありません。ただ、それらのアカウントは明らかにLTA:ISECHIKAのソックパペットであり、多重アカウントの不適切な使用であるため、ブロックされています。--20041027 tatsu (トーク) 2026年3月27日 (金) 13:44 (UTC)[返信]

非推奨テンプレートの一斉変更について

非推奨テンプレートである{{infl}}と{{see}}の二つをボットを使用して一斉にそれぞれ{{head}}と{{also}}に変更しようと考えております。seeについてはセネカ語の言語テンプレートを兼ねておりますが、現在セネカ語の項目は未作成でありますので全てalsoに変更しても問題ないと考えます。つきましては一斉変更の合意を取りたいと思いますのでご意見ご投票の程よろしくお願い致します。--M-30722 (トーク) 2026年3月29日 (日) 10:59 (UTC)[返信]

セネカ語の用途で使用例があります：付録:記号言語対応表（言語名→記号）, 付録:記号言語対応表（記号→言語名）。これらをどうしますか？--Naggy Nagumo (トーク) 2026年3月29日 (日) 14:09 (UTC)[返信]

一時的に手打ち（[[セネカ語]]）に変更して、以降処理が終わり次第テンプレートに戻すというのはいかがでしょうか？--M-30722 (トーク) 2026年3月29日 (日) 14:14 (UTC)[返信]

付録から{{see}}を外しました。また、表がまだ3文字コード優先のままになっていたので2文字コード優先に更新しました。 --M-30722 (トーク) 2026年3月29日 (日) 17:19 (UTC)[返信]

賛成この少人数で手動でやろうものなら20年かかってもおかしくない。替えれるものはさっさと変えてほしい。--雛宮黒狐（Talk） 2026年3月30日 (月) 22:53 (UTC)[返信]

上記の問題は性質的にinsource:/"{{see|"/で範囲を絞ればそんなことしなくても解決できそうに見えますが、ならない理由があるんでしょうかね?--雛宮黒狐（Talk） 2026年3月30日 (月) 22:53 (UTC)[返信]
技術的に問題はありません。セネカ語の用途で使用されているものが存在しても、巻き添えで置換されることは回避可能です。ただ全てalsoに変更しても問題ないという主張は正しくなさそうだったので念のため確認しました。--Naggy Nagumo (トーク) 2026年3月31日 (火) 12:43 (UTC)[返信]

特に異議が出なければ合意としたいと思いますが、本件は大規模な編集を伴いますのでなるべく多くの人の意見を聞きたく思います。今回の議題は非推奨のテンプレートの大多数を閉める{{infl}}と{{see}}を自動で推奨されているテンプレート（head、also）に変更することに対する是非を問うもので、これにより非推奨のテンプレートを自動で大きく減らせるメリットが期待されます。コメント無しで賛否のみでも構いませんので皆様投票のほど宜しくお願いします。 --M-30722 (トーク) 2026年4月5日 (日) 18:08 (UTC)[返信]

賛成--ふゆくれ (トーク) 2026年4月5日 (日) 21:45 (UTC)[返信]

賛成--ねこ8 (トーク) 2026年4月9日 (木) 13:00 (UTC)[返信]

終了それでは、全会一致で

賛成となりましたので可決します。 --M-30722 (トーク) 2026年4月14日 (火) 18:03 (UTC)[返信]

おや、この決議をもって私にボット作業を依頼しているつもりですね？では以下の作業内容で検討に入ります。最初はメイン名前空間に絞って実行し、必要に応じてほかの名前空間にも範囲を広げていきます。使用するボットは利用者:Naggybot です。

{{infl|　→　{{head|
{{see|　→　{{also|

--Naggy Nagumo (トーク) 2026年4月23日 (木) 09:51 (UTC)[返信]

ありがとうございます、お手数おかけしますがよろしくお願いします。--M-30722 (トーク) 2026年4月26日 (日) 07:50 (UTC)[返信]

終わりました。--Naggy Nagumo (トーク) 2026年5月2日 (土) 01:49 (UTC)[返信]

おかげさまで非推奨のテンプレートを実に8割ほども解消出来ました。ありがとうございました。--M-30722 (トーク) 2026年5月2日 (土) 13:53 (UTC)[返信]

metaのWikimedia Forumに書いても差し戻されること 260330

metaのWikimedia Forumで時々あるようですが、運営に問題があると発言しても管理者が差し戻すようなことはどこで議論すればいいですか--~2026-19631-61 (トーク) 2026年3月30日 (月) 08:27 (UTC)[返信]

漢字表記語の仮名表記について

日本語の同音異義項目を立項していて思ったのですが、「漢字表記語の仮名表記」のうち「単純なリダイレクト」で立項するものが「{{also}}でリンクを踏んだあと、リンク元の同音異義項目に戻れない」のは不便に感じます。そこで、「（英語版のように）漢字表記がただ一つであっても仮名表記をソフトリダイレクトとして立項」すること及び「漢語仮名項目・同音異義項目のスタイル統一」を提案します。

具体的なスタイルは、節名には{{kangokana}}・見出しには{{ja-kangokana}}を用いる（「カテゴリ:日本語漢字表記語の仮名表記」は{{ja-kangokana}}で出力）ようにして、残りは同音異義語のスタイルを踏襲する形が良いと思います。また、同音異義の入力支援をする{{ja-k}}(仮)を作成したいと考えています。

{{ja-k}}(仮)の仕様

{{#ifeq:{{{hom|}}}|y|[[カテゴリ:{{ja}} 同音異義|{{#invoke:ja|jsort|{{PAGENAME}}}}]]}}

*【[[{{{1}}}]]{{#if:{{{2|}}}|・[[{{{2|}}}]]}}{{#if:{{{3|}}}|・[[{{{3|}}}]]}}{{#if:{{{4|}}}|・[[{{{4|}}}]]}}{{#if:{{{5|}}}|・[[{{{5|}}}]]}}】：
--ふゆくれ (トーク) 2026年3月30日 (月) 10:41 (UTC)[返信]

現行では転送先が2語以上あることが前提でしたが、1語でも統一のスタイルで記述するという提案ですね。もう一つの制約について確認したいのですが、現行のルールだと転送先が漢字一文字以外である必要があります。たとえば「かん」「こう」には適用していません。同音異義なのに…。これらも統合するつもりはありますか？--Naggy Nagumo (トーク) 2026年3月31日 (火) 12:51 (UTC)[返信]

朝鮮語のハングル項目やベトナム語の単音節語などと扱いを一にできるので統合を考えています。ただし、「単字で品詞として確立した用法がある」もの以外は今まで通り漢字索引に誘導する形で良いと思います。挙げられた「かん」で言うと、単字での名詞用法がある「官」「缶」などは同音異義のスタイルで記述しますが、漢字音としての用法しかない「串」「減」などは記述せず索引に任せます。--ふゆくれ (トーク) 2026年3月31日 (火) 13:16 (UTC)[返信]

賛成意味的に一貫性があり、用語に矛盾がなくわかりやすいです。--Naggy Nagumo (トーク) 2026年3月31日 (火) 13:49 (UTC)[返信]

賛成--ねこ8 (トーク) 2026年4月18日 (土) 10:12 (UTC)[返信]

このまま反対意見が無ければ5/1から運用を開始したいと思います。--ふゆくれ (トーク) 2026年4月24日 (金) 15:43 (UTC)[返信]

提案運用にあたって、{{ja-homonym}}を現行の「カテゴリ:日本語同音異義」付与に加えて「カテゴリ:日本語漢字表記語の仮名表記」も付与されるようにしようと思うのですがいかがでしょうか？--M-30722 (トーク) 2026年5月1日 (金) 15:45 (UTC)[返信]

コメント 暫定的にはそれでもいいですが、最初の提案の通り「漢語仮名項目・同音異義項目のスタイル統一」を行うので「節名に{{kangokana}}、見出しに{{ja-kangokana}}、同音異義カテゴリは{{ja-k}}」を順次適用していく予定です。--ふゆくれ (トーク) 2026年5月3日 (日) 09:31 (UTC)[返信]

対処「カテゴリ:日本語漢字表記語の仮名表記」も付与する仕様に変更しました。また、二つ質問がありまして

{{ja-homonym}}は将来的には全て{{ja-kangokana}}に置き換えて廃止する予定でしょうか？
同音異義カテゴリの付与は{{ja-k}}の引数「hom」で行うのと、{{ja-kangokana}}の引数「h」で行うのとがあるかと思いますがどちらが推奨でしょうか？もしくはどちらでも問題無いのでしょうか？

--M-30722 (トーク) 2026年5月3日 (日) 09:47 (UTC)[返信]

{{ja-homonym}}は置き換え完了後に廃止の方向で考えています。また、同音異義カテゴリも{{ja-k}}での付与を推奨します（朝鮮語・ベトナム語の漢字語に於ける{{ko-h}}・{{vi-h}}と同様の運用）。--ふゆくれ (トーク) 2026年5月3日 (日) 10:05 (UTC)[返信]

{{ko-h}}及び{{vi-h}}を作成した身としては、これらの言語では見出し語テンプレートとして（その言語専用のテンプレートではなく）多くの言語で共通して用いる{{head}}を使用している為（このテンプレートで同音異義カテゴリを付与しようとすると「cat〇〇=同音異義」のようにやや長ったらしい記述になる）これらのテンプレートで同音異義カテゴリを付与するようにしましたが、専用の見出し語テンプレートの{{ja-kangokana}}があるのであればそちらで付与しても良いと考えておりますが、せっかく見出し語テンプレートがあるのに{{ja-kangokana}}からの付与ではいけないのでしょうか？--M-30722 (トーク) 2026年5月3日 (日) 10:11 (UTC)[返信]

（追記）{{ko-h}}及び{{vi-h}}から同音異義カテゴリを付与する仕様とした理由については上記の他にもこれらのテンプレートは「漢字語」カテゴリを付与するようになっているといったものもあります。{{ja-k}}には漢字語に相当するカテゴリの付与機能は無さそうなので無理に合わせる必要はないと思います。--M-30722 (トーク) 2026年5月3日 (日) 10:15 (UTC)[返信]

無引数で運用されてきた{{ja-kangokana}}よりは既存の{{ko-h}}・{{vi-h}}と同様の仕様にした{{ja-k}}の方がカテゴリ指定忘れが少なそう、という理由です。あくまでも推奨なので{{ja-kangokana}}でのカテゴリ付与を制限するわけではありません。--ふゆくれ (トーク) 2026年5月3日 (日) 10:20 (UTC)[返信]

個人的には{{ja-k}}でカテゴライズする仕組みはちょっと使いにくそうだと感じます。1行目だけで引数homを指定する感じでしょうか？ソートキーはどうやって指定しますか？--Naggy Nagumo (トーク) 2026年5月3日 (日) 11:15 (UTC)[返信]

ソースを見て理解した。ソートキーはページ名から生成していますね。 --Naggy Nagumo (トーク) 2026年5月3日 (日) 11:18 (UTC)[返信]

それでは{{ja-homonym}}及び{{ja-hom}}の非推奨化を行おうと思いますが、まだこのテンプレートを使用しております@うーむさん始めその他皆さん、問題ないでしょうか？ --M-30722 (トーク) 2026年5月5日 (火) 15:33 (UTC)[返信]

了解しました。--うーむ (トーク) 2026年5月5日 (火) 21:11 (UTC)[返信]

ありがとうございます。その他には@鍼灸さんが{{ja-hom}}を使われるかと思いますが、非推奨化の件問題ないでしょうか？--M-30722 (トーク) 2026年5月7日 (木) 10:41 (UTC)[返信]

問題はないです。その際どういったテンプレートを使用していいか教えて頂ければよろしいかと。--鍼灸 (トーク) 2026年5月7日 (木) 11:11 (UTC)[返信]

この議題の提案の通り「節名に{{kangokana}}・見出しに{{ja-kangokana}}」です。同音異義語の場合は「{{ja-kangokana|h=y}}」のようにすることで同音異義のカテゴリを付与可能です。 --M-30722 (トーク) 2026年5月7日 (木) 15:12 (UTC)[返信]

わかりしました。--うーむ (トーク) 2026年5月7日 (木) 15:40 (UTC)[返信]

@うーむ「だんれん」等同音異義語が存在するものに同音異義のカテゴリを付与されておりませんが、「カテゴリ:日本語同音異義」は廃止にでもなったのでしょうか？ --M-30722 (トーク) 2026年5月7日 (木) 15:13 (UTC)[返信]

直しました。--うーむ (トーク) 2026年5月7日 (木) 15:47 (UTC)[返信]

（質問）@ふゆくれ新規に作成された項目を見ておりますと節名の表示が「じゅじょう」のように「漢字表記語の仮名表記」としているものと「じゅうざい」のように従来の「同音異義語」を用いているものとが混在しておりますが、これはどちらでも問題ない（編集者の裁量に委ねる）のでしょうか？私の認識では「漢字表記語の仮名表記」に節名を統一するものと考えておりますのでこの部分の方針を確認したく思います。 --M-30722 (トーク) 2026年5月9日 (土) 17:15 (UTC)[返信]

最初の提案の通り「節名は『漢字表記語の仮名表記』で統一」です。--ふゆくれ (トーク) 2026年5月9日 (土) 22:56 (UTC)[返信]

ふゆくれさんと同じ認識です。従来の「同音異義」という見出し名は正確な理解が非常に難しい用語です。たとえば「いし」項目で「『石』は同音異義に含まれないのか？」という無駄な疑問を生じさせる可能性が高いと感じます。--Naggy Nagumo (トーク) 2026年5月10日 (日) 01:53 (UTC)[返信]

過去に削除された項目について

「池沼」のページが2010年に削除されていますが、ネットスラングとしては現在も使用されていることから十分に定着していると考えることができ、それ以外にも不動産登記における地目の一つとして「池沼」が存在していることから、後者の項目だけでも作成し直してよいと考えますがいかがでしょうか。--Jiba1219 (トーク) 2026年4月4日 (土) 17:18 (UTC)[返信]

荒らしのために保護を掛けて、そのままになっているみたいですね。記録を見る限りでは荒らしがあった時期と保護を設定した時期に隔たりがあり、保護自体の正当性が確認できません。やむを得ない理由があったとしても、保護期間を無期限にするのは不適切です。「池沼」は一般的な語句であり編集可能であるべきです。また今の状況であれば蔑称のほうも掲載可能だと思います。--Naggy Nagumo (トーク) 2026年4月4日 (土) 23:25 (UTC)[返信]

あなたには「このページの作成」を行う権限がありません。理由は以下の通りです:

⧼Titleblacklist-forbidden-vandalism⧽

という表示が出て作成できない状態なのでどなたか対処していただけないでしょうか？--Jiba1219 (トーク) 2026年4月13日 (月) 17:57 (UTC)[返信]

Wiktionary:保護解除依頼で依頼してみてください--ねこ8 (トーク) 2026年4月14日 (火) 09:04 (UTC)[返信]

作成できない理由は保護ではなく、タイトルブラックリストが原因です。そのため、タイトルブラックリストの編集依頼が必要です。既に私の方で依頼しました。--20041027 tatsu (トーク) 2026年4月15日 (水) 18:56 (UTC)[返信]

訓読みの固有名詞について

現在、Wiktionary:スタイルマニュアル/日本語では固有名詞は漢字表記で立てる事となっていますが、それだとおおののような場合だと名字の大野にたどり着けなくなってしまいます。なので固有名詞でも和語であれば平仮名で立項するのはどうでしょうか？--ねこ8 (トーク) 2026年4月13日 (月) 07:42 (UTC)[返信]

コメント 名字の場合は例えばかわしまのように同じ読みでも複数の漢字表記（川島・川嶋・河島・河嶋）があったり、逆に下田のように同じ漢字表記に複数のよみ（しもだ、しもた、みさだ、しただ、しめだ）があるケースが存在するので漢字項目、かな項目ともに役割があるように感じています。なので名字について独自にルールを新設する方法もあるかと思います。--M-30722 (トーク) 2026年4月13日 (月) 13:09 (UTC)[返信]

Updating old syntax

First let me apologize for the English, I'll add a DeepL translation at the bottom for convenience.

I wanted to ask if it is possible to set a bot to update the old syntax:

[[Category:{{ja}} {{noun}}]] '''[[義]] [[足]]''' (ぎそく)

into

If you see my history, you will see that I have done this manually quite few times, but the number of pages affected is quite large. Besides the fact that I think the template looks better, this is also useful to me because of the quality of extracted data made by the wiktextract project. In particular, readings of words are only extracted if the page uses this template.

For more context, I add the relevant github issue: https://github.com/tatuylonen/wiktextract/issues/1579

DeepL translation

まず、英語が不慣れな点をお詫びします。便宜上、最後にDeepLによる翻訳を添付しておきます。

古い構文を次のように更新するボットを設定することは可能でしょうか：

[[Category:{{ja}} {{noun}}]] '''[[義]] [[足]]''' (ぎそく)

into

のように更新するようにボットを設定することは可能でしょうか。

私の編集履歴をご覧いただければわかりますが、これまでに手動で何度かこの作業を行ってきました。しかし、影響を受けるページ数が非常に多いため、テンプレートの見た目が良くなるという点はさておき、wiktextractプロジェクトによって抽出されるデータの品質の面でも、私にとってこれは有用です。特に、このテンプレートを使用しているページでのみ、単語の読みが抽出されるようになっています。

背景の詳細については、関連するGitHubのイシューを以下に追加します：https://github.com/tatuylonen/wiktextract/issues/1579

DeepL.com（無料版）で翻訳しました。--Daxidawiki (トーク) 2026年4月13日 (月) 08:05 (UTC)[返信]

技術的に、ある程度可能だと思います。ただし多くのページが想定されるフォーマットに合っていないと思うので、網羅的に全てというのは無理でしょう。ボット作業をするためには、その変更に関してコミュニティの合意があることが明確でなければいけません。そのうえで、Daxidawikiさんがご自身でボット作業をしようとしているなら申請が必要ですし、既に運用している方に任せるなら作業内容を明確にする必要があります。--Naggy Nagumo (トーク) 2026年4月15日 (水) 11:18 (UTC)[返信]

I have no experience with Wiktionary bots. It would be preferable if someone else with more knowledge took care of the fixes. What I can do is, as you ask, clearly define the changes, and test some regexes myself against the wikidump to softer the charge on the work.

Ideally there are two families of fixes that I'd like to see applied. Both only concern Japanese entries:

- Replacing the [Category::{ja} {noun}] + MORE into {ja-noun|reading}. This includes variations like {ja-noun-suru|reading}, {ja-adv|reading} etc.

- (maybe for another round of fixes) Fixing the {wago} templates.

I will play around with the wikidump to see if I can get the regex working. In which language are wiktionary bots generally written in?

-----------------

DeepL translation

-----------------

私はウィクショナリーのボットに関する経験がありません。知識が豊富な他の誰かに修正をお願いした方が良いでしょう。私ができることは、ご要望通り、変更点を明確に定義し、作業負担を軽減するために、ウィキダンプに対していくつかの正規表現を自分でテストすることです。

理想としては、2つの種類の修正を適用してほしいと考えています。どちらも日本語の項目に関するものです：

- [Category::{ja} {noun}] + MORE を {ja-noun|読み} に置き換えること。これには {ja-noun-suru|読み}、{ja-adv|読み} などのバリエーションも含まれます。

- （おそらく次の修正ラウンドで）{wago}テンプレートの修正。

正規表現が機能するかどうか、ウィキダンプを使って試してみます。ウィクショナリーのボットは一般的にどの言語で書かれているのでしょうか？--Daxidawiki (トーク) 2026年4月15日 (水) 17:51 (UTC)[返信]

ボットはPythonで記述されることが多いです。ほかの編集者の方々は、この作業について賛成・反対意見やコメントをお願いします。--Naggy Nagumo (トーク) 2026年4月16日 (木) 15:29 (UTC)[返信]

This is the proof of concept in Python. If you and the other editors are interested, then I can continue iterating on it. It only contains the transformation logic, I don't know anything about bots. Feedback appreciated. https://github.com/daxida/bot-wiktionary

--------- DeepL translation

これはPythonでの概念実証（PoC）です。もしあなたや他の編集者の方々が興味をお持ちであれば、引き続き改良を重ねていきます。これには変換ロジックのみが含まれており、ボットに関する知識は一切ありません。ご意見・ご感想をお待ちしています。--Daxidawiki (トーク) 2026年4月16日 (木) 17:18 (UTC)[返信]

I updated the code: it should catch many more errors now. Can I have an update? I would rather not spend more time if there is no intention to apply the fixes.

コードを更新しました。これで、より多くのエラーを検出できるようになったはずです。進捗状況を教えていただけますか？修正を適用する予定がないのであれば、これ以上時間を費やしたくないのです。--Daxidawiki (トーク) 2026年4月21日 (火) 06:40 (UTC)[返信]

皆さん、特に意見ありませんか？4月23日までに反対意見がなければ合意と見なします。--Naggy Nagumo (トーク) 2026年4月21日 (火) 14:43 (UTC)[返信]

それではコミュニティとしてボット作業の合意があると見做しますので、Daxidawikiさんにご提示いただいたないようで検討に入ります。私が運用している利用者:Naggybot は現在ほかの作業に占有されているので、そちらが終わってからになります。ご提示の作業内容はおそらくPywikibotの標準機能では不可能であり、カスタムスクリプトが必要と思います。これは私にとって初めての作業になりますので、検討に時間がかかるかもしれません。--Naggy Nagumo (トーク) 2026年4月25日 (土) 05:53 (UTC)[返信]

I don't know much about Pywikibot but I pushed some rough code that just applies the transformation function to a page wikitext and it seems to work fine. I assume it becomes a matter of having enough privileges to be able to save the changes.

If you copy the repo, you can see the diffs by opening the html in diffs with your browser. I tried to make it as easy as possible to visualize the results. I even spotted some issues that I will try to fix.

I also added a Japanese DeepL translation of the README.

---

Pywikibotについて詳しくは知りませんが、ページのwikitextにトランスフォーム関数を適用するだけの大まかなコードをプッシュしてみたところ、問題なく動作しているようです。あとは、変更を保存できる十分な権限があるかどうかが鍵になると思います。

リポジトリをコピーすれば、ブラウザでdiff内のhtmlを開くことで差分を確認できます。結果をできるだけ分かりやすく可視化するように努めました。いくつか問題点も見つけたので、修正を試みるつもりです。

また、READMEのDeepLによる日本語翻訳も追加しました。--Daxidawiki (トーク) 2026年4月25日 (土) 10:57 (UTC)[返信]

I renamed the repo for consistency, the url is now: https://github.com/daxida/wiktbot

You should be able to modify `bot.py` with whatever logic is needed to save the changes, then run it with `wb run`.

---

一貫性を保つためにリポジトリの名前を変更しました。新しいURLは次の通りです：https://github.com/daxida/wiktbot

bot.py を編集して、変更を保存するために必要なロジックを追加し、`wb run` コマンドで実行してください。--Daxidawiki (トーク) 2026年4月25日 (土) 12:51 (UTC)[返信]

「diff」を確認しましたが、誤動作が目立ちます。

✗ アーカイブ, アーク灯, アードウルフ, アートタイプ, アームストロング砲, アームレスリング, アイアイ, 合い印, 哀韻: 翻訳の記法を変えることは合意されていません。合意のない作業は受け入れられません。
✗ 藍: 誤った置換です。

それから、見出し語表示テンプレート({{ja-noun}}など)を記述する場合、[[カテゴリ:日本語]]も不要になります。残っていても害はありませんが、取り除くこともご検討ください。--Naggy Nagumo (トーク) 2026年4月28日 (火) 09:16 (UTC)[返信]

I think everything was already fixed, I just didn't update the github html. You can make a new one with `wb run NUMBER_OF_PAGES`, for example, wb run 100.

I don't intend to add the translation changes. They share some logic with the other replacement so I was experimenting and testing common logic, but in `main.py`, it should eventually just be `repl = repl_reading`.

There are more subtle errors for sure, it still needs more testing.

I will try to look at `[[カテゴリ:日本語]]`

---

もうすべて修正済みだったと思いますが、GitHubのHTMLを更新し忘れていただけです。`wb run NUMBER_OF_PAGES`（例：wb run 100）で新しいものを作成できます。

翻訳の変更は追加するつもりはありません。他の置換処理とロジックを共有しているため、共通ロジックの実験とテストを行っていましたが、`main.py`では最終的には単に `repl = repl_reading` とするべきです。

間違いなくもっと細かいエラーがあるはずなので、まだテストが必要です。

`[[カテゴリ:日本語]]`を確認してみます--Daxidawiki (トーク) 2026年4月28日 (火) 10:48 (UTC)[返信]

Just to be sure I understand:

- If there is a ja-[noun|noun-suru|adverb|name] (I don't do verb-suru because it's very rare), then I can remove [[カテゴリ:日本語]] and [[category:{{ja}}]] from EVERYWHERE in the page?

確認のため、以下で合っていますか：

- ja-[noun|noun-suru|adverb|name] （verb-suruは極めて稀なので扱いません）がある場合、ページ内のあらゆる場所から[[カテゴリ:日本語]]と[[category:{{ja}}]] を削除してもよいのでしょうか？--Daxidawiki (トーク) 2026年4月28日 (火) 18:02 (UTC)[返信]

それでいいです。--Naggy Nagumo (トーク) 2026年4月29日 (水) 00:16 (UTC)[返信]

Ok, that's added. I updated the diff.html again to only apply the reading replacement that now contains removing [[category:{{ja}}]]. Note that it will also remove [[category:{{ja}}|Some reading]] as it can be seen for 藹雲

Also, should I include the {{wago}} changes, or do you want to do that in a separate run?

---

了解しました。追加しました。diff.htmlを再度更新し、[[category:{{ja}}]]の削除を含む読み替えのみを適用するようにしました。なお、藹雲の例にあるように、[[category:{{ja}}|Some reading]] も削除される点にご注意ください。

また、和語の漢字表記の変更も含めるべきでしょうか、それとも別の処理で対応しますか？--Daxidawiki (トーク) 2026年4月29日 (水) 05:46 (UTC)[返信]

和語の漢字表記に関しては明確な合意があるかどうか微妙です。品詞相当の概念だと考えれば、合意に含まれるような気もします。Pythonソース上では分かれていますが、同じロジックで扱えるのであればリスクも低いので、一緒に作業しても問題ないと思います（個人的な意見）。--Naggy Nagumo (トーク) 2026年5月7日 (木) 09:38 (UTC)[返信]

ja-wagokanjiには「ja」カテゴリも含まれていますか？その変換でそちらも削除したいので、確認させてください。--Daxidawiki (トーク) 2026年5月7日 (木) 16:18 (UTC)[返信]

{{ja-wagokanji}}も同様に、日本語カテゴリを付与します。--Naggy Nagumo (トーク) 2026年5月8日 (金) 11:31 (UTC)[返信]

I pushed some changes. Now we:

remove the ja:category from ja-wagokanji
Improved ja:category detection
Deal with rare readings variants like 副詞 (following the example of 感動詞#Japanese). Ideally the ja-noun template should support this, writing the reading in plain text is always going to be problematic.

--Daxidawiki (トーク) 2026年5月9日 (土) 06:09 (UTC)[返信]

I also included ja-verb and ja-adj in the list of POS replacements.

I'm sure I am missing other POSes, it would be nice to have your bot do the replacements with the current logic, and then look at what I missed to further iterate.--Daxidawiki (トーク) 2026年5月9日 (土) 06:26 (UTC)[返信]

I added some more minor changes. Any update on this? Can I help with something else?

さらに細かい変更をいくつか加えました。これについて何か進捗はありますか？他に何かお手伝いできることはありますか？--Daxidawiki (トーク) 2026年5月15日 (金) 16:54 (UTC)[返信]

時間のあるときに正しく動作するか検討しています。今気になっているのは以下のことです。

置換後のテンプレートにおいて読み仮名は　ひらがな、カタカナ、一部の記号　のみが許容されます。たとえば「ヒンディー語」においてヒンディー語（-ゴ）と記述されていますが、ここから完全な読み仮名を抽出する処理はないですよね。こういうものは少数であり手作業でやったほうがいいと思うので、何らかの条件でスキップできないでしょうか？例えば想定しない記号が含まれているとか、ページ名より読み仮名のほうが文字数が少ないとか。
日本語カテゴリの形式は　([cC]ategory|カテゴリ):(日本語|\{\{ja\}\})　のようになるはずで6通りのパターンがあります(case-insensitiveなら4通り)。"is_category_removable" や "is_category_ja" は正しく動作しますか？

--Naggy Nagumo (トーク) 2026年5月16日 (土) 23:10 (UTC)[返信]

- For ヒンディー語, the noun header did not use a template so the logic wasn't able to parse a section and made no replacements. There is logic to extract the reading when the header is correctly recognized. I added an exception for leading hyphens (there can be inner hyphens, see 愛盛り), and a test for this case.

- I improved the logic to recognize raw headers (it is something that I should have finished before).

- The category functions are tested in every test. is_category_ja expects lowercase because it is only called with such argument:

line for line in s.splitlines() if not is_category_ja(line.lower().strip())

They are not exactly the same: is_category_ja, is just for the japanese category that can be anywhere on the wikipage, while is_category_removable is supposed to be in the pos section (and so we can narrow the regex to be more precise, and have less false positives). is_category_removable is not called with lowercase only strings.

---

- ヒンディー語の場合、名詞のヘッダーにテンプレートが使用されていなかったため、ロジックがセクションを解析できず、置換が行われませんでした。ヘッダーが正しく認識された場合に読み方を抽出するロジックがあります。先頭のハイフンに対する例外処理（内部にハイフンが含まれる場合がある。例：愛盛り）を追加し、このケースに対するテストも実施しました。

- 生のヘッダーを認識するロジックを改善しました（これは以前から完了しておくべきことでした）。

- カテゴリ関数はすべてのテストで検証されています。is_category_ja は、そのような引数でのみ呼び出されるため、小文字を期待します：

line for line in s.splitlines() if not is_category_ja(line.lower().strip())

これらは厳密には同じではありません。is_category_jaは、ウィキページのどこにでも存在する可能性のある日本語のカテゴリ専用であるのに対し、is_category_removableはposセクション内にあるものと想定されています（そのため、正規表現をより厳密に絞り込み、誤検知を減らすことができます）。is_category_removableは、小文字のみの文字列に対しては呼び出されません。--Daxidawiki (トーク) 2026年5月17日 (日) 06:12 (UTC)[返信]

私たちが使っている中国語のソートキーは、辞書順に並ばないのでは？

既存のソートキー生成規則をもとに「Wiktionary:カテゴリの付け方/中国語のソートキー」を書き上げたのですが、変じゃないですか？このソートキーだと「中心(zhōngxīn)」と「重心(zhòngxīn)」が遥か遠くに並びます。--Naggy Nagumo (トーク) 2026年4月13日 (月) 13:04 (UTC)[返信]

これ、中国語の辞書を見たことない私がテキトーに違和感を表明しているだけなので、そういうものであればそれでいいです。実際のところ普通の辞書順ってこれでいいんですか？--Naggy Nagumo (トーク) 2026年4月15日 (水) 10:16 (UTC)[返信]

(いわゆる北京官話についてだと思うのでそうと思って書きます) 例えば『现代汉语词典』では、声調順に中→忪→忠→终（いずれもzhong1）...と続いて、その後に肿→种→冢（zhong3）...と、そのまた後に中→仲→众...ときて重（zhong4）がきます。この手の辞書では一般的な配列なのではないでしょうか？--雛宮黒狐（Talk） 2026年4月15日 (水) 10:40 (UTC)[返信]

同感です。『現代漢語詞典』の派生版である『商務国際現代漢語詞典』（2013年）および『新華字典』第12版（2022年）を確認すると、見出しは声調順（第一声から第四声、そして最後に軽声）で配列され、同一声調内では筆画順に並んでいます。ソートキーも声調順に設定するのが望ましいと思いますがいかがでしょうか。--MiiCii (トーク) 2026年4月16日 (木) 10:58 (UTC)[返信]

もしかして　中→中○→中△→…→忠→忠○→…　みたいに声調まで一致しても1文字目が共通するもの同士を並べてソートするみたいなスタイルですか？今のウィクショナリーはそうなっていませんね。筆画順というのも、ページ名のUnicode順と異なるのであれば、実現できていません。軽声を最後に並べるというのもできていませんね。私たちは中国語の配列順序を見直したほうがいいかもしれません。皆さん、どうしたいですか？--Naggy Nagumo (トーク) 2026年4月17日 (金) 23:17 (UTC)[返信]

北京官話の軽声に関して、私はウェード式に倣って「5」を声調番号に当てていました。これを標準化するのはどうでしょうか？それと、他の方言で声調番号がないものの扱いもどうしましょうか？--ふゆくれ (トーク) 2026年4月18日 (土) 02:01 (UTC)[返信]

軽声の順序を安定させるために「5」を割り当てるのは良いアイデアです。でも問題はそれだけではありません。まずはソートキーのことは忘れて、どういう順序で並べるべきかを整理する必要があります。まずは北京官話について考えましょう。残りの「中国語」も同じような考えで決まるはずです。--Naggy Nagumo (トーク) 2026年4月23日 (木) 09:41 (UTC)[返信]

日本語ソートキー生成規則の変更提案

現在の日本語ソートキー生成規則には不備があります。それは小書き仮名が含まれる場合に順序が安定しないという問題です。小書き仮名は直音よりも前に並ぶことが期待されますが、そうなっているとは限りません。

じょう → じよう（正しい）
不安 → ファン （逆転）
ツアー → ツァー （逆転）

原因は、第1ソートキーと第2ソートキーが同一である場合に第2ソートキーを省略していることと、第1ソートキーがページ名と一致する場合にソートキーを無指定にしていることです。この問題を解消するため、ソートキー生成規則について以下のように変更提案します。

日本語ソートキーは第1ソートキー・第2ソートキーを必ず使用する（省略できない）

（例）

くさもち → くさもちくさもち

影響範囲としてはそこまで大きくないと思います。なぜならこの変更がカテゴリメンバーの並び順に実際に影響する部分は、全体に対してほんの一部であるためです。そもそも今のソートキー生成規則が守られていないページも多数あるので、現状でもきれいに統一されているわけではないです。規則変更後も、ソートキー生成機能を持つテンプレート({{kana-DEFAULTSORT}}とか{{ja-noun}}とか)のインターフェースは変わりません。内部処理が変わるだけです。--Naggy Nagumo (トーク) 2026年4月15日 (水) 10:33 (UTC)[返信]

4月29日までに反対意見がなければ合意とみなし、正式にこの規則で運用開始します。みなさん従ってくださいね。--Naggy Nagumo (トーク) 2026年4月23日 (木) 09:35 (UTC)[返信]

日本語のソートキー生成規則を変更しました。--Naggy Nagumo (トーク) 2026年4月30日 (木) 10:46 (UTC)[返信]

フランス語やドイツ語の第2ソートキーは何のために存在している？

日本語やベトナム語はソート規則が複数レベルに分かれているので、第2ソートキーの意味があります。でもフランス語やドイツ語の第2ソートキーは何のために存在しているのでしょうか？不要ならば第2ソートキーは書かない規則にしようと思います。--Naggy Nagumo (トーク) 2026年4月15日 (水) 11:00 (UTC)[返信]

賛成--Praqimu (トーク) 2026年4月16日 (木) 16:00 (UTC)[返信]

例えば、émanesとémanésは第一ソートキーだけならともに「emanes」となり区別が付かないので第二ソートキーも用いてそれぞれ「emanes émanes」「emanes émanés」とし区別しています。--M-30722 (トーク) 2026年4月17日 (金) 15:47 (UTC)[返信]

このケースでは第2ソートキーを指定してもしなくてもカテゴリページにおける配列順序は同じになります。ただ、一方は第2ソートキーを書いて、一方は書かないみたいに入り混じっていると乱れます。私の見ている限り、第2ソートキーは常にページ名と一致していて、第2ソートキーが必要なものは存在しないように見えます。書いても書かなくても同じ結果となるなら、書かないほうで統一したほうがいいと思います。--Naggy Nagumo (トーク) 2026年4月17日 (金) 23:09 (UTC)[返信]

そういった仕様になっているのであれば第1ソートキーのみで問題ないと思います。--M-30722 (トーク) 2026年4月19日 (日) 10:21 (UTC)[返信]

たぶんこの仕様を知らないまま作られた慣習だと思うので、不必要な第2ソートキーは取り除くことにしましょう。4月26日までに反対意見がなければ、文書に反映します。この変更が効力を持つページはあまり多くないと思いますが、一方で影響するページ数は膨大です。ボットである程度対応できないか検討し、別途提案します。--Naggy Nagumo (トーク) 2026年4月23日 (木) 09:33 (UTC)[返信]

不要な第2ソートキーは用いないことで決定します。このスタイルで統一してください。--Naggy Nagumo (トーク) 2026年4月30日 (木) 10:51 (UTC)[返信]

項目の収録範囲について

主に日本語・漢語（いわゆる中国語）・満洲語（中国の民族言語の一つ）に関するウィクショナリーで編集活動を行っております。編集に詳しい皆様に、項目の収録範囲についてご意見を伺いたく存じます。

渋谷区や大田区といった行政区分、JR・私鉄の駅名、河川名、さらに満洲語における城門（天安門や東直門など）や集落などといった項目を作成することは可能でしょうか。これらが日本語版ウィクショナリーのガイドラインに沿っているか、ご教示いただけますと幸いです。--MiiCii (トーク) 2026年4月16日 (木) 10:03 (UTC)[返信]

地名や施設名に関してはWiktionary:編集方針#地名・施設名の扱いによります。--M-30722 (トーク) 2026年4月17日 (金) 15:49 (UTC)[返信]

了解いたしました。ご回答ありがとうございます。--MiiCii (トーク) 2026年4月21日 (火) 15:32 (UTC)[返信]

四川語拼音のüのソートキーにおける扱いについて

中国語の拼音でüが含まれる場合のソートキーをvで代用するというお話が以前編集室でありましたが、この規則は四川語拼音においても同様と捉えてよろしいでしょうか？--Jiba1219 (トーク) 2026年4月17日 (金) 07:44 (UTC)[返信]

日本語版ウィクショナリーにおいては四川語は見出し上は中国語と一緒に書かれているものの、カテゴリにおいてはそれぞれ区別して付与されておりますのでこの場で四川語のソートキーをどのように扱っていくのかを決めると良いかと思います。--M-30722 (トーク) 2026年4月17日 (金) 16:02 (UTC)[返信]

ご提案ありがとうございます。ソートキーの扱いについてですが、あまり細かく言語ごとにルールを分けてしまうと運用が煩雑になり、編集時の負担や混乱も増える懸念があります。そのため、四川語拼音におけるüの扱いについても、中国語拼音と同様に「vで代用する」という既存ルールに揃える形にしたいと考えています。この方針で統一するのが分かりやすいと思うのですが、皆さんはいかがでしょうか。--Jiba1219 (トーク) 2026年4月20日 (月) 13:47 (UTC)[返信]

それで無難だと思いますが、そもそも北京官話のソートキーをどうするか議論されています（Wiktionary:編集室/2026年Q2#私たちが使っている中国語のソートキーは、辞書順に並ばないのでは？）。その議論の決着次第だと思います。--Naggy Nagumo (トーク) 2026年4月23日 (木) 09:24 (UTC)[返信]

リダイレクトの削除依頼はどこに出す?

古くに移動され、不要とみられるリダイレクトの整理（主にラテン語あたり）をしようと思うのですが、この類はどこに提出すればよいのでしょうか?形式的にはWiktionary:リダイレクトの削除依頼だと思うのですが、それ自体がWiktionary:削除依頼へのリダイレクトになっています。--雛宮黒狐（Talk） 2026年4月19日 (日) 11:50 (UTC)[返信]

即時削除の方針に合うなら即時削除で、そうでないなら削除依頼だと思います。--Naggy Nagumo (トーク) 2026年4月23日 (木) 09:25 (UTC)[返信]

相談

「性氏」は「姓氏」の誤りですが、「姓氏」がリダイレクトではないので移動によって解決することができません。「性氏」作成以後の「姓氏」の編集記録が無いので、この場合、「性氏」の内容を「姓氏」にカット&ペーストした上で履歴統合以来を出すのが良いのでしょうか。--ふゆくれ (トーク) 2026年4月20日 (月) 01:58 (UTC)[返信]

シソーラスの運用をどうしますか？

一部ユーザーによって「シソーラス:○○」というページが作られているようですが、この種のページをメイン名前空間に作るべきではないと思います。数が膨大になる前に運用を決めたほうがいいと思います。私は以下の二つの案がありますが、皆さんはどちらがいいと思いますか？もちろん別の案も歓迎します。

(案1) 「シソーラス」名前空間を新設する
(案2) シソーラスは「付録」名前空間に作る

--Naggy Nagumo (トーク) 2026年4月23日 (木) 09:22 (UTC)[返信]

私個人では案1の方向性で動いてほしい、と思っています。ただ生憎、名前空間のそれは私のパワーでは出来ない問題です...--雛宮黒狐（Talk） 2026年4月23日 (木) 10:22 (UTC)[返信]

案1は具体的にはどのようなものになりますか？--Praqimu (トーク) 2026年4月23日 (木) 12:00 (UTC)[返信]

現在は「シソーラス」名前空間が存在しないので、メイン名前空間に「シソーラス:○○」というページ名を持つエントリーがある状態です。名前空間を追加すると、「シソーラス」名前空間に「○○」というページ名を持つエントリーが登録されることになります。フルページ名は変わらないのでリンクやURLは同一になりますが、{{PAGENAME}}の動作が変わったり、検索や一覧で名前空間を絞っている場合に出てくるか出てこないかが変わったりなどの影響があります。メイン名前空間は辞書本体、すなわち語句の解説を登録する場所なので、シソーラスが混じらないように分けたほうがいいです。--Naggy Nagumo (トーク) 2026年4月23日 (木) 12:22 (UTC)[返信]

そういうことですね。シソーラス関連のテンプレートを最初に作成したのはおそらく私なんですが、私自身そちらの仕様を想定していました。案1に

賛成です。--Praqimu (トーク) 2026年4月23日 (木) 12:32 (UTC)[返信]

今の状態が望ましくないということは分かっていただけていると思いますが、次は「付録にまとめるのではだめなのか？」というところが論点になります。英語版ウィクショナリーでは既に対応する名前空間があり、一定の成功例と言えるのかもしれません。でも日本語版ウィクショナリーで真似をしなければならない道理はありません。名前空間新設を支持する方は、なぜ付録ではだめなのか、付録との構造的な違いを説明してほしいです。 --Naggy Nagumo (トーク) 2026年4月26日 (日) 04:14 (UTC)[返信]

一つの見出し語に表示するには多数の類義語へのリンクをまとめて置く(似たようなものですと、英語版のalso用のまとめ項目のような)ものという感覚で捉えて使用しておりました。

付録もしくは付録と同列のものという扱いあっても、リンクの設置方法に変更がないのであれば問題ありません。--NekoyamaWataru (トーク) 2026年4月26日 (日) 09:59 (UTC)[返信]

付録に移動する場合はリンクが変わります。シソーラス名前空間を新設する場合はリンクが変わりません。今のところ日本語版ウィクショナリーではシソーラスのエントリー数が非常に少なく、名前空間を新設するほど大きなテーマなのかどうか、方針が固まっているのかどうか疑問に思います。

私は名前空間の新設に反対ではありませんが、ちゃんと理由があるのかが気になります。名前空間を新設することは私たちで勝手にできることではなく、責任が伴います。今のところ誰もシソーラスの必要性について述べてくれないので、これではWikimedia Foundationの人たちに説明できません。--Naggy Nagumo (トーク) 2026年4月27日 (月) 11:55 (UTC)[返信]

今回作成しましたハンガリー語のシソーラス項目は現在英語版にあるもの全てで、数が爆発的に増えるような気配はありません。名称が変わるだけでしたら手作業で対応できる数ではあります。また日本語版で独自に増やすことは現在考えておりません。--NekoyamaWataru (トーク) 2026年4月27日 (月) 13:06 (UTC)[返信]

シソーラス名前空間を新設すべきと考える理由は、単に検索しやすいからです。付録に移動する場合は「付録:シソーラス/〇〇」といった名前になりますよね？対してシソーラス名前空間の場合は「シソーラス:」と、検索する際の手間が省けます。それに付録名前空間にしてしまうと付録が増えすぎてしまうという問題も発生してきます。増えすぎると管理もしづらくなるでしょう。付録に関して、もし異なるものを想定しているようでしたらお教えください。--Praqimu (トーク) 2026年5月8日 (金) 15:30 (UTC)[返信]

シソーラス名前空間に入るページの数はどれくらいになると想定されますか？付録の9割以上がシソーラスになるとしたらたしかに独立させたほうがいいような気もしますが、半分未満なら他の付録と同居していて不都合はないと思います。 --whym (トーク) 2026年5月10日 (日) 05:07 (UTC)[返信]

半保護の明示は必要?

利用者・トーク:ねこ8#半保護テンプレートを消す?の延長線上として意見を仰ぎたく思います。従来より慣例として保護されたページには明示のテンプレートを貼っていた(よう)ですが、これらが必要か否かについてです。--雛宮黒狐（Talk） 2026年4月26日 (日) 03:36 (UTC)[返信]

保護されているページは特別:保護されているページで確認できますし、管理も大変で、英語版Wiktionaryでも使用していないので不要だと思います。--ねこ8 (トーク) 2026年6月3日 (水) 12:34 (UTC)[返信]

英語版ウィクショナリー由来のモジュール群をどうやって管理していけばいいか？

英語版ウィクショナリー由来のモジュールがたくさんあります。これらはある時点で英語版ウィクショナリーから流用改変したものです。しかし本流の英語版ではモジュールの修正・改良が続けられているのに、本流から切り離された私たちのモジュールは不具合が修正されず機能も古いままです。だからといって英語版から再流用しようとしても、あまりに差分が大きすぎてもはや手が付けられなくなっていますよね。差分が大きいだけでなく、日本語版ウィクショナリー独自の改変がたくさん含まれていることが、マージを厄介にしています。私たちはどこで間違えたのでしょう。どうすれば本流の変更をマージできる形で日本語版ウィクショナリーに適合できるでしょうか。何か方針を考える必要がありませんか？--Naggy Nagumo (トーク) 2026年5月1日 (金) 14:35 (UTC)[返信]

enwiktのモジュールをjawiktで使おうとするとどうしても和訳が必要な箇所が出てくるのでそっくりそのまま使用するのは元々無理があるのかなと思います。幾つかのモジュールが使用されているテンプレートを見ておりますと、モジュールを使わなくても容易に記述出来る内容のものが複数あるので特にモジュールを使う必要の無い内容であればモジュール無しで記述すると管理上の問題をある程度軽減出来るのかな、と思います。 --M-30722 (トーク) 2026年5月5日 (火) 15:40 (UTC)[返信]

無理ではありません。英語版・日本語版それぞれの変更をマージできないことが問題です。つまり、英語版から持ってきたモジュールのあちこちに変更を挿入していて、しかも変更した箇所が分かりにくいところが問題なのです。こういった編集は自分もやってきたことではありますが、今になって管理不能に陥っていると実感しています。

たとえばrequire("Module:●●")のところをわざわざ和訳して「モジュール:」に変更するのは完全に無駄で、競合の原因にもなります。メッセージの和訳など必要な編集についても同様で、競合が発生しにくい仕組みがあれば役立つと思います。皆さんがどうやってモジュールを更新していくつもりなのか。あるいは何も考えていないのでしょうか？--Naggy Nagumo (トーク) 2026年5月5日 (火) 23:31 (UTC)[返信]

皆さん特に困っていないんですかね？困っていないのであれば{{ja-pron}}で指摘されている不具合を修正してほしいです。誰も修正できないのであれば、困っているということでしょう。--Naggy Nagumo (トーク) 2026年5月10日 (日) 15:09 (UTC)[返信]

OK, 皆さん特に意見ないんですね。私のほうで何か考えます。「Module:」をわざわざ「モジュール:」に置換する編集は、全員今すぐにやめてください。--Naggy Nagumo (トーク) 2026年5月17日 (日) 05:49 (UTC)[返信]

「Module」の翻訳の件了解しました。以前nsTextについては翻訳する必要があるという話がありましたので翻訳すべきものと翻訳すべきでないものを改めて整理して告知していただけますと幸いです。--M-30722 (トーク) 2026年5月17日 (日) 15:58 (UTC)[返信]

とりあえずrequireやmw.loadDataでは翻訳不要で、mw.title.getCurrentTitle().nsTextでは翻訳必須。今はそれだけです。保守可能にするために、今後は英語版ウィクショナリー由来モジュールの編集方法を規定するつもりです。結構複雑な手順になると思うので、文書化は必須だと思います。考えがまとまったら、まずは提案します。--Naggy Nagumo (トーク) 2026年5月18日 (月) 11:39 (UTC)[返信]

質問

閩南語のソートキーについてなのですが、発音が複数存在する場合、特定の地域の発音を優先をするなどの基準はありますか？--Jiba1219 (トーク) 2026年5月6日 (水) 19:04 (UTC)[返信]

現時点では特に基準は設けられておりません。もし設けるとすると閩南語の教材のほとんどが台湾語のものであることを考えると台湾の発音を優先するのが良いでしょうか。--M-30722 (トーク) 2026年5月7日 (木) 10:44 (UTC)[返信]

ありがとうございます。では、台北と高雄など地域によって発音が分かれる場合、どれを採用するかについても、あらかじめ一定の基準を決めておいた方がよいように思います。皆さんのご意見をお聞きしたいです。--Jiba1219 (トーク) 2026年5月16日 (土) 16:39 (UTC)[返信]

既に上のあたりで別派がいるあたり一意に定まってないようですが...見るに昔はもっぱら廈門語中心にしか掲載しておらず、従いまして自分は廈門語を中心にソートキーを組み込んでいました。--雛宮黒狐（Talk） 2026年5月16日 (土) 22:21 (UTC)[返信]

語源での言語名の表示について質問

テンプレート:etyl を使用して「ゲルマン語派」を表示しようと、{{etyl|gem|hu}}と設定しましたが、{{etyl|gem-pro|hu}}と同じ「ゲルマン祖語」と表示されてしまいます(参照: császárの語源)。これを正しく「ゲルマン語派」と表示するためにはどうすればよろしいでしょうか？--NekoyamaWataru (トーク) 2026年5月9日 (土) 08:19 (UTC)[返信]

テンプレート:gemのリダイレクトを解除して「ゲルマン語派」と表記するテンプレートにすればよいわけですが、ゲルマン祖語の文脈で使用されていないかは厳密にチェックする必要があります。--雛宮黒狐（Talk） 2026年5月9日 (土) 08:32 (UTC)[返信]

リダイレクトが設定されていましたか。gemへのリンク元を見るとかなりの項目が表示されますね。császárについては該当部分を一旦コメントアウトにしておきます。--NekoyamaWataru (トーク) 2026年5月9日 (土) 08:42 (UTC)[返信]

簡単ではないと思いますが、言語コードをテンプレート名とする実装をやめるべきです。つまりテンプレートの実装は{{{{{1}}}}}ではなく{{language|{{{1}}}}}のように引数であるべきです。今は{{language}}がそもそも{{{{{1}}}}}の実装になっているので意味がありませんが、「Wiktionary:言語名一貫性チェック」がすべてOKになれば移行可能です。なお{{language}}はカテゴリ名およびレベル2見出しで使う言語にすべきだと思いますが、語源で使用する言語名はまた別で定義したほうがいいでしょう。--Naggy Nagumo (トーク) 2026年5月10日 (日) 04:25 (UTC)[返信]

メインページ姉妹プロジェクト

ウィキニュースが閉鎖されため、Wiktionary:メインページ/姉妹プロジェクトについて対応が必要かと思います。全保護されているようなので、どなたか権限をお持ちの方お願いいたします。--Marine-Blue^{talk❃contribs❃mail} 2026年5月9日 (土) 11:04 (UTC)[返信]

閉鎖の周知させる意味でも、変更はぼちぼちでいいかなと思ってました。

（提案・質問）Wiktionary:メインページ/姉妹プロジェクトのリンク群から、(1)単純にウィキニュースを消去するだけか、(2)ウィキニュースを消去するのに合わせて、英語版ウィクショナリーやウィキペディアのようにウィキファンクションズを追加するか、(3)あるいはその他か、ご意見集います。変更はメインページの姉妹プロジェクト節に反映されます。特に意見なければ(2)の処置を行います。--Yapparina (トーク) 2026年5月9日 (土) 22:47 (UTC)[返信]

お返事ありがとうございます。既に各所でウィキファンクションズへの差し替えが実施されているため、(2)の対応で良いのではないでしょうか。--Marine-Blue^{talk❃contribs❃mail} 2026年5月13日 (水) 07:26 (UTC)[返信]

(2)を支持いたします。保護はされていませんが、Wiktionary:コミュニティ・ポータル/姉妹プロジェクトについても同様の対応をお願いしたく存じます。--Shokupan (トーク) 2026年5月17日 (日) 02:20 (UTC)[返信]

メインページ・コミュニティポータル共に(2)で更新しました。--Yapparina (トーク) 2026年5月23日 (土) 06:18 (UTC)[返信]

古典日本語の「いたいけ」について

こんにちは。日本語が話せるアメリカ人で、大体はウィクショナリー英語版で編集しますので、ここはこんな質問にあってる場所なのかわかりません。そうではなければ告知してください。

いたいけという古典日本語の項目では、語源は「『痛い気』より」と書いてあります。しかし、その「い」と終わる形は中世日本語までは存在しませんでした。古典日本語では、「痛し」と「痛き」しかありませんでした。それで、室町時代に現れた単語の「痛い」は古典日本語の「いたいけ」の語源のはずではありませんね。自分は本当の語源が分かりませんけど、この間違いそうな語源をここの編集者さんに告知していたいけです。よろしくお願いします。Ookap (トーク) 2026年5月15日 (金) 17:29 (UTC)[返信]

手元の辞書（全訳読解古語辞典）では「痛い気」の意と説明がありました。また、デジタル大辞泉では「痛き気」の音変化との説明がありましたので「痛き気」が変化したものである旨の説明に変更することとします。--M-30722 (トーク) 2026年5月20日 (水) 14:29 (UTC)[返信]

ありがとうございました！Ookap (トーク) 2026年5月20日 (水) 15:11 (UTC)[返信]

項目について

項目を作成したときは情報源を追加したほうがいいですか？-- Takuan Yuzuki（TALK・History） 2026年5月16日 (土) 10:43 (UTC)[返信]

「いいですか」というより、「そうすべき」だとは思いますが...控えめに言っても「日本語版ウィクショナリーはウィキペディアに二十何年遅れている」と形容さるるべき現況がありますので、出典を書く文化が依然薄いです。書かないのは信頼性の面で問題があります。--雛宮黒狐（Talk） 2026年5月16日 (土) 11:54 (UTC)[返信]

引用にYouTube動画はあり？

最近、ごく一部の編集者がYouTube動画の文を(現代文としての証左なのかはて分かりませんが)引用として掲載しているようです。この系統ってアリなんでしょうかね？青空文庫のそれと違って問題ありまくりのようにしか見えないのですが。--雛宮黒狐（Talk） 2026年5月19日 (火) 10:10 (UTC)[返信]

テンプレート:ja-proverb doesn't exist

Since idiom and ja-idiom are valid header/template, it makes sense that the same happened to proverb/ja-proverb. Unfortunately, ja-proverb doesn't work. They are documented here: Wiktionary:テンプレートの一覧#品詞表記

Sorry the above link doesn't work. This should:

https://ja.wiktionary.org/wiki/%E3%82%AB%E3%83%86%E3%82%B4%E3%83%AA:%E6%97%A5%E6%9C%AC%E8%AA%9E_%E8%A6%8B%E5%87%BA%E3%81%97%E8%AA%9E%E3%83%86%E3%83%B3%E3%83%97%E3%83%AC%E3%83%BC%E3%83%88--Daxidawiki (トーク) 2026年5月27日 (水) 16:44 (UTC)[返信]

Add a template for the 人名 header

For consistency with name (See Wiktionary:テンプレートの一覧#品詞表記) it would be helpful to have a template for this header. See this category for examples: カテゴリ:日本語日本語人名--Daxidawiki (トーク) 2026年5月27日 (水) 16:32 (UTC)[返信]

Also, what would be the correct version of this page 俊彦? Ideally one that uses a template to display the readings. Is using the ja-name template for the headword (not the header) acceptable?--Daxidawiki (トーク) 2026年5月27日 (水) 16:39 (UTC)[返信]

ボットにRollback権限を付与したい

他ボットの誤動作時に、指定日時以降の編集をまとめて安全に差し戻すためのボットを作成しています。通常権限でできる範囲では、ページごとに最新の編集しか差し戻せず、複数の版がある場合にも差し戻しを確実に行うためには、rollback権限が必要そうです。ボットへのrollback権限付与は、どこで申請するのが適切でしょうか？また事前に合意が必要ということでしたら、何をすれば合意が得られるでしょうか？--Naggy Nagumo (トーク) 2026年5月31日 (日) 10:25 (UTC)[返信]

カテゴリ「社会主義」と「マルクス主義」について

現在、カテゴリ「社会主義」が存在しますが、収録語数は少なく、その運用方針も必ずしも明確ではないように見受けられます。英語版Wiktionaryには「Marxism」のカテゴリが設けられています。一方、日本語版には「社会主義」カテゴリは存在するものの、「マルクス主義」に相当するカテゴリは存在しません。そこで、既存の「社会主義」カテゴリで対応するべきか、新たに「マルクス主義」カテゴリを設けるべきかについて、皆様のご意見を伺いたく思います。--Jiba1219 (トーク) 2026年6月13日 (土) 15:25 (UTC)[返信]

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

[1]

ログ

単漢字項目

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

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

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

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

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

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

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

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

{{ja-compound}}

質問です

項目の削除に関する要望

「関連語」節

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

{{cmn-pron}}について

見出しの並び順

質問です

漢字項目の作成に関して

カテゴリー付与について

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

繁体字について

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

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

広東語の発音について

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

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

旧字体のページについて

文字情報見出しについて

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

Wikipediaへの移行について

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

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

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

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

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

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

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

ご相談

和製英語

ご相談

Bot Flag Request for 利用者:SchlurcherBot

XXBlackburnXxさんが行ったブロックについて 260327

非推奨テンプレートの一斉変更について

metaのWikimedia Forumに書いても差し戻されること 260330

漢字表記語の仮名表記について

過去に削除された項目について

訓読みの固有名詞について

Updating old syntax

私たちが使っている中国語のソートキーは、辞書順に並ばないのでは？

日本語ソートキー生成規則の変更提案

フランス語やドイツ語の第2ソートキーは何のために存在している？

項目の収録範囲について

四川語拼音のüのソートキーにおける扱いについて

リダイレクトの削除依頼はどこに出す?

相談

シソーラスの運用をどうしますか？

半保護の明示は必要?

英語版ウィクショナリー由来のモジュール群をどうやって管理していけばいいか？

質問

語源での言語名の表示について質問

メインページ姉妹プロジェクト

古典日本語の「いたいけ」について

項目について

引用にYouTube動画はあり？

テンプレート:ja-proverb doesn't exist

Add a template for the 人名 header

ボットにRollback権限を付与したい

カテゴリ「社会主義」と「マルクス主義」について

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

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

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

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

`{{ja-compound}}`

`{{cmn-pron}}`について

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