Wikipedia:井戸端

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

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

See more Help for Non-Japanese Speakers, If who write in languages other than Japanese. On the one hand, This page's purpuse is ask or discuss mainly in Japanese language. Its about policies and new ideas of Japanese Wikipedia.


次のような内容には、ここ井戸端でなく別の専用のページがあります。適切な場所に投稿が移動される場合があります。

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

過去ログ検索

井戸端の話題タグとは、既に分類された単語によるページのカテゴリのことです。

最近の更新

以下は、►のクリックによって期間ごとの話題がツリー表示されます。

運営方針
  • 投稿された全ての話題はサブページに移動し、Category:井戸端の話題にカテゴライズされています。
  • サブページは、最新の投稿から10日間経過するか、最初の投稿から30日が経過すると、井戸端への読み込みが解除されます。

ルビをふるテンプレートについて編集

特別:カテゴリ未導入のテンプレートを見ていて気がついたのですが、ルビをふるテンプレートが大量に作成されているようです。見つかったものを示すと

これらのテンプレートのうち{{キリスト教/ルビ要素}}以外はソックパペットによって作成されたと思われ、用途も本文中に使うという不適切なものですが、{{キリスト教/ルビ要素}}は表に使われており、元のソースが非常に汚かったのを若干ですが改善しているように思います(差分:キリスト教)。また、{{読み}}の解説文にこの機能を実現する具体的なソースも書かれており、Wikipedia:表記ガイド#読み仮名への誘導つきでテンプレート化されてもおかしくないような内容だと思います。そのようなテンプレートの案内がないのはなぜでしょうか。--プログラム会話) 2018年2月10日 (土) 18:30 (UTC)

  コメント Template:読み仮名を導入する際、ルビをそのまま表示する場合は特別なstyle指定も必要ないし記事中で多用される可能性も低いのでHTMLタグを直に書くほうが手っ取り早いかなと思ってテンプレートは作らなかったのですが、ニーズが有るようなら汎用のルビ表示用テンプレートを用意してもよいのではないでしょうか。
ただ、記事「キリスト教」のようなヘビーな使い方はマークアップの煩雑さもありますが、ルビ非対応のブラウザでの可読性がかなり厳しい面もあると思いますので類似の使用形態が積極的に使われることはそうそうなさそうな気はします。何かしら工夫できればとも思いますが、そもそものruby要素の仕様としてrbc要素はおろかrbタグすら主要なブラウザでは完全無視の仕様になっていると思われますので、テンプレート化したとしてもそこはある程度しょうがないのかなと。
仮にルビ表示用テンプレートを導入する場合、日本語版全体のCSSスタイルシートでrt要素のスタイル指定をデフォルトinline表示にしてしまう(ルビ表示用のTPでstyle指定が必要になる代わりに、より使用数の多い{{読み}}と{{読み仮名}}のstyle指定を簡略化できる)という選択肢ももしかしたら可能なのではないかと思います。--ディー・エム会話) 2018年2月11日 (日) 11:15 (UTC)
  コメント Chromeでは Template:読み仮名 の折り返し処理がされないようですが、今回の件には関係ないでしょうか?--Hiroes会話) 2018年2月12日 (月) 04:43 (UTC)
  返信 それは前からある現象で、より具体的にいうと折り返し処理はされるのですが、ruby要素部分がno-wrap指定されているかのような改行処理が(強制的に)されてしまうという仕様のようです。ですが、当該テキストの前に折り返し点がなければruby要素テキストの途中でも折り返されます(行頭がいきなりrubyタグで、なおかつ1行分以上の一連のテキストがそのrubyタグで囲まれていた場合など)。これはテンプレート特有の現象ではなく、ruby要素全般で発生するようです。当方Macがメインで今手元にWindowsが無いですが(切り替えればあるのですが面倒なので)過去にテストしたときの記憶では、Windowsでも基本同様の状況だったと思います。--ディー・エム会話) 2018年2月12日 (月) 06:50 (UTC)
なるほど。では今回の件とは関係ないというかこれらのテンプレートでも同様という事ですね。失礼しました。--Hiroes会話) 2018年2月12日 (月) 06:57 (UTC)
  情報 テンプレートではstyle属性で明示的にinline表示を指定しているので、inline表示されないと逆におかしいのですが、HTMLタグの基本どおりの用法でブラウザの仕様でそうなってしまうのでそれ以上はどうしようもないというのが正直なところです(無料で使っておいて文句も言えませんし)。長大な単語で使用しない限り大怪我はしないと思われるので以前から放置していますが、表組みなどでは行の字数がシビアなのでもしかしたら問題は起こりやすいかもしれません。その場合は潔く普通のテキストで括弧書きしていただくのが一番手っ取り早くて確実ではないかと。
