Wikipedia:井戸端

出典: フリー百科事典『ウィキペディア(Wikipedia)』
移動先: 案内検索
水辺の夕暮れ
相談と質問
井戸端
利用案内
調べもの案内
執筆・翻訳者の広場
For Non-Japanese Speakers

このページ(井戸端)は、ウィキペディア日本語版について、運営や方針、新しいアイディアや作業の仕方、その他様々なことで質問や提案、議論、意見交換を行なう場所です。

  • 既に似た質問がないか質問を行う前にご確認ください(→過去ログ検索)。
  • よくある質問(FAQ)もご確認ください。
  • ウィキペディア日本語版やウィキメディア・プロジェクトと関係のない話題を投稿するのはご遠慮ください。

This page is used to ask, propose and discuss the operations, policies and new ideas of Japanese Wikipedia. If you want to write in languages other than Japanese, you can use Help for Non-Japanese Speakers too. If you hope to inform something rather than to discuss, you can post it to お知らせ.


次のような内容には、このページ(井戸端)ではなく専用のページがあります。

ウィキペディア全体に関して
個々の専門分野に関して
個々のページに関して
個々の利用者(アカウント)に関して

井戸端以外に適切な議論の場所がある場合、投稿が移動される場合があります。ご了承ください。


過去ログ
井戸端の過去の議論をこちらから検索することができます。
井戸端タグ
井戸端の過去の議論を井戸端の話題タグカテゴリから検索することができます。
最近の更新
井戸端ウォッチリスト - サブページを含めた井戸端の投稿状況が確認できます。
サブページ
運営方針
  • 投稿された全てのトピックは、サブページに移動します。
  • サブページは、Category:井戸端の話題にカテゴライズしています。
  • サブページは、最新の投稿から10日間経過するか、最初の投稿から30日が経過すると、井戸端への読み込みが解除されます。

目次


citoidは日本語版ウィキペディアでも利用できるようになるか[編集]

VisualEditor Citoid Inspector-xh.png

(ここにきいていいのかわかりませんが) Mediawikiのビジュアルエディタにはcitoidという出典脚注の挿入を補助してくれる機能が用意されてい、enwpなどで実際に使用することが出来ます。

現状の日本語版では利用できないようですが、enwp以外にもfrwpやkowpでも同様に利用できるのでおそらく設定すれば利用できるのかと思います。 mw:Citoid/Enabling_Citoid_on_your_wiki/jaを見た感じ、MediaWiki:Citoid-template-type-map.jsonの設定が行われていないためでしょうか(あるいはtmeplatedataの追加も必要?)、実際これで利用可能になるのでしょうか?

脚注の挿入がいちいち面倒なのでこれが利用できるだけでも大幅に変わるかと思います。 --Hina会話) 2017年11月22日 (水) 16:17 (UTC)

  • これは私も非常に気になっていたものです。日本語版で導入する予定があれば是非やって頂きたいのですが…--さえぼー会話) 2017年11月23日 (木) 01:55 (UTC)
  • 誰も良く分からないなら、とりあえず「MediaWiki:Citoid-template-type-map.json」を英語版からコピペするのはどうでしょう。日本語版に存在しないテンプレートを Citation にするぐらいの修正はします。失敗しても他に影響が出るような物ではないと思うのですが。--Frozen-mikan会話) 2017年11月23日 (木) 05:17 (UTC)
    • そうですね。まずは試してみるのが手っ取り早いかと。幸いにも日本語版のCite系テンプレは英語版の名前をわりとそのまま使ってますしね。 --Hina会話) 2017年11月23日 (木) 13:35 (UTC)
  • 少し日が空いてしまいましたが如何でしょう、他に意見のないようであればひとまずFrozen-mikanさんなりあるいは誰か権限のある方なりに上記コピペを行ってもらってもいいかなと思うのですが。 --Hina会話) 2017年11月27日 (月) 15:43 (UTC)
    • コメント 当方としては有用そうで面白そうな機能は追加してしまいたいところですが、新機能のテストにしては人が集まらない事が気になっています。まあ、反対される方も居られないので、ゆるゆると始めても良いのかな、とは思っています。--Frozen-mikan会話) 2017年11月29日 (水) 17:19 (UTC)
      • (待ってても進まないですね、)告知を出しつつ試していくか、あるいはコメント依頼等でもう少し意見を集めるべきなのか、そのあたり慣れてる方の判断に任せられればと……(なにせ自分は苦手なので)--Hina会話) 2017年12月8日 (金) 17:43 (UTC)
  • 私自身がビジュアルエディタは全然使ってないので若干無責任な賛成にはなってしまいますが、利用者がWP:VWP:CITEを実行することを手助けするツールが充実するのは大歓迎です。ソースエディターの方も英語版ではRefToolbar 2.0というのが備わってて、出典情報の記入を編集初心者でも行いやすいようにしてあるので、これも日本語版に導入されるといいなあと思ってます。--Yapparina会話) 2017年12月9日 (土) 10:06 (UTC)

加筆・修正において「差分の可読性」に配慮すべきか?[編集]

とある利用者の方から「差分が読みづらく変更内容を確認することが困難なため、分割して投稿するかあるいは詳細に要約を記入をして欲しい」とのご指摘を頂きました[1]。確かに問題となった編集では一度に複数の内容修正(改行の除去、節順序の変更、refタグの追加 etc.)を行っているため、差分が追いづらい状態となっています。一方で要約欄において変更内容について簡潔に述べられていることも申し添えておきます。

このように複数の変更を加えた場合に「差分の可読性」を考慮に入れた投稿をする必要があるのか否か、コミュニティの皆様の意見を伺えればと思います。また、もし類似の議論が既になされている場合はご教示いただけると幸いです。

なお私見と致しましては、最低限の要約記入を前提とした上で、履歴の肥大化を避けるためにも敢えて分割投稿する必要はないと考えます(WP:ESWP:CONSEC)。「差分の読みづらさ」については、ローカル環境にて適当なdiffツールを利用すればある程度は解決する問題と思われます。--DFT B3LYP会話) 2017年11月23日 (木) 12:16 (UTC)

参考リンク

  • コメント あなたの個々の編集内容は見てませんが、一般論として「差分の可読性」は考慮しなくても大丈夫です。細かく分けたら分けたで、いくつもの差分を見る羽目になるのですから、かえってそれを不愉快に感じる人もいるはずです。現在のシステムでは(単純な編集でさえ)かえって分かりづらく表示されてしまうことも多々あり、気にしていたらキリがありませんし。「きれいな差分」なんて下らないものにかける時間や労力は、編集内容や他の部分の推敲に使うべきです。--Hisagi会話) 2017年11月23日 (木) 12:32 (UTC)
  • 多くの人が懸念するのは、見難いことが悪用される危険性です。問題があるのは、「荒らしや論争の余地のある編集を気づかれないように混入させるを目的として、差分を複雑にする」ことでしょう。混入していなければ、問題ありません。 --163.49.207.226 2017年11月24日 (金) 11:52 (UTC)
  • コメント ケースバイケースですけどもご自身で仰っておられる通り「各差分で何をどう変更したのかが不明になる最大要因」は『WP:ESに適切に従っていない状態が継続されること』ですから、複数の編集内容を内包した大規模変更に於いても要約欄に適切に編集内容の要約があれば何方であっても理解出来るであろうと思います。 / その上で「故意に履歴を重ねた方がより分かりやすい場合、または『どうしてもそうする必要があって』履歴を分ける場合」などのケースも有り得る、と考えます。 / 具体的な前例としては プロジェクト:ボクシング で全保護中のページの編集に際し、現役管理者さんが「(1度の編集で可能な編集内容を)故意に2回に分けて別内容を投稿、要約欄にその旨明記の上で編集実施した例」を思い出しました(ノートの実施報告で説明された複数回投稿理由も併せて参照)。--Nami-ja (会話 / 履歴) 2017年11月24日 (金) 18:26 (UTC)
  • コメント Hisagiさんのおっしゃるように、そのような約束事は明文上も慣習上も存在しません。単なる趣味の領域ですね。趣味の押し付けなど無視して構わないと思いますが、この機会にそんな趣味の人もいるという事を頭の隅に入れておくのも無駄ではないかと。私自身は、とある項目で大幅改稿するさい、最初に編集除去した分を投稿し、改めて加筆分を投稿したことはあります。一回の投稿で済ますと編集の前後でバイト数がプラマイであまり変化しないのを、ここで大幅改稿したことを解るようにするためですが、単に趣味の問題です。他人に指図されることではありません。--123.218.145.107 2017年11月26日 (日) 01:27 (UTC)
  • コメント ケースbyケースでしょうか。差分がわかりにくくなるのは節の順番を変えるなどした場合ですね。私も差分をわけてわかりやすくするよう心がけているつもりですが、なかなかうまく行かない時もあります。一方、修正前の状態が論外であれば、わかりにくかろうが差分はわけません(差分を見る必要がないと判断します)。他者の編集では、編集に問題がなければともかく、問題のある編集を含み差分がわかりにくい時は、全Rvとする場合もあります。なお、diffツールでもわかりにくい差分もあります。--JapaneseA会話) 2017年11月26日 (日) 06:24 (UTC)
コメント ケースbyケースではありません。全てのケースに置いてそのような義務など全くありません。質問者が聞いているのは、そのような義務(必要性)があるのかであって、その方が便利な場合もあるのかではないです。123.218.145.107 2017年12月7日 (木) 01:16 (UTC)

モバイル版で記事名の下に表示される「ウィキデータの説明文」が荒らされるケース[編集]

私もつい数日前に知ったばかりなのですが、モバイル版では記事名の下に、ウィキデータの情報を引っ張ってきたものが、サブタイトル的に表示されているようです。たとえば、

朝日新聞
モバイル版記事[2]
ニコニコ動画
モバイル版記事[3]
朝日新聞
記事の問題点
日本の新聞
ニコニコ動画
記事の問題点
日本の動画サイト

というような感じです。記事名の下の灰色の説明文はウィキデータにあるもので、これが「日本の悪質新聞」「日本のクソ動画サイト」のように荒らされるケースが起きています。(先ほど見たら、数日前にrvvしたのがまた荒らされていました)

根本的にはウィキデータ側で保護なりブロックなりしてもらわねばなりませんが、とりあえず、jawp外部のデータがあたかもjawpの記事のサブタイトルのように使われているということの周知と、目が行き届きにくいウィキデータのそれを引用する仕組みの是非(やめても良いのでは?)や対策についてのご意見をお願いします。--Hisagi会話) 2017年11月23日 (木) 14:55 (UTC)

