ポケモンスリープ攻略・検証Wiki

投票が編集扱いであることを知りませんでした。ご迷惑をおかけし申し訳ありません。
代替案を持ち合わせていないので、いったん投票機能を削除します。

即時対応を強制したいわけではなかったので申し訳ない気持ちもありますが、暫定的な対応ありがとうございます

根本的な解消ではありませんが、対症療法として「編集ログから、みんなの意見のログだけを見えなくする方法」ならあります。
ブラウザの拡張機能でユーザーCSS（ユーザースタイルシート）を使う方法です。

div.diff-log-info:has(a[href$="/%E3%81%BF%E3%82%93%E3%81%AA%E3%81%AE%E6%84%8F%E8%A6%8B"]) {display: none;}

引数にnotimestampと付ければ、投票でタイムスタンプが更新されることが無くなると思います。
一旦変更してみたので、問題ないかテストしてみます。

タイムスタンプが更新されないだけで、編集は行われているから、diff_logに引き続き反映されますね

なるほど。これじゃダメなんですね。
また停止します。

よく分かってないのですが、編集ログが溜まってしまうことの弊害って何かあるのですか？

「タイムラインが更新されない=RecentChangesを荒らさない」ということなので、みんなの意見ページの管理は難しいかもしれませんが、ほかのページというかwiki全体の管理には影響を与えない気がします。

• 新規で投票を作成する場合は"notimestamp"と必ずつける。
• 問題が発生したら該当ページを削除/凍結させる。（編集履歴を遡って復元するとかはしない）
  というルールで復旧させるのはどうでしょうか？

編集ログが大量に流れる弊害としては「荒らしが現れた際に発見が遅れる」ということはあると思います。
先日新しいポケモンのページで荒らしがあったみたいなので他のページは大丈夫かな？と思い更新履歴をまとめて確認しようとしたら「みんなの意見」がズラーッと並んでおり…該当IDを追うのが大変…ということがありました。

タイムスタンプを更新しない事にしても、更新履歴としては記録されてしまいますので解決にはなっていないですね。
詳しい仕組みを把握していないので、わかりませんが今の仕組みで投票をするなら「該当ページの更新履歴だけ除外する」みたいな事をするしかないと思います。

(1) おそらく不可能です。
管理画面を見た感じ、そのような設定項目が見当たりません。
現状のブラックリストは、「コメント内容規制」という機能で、zawazawaに書き込まれるコメント全体が対象となります。
この規制機能には、コメントの行数制限・文字数制限・禁止ワード設定などが含まれ、その中のひとつに「禁止絵文字」という設定項目があります。

(2) 「禁止絵文字」にはおそらく上限はありません。
ただし、コメント全体が対象であるため、「禁止絵文字」に登録した絵文字は、コメント本文でも使うことができなくなります。

(3) ありかもです。
このままこの木で議論を続けるよりは議論がやりやすいかもしれません。

まとめて返信させていただきます
>> 225
こちらも正直ブラックリスト式の欠点がかなり目立つので戻してもいいかなという考えが強くなってきました

上で挙げた絵文字を追加するよりホワイトリスト式に戻したほうが賢明かなと思いますね
5択以上の投票をする場合は枝葉に分けてもらうほうが良さそうですが、最初の投票ページを作成した方にも意見伺いたいです

>> 227
リアクション者の特定・規制は可能です

>> 231
diff_logの一般解放は荒らしの差し戻しなどを管理者がいなくても発見しやすく・差し戻ししやすくするためですので、これをクローズするのは今の所考えていないです

>> 232>> 233
あまり使用頻度が少ない板を立てると管理が辛くなるので、長くなりそうな議論を行う議論板というものを新設してそちらで行うのはどうでしょうか?

diff_logとwiki内で行う投票の仕組みの両立が不可能で、diff_logの一般開放はしておきたいという事であれば、一旦諦めざるを得ないかなと思います。
（自分が見ている範囲だと、荒らしよりも編集合戦が熱くなったり勝手に検閲する人がいたりする方が問題としてよく発生している印象ですので、編集者の特定が可能になるというデメリットの方が大きい気がします。なので、「一般ユーザーがdiff_logを扱いにくい」という状態を受け入れて、wiki内の投票機能を使うのが一番良いかなと思っています。）
zawazawaを利用した投票については、wiki内の機能を利用した場合に比べるとかなり分かりにくくて使いにくいですが、妥協案としては良いと思います。
枝葉を利用する場合とリアクションを利用する場合を両方とも練習板の方で作ってみてあります。枝葉を利用する場合は表示コメント数を増やしておかないと流れて行ってしまうのと、荒らしではないにせよコメントが付いてしまうと形が崩壊するのが問題ですかね。

>> 241
リアクションに関する板は、私は一時的なもののつもりでした。
今回の件にのみ使用し、1ヶ月とか一定の期間後に凍結するというイメージでした。
しかし、今後の議論でも再利用できる議論板を新設するのもアリですね。
本来は編集相談板でやることなんでしょうけど…書き込みのハードルが高い雰囲気なので…

>> 244
1点、wiki内の投票機能のデメリットに気付いたのですが、あれって、同一ユーザーが同じ選択肢に複数投票できちゃいません？
zawazawaだと同じリアクションは1回しか押せない利点はあります。
なお、zawazawaには「同一ユーザーが複数の選択肢に投票できてしまう」デメリットがありますが、おそらくこれもwiki内機能でも同じかなと思います。

先程書き込んだときには気付いておらず、後から気付いたのですが、
こちらのコメントとリアクションを見る限り、もうホワイトリスト方式に戻す方向でいいように思います。

投票を実現したいという気持ちは分かりますが、投票よりも「常日頃のコメント投稿がしやすいこと」「荒れにくいこと」「コメントしている人たちがより多く求めているほう」を優先すべきと考えます。

いっそのこと、雑談板で「ホワイトリスト方式がいい人は👍、ブラックリスト方式がいい人は❤を押してね」のような簡易投票を開催してもいいのかもです。できれば早いうちに。

簡易投票を行おうかとも思いましたが、

• 既にいくつか攻撃的なリアクションを行っている人が散見されること
• 絵文字規制に切りがなさそうなこと
• 上で挙げてもらった様にホワイトリスト式の方がより支持されていると思われること

からホワイトリスト式に戻しました
ご迷惑おかけしまして申し訳ないです

結論としては『zawazawaの枝葉を利用した投票の仕組み』を使って「みんなの意見」ページを作る感じでしょうか？
もしそうなら、zawazawa板の新規作成をお願いしたいです。

投票の件とは話がずれますが、
リアクション絵文字の件は、おおよそこのような感じになりました。
本日実際に絵文字を変更し、雑談板での告知も行いました。

数日様子を見て、何事もなければ、議論板の該当の話題はクローズでよいと思います。
新しい議題のために空けておくもよし。
議事録としては残しておきたいですが、どのようにするかはお任せします。