ちなみにMac版safariもChromeと同様です。FireFoxはruby要素のデフォルトではno-wrap相当の折り返し禁止になりますが(Chromeなどと違って1行分まるまるruby要素でも折り返されません)、TP:読み仮名とTP:読みはinline表示で指定通り折り返されます。--ディー・エム会話) 2018年2月12日 (月) 07:35 (UTC)
(補足)折り返しの指定はwhite-spaceですが、テンプレートではそれも明示的に各要素ともnormalを指定していてもなおChromeには効かないという状態です。--ディー・エム会話) 2018年2月12日 (月) 07:49 (UTC)

  報告 Wikipedia:削除依頼/少池百合子のソックパペットによって作成されたルビテンプレートを提出しました。--プログラム会話) 2018年2月22日 (木) 00:24 (UTC)

ガイドラインで禁止とすることの解釈について編集

例えば今回お知らせにあった「Wikipedia:色の使用」は現状ガイドラインに過ぎないように見えますが、「xxは禁止」といった強い表現が見受けられます。結局はどのように解釈すればよいのでしょうか?--Hiroes会話) 2018年2月12日 (月) 04:52 (UTC)

  •   コメント そこまで厳密に解釈しなくてもいいでしょう。いちばん上に{{Guideline}}が貼ってありますが、その通り「多くの利用者が基本的に同意しており、従うことが推奨され」るもので、それ以上でもそれ以下でもないです。--Jkr2255 2018年2月12日 (月) 05:06 (UTC)
    • ありがとうございます。「ガイドラインに過ぎないと考える方」と「強い禁止の文言を真に受けた方」の間でトラブルが起きないかちょっと心配になったもので。杞憂である事を願いつつとりあえずは静観します。--Hiroes会話) 2018年2月12日 (月) 05:14 (UTC)
  •   Hiroesさん WP:COLOR個別の議論と、ガイドライン全般の議論と分けます。まず前者についてですが「原則禁止」、「その理由はXX」、「ただし例外としてXXはOK」、「かつ違反を発見しても、すぐさま差戻しは実践的な編集ではないので、理由を説明すべし」と明記してあります。したがって、全体を通して「強い表現」にはなっていません。是非、今一度WP:COLORの全文をご熟読ください。
続いて後者ですが、本日改訂する前のバージョンのWP:COLORを例にとります。明確な規制根拠や例外を明示せずに「原則禁止」と書かれていて、結局は個々人のセンス・主観で解釈が分かれてしまい、合意形成に寄与しきれていないガイドラインになっていました。私が概観した限りの印象ですが、このような弱いガイドラインは他にもいくつかあります。地道にノートページで議論し、改訂していくしかないでしょう。--Mis0s0up会話) 2018年2月12日 (月) 05:21 (UTC)
  •   Mis0s0upさん WP:COLOR全体はそうですね。紛らわしい書き方ですみません。ただ要旨では原則禁止となっており、後者と同様に主観に依存する文章だと思います。ではどう書くのがいいのかまでは今のところいい案がありませんが…--Hiroes会話) 2018年2月12日 (月) 06:28 (UTC)
  • もう少し話を単純化するなら「ガイドライン」の上で、原則とはいえ「禁じます」という文言がどの程度の意味を持つのかというのが疑問であります。元々守る義務のないもので禁じても強い非推奨と変わらないのではないのでしょうか。--Hiroes会話) 2018年2月12日 (月) 06:37 (UTC)--Hiroes会話) 2018年2月12日 (月) 06:42 (UTC)
  Hiroesさん なるほど、WP:COLORはNutshell部分のご指摘でしたか。たしかにうっかりしていて、原則の枕詞が抜けていました。本日ロールアウトした改訂では「中立性・正確性」の観点から色使用についての記述を補強したため、その趣旨が分かるようにNutshellを修正しました。差分をご確認ください。