自分もいくつか修正しましたが、いずれも記事ノートでの指摘を見てはじめて気づいたものです。問題の部分はデスクトップ版では表示されないのでアクティブな編集者の目に留まりにくいですし、モバイルビューで気づいてもウィキデータを編集するまでの手間がかかります(モバイルビューからデスクトップ版に切り替え、サイドバーからウィキデータに飛ばなきゃいけない)。コミュニティのコントロール下にないコンテンツを問答無用で割り込ませるのであれば、せめて一発で修正できるリンクの提供くらいはしてほしいものです。それができないのであれば、表示させない方がマシでしょう。モバイルビューのスタイルシートで、当該要素を display: none; するのが手っ取り早いかと。--Claw of Slime (talk) 2017年11月23日 (木) 18:36 (UTC)
「記事の問題点」とは別に tagline というクラスが指定されていますので、「.tagline {display: none;}」でピンポイントで消せます。--Claw of Slime (talk) 2017年11月24日 (金) 02:45 (UTC)
その方法ならモバイルウェブ版で「誤魔化す」ことはできても、モバイルアプリ版ではそのままになってしまうため、むしろ監視が今以上に行き届かなくなり、モバイルアプリ利用者に不適切な表示がされ続けるものと思います。場当たり的な対処で解決できる問題ではないかと思います。アプリ版にも依存があるとなると、設定ファイルから切るだけといったものではすまなさそうに見えますね…(英語版ウィキペディア、ロシア語版ウィキペディア、ウィキペディア以外の姉妹プロジェクトのモバイル版がモバイルウェブ版からの説明を表示していないようです <設定コード(閲覧注意:重い)>。それでも、モバイルアプリ版ではウィキデータの説明文が挿入されているようですが… )。監視を強化するならガジェットなどでデスクトップウェブ版にも同様の説明文を挿入できるようにした方がいいかもしれません。あと、記載された tagline クラスをすべて消す場合、利用者ページに表示される登録年数も消えますし、wikidata の説明文だけが割り込んでいるとも言い切れずに意図しない不具合をもたらしかねないことから、現時点ではこの方法には反対します。 /* 検査用に wikidata の公開過去版全部に対する検査 SQL を走らせているものの、応答が返ってこない… */ --rxy会話) 2017年11月24日 (金) 14:14 (UTC) 下線部追記 --rxy会話) 2017年11月24日 (金) 14:39 (UTC) mw.config の wgWikibaseItemId がウィキデータの当該項目に紐づく ID になりますので、モバイルウェブから一発でウィキデータへ飛ぶためのリンク、または直接編集等の実装ハードルはさほど高くないように見えます (mw.config.get('wgWikibaseItemId');)。--rxy会話) 2017年11月24日 (金) 14:39 (UTC)
コメント トヨタ自動車朝日新聞社も荒らされていたのでrvvしておきました。こっち側で決めて良いのであれば、やめる事に1票とします。--JapaneseA会話) 2017年11月24日 (金) 01:02 (UTC)
コメント 日本語でのモバイル編集はいたずらが多く、まともな編集が少ないのでアレですね。しばらくreCH(termsをクリックしてjaでfilter)で監視しておく必要があるでしょう。--Afaz会話) 2017年11月24日 (金) 03:07 (UTC)
コメント モバイル編集と言ってもアプリなんですよねぇ〜。上でも述べられていますが、モバイルウェブでウィキデータを編集するとなると、モバイルビューからデスクトップ版に切り替え、サイドバーからウィキデータに飛ばなきゃいけないので、荒らしてる人もそこまでしてウィキデータを編集するとは思えません。ところがアプリだと、記事名の直下に「説明を追加」と言うリンクがあって、それをタップすると簡単な説明の追加が可能なんですが、それが実はウィキデータの説明欄の編集なんですよ…(私もアフリカ人、イクイアーノの生涯の興味深い物語で初めてやるまで気付きませんでした)。自分としては、モバイルビューでウィキデータの説明欄が表示されるのは便利で良いと思っているので、この機能の廃止には反対なんですが、前述のアプリでの編集機能を停止して欲しいとは思っているので、こちらを提案したいかなぁ〜、と言う感じです。--知識熊会話) 2017年11月24日 (金) 05:58 (UTC)
コメント そうなんですよね、問題の入力はモバイルアプリでありCSSで隠したところで意味がない、むしろ悪化させるだけ。ガジェット等でPCビューでも表示させて気付きやすく、編集しやすくすることは可能かもしれませんが……(もちろん別途ウォッチも必要として)--Hina会話) 2017年11月24日 (金) 06:51 (UTC)
User:Rxy/wikidata-description.js : 書きました。 mw.loader.load( '//ja.wikipedia.org/w/index.php?title=User:Rxy/wikidata-description.js&action=raw&ctype=text/javascript' );Special:MyPage/common.js に貼り付ければウィキデータの説明を読み込んできて H1 のタイトルしたに引っ付けます。私は本来フロントエンドの人ではないので古いブラウザーは無視します。chrome 最新安定板でしか保証しません。同一生成元ポリシー 鬱陶しい…--rxy会話) 2017年11月24日 (金) 16:19 (UTC)
あっ、ありがとうございます。 if(typeof data.entities[WikidataQID].descriptions.ja.value !== undefined)の部分が間違っているようですがざっと見た感じ大体どのブラウザでも普通に動きそうなコードですね。(CORSについてはorigin:*にしておくとオリジン違っても使いまわせそうで手っ取り早そう……) --Hina会話) 2017年11月25日 (土) 10:15 (UTC)
ご指摘ありがとうございます。修正しました。origin の処理は "mw.ForeignApi" を使えば勝手にやってくれるようでしたので、削除しました (mw:Manual:CORS)。credential (cookieとか)を送りたい場合は schema + FQDN な必要があって、それ以外なら * でも大丈夫そうですね。/includes/api/ApiMain.php--rxy会話) 2017年11月25日 (土) 13:44 (UTC)
  • 「目が行き届きにくい」「飛ばなきゃいけない」とのことですが、「ウィキデータを表示」する設定にすればかなり問題がなくなるのでは?[4](態々ウィキデータに見に行く必要はありません) --163.49.207.226 2017年11月24日 (金) 11:56 (UTC)
    • 当該の項目ですが日本語版ウィキペディアのウォッチリストには表示されていないようです。(ところでIP氏の提示されているリンクですが、細部以外の変更が選択されているためウィキデータの編集は表示されていません。) --Hina会話) 2017年11月24日 (金) 13:18 (UTC)
      • 環境によるのでしょうか? http://archive.is/9EJ50 で見ても細部の編集もウィキデータもありますが・・・。 --163.49.200.123 2017年11月25日 (土) 01:27 (UTC)
        • なるほど、新レビューツールでなければそうなるんですね。ログアウト状態でアーカイブのオリジナルのURLを開いたところ細部の編集を無視が選択されてませんでしたがログインしてると自動的に入りました……設定か / どのみち当該項目のログが出てるのは見つけられないのですが。 --Hina会話) 2017年11月25日 (土) 10:24 (UTC)
  • Wikipedia:井戸端/subj/モバイル版で記事名の下に表示される「ウィキデータの説明文」が荒らされるケース/IPユーザーによる説明変更一覧 いつぞやの時点までに IP 利用者によってウィキデータの説明が変更されたものの一覧です。ページ名も併記したかったのですが、応答が返ってこなくなるので諦めました。toollabs の複製 DB から抽出しました。公開版すべてが対象です。--rxy会話) 2017年11月24日 (金) 17:58 (UTC)

jawp側でモバイル版・アプリ版のそれを全て消す/隠すことができるなら良いのですが、アプリ版では消せない(?)のであればかえって監視が弱まるだけですし、現状、有効な対策としては「監視を強化する」ことだけでしょうか…。今はこの井戸端の話題があるので一時的に監視体制ができていますが、今後ずっと続けなければならないことを考えると、大規模な周知や、後々の利用者のための体制づくりが必要になりますね。--Hisagi会話) 2017年11月28日 (火) 16:02 (UTC)

  • 話題の全体像がつかめていませんが、この話は日本語版だけに関わる話なんでしょうか。またwikipediaへの引用をやめればという点については余計にwikidataの誤りが露見しにくくなり、wikidataのデータ信頼性がより悪化するように思います。アプリの機能は導入されてしばらく経ちましたが、導入時の案内にもあるように懸念点があるようであればmw:Wikimedia Apps/Short descriptionsのノートに課題・要望をあげるのも必要なのかもしれません。--115.39.11.17 2017年12月2日 (土) 01:53 (UTC)
コメント モバイル版にウィキデータが表示されているなんて知りませんでした。化学物質で当該ウィキデータをいくつか編集した記憶がありますのでそれらも表示されているということですね。どの記事なのかなんて覚えていません。日本語版でこれを表示する必要性があるのかも疑問です。テンプレートでもウィキデータは使ってますが世界に1つデータベースを設定すればすべての言語で利用できて便利です。荒らしは、ウィキメディア側が動いてくれないと難しいでしょう? -- signed by にょろん (会話) 2017年12月2日 (土) 05:04 (UTC)

日本独自の経済学運動による経済学の偏重について[編集]

経済学において、教科書と異なる内容の記事が日本語版wikipediaでは多いです。 特に日本独自の運動であるリフレーション関連の記事に偏重がよく見られます。

例1: reflationの記事
英語版  Reflation
日本語版 リフレーション

中には、学問上での重要事項よりリフレーション関連の情報が多くなり、辞書としての機能を損ねている記事もあります。
下記の例では記事の内容が実質金利の解説ではなく、リフレーションでの実質金利の扱いになっております。

例2: Real interest rateの記事
英語版  Real interest rate
日本語版 実質金利

対応策として、英語版の和訳に差し替えようと考えてますが問題ないでしょうか? --Nenemi4会話) 2017年12月4日 (月) 14:09 (UTC)

英語版ウィキペディアではなく、(英語でも日本語でもいいですが)経済学の教科書を参照して、それらを出典とした方がいいかと。例えばen:Reflationには全く出典がないため、翻訳してもウィキペディアで求められるWikipedia:検証可能性に合致しません。また、「リフレ派」の記述が多すぎるという場合、「リフレ派」による主張を消すのではなく反対派による反論や別の立場による意見を追加することがウィキペディアでは好まれます。その際も、どの学者・専門家が何と言ったかを記述することが重要です。 --163.49.206.59 2017年12月5日 (火) 06:33 (UTC)
コメント IP163.49.206.59さんの意見に賛同です。その上で補足を。私は英語記事を翻訳することが多いため、英語版と日本語版のギャップをよく目にします。Nenemi4さんの記述で2か所気になる点があります。1点目: 「偏重」というネガティブな表現に違和感を覚えました。日本語版は日本に関する記述が増えることは必然です。単に過去の執筆者が日本について詳しかっただけ。日本国外の状況に詳しい別の執筆者が新セクションを設けて追加執筆し、今後記事を育てていけば良い話だと思います。リフレーションであれば、第3節 日本に呼応する内容を第4節 アメリカ以降に追記していけば良いだけですので、「偏重」ではありません。Template:節スタブを挿入して、加筆者を募るという方法もあります。また、 のように、Template:See alsoTemplate:Mainなどを使って、日本国外の状況について詳しく記述している他言語記事に参照を飛ばすという手法もあります。このようにすれば、翻訳を手伝って下さる方が現れやすくなるという副次効果も期待できます。
2点目: 「辞書としての機能を損ねている」との表現も気になります。記事が育っていくと記事タイトルから派生した内容が盛り込まれやすくなります。派生内容が記述されたページ位置が不適切なだけであり、内容そのものは価値があります。ですから「損ねている」と否定するのではなく、Wikipedia:ページの分割と統合をまずは検討すべきではないでしょうか? --Mis0s0up会話) 2017年12月5日 (火) 09:19 (UTC)
提案 基本的には井戸端ではなく、まずは個別記事のノートページ (ノート:リフレーション等)で不備の指摘や改訂案の提示をし、執筆者らと意見交換するプロセスが肝要かと思います。特にリフレーションの記事はかなり内容も充実していて、出典もバラエティーに富んでいますから、過去の執筆者が相当の時間をかけたと推察されます。ノートページで合意形成なしのまま大幅に修正・削除をしてしまうと、編集合戦の対立が生じる危険性があります。
最後に蛇足ですが... 改行コードbrを使うべきではないところに使っていたり (詳細はWikipedia:改行時の注意点)、他言語記事へのリンクに外部リンクを使っていたりと (詳細はHelp:言語間リンク#言語間リンク)、スタイルガイドから逸脱した記述が見受けられたため、まずはWikipediaのチュートリアルにしっかり目を通すところから始めてみてはいかがでしょうか? --Mis0s0up会話) 2017年12月5日 (火) 09:19 (UTC)
IP163.49.206.59さん、Mis0s0upさんコメントして頂きありがとうございます。意見に従い、チュートリアルを見てから、経済学の教科書から参照していこうと思います。ただ一つ質問があります。経済学の教科書や観測された事実と、「リフレ派」の記述が異なる場合はどうしたらよいでしょうか?偏重としたのはこれが時々見受けられるからです。--Nenemi4会話) 2017年12月6日 (水) 00:11 (UTC)
そろそろ当該記事のノートで扱う内容になってきている気がしますが、解説節の最後のほうのことですかね? 基本的には、どちらの立場でも共通の認識が成立している部分を解説節に残し、解釈の違いがある部分を両論併記(たとえば固有語のような形)で記していけばいいのではないでしょうか。個人的には「観測された事実」というおっしゃり方に少し不安を覚えます。検証可能性に注意してご編集ください。--HANSON会話) 2017年12月6日 (水) 08:58 (UTC)

特定の災害などの犠牲者Categoryと没年Categoryの兼ね合い[編集]

Category:死因別の人物の中にはCategory:自然災害で死亡した人物Category:戦争・戦闘で死亡した人物があり、そこからさらに細分化された特定の災害や戦争による犠牲者のCategoryがあります。最近、その中の一つのCategory:震災死した人物の下位Categoryがある人物記事に没年Category付与したところ、別の方に除去されました。Categoryのページを見ると「Category:xxxx年没はいりません。」とあり、これを理由にした除去と考えました。しかし、そもそもこの記述の根拠はなんなのでしょうか。履歴を見ると今年、同一人物によって追加された説明でした。かといってCategory:洞爺丸事故の犠牲者Category:アメリカ同時多発テロ事件の犠牲者など年を跨がず発生した事件事故のCategoryにはその説明がなく、基準がわかりません。その方はIP利用者で半年近く編集されていないので返事があるのか不透明です。--Nuonuonuo会話) 2017年12月5日 (火) 18:33 (UTC)