@WakefulSpectさん
絵文字に関する方針を、暫定的にサンドボックスに書きました。
編集方針の「zawazawa」の項目に追加する想定です。
一度目を通していただいて、問題なければ編集方針に転記します。または転記してくださると助かります。

サンドボックスを確認しました
一点、編集方針ページの文体に合わせて常態(だ・である)から敬体(です・ます)に文末を統一していただければと思います
議論板Aは私がクローズしておきます

確認ありがとうございます
編集方針に、「リアクションについて」の項目を追加しました

フォーマットは引用することになったようですが、画像も移行ということで問題ないですか？

金曜あたりまで反対意見がなければ移行(※)したいと考えています。
(新しい寝顔も更新したいので)
※寝顔図鑑の一覧に画像アップロード、同ページ内の画像引用先の変更のみ

詳細ページからのファイル削除は新しいフォーマット適用以降になると思いますが、
削除は管理者のほうが一般ユーザーより楽にできたりしますか？
(そもそもバックアップごと消したほうがいいかもしれません)

削除は管理者のほうが一般ユーザーより楽にできたりしますか？

私が把握している限りでは、そのようなことはないと思います。
「複数ページの添付ファイルを一括で削除」みたいな機能はおそらくありません。
「バックアップごと消す」については、何か問題が発生した際に取り返しがつかなくなりますので、お勧めできません。

なお、複数ページの添付ファイルの一覧については、一般ユーザーでもアクセスできます。

作業としては、個々のページの添付ファイルから、あるいは上記の一覧から、該当ファイルの「詳細」をクリックし、遷移先（「添付ファイルの情報」ページ）から1つずつ削除する流れです。
量が多く大変ですので、新フォーマット移行後に、時間をかけてまたは複数人で地道に削除することになるかと思います。声をかけていただければお手伝いはします。

>> 290で話した通り、寝顔画像の移行（追加のみ）と更新を行います。

>> 308

「バックアップごと消す」については、何か問題が発生した際に取り返しがつかなくなりますので、お勧めできません。

自分はどちらでもいいですが、同じファイルが2か所にある必要はない（しかも使われなくなる）と思ったので、バックアップごと削除を提案しただけです。

>> 441
すみません。あの書き込みの時点では、「バックアップ」という言葉の意味を勘違いしておりました。
画像ファイルを削除した後に残る、添付ファイルのバックアップのことを指すのですね。

それは削除して大丈夫なのですが、添付ファイルのバックアップは実は管理者権限でしか削除できません（副管理者でも削除できません）ので、削除が必要な際はSpectさんに依頼していただければと思います。

寝顔画像の移行が完了し、更新を再開しました

バックアップ見た
スリープポイント換算においてポケサブレをノーマル交換所の価格で換算してたっぽいけど、それって適切なのか？
プレパス優先が当たり前で、入った上での評価だと言うならば、パックの内容もプレパス加入前提で、つまりポケサブレもプレミアム交換所のSP価格で換算すべきだと思うが
当然万能アメSも、プレミアム交換所の万能アメMのSP価格と効果量から換算しないと適切ではないと思う

そもそもダイヤで買う物をスリープポイントで評価すること自体適切なのか？とも思うし
プレミアム交換所の価格で比べること前提で、無理矢理スリープポイントをダイヤに換算するなら、色々計算して大体2SP＝1ダイヤと算出できるけども
計算式も書けるけど、それで他の人が納得するかどうかは分からないし、この計算が適切かは分からない
一応、この場合はサブスキルの種の価値は700ダイヤ、メインスキルの種の価値は900ダイヤってことになる

プレパス未加入を考慮外にしてプレパス加入前提で考えるとして、
結局種が足りてるか足りてないか、足りてない場合に来月まで待つか、足りなくて待てないから課金するかが買うべきか買わないべきかの境界線
場合分けすると、種が足りてるなら△（購入の意義は薄い）、足りないけど来月まで待てる場合も△（待てるなら購入の意義は薄い）、足りなくてしかも待てない場合は◯（どのくらい得かは要検証）かな
この3つの中で最も一般的なパターンを基本の判定にして、他のパターンについては備考に記述するのが良いと思う
種が足りてる人が多いのか、足りないけど購入を急がない人が多いのか、足りなくて待てない人が多いのか、どのパターンが一般的なのかね

もっと言えば、どうせ「パック買う前にプレパス入るのは当たり前」「プレパス入った上での評価をする」という話であれば、
パック関連のみ基本的にプレパス加入前提の評価にして、プレパス未加入の場合の記述はなるべく避けるという方針も必要かも知れない（まずプレパスに加入しろという結論にしかならないし）
この方針がないとプレパス未加入の場合は～と毎回考慮して書かざるを得ないので
しかしこの方針だと、「完全無課金で、無料ダイヤだけでパック買う人」には申し訳ないことになるけど、そういうプレイスタイルの人はどのくらいいるんだろうか

①単品売りされていないスリープポイント限定アイテムをダイヤ換算で評価するか
スリープポイント換算の評価は記載しても問題ないと思いますが、具体的な数値を記載するかは計算式等の議論が必要そうなので、一旦後回しで

②結局種が足りてるか足りてないか、の境界線
一般的かどうかは自分だけではなんとも言えないので難しすぎる
評価は人によって意見が分かれるので、
交換所のアイテムと違い、定期的に新しいパックが出るので評価が難しい...他のプレイヤーの意見を参考にするために投票所がほしくなります。
大体のプレイヤーにはサブレ買うついでにスキルの種が手に入るのは嬉しいことだと思っているので◯でいい気もしますが。

サンドボックスに投票所作って試し置きしてみます。投票所を実装するかどうかはもう少し議論が必要そうですが。

それと、本文に「来月まで待つか」と書くよりは、「毎月の交換分だけで足りる場合は」に言い換えれば文章のボリュームを減らせると思います。

「スリープポイント換算のコスパは優秀だがサブレだけで見ると単品で買った場合と変わらない。貴重品のスキルの種が必要かどうかで判断しよう。
毎月の交換分だけで種が足りてるなら△、種が足りてなかったり買いだめしておきたい場合は◯」

②この方針がないとプレパス未加入の場合は～と毎回考慮して書かざるを得ないので〜

今回のパックを無課金の方が買いたい場合も種が付属していることをどう捉えるかに落ち着くので②の書き方でいいと思います。

・無課金が貯めたダイヤで購入する
・プレパスとダイヤ課金を辞め、余ったダイヤで購入する

↑の2つはダイヤ配布の渋さから考えてレアケースなので、よほどパックの内容がお得でもない限り毎回考慮するのはキリがなさそうです。
個別ページ「デイリーギフトの確率調査」でも、50や100ダイヤは滅多に当たりませんし。

表の上に
※価格が安かったり、無課金でも交換したほうがいいほど内容が良質な場合を除き、プレミアムパスに加入している前提で評価しています
と書きたすだけでいいと思います。

ただ、新しいルールを敷くことになるので、管理人に相談かな?