さて、ガイドライン全体論ですが、私は{{Guideline}}のメッセージを英語版に合わせて修正するのが、効果的・効率的なのではないかと思います。"It is a generally accepted standard that editors should follow, though it is best treated with common sense, and occasional exceptions may apply."と書かれていて、日本語版と対比すると、
  • 【日本語版】「多くの利用者が基本的に同意しており、従うことが推奨されますが、方針ではありません。」
  • 【英語版意訳】「多くの利用者が基本的に同意しており、従うことが推奨されますが、良識と大局観を持って慎重に取り扱うことが求められます。また例外も存在するため、個々の状況に即してガイドラインを適用します。」
ガイドラインであれ方針であれ、そしてどんな文章表現であれ、杓子定規にそのルールを適用しようとする、「誰も求めていない自警団の取り締まり」みたいな残念な方も少なからずおられるのでしょう。英語版はこのような事情を加味した、オトナな文言になっているように感じます。--Mis0s0up会話) 2018年2月12日 (月) 07:06 (UTC)
解釈に幅があるが故に「例外的ケース」対「自警団」あるいは逆に「普通にダメ」対「ダメじゃないんでしょ?」を危惧したのですが、落ち着いて考えれば起きてから議論すれば済む話ではありますね。
差分を拝見させていただきました。かなり印象が和らいたように思います。ありがとうございました。--Hiroes会話) 2018年2月12日 (月) 07:30 (UTC)
追記。ガイドラインの「推奨」とは元々shouldの訳なのですね。個人的には推奨というとshouldよりbetter寄りな印象ですが、一般的にはそうではないのだと納得しておきます。多分PC系の「推奨環境」のせいですかね。--Hiroes会話) 2018年2月12日 (月) 07:48 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────  英語版のガイドラインは日本語版よりも合意形成に厳格な手続が必要なため、その分拘束力を持っています。Should (義務) を直訳して「推奨」と表現したわけではありませんので、ご注意下さい。

  • 私論の質: 日本語版では合意形成なしで私論が作成され、使われなくてもそのまま放置されることがあります。一方英語版では、私論も廃止手続が手引書で明文化されています。そのため英語版の場合、ガイドラインに格上げ前の私論であっても、一定の質が求められます。
  • 私論からガイドラインへの格上げ難易度: 格上げ提案から一定日数が経過し、採択されないと、英語版では自動的に「Failed (提案却下)」のステータスになります。一方、日本語版では格上げ提案を数年かけてダラダラやって、何となく数名が合意したらガイドライン化してしまうこともあります。
  • 日本語版独自のガイドライン: 多くのガイドラインは英語版で洗練された状態で、日本語版に輸入されます。ですが稀にWP:COLORのように、英語版より日本語版の方が検討度が先行しているケースもあります。日本語版はユーザ数が相対的に少ないので、日本語版独自のガイドラインはどうしても条文に不備が増えます。

なお、私はこれらの現状を上から目線で批判したいわけではありません。むしろ少ない日本語ユーザの環境下で、これまで先人たちはよく頑張ってきたなと思います。後発参画の私も、微力ながら環境改善に貢献していこうと前向きに捉えています。--Mis0s0up会話) 2018年2月14日 (水) 03:05 (UTC)

  • ご指摘ありがとうございます。日本語版と英語版ではそもそも各ルールの位置付けから微妙に異なっているという事ですね。不備といいますか、日本語版のユーザ数を考えれば、そう頻繁に起きないケースを一般論にまで詰めるよりは個別対応した方が効率的なのかもしれません。なるべくそういったレアなケースには拘らない様に努めたいと思います。--Hiroes会話) 2018年2月15日 (木) 17:40 (UTC)

見出しのない議論に第三者が見出しを与えることは許容されるか編集

はじめまして蚯蚓といいます。WP:TALKなどを参照しましたがいまいち見つからなかったので確認させてください。 主題は「ほかの方が見出しをつけずにノートに書きこんだものに対し、第三者がその議論の冒頭に見出しを付けて議論を整理することは可能か」ということです。 個別事案をお伝えします。ノート:北方領土問題の冒頭、見出しのない書き込みが6年ほど放置されていたのち、先日その書き込みにレスポンスがついておりました。この話題、ある程度続く可能性があり、ぜひとも見出しをつけたいと考えているのですが、第三者である私が見出しを付与する(また適切な位置=ノートの末尾に移動する)のは許容されるのか、いまいちわかりません。WP:TALKには他人の書き込みに対ししていいことと悪いことがある程度書かれていますが、今回の事案がどうなのかはっきりしません。どなたか見解をお聞かせください。--蚯蚓会話) 2018年2月15日 (木) 02:31 (UTC)