津高和一Category:阪神・淡路大震災で死亡した人物でしょうか。利用者:Seibuabina様によりCategory:1995年没が除去されていますね。1年後に死亡する場合もあるので(意識戻らず長期入院で1年後に死亡)、完全な下位カテゴリとはならないと思います。「阪神・淡路大震災で死亡した人物」は該当者1名であれば、過剰なカテゴリとして削除すべきでしょう。なお、「洞爺丸事故の犠牲者」も「アメリカ同時多発テロ事件の犠牲者」も過剰なカテゴリに見えます。--JapaneseA会話) 2017年12月5日 (火) 20:19 (UTC)
おっしゃるとおり、津高和一における編集のことです。あの記事の編集者本人に突撃するわけもいかず他意もないでしょうからあえて伏せましたが、確かにCategory:阪神・淡路大震災で死亡した人物は1名しかカテゴライズされていないので過剰ともいえますね。この震災では元西宮市長の辰馬龍雄や地元出身の企業役員、大学教授などが亡くなられているんですが今のところそれらの人物の記事をつくる予定はありませんので増やそうにも増やせませんね。Category:アメリカ同時多発テロ事件の犠牲者は日本語版では4名しかカテゴライズされていませんが英語版では45名もあり、そこからさらに細分化されたCategory:United Airlines Flight 93 victims(ユナイテッド航空93便テロ事件の犠牲者)もあります。複数の他言語版に同様のCategoryがあるのは有用性を示す理由になるでしょうから削除までいけるのかどうか。
Wikipedia:過剰なカテゴリでは「項目数が少なく、成長の余地もないもの」を例として挙げていますが、震災も911も特筆性を満たす可能性がある犠牲者は存在するわけですから成長する見込みがないとまではいえないかもしれません。今のところそれらのCategoryを削除依頼にかけるかは他の方の判断に任せたいと思います。--Nuonuonuo会話) 2017年12月6日 (水) 16:01 (UTC)
コメント 本来的に「洞爺丸台風」とか「戦争」といったものは「死因」じゃないんですよね。交通事故は死に至る要因であっても、死因は「外傷性ショック」とか「失血死」などなんですから、「洞爺丸台風の犠牲者」でいえば、「洞爺丸台風によって沈没したxxxに乗船しており、死亡が確認されたあるいは行方不明等により死亡と判断された者」であって、溺死とかの「死因」にはならないんです。先にも述べられていますが、後年になってその災害等が原因で死亡するというケースもありますから、現状においても「xx年没」と「災害による犠牲者」は共存させられても、一方に内包できないと考えられます。極端な話、20xx年12月31日に起きた災害で受傷した人物が、翌年1月1日に死亡したなら「20xx年12月31日災害の犠牲者」であって、「20xx+1年没」の人物になるわけです。今のところ、「どうしなさい」という明確な基準はないですから、しっかりと「提案」という形にしてこのまま没年カテゴリ自体の運用方法について議論しても良いでしょうし、先に特定災害別の犠牲者カテゴリの要・不要を議論してもよいかと思います。--アルトクール会話) 2017年12月9日 (土) 05:37 (UTC)
アルトクールさんのしゃっるCategoryの運用方法、存廃議論のどちらから始めても自分は構いません。どうやら井戸端の議論だけでは収まらないようなのですが、どこか場所を移すべきなんでしょうか。問題になっているCategoryの上位Categoryのノート、つまり没年や死因別の人物のノート、はたまた関連するウィキプロジェクトであるおう人物伝やそのスタイルマニュアルで議論することなのか。こういった複数のCategoryにまたがる議論については経験が乏しいので意見をお聞かせいただきたいです。--Nuonuonuo会話) 2017年12月10日 (日) 13:03 (UTC)
コメント 提案の場所としてはプロジェクト:人物伝でしょうか。提案自体はプロジェクト人物伝における合意として私論以上、ガイドライン未満とするか、Wikipedia:存命人物の伝記のような方針・ガイドライン化を前提としたものとするかです。告知についてはWikipedia:お知らせWikipedia:コメント依頼で議論を通知するのが必要となると思います。Wikipedia:スタイルマニュアルはレイアウト関係なんでちょっと違うかと思います。
いっぺんに議論しても良いですが、その場合は「素案」が必要です。順番に解消するなら「死因別または災害別の犠牲者カテゴリの整理」→「生没カテゴリの整理・付与について」で提案をしていくことになろうかと思います。このまま、この井戸端ログに提案セクションを置いて、PJ人物伝に読み込ませる(終了後はリンクにして過去ログ扱いにする)方法もありますので、そのあたりは提案者の好みになるでしょうか。--アルトクール会話) 2017年12月10日 (日) 13:42 (UTC)
提案したページをプロジェクト‐ノート:人物伝に参照読み込みさせる方法をとってみました。優先される議論としてはCategoryの運用方法でしょうか。存廃問題は仮に削除依頼に出すことになってもそこからある程度は時間がかかってしまうでしょうし。--Nuonuonuo会話) 2017年12月10日 (日) 14:53 (UTC)
コメント まずは「Category:死因別の人物を整理するところから始めてはどうでしょうか。カテゴリのいう「死因」とは何を基準とするのか、それが決まれば配下となるカテゴリの整理も付きやすくなろうかと思います。結果として「未使用になったカテゴリ」があれば削除に書ければよいだけです。--アルトクール会話) 2017年12月14日 (木) 10:06 (UTC)
(インデント戻す)死因別の人物を見てまず気になったのはCategory:獄死した人物ですね。刑務所などの犯罪者収容所施設で亡くなった人物のCategoryですが、獄死って病死も多くて拘束されたせいで死んだわけではない人物の死因とするのはどうなんでしょうね。死因じゃなくて死没地のCategoryと化しています。下位のCategoryのホロコースト犠牲者は収容所で劣悪極まる環境に置かれたせいでしょうから間違ってはいませんが。
ざっとみたところ日本限定のCategory以外は他言語版にもあるものばかりです。日本語版独自のCategoryで記事数が10未満のものは既に挙がっているもの以外だとCategory:阿波丸事件の犠牲者、Category:競技中に死亡したオートレース選手、Category:競技中に死亡した競輪選手、Category:東北地方太平洋沖地震で死亡した人物、Category:流産・死産した人物がありました。--Nuonuonuo会話) 2017年12月15日 (金) 11:13 (UTC)
余談になりますが、「Category:流産・死産した人物」は、早世した側をカテゴライズするようですが、誤って存命人物の母親をカテゴライズしないか非常に心配です。また、母親が存命人物の場合、早世した側さえもカテゴライズすべきではないでしょう(現状カテゴライズされている記事は、母親も全て死去している事を確認しました)。--JapaneseA会話) 2017年12月15日 (金) 11:27 (UTC)
生まれた瞬間から特筆性が発生する人物って王族皇族でもないと現代では考え難いので、存命人物とはいえ公人なので母親側はどうなんでしょうね。特殊な病気にかかった嬰児や胎児やその親の記事はあってもおかしくはなさそうですが。--Nuonuonuo会話) 2017年12月15日 (金) 13:10 (UTC)
コメント 母親側にはCategory:難産死した人物というカテゴリがあるので、出産時に死去した人物はこちら側に収録されています。扱いに注意さえすれば問題ないでしょう。ちなみに、Category:流産・死産した人物は早世(夭折)した人物を収録しているわけではなく、あくまで「出産時までに死亡した状態の人物」を収録しているので、その点も注意を促す必要があるかもしれません。「xxした」の「した」が誰にかかるのかを、カテゴリの説明に記載すれば避けられる問題です。--アルトクール会話) 2017年12月15日 (金) 14:50 (UTC)

同姓同名かつ分野も同じ人物の記事名のルールは[編集]

作新学院大学の編集をしているときに気がついたのですが、現学長の渡邊弘氏(教育学)とは別人の教育学者の渡邊弘氏(鹿児島大学、[5])が存在するようです。通常であれば「(教育学)」あたりで曖昧さ回避をするところですが、分野まで同じとなると、どうしたものやら……。もし今後鹿児島大の渡邊氏の記事を立項する場合、どのように記事名を区別すれば良いかの基準が分かりません。生年で、とも考えたのですが、なかなか厳しいように思います。皆様のご意見をお願いします。--Doripoke会話) 2017年12月6日 (水) 15:21 (UTC)

分野を細分できないなら、生没年が一般的では?
……とか。適当な例がすぐに思いつかないのでカテゴリ内おまかせで拾ってきましたけど、すぐに見つかる程度にはありましたし。--Hisagi会話) 2017年12月6日 (水) 15:56 (UTC)
コメント 一般的にはHisagiさんの意見に賛成しますが、もし調べがつかないようであれば一時的にでも現状はっきりしている在籍地で分けるしかないのでは。--Hiroes会話) 2017年12月6日 (水) 18:47 (UTC)
コメント リンク先を確認しましたが、鹿児島大学の方は「教育学修士」をもっているだけで専門は「法学」のようです。教育学と法学で曖昧さ回避できるでしょう。また、一般論でいうなら分野が重複した場合、さらに細かい分野分けでの曖昧さ回避をしてもよいかと思います。--SilverSpeech会話) 2017年12月7日 (木) 00:34 (UTC)
今回は分野が違うということで決着しそうですが、大学の先生は別の大学に移ることがありますので在籍を曖昧さ回避にするのはマズいかもしれませんよ?--KAMUI会話) 2017年12月8日 (金) 12:31 (UTC)
  • 皆様、ご意見ありがとうございます。鹿児島大の渡邊先生は、法学というよりも法教育がメインのテーマになっているようで、執筆誌や過去の担当講座、講演可能なテーマや役職等を見ても、やっぱり大きな括りでは教育学者になるんじゃないかと思います。生年(or生没年)が第一の選択肢になるようですが、これはケースに応じて当てはめていくしかないんでしょうね。--Doripoke会話) 2017年12月17日 (日) 13:58 (UTC)

記事の一部を分割したテンプレート[編集]

IP:240f:7:162b:1:4867:fe9c:a11b:60a2ノート / 履歴 / ログ / Whois IPv4IPv6さんやIP:121.108.122.224ノート / 履歴 / ログ / Whois IPv4IPv6さんが全日本吹奏楽コンクールで課題曲一覧などを分割してテンプレートにしています(例:{{全日本吹奏楽コンクール/課題曲参考演奏}}、{{全日本吹奏楽コンクール/課題曲一覧/1940}})。分割の手段としてテンプレートを使うのは良い方法になりうるのでしょうか。また、ギリシャ神話の英雄の系図のようにいくつかのテンプレートをまとめて一覧記事としてもよいのでしょうか。--プログラム会話) 2017年12月6日 (水) 17:15 (UTC)

