Wiktionary:編集室 - ウィクショナリー日本語版

Wiktionary:編集室 - ウィクショナリー日本語版
コンテンツにスキップ
出典: フリー多機能辞典『ウィクショナリー日本語版（Wiktionary）』
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
ログ
編集
2005年2月まで
m:日本語版ウィクショナリーの整備
2005年6月13日 ~ 7月14日
2005年9月17日 06:16まで
2006年1月5日 20:07まで
2006年5月24日 14:36まで
2006年9月12日 05:39まで
2007年4月12日 00:41まで
2007年7月24日 22:01まで
2006年11月24日までに新設された議論項目
2007年に新設された議題
2008年:
1-3月
4-6月
7-9月
10-12月
2009年:
1-3月
4-6月
7-9月
10-12月
2010年:
1-3月
4-6月
7-9月
10-12月
2011年:
1-3月
4-6月
7-9月
10-12月
2012年:
1-3月
4-6月
7-9月
10-12月
2013年:
1-3月
4-6月
7-9月
10-12月
2014年:
1-3月
4-6月
7-9月
10-12月
2015年:
1-3月
4-6月
7-9月
10-12月
2016年:
1-3月
4-6月
7-9月
10-12月
2017年:
1-3月
4-6月
7-9月
10-12月
2018年:
1-3月
4-6月
7-9月
10-12月
2019年:
1-3月
4-6月
7-9月
10-12月
2020年:
1-3月
4-6月
7-9月
10-12月
2021年:
1-3月
4-6月
7-9月
10-12月
2022年:
1-3月
4-6月
7-9月
10-12月
2023年:
1-3月
4-6月
7-9月
10-12月
2024年:
1-3月
4-6月
7-9月
10-12月
2025年:
1-3月
4-6月
7-9月
10-12月
2026年:
1-3月
4-6月
7-9月
10-12月
単漢字項目
編集
その編集ちょっと待った
。慎重に。
単漢字項目に テンプレート: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)
返信
私が熟語について異体字セレクタを用いて改変&作成している本人です。
私は異体字セレクタを用いての熟語項目を作ることを希望します。
私が編集している記事は，「〜の旧字体表記」とあるものであり，それら記事内で注目されているものは表記についてです。なので優先されるべきは表記だと思います。
もし用いることが可能な場合にはどちらを使うかについてなどは新たに指針を定めればよいと思います。
----
ですので用いての表記に賛成します。--
ダイタクヘリオス
トーク
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
の積極的使用を提言します。現在の基本フォーマットでは異体字を列挙するために「[[●]]」を連続して書いていますが、この記述方法ではソースコードが長大になってしまいます。一方で
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/」は「妹」の意味ですが、辞書 (
) には載っていません。
別の解釈としては：
우라리：（妹）/u.ra.ri/
아리：あり（ある）/ri/
でも、辞書 (
) に載っていません。--
Blahhmosh
トーク
2026年2月7日 (土) 05:16 (UTC)
返信
一部の項目で語義説明の末尾に「漢字源」と記述されている
編集
幾微
幾希
幾望
語義説明の末尾に「漢字源」と書いてあります。ひょっとして著作権侵害だったりしないでしょうか？確認できる方はいますか？--
Naggy Nagumo
トーク
2026年2月8日 (日) 11:19 (UTC)
返信
確認してきました。結論、
ほぼ
そのままです
。たいへん→大変になっている程度です。安全側に倒すなら削除に移すべきでしょう。--
雛宮黒狐
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
to
(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)
返信
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)
返信
metaのWikimedia Forumに書いても差し戻されること 260330
編集
metaのWikimedia Forumで時々あるようですが、運営に問題があると発言しても管理者が差し戻すようなことはどこで議論すればいいですか--
2026-19631-61
トーク
2026年3月30日 (月) 08:27 (UTC)
返信
漢字表記語の仮名表記について
編集
日本語の同音異義項目を立項していて思ったのですが、「漢字表記語の仮名表記」のうち「単純なリダイレクト」で立項するものが「
also
でリンクを踏んだあと、リンク元の同音異義項目に戻れない」のは不便に感じます。そこで、「（英語版のように）漢字表記がただ一つであっても仮名表記をソフトリダイレクトとして立項」すること及び「漢語仮名項目・同音異義項目のスタイル統一」を提案します。
関連議論→
トーク:ながねん
トーク:たっぴつ
--
ふゆくれ
トーク
2026年3月30日 (月) 10:39 (UTC)
返信
具体的なスタイルは、節名には
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)
返信
過去に削除された項目について
編集
池沼
」のページが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
{{ja-noun|ぎそく}}
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:
DeepL translation
まず、英語が不慣れな点をお詫びします。便宜上、最後にDeepLによる翻訳を添付しておきます。
古い構文を次のように更新するボットを設定することは可能でしょうか：
[[Category:{{ja}} {{noun}}]]
'''[[義]] [[足]]''' (ぎそく)
into
{{ja-noun|ぎそく}}
のように更新するようにボットを設定することは可能でしょうか。
私の編集履歴をご覧いただければわかりますが、これまでに手動で何度かこの作業を行ってきました。しかし、影響を受けるページ数が非常に多いため、 テンプレートの見た目が良くなるという点はさておき、wiktextractプロジェクトによって抽出されるデータの品質の面でも、私にとってこれは有用です。特に、このテンプレートを使用しているページでのみ、単語の読みが抽出されるようになっています。
背景の詳細については、関連するGitHubのイシューを以下に追加します：
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.
--------- 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)
返信
私たちが使っている中国語のソートキーは、辞書順に並ばないのでは？
編集
既存のソートキー生成規則をもとに「
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)
返信
フランス語やドイツ語の第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)
返信
項目の収録範囲について
編集
主に日本語・漢語（いわゆる中国語）・満洲語（中国の民族言語の一つ）に関するウィクショナリーで編集活動を行っております。編集に詳しい皆様に、項目の収録範囲についてご意見を伺いたく存じます。
渋谷区や大田区といった行政区分、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)
返信
」から取得
カテゴリ
ウィクショナリー
Wiktionary
編集室
話題を追加