利用者‐会話:Ef3

2006年11月

あなたの投稿している項目は、Wikipedia:記事名の付け方、Wikipedia:スタイルマニュアル (導入部)に沿っていません。竹麦魚︵ほうぼう︶ 2006年11月8日 (水) 13:27 (UTC)

具体的にどの記事でしょうか？サブページ関係ですか？--Ef3 2006年11月8日 (水) 13:32 (UTC)
通常の名前空間ではサブページは使えません。竹麦魚︵ほうぼう︶ 2006年11月8日 (水) 13:33 (UTC)
Wikipedia:サブページ#その他ですね。理解しました。利用者:名前空間でうまくいったので標準名前空間(？)でも通用すると誤解していました。
-- ご指摘ありがとうございます --
あと﹃具体的にどの記事でしょうか？﹄は反語的な意味でなく、もう1つ思い当たる点→﹁特別:Prefixindex/のトリッキーな用法﹂をやっている為です。こちらは構想中で横展開は︵まだ︶していません。あぁ、あと﹁節への直リンクの多用﹂ってのもやってます。・・・問題ありましたら、またご指摘の程よろしくお願いします。--Ef3 2006年11月8日 (水) 13:53 (UTC)

プレビュー機能のお知らせ

初めまして。ウィキペディアにご寄稿いただきましてありがとうございます。さて、Ef3さんが同じ記事に対して短時間に連続して投稿されているようでしたので、同じ記事への連続投稿を控えて頂くようお願いに参りました。

投稿する前に﹁プレビューを実行﹂のボタンを押すと、成形結果を先に見ることができます。これを使うことで

●マークアップ

●リンク

●誤字脱字

などを予めチェックし、修正してから投稿していただくことにより、同じ記事への連続投稿を減らすことができます。この利点についてはWikipedia:同じ記事への連続投稿を減らすに説明がありますので、よろしければお読みください。また、Wikipedia:ガイドブックにウィキペディア全体のことについて分かりやすく解説されていますので、あわせてお読みいただけると幸いです。ご理解とご協力をよろしくお願いします。 --SGreen 2006年11月15日 (水) 11:35 (UTC)