コメント テンプレートについての説明はHelp:テンプレート早わかりに在る通り、「同じ説明やデータ一覧を呼び出す際に手順を簡便化するために作成するもの」なので、用法自体は間違ってはいないです。
ただし、この2テンプレートは内容が「どこの誰が何の情報を元に書いたのやら、内容信頼性が一切皆無の無出典記述(全文が公式三大方針WP:V違反状態)」ですので、場合によっては「呼び出されるたびに呼び出し元記事の信頼性を引き下げる結果を生む」ので削除依頼が必要かもしれませんし(WP:DEL#Z)、分割手法としても、本来的にはWP:MMに従い議論と合意必須な分割手順の抜け道的に、個人の独断でこのように安易に記事の解説内容をテンプレート化すべきではない、と思います。
ギリシャ神話の英雄の系図の問題点は「1ページ内のテンプレート使用回数が既定値を超えていること(Help:テンプレートの制限)」なので、この記事内容を全部まとめてテンプレート化しても何の解決法にもなりません(テンプレート使用数が更に増えるだけ)。この記事の場合は{{familytree}}を改造するか、用法を変えるべきなんじゃないかな、と思います。──手っ取り早いのは{{familytree}}の使用部分を、テンプレートを使用せずに表示状態を同じスタイルシートやテーブルで置換すること(例えばsubst展開)でテンプレート使用総数を減らすと、ページ下部まで正常に表示されるようになると思います。…あるいは、系図ごとの単独テンプレートの内部をそのように変更すればページ容量をあまり増やさずに同様の対策が採れるかもしれません(こういうのはPJ:技術部の管轄なんじゃないですかね?)。--Nami-ja (会話 / 履歴) 2017年12月7日 (木) 17:54 (UTC)
コメント {{全日本吹奏楽コンクール/課題曲一覧/1940}}のような創作性の介在しないような単純なデータリストなどであれば(編集方針上の適否は置いといて)著作権やライセンス上は問題ないとは思いますが、{{全日本吹奏楽コンクール/課題曲参考演奏}}はそれなりのボリュームの文章ごと複製してあるのでライセンス的にアウトではないかと。元の記事(全日本吹奏楽コンクール課題曲音源)からテンプレートへは履歴継承ができていたとしても、テンプレートの仕組み上、呼び出された記事(全日本吹奏楽コンクール)側でテンプレートの履歴が継承されないので。
Template名前空間への投稿についてはシステム上、記事名前空間への呼び出し時に履歴継承されないことを了解の上で投稿しているとみなしてセーフ扱いにしているはずなので、テンプレート同士の切り貼りであればテンプレート間の履歴継承さえできていれば大丈夫ですが、記事や他の名前空間からTemplate名前空間への文章転載は軒並みまずいかと。--ディー・エム会話) 2017年12月7日 (木) 18:09 (UTC)(一部訂正--ディー・エム会話) 2017年12月7日 (木) 18:26 (UTC)
  • コメント私もノート:全日本吹奏楽コンクールにて、このテンプレートについて疑問を表明したところでした。せっかくテンプレートで呼び出してるのにデフォルト折り畳み状態だと存在そのものに気付かないことも多いみたいで(私の投稿履歴を確認しもらうと、駅記事の乗降人員の表の更新が特に折りたたまれた表で滞っていることがわかるかと思います)、それならば{{Main}}で課題曲一覧に誘導するだけにしたほうがいいのかなとも思います。ギリシャ神話の英雄の系図についていうと、それぞれの系図については該当の記事にそれぞれ呼び出しているようなのでテンプレート化するメリットもありそうですが、吹奏楽コンクールの分割された各パーツについてはほかの記事で再利用する当てがあるのかな、とも思います。ノート:全日本吹奏楽コンクールでの議論が特に進まなければ試しに記事に誘導する形に置き換えてみようかなとも思います。--VZP10224会話) 2017年12月8日 (金) 23:10 (UTC)
  • テンプレート化するにしろ直に書くにしろ、一つの記事内に長い一覧を見せること自体を再考すべきではないかと思います。単純除去に抵抗があるのであれば、一覧記事として分割する方法はどうでしょうか(念の為ですが、分割したものを埋め込んでは全く意味がないので、埋め込みではなく本体から一覧へのリンクを貼ることになります)。なお1つの記事でしか使わないのであれば、テンプレート化は本末転倒です(複数の記事で同じことを書く手間を減らすのが本来の目的でしょう)。 --163.49.213.64 2017年12月9日 (土) 02:55 (UTC)

報告 先ほどWikipedia:削除依頼/「Template:全日本吹奏楽コンクール」のサブページを提出しました。--プログラム会話) 2017年12月9日 (土) 18:26 (UTC)

年の表記は昇順か降順か[編集]

  • コメント 賞金ランキング (囲碁)#賞金ランキングのような年表を昇順にするか降順にするかという話です。Wikipedia:利用案内#昇順か降順かにて質問したのですが、決まったルールは無いとの事です。議論が拡散して申し訳ないのですが、Wikipedia:利用案内#昇順か降順かを御覧になられてからコメント頂ければ幸いです。--JapaneseA会話) 2017年12月7日 (木) 21:10 (UTC)
  • コメント 元議論を拝見しますと、結局記事・記述が求めるその表の目的によって個別に決めるものと結論付けるしかなさそうです。その上で何を聞きたくて本項を立てたのか、もう少し明確にして下さい。--mit freundlichem Gruß LudwigSKDiskussion/Beiträge) 2017年12月8日 (金) 01:12 (UTC)
  • コメント 並べ方の順序にそれぞれ利点が在るならば、表自体を sortable wikitable タイプに変える方法もありますね。──(表の順序を並べ替え可能なのに)昇順/降順のどちらかに決着しなければならない、という意味合いの議論ならば、利用者同士でウィキペディア上に在る前例を持ち寄っても(所詮、ウィキペディア編集者のその記事での必要の結果であり絶対的な指針には成り得ない理由から)永久に水掛け論でしょうから、論拠と成るべき何らかの依拠可能な(ウィキペディア外での研究書や事例集といった)参考文書が在ると議論が進みやすいかな、と思います。
    (以下蛇足)ご提示の一覧は、125%拡大しても色潰れで部分的に判読不可能という。とりあえず、その一覧表はWikipedia:色の使用Wikipedia:色のコントラストを暗唱できるまで熟読して頂いた上で図表全破棄を提唱したいですね。色弱者に喧嘩売ってるとしか思えませんけども。--Nami-ja (会話 / 履歴) 2017年12月9日 (土) 04:43 (UTC)
    • コメント要するにJapaneseAさんが降順の表もあるのに見たことがなかったてだけでしょ?自分の経験だけで判断してはいけません。さらに前も書きましたがsortableはモバイルビューでは使えません。もう一度説明するとこの記事は一番その時に読まれる最新の行がすぐ見られること、開始年が判明しないことを理由に降順を選びました。
Nami-jaさんのご意見に答えますと棋士の数が多いので使える薄めの色がもう選びようがないんですよ。ていうか私は囲碁のタイトル在位者一覧を参考にしてさらに見やすいように配色し直したんですよ?これでもかなり見やすくなってるはずですが--木下源造会話) 2017年12月9日 (土) 07:03 (UTC)
コメント 蛇足の続き ええ、一瞥して「頑張ったな」というのは「編集者としてはよく伝わる」んですが、「読者視点ではとてつもなく読みづらい、読めない」んですよ…。Wikipedia:色のコントラストをご一読頂きたいのですけども、「正常な色覚を持っている方が分かりやすくするつもりで配色したセルの内容を、正常に認識出来かねる障害者は一定数居るのだ」という事実自体に配慮して頂きたいな(WP:COLORWikipedia:配色の変更は控えめにHelp:配色のコントラスト比)と、そういうお話です。 / 謝依旻 よりも謝依旻[女]大竹よりも大竹[注釈1]とかの方が分かりやすいし楽だと思いますし、この図表を見て色だけで「依田名人は何回表示されているか」を把握するのは著しく困難かと存じます。--Nami-ja (会話 / 履歴) 2017年12月9日 (土) 12:07 (UTC)

提案 セクション名「年の表記は昇順が降順か」という一般論から議論が派生し (最初に脱線させたのは私ですが)、賞金ランキング (囲碁)#賞金ランキングの表の見せ方という個別論になっているので、ノートページで議論しませんか? 私もNami-jaさんのご意見に賛同です。ですがノートページ上で具体的な表レイアウトのコードを書いてあれこれ議論した方が、具体的なアクションにつながりやすいと感じます。または一般論として議論するのであれば、「表の色について」というセクション名で井戸端に別途立てるか。

また、元々の利用案内ページで昇順/降順議論が相当進んでいますので、こちらの井戸端ページは案件クローズにしても良いのではないかと思います。質問主のJapaneseA、いかがでしょうか?--Mis0s0up会話) 2017年12月10日 (日) 02:17 (UTC)

井戸端にそのまま移動して欲しかったのですが、そうはならなかったようです。後は利用案内でコメントした通りでございます。--JapaneseA会話) 2017年12月10日 (日) 03:42 (UTC)

報告 上記の話題のうち、図表の改訂提案は現在はノート:賞金ランキング (囲碁)に議論の場を移しています。--Nami-ja (会話 / 履歴) 2017年12月13日 (水) 04:58 (UTC)

報告 利用者:木下源造会話 / 投稿記録 / 記録利用者:Abtelp会話 / 投稿記録 / 記録さんのソックパペットとして無期限ブロックされました。現在は更に別の靴下が出現し、記事は保護依頼に提出されています。--Nami-ja (会話 / 履歴) 2017年12月17日 (日) 04:01 (UTC)

改名時のノートの処理[編集]

映画の記事「〇〇〇」と、曲の記事「〇〇〇 (曲)」という記事があったとします。2者は全く関係がなく、たまたま同じ名前です。「ノート:〇〇〇」にて議論をし「〇〇〇」を「〇〇〇 (映画)」に改名し、跡地は平等な曖昧さ回避とします。ここまではよくある話です。議題としたいのは、「ノート:〇〇〇」の扱いです。慣例ではこのパターンの議論しかない場合は、ノートは移動せずというケースをよく見てきました。しかしノート:ひかりのまちにて、「移動済ノートを使用すべき」という旨の意見が出ました。「移動済ノート」は、このパターンの改名議論以外の、他の議論もノートに記載がある場合に使用すべきだと思います。さて、どちらがベストなのかコメント頂きたく思います。--JapaneseA会話) 2017年12月7日 (木) 22:31 (UTC)

  • コメント 個人的にはどっちでもいいと考えます。「議論の経緯をどこに置くか」なんていうまったく本質的でないところにリソースを費やすのがいちばん無駄だと感じます。--Jkr2255 2017年12月7日 (木) 22:41 (UTC)
  • コメント ベストな方法、というか提案の終了に最速なのは「ノートページの移動を禁じたり、正当な議論保存場所を制定している方針ガイドラインは(現時点では)存在しない」し、移動元ノートページに{{移動済みノート}}を置いて誘導する、というのであれば「ノートを閲覧した閲覧者が過去の議論に気づかない可能性は限りなく減じられる」ので、「ノートでの議論の痕跡を残す『正当な』場所はどこで在るべきか」といった「未だ存在しない方針ガイドラインの制定(主提案から派生した枝葉)にリソースを割く時間は蛇足に過ぎる」ように思われます。
    …問題点を切り分けるならば、「(現状では)ノートページの移動を禁ずる方針ガイドラインはない(どこに在っても良い)」ので依頼者の提案通りに移動しても良い(ルールに反するような重大な問題はない)、移動終了後に別提案として然るべき場所で「主題と目されるページのノートに議論場所を統一する提案をして別途議論、合意を目指す」といった形になるのではないかな、と思いました。
    ◆少なくとも、議論保存場所の正当なページについての話題は、移動提案を妨げる理由としては限りなく弱い、と思います。現時点ではルールに依拠出来ませんし、提案者が明文化されていない「これから策定する未来のルール」に従わねばならない方針ガイドラインも存在しておりませんから。--Nami-ja (会話 / 履歴) 2017年12月9日 (土) 05:16 (UTC)
Symbol comment vote.svg 追記 現時点では議論参加者の合意がノートは残す方向に傾いているので、其れはWP:CONSが適切に成っている状態であり、そちらも合わせて「誰もルールを曲げていない正常な議論状態」かと存じます(お話の中に無い、別の問題点は一先ず置いておくとして)。--Nami-ja (会話 / 履歴) 2017年12月9日 (土) 05:21 (UTC)

Jkr2255さん、Nami-jaさんのコメントに感謝致します。議論立ち上げ人が挙げている改名提案の提案者ですが、正直ここまで些末な事に口を挟まれる事に対して、「{{移動済みノート}}を用いて議論内容が途切れないようにすると明言しているのに何故このような些末な事にこだわり口を挟むのか」と理解に苦しんでおりました。立ち上げ人におかれましては、井戸端での他の議論内容もJkr2255さんが挙げておられる自転車置き場の議論そのものであることを改めて指摘申し上げますとともに、「木だけを見て森を見る事ができないのであれば安易な議論への口挟みは自重する」事を心掛けて頂けましたらと進言申し上げる次第です。--Ohtani tanya会話) 2017年12月12日 (火) 20:38 (UTC)