種の必要性は本当に人それぞれなので、他の人の状況は聞いてみたいところです
ちなみに自分はメインサブ共に種は足りてます

どちらかというと、常に必要で緊急性が高くすぐ欲しい待てないという状態になりやすいのはサブレなので、「とにかくサブレを安く買いたい」という人は多いと思います
なのでサブレを安く買えるパックの評価を高めにするのが良いのではと個人的には思います

ルール制定については、このくらいなら今のところ反対意見もなさそうですしやってしまっていいと思います
とりあえずショップのページにそのルールを書いてみて、異論があれば一度差し戻して再議論という形で

追記：いやちょっと待ってください
100ダイヤとか250ダイヤとかの格安パック、600ダイヤくらいの安いパックもありますね
このくらいのダイヤの支払いなら、無課金の無償ダイヤでも買う可能性はありそうです
価格で閾値を設けた方が良さそうですね
1000ダイヤ以上の価格の場合だけプレパス加入前提にするとか

パック購入するべきか否かの評価等は不要なのでは？
ダイヤあるいはスリープポイント換算で、「このパックはどれくらいお得か？」というのを書く分には良いと思いますが、それ以上の記載の必要性は感じないです。
正直に言って、スリープポイント交換所にある評価の欄も必要性を感じないですね。評価という項目ではなく、ほかにどんな入手手段があるか？という客観的な情報を載せるに留めておくべきだと思います。
（実際に評価が分かれる例は多くあります。以前ノーマル交換所のばんのうアメの評価が×だったことがありますが今の評価と違っていますし、フィールドいどうチケットは◎になっていますが、私は交換する価値はほとんどないと思っています）

まぁ◎でもそのアイテムを使わない人は買う必要はないですからね
あくまでコスパ的に得かどうかというだけの話なので

確かに、評価の欄そのものを消すという方法もあると思います
評価って荒れる元になりがちですし
もちろん、評価があった方が購入の参考になるという人もいるとは思いますが
初心者とかは評価欄が欲しかったりするんでしょうか？

それなら、レイアウト変更の方が本質に近い気がしますね。
おてつだい時間や食材、メインスキルや所持数などの基本的なパラメータを画像の隣かすぐ下に書いて、ページの下の方に「考察」とか「概要」みたいな項目を用意する感じが良さそうな気がします。

>> 196よくある相談にこれほどの情報が集まっているとは知りませんでした。記載されているポケモンについては、ポケモン個別ページからリンクを飛ばすと良さそうですね。同じポケモンの情報がwiki内でバラけてしまっているのは、スキルや食事、育成法などの「観点」ごとにページが作られている弊害かもしれません。wikiの構造に関わる大きな問題だと思いますので、別のツリーでしっかり意見を交わす必要がありそうです。

＞同じポケモンの情報がバラバラなページに記載してあって

これ非常にマズい状況なんですよね
ポケモンだけじゃなく、同じサブスキルの情報が色々なページに散逸していたり、
同じ食材の情報が色々なページに散逸していたりしないでしょうか

これを危惧していたので編集方針にもそうならないよう追記してもらったんですけども
まぁ時既に遅しと言われればそれまでなんですけどね

そうですね。すでに「あのことについて詳しく書いてあるページあった気がするんだけどどこだったっけ？」ってよくなるので、整理の必要性は強く感じます。

1つの話題はなるべく少ない箇所にまとめて、他のページで書きたい時は埋め込み機能を使う
なるべくこれを徹底していきたいですね

一旦バンギラスこれまでの記述はバンギラスの個別ページに折り畳みで戻しておいて、まとめる方向性で話を進めたいですね。
厳選のページにあるポケモンごとの厳選基準の考察とか、エナジーチャージのページにある比較、おてつだいサポートのページの検討あたりもうまくまとめていけると良さそうです。

「そのページのテーマだからこそ書けること」がおおよそ出尽くしたので、どのようにうまく集約していくべきかを検討する段階になったような気がしますね

一旦削除されていた部分をfoldで残して見れるようにしておきました。
ひとまず、下の木でポケモンの基礎データを見やすくまとめる方針を決めたいですね

ありがとうございます！

一応、言い出しっぺとして具体的なレイアウトの提案だけしておきます。ポケモンの詳細な説明（あるいは性能考察と呼ぶべき内容）は、進化関係の一つ下、かつ出現フィールド一覧の上にあると良いのではないかと思っています。理由は、性能考察をなるべく基礎データの近くに配置したいのが一つ。そして出現フィールドと寝顔一覧は、ポケモンの性能とはあまり関係がないと考えているためです。

このレイアウトだと、食材がABBの時に3枠目の個数が分からなくなります
ABAやAABの時も知識がないと分からないので初心者に優しくないです
枠については今の方が良いかと

月並みな感想ですがとても便利そうで良いと思います。
このプラグインって&attachrefの挿入も可能なんでしょうか？(きのみと食材の部分を想定しています。アイコンページの日本語ファイル名の方の画像を使えばいけそうな気が…？)

このゲームの設計上仕方ないのですがホリデー追加ポケモンのページは情報が出揃うまでに２日ほどかかっていたので、#trackerプラグインを使うとなるとページ作成のタイミングは決めておく必要がありそうですね。

一応サンドボックスの方のデザインも変更してみました。必要な情報は一通り集約したつもりです。
もっと見やすくすることはできると思いますし、trackerを使って作ることは考えていなかったので、たたき台として使ってもらえたらと思います。

う～んこの…いかにも日本人が作りそうな、デカい四角を用意して、その中でExcelの枠線と結合を駆使して詰め込みました的な感じの見た目ですね…
こういうデカい四角の中に大量の枠線を入れた文書や申請書は役所等でよく見かけますが…デカい四角の中に全部の情報が詰まっているので見にくい感じもあります
データを入れる場所にも法則性がなく、欲しい情報を探すのに時間がかかるので、ユーザーのストレスになります
1回1回は僅かな差でも、色んなポケモンを見比べるとそのストレスの差は馬鹿になりません
何だか悪口みたいになってしまって申し訳ないですが…

>> 234とっても具体的なご提案がありそうなことはお察ししますが、ちょっと文字だとイメージが湧きづらかったのでサンドボックスに「その案」を作成していただいてもよろしいですか？
自分も考え中ですがいろんな方の案を見てそれぞれの良いところを取り入れて、閲覧者の方が見やすく、かつ今後も編集・維持しやすいテンプレートができればいいなと思っています。

むしろ全体的に作り直して、「ポケモンページのテンプレ」みたいな感じでサンドボックスに作ってみてもいいですか？
問題が枠線だけにあるわけではないと思うので
時間はかかるかも知れませんが…クリぼっちなのでこの土日にでも作るか…
あと、自分はデザインの腕前はあまりないので、「ここをこうしたいんだけど…」みたいな感じで誰かにお手伝いして貰いたいこともあるかも…

こうしてみると項目名長いですね。
略称かアイコンにしてツールチップをつけるのはどうでしょうか？