議論が追いやすくなるのであれば、別に構わないのではないでしょうか。個別事例は思い出せませんが、よくあることのように思います。ただ、私の発言に私の意図と異なる見出しを付けられたときに、その見出しを外させて頂いたことはあります。当然ながら、適切な内容の見出しが望まれますし、「見出しを付与した」というコメントを添えればなおよいと思います。--白駒会話) 2018年2月15日 (木) 03:08 (UTC)
WP:TALKNEWに基づき新しく見出しを付けました。」というコメントを付けて見出しをつけたことがあります。ご参考までに。--MawaruNeko会話) 2018年2月15日 (木) 14:37 (UTC)
お二方、ありがとうございました。そのように対応しようと思います。こういう事案は何回か見かけたことがありますので、ガイドラインに明記したほうがいいかもしれませんね。--蚯蚓会話) 2018年2月16日 (金) 03:05 (UTC)
私も、見出しがない状態で議論が記載されているノートに、便宜上の見出しをつけた経験があるように思います。複数の議論が識別できないと困りますから。既にお二方から意見が出ていますが「他者発言の改竄」には当然該当せず、正当な行為であると考えます。ただ、自分が付ける場合以上に、どういう見出しをつけるか気を配らないといけないでしょう。
「==ウィキ太郎さんが2017年2月20日に提起した議論==」というような、機械的に見出しを生成でき、見出しの内容についてトラブルが生じ得ない方法でつける、というルールでも良いかもしれません。--Pooh456会話) 2018年2月20日 (火) 10:21 (UTC)

アカウント作成の、作成されましたと自動的に作成されました。の違いは何ですか?編集

アカウント作成記録の「利用者アカウント○○が作成されました。」と「利用者アカウント○○が自動的に作成されました。」の違いはなんですか?--プログラマリオ(会話 記録) 2018年2月17日 (土) 11:33 (UTC)

一般単語記事名の非一般単語記事への単語の説明編集

THEOBROMA(企業記事)での[1]や、オーバーサイトのリダイレクト先のWikipedia:オーバーサイト(ウィキペディアの機能記事)の[2]などを戻されたりすることがありますが、この編集は問題ないのでしょうか、と不安になってしまうので念のため井戸端に出してみる -- 17の1会話) 2018年2月19日 (月曜) 09時28分 (UTC)

  • 議題提案者はWP:ILLEGITとして無期限ブロックされました。--ただのりゅうた会話) 2018年2月23日 (金) 01:41 (UTC)
  • 前者についてはよく分かりませんが、少なくとも後者はWikipediaに大きく関わるものについてのページなので、ノートでそれを追加する事についての提案をしていないから、というだけではないでしょうか?--プログラマリオ(会話 記録) 2018年2月19日 (月) 09:38 (UTC)
  • 自分の編集が取り消されると強硬にそれを戻そうとするのは無理矢理解決しようという姿勢に他なりません。そもそも、文書を合意なく変更するのはいけないことだと既に何度も教えられているはずです。他者の助言から学び取る気はないのですか。Wikipedia‐ノート:管理者伝言板においても、あなたの行った提案に反対意見のみ来た状態で一週間経過しているのに、適当な理由をつけて議論を継続しようというのはお話になりません。これ以上続くのであれば、WP:POINTに反していると見なさざるを得ません。--ただのりゅうた会話) 2018年2月19日 (月) 15:27 (UTC)
  • THEOBROMAについては有名でないギリシャ語の単語ですので日本語文脈では一般単語とはいいがたく、otherusesによる誘導にはあまり馴染まないでしょう。本文中にカカオを意味する言葉であることを説明しておくのがいいかと思います。オーバーサイトについては、一般的に使われる単語ですので17の1さんの追加されたものは必要な誘導であろうと思います。方針やガイドラインの中身を書き換えるのでなく閲覧者の利便を図る編集にいちいち合意が必要ということもまったくありませんのでどうか自信を持ってください。しかし、リダイレクトの削除依頼でIPユーザー氏が指摘しているように、曖昧さ回避ページがあるほうがより適切だとも思います。--cpro会話) 2018年2月20日 (火) 01:50 (UTC)
    • リダイレクトの削除依頼で俎上に上がっているのはオーバーサイトではなく「オーバサイト」です。--ただのりゅうた会話) 2018年2月20日 (火) 04:13 (UTC)
      • どうか、落ち着いて内容をお読みください。私は「リダイレクト『オーバサイト』の削除依頼におけるIP氏の『オーバサイトは曖昧さ回避であるべき』との発言」に言及したのであって、「リダイレクト『オーバサイト』の削除依頼」には言及しておりません。--cpro会話) 2018年2月20日 (火) 06:38 (UTC)
        • 申し訳ございません。上のコメントを残した際は少々冷静さを欠いていたようで、論点がずれておりました。オーバ「ー」サイト曖昧さ回避にすることでしたら賛同します。--ただのりゅうた会話) 2018年2月23日 (金) 01:41 (UTC)
  • THEOBROMAは「学名に使われるギリシャ語の意味」という表記では部分言及であり、otherusesは不適切に思います。ただ「カカオ属」へのリンクであればありかと思いますが。またオーバーサイトがwikipediaの説明へのリダイレクトになっている事自体がWikipedia:ウィキペディアへの自己言及に相当してるようで、オーバーサイトは曖昧さ回避であるべきだと思います。--115.39.24.45 2018年2月20日 (火) 02:41 (UTC)