コメント 氏の会話ページへ。--JapaneseA会話) 2017年12月13日 (水) 01:06 (UTC)
と思いましたが議論が拡散するので。私は、賛成票のついでに「ノートは移動しない」事を提案したのです。私から見れば、それに対し貴方が「些末な事にこだわり口を挟」んだように見えます。井戸端での提起は、貴方を利する善意ある行動だという事が全くわかっていないようですね。井戸端で提起しなければ、各議論で決める事になり、私が移動に反対している以上、それをよほど上回る移動賛成票がない限り、合意不成立となり移動はできません。それでは現状の記事名(ノート名)優先となりフェアではないので、提起したのですが。その善意に対する返信が上記コメントとは非常に残念に思います。どちらが「木だけを見て森を見る事ができない」のか、どちらが「自重」すべきなのかはコミュニティが判断するでしょう。なお、これ以上の反論には返信はしません、建設的な提案があればノート:ひかりのまちにて御願いします。--JapaneseA会話) 2017年12月13日 (水) 01:25 (UTC)

コメント 皆様、コメントありがとうございます。井戸端に提起したのは、こんな瑣末な話はどっちかに決めておけば、その後揉めずに済むと思ったからです。なお、記事自体の移動には私も賛成していますし、(7日以内に記事の移動に反対がなければ)ノートをどうするかと関係なく、移動して良いとも意見を述べています。--JapaneseA会話) 2017年12月13日 (水) 01:25 (UTC)

コメント 正直言って、ことさらに決めるまでもなく、通常の改名提案と同じルールを敷衍すれば、「ノートの移動位置に合意が得られなければノートは放置」という結論となるわけで、それで特に問題ないのかなとは思います(記事の状況に応じて適切なノートの位置は変わると思いますので、合意が優先でしょう)。--Jkr2255 2017年12月15日 (金) 13:20 (UTC)
  • 賛成 某掲示板から来ました。JapaneseAさんの「ノートは移動しない」に賛成します。--塩戸真珠会話) 2017年12月15日 (金) 13:12 (UTC)

自身の会話ページに返答を返さない場合は常に対話拒否とみなされるか?[編集]

本来無関係だったはずの方に横からブロック依頼を提出してしまった事が発端となり、現在私の会話ページにおいてこのような事態となってしまいました。本件については激しく後悔しており、正直これ以上関わり合いになりたくはないのですが、何か答えないと対話拒否という事になってしまったりするのでしょうか?--Hiroes会話) 2017年12月9日 (土) 07:46 (UTC)

ご自身の行為によってウィキペディア日本語版やそのコミュニティ、プロジェクト目的遂行にあたって損害をもたらすことが予見される、または実際にもたらした場合、それに対する説明を行わなければ対話拒否とみなされることがあります。しかしながら、本件では Hiroes さんによる本件ブロック依頼は依頼文に経緯とブロックの必要性について記載が乏しかった点があるとはいえ、本件依頼はウィキペディア日本語版コミュニティにとって益となっているように私は思いますし、本件利害関係者による方針上問題のある投稿であるため、ご返答いただく必要はないと私は考えます。時間は貴重で不可逆なものですので、ご自身にとって有意な使い方をなさってください。--rxy会話) 2017年12月9日 (土) 08:11 (UTC)
コメント 結論を言えば対話拒否にならないでしょう。対話拒否とは、単純に返事をしないのではなく、対話を拒否して同じ問題(あるいは行為)を繰り返す事だと理解しています。対話に応じても同じ事を繰り返せば、実質的な対話拒否となります。また、誰がどう見ても正しい事をするのであれば、相手の意見を無視しても、それは対話拒否とはならないでしょう(例えば、荒らしの巻き戻しと、それに異を唱える荒らしからの会話)。審議を見るに、間違ったブロック依頼を出したようにも見えないので、気にされる事はないと思います。なお、ブロック依頼は自分しか出す人がいない場合もありますが、大抵は誰かが出してくれますので。--JapaneseA会話) 2017年12月9日 (土) 08:22 (UTC)
了解しました。お二方ともありがとうございました。--61.207.218.157 2017年12月9日 (土) 08:27 (UTC)--Hiroes会話) 2017年12月9日 (土) 11:29 (UTC)

産経新聞の信頼できる報道機関としての評価について[編集]

かなり驚いた記事から以下の問題提起について、ここで皆様のコメントを頂きたいと思います。
問題は流行語大賞に選ばれた「忖度」なる言葉から天啓を受けて、ファミリーマートで発売された忖度弁当の記事になります
産経新聞ではこの忖度弁当がほとんど売れず廃棄になっていると、ファミリーマートの広報でもなく、不明確な匿名のツイッターから情報を引用して伝えているのです。当然、匿名ですから身分も詐称している、可能性のあるネガティブキャンペーン的な情報を流す危険性を孕んでいる場合もあります。さらに後続の文では、バイラル系列のまとめサイト[1]とされる品質が低いNETGEEKの勝手な評価を「忖度というネガティブなワードがマイナスイメージを誘う上、値段が高すぎる」と著名な識者のように語るのはあまりにも、信頼性のある情報機関としてあるまじき態度ではないでしょうか。足を使わず適当に偏向したネットの情報を切り貼りするのは、産経のジャーナリストの価値は何なのか疑いたくなりました。 さらに「ユニー・ファミリーマートホールディングス」は市場の東証1部として上場しており、不明瞭で合理的ではない情報をマスメディアがさらっと流すの、やはり業務妨害として、風説の流布に当たるのではと、訝しむ次第です
検証可能性のガイドラインの通常は信頼できないとされる項に「一般に、信頼性に乏しい情報源とは、事実確認について評判がよくない情報源、あるいは事実確認の機能を欠く情報源(「TVで観た」や「ラジオで聴いた」など)、または編集上の監督を欠く情報源です。」と掲載されてます。
それ以前これを特例的に信頼できると認めた場合でも、孫受け状態になっている気がします。SNS、まとめ→産経→wikipediaなので。 jawpでは「産経新聞」は一応、信頼性の高い報道機関として、多数の記事の出典として使用されています。ですが、上のような不合理な行動を見ているとマスゴミなんて言葉もありますが、産経のゴシップ担当であるzakzakと同じような報道を高級紙である、産経が並列していると、さすがにjawpの信頼性のある報道機関として相応しくない、もしくはzakzakと同じゴシップ扱いを免れないのではと考えるようになりました。過去の井戸端を参照すると、アルトクールさんが夕刊フジに対してWikipedia:信頼できる情報源Wikipedia:検証可能性Wikipedia:中立的な観点という記事を書く上で必要な三大方針を読み込めば、「夕刊フジは信頼できる情報源であるとは言えないはず]とブロックされたはるみエリーに、夕刊フジは適切ではないと叱責なさっています。信頼できない出典のSNS、まとめサイトを二次にした産経新聞はその夕刊フジと同じ振る舞いをしているため、正直タブロイド扱いすべきか他の高級紙と情報が一致した場合のみの出典を許容すべきと思っています。もちろんこの記事に限っての場合だ、その場合は使わなければ良いなどの意見もあるとは思いますが、他にも不明瞭なSNSやゴシップ以下である、まとめのネットギークを論拠した記事があり

蚕食的に使用してるのを見ると、無言の引用で毒饅頭を食わされることになりそうなのが、気がではないのです。
その事例として、「ミサイル発射は安倍首相のせい」の文言確認できず 産経の見出し不正確などがありますが、ツイッターを確認すれば嘘か誠か判別できるレベルを偏向を見出しにする辺り、この手のまとめサイトを論拠にしているのではと疑惑が尽きません。ですので、ネットギークやその他のサイトであると明記した時だけ、除去すべきという理論が成り立つのかは疑問視されるでしょう。この事例を踏まえた上で、皆様に産経新聞が信頼できる報道機関であるかの意見を拝聴したいと思います。
投稿ブロック依頼/深見東州記事、政治家記事を中心とするミートパペット群のブロック依頼でも、産経系列の出典を起用するコミュニティ消耗者が多数居ましたので、この井戸端はjawpの信頼性足る情報整理になると思われます。--お相撲サンバ会話) 2017年12月10日 (日) 04:58 (UTC)

脚注
  • 「ネット上でこういう話題があった」という趣旨の記事に対して、「ネットの情報を情報源にするのはけしからん」というのは、そもそも情報源評価としておかしいです。 まして他の記事も(それこそ政治部や社会部の記事も)、だから全部信頼性が低いというのは、論理の飛躍かと存じます。これは別に産経にかぎらず、朝日だろうと読売であろうと、信頼できる情報源とされる媒体だからといって、そこの記事を無批判に事実として引用しても良いことにはならないというごくごく基本的な話で、実際、ネット上だの、世間の声だのと、聞いたこともない国民の声の記事なんていくらでもあるんですから。アベるなんて良い例です。--EULE会話) 2017年12月10日 (日) 05:54 (UTC)
  • WP:RSは何か、WP:NOTRSは何か、という話になりますね。夕刊フジのように自らを大衆紙と名乗ってくれれば「WP:NOTRS」確定ですが、そのように名乗っているケースは少ないと思います。にも関らずスポニチとか週刊文春とかが「WP:NOTRS」とされるのは、複数の情報源で「大衆紙」と評価されているからでしょう。一方、産経新聞や朝日新聞を「WP:RS」とするのも複数の情報源で「ゴシップ誌ではない真面目な新聞」と評価されているのでしょう。この「複数の情報源」を誰も探していないのは、探せば見つかるだろうけど、誰も異を唱えないからだと思います。産経新聞を「WP:NOTRS」にするのであれば、真剣に産経新聞を評価している「複数の情報源」を提示する必要が出てきますが、多分やるだけ時間のムダになるでしょう。なお、WP:RSだとしても、報道は必ずしも事実として扱うべきではなく、特に批評は帰属化(産経新聞は~と報じている)する必要があります。ちょっと余談になりますが、私は産経自体よりも、産経に書かれている発言全てを引用して自身の政治主張を行っているとしか思えない点によほど問題を感じています(ダメな例:〇〇は「~で~だから~であるべきなのに~だ」と反対している。本来:〇〇は反対している)。--JapaneseA会話) 2017年12月10日 (日) 06:42 (UTC)
  • 返信 おかしいなと思ったところには、適宜質問させて頂きます。利用者:EULE会話 / 投稿記録 / 記録>ネット上でこういう話題があった。タイトルで煽り、中身は別物というのががゴシップの様態では?バイラルメディアと行動が一緒でしょう。ですから申しているんです。>だから全部信頼性が低いという。誰も言っていません。そもそも、全部の信頼性が高い訳ではない→だから高級紙扱いすべきだ。にはならないと思います。その理屈だと全て出典が使えるのでは?ゴシップにしろまとめにしろ100パーセント正確で100パーセント間違っているなんて、そりゃありませんよ。あの虚構新聞ですら事実を報道しているのですから。私が言って居るのはその中で、jawpの規約に沿うマシか否かの話なのです。>実際、ネット上だの、世間の声だのと、聞いたこともない国民の声の記事なんていくらでもあるんですから。具体的にお願いします。読売、毎日、朝日。産経を入れれば、産経を入れれば、高級紙天王とでも言いましょうか。どの紙のどの部分のことでしょう?例に出された、アベるは調べた所良く分かりませんでした。アサヒるというネットの洗礼を受けたのは理解できますが。産経も同じ目に逢えと?結局、他の紙もやってるんだからに演繹する理論はちょっとズレてません?少なくともまとめサイト的なバイラルメディアを論拠にした高級紙はこれが初めてなんじゃないですかね。その点が、下部ゴシップメディアのzakzakと産経の振舞いはゴシップなのではないかと引っかかっているのです。引き続きお願いします。--お相撲サンバ会話) 2017年12月10日 (日) 11:30 (UTC)
  • 返信 おかしいなと思ったところには、適宜質問させて頂きます。利用者:JapaneseA会話 / 投稿記録 / 記録>>報道は必ずしも事実として扱うべきではなく。つまり仮に前置き、産経が~と帰属すれば、誤報だろうが捏造だろうがOKになるのでしょうか。それを無視しても、産経を出典を使った場合、8:2の割合だとかjawpの政治系の記事の比重が重すぎる場合もありますね。偏り的にも。あぁ、ガイドラインにはWP:SELFSOURCE「すべての報告は、作成した過程や人々に関する検証が必要です。」上の問題を引用すれば、ゴシップに近い様態なんですけど、それでも検証せずに使うのですか?反しているのに使うしかないって言うのは、ガイドラインの形骸化を推し進める容認に見えます。ガイドラインって都合よく無視されすぎる事例が多い気がします。コミュニティを消耗させる人物もこの動きが顕著でした。あぁ、他にも「政党や宗教団体のウェブサイトや出版物は、政治的主張や宗教的信条が含まれていなくても注意して扱うべきであり、情報源として使わない理由になります。」なんてのもありました。wikipediaは面白いですね。ところで、高級紙が高級紙たる持論はなんでしょう?「編集者は複数の情報源の信頼性を評価し、できる限りより信頼でき、よりすぐれていると一般に認められているものの中から、出典を幅広く選ぶようにして下さい。」と明大的書かれていますが、一般的に認められいるということはどれだけ、万人に購読されているかなんでしょうか。あぁ、でも産経は朝日より購読数が下でしたね。この場合、朝日より劣るってことになるんでしょうか?--お相撲サンバ会話) 2017年12月10日 (日) 11:30 (UTC)