ご指摘ありがとうございます。Wikipedia:常に要約欄に記入するから、﹁要約欄に記入出来る程度の粒度でコミットする﹂と解釈をしていました。程度問題というのは理解しています。で、連投の多いもう1つの理由は、[プレビューを実行﹈では節へのリンクのリンクチェックが出来ず、また言語間のリンクをチクチク張っているときや、Commons や Wikispecies などの姉妹プロジェクト{から,へ}のリンクも同様です。一応、利用者:名前空間以下で作業してリリースというのもやっているのですが、今度はその間の競合編集を調べる方法がコミットするしかなく、上書き破壊してしまい、また無駄に rev してしまう結果となり本末転倒でしした。本質的には CVS や svn の様な、マージベースの履歴管理が必要だ思うのですが、発展の初期段階の MediaWiki ですから、システムの特性に合わせるしかないですね。--Ef3 2006年11月15日 (水) 12:00 (UTC)

お礼と {{prefix}} のお知らせ

はじめまして。利用者:Ef3/項目名から始まるページを表示を大いに参考にさせていただき、{{prefix}} を改変しました。今の感じでどうでしょうか。パラメタも使えるようになっています。たぶんこのテンプレートの存在自体ご存じ無かったのではないかと思いますので、お礼を兼ねてお知らせいたします。ありがとうございました。--.m... 2006年11月16日 (木) 19:56 (UTC)

三島市の記事について

はじめまして。いちごミルクと申します。一つお尋ねしたいことがあります。三島市の記事のショッピングセンターの項目内に記載した﹁伊豆　村の駅﹂を削除した理由をお聞かせいただければと思います。--いちごミルク 2006年11月19日 (日) 09:13 (UTC)

早速ありがとうございます。﹁伊豆　村の駅﹂については説明書きを加えられるよう少し調べてみます。自分は有権者ではないのですが、選挙結果は気になりますね。いつの間にか﹁中核市になるか、否か﹂が選挙の争点になっていることに驚きましたが。--いちごミルク 2006年11月19日 (日) 09:50 (UTC)
﹁伊豆　村の駅﹂の記事期待しています。私も、3年前に駿河区に越してしまい三島市民でないのですが、知人も多いので動向気になります。投票率低いですね。--Ef3 2006年11月19日 (日) 09:58 (UTC)
このままだと投票率50パーセント超えないでしょうね。実は今回の選挙では、小池市長の買収に関わる怪しい金の動きを告発する文書︵1500万円の示談金の証明書︶が地元では出回ってますよ。こんなこと書いていいのかはわかりませんが︵笑︶。結果が楽しみです。--いちごミルク 2006年11月19日 (日) 10:11 (UTC)
50%微妙ですね。⇒選挙速報︵投票率︶ だと19:30で47.18%、天気悪いとはいえ低いですね。怪文書は対外出回りますが本星にで会った事がありませんね。それにしてもいまさら中核市って。。。--Ef3 2006年11月19日 (日) 10:57 (UTC)

開票率99パーセントの時点で小池25034︵票︶vs豊岡23367︵票︶ですから小池の三期目がほぼ確定しましたね。というかどっちの候補も清水町・長泉町・函南町との合併を目論んでいるはずなので結局特例市ぐらいにはなるでしょうが。ということでお騒がせしました。--いちごミルク 2006年11月19日 (日) 13:39 (UTC)

小池氏3選の様ですね。[1]、人工要件；特例市:２０万人・中核市:３０万人；三島市:112,181人、函南町:39,069人、清水町:31,290人、伊豆の国市:49,956人・・・単純に数字的に厳しいですね。熱海伊東は論外だし（あっちは湯河原と合併したがっているんですよね）。--Ef3 2006年11月19日 (日) 20:54 (UTC)

Category:江口姓の人物

Category:江口姓の人物につきまして、作成後ご自分で白紙化されているようですが、正式に削除の手続きをお願いします。別の方が使い始めてしまっています。--Yas 2006年11月19日 (日) 11:17 (UTC)

お知らせくださりありがとうございます。早急に処置します。--Ef3 2006年11月19日 (日) 11:19 (UTC)
Category:江口姓の人物を、{{即時削除|[[Wikipedia:削除依頼/Category:源姓の人物]]・[[Category‐ノート:藤原姓の人物/削除]]で削除対象となったカテゴリと同様、不要にして有害。}}に処理しました。手続き上これでよかったか確証ないですが、方向はあっていると思います。︵削除手続きはやったことがないので︶--Ef3 2006年11月19日 (日) 11:30 (UTC)

Category:赤星病について

はじめまして。Category:赤星病というカテゴリと、その子供のCategory:赤星病中間宿主を作成されていますが、こうしたカテゴリは必要なのでしょうか？ Wikipediaは、植物病辞典ではありませんので、私には不要に思えますが・・・。 必要性が薄いなら、申し訳ないのですが削除依頼に出したく思っております。議論はCategory‐ノート:赤星病でお願いします。--Kenpei 2006年11月29日 (水) 12:05 (UTC)

ご案内ありがとうございます。では議論は議論はCategory‐ノート:赤星病にて。--Ef3 2006年11月29日 (水) 12:11 (UTC)

一括投稿のお願い

こんにちは。Ef3さんが同じ記事に対して節ごとに分けて連続して投稿されているようでしたので、一括投稿のお願いに参りました。Wikipedia:同じ記事への連続投稿を減らすにあるとおり、同じ記事への連続投稿はウィキペディアのサーバーに負荷がかかる上、私たち他の利用者にもエラーが出て編集がしにくくなったり、履歴の見通しが悪くなったりと、様々な面で支障をきたす恐れがあります。細かい節がたくさんある場合は、節ごとに細かく投稿をするのではなく、上位の節または項目全体の編集を行い、一括して投稿してくださるようお願いいたします。

1の部分がプレビューを実行できるボタンです。

その際に細かいところでミスを起こすのではないかと心配な場合は、﹁投稿する﹂ボタンの右隣にある﹁プレビューを実行﹂ボタンを活用されることをお勧めします︵画面右側の図を参照︶。投稿される前に﹁プレビューを実行﹂のボタンを押すと、成形結果を先に見ることができます。これを使うことで、

●マークアップ

●リンク

●誤字脱字

などを予めチェックし、修正した上で記事を投稿することができますので、是非ともご活用下さい。ご迷惑をおかけしますが、ご理解とご協力をよろしくお願いします。koon1600 2006年12月16日 (土) 04:07 (UTC)

以前にもこれと同じ趣旨のメッセージを︵他の方から︶頂きましたが、挨拶同好会と同じで同好会があるのでしょうか？もし元の文章がWikipedia上にあるのであれば出典を明記していないという意味でGFDL違反です。機械的に履歴が連続しているとコピーアンドペーストで利用者のノートに書き込んでいるようですが、履歴を追えば判るのですが、節毎に更新したり、大きなマークアップの変更の前に履歴が追えるように構成のみの変更を行うものです︵デルタがごちゃごちゃしないように︶。

まず、誤字脱字のレベルのコミット前のプレビューによる確認を行う事が必要︵重要︶であることに議論の余地はありません。

連続投稿によってサーバーに負荷がかかるという事象はありえるのでしょうか？︵⇒要出典、節編集であればPOSTサイズは減るし、プレビューでもコミットでも不可は同じはずです︶、同様に﹃私たち他の利用者にもエラーが出て編集がしにくくなったり﹄も︵⇒要出典、コミットの粒度をしいさくすると、デルタが小さくなったり競合編集の可能性が減ったりする利点の方が大きいと考えられます。さらにオフライン編集をされると、本来検出来たはずの﹁競合編集﹂に気づかず上書き破壊される危険が発生しこれが rvv と誤解され無意味な論争を生んでしまう恐れも大きい︶。

また、Wikipedia:同じ記事への連続投稿を減らすは、Wikipedia:基本方針とガイドライン#考慮すべきガイドラインですが公式な方針ではありません。

さらに、Wikipedia:ページサイズ#長いページの編集時にみられる﹁節単位の編集を利用しましょう。﹂と矛盾します。--Ef3 2006年12月16日 (土) 04:24 (UTC)

では、ご説明いたします。まず、これはテンプレートでして、一種の警告、というかお願いです。ガイドライン︵考慮すべき、公式である無しにかかわらず︶の連続編集自粛を守っていただけない方に送っているメッセージです。よってGFDL云々からは離れます。

次に、連続投稿によってサーバーの負荷は、更新するたびに通信があるのですから、当然ながらかかります。また、ウィキには履歴と言うものがありますから、それが大量に並ぶのは履歴を追う面でもよろしくなく、どのような編集が行われたかわかりにくくなるという問題があります︵あなたは履歴を分かりやすくする目的でやっているのかもしれませんが、履歴は積み重なっていく都合上、何度も編集されると逆に分かりにくいだけです︶。

また、履歴は1つずつ保存されますから、連続投稿は、容量の面でわずかではありますが圧迫するのです。また、編集競合についていえば、それは杞憂でありませんか？オフライン編集でつくっていく状態と言うのは基本的に赤リンク状態が多く、すでにある場合はある程度まとまったら適宜更新していく、と言う方式が多いと思われます。少なくとも私は、そういった形での競合に陥ったことは一度もありません。逆に言えば、多くの更新がされた後にそれを無視して記事を差し替えると言うのは、した側に問題があるのですから、それを気にして履歴を増大させるのはやはり問題です。

なお、考慮されるべきガイドラインは、文字通り考慮されるべきであり、意図的に破っている場合は短期間ブロックになる可能性が0ではないと言うことを考慮してください。過去に同じ例で文章方針の要熟読という理由で数日ブロックをされた方は数多くおりますので。また、節単位編集は﹁その節だけを編集する場合﹂です。全体および数多くの節を編集する場合は節単位編集は推奨されません。これは、ウィキぺディアの構造上、編集は履歴と言う形で積み重なるためであり、どちらも﹁履歴が大量にたまるのを防ぐ﹂という目的があるのです。そのため矛盾はありません。今回このお願いを入れたのは[2]のようにあなたの編集履歴がずらずら並ぶのは、よろしくないという考えからです。容量とかよりも、こういった具合に並ぶことが履歴を追跡し難くしている、とお考えいただいても結構です。--koon1600 2006年12月16日 (土) 08:03 (UTC)

(インデント戻します)まず、ご返答に感謝します。以下用手別に列挙するので、もしご返答がある場合は、項目1つ1つにお願いします。

●GFDL について
趣旨によってライセンスが変わるという見解は興味深いですが、こと法律問題︵ライセンスは法律問題です︶としては有効性に疑問があります。またテンプレートなる用語には非常に多岐にわたる意味がありますが、Wikipediaに投稿された文章の一部であるかが問題で、﹁以上の記述を完全に理解し同意した上で投稿する﹂を押した時点で形式的には GFDL の適用される対象となるわけです。ともありこれは本件の主たる争点ではありません。

●サーバ負荷について
﹁履歴﹂についてという観点は、最初のご指摘からは思い至りませんでしたが、なるほど粒度を小さくコミットすれば履歴の件数は増えましょう、しかし、それがサーバの負荷問題になるのでしょうか？容量負担にはなるかもしれませんが、履歴表示を行ったときのトランザクションがやや大きくなる筈ですが、それを測定できる方法がないほどの有意とはいえない差だと思います。

●履歴の判り易さについて
﹃履歴を分かりやすくする目的﹄というのは﹁履歴を判りやすくする目的﹂とおっしゃりたいのだと思います︵それとも履歴を分かつの暗喩でしょうか？︶。これについては、個人的な感性・感覚に依存するものですので、絶対的な評価を行うのは履歴件数の比較ほど容易ではありませんが、要因を分析してみます。

(一)Wikipediaでは、投稿ごとに編集内容の要約をつけることが出来る

(二)--、﹁編集内容の要約﹂に、 /* 節の名前 */ が含まれると、履歴表示では節へのリンクとなる

(三)--、﹁編集内容の要約﹂以外にChangelLogの様な履歴ドキュメントを記録する機構も習慣もない︵ノートは少し違う︶

(四)--、過去の版間で差分をとることが出来るが diff(1) の -d 相当の最小差分アルゴリズムを取っていないので差分が無意味に冗長になる。

(五)--、改行をあまり行わないスタイルが推奨されているので前記と併せ編集箇所を特定しにくい

このように、粗粒度のコミットを行うと判りにくくなる要因が多数あります。これに対して細粒度のコミットは

(一)﹁編集内容と要約﹂と真の編集内容を乖離させない

(二)∴ドキュメント性が高く判りやすい

(三)変更が局所的なので差分がコンパクトかつ要約的になる

(四)サーバのデルタ生成アルゴリズムに与える負荷が︵変更が局在的なので︶小さい

などの利点があります。

●オフライン編集について
オフライン編集は検索や置換の様な編集行為をオフラインのエディタを行う為に実現するに留めた方がいいです。というのは競合編集に気づかないで他人の編集成果をキャンセルしてしまう可能性があるからです。私は、競合編集が起こると言っていません。﹁少なくとも私は、そういった形での競合に陥ったことは一度もありません。﹂と自信を持って言っておられますが、気づくのはあなたではなくあなたに編集成果を上書き破壊された人ですので、いままで何度かやっている可能性があります。︵オフライン編集結果をWikipediaに反映させる時に毎回、持ち出した版と現在の版が一致している事を確認してから投稿していますか？︶残念ながら　MediaWikiにはシステムが自動的に版毎に︵$Id$の様な︶ユニークIDを振る機能がないので機械的にオフライン編集を検出する方法がありません。︵本来　MediaWiki がオフライン編集を支援すべきでしょう︶
いみじくも﹁多くの更新がされた後にそれを無視して記事を差し替えると言うのは、した側に問題があるのですから、それを気にして履歴を増大させるのはやはり問題です。﹂とおっしゃっていますが、﹁多くの更新がされた﹂かを知る方法がないのです。これは﹁時間的に短ければ﹂という推定は﹁高速道路でも速く走って渡れば惹かれないだろう﹂と質的な差がない事を言っています。専門的に言うと、﹁MediaWikiaの編集セッション管理を無効にしてしまう﹂と言います。

●﹁オフライン編集でつくっていく状態と言うのは基本的に赤リンク状態が多く、すでにある場合はある程度まとまったら適宜更新していく、と言う方式が多いと思われます。﹂
そうなんでしょうか？同意いたしかねます。

●オフライン編集による破壊体験
残念なことに、わたしにはオフライン編集によって記事を上書き破壊された経験があります。これがその上書き破壊の現場です[3]。このケースは分かち書きを行う英語版で起こっているので差分が比較的容易に弁別できますが、漢字カナまじりの日本語版では形態素解析を行わないMediaWikiの差分アルゴリズムは夥しい量の無駄なレポートを生成します。もちろんこの不幸な例は、10日以上も自分で暖めていた版をノーチェックでコミットした氏に責任がありますが、同時に氏にはこの事に気づく機会が有りません。

●ブロックについて
ブロックについて言及されていますが、ブロックはWikipedia:投稿ブロックの方針︵公式な方針︶に照らして行われるべきです。﹁過去に同じ例で文章方針の要熟読という理由で数日ブロックをされた方は数多くおりますので。﹂というのがWikipedia:同じ記事への連続投稿を減らすを破った利用者なのか、方針未満のガイドラインを破った利用者一般を指すのか曖昧ですが、どちらにしてもそれ自身が基本方針違反で、その論によるならば反対に︵ガイドラインを破った旨でブロックを行った者が︶ブロックの対象となりえます。

●履歴が詳細かつ構造的になるのは好くないか？
﹁今回このお願いを入れたのは[4]のようにあなたの編集履歴がずらずら並ぶのは、よろしくないという考えからです。﹂に対する直接的な答えです。﹁ずらずら並ぶ﹂という言動の情緒面は問題にしませんが、これ相応のボリュームで行われた編集にはドキュメントとしてそれ相応のボリュームの履歴が伴ってしかりべきだと思いますし、大変失礼ですがSpecial:Contributions/Koon16000を拝見しても、どんな編集をなさったかは(差分)を観ないと判りませんし、差分を観れば変更した箇所こそわかりますが、変更の意図は想像するほかありません。手前味噌ですが、Special:Contributions/Ef3を御覧になれば、編集の内容と意図がお分かりになるのではないかと思います。また、このように履歴から意図が汲み取れるとは、非常に重要なコンテンツ開発上の価値だと感じており、目先のサーバ負荷や履歴が長くなる事で粗粒度にするのは本末転倒です。特にサーバ負荷の問題はハードウェアの進歩と資本投下で如何様にもなるのです。過去の履歴が粗く情報量︵と質︶が低いのは、未来のウィキペディアンから﹁昔の人の貧乏性が今の苦労の元だ！﹂と指摘される筆頭だとおもいます。

誤解されないように繰り返しますが、私は﹁プレビューを十分行い・適切な要約を伴った投稿﹂は、連続した投稿になりえるので許容できると主張しているのであり、﹁プレビューも行わず・要約もない︵ないし要を得ない︶投稿﹂を連続して行うことを推奨したり擁護してはいません。 (以下、余談)WikipediaはMediaWikiというサーバーサイドアプリケーション上に造られています。このMediaWikiもソフトウェアですから、ソースコードがあり、それは svn という世代管理システムで管理されています。MediaWikiのsvnリポジトリはウェブで観ることが出来ます[5]。御覧になると判りますが、個々のコミット単位︵ファイルといいます︶について初版から番号が振られとても充実した履歴を観ることが出来ます。またMediaWikiの競合編集では競合に気づいた版の持ち主は、編集内容を破棄︵少なくとも保存して中断︶する必要がありますが、svn では、機械的に解決可能な競合︵衝突︶は自動的にマージされ本当に同じ行を編集いてしまった場合にも、競合状態でコミットしようとした利用者に人手により合成の裁量が与えられます。またMediaWikiは投稿ごとに記事全文をDBに積んでいますが、svn は直前の版からの差分だけをDBに積みます。MediaWikiがsvnの様なリッチな履歴管理機構を今後目指すのかは判りませんが、1つ言えるのは MediaWiki の開発者全員は svn の様な世代管理システムの利点を熟知しているということです︵自分が使っていますので︶。--Ef3 2006年12月16日 (土) 11:18 (UTC)

まず、1番考えるべきことは﹁現在のガイドライン﹂において節投稿を何度も行うことは推奨されていない、ということです。未来関係なく。私はコード関連はあまり詳しくないので触れませんが、マークアップ云々以前に、現在は﹁節単位で何度も編集するのは好ましくないから、気をつけてください﹂ということです。また、履歴は差分を見ることが前提であり、あなたのは逆に差分を見ると何しているのか分かりにくいです。また、他人の編集を破壊したことは、私は無いと自負しています。履歴は事前のものを確認してから編集しますし、オフライン編集は基本的に赤リンクのみに行うようにしてそれ以外で行う場合はウォッチリストにほうりこんでいるので。

とにかく、節単位で行うのが有意義であるとか、そういった主張はわかりますが、ガイドライン︵先ほども言いましたが、公式、考慮すべきにかかわらず︶にそういったものがあり、また、テンプレートに控えていただきたいという旨のが用意されている︵つまり、節単位の連続編集は好ましくないと一般に考えられている︶以上、不満なのは分かりますが守ったほうが良い、と私は思います。なお、ブロックについては節単位、通常プレビュー両方です︵どちらも、方針を守っていないことに変わりないため︶。私は、現在のブロック状況には賛成しております。ご不満ならば、節単位について井戸端でもかまわないので意見を出しては如何でしょうか？--koon1600 2006年12月16日 (土) 11:55 (UTC)

返答した後であれなのですが・・・やはり気になったので、井戸端において意見を募ってみました。お知らせのみでありますが、よろしくおねがいします。--koon1600 2006年12月16日 (土) 12:26 (UTC)

競合編集しました。箇条書きマークアップした30行ほどの長文が失われました。--Ef3 2006年12月16日 (土) 12:40 (UTC)

(←趣旨だけ再建)

主張は概ね理解しました。﹁オフライン編集は基本的に赤リンクのみに行うようにしてそれ以外で行う場合はウォッチリストにほうりこんでいるので。﹂というのは、あなたの流儀でWikipediaの方針では有りませんね。また、﹁あなたのは逆に差分を見ると何しているのか分かりにくいです。﹂は﹁私はコード関連はあまり詳しくないので﹂と密接な関係があると思います︵最近はマークアップの整頓が多いのでWiki記法の内面や生のHTMLのコードについて多くの時間を割いています。またこのことは編集内容の要約にコンパクトに書いてあります︶。議論の場についてですが、当のWikipedia:同じ記事への連続投稿を減らすのノートで︵あまり盛り上がっていませんが︶行われた形跡があり。しかし、正当性の疑問に対しての有意な反証は出現していません。﹁同じ記事への連続投稿を減らす﹂というガイドラインが方針に昇格しないこともこのあたりが理由であろうかと個人的には推定します。koon1600殿は、Wikipedia:同じ記事への連続投稿を減らすがガイドラインから方針に昇格されることに尽力される事をお勧めします。また、koon1600 殿はGDFLに関するご意見に代表されるようにユニークな視点の持ち主とお見受けするので、ぜひ井戸端にてご披露願いたいところです。停滞している、Wikipedia‐ノート:同じ記事への連続投稿を減らすの好い刺激となると思います。それからWikipedia:同じ記事への連続投稿を減らすを、もう一度お読みください。特に最後のパラグラフのあたり︵非常に大きな︶相反する2つの問題を挙げておいて解決方法を提供していません。ノートでは更に厄介な問題の内在が指摘されています。このガイドラインを擁護するには、ここで述べられている問題への合理的な解答が必要かと思います。
Wikipediaには、Wikipedia:同じ記事への連続投稿を減らすの他にも、Wikipedia:改行記号は使うなの様な、技術的にも編集負荷的にも存在が疑問な﹁考慮すべきルール﹂が多数散見されます。それについて逸脱する︵あるいは逸脱する可能性がある︶たびに井戸端に出向くことは︵私は︶しません。koon1600 殿の主張や活動を私は尊重とまではいえませんが、阻害はしないつもりです。出来れば私の主張や活動について同様であって欲しいと思いますが、はてさてこれも私の価値観に基づく主張ですね。--Ef3 2006年12月16日 (土) 12:45 (UTC)

ちょっとまってください・・・その競合って、﹁あなたが編集している間に・・・﹂というやつですよね？上に更新された版がでて、下に﹁あなたの編集したもの﹂があるはずですよ。その後消したら失われますが、コピーして上に持っていけば問題ないはずですが、如何でしょうか？--koon1600 2006年12月16日 (土) 12:47 (UTC)

端末について何か予断を持ち込んでいませんか？長文から変更部分を切り貼りするのが困難な環境もあるのです。これも個人的事情ですが。--Ef3 2006年12月16日 (土) 12:59 (UTC)

静岡市の場合

静岡市の履歴を見たとき、10回行われている<div>による段組は1回にまとめられるだろうと思いました。Ef3さんの同じ記事への連続投稿は減らせる余地があると思います。 --SGreen 2006年12月18日 (月) 03:43 (UTC)

一般論的に﹁同じ記事への連続投稿は減らせる余地がある﹂と言うご意見には賛同します。ただ、この静岡市の記事の編集の場合、

●レンダリングの確認が必要なためオフラインで編集できない。

●︵節ごとでなく︶ページ全体を編集してレンダリングを確認すると、変更箇所を探すのにひどく苦労する。

●︵狭幅環境検証のため︶使用端末が PDA でなるべく編集単位を小さくしたかった。

という理由で節ごとに分割して投稿しました︵また同じ説単位でもなる出来る限り粗粒度︵===よりは==で︶編集するようにしました︶。
ご意見は一般論として、今後の参考に致します。ありがとうございました。--Ef3 2006年12月18日 (月) 03:55 (UTC)

合意無き独断による記事改名について

記事改名について自ら提案をしているのにも関わらず、貴殿はそれをまとめるという義務すら怠り独断で移転をするという暴挙に出てしまわれました。これでは、その移転に関して如何に正しい事を述べていたとしても、荒らしとして扱われて然るべき行為としか言う事ができません。それゆえ、不適切な移動行為として移動依頼をさせていただきました。ご理解とご協力をお願いいたします。--Pippi 2007年2月6日 (火) 07:11 (UTC)

新富士駅について

新富士駅 (静岡県)と新富士駅 (北海道)に{{otheruses}}を追加してらっしゃいますが、{{otheruses}}はいずれかがメインになるトピックに用いるべきであり、この場合は平等な曖昧さ回避にするべきではないでしょうか。ご一考ください。--郁 2008年4月1日 (火) 22:06 (UTC)

Wikipedia:曖昧さ回避#分野名つき記事名の記事にはOtherusesは不要との指摘ですね︵これはOtherusesではなくOtheruseslistの誤記なんじゃないでしょうか？︶。新富士駅 (静岡県)と新富士駅 (北海道)に関しては{{Otheruses}}を使うことが、Disambiguation相手が1つだけであることが冒頭で判り明快である点と、Wikipediaで普遍的に使われているナビゲーションモデルに準拠しているという点で優れています。私の考えは、どの曖昧さ回避を使うべきかの冒頭が代弁しています。編集合戦とみなされないため当該記事は︵私は︶差し戻しません。ご一考ください。--Ef3 2008年4月1日 (火) 23:27 (UTC)
了解しました。私としては将来的に﹁新富士駅 (○○○)﹂が別にできたときのメンテナンス性、および、検索時に曖昧さ回避の括弧を考慮する人は少数派であろうことを考慮すると、平等な曖昧さ回避の方がいいのではないかと考えたのです。なにぶんにも鉄分がほぼゼロなので、鉄道関係記事を積極的に編集することはありません。差し戻し等は考えておりませんのでご安心ください。--郁 2008年4月2日 (水) 00:12 (UTC)
分野名つき記事名の記事にはOtherusesは不要については、議論もあるようです。この議論を知っただけでも、ご指摘に感謝しなければいけませんね。また、ユーザーインターフェース︵ナビゲーションモデル︶に関係した議論なので、結論を出しがたいことも容易に想像できます。個人的には曖昧さの回避もカテゴリのようにMedaiWikiの機能として実装してしまうのがシンプルかつ合理的だと思うのですが、本文名前空間のサブページを禁止して当時とは記事の量もコミュニティの規模も全然違うので、もう大鉈は振れないのかもしれません。MediaWikiについていうと、表意文字と表音文字を併用する言語では﹁読み﹂も重要な記事の情報なので{{DEFAULTSORT}}の様なカテゴリをソートするための付け焼刃ではなく、音引きがちゃんと出来る水準の改修が求められるのですが、いかんせん開発元に必要性を理解させるのが厄介な問題です。…余談が過ぎました。--Ef3 2008年4月2日 (水) 00:39 (UTC)

ブライアンズ・シアウォーターについて

ブライアンズ・シアウォーターでのプレスリリース掲載ありがとうございました。太平洋海鳥会議の資料を少し見つけましたので、誠に勝手ながらEf3さんに掲載していただいたプレスリリースや会議の資料などを出典にして小笠原諸島での発見について少し加筆させていただきましたことを報告させていただきます。ただし少々勢いよく執筆してしまいましたので、どこかおかしなところがあるかもしれませんが。--Henares 2012年2月9日 (木) 13:24 (UTC)

ご連絡感謝します。私が考えていた以上に充実した編集をしていただいたと思います。--Ef3 2012年2月20日 (月) 06:16 (UTC)

定義リストのマークアップについて

こんばんは。﹁世界重要農業遺産システム﹂でEf3さんが1時間ほど前に行った編集[6]についてのお知らせです。要約欄に﹃包含要素なきDD要素を削除﹄と記入されていますが、実はそれ︵一見すると空要素のDDがある記述方法︶が正しいのです。

これは割とよく知られたMediaWikiのバグ(?)で、定義リストの中に箇条書きを入れる場合、定義リストが分断されてしまうのです。そのバグ回避の方法が、Ef3さんが除去された﹁中身のないDD要素﹂を挿入することなのです。

Help:箇条書き#定義の箇条書き中の箇条書きに、分かりやすい図解がありますのでご覧ください。

ですので、今後は﹃包含要素なきDD要素を削除﹄は行わないようお願いいたします。﹁世界重要農業遺産システム﹂の該当部分は差し戻しておきましたが、他に同様の編集がありましたら差し戻しをお願いします。--氷鷺︵会話︶ 2014年6月2日 (月) 13:40 (UTC)

お知らせ頂きありがとうございます。状況概ね理解しました。

他に同様の編集がないか投稿記録から調べてみましたが:の単体使用を定義リストに編集のケースは数例ありますが、DDにブロック要素を含めた場合の捨てDDの削除は世界重要農業遺産システムの編集だけのようです。

ご案内頂いたHelp:箇条書き#定義の箇条書き中の箇条書きを参考に、発現条件を絞ってみました。

↓この結果を観る限り、DD要素にUL,OL,DLあるいはTABLE要素を含めると発生するというこのようです︵DDにTABLEを含める場合は、捨てDDしても改善されないのでマークアップに工夫の余地があるかも︶。またDT要素にリストを含めた場合にも同じ現象が発生するようですが、元々DT要素の内容モデルにはインライン要素かテキストしか取り得ない︵ブロック要素は取り得ない︶ので問題無いとして。DDにブロック要素を含ませると必ず発生するという発生条件をHelpなどに反映する必要があるかもしれません。またバグなのか仕様なのかもMediaWikiの開発側に伺いたいところ︵Send-PRの様な仕組みがあるか調べてみます︶。--Ef3︵会話︶ 2014年6月2日 (月) 23:05 (UTC)

Wiki-source

; 用語1
: 用語1の説明
:#用語1に関する項目1
; 用語2
:{|
! 見出し1 !!見出し2 !! 見出し3
|-
| 1-1 || 1-2 || 1-3
|}
;用語3
:定義3

↓ULとOLにDLを含めた場合は安全
*項目1
*;項目2用語
*:項目2定義
*項目3

#項目1
#;項目2用語
#:項目2定義
#項目3

レンダリング結果

用語1

用語1の説明

1. 用語1に関する項目1

用語2

見出し1	見出し2	見出し3
1-1	1-2	1-3

用語3

定義3

↓ULとOLにDLを含めた場合は安全

• 項目1

  項目2用語

  項目2定義

• 項目3

1. 項目1

   項目2用語

   項目2定義

2. 項目3

展開されたHTML

<dl>
<dt>用語1</dt>
<dd>用語1の説明
<ol>
<li>用語1に関する項目1</li>
</ol>
</dd>
</dl>
<dl>
<dt>用語2</dt>
</dl>
<dl>
<dd>
<table>
<tbody><tr>
<th>見出し1</th>
<th>見出し2</th>
<th>見出し3</th>
</tr>
<tr>
<td>1-1</td>
<td>1-2</td>
<td>1-3</td>
</tr>
</tbody></table>
</dd>
</dl>
<dl>
<dt>用語3</dt>
<dd>定義3</dd>
</dl>
<p>↓ULとOLにDLを含めた場合は安全</p>
<ul>
<li>項目1
<dl>
<dt>項目2用語</dt>
<dd>項目2定義</dd>
</dl>
</li>
<li>項目3</li>
</ul>
<ol>
<li>項目1
<dl>
<dt>項目2用語</dt>
<dd>項目2定義</dd>
</dl>
</li>
<li>項目3</li>
</ol>

お知らせ

利用者:Ef3が、Category:修正が必要なページに分類されています。リンクを意図していたのであれば、この編集内容を参考に先頭に:を追加してください。--タバコはマーダー（会話） 2016年2月26日 (金) 10:12 (UTC)

新東名高速道路について

あの形式では、括弧が見づらかったりしますし、他の記事でも殆ど採用されていませんが…--Syduf-2006︵会話︶ 2016年5月7日 (土) 15:02 (UTC)

ご意見ありがとうございます。﹃括弧が見づらかったりします﹄というのが﹁Wikiソース上で﹂という意味でしょうか？﹁レンダリング結果が﹂という意味でしょうか？前者は Wiki 形式と生の HTML が混在しているので思い当たらなくもないです︵解消方法として、例えば{{hlist}}あるいは{{リスト}}などの構文を隠すテンプレートを使うなどが考えられます︶。後者の場合、 class=hlist のCSS実装で括弧を生成している部分を変更するなどの対策が考えられますが、jawp 全体に及ぶ問題なのでかなり大規模な議論が必要だと思います︵何年か前に井戸端で類似の意見を見かけた記憶があります‥ hlist や hlist-hyphne は MediaWiki:Common.css で実装されています︶。﹃他の記事でも殆ど採用されていません﹄というご意見ですが、class=hlist ある意味﹁新東名高速道路でも使っています﹂、例えば Template:新東名高速道路で使っています。同じように記事の末尾に使うTemplate:日本の高速道路とくらべてみてください。Wiki ソースの可読性と、変更があった時の差分がコンパクトになること︵何を変えたかが一目瞭然であること︶などの利点があります。。長々と書きましたが﹁水平レイアウトであってもUL要素の様なリストとしてマークアップすべき﹂また﹁括弧で表現されている階層構造もリストの包含構造で表現できる︵表現すべき︶﹂というのが私の意見の趣旨です。 --Ef3︵会話︶ 2016年5月7日 (土) 21:42 (UTC)

年　ウィキメディア財団事務長採用に関する コミュニティアンケート

ウィキメディア財団の理事会は、財団の次期事務長の選出を一任するための委員会を設立しました。そして、私たち委員会の最初の任務の一つに、事務長の職務内容の記述があり、現在、ウィキメディアのコミュニティから意見を募っています。この簡単なアンケートにご協力いただくことで、私たちはコミュニティやスタッフのウィキメディア財団の事務長に対する期待をさらに理解できると考えています。 ご協力いただきましたこと、重ねてお礼申し上げます。

●アンケート (Qualtrics)

ウィキメディア財団事務長採用 運営委員会 via MediaWiki message delivery︵会話︶ 2016年6月1日 (水) 22:10 (UTC)

hlist の空白問題

こんにちは。特別:差分/67456828 にて「ULの * の後に空白文字を入れると hlist でレンダリングが変わってしまう」とのご指摘を拝見いたしました。前後の版を表示してみましたが、私の方では違いを確認できませんでしたが、どのような問題が起きているのでしょうか。私の解釈では、通常のウィキマークアップにおいて、*文字の後に空白を挟んでもリスト構造の出力に違いが出ることは無いものと思っています。hlist においても、通常のリスト構造をCSSにより表示が異なるよう加工したもので、問題が出るとしたら、環境によってCSSの解釈に違いがあるのではないかと思っています。いずれにしましても、もしよろしければ、この問題をバグの報告などにご提示頂けるとありがたいです。--Frozen-mikan（会話） 2018年2月21日 (水) 02:22 (UTC)

こんにちは、ご指摘感謝します。

↓再現コードを書きました。

b1とc1の左の空白の有無に違いがあります︵書き込み前のプレビューで確認:: ︵ビジュアル編集ではなく︶ソースの編集を使用しています︶。ただ投稿後は空白の有無による違いがなくなるようですので、その意味で私の事実誤認と言えそうですが、投稿前のプレビューと投稿後のレンダリングが違うのはそれはそれで問題なので継続して調べようと思います。--Ef3︵会話︶ 2018年2月21日 (水) 07:51 (UTC)
上の例は失敗しました︵プレビューではレンダリングは崩れませんでした︶。インデントを外してみます。

--Ef3︵会話︶ 2018年2月21日 (水) 07:57 (UTC)

具体例をご提示頂き、ありがとうございます。ご提示頂いたものについて、私の環境︵Win10, Chrome/Edge/Firefox︶では違いが見当たりません。ソースの編集によるプレビューでも通常画面でも違いがありません。ログインの有無による違いもありませんでした。出力されたソースコードを比較しても違いが無いようです。本件と合わせ、最初のNavboxの表示がプレビュー時に崩れなかった事も踏まえると、お使いの環境に由来した何らかの問題が起きているのかもしれません。もしよろしければ、問題点の切り分けなど情報共有のため、ご使用の環境と合わせ、Wikipedia:バグの報告 にご提示頂けるとありがたいです。--Frozen-mikan︵会話︶ 2018年2月21日 (水) 10:14 (UTC)
﹁新しいウィキテキストモード﹂を個人設定で使っています︵[[7]]︶。これについては﹁お使いの環境に由来した何らかの問題﹂と言うのはとても的を射ています。色々 F12 で調べましたが、wiki-source を HTML にレンダリングする動作が MedeiaWiki と﹁新しいウィキテキストモード﹂の間でかなり違うようです。いま wiki-source から HTML を生成する仕様を定義した文書を探しています。--Ef3︵会話︶ 2018年2月21日 (水) 12:25 (UTC)

トンボロ現象について

2006年11月にEf3さんが初版を執筆されたトンボロ現象について、主にその名称の典拠についてノート:潮間島の改名議論の中で話題となっています。典拠をお持ちか当時の記憶･記録が残っているようであれば、お知らせ下さい。--Open-box（会話） 2019年5月31日 (金) 16:14 (UTC)

利用者ページのカテゴリについて

こんにちは。Ef3さんの利用者ページ﹁利用者:Ef3/C﹂﹁利用者:Ef3/南アルプス赤石温泉白樺荘﹂﹁利用者:Ef3/河川コード﹂﹁利用者:Ef3/相模灘draft﹂﹁利用者:Ef3/神道用語一覧﹂﹁利用者:Ef3/草稿/口坂本温泉﹂﹁利用者:Ef3/草稿/静岡市立南部図書館﹂﹁利用者:Ef3/TDSkel.js﹂﹁利用者:Ef3/sandbox/日本の基礎自治体と行政区/TemplateData﹂ですが、Category:プログラミング言語など通常記事︵標準名前空間︶で使うことが想定されているカテゴリが複数、付与されています。そのため、カテゴリページにてEf3さんの利用者ページが表示されてしまっています。利用者ページには通常記事と同じカテゴリは付与しないことになっていますので、Wikipedia:利用者ページ#カテゴリ、テンプレート、リダイレクトを参考に利用者ページのカテゴリを<!--と-->で囲んでコメントアウトするなどの対処をお願いします。

1週間ほどお待ちしても対処いただけなければ、不躾ながら利用者ページを他の利用者が直接修正させていただく場合もありますので、ご容赦ください。--Keruby︵会話︶ 2020年3月23日 (月) 08:51 (UTC)

 報告 予告通り、修正を行いました。なお、﹁利用者:Ef3/TDSkel.js﹂と﹁利用者:Ef3/sandbox/日本の基礎自治体と行政区/TemplateData﹂も修正する予定だったのですが、先週確認した時には付与されていたカテゴリがいつの間にか消えていたため、こちらは修正の必要はなかったようです。お騒がせして申し訳ありません。--Keruby︵会話︶ 2020年3月30日 (月) 19:48 (UTC)

2021年ウィキメディア財団選挙の候補者を紹介します

こんにちは！

2021年ウィキメディア財団選挙が8月に始まります。今年の理事会選挙は、2021年8月4日から17日まで実施されます。ウィキペディア日本語版の編集者を含むウィキメディア・コミュニティのメンバーは、3年の任期で4人の新しい理事を選出する機会があります。理事会選挙の開始に先立ち選挙運動期間が設けられており、この期間中にコミュニティが候補者と顔を合わせる機会があります。

●ウィキメディア財団における理事会の役割は何ですか?

理事会の簡単な説明はこちらをご覧ください。

●候補者紹介

今回の選挙には20名の立候補者がいます。候補者についてはこちらをご覧ください。

理事選挙をサポートするファシリテーター チームは、選挙運動期間中にいくつかの活動を用意しています。
7月31日︵土︶の19:30︵JST︶から、日本を含むアジア・太平洋地域のユーザーが候補者と交流できるオンラインイベントが開催されます。日本語による同時通訳も提供される予定ですので、どうぞお気軽にご参加ください。

こちらのフォームから事前に参加登録をお願いします。

フォームのプライバシーポリシーをご確認ください。

その他の活動については、メタウィキの理事選挙ページをご覧ください。

ご質問がございましたら、ファシリテーターか選挙ボランティアまでお問い合わせください。

選挙ボランティア一同 2021年7月24日 (土) 15:03 (UTC)

このお知らせは2021年ウィキメディア財団理事会選挙ボランティアにより作成され、botにより配信されました。 •フィードバック •購読解除

まもなく終了 理事会選挙へ投票のお願い

Ef3さん

こんばんは。お忙しい時間帯に恐れ入ります。

2021年ウィキメディア財団選挙は最終盤に入っております。これまでご協力いただいた皆様、ご投票いただいた皆様に心より御礼申し上げます。

もしEf3さんが投票をお済ませでなければ、ぜひこちらから清き一票をお願いいたします。

ウィキペディア日本語版の運営にも深く関与する理事会の候補者の選出に際し、投票資格をお持ちの数少ないユーザーの一人であるEf3さんのご意見を反映することは非常に重要だと考えています。

投票いただくに際し、まず19名の候補者からEf3さんが支持する方をお選びください。 支持する候補者を選んだら、支持する順に候補者の名前を選び、投票ボタンを押すだけです。 所要時間は5分未満で、完全な匿名性が保証されます。

投票は、日本時間の9月1日︵水︶の朝9時に締め切られます。

ウィキメディア財団の運営にウィキペディア日本語版コミュニティの意見を反映させるために、Ef3さんのご協力を重ねてお願い申し上げます。

どうぞよろしくお願いいたします。

--選挙ボランティア一同 2021年8月31日 (火) 11:14 (UTC)

このお知らせはウィキメディア財団2021年理事会選挙ボランティアにより作成され、botにより配信されました。 •フィードバック •購読解除