単位は原則的に単位記号を用いず、かな・漢字で表記することの妥当性について編集

Wikipedia:表記ガイドでは「単位は原則として単位記号を用いず、かな・漢字で表記します。 」とあります。この規則は表記ガイドの制定当初からあったようですが、これについての妥当性を示されていないように思います。しかしながら、Wikipedia‐ノート:表記ガイド/過去ログ2#単位の前に半角スペースを入ると文章が間延びするので反対ですWikipedia‐ノート:表記ガイド/過去ログ10#単位の前のスペースなどでは、「リンクをつけていればいきなり記号による表記を行ってもいいという箇所に関して。単位記号は「NHK」のような略語と性質の似たところもあり、本文中ならば初出時くらい一度は日本語で書き下したほうがいいように思えます(しない理由があまりない)」という朝彦さんの言及があるくらいで、あまり考慮されずに前提となっていたようです。

英語版ではざっと見たところ単位記号を不可とする記載はなく、また、「ジュール毎キログラム毎ケルビン」などのように複雑になればなるほど見難いのですが、正当性があれば教えていただきたいです。--佐藤莞嬴会話) 2018年2月20日 (火) 10:10 (UTC)

Wikipedia:表記ガイド#単位で1行目でかな・漢字とするのは基本単位の話で、複雑な組立単位は例外扱い(5行目)だと書かれてるように思っていたのですが...。--115.39.24.45 2018年2月21日 (水) 11:51 (UTC)
おっと、失礼いたしました。「bpsppm、組立単位など、かな・漢字で書かない慣習のもの。」とありますね。これによれば、組立単位は一律例外扱いのようです。(平方メートルなどの単位がかな・漢字で書かない慣習のものかどうかは疑問が残りますが)
基本単位についてはいかがでしょうか。道路や鉄道などの記事でいちいちキロメートルと書くのは煩わしいので初回から[[km|キロメートル]]とできればうれしいのですが。--佐藤莞嬴会話) 2018年2月21日 (水) 12:38 (UTC)
平方メートルなどはSI組立単位に相当します。Wikipedia‐ノート:表記ガイド/過去ログ10#単位の片仮名表記にもあるように表記が煩雑だという話はあるものの、表記ガイドの本質的な見直しまでは到っていないのだと思います。将来的には単位はテンプレート化してマイクロフォーマットを埋め込むとか個々の閲覧趣向に応じて単位表記を変化させてほしい部分ではあります。--115.39.24.45 2018年2月22日 (木) 01:33 (UTC)
Wikipedia‐ノート:表記ガイド/過去ログ10#単位の片仮名表記この議論は完全に見逃していました。申し訳ないです。さて、windows10付属のナレーターで試してみたところ、kmは読まれますが、mは読んでくれませんでした。(たんにエムと読まれます。)また、kg,gはともに正常に読まれました。もっとも、誤読があまりにも多く(windows10ですらじゅうと読む)発展途上という印象も受けました。これについてはマイクローフォーマットで完璧な対応も可能ですし、ご提案の単位のテンプレート化も含めて、改善出来たらよいと思います。--佐藤莞嬴会話) 2018年2月22日 (木) 09:29 (UTC)