お相撲サンバ様へ。誤報や捏造だとはっきりしているものについてはその限りではありません(これこそが「すべての報告は、作成した過程や人々に関する検証が必要です。」です)。「8:2の割合」とは何の事ですか?「産経は政治系の記事の比重が多すぎる」、Wikipedia内の政治系の記事に産経の出典が多い、という事で宜しいでしょうか?で、あれば観点タグを貼るか、他の出典を使い加筆するか(Wikipedia:中立性)、どうでも良いものは除去するか(WP:IINFO)という対処をすれば良いと思います。産経は「政党や宗教団体のウェブサイト」ではありません。後は上で述べた通りです。このように個々に質問をすれば、個々に返答が返るでしょうが、特定の人だけが延々と議論すると新たな参加者が議論に参加しづらくなりますよ。ある程度待ってから質問した方が良いでしょう。--JapaneseA会話) 2017年12月10日 (日) 11:44 (UTC)
>>だから全部信頼性が低いという。
>誰も言っていません。
断言的になってしまったので言葉のチョイスを誤ったとは思いますが、でも氏の言ってる内容はそういうことなのですよ。つまり、WEB版の固有記事がゴシップ的だから、産経新聞はゴシップ紙とみなすべきだ。それってつまり、大手紙のメインである(そここそウィキペディアで最も引用されるであろう)政治部や経済部、社会部の記事も信頼性が低いものと見なせと言っているのと同じなのですから。でも、そうやって猛反発なされるということは、氏は政治部や経済部、社会部といった大手紙が大手紙と呼ばれる所以のメインの記事の信頼性は認めているということでよろしいのですか?--EULE会話) 2017年12月10日 (日) 13:09 (UTC)

複数依頼のまとめ化と長期化の関係性[編集]

現時点で提出中の25件の削除依頼まとめと、今後提出すべきかどうか思案ちぅのとあるブロック依頼提出済みな利用者の行動履歴に関して現時点で判明している削除依頼が必要そうな複数案件について、提出案件の精査、まとめ中にふと思った疑問点なのですけども。──何年か前から思っていたのですけども、10件、20件と複数の依頼案件をまとめて提出すると「各案件の問題点の有無をダブルチェック、トリプルチェックした上で審議参加する編集者の時間をそれなりに奪う」ことから、長期化案件になりがち、ですよね。

これまでは『(何の依頼案件でも)まとめられるならまとめて提出した方が(誰もが)楽』と考えてましたけども。…削除実施者の管理者さんに「審議合意成立後に(最初に依頼者が個別に事細かく問題点について精査した上でなければ、方針違反であり)削除実施出来ない」と苦言を言われました過去もあったりしまして(これは提出時点で依頼者もかなり乱暴な手順であることを認めているのですけども)、もしかすると依頼者だけが楽な依頼提出方法なのかもなあ? などと考えたりもしまして(その後提出された案件記事群は編集対処が必須な案件としてWikipedia:進行中の荒らし行為/長期/ダルメーター/新規作成された記事群にまとめまして、後始末の終了まであと5~10年くらい掛かるかな、と思います)。

自分的な同種前例は他にもまだあるのですけども、現状で管理者、削除者のマンパワーが極度に少ない状況に於いて「削除依頼など、複数依頼案件をまとめて(結果的に審議終了を)長期化させてしまう行為(依頼)」というのは、各々の立場から見てどんな風に感じられるんでしょうね? 個人的には審議の早期終了、コミュニティの労力軽減の観点で見ると、ある程度以上(各精査が必要な)案件が多くなった場合、個々の個別依頼案件として提出した方が良いのかな? などと考え始めたところなのですが。--Nami-ja (会話 / 履歴) 2017年12月10日 (日) 13:34 (UTC)

ベテラン編集人の言動について[編集]

ログインが少ないライトユーザーなためルール上の不備があったらすいません。以前、あるページで記載について編集の議論をしました。その際にベテランと思われる方と議論になりました。その方は私個人のページに「何が目的でウィキペディアに参加したのか」なとど圧力ともとれる発言をしてきたり、また今は消されているようですが4ヶ月前に「Wikipedia:管理者伝言板/投稿ブロック/ソックパペット」の「ログインユーザー」の項目で無期限ブロックされた別のユーザーと同じだとレッテルをつけてきたり、あまりにもひどいと感じています。こういった編集人の新人潰し、自分の気に食わない言論を記載する編集人は徹底的に潰していくという行為を繰り返す人間がベテラン編集人として日本語版ウィキペディアにいることについて限度を超えていると思いますのでここで話したいです。個人ユーザー批判は厳禁だと思いますので一般論としてWikipediaがより開かれた場所として改善されるようにベテラン編集人の問題について議論がしたいです。--Ueumi会話) 2017年12月11日 (月) 11:04 (UTC)

執筆記録を見ると、「事件」は約半年前に起きたようですが、会話ページに書き込んだ相手は、いずれも無期限ブロックされているようです。この二人がベテランか分かりませんが、Ueumiさんが今回受けたと思う仕打ちは、嫌がらせであったと考えて良いでしょう。--Bletilla会話) 2017年12月11日 (月) 13:10 (UTC)
コメント 編集回数だけで言えば「ベテラン」の部類となる利用者です。まず、本件に限って。Baledeparseは荒らしなので気にする必要はありません。はるみエリー氏によるソックパペットの報告については、被害妄想も含めた精度の低いものと判断しています。立場は違えど氏の気持ちはわからんでもないですが、政治記事は同じ編集傾向の人が登場しても不思議はありませんので、短絡的に過ぎると思いました(はるみエリー氏も他のLTAにはカンが良かったのでそこは高く評価していたのですが)。次に一般論というより経験則ですが、ベテランにやたら絡んでくる新規アカウントは大抵の場合LTAですし、狭い範囲の記事で現れるのは大抵の場合ブロック破りです。新人を排除する気は毛頭ありませんが、新人を偽装したLTAが非常に多いのは事実です(Wikipedia名前空間の場合、特に)。ちなみにUeumi様については、この井戸端を見るに「新人」である特徴が一瞥で3つ見つかりました(新人を偽装するLTAを利するので何かは言いませんが)。ベテラン(というよりLTAに絡まれている利用者)から見れば、それが新人かどうかはよくわかりますので。--JapaneseA会話) 2017年12月12日 (火) 09:58 (UTC)
コメント 蛇足ですが念のため。ウィキペディアでは新しい参加者を歓迎しています。ガイドには「新規参加者を苛めない」もあります。納得がいかない事態が発生した場合には「困ったとき」のガイドも、ユーザーに対する第三者からのコメント依頼も使用できます(個人への悪口は良くないですが、特定ユーザーへの客観的な問題提起は可能です)。ただしウィキペディアでは「新人」も「ベテラン」も「管理者」もユーザーとして原理的には対等です。問題ユーザーは「新人」にも「ベテラン」にもいると思います。従って「ベテラン編集人の問題」という一面的な表現には、少し疑問を感じます(今回たまたまそうだったというのは理解しますが)。習熟度や実績はあると思いますが、基本的には参加年数よりも、建設的である事が重要と思います。--Rabit gti会話) 2017年12月12日 (火) 14:10 (UTC)
コメント じゃあ蛇角辺りを。Wikipedia:新規参加者を苛めないでくださいという『比較的強力なルール文書』が在りますので、基本的にはベテランの皆さんは初心者には優しく在ろう、と思ってはいますけども、その上で、「初心者」と「ベテラン」に区分けして『ベテランが初心者に優しくない!』『ベテランならば常に初心者に優しくあるべき!』といった主張を為されるのは、ウィキペディアがどんな場所なのかを最初から勘違いされているようにも思います。──ここは学習教育機関でも新人育成教育場でもありませんので、現時点でその能力をお持ちでない方が失敗を繰り返しながら少しずつ成長して行く姿を見守ることを個人的には全否定するものではありませんけども、少なくとも初心者であることを自ら声高に主張され、ベテランに一方的に譲歩を求める、初心者であるご自身を優遇するような現状改善を求める、というのは過去に全く同様の行為を行われた初心者さんもいらっしゃいましたけども、少々ながら違和感を覚えます。◆提案者さんの新規作成記事を拝見させて頂きましたが、少なくともずぶの素人以上、一般的な初心者以上に立派な記事を書ける能力をお持ちである『初心者の枠を超えた優良編纂者』さんであられると個人的には思います。ですので、そういった「百科事典編纂に密接に関係しない話題に拘泥される」のは後回しに、良い記事を書く、既存記事の信頼性を更に高める方向性で限られたウィキペディア接続時間を使われた方がより有意義な時間の使い方ではないかな、と思いました。--Nami-ja (会話 / 履歴) 2017年12月13日 (水) 04:44 (UTC)
コメント 補足 投稿履歴によって全ての利用者の行動は常に公開されている[[特別:投稿記録/○○]]←○○の部分を自分や他人の利用者名に変えて利用者:Ueumi/sandbox辺りで保存してみて下さい、その利用者の全投稿記録が見られます)のですが、この機能で提案者さんの編集履歴を見ると当年5月にウィキペディアに参加されてから記事の編集を行われたのは僅か2回のみで、その他は全て記事以外の会話ページや利用案内などへの質問や議論です。ですので、他編集者から「ウィキペディアに参加した(本当の)目的は何か」と問い質されることに繋がっていると考えます。──ルール改訂に先ず拘るのではなく、ご自身で利用者ページに書かれ表明されている通り「記事の改訂や信頼性を高めることを主目的として参加した」のであれば、その通りの行動を優先され、こういった「本来の目的から外れた些事」は片手間に進めるくらいがちょうどいいのではないかな、と思います。…もちろん、ご自身の編集環境を整えることも重要なことですから否定しませんが、本来の参加目的から枝葉を追ってどんどんと外れた目的へ逸れていませんか? というお話です。--Nami-ja (会話 / 履歴) 2017年12月13日 (水) 04:44 (UTC)
コメント 更に蛇足ですが念のため。私は各発言者の履歴には興味が無いので単に一般論です。ウィキペディアでは、参加年数や編集回数による上下はありません(重要な投票等での編集回数制限はありますが容易にクリア可能)。また、参加作業(執筆、雑草取り、議論、運営、bot作成などなど)も、同様に自由であり上下はありません。「ベテランが偉い」という事は無いのと同様、「記事執筆者が偉い」とか、「議論中心だから悪い」という事もありません。好きな時間に好きな内容に参加すれば良いと思います。--Rabit gti会話) 2017年12月13日 (水) 14:10 (UTC)

一部の縦に長い表にスクロールバーを導入し見かけ上短縮する提案[編集]

一部の記事にあるような縦に長い表(例えば、アニメ等におけるキャラクターリストなど)ですが、PC版では上から記事を読んでいく場合スクロールがとても大変な状況になっています。(例えば、艦隊これくしょん_-艦これ-けものフレンズの記事におけるキャラクター一覧)キャラクター一覧は、コンテンツにもよりますが、基本的に記事から除去すべきとは言いにくい状況にあり、また独立記事にするかといわれれば特筆性の面で否定され、記事が見にくい状態となってしまっています。

そこで、他のWIKIからの引用で申し訳ないですが、ニコニコ大百科/艦隊これくしょん~艦これ~の中央部、「サーバー群」での表のようなスクロールバーを利用することによって、表の高さを軽減し可読性を高めるという提案になります。

表を長くせざるを得ない状況であり、かつ記事において常にすべての内容を表示する必要はない表といったものにおいて、スクロールバーあり表を導入することはできないでしょうか? Wikipediaにおいて導入可能かは私のほうで判断できないのですが、ご意見等お願いできればと思います。--Pengin会話) 2017年12月11日 (月) 16:54 (UTC)

  • Symbol comment vote.svg 追記 また、説明にも有る通り、出来るだけ避けるべきでは有りますが、Template:Collapse topも『選択肢の一つ』とはなるかと思います。--ただのしかばね / / 2017年12月11日 (月) 23:15 (UTC)
  • Symbol comment vote.svg 追記 