プログラムとは…？ 100ページ以上あるポケモンページを作り直すのは骨が折れるな…と思っていましたが、Wikiにそのような機能があるのですか？

編集画面（構文ハイライトON時）に置換機能はありますね
また、wikiの編集フォームだけでやろうとせず、テキストエディタなどにコピペして作業することで、高度な挿入や置換ができる場合があります
表などは「いったんエクセルで作る→テキストエディタにコピペ→区切り文字のタブ文字を|に一括置換」などでかなりスムーズに作れますし

置き換え機能で全部ポケモン分の作業をやるのは結構辛くないでしょうか？
テキストエディタでやるとして、その方法は誰でも作業が出来るように共有できますか？

ポケモンのページに情報を集約するというのには大賛成なのですが、
編集が大変なあまりにレイアウトを提案した人が100ページ以上をすべてひとりで作業することになったり、中途半端なところで作業が投げ出されてポケモンによってレイアウトがバラバラ…ということにならないかが心配です。

レイアウトさえ決まってしまえば、基本的にコピペしていくだけなのでそこまで大変でも無いと思います。
『ページ移行中』みたいに全体にアナウンスしておいて、1週間も時間作れば十分じゃないでしょうか？

議論板が空いているそうなので、今まで出ている案、これから出されるであろう案をまとめて整理しつつ議論しましょうか

便利で助かります！ありがとうございます

補足ありがとうございます！考察の検討中の記述は共通項として下の補足事項に移動しておきました。
案６については「データは上の方にまとまっていてほしい」で意見が一致していた複数の編集者の案を集約したものなので、とくに補足は無いんじゃないかと思います～

それもそうかも知れませんね。補足が無ければそれはそれで。

案６のcontentsxをやめて項目へのリンクにしてみたら122ms→84.3msに改善されて、案５(96.8ms)と大差ない感じになりました！　contentsxって結構重かったんですね…
各ページの負荷は軽い方が良いのはごもっともですし、

考察, 厳選, 使用感の3つを即座に移動できるような目次を作成し、「考察」の下辺りに配置するのはどうでしょうか？仮に文章が長くなり過ぎてしまったとしても、知りたい情報（文章）にすぐ飛べるよう設定しておくこと