翻訳記事での画像の利用編集

はじめまして、お世話になります。 先ほどガラス特性の計算w:en:Calculation of glass propertiesから翻訳したのですが、画像を引っ張ってくることができませんでした。 どのようにしたら画像が表示できますでしょうか?

ファイルは英語版のウィキペディアにあって、パブリックドメインになっているようです。 --やねのすずめ会話) 2018年2月20日 (火) 12:19 (UTC)

現在英語版で確認作業中です。作業が終わり次第botによりコモンズにアップロードされますので、その後に反映が可能となります。--Open-box会話) 2018年2月20日 (火) 12:24 (UTC)

アカウント作成者の権限申請プロセス提案編集

Wikipedia:お知らせ#Tech News: 2018-06での説明通り、ビューロクラットアカウント作成者の権限を付与できるようになりました。これに伴い、ローカル(ウィキペディア日本語版)での権限申請プロセスを提案いたします。まず1週間ほど大まかなコメントを募り、続いて具体的な申請プロセス案を提出、1か月を目処に正式化したいと思います。--ネイ会話) 2018年2月24日 (土) 14:26 (UTC)

権限の詳細編集

日本語版でのアカウント作成者は「速度制限を受けない」(noratelimit)という権限を有します。これは、24時間以内に7個以上のアカウントを作成できるという意味です。使い方としては、権限を有する利用者がログインした状態でSpecial:CreateAccountをアクセスしてアカウントを作成することを想定しています。「無作為な仮パスワードを生成し、指定のメールアドレスに送信」という機能がありますので、新規アカウントのパスワードが権限を有する利用者に知られることはありません。

現時点ではスチュワード、ビューロクラット、管理者、削除者、巻き戻し者、ボットがnoratelimit権限を有しています。

申請プロセス編集

権限申請はWikipedia:権限申請にて受け付けます。手順はWikipedia:Bot/使用申請に準拠します。すなわち、(1週間程度の)コミュニティの審議を経て、問題がなければビューロクラットがフラグを付与します。権限申請者はアカウント作成者の権限が必要である理由(例えば、どのような教育プログラム、アウトリーチ活動に取り組んでいるか)、および権限が必要な期間を述べなければなりません。

権限付与の条件編集

下記のいずれかを満たす自動承認された利用者

  • 教育プログラムに取り組み、長期的に大量のアカウントを作成する必要がある利用者は、アカウント作成者の権限を1年間の期限付きで付与されます。権限を更新する必要がある場合はWikipedia:権限申請にて申請します。
  • アウトリーチ活動を主催するなど、短期間のイベントで大量のアカウントを作成する必要がある利用者は、そのイベントの前後数日間の期限付きでアカウント作成者の権限を付与されます。