Template:Collapse topを使用した場合にはSpecial:PermaLink/66597030のように、
Portal:テレビ/執筆依頼のようにした場合にはSpecial:PermaLink/66597068のように、
なります。(尚、どちらも僕の利用者ページ傘下の下書き用ページで、固定版リンクです)--ただのしかばね / / 2017年12月11日 (月) 23:42 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────何度もスミマセン。個人的には、Portal:テレビ/執筆依頼のやり方が良いと思います。
<div style="background-color:#ddd; border-bottom:dashed 1px #000; border-left:solid 3px #000; padding:2pt 1em">'''リスト名'''</div>
<div style="overflow-y:scroll; width: full; height:400px;">
<div style="padding-left:1em;">

</div>
</div>
で挟む感じですね。サンドボックスで試したところ、この縦幅だと15行になるみたいですので、20行程度だと逆に見づらく感じる人もいるかも知れません。30行を超えるリストの場合に、使用するのが良いのではないかと思います。--ただのしかばね / / 2017年12月12日 (火) 00:06 (UTC)

返信 わざわざ例まで作っていただいてありがとうございます。ただのしかばねさんの例だと、表をDiv要素で分けてそのうえでそのDivをスクロール可にするという方法ですよね。一応、自分も例を用意してみるべきかなと思ったので、表自体がスクロールできるようになるタイプを作成してみました。(利用者:Pen_bo/sandbox#艦娘)こちらの方法は、表自体にCSSを適用して、縦の表示サイズを300pxまでに制限するものになります。こちらのタイプの場合は、既存の形を崩さずに短縮できるのかなと思っていますが、どうでしょうか?--Pengin会話) 2017年12月12日 (火) 05:32 (UTC)
Symbol comment vote.svg 追記 ざっくりと作り方です。
{| class="wikitable"の部分に
style="display: block; overflow-y: scroll; max-height: 300px;"を追記し
{| class="wikitable" style="display: block; overflow-y: scroll; max-height: 300px;"とすることでスタイルの適用を行っています。この場合縦300pxを超える場合、スクロール可能な表になります。--Pengin会話) 2017年12月12日 (火) 05:38 (UTC)

情報 Help‐ノート:脚注/過去ログ2#脚注スクロール廃止の提案で2009年5月に全廃止された機能と同一のものを指していると思います。このときに「インラインスクロールがあると全体スクロールとカブって操作性が非常に悪くなる」といった意見も出されているようです。 / 個人的には「そんなに長くて記事単独内部の可読性に難点があるなら、初期設定で一覧表自体を折り畳んで『必要に応じて必要な方だけが適時開いて確認出来る設定にしておく』方がいいのではないか」とも思います。--Nami-ja (会話 / 履歴) 2017年12月12日 (火) 08:24 (UTC)

コメント まず、Template:Collapse top本文中では絶対に使用しないでください。Navboxの仕様を借用しているため、モバイル版ではその部分の情報が丸ごと欠落します(表示されない)。ただのナビゲーションであれば欠落は問題ないですが、重要な本文が無くなってしまうことは避けねばなりません。モバイル版がきちんと運用され利用される前に作られたテンプレートですから、昔の記事にあるのは仕方ありませんが、新たに使うのは言語道断。
次に、overflow-y:scrollもなるべく使わないでください。モバイル版では問題ないですが、印刷時には隠れた部分の情報が印刷されず欠落します。どうしてもスクロール化したいなら、Help:脚注部分をスクロール化するのように「デフォルトではオフの、使いたい人だけが使えるガジェット」として実装してください。閲覧環境は人それぞれなのに、ある環境では見づらいから~というのを根拠なく全体化して、検証もせずデフォルト実装してはいけません。
基本的に、ウィキペディアの基本表示というのは私ら素人よりずっとUIやアクセシビリティに詳しい人が作っているので、あまり弄るべきではないです。--Starchild1884会話) 2017年12月12日 (火) 21:54 (UTC)
折り畳み方式はTemplate:Collapse topという事になるので、overflow-y:scrollの方が良いかと思いましたが、コッチにも別の弊害が有ったのですね。情報、感謝します。
それでしたら、執筆依頼や加筆依頼などにおいては(印刷する人がいるとは思えないので)問題ないけれど、通常の記事においては避けた方が良いですね。
そして、閲覧環境云々については、以前やらかしてしまった事が有るな、と……「『不都合なようでも、総合的に考えると、現状が最善なケースが多い』という感じ」が、今回も当てはまるのですね。
  ガジェット化するにしても、実際の記述に手を加える必要が有ると思うのですが、その辺りはどうなるのか分かりますか? 僕は完全に素人でして、ガジェットがどういう仕組みで構築・実装されているのかも、よく分かっていないのです。個人的には、オンに設定を変更した人のみ、overflow-y:scrollの動作になるというのが、良いと思うのですが(横スクロールはやりづらいので。横か縦かも選べるなら、それが一番いいとは思いますが、難しそうですし)。--ただのしかばね / / 2017年12月13日 (水) 00:15 (UTC)
コメント 本筋から外れますが、本文中に長々と表が現れること自体に違和感を覚えます。表が無くても理解できるように本文を構成し、補足として表を作るなら記事の末尾(脚注の前)に「別表」として纏めて置いて欲しい。まぁそんなルールは無いので、私はこうなったら良いなと思っているというだけです。--mit freundlichem Gruß LudwigSKDiskussion/Beiträge) 2017年12月13日 (水) 00:37 (UTC)
末尾に『別表』セクションを作り、そこにTemplate:Anchorを付けた上で長いリストを記載。現在有る位置には、同テンプレートを使ってのページ内リンクを貼っておく。
これも確かに、状況次第では最適となる『可能性』がある案だとは思います。デフォルトでは現状の表示で、ガジェットをオンにした場合に別表表示となる。そういう事が出来たら良いかも知れない、と思いました。--ただのしかばね / / 2017年12月13日 (水) 00:55 (UTC)
返信 (LudwigSKさん宛) ありますよWikipedia:スタイルマニュアル (表)Wikipedia:アクセシビリティが該当します。…どちらも未だ草案ですけども。仰っておられる内容は「ユーザーアクセシビリティ」そのものですね。--Nami-ja (会話 / 履歴) 2017年12月13日 (水) 03:38 (UTC)
コメント けものフレンズ#フレンズ一覧艦隊これくしょん_-艦これ-#登場キャラクターも『ゲームを実際に遊んでいるか、これから遊ぶ方のためにどのキャラクターにどんな利点があるかに主眼を置いた一覧になっている』ので、表そのものがWP:NOTMANUAL、「ゲーム攻略法を百科事典解説と混同した状態」になっている虞はあると思います(実際にそのキャラクターを使って遊んだ匿名プレイヤーの経験的情報、独自研究の成果でありWP:NOR違反)。◆百科事典の観点ならば「キャラクターのゲーム使用上の利点」ではなく「(百科事典的に文章でそれぞれのキャラクターを解説するものとして)ゲームキャラクターと他出版物などと比較した場合のそれぞれの相違点、元になった史実艦船や動物と比較しての特徴のデフォルメポイント、他同様ゲームと比較しての本ゲーム上でのキャラクターの特色の文章解説」などに主眼を置くべきで、『表自体を作成した目的が、それこそゲーム攻略ウィキと混同状態に在る』のではないかな、と思います。──ここまで徹底的にゲーム攻略サイト代わりに利用されて来たものをこれから改訂するのは容易ではなかろうと思いますが、似た前例として現時点で15年続くMMORPGゲームとして有名なラグナロクオンラインがあるのですけども、このゲームは数千を超えるアイテムがゲーム内に登場してプレイヤーに密接に関係するのですけども「アイテム一覧は記事上に一切ありません」。ゲームシステムの特色を列挙解説する形の記事になっており、表は完全排除された状態で記事として成立しています。--Nami-ja (会話 / 履歴) 2017年12月13日 (水) 03:38 (UTC)
素朴な疑問なのですが、なぜ表が長いといけないのでしょうか。そもそも項目が多いものは表も長くなるでしょうし、その多さ・長さはある意味仕方がないような気もします(たとえばロシアの都市に「多すぎるから30にまとまれ!」とかいうほうがそもそも理不尽なような気がします)。
また、文章だと読みにくいから表を作成しているはずで(たとえば、「AA天皇は第X1代天皇、在位000年から001年、生年00年、没年00年、別称QQ天皇、諱はWWW。BB天皇は第X2代天皇、在位000年から001年…、」なんて文章が延々(100人越えて)続くよりも、明らかに表のほうが(たとえ100段越えの表だとしても)見やすいし理解しやすいはずです(天皇の一覧#一覧表))、表は、すでに可読性を高める配慮がなされている部分であると思います。
そして、表も記事の一部であり、文章や箇条書きと同等なのではないかと思います。で、文章にスクロールバーをつけよう、という提案は、おそらく否決されるのではないかと思います。(たとえば日本の歴史の中で、「明治までスクロールするのがダルいから、平安とか鎌倉とか畳んでください!」とか要求しても、「いや目次から飛ぶとか頭使いなさいよ」といわれて終わるような気がします)。繰り返しになりますが、表も記事の一部であり、文章や箇条書きと同等なのではないかと思います。表だけ畳まれるのは何か違うような気がします。--ノフノフ会話) 2017年12月13日 (水) 08:07 (UTC)
コメント ご提示のような一覧ページが表になっていても問題ないと思いますよ。私は長大な表は別表にして末尾に追い出して欲しいと書きましたけれど、一覧ページはページ自体を分離して追い出してある訳ですから。ただロシア#地理ロシアの都市の一覧が、天皇天皇の一覧が、そのまま入っているような記事が結構あるんですよね。本提案冒頭に例示されている艦隊これくしょん_-艦これ-けものフレンズのように。その表の後にまた本文が続くのです。
それに表を箇条書きにしたって読み易い訳ないじゃないですか。本文として構成し直すというのは、天皇#天皇の歴史の様になって欲しいのです。その上で、一覧性が高く比較し易い天皇の一覧がある。末尾に別表でも良いし、別ページでも良い。でもその一覧が、天皇#天皇の歴史の代わりにあったら邪魔じゃないかな、と。まぁマンパワー的に無理ですよね……ただの願望です。--mit freundlichem Gruß LudwigSKDiskussion/Beiträge) 2017年12月13日 (水) 09:03 (UTC)
コメント 表自体が、本文内の箇条書きや本文と同等なのではないかとおっしゃっていますが、私はそうは思いません。表に箇条書きや本文にできるだけの情報量があり、またそれができるのであれば、表は作られないわけですしただの列挙である表は邪魔になると思います。記事とするには無理があったり、またそのための情報が足りない場合に作られるのが表であり、必然的にその優位性は本文や箇条書きよりも劣ってはいるのではないでしょうか? また、本文は目次から飛ぶことができたとしても、同じ見出し内の文章内に表がありその後文章がさらに続く状況においては、「目次で飛べよ」というのは不可能にかんじます。--Pengin会話) 2017年12月14日 (木) 12:42 (UTC)

少々忙しかったので返信が遅れました。すみません。今でている案を整理すると以下のようになりますかね?

  • 表を標準でスクロールにする(印刷等で問題が出る可能性あり)
  • ガジェット機能として実装する(実現できるのかは不明)
  • 表をページ末尾に移動させる(今のところ実現性に問題はなし)
  • 現状維持
  • 表を折り込む(使用できない端末があるため不可)

一応ですが、表自体の意義や文章化などは議題として少しずれている気がしたのでここには含めてません。

コメントMawaruNekoのコメントここから)ガジェット化について、ガジェットは管理者にしか追加できませんが、Wikipedia:カスタムCSSWikipedia:カスタムJSは各利用者が利用できますので、それである程度実験をすることが可能です。その上で、ガジェット化する場合について考慮すべき点をいくつか述べます。
  • 記事中の表にはwikitableクラスがついている場合が多いので、wikitableクラスの付いている(長い)表にスクロールバーをつけることを考えます。
  • 単純にCSSで済ませる場合には、カスタムCSSに以下を追加します。
    table.wikitable { max-height: 300px; overflow-y: scroll; display: inline-block; border: 0; }
    
  • display: inline-blockを指定すると、スクロールバーが表の真横に表示されます。display: blockにすると、ページの右端に表示されます。
  • overflow-y: scrollを指定すると、小さい表にもスクロールバーが表示されます。overflow-y: autoにすると、ブラウザによってはサイズの上限を超えた場合のみにスクロールバーが表示されるようになりますが、スクロールバーが表の内側に表示されてしまうため、スタイル崩れを起こしてしまいます。
  • カスタムJSを使用すると、サイズの上限を超えた場合のみに(上記の問題を起こさずに)スクロールバーを表示することが可能です。User:MawaruNeko/TableScroller.jsにサンプルを作成しましたので、お試しください。--MawaruNeko会話) 2017年12月16日 (土) 15:45 (UTC)--MawaruNeko会話) 2017年12月16日 (土) 15:47 (UTC)微修正

