Wikipedia:井戸端/subj/単独記事としての成長を妨げられた項目について
|
単独記事としての成長を妨げられた項目について
[編集]中途半端に情報が載せられて容量が肥大化しているリスト項目がしばしば見受けられる。このような記事はフィクションなどのキャラクターの記事を複数統合したものに多いが、この場合英語版には立派な記事が立っていて、それが日本のアニメのキャラクターだった場合、単独の記事としての成長可能性の芽を摘まれてしまったと思い苛立ちを覚える。自分としては今後記述の増大(目安として1kb以上)の望める記事は全て存続するべきだと考えている。それは何もある作品のファンだからという理由ではない。サーバーと回線の事を考えるとそれぞれのキャラクターの情報だけが見たいのに毎回何十倍の容量を持つ巨大な一覧記事へ飛ばされていては転送量が増大し、統合しなかった時に比べ大幅にサーバーや利用者の回線へ多大な負担を生むこともその理由である(それは結果的にウィキスローの原因となり、ウィキメディア財団の資金を浪費する結果となる)。よってその点において無闇な統合を自重していただきたいと同時に、肥大化したリストの分割の目安について提案したい。その基準は一部の旧式のブラウザでの編集に支障を来たす25kbとしたい。皆様はこれについて如何お考えか?Sionnach 2006年8月4日 (金) 17:11 (UTC)
- 大量の単独記事が成立してしまうことの方がよろしくないという向きも存在しますし、実際そういったケースも多いと思います。ですから、原則で一括りに規定するのではなく、個々の記事毎に対処すべき問題であると感じます。統合記事ならばページ内検索の有用性が高まる利点も存在します。
- それから「何十倍の容量を持つ巨大な一覧記事へ飛ばされていては転送量が増大し」と言われますが、サーバーへの負荷を考えるならば、巨大な統合記事の方が 多くの分割記事よりも優れていると言えます。Wikipediaでは1つの記事について毎回(記事の長短にかかわらず)10ファイル程度・60KB超のCSSとJavaScriptが読み込まれており、これがサーバーに負荷をかけ、閲覧者にストレスを与えています(カスタムCSSなどを使用している場合では更に増大)。
- これは実際の実験結果にも基づく結論で、ページ表示時に毎回読み込んでいるファイルをローカルにコピーしてこちらを参照するようにしたところ、ページ表示にかかる時間が平均で三分の一以下にまで短縮されました。
- つまり、1KBのページをいくつか閲覧しただけで、長いリスト状のページ1つと同程度の転送・遥かに多いリクエストが発生することになります。最終的に、サーバーにかかる負荷・表示にかかる時間で前者が圧倒的に不利になりましょう。-- D.328 2006年8月4日 (金) 17:37 (UTC)
- CSSやJavaScriptについては読み込まれる以上通常キャッシュされるのではなかろうか?一々巨大なファイルを読み込むしかできないのなら開発元へ問題点を報告して対処してもらうべきではなかろうかね。Sionnach 2006年8月4日 (金) 23:34 (UTC)
- 既に表示されたページの、再読込を繰り返して得た結果(平均)が上記の「三分の一」なので、キャッシュではなくダウンロードし直している可能性が高いと感じます。トラフィックが集中する時間帯(夜)での結果です。空いているときはそれほどの差は認められませんでした。
- 憶測ですが「/index.php? title=MediaWiki:Common.css &action=raw &ctype=text/css &smaxage=18000」といったURIからCSS等が「生成される」ので、キャッシュがURIに関連づけられないのではないかと。
- 外部のサイトでも、MediaWikiが使われている場合は同様のソースになっていましたので、これはWikipediaではなくMediaWikiソフトウェアの仕様であろうと考えております(Wikimediaのbugzillaに問うべき不具合ではなさそうです)。-- D.328 2006年8月5日 (土) 00:06 (UTC)
- えーと、css/jsがキャッシュされないんじゃMediaWiki:Clearyourcacheはいらなくなるわけですが。IE+ieHTTPheadersで見たところ、いちいち読み直しているなどということはありませんでした。ブラウザかその設定が悪いのでは?--Kkkdc 2006年9月1日 (金) 11:37 (UTC)
なぜトラフィックが集中すると差が見られるのだろう?Sionnach 2006年8月5日 (土) 01:01 (UTC)そうか転送量ではなく時間か、しかしローカルのキャッシュに残らないのなら改善の余地はあるのだろう。メディアウィキのBugzillaではそういった事も受け付けているのではないのだろうか?Sionnach 2006年8月5日 (土) 09:10 (UTC)
- CSSやJavaScriptについては読み込まれる以上通常キャッシュされるのではなかろうか?一々巨大なファイルを読み込むしかできないのなら開発元へ問題点を報告して対処してもらうべきではなかろうかね。Sionnach 2006年8月4日 (金) 23:34 (UTC)
- なんにせよ、統合したがる人は細かな記事が立った直後に行動し始めるため、単独記事に対しての加筆猶予が全く与えられないというのが大部分である。数日、数週間、または数ヶ月経てば英語版のようになったのかもしれないところを、その場の様子だけを見て水増し要素的に複数の記事を統合し、しょうもない一覧になってるのは事実だ。
- それを分割しようにも「一覧に加筆してから行え」と言い、加筆したところで「それでは少なすぎるので反対」という。結局のところ、邪魔をしたいだけなのかと思えてならない。自分で執筆しない人に限って執筆する側へ大きな要求をし、妨害する。理想主義にも程があるのではないか。--ワッハハッハポッキモン 2006年8月5日 (土) 01:09 (UTC)
- 細かな記事が立った直後に行動し始めるため
- 周知徹底できていないからです。賛同意見が多ければ誰も文句は言えない。
- 加筆したところで「それでは少なすぎるので反対」という
- どの項目でいつそんなことがあったのでしょうか。提示してください。
- それに、ポケモンなどは分割後の加筆が行われていないようですが、これはどういうことでしょうか。 -- NiKe 2006年8月5日 (土) 04:15 (UTC)
それ以前の問題としてNiKe氏は削除やリバートばかりで加筆そのものが行われていないようですが、これはどういうことでしょうか。--以上の署名の無いコメントは、199.72.256.181.(会話・投稿記録)さんによるものです。--PeachLover 2006年8月5日 (土) 09:37 (UTC)修正--Avanzare 2006年8月5日 (土) 10:08 (UTC)さらに修正--Avanzare 2006年8月5日 (土) 10:09 (UTC)
- >ワッハハッハポッキモン氏へ
- 単独記事に対しての加筆猶予が全く与えられない
- サブスタブが長らく放置される状態についてにもあるが、先にノートページ等を利用しての準備も可能である。それ以前に各自で用意すらしてないのはどうかと思うが。
- 自分で執筆しない人に限って執筆する側へ大きな要求をし
- 大きな要求が必要とされる状態へ運んだ者の責任であり、他の者には何の義務も無い。--61.114.55.2 2006年8月5日 (土) 17:11 (UTC)
- >英語版では立派な記事が立っていて…
- 英語版でもすべてが単独の記事というわけではないですよ。『ファイナルファンタジーVII』(w:Final Fantasy VII)でも登場人物一覧なるもの(w:List of Final Fantasy VII characters)があるが、単独記事になっているのはメインキャラだけで残りはリスト項目になっています。ドラゴンクエストシリーズとなればゲーム画面や公式イラストが載っているのを除き、日本語版とそれほど差がないと思います。(cf.『ドラゴンクエスト VIII』日本語版 / 英語版)--にゃんぴー 2006年8月6日 (日) 07:06 (UTC)
メインキャラの記事さえないの(統合する様な人物がいること)が問題なのだよ。Sionnach 2006年8月6日 (日) 23:15 (UTC)
こんな事故が起こりました。分割ではなく一から書くほうが安全なんでしょうか。--煌々 2006年8月7日 (月) 01:21 (UTC)
とりあえず、中身はなくてもいいんで目次を建てておくくらいはしておくべきじゃないでしょうか?定義と目次は新規記事作成者(もしくは分割者)の義務かなと思ってます。それさえしていれば、記事が分離されていようが問題ないかと思います。逆に、そのレベルですらない記事を統合したがる人が統合するのはしょうがない部分があるかと思います。Fuji 3 2006年8月7日 (月) 09:45 (UTC)
- 自分で記事も書けないような人間が分割分割と叫ぶのは甚だ見苦しいと思うのだが、S氏にW氏?あと英語版は量こそ多いが中身が薄くないか?心の目と一撃技で2ターンで倒せるとか書かれてもさぁ。--61.114.40.173 2006年8月7日 (月) 16:12 (UTC)
儂の投稿記録を目ぇかっ開いてよく観察するように。Sionnach 2006年8月11日 (金) 14:10 (UTC)