コメント編集

  •   英語版ではCAPTCHAを通過できない利用者のためにen:Wikipedia:Request an account(アカウント申請)というプロセスがあり、それを処理するためのアカウント作成者権限でもあるようです。日本語版ではこのようなプロセスがないため、本提案には盛り込みませんでした。--ネイ会話) 2018年2月24日 (土) 14:26 (UTC)
  •   多分アカウントを作成してメールでPINを送るという方法で作成されるのでは無いかと思うのですが、教育プログラムの場合はその組織のプライバシーポリシーなどもあることから問題になる事は無いでしょう。アウトリーチの場合の個人情報の取扱いをどうするのかなどをつめる必要があるのでは?と思います。補足として「速度制限を受けない」(noratelimit)は管理者・削除者・巻き戻し者・ボットにも含まれていますからその辺りの取扱いもどうするか決めた方が良いのでは?あと実務面では希望するアカウントが既に使われてるのでその時別の名前を考えるという事態も結構発生してます。アウトリーチのような時間の限られたイベントの場合アカウント作成に時間を取られるのは結構致命的だとも思う。--Vigorous actionTalk/History) 2018年2月24日 (土) 15:16 (UTC)
  •   返信 想定している使い方を追記しました。「無作為な仮パスワードを生成し、指定のメールアドレスに送信」という便利な機能があるので、アカウント作成時の個人情報の取扱いは利用者名とメールアドレス程度で、問題は少ないのではないかと思います。現時点でnoratelimit権限が付与されている管理者などの扱いは、特に反対がなければそのままでよいと考えます。--ネイ会話) 2018年2月24日 (土) 15:42 (UTC)
  • 「無作為な仮パスワードを生成し、指定のメールアドレスに送信」という機能は使ったことがあるので知ってます。「アカウント作成時の個人情報の取扱いは利用者名とメールアドレス程度で」とのことですが、イベントで対面するでしょうからアカウントと個人が連結されます。なので作成依頼者に危険性等を説明して同意を取った後であればという条件は安全面から必要なのではと思います。財団の非公開情報へのアクセス権限のある利用者なら財団のプライバシーポリシーの制限を受けるので大丈夫だとは思いますが。。。--Vigorous actionTalk/History) 2018年2月24日 (土) 16:15 (UTC)
  • 「作成依頼者に危険性等を説明して同意を得る」ことを要件とするのは特に反対しませんが、それを履行していることの確認は難しいのでは?しかし、Access to nonpublic information policyの署名まで求めるのもオーバーキルに見えます。--ネイ会話) 2018年2月25日 (日) 05:13 (UTC)
  • 落としどころはアウトリーチの場合「財団の非公開情報へのアクセス権限のある利用者」か「作成依頼者に危険性等を説明して同意を得ることを要件にその履行が行われると信頼に足る利用者」あたりではどうでしょう?現状私の知る限りアウトリーチでお話されたり参加されてるWikipediaのアクティブな利用者で「速度制限を受けない」(noratelimit)を持たない人はこの条件を満たしていると考えます。あと、全く一人でと言うことも無いでしょうから履行確認は相互監視という手段で。--Vigorous actionTalk/History) 2018年2月25日 (日) 06:00 (UTC)
  •   「アカウントと個人が連結」について:イベントに参加して編集する以上、編集履歴から(アカウント作成に関係なく)結びつくことも多いので、前者の「財団の非公開情報へのアクセス権限のある利用者」ほど大きなハードルを設ける必要はなく、「削除者」や「巻き戻し者」と同じように「(その行為について)適切な対応を出来る利用者」程度でよいと思います。なのでどちらかというと後者の「作成依頼者に危険性等を説明して同意を得ることを要件にその履行が行われると信頼に足る利用者」のほうに賛成ですが、説明漏れを防ぐため(私だったら毎回何か言い忘れそう)「アカウント作成依頼」について説明する文書を作成して「アカウント作成依頼説明文書を示して同意を得たうえで履行すると信頼に足る利用者」とするのが確実かもしれません。--miya会話) 2018年2月25日 (日) 15:36 (UTC)
  •   書き方悪かったですね、「財団の非公開情報へのアクセス権限のある利用者」か「作成依頼者に危険性等を説明して同意を得ることを要件にその履行が行われると信頼に足る利用者」のいずれかを満たす。という意図でした。あと、アカウント作成依頼説明文を作成するのは良いですね。紙の処分を気にしなくて良いんだったら、作成依頼書みたいなののフォーマット作っておいて、そこに説明文を入れるのも一つかもね。--Vigorous actionTalk/インデント修正及び下線部追記History) 2018年2月26日 (月) 03:21 (UTC)--Vigorous actionTalk/History) 2018年2月26日 (月) 03:30 (UTC)
  •   「権限付与の条件」について:「アウトリーチ活動を主催するなど」について「そのイベントの前後数日間の期限付きで」と提案されていますが、今実際にアウトリーチ活動に携わっている方々は「数週間に一度」や「1か月に複数回」ほうぼうのイベントの補助に入られていて、そのたびに申請(BCにとっては付与と除去)を繰り返すのは非効率的ではないかと感じます。なので「アウトリーチ活動を主催または補助するなど、短期間のイベントで大量のアカウントを作成する必要がある利用者」は「アウトリーチ活動期間内で1年間を上限としてアカウント作成者の権限を付与されます。」としてはどうかと思います。--miya会話) 2018年2月26日 (月) 02:44 (UTC)
  •   同意します。--Vigorous actionTalk/History) 2018年2月26日 (月) 03:21 (UTC)

一部のサッカークラブの記事名について編集

Template:ウクライナ・プレミアリーグのリンクを見て思ったのですが、ほぼすべてのチームが「FC」表記となっています。元は "ФК" なので、英語で一般的な「FC」表記よりもラテン文字転写例の「FK」となるのが妥当ではないでしょうか。--BR141会話) 2018年2月25日 (日) 17:13 (UTC)