拡張半保護の導入/決選投票[編集]

決選投票の概要[編集]

以前から提案しております拡張半保護の導入に関する投票です。事前議論の結果、投票実施に賛同が得られたため、投票を行っております。--Marine-Bluetalkcontribsmail 2017年12月13日 (水) 17:40 (UTC)

議論の経緯

  1. Wikipedia:井戸端/subj/保護機能の仕様変更について
  2. Wikipedia:井戸端/subj/拡張半保護の導入
  3. Wikipedia:井戸端/subj/拡張半保護の導入/調査投票
拡張半保護とは
半保護よりも強力な保護で、編集回数のかなり多い利用者(≒ある程度活動期間の長い利用者)のみがページを編集できます。
導入の目的
半保護突破対策です。長期荒らしなどが寝かしアカウントを使用し、半保護を回避する場合、そのページは全保護せざるを得ず、荒らしを行わない一般の利用者も全員編集できなくなってしまいます。
半保護の強化ではない
あくまでも全保護されたページの編集制限緩和が目的です。拡張半保護は半保護の代用機能ではありません。
編集回数の少ない利用者に対する制限を増やすのか
現在の半保護を拡張半保護に移行するわけではありません。IPユーザーによる荒らしなど、今まで半保護で対応してきたものは今後も半保護で対応されます。
完全に防げないのではないか
保護に穴あけを行うようなものなので、荒らしを100%という確度で防げないことは明らかです。これはやむを得ないと考えます。全保護を回避し、ページを編集できる利用者を少しでも増やすことが提案の目的です。
また、仮に荒らしアカウントの紛れ込みがあったとしても、半保護突破のように大量の寝かしアカウントを継続的に投入する荒らしは不可能でしょう。拡張半保護を突破した荒らしアカウントをブロックしていけば荒らしはかなり抑制出来るはずです。
全保護の3ヶ月ルール
拡張半保護を導入すると、3ヶ月置きに全保護を行う必要はなくりますので、対処する管理者の手間も多少は省けるでしょう。
スチュワードなど
スチュワードとグローバルインターフェース編集者はウィキペディア日本語版での編集回数に関係なく、拡張半保護されたページを編集することができます。
稀にウィキメディア・プロジェクト全体のメンテナンス目的でスチュワードなどが一部のページを編集しますが、拡張半保護がメンテナンスを阻害することはありません。

調査投票の際に出た意見(要約)

  • 可能な限り長いものがいい
  • 参入障壁が高くなるため短いほうがいい
  • コンスタントに編集を行った場合、120日ほどで500編集に到達したので、そこから少し短くして90日
  • チェックユーザーの情報の保存期限が90日なので90日
  • 全保護の3ヶ月ルールとは期間をずらす形で120日
  • 長期荒らしは90日でも突破するので120日

投票者の方はどうぞ、ご自身が望ましいと思う選択肢に投票してください。事前議論の結果は考慮せずとも構いません。なお、CUに関する意見や説明は他のCU経験者の方におまかせします。--Marine-Bluetalkcontribsmail 2017年12月13日 (水) 17:40 (UTC)

投票スケジュール[編集]

スケジュール[編集]

日本時間(UTC+9)で言うところの2017年12月18日 (月) 09:00から 2017年12月25日 (月) 09:00の日程で実施します。得票数の多かったものが決定案となります。反対票が総得票数の半数を超えた場合は廃案とします。


投票資格は2017/8/17 0:00(UTC)時点で初回編集から3ヶ月以上、標準名前空間の編集回数500回以上のログインユーザーとします。荒らし対策なので、荒らしユーザーの紛れ込み(妨害行為)を阻止すべく、事前議論のもとにやや高い条件設定を行っています。コメントに関しては、今のところ特に制限はありません。

投票所[編集]

投票の詳細
拡張半保護されたページを編集できるようになるまでの日数(半保護でいうところの4日)は何日が良いかを投票で決定します。編集できるようになるまでの編集回数(半保護でいうところの10編集)は、500編集とします。
導入する機能の詳細(提案内容) / Proposal of enable to extended semi-protection
1.管理者が保護の設定画面で拡張半保護という選択肢を選べるようになります。/ Enable extended semi-protection.
2.拡張半保護されたページが編集できる利用者には「拡張承認された利用者」というフラグが自動的に付与されます。/ Autopromote "extended confirmed users".
3.拡張承認された利用者の他に、管理者、ボット、インターフェース編集者は総編集回数に関係なく拡張半保護されたページを編集できるようにします(技術的問題を考慮)。/ Add "extendedconfirmed" right to exteded confirmed users, sysop, bot and interface editors.
4.拡張承認された利用者のフラグは原則として自動付与されるが、管理者によって能動的な与奪も可能とします(500編集未満で承認or500編集以上でも承認取り消しができる)。/ Sysop grant/revoke "extended confirmed users" flag.
5.フラグの与奪基準などはWikipedia:拡張半保護の方針にて決定する予定です。このページでは導入そのものについての賛否を問います。

提案内容は必ず確認して投票してください。賛成票の合計が反対票を上回った場合に成立とみなします。

投票の書式は#--~~~~でお願いします。

90日、500編集に賛成 / support (autopromote 500 edits and 90 days)[編集]

120日、500編集に賛成 / support (autopromote 500 edits and 120 days)[編集]

導入に反対 / oppose to this proposal[編集]

コメント / comments[編集]

Sitenoticeでの告知文章について。

荒らしを原因とする長期全保護の緩和策として、[[Wikipedia:井戸端/subj/拡張半保護の導入/決戦投票|拡張半保護の導入提案と投票]]を行っています。<br>
<small>投票期間:2017年12月18日 (月) 00:00 (UTC) から 2017年12月25日 (月) 00:00 (UTC) まで</small>

短期間表示されるだけの文なので細かい部分を徹底的に調整する必要はないかと思います。大きな問題がなければこれを使っていただけると幸いです。必要な情報が抜け落ちているようであれば修正します。--Marine-Bluetalkcontribsmail 2017年12月13日 (水) 17:40 (UTC)

現行予定での投票実施に 反対  : 変更影響度と有権者規模に対して告知期間、投票期間が何れも短すぎます。私が単に存じないだけかもしれませんが、これらの投票日程はどこで事前提案と合意を経たのですか?Wikipedia:井戸端/subj/拡張半保護の導入/調査投票 がいったん停止する経緯から何も学ばれていないのか、それともそれらは考慮するに値しないと思われたのですか?現行の状況で遂行されようとすることに対して、あまりにも事前準備が疎かで、コミュニティ軽視が過ぎます。enwp の拡張保護ですら、もともとの根拠はコミュニティから厳正な信任投票を経た裁定委員会の決定を、技術的により良い実装方法にするために行われた提案で、それでも1カ月の合意期間をもって実装に至っています。本件では「多重投票の排除」を名目にウィキペディア日本語版のローカル投票では過去に例のないと思われる異常なまでに高い投票資格設定を投票期間 1週間で、しかも告知もままならないまま実施に移そうとしていることは如何なものかと考えます。Wikipedia:井戸端/subj/半保護の期間を英語版同様の「登録から4日かつ10編集」に変更する提案 ですら投票期間に 10 日あるのです。--rxy会話) 2017年12月14日 (木) 12:35 (UTC)

  • コメント これは失礼。確かに、わざわざ最初からカウントダウンを行う必要はなかったですね。告知の類も含めて短期間で全て一気に準備を仕上げなければと(どういうわけか)考えてしまいました。そこまで高速で仕上げるほど敏腕ではありませんので、もう少しスローで行くことにします。--Marine-Bluetalkcontribsmail 2017年12月14日 (木) 13:52 (UTC)
  • コメント ざっと調べてみましたが、投票期間は1週間程度が慣例のようで、メインページの改訂なども(募集期間を含めれば掛かる期間はかなり長いですが)投票期間自体は一週間のようです。もちろん1週間から多少伸ばしても問題はないと思いますが、大幅に伸ばすのは慣例から大きく逸れるため合意を得にくいかもしれません。長くても2周間程度あたりが無難かなと考えました。--Marine-Bluetalkcontribsmail 2017年12月14日 (木) 14:05 (UTC)
    • 期間について: メインページの改訂は現行の利用者操作に制限となることが見込まれる変更ではありませんので、例示としては不適当と考えますし、投票開始前の告知が十分でないことの説明にはなりません。MediaWiki:Sitenotice , Template:メインページお知らせ/本文, Wikipedia:お知らせ, Wikipedia:投票/リスト (使われているのかが怪しいのですが) 等で投票開始前 1週間以上告知を掲載して周知を促す場合の投票期間は 1週間程度でも良いかと思います。または、各所への掲載開始時点で既に投票を開始しておき、2週間程度の投票期間を確保する方法も考えられます(たとえば、Wikipedia:管理者の解任 での猶予期間、Wikipedia:権限申請 の予告期間等、本投票期間外でも有効票とするもの)。
    • 投票資格について: そもそも、3か月前は「基準時点から3か月前の同日同時刻」ということなのか、最近の RfA における投票資格の「1か月前定義の改定」と同様に時間換算なのか (2017-05-19T00:00:00Z)。おそらく前者であろうとは思いますが、なぜ直接日時指定が可能な場所で間接指定をなさっているのでしょうか。また、現行の RfA 系ガイドラインにおける投票資格は想定外の不備が多すぎて役に立たないので、特に深い意味がないのであれば機械的になるべく処理できるように、“投票資格は 2017年8月17日 00:00:00 (UTC) 以前の 「(標準)」名前空間における編集が 500 回以上、かつ初回編集が 2017年5月17日 00:00:00 (UTC) 以前の 登録利用者(編集とは、投票時点で 特別:投稿記録 に投票者の利用者名を入力した際に表示されるものすべてを指す)”(初回編集が 2017年5月17日 00:00:01 (UTC) 以降は無効;しかし初回編集は全名前空間?初回編集も標準名前空間に限定するなら、「編集」の定義に名前空間条項を移動させたほうがいいし、そうでないなら全名前空間であることを明記した方がいい) 等と記載いただけると助かります。/* 投票開始前に SQL で有権者名簿を吐き出させて有権者を事前に確定させてしまった方が楽な気もします… けれども、そこまでやるなら投票資格のない人がそもそも投票できず、多重投票排除機能の優れた SecurePoll 使っちゃってもいいかもしれない… しかし明らかに面倒くさい… かと言っていちいち投票資格を投票者も確認者も確認する必要があるものよろしくないシステムであることは確か。そもそも合意形成手段の一つに過ぎないのに投票資格をここまで固める必要とは…*/--rxy会話) 2017年12月16日 (土) 15:05 (UTC)

出典元の外部のニュースサイトに接続すると変なポップアップ画面が表示される[編集]

タイトル昆明級駆逐艦の今日投稿されたところ。240D:1A:1B9:EF00:8C72:783F:AA5C:DC42 2017年12月17日 (日) 14:46 (UTC)

「ポルノ被害と性暴力を考える会」からの依頼について[編集]

(内部・外部関わらず、すべてリンクしません)某削除依頼の件なのですが、「NPO法人ポルノ被害と性暴力を考える会(PAPS)」なる団体と称する利用者からの削除要請が即時削除タグの理由欄に書かれていたようです。当然即時削除の方針に合致しませんが、通常削除依頼に回され削除されました。今後、日本語版ウィキペディアでは、この団体からの要請とされるものについては、その真偽を問わず一律に削除する方針なのか、あくまで通常通りの審議を行うのか、方向性がいまいち分かりません。なお、本件について、団体の公式サイト、及び公式ツイッターアカウントでは本削除要請、及び日本語版ウィキペディアにおけるアカウント取得に関する情報の発信がされていません。--Doripoke 2017年12月17日 (日) 15:55 (UTC)