という意見(議論板B#110)を取り入れるだけならわざわざcontentsxを使わなくても大丈夫でしたね。

「考察」の部分だと思います。
特定の睡眠タイプを狙って睡眠計測をしたり、分割睡眠や絶食厳選を積極的に推奨したくは無いので、「○○のフィールドで出現しやすい」とか「○○だと出現しない」みたいな情報を軽く扱う程度で良いと思っています。

案5だとフレンドポイントの記述は「仲間にする」の項目にだけ書くので重複はしていないと思います。
文章作成にルールを設けると編集を重ねていくうちに消えたり、どこに情報があるか分からなくなったり、変更があった場合に修正が難しくなるので避けたいです。

案5の一番上の表が繋がっていないように見える

これは後で修正できると思います。

待ってください～！

案5の一番上の表が繋がっていないように見える

そう思うということはスマホでの閲覧かな？と思うのですが、これはPCで横並びにしている(縦幅を抑えるためにflex_boxを使っている)影響なので、表をピッタリくっつけることはできません。
案５だと右ブロックが一行しかないので、余計にそう見えますよね…ちょっと書式指定を考える必要がありそうです。

離れている部分は、経験値タイプと博士に送った時のアメの数
この2つは、他の種族値的なデータとは分類的にも違うものですし、分離していても問題ないのではと思います
むしろ、見た目は少々不格好だとしてもそこは分離したほうが分かりやすい可能性もあります
つながってないのは案6も同じですし

案5の左上の表（スマホなら一番上の表）がとてもいい

ありがとうございます。この表は案6にある表とほぼ同じものですが、お手伝い時間とかメインスキルを一つの表にまとめた方が良いという事ですかね。

そうです！
「とくい、お手伝い時間、きのみ、食材、所持数、メインスキル」
これらが合わさって「ポケモンの性能（本編で言う種族値みたいなもの）」になるわけです
これらが一つの表にまとまって配置されていると、性能を見たい時に役立つし見やすいです

投票はいったん止めていただけますか？

というのも、現状で既に編集差分ログに投票ページの更新がたくさん載ってしまっています。
以前問題になったときに比べて票数が少ない＝現時点ではログに流れた回数も少ないとはいえ、これを許してしまうと、「じゃあこの投票も人数が少ないだろうからOKだよね！」みたいになって線引きが曖昧になってしまいます。

ここ（編集相談板）の過去のやり取りで、おおむね「wiki内の投票機能は使用せず、zawazawaを利用して投票を行う」という流れになっていましたので、今からでもそのようにしていただきたいです。

そのために必要なzawazawa板の話は後述します。

zawazawa板新設の話です。

kさんは>> 257さんですよね。すみません、あのコメントを無視したわけではなく、あのときはまずリアクションを整備することを優先しており、板の新設を後回しにしておりました。
まず前提として、板（トピック）の作成はログインユーザーなら誰でもできます。編集相談板などで相談し、合意が取れたのであれば、管理チームでなくても建てていただいて大丈夫なものです。→編集方針

肝心の板の新設ですが、どのようにしましょうか？
「みんなの意見板」のようにしますか？
それとも、今回のような投票に使えるように、「投票板」のようにしますか？

一旦停止しました。
diff_log(編集差分ログ)に関する個人的な意見としては（こちらも完全にスルーされていましたが）

（自分が見ている範囲だと、荒らしよりも編集合戦が熱くなったり勝手に検閲する人がいたりする方が問題としてよく発生している印象ですので、編集者の特定が可能になるというデメリットの方が大きい気がします。なので、「一般ユーザーがdiff_logを扱いにくい」という状態を受け入れて、wiki内の投票機能を使うのが一番良いかなと思っています。）

という意見です。
現在活発に動いているwiki内のコメントを利用したページというのもほとんどないですが、投票だけでなくwiki内コメントによっても編集差分ログは流れてしまうので、投票だけでなくコメントも含めた編集差分ログの扱いをしっかり定めておく必要はありそうです。

まずはご対応ありがとうございます。お手数おかけします。

なるほど、diff_logが見づらいことは許容する、そもそもwiki内コメントによっても流れるのだから投票で流れようが同じこと、というようなスタンスでしょうか。

正直なことを言いますと、実は私自身、普段まったくdiff_logを見ていません。
ただ、diff_logを普段から見ている人が複数いて、その方達が「流れると困る」と言うのなら、当事者（普段見ている人）の意見を尊重すべきと考えていました。

しかし、改めて>> 171のツリーを読み直してみたところ、
「diff_logが流れても構わない派」がkさんと5ab84@62cc8さんの2名、
「diff_logを投票で流さないでほしい派」がSpectさんのみ、
のようでした。
他にdiff_logを見ている人、流さないでほしい人がいるのかどうか。いないのなら、wiki内投票を使ってもよいのかもしれません。

なるほど、diff_logが見づらいことは許容する、そもそもwiki内コメントによっても流れるのだから投票で流れようが同じこと、というようなスタンスでしょうか。

というよりも、例えば検証でよく用いられる「コメント欄を利用したデータ収集」などを行うと投票と同じように多くのログが生まれてしまうので、「投票をどうするべきか？」よりも「diff_logをどうするべきか？」の方が重要だろうということですね。

荒らしが発生した際に被害の全容把握が一般ユーザーには難しいという問題はありますが、荒らしの出現頻度は低いですし、「荒らされているページを見つけたら管理人に報告する」とすればdiff_logが無くても問題はないと思っています。

私もwiki全体の編集差分ログを参照することは無いので、他にどんな使い方があるのかは把握していないです。

投票所を慌てて作る必要はないと思います
ログの件もそうですが、投票所はしっかり内容を練ってから公開すべきかと
せっかく詳しい説明があった案の特徴も投票所にはなかったし、その辺拙速だった感もあります

「投票をどうするべきか？」よりも「diff_logをどうするべきか？」の方が重要だろうということ

なるほど。一番の焦点はここなのですね。
しかし、このままdiff_logを見ない人同士で話をしていても答えは出なさそうに思います。
「diff_logをどうするべきか？」については、改めて議論していく必要がありそうです。

とりあえず、まず今回の投票の件に絞って見た場合、今取れる選択肢は、
①diff_logを見ている人を交えて議論を行い、解決するまで投票中止
②投票を再開。diff_logを見ている当事者から何か言われたら、そのとき改めて対応する

私は②でいいかなぁと思います。（追記）
そもそも、当事者が何も言っていないのに、当事者でない私が投票をストップさせるべきではありませんでしたね。申し訳ありませんでした。

追記：
投稿が前後してしまいました。
「投票所自体をもっと練ってからやり直す」案、いいですね。

ログの件もそうですが、投票所はしっかり内容を練ってから公開すべきかと

それはそうですね。編集相談板だけでもそれなりに反響があっていろんな意見が集まる気配があるので、投票の実施はまだ先送りして良さそうです。

それはそれとして、みんなの意見等の投票ページについては「diff_logを参照できなくて困っている」という具体的な意見が挙がるまでは解禁していいのかなと思っています。

自分は時々diff_logを見る派ですが、「みんなの意見」の問題点は無期限＋複数の質問があり大量に投票(編集)が入ることだと思うので、ごく短期間(たとえば今回設けていた50～100票で終了という制限つき)であればtvoteプラグインでもいいのではと思います。

>> 275これを許してしまうと、「じゃあこの投票も人数が少ないだろうからOKだよね！」みたいになって線引きが曖昧になってしまいます

しかし、上記もたしかに考慮すべき点であると思います。

個人的にはzawazawaで「投票板(みんなの意見)」を作成してリアクションで投票＋(すべての意見を完璧に取り入れられるわけではないという注釈をつけて)意見がある場合はコメントをしてください、とするのが今後も使いまわせて良い気がしますがいかがでしょうか？

投票だけでなく、wikiwiki式コメント欄についても併せて編集方針を定めておく必要があると思います。
（デイリーギフトやゆびをふるの検証等のように大量のwikiコメントが予想される場合にはzawazawaを推奨するなど）
zawazawaでの投票のデメリットとして気になっているのは、コメントが書き込まれると流れて行ってしまう点と投票としての見にくさですね。
枝葉を利用した投票だと何が質問でどこまでが選択肢か分かりにくいですし、票数も確認しにくいです。
ただ、不便ということ以外に問題はなく、投票の仕組み自体は実装可能だと思うので、wiki内投票を禁止するという措置が下されるのであれば妥協も止む無しという感じです。

diff_logについてお答えします
>> 277

>> 282

>> 285
trackerについて、どのような編集・操作が必要が教えていただければ対応します

その他質問等も受け付けます

「diff_logを一般ユーザーが使いやすい」状態における問題点として挙げた内容は例えば通報合戦や晒しみたいなことが起こる事への懸念ですね。私としてもそこまで深刻な問題であるとは思っていません。
言いたいこととしては「一般ユーザーがdiff_logを閲覧しやすい状況」というのが手放しで望ましい状態ではないため、「diff_logを一般ユーザーでも閲覧しやすい状況を維持することの明確なメリット」が必要だろうということです。

管理者のみ閲覧できる方の編集差分ログにおいて、『voteやtvoteによる編集』を除外した差分の確認も困難であるとすれば上述の「diff_logを一般ユーザーでも閲覧しやすい状況を維持することの明確なメリット」として十分だとは思います。（うまくvoteによる編集ログだけ除外する方法があるはずだと思うのですが、自分では見つけることができませんでした）
荒らしに対してそこまで迅速な対応が必要だとは思いませんが、「投票を実装しないことで迅速な荒らしへの対応が可能である」とするなら『投票を実装することを制限する』という措置にも一応の納得感はありますね。

管理画面の編集差分ログは正規表現が使えない検索機能のみとなっており、以前あまる氏が提示されたCSSが利用可能かもしれない、といった感じですね
当方が最も利用する環境がiOSですためCSSは難しい(ショートカットAppを利用する手があるのは存じていますが毎回実行する手間を考えると厳しい)と思われます
紆余曲折ありながらも投票はzawazawaで行えるという見解で一致したことを踏まえると、投票はzawazawaでお願いしたいと考えています

余談ですが、先ほど思い出したdiff_logの利点に「先頭に:が含まれるページ」を除外表示しないというものがありました
RecentChangesや最新n件では除外されるため、#trackerの設定ページなどが荒らされると気づきにくい、というニッチな利点もあります
あまり有効な意見では無いかもしれませんが、一応記しておきます

>> 297について挙げられたものはすべてフォーム化可能でした
ポケモンの説明など他にもフォーム化できるものもありそうです
なので、フォーマットが確定したタイミングで教えていただければ必要そうな事項を見繕ってフォーム化しますね
ちなみにページの作成タイミングにもよりますが、入力事項は空白でも動きはするのですべて埋め尽くす必要もありません

また>> 296で挙げられていた「同系統のポケモンを並べて表記」もうまくいきました
サンドボックスに雑ですがフォームを設置しているので試してみてください

trackerテストありがとうございます！フォーム化してうまく動きそうなのでこのまま進めても大丈夫そうですね。

一点疑問なのですが、trackerフォームで作成したページって見出しのアンカータグの文字列までは指定できなさそうですか…？
>> 263で「考察」部分に使っていたcontentsxを軽量化のために

-[[厳選基準考察>./#select]]
-[[使用感・育成相談>./#experience]]

と見出しのアンカータグにジャンプできるように変更していたのですが、
trackerで作成したページのアンカータグがランダムな文字列で生成されてしまうのであれば、contentsxに戻した方が良いのかな？と思っています。
少々処理が重くはなってしまうものの各リサーチフィールドのページと大差ない処理速度ですし、できれば多少の重さよりは利便性を重視した方が良いように思います。いかがでしょうか？

仕様かバグか不明ですが、仰る通りアンカー文字列の指定ができないようです
wikiwiki運営は非推奨プラグインとしているようで修正には期待できないので、手動でアンカー文字列を修正するか#contentsxを利用していただければと思います

見出しのアンカー([#pokemon_data])は勝手にランダムの英数字に変わりますが、
#aname(pokemon_data)は変わらなかったので
同じことはできます。

案6-3の「考察」部分で試してみたところできました！anameって見出しにも使えるんですね。知らなかったので勉強になりました
テンプレートに組み込めるのであればcontentsxに切り替えなくても大丈夫そうです。ありがとうございます。

スーパー優柔不断で申し訳ないのですが理由や>> 268の木を見るとその並びその方がいいのかも～と思えてきたので案６も変更してみました。
もともとこの案６を作成してくださったkさんも案７でこの順番にしているので良いかと思っての判断です。
（もし元の案６の方が良かった…という方がいらしたら戻せますので遠慮なく言ってくださいね！）

そしてこの話は議論板Bに戻って書いた方が良さそうなので、一旦議論板Bに戻りますね。

お察しの通り、表の順番には何のこだわりも無いので問題ないと思います笑

それなら大丈夫ですね。了解です！

入れ忘れ…ですね！足しました～

SP算出に用いられる変数です。この変数の値自体は検証だけで無く解析でも明らかとなっていて信憑性が高いとされています。
『スキル変数=スキルの価値*確率の数値』として考えられていますが、スキルの価値や確率の数値に信憑性の高いデータが無かったため、スキル変数という項目が残っています。
ただ、スキル変数という値自体検証でしか用いないので、無い方が良いかもしれませんね。
検討してみます。

古い（既存）モデルの考え方

スキルSP = 共通係数 × スキルエナジー(SLv1) × スキルレベル補正 × スキル確率
スキル変数 = スキルエナジー(SLv1) × スキル確率

解析に基づいた考え方

スキルSP = 共通係数 × スキルエナジー(SLv込) × スキル確率

考察の目次は先日も書いた通りこちらの意見を取り入れたものですね。

考察, 厳選, 使用感の3つを即座に移動できるような目次を作成し、「考察」の下辺りに配置するのはどうでしょうか？仮に文章が長くなり過ぎてしまったとしても、知りたい情報（文章）にすぐ飛べるよう設定しておく

考察・厳選は長文になることがあるため、自分も（とくにスマホでの閲覧を考慮して）クイックアクセスとなるものは必要だと思います。
「目次っぽいのがなんか変」ということでしたらデザインの変更は可能です。試してみますね～

その点は自分も気になってはいました。今後検討しようと思います。

今考えているのは、見出し自体をいじれないかなぁ…と。
例えば、

• データ　　　　▼
• 考察　　　▲　▼
• 厳選　　　▲　▼
• その他　　▲

みたいな感じにして、上向きの▲を押すと1個上の項目にジャンプ、
下向きの▼を押すと1個下の項目にジャンプ
みたいな感じにできないかなぁと思ったりしてます

やってみました

>> 323
なるほど、クイックアクセスが必要とのこと、理解しました。

>> 324
（もう実装されてる！）上下の項目にサクッと移動できてよいですね。
「▼を押すと次の項目に移動できます」のような案内表記がありませんが、なくても大体分かってもらえます…よね？

こういう仕様はよくあるものですし、何も知らない人でも一度触れば分かる…はず

• スキル変数は別ページから引っ張ってきているものだったと記憶しているので、ポケモンページに引用する時だけ消すことができるかどうか詳しい方に聞く必要があります
  ただ、そのような処理は更新が大変になる可能性が高く、メンテナンス性を低下させることは間違いないので、個人的には「ただ引用するだけ」の方が今後もメンテナンスしやすいと思います
• きのみエナジーについては欲しいという意見があったのでとりあえず入れましたが、最終的に入れるかどうかは要検討と思います
  今後きのみエナジーが変更されることがあるかどうかは分かりませんが、きのみエナジーの記載は無い方がメンテナンス性は高いです
• 説明文の内容についてはあくまでサンプル、仮であり、テンプレが完成し移行完了した後に皆さんに上手く編集して貰えればと思います
• 投票については全体的に不要という方向へ意見が傾いていることを認識しております

ご意見ありがとうございます。

基礎データの中身ですが、先にご指摘の方がいらっしゃるようにスキル変数は分からない方も多いと思いますし、推定確率さえあれば情報としても多くのユーザーにとっては不要なため、記載しないか、するとしても何を意味するものなのか分かるよう注釈をつけた方が良いかと思います。

スキル変数については元の参照している表の時点で質問が絶えず、検証のページに記載しておけば十分と考えたため削除しました。

またきのみエナジー効率を載せるのも少し違和感があります。ポケモンの総合的なエナジー効率を厳密に計算する場合はスキルや食材も加味する必要がありますし、特にスキルとくいや食材とくいの場合はきのみエナジー効率だけ提示されても、上級者には大して役に立たない、初心者には却って誤解を生みかねないだけな気がします。そもそもごく簡単な計算で算出できる情報ですし、きのみの数sの有無によっても変わってしまう情報です。総じて今の表記の仕方だと実際の運用上は役に立たないデータになってしまうのではないかと思いました。

厳密なエナジー効率を示す指標にはならないというのは正しいと思いますが、大まかな強さの指標としては適切なものだと考えています。
「ヘルガーとラッタはどっちがどれくらい強いのか？」のようなことを考える際に有用な他の指標も無いですし、あって困るものではないでしょう。
初心者の場合「お手伝い時間が短ければ強い」と考えている場合が多く、それよりは「きのみエナジー効率で優っていれば強い」という認識を持ってもらった方が良いと思います。（それに、きのみ得意の場合はおおよそ正しい認識と言えるはずです。）
食材とくいやスキルとくいの場合には適切な指標とは言えない部分も大きいですが、重大な誤解を生むという事も無い気がします。

次に考察及び厳選の内容について、考察というものの性質上仕方のない部分かとも思いますが、なるべく客観的な情報の記述に留められた方が良いのではないかと感じました。例えば「ニンフィアと比べられることが多いが決定的な差があるわではない」との記述がありますが、今後レベルキャップが解放された場合などおてつだいスピードや所持数の差が明確な違いを生む可能性もあります。おてつだいスピードの違い、最大所持数の違い、それぞれのメリットデメリットを述べて比較するに留めるか、せめて「現時点では決定的な差はないと考えられている」などと、事実と主観を明確に区別出来る記述にして頂けるとありがたいなと思います。

現時点でニンフィアとプクリンの間に決定的な差があるわけではないというのは客観的な情報だと思います。『現時点で』の文言を必ず入れるというのは冗長だと思いますし、大きな仕様変更があった場合に評価が変わるのは避けられないので、気にしすぎる部分ではないように思います。
基本的には現行のバージョンでの仕様や仕組みに基づいて記載して、逆に『3枠目の食材が解放されて所持数等の仕組みが今と何も変わらないと仮定すると、○○%分スキル確率に差が生じるため、△△の方が優れていると言えるだろう』のように未解禁の要素を書く場合にどのような仮定での考察なのかを明記しておけば十分だと思います。
勿論、主観的な情報（例えば、「プクリンよりもニンフィアの方がかわいい」とか「ニンフィアの方が進化が大変なのでソーシャルリサーチで自慢できる」など）を厳選の項目に書くべきではないという点には同意します。

この返信内容はあくまで私個人の意見です。思ったこと、感じたことを明確に表現していただけるのはとても参考になるので助かります。
改めてコメントありがとうございます。

それと、寝顔一覧については、
・そもそもネタバレの要素が大きいデータである
・頻繁に見るデータではないし、あんまり必要とされるデータでもない
・他のデータと同時に一望する必要性、上方に配置する必要性が低い

等々の要因があるので、初期の案に回帰する話になりますが、
無理に左右に分けなくても、寝顔一覧だけ一番下の「その他」に配置すれば良くないか？
と、今日になって思いました。

寝顔一覧だけその他に回した案がこれです

サンドボックスにある新しい出現フィールドの表で表示することはできますか？

それについては出現フィールドの表をどうするか決着してからの方が良さそうですね
あちらの結論が出るのを待ちましょう

>> 337
全角を用いたとして、ランクやフィールドで検索して出現ポケモン一覧にたどり着いたとします。
それで何かできるとは考えにくいです。

そもそもどういうケースを想定していますか？

検索しやすさはwikiとして最低限必要な機能かと思います。
どのような意図で検索するかは人それぞれですし、将来的にどのような形で検索が必要になるかわかりません。
編集方針に「公式で使用されている単語を使うようにし、漢字変換や俗語を使用するのはできるだけ避けるように」と書かれているため、半角、絵文字、略称は避けた方がよろしいのではないでしょうか。

>> 345
それを理解するには>> 339でも確認している質問に答えてほしいです。

1. どういうときにランクやフィールド名の検索に出現ポケモン一覧にたどり着いてほしいか
2. たどり着いたあと、同じランクやフィールド名のページ内検索すると、ヒット件数が数十あるのですが、それに何の意味があるのか

厳選のページは一部もしくは半分以下ほどですが該当するものもあります。
省略せず、おてつだいスピードと書いたものは自動で用語へのリンクが貼られているのに対して、おてスピと書いた場合はリンクが貼られていません。
絶対に使うなとは言いませんが、ルールに則って極力控える方向で考えた方が良いと思います。

現時点でもフィールドごとに表が分かれているため表内に名称を追記する必要性は低く、追記する場合は横に長くなるのはやむを得ないと思います。

少なくとも半角と絵文字はメリットよりもデメリットが上回るため反対です。
略称に関しては、どうしても使用する場合はポケモンの一覧を参考に
・冒頭に解説を記述する
・冒頭の解説が長くなりすぎない程度に収める
・フィールド名のような将来的に増えることが想定されるものには使用しない
あたりに留意してはいかがでしょうか。

>> 351さん、>> 350さんの質問にもご回答いただけましたら幸いです。

現時点でもフィールドごとに表が分かれているため表内に名称を追記する必要性は低く

この一覧表は各ポケモンのページにもこのように引用して表示されており、そこではフィールドを色分け以外で判別できる要素がありません。
最初にも書きました通り

1. リサーチフィールドが増えていった時、似たような色が増えると紛らわしくなる
2. 色覚が特殊な人は見分けが困難になっていく
   という観点から、色以外でもリサーチフィールドを判別できる要素はいずれ必要になってくるかと思います。自分はとくに②を問題視しています。

略称に関しては、どうしても使用する場合はポケモンの一覧を参考に
・冒頭に解説を記述する
・冒頭の解説が長くなりすぎない程度に収める
・フィールド名のような将来的に増えることが想定されるものには使用しない
あたりに留意してはいかがでしょうか。

これについては編集方針の追加に関わってくるかと思いますので、管理人さんのご意見をお聞きしたいところです。

1. リサーチフィールド名の併記
2. 略称を使わない
3. スマホ閲覧での使い勝手を今までと大きく変えない

上記の３点を満たすためには「一覧の一番右にセルを追加し、リサーチフィールド名をフルネームで書く」とするのが最良なのではないかと思いますがいかがでしょうか。

上記にて御指摘の通り略語については使用の一律禁止とすると文が面倒になりますね。
ただ、だからといって無秩序に略語を許可してしまうと「どう略すか」が編集者間でバラけて派閥というか流派というかが出来てしまうリスクがあると思います。

ポケモン名を略すことは一律禁止（例：ライチュウとピカチュウを～→ライピカを～）としてしまえば、残る対象語句は懸案のエリア名やサブスキル、おてつだい時間といったシステム名称くらいと思いますので略語のホワイトリストを作ってしまうのはいかがでしょう？事前準備がちょっと面倒なのですが編集ルール作成の範疇かなと

だからといって無秩序に略語を許可してしまうと「どう略すか」が編集者間でバラけて派閥というか流派というかが出来てしまうリスクがあると思います。

ルールが新しくできると編集のハードルが上がってしまいますし、線引きがややこしいので避けたいですね。あったかジンジャーをジンジャーと略したり生姜と略したりしますが、どちらでも伝わるので問題は無い気がします。流石に「たかジン」とか書かれていたら修正するべきだと思いますが、この略称が流行って皆に伝わるという事であれば規制するほどでは無い気がします。
ただ、将来的にあったかジンジャーが突然ひんやりニンニクみたいに改名したりすると管理が大変という問題はありますので、ゲーム内容語一覧に対する逆引きリスト（「あったかジンジャーの略称としてジンジャー、生姜があるよ」とか「おてつだいボーナスの略称としておてぼ、おてボがある」みたいな）ものは余裕がある時に作っておく価値はあるかもなと思います。

それはいいですね
非公式な用語・略語にまとめておくとかで、ゆる～く方向性を示すくらいがよさそうです。
御指摘の通り厳しくし過ぎると編集ハードルが上がって誰もいなくなった、を招きますし。

1. 色覚が特殊な人は見分けが困難になっていく
   これについては完全に同意です。
   引用までは考慮に入れておりませんでした。失礼いたしました。

350さんのおっしゃるとおり「一覧の一番右にセルを追加し、リサーチフィールド名をフルネームで書く」に概ね同意です。概ねと書いたのはセルの位置は長くなるため右寄りが良いと思いますが個人的には一番右にはこだわらないためです。

>> 350さんの質問にについては、出現ポケモン一覧に限定したお話でいえば検索に関する問題は極めて少ないと思います。ただし、サイト全体で見た場合、他のページでは問題となる可能性が出てくると思います。

そのうえでサイト全体の統一性を保つことも考えると、極力編集方針に沿って編集するのが望ましいと考えています。

半角と絵文字の使用は文字化けの原因もあり反対ですが、略語については一切使用禁止とは思っておらず、Azumaさんとほぼ同意見です。
編集方針の「できるだけ」使わずの運用方法の問題かと思います。

現行の出現ポケモン一覧もそうですが、基本的にこれらのページを直接閲覧することはないはずです。
ページを分割すると管理や引用が難しくなりそうです。

>> 388
「直接閲覧しない」はその通りで、アクセスが極端に少ないならいいよねって、負荷の観点から言えばそうなんですが…
ある日突然行数オーバー（または容量オーバー）になって新ポケモンを追記できません！という日は必ず来ます。そうなってから対処してもいいんですが、その際には一覧表を引用しているあらゆるページの引用部分に対し、書き換えが必要になると予想されること、そして今ちょうどポケモンページのフォーマットに手を入れている最中なので、やるなら今では？というのが私の考えでした。
「実際に容量オーバーで追記不能になってから対処すればよい」が多数派なら、別にそれでもいいです。

元のデータ構造はフィールドごとなので、本来なら分割はフィールド別一択ですが、
複数フィールドの引用（たとえばポケモン詳細）の際、フィールドの数だけincludexが必要なので、
フィールドが増えると編集が必要になってしまいます。

やはり睡眠タイプごとになりますかね…

とはいえ3分割しても相当なデータ量のはずなので、もう少し細かく分ける必要があるかと思います。

データ量の問題なら、極端な話独自のプラグインを作るしかないかと思います。

だめでした

1.出現ポケモン一覧側（:config/の下層になるかもしれない）はテキストベースの最小限の内容

（ここではヘッダー行を省略）

25	コラッタ	すやすや	1	ワカクサ	ノーマル1

2.引用の際は独自のプラグインを使用

#hoge(コラッタ)

3.整形されたテーブルが出力される

（ここではヘッダー行を省略）

	0025	コラッタ	すやすや	ワカクサ	1

>> 389
あ、すみません、ソースを読み違えていたようです。
ワカクサ本島のページでは出現ポケモン一覧にリンクを貼っているだけで引用はしていませんでしたね。

ところで何でこんなに容量が大きくなってしまったんでしょう？
画像データが原因ですかね？
文字データだけにすれば容量は抑えられると思いますが

同じことが寝顔図鑑一覧の方でも言えるかと思いましたが、あちらはまだ500kBくらいなんですね。
複数の睡眠タイプを持つポケモンが追加されたりすると面倒くさいですが、当分は起こらないでしょうし睡眠タイプでページを分割するのが妥当でしょうね。
流石にもう面倒くさいのでこの仕事は他の誰かにパスします笑

>> 395
作れると勝手に思っていましたが、wikiwikiは自作プラグインを利用できない仕様でした…

自分で言い出しておいてなんですが、これ以上は別件として別の木でやったほうがいいですね。
もうちょっと自分の考えを整理してから、また提案したいと思います。

結局この議論が収束しないとポケモンページのフォーマットも完成しないので、優先度高めな議題ではあります。
あと、新フィールド実装を見越してページ分割するなら「限定」の列は管理が難しくなるので削除しても良い気がします。

遅レスで恐縮ですが自分も出現ポケモン一覧表のデザインは>> 377のものが良いと思います。ランクのアイコンがわかりやすいです。

サンドボックスではランクのアイコン画像にnolinkのオプションがついておらずリンク画像になっていたようなので、nolinkにすれば少しマシになるかも…？と思い軽量版のページに勝手ながらnolinkのオプションを追加してみたところ、約560ms→約470msに軽減されて右上のメーターが赤からオレンジになりました。

しかしこの微量な軽減は1ページあたりの容量オーバーの問題とは別の話ですので、自分もデータベースのページ分割は必要だと思います。
(噂では1600行or約15万文字、ファイルシステムのデータ量350KBくらいが限界らしいです)

PV数がそこまで多いわけではないので、ecacheを使う必要は無さそうです。
多重引用は試してみないと分かりませんが、できなさそうですね。ただ、試してみる価値はあるでしょう。
試しましたが、できませんでした。

睡眠タイプで分割するデメリットとしては、基本的に睡眠タイプを参照して引用することが少ないので不便というのが挙げられそうです。
新フィールドが追加されるたびに3つのページを横断して編集するのが手間になったり、フィールドごとの寝顔一覧で参照する時に3つincludeする必要が出てくるのは若干面倒です。

公開の場で答えないほうがよい質問かもしれませんので、その場合は無視して下さい

wikiwikiのアクセス制限はIP/ホストどちらで実施なさいますか？
自分、別のwikiを管理しているので管理手段として参考にしたく

ワンボタンで規制できるホスト規制を先に行い、同一IPから荒らしが続いた場合はIP規制も行う、とする予定です

ホストを規制しました。

ポケモンの一覧や寝顔図鑑の一覧も変更するのは面倒ですね
やるならポケモン数がさほど増えてない今、だとは思いますが、それでも労力はかかるでしょう
変更した方がより良さそうではありますが、手間に見合うメリットかどうかは…どうなんだろう

ぐっすりについては白文字ですから今のままで良いと思います
もし変更するなら背景色をより濃くする方が良いでしょうね

やるとしたら、

　元うとうと　　　　うとうと（fff094）　

　元すやすや　　　　すやすや（bafcff）　

　元ぐっすり　　　　ぐっすり（23457e）　
こんな感じ？
元のイメージから離れることはないと思いますが

まぁぐっすりは元々そのままでいいと書いてましたし

すやすや（bafcff）は、元のイメージを保ちつつ、チカチカ感が軽減されて元の色より見やすいと感じます
ぐっすりは元のままがいいと思います
うとうと（fff094）はどっちでもいいかな…元に比べて、やや柔らかく・優しくなった印象はあります

フィールドと違って列の色一括指定ではないので、あとは労力との相談ですね
変えた方が見やすいですが、今のままでもダメというわけではないですから
ただ、片方だけ変えると明らかにコントラストが合わないと思うので、片方だけ変えるのは微妙かもしれません

面倒とか労力がかかるとのことですが、何を指していますか？
変更することになっても、一括置換するだけだと思います。

そう言えば、メモ帳に貼り付けて置換するという手があったか

色の比較を用意してみました。
ここは上でも話が出ている通り、後からでも簡単に変更できる要素なのでそこまで慎重にならなくても良いかと思います。

ほぼ誤差の範疇と思ってしまうのですが、あまるさんが言うように、すやすやはbafcffの方が読みやすいような気はします。

>> 443
コード自動生成が完成したので>> 439で話したデフォルト順になりました。

出現ポケモン一覧うとうと
出現ポケモン一覧すやすや
ポケモン一覧
寝顔図鑑一覧

色の変更を反映してみました
却って見にくい等不具合あれば言ってください