Wikipedia:井戸端

ナビゲーションに移動 検索に移動
ネパール、ララ湖の虹
相談と質問
井戸端
利用案内
調べもの案内
執筆・翻訳者の広場
For Non-Japanese Speakers

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

  • 下記の過去ログ検索機能にて、既に似た質問がないか質問前にご確認ください。
  • よくある質問(FAQ)もご確認ください。なお、この井戸端で特に多くされている質問があれば、その内容をFAQの適切なサブページに追加するようにお願いします。
  • ウィキペディア日本語版やウィキメディア・プロジェクトと関係のない話題を投稿するのはご遠慮ください。

This page is for discussion of Japanese Wikipedia, normally in Japanese. But see also Help for Non-Japanese Speakers.


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

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

過去ログ検索

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

最近の更新

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

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

関連カテゴリ提示用テンプレートの使い分けについて[編集]

コメント 現在、関連カテゴリを提示するための内部リンク生成用テンプレートが、Template:CatlinkTemplate:Category see alsoの2つあります。前者は日本語版独自のテンプレートで、後者は英語版から移植されたテンプレートのようです。両者は用途が重複しているような気がするのですが、皆様はこれらを場合に応じて使い分けていますでしょうか。もし使い分けられていないなら、統合も視野に検討してみてはいかがでしょうか。--Doraemonplus会話) 2019年6月26日 (水) 11:55 (UTC) 誤字訂正。--Doraemonplus会話) 2019年6月26日 (水) 11:56 (UTC)

コメント 個人的には、前者に統合した方が良い気がします。テンプレート名も短いですし、説明も有りますし。--お好みでタピオカをおかけください会話) 2019年6月26日 (水) 13:47 (UTC)
コメント 前者が2008年に日本語版で独自に作られたものでカテゴリ10件まで、後者が2006年に英語版で作られたものを2014年時点で持ち込まれたようで、カテゴリ40件までに対応しています。ただ、日本語版は2016年以降メンテナンスされていませんが、英語版の方はその後2017年にLua化されてen:Module:Category see alsoに機能統合されており、日本語版よりも更に高速化・多機能化(恐らく引数が無限引数化)されたのではないかと思われます。
前者に全て機能統合する場合、なぜか後者は未使用状態のModule:Category see alsoが持ち込まれていますから(ていうか質問者さんが持ち込まれていますが)、これの扱いも含めて議論する必要があるんじゃないかなー、と思います。
個人的には日本語版独自のCatlink使用数1万5000件弱に対し、Category see alsoは120件弱なので、前者統合の方がリンク張替え作業などの後処理が楽だろうな、と思いますが、実際に統合合意された場合は同時にbot作業合意することになるでしょうから、張替えに掛かる労力自体を重視する必要性は高くないでしょう。--Nami-ja [会話 履歴] 2019年6月26日 (水) 18:14 (UTC)
確認しましたが、現状、en:Module:Category see alsoを利用したen:Template:Category see alsoが最も機能的に勝ていると思います。現状のen:Template:Category see alsoja:Template:Catlinkに移植(言語間リンクもこちらにする)して、ja:Template:Category see alsoja:Template:Catlinkへのリダイレクトにするのがきれいかなと思います。--翼のない堕天使会話) 2019年6月26日 (水) 22:32 (UTC)
これらのテンプレートに関して事実確認して頂き、ありがとうございます。皆さんも特に両テンプレートを使い分けているわけではない様子がわかり、統合への期待が一段と高まりました。というわけで、正式に統合を提起しました。使用ページ数ではCatlinkが圧倒的、機能性・高速性はCategory see alsoが上、とのことから、統合先はTemplate:Catlinkとし、中身は現状のen:Template:Category see alsoより移植して、後者から前者へのリダイレクトとする、翼のない堕天使さんの案をほぼそのまま採用させていただいています。ちなみに、ja:Module:Category see alsoは(Nami-jaさんがご指摘の通り)私が昨日、en:Template:Category see alsoのLua化に合わせてja:Template:Category see alsoを更新するつもりで、英語版(と少々中文版)より持ち込んだものですが、まだテンプレート本体の方には手をつけていないため、モジュールは未使用の状態です。中途半端ですみません。上述した統合案で合意された暁には、統合後のテンプレートに最適化して使って頂ければ、と思います。--Doraemonplus会話) 2019年6月27日 (木) 08:06 (UTC)

報告 本日、両テンプレートを統合し、{{Catlink}}に一本化しました。もし仕様に不備がありましたら、どなたかスクリプトに通じた方が修正してくださると助かります。--Doraemonplus会話) 2019年7月9日 (火) 09:35 (UTC)

コメント for i, cat in ipairs(args) do(入力最大数分繰り返す)なので、たぶんですけど入力最大数の仕様は40ではなく無限だと思います。40個限定にするならココを書き換えることになりますね(必要ないと思いますが)。--Nami-ja [会話 履歴] 2019年7月12日 (金) 13:35 (UTC)
モジュールではなく、テンプレートの解説ページの方を修正(40個制限の記述を削除)しておきました。ご指摘頂き、ありがとうございました。--Doraemonplus会話) 2019年7月14日 (日) 12:21 (UTC)

Wikipediaでのレビューサイトの取り扱いについて[編集]

約10年前にスーパーロボット大戦Kにおいて、mk2の内容をもとに評価節を設けて追記した分を取り消されたことがあり、他記事のノートなどで様々な編集者が異口同音に「レビューサイトは出典にならない」という文言を見かけ、レビューサイト#批判においても信頼できない一因は挙げられています。もうレビューサイトを用いた編集を行うつもりはありませんが、なぜWikipedia:検証可能性#通常は信頼できないとされる情報源でレビューサイトを例として明記していないのかという疑問はあります。--ペン打ゴン会話) 2019年6月29日 (土) 00:31 (UTC)

基本的に「誰でもレビューを投稿」できるサイトの点数や評価は「信頼できない情報源」です。ただ映画の例ですが、プロの批評家の評価を集めたレビューサイトRotten Tomatoesの評価などは認められています。職業としてレビューをしている人物による評価なら出処を明記すればウィキペディアに記述できます。--Afaz会話) 2019年6月29日 (土) 00:44 (UTC)
返信ありがとうございます。確かに「レビューサイト」の単語を含むものを検索すると、主に日本国外の映画の記事が多く引っ掛かっていました。--ペン打ゴン会話) 2019年6月29日 (土) 03:20 (UTC)
(追記)「職業としてレビューをしている人物(以下略)」の部分に関する質問ですが、例として前田有一はいかがでしょうか。同項目の外部リンクにある「前田有一の超映画批評」で「それが映画をダメにする」という本を出したことに触れており、その本が自費出版の類でなければ「超映画批評」を出典として使えると解釈して大丈夫でしょうか。--ペン打ゴン会話) 2019年7月14日 (日) 11:44 (UTC)

日本人の姓の区別について[編集]

24歳、学生のウィキペディアンです。ウィキペディア日本語版では、同名表記の記事は括弧を付けて見分けていますよね。

「同じ表記だけど意味が違うことば」は別々の記事にして、それぞれを括弧で見分けているんですよね。で、それはわかるんですけど、これはコモンズではどうなっているんでしょうか。コモンズで最近「日本人の姓」が乱立しているんですが、これはどうやって区別しているんでしょう。「鈴木」だと

となっています。株式会社スズキとかと区別をつけるため「surname」と入れてるんでしょうけど、では「伊藤」「伊東」「井藤」「依藤」の区別はどうなってるんでしょうか…。全部「surname」ですが、「伊藤」と「伊東」はそもそも違う苗字ですよね。新字体と旧字体で「藤沢」「藤澤」を同じ「Category:Fujisawa (surname)」にカテゴライズするのはわかりますが、「藤」と「東」は全然違う字ですからね…。ちなみにウィキデータでは「Japanese family name (伊藤)」「Japanese family name (伊東)」と分けてるみたいです。これをウィキペディアで質問するなよ、という意見もあるかもしれませんが、日本語版の読者の方が一番詳しいと思うので質問します。--126.146.82.109 2019年6月30日 (日) 16:51 (UTC)

すみませんが、英語という前提において、原語の漢字の違いを区別する必要はないと思います。これは逆を考えてみればよいのですが、それこそゲルニカは、英語やスペイン語では "Guernica" ですが、そもそものバスク語では "Gernika" であり、綴りが違います。でも、日本語としてカタカナ表記にしたらゲルニカであり、「ゲルニカ」で記事が作られるんです。こういうは他にもウィスキー(whisky or whiskey)とかいくらでもありますし、今回の例とは少し違いますがマイケル、ミシェル、ミカエルの読み違いのパターンもあるでしょう。--EULE会話) 2019年7月1日 (月) 09:55 (UTC)
EULEさんの説明に便乗しますと、マイケル英語: Michael)には同義語としてミヒャエルドイツ語: Michael)、ミハイルロシア語: Mikhail)、ミシェルフランス語: michel)、ミゲルスペイン語: Miguel)などがありますが全てミカエルヘブライ語: מִיכָאֵל‎、英語: Michael)を語源にするものです。そしてそれぞれが別々の日本語として記事が作成されています。各言語圏での表記/発音変化例が凄まじいことになっているエリザベスも参考になるかなと。
故に、コモンズのカテゴリについてですが、渡邉、渡部、亘鍋、綿鍋、綿奈部、綿辺、渡那部、渡邁、渡鍋、綿部、といった同音異義語についても『 読み発音として、Watanabeと読むこと 』を第一理由としてcommons:Category:Watanabe (surname)に分類されると思います。その上で、もしその分類で何らかの著しい不便・不具合が生じれば、例えばですけどWatanabeの下位に属する子カテゴリとして「Category:Watanabe (渡邉)」のような形で再分類(合意)する未来があるかもしれないとは個人的には思います。--Nami-ja [会話 履歴] 2019年7月2日 (火) 13:48 (UTC)
Nami-jaさん、ご説明ありがとうございます。コモンズで明確に(あるいは、慣習的にでしょうか)「読み発音として、○○と読むこと」が第一条件として通用しているのですね。なるほど理解しました。それならば、本来は異なる姓であっても偶然にも英語で同じ綴りなら、渡那部や亘鍋も同じcommons:Category:Watanabe (surname)になるのは、第一条件どおりの分類作法なのですね。ウィキデータのお作法では渡那部と亘鍋のようなものは明確に分けていたのでコモンズでは分けないのは何故だと思ったのですが、コモンズでは同一扱いになる理由について理解いたしました。ありがとうございます。また、Watanabeの下位に属する子カテゴリとして「Category:Watanabe (渡邉)」で再分類するような合意が将来的になされるかも、というのは確かにありそうな話ですね。ただ、現時点ではそのようなルールはないようなので、私は今現時点での慣習に従うようにしたいと思います。--126.183.65.210 2019年7月3日 (水) 13:33 (UTC)
EULEさんのコメントに一言。EULEさんの挙げている例は、今回の質問とは全く無関係の話題ですよね。最初読んだとき「おふざけが過ぎる」と感じました(無論悪気はないのでしょうが)。そもそも私が質問しているのは「それぞれ別々の事物であり、母語では綴りが異なっているが、別言語にすると同じ綴りになってしまう場合」についてお聞きしています。たとえば、姓の「伊藤」と「伊東」は別々の事物であり、日本語では綴りが異なっているので区別できますが、別言語にすると同じ綴りになってしまい区別できなくなってしまいますよね。その点についてお聞きしているのです。「伊藤」と「伊東」は別々の事物ですから、姓が「伊藤」の人は、英語で綴りが同じだからといって「伊東」という姓で代替できませんよね。私がしているのは、同言語内で「同表記異義」となる姓の話です。
それに対して、EULEさんの挙げている例は「同一の事物が、複数の言語でそれぞれ綴りが異なっている場合」の話しですよね。そんなこと誰も質問していないと思いますが、何故いきなり唐突に無関係の話しをぶち込んできたのかとちょっとびっくりしました。あなたの挙げている例でいいますと、たとえば地名のゲルニカであれば、スペイン語「Guernica」とバスク語「Gernika」は綴りが異なりますが、双方とも同一の事物を指していますよね。同一の事物である以上、日本語版でも記事は「ゲルニカ」が一つできるだけに決まっているではありませんか。何も悩む必要は全く無いですよね。「同一の事物の場合、ページは一つ」というのは誰でも知ってる基本的なルールの一つでしょう。「Guernica」と「Gernika」は同一の事物であり、「Guernica」と「Gernika」は全く同じものを指していますから、単に言語によって綴りが違うというだけでしょう。あなたが言ってるのは、言語間での「異表記同義」の話ですよね。なぜそんな話を突如しはじめたのでしょう。
……たとえば、イヌの場合英語「Dog」とフランス語「Chien」は綴りが異なりますが、双方とも同一の事物を指していますよね。その場合、日本語では当然「イヌ」というページが一つできるだけでしょう。「イヌ (Dog)」と「イヌ (Chien)」のようにそれぞれ別々にページが必要ではないか…などと悩むような人は一人もいないでしょう。冒頭の私の質問の仕方がわかりにくかったなら謝罪しますが……ただ、いま読み返してもそんなわかりにくいことを書いているとは思えませんが…。私の質問の意図を理解したうえでズレたたとえを出してきたのであればちょっとどうかと思いますし、私の質問の意図を理解せずにズレたたとえを出してきたのであればもう勘弁いただきたいのですが。井戸端を閲覧する人の迷惑にもなるでしょう。--126.183.65.210 2019年7月3日 (水) 13:33 (UTC)
それから、マイケル英語: Michaelミヒャエルドイツ語: Michaelミハイルロシア語: Mikhail)…などは全てミカエルヘブライ語: מִיכָאֵל‎を語源にしている、というのは、日本語の姓での話しでいうと「小沢」と「小澤」、「沢田」と「澤田」のようなものが近いかもしれませんね。戸籍上「小澤」「澤田」であっても、手書きや新聞用字など俗な用法では「小沢」「沢田」と書く人は珍しくありません。とはいっても、正式な書類では、戸籍あるいは住民登録などと一致する「小澤」「澤田」でないとダメだよ、となる場合もありますよね。これなんかは同一の事物、といってもいいようですし、別々の事物、といってもいいように思います。--126.183.65.210 2019年7月3日 (水) 13:33 (UTC)
いや、間違っていないし、ふざけてもいないです。例えが悪くて私の指摘がご理解できなかったというなら、ナイト(騎士か夜か)とかリード(読むか先導か)とか、いくらでも挙げますが。特にリードは人名も絡みますし。つまり、
>「伊藤」と「伊東」は別々の事物ですから、姓が「伊藤」の人は、英語で綴りが同じだからといって「伊東」という姓で代替できませんよね
英語表記上、Itouとして代替できるし、それは別におかしなことではないと言っております。もちろん、それを日本語で言えば「リード(Lead)」と「リード(Leed)」と「リード(Read)」と単独立項しても構いませんが、しなくても問題ないという話です。--EULE会話) 2019年7月3日 (水) 13:56 (UTC)
「間違っていないし、ふざけてもいない」とはどういうことでしょうか。「それぞれ別々の事物であり、母語では綴りが異なっているが、別言語にすると同じ綴りになってしまう場合」について質問しているのに、突然議題と無関係な「同一の事物が、複数の言語でそれぞれ綴りが異なっている場合」について独り語りを始めたわけですが、それで「ふざけてもいない」と言い張るつもりですか? ではなぜ同言語内で「同表記異義」となる姓の話について質問されているのに、言語間での「異表記同義」の話をはじめたのでしょうか? 「間違っていない」などとのたまっていますが、じゃあ聞きますけど、あなたのゲルニカのたとえは同言語内で「同表記異義」となる話だったのですか? そうではないですよね。ゲルニカのたとえはスペイン語とバスク語の綴りの違いですから、明らかに同言語内で「同表記異義」となる話ではないじゃないですか。……ってこうして指摘されたから、今度は慌ててナイトのような「それぞれ別々の事物であり、母語では綴りが異なっているが、別言語にすると同じ綴りになってしまう場合」の話しに軌道修正してきましたね。だったら「同一の事物が、複数の言語でそれぞれ綴りが異なっている場合」のような無関係の話しをせずに、最初から「それぞれ別々の事物であり、母語では綴りが異なっているが、別言語にすると同じ綴りになってしまう場合」のたとえを挙げればよかったのに。でもですねぇ、「ナイト」はたしかに英語では「knight」「night」ですから「それぞれ別々の事物であり、母語では綴りが異なっているが、別言語にすると同じ綴りになってしまう場合」つまり「同言語内で「同表記異義」となる話」ではありますが、ジャンルが違うから仮に同名ページができたとしても「ナイト (騎士)」「ナイト (夜)」のように括弧でかんたんに識別可能じゃないですか。それに対して、今質問している姓の場合、たとえば「渡那部」「亘鍋」はどちらもジャンルがsurnameですから双方「Category:Watanabe (surname)」となってしまい区別できない、という話をしているのに……。まったく、いい加減にしたらどうですか。上手いたとえが思いつかないのなら、無理して下手なたとえを披露する必要はありません。いっちょかみみたいに意味も分からず口をさしはさむ必要はありません。いい加減にしてください。--126.146.17.85 2019年7月5日 (金) 16:27 (UTC)
そもそもcommons:Category:Watanabe (surname)は、どういう場合に使うのでしょうか。名前が写った(?)写真でしょうか。人物写真だとちょっと違う(人物ではなく名前(surname)についてのカテゴリを適用するのは、カテゴリ名に合わない)気がしますが。「渡辺家の家系図の写真」とかでしょうか。 --2001:240:241F:7B59:C998:FB2A:6B78:77BF 2019年7月4日 (木) 07:39 (UTC)

コメントコモンズは英語版ウィキペディアと同じく伊藤と伊東の違いは区別してないみたいですね。ぜんぶIto。ちなみにウィキデータでは「いとう」「イトウ」「伊東」「伊藤」…すべて区別されて別項目になります。人手不足で整備が追いついてないですが。コモンズはウィキデータからデータをとってきてるので、リンクがおかしいのもあるかもしれませんが、そのうち改善されることに期待しましょう。--Afaz会話) 2019年7月4日 (木) 07:55 (UTC)

コモンズはウィキデータのからデータを引っ張ってきているので、ウィキデータで指定されたfamily nameに従って自動でカテゴライズされてしまいます。たとえば「Category:Miki Watanabe」は、明示的に「Category:Watanabe (surname)」にカテゴライズされてはいませんが、Wikidata Infobox等でウィキデータと連携させたら自動でカテゴライズされてしまうようです。たしかに渡辺家に因んだ画像がカテゴライズされるわけではありませんし、「人物ではなく名前(surname)についてのカテゴリを適用するのは、カテゴリ名に合わない」という指摘はたしかにその通りだと思います。でも、もう運用始まっちゃってるんですよね…。また、ウィキデータは日本語話者があまりに少ないせいか滅茶苦茶なものも多数あり、同じ姓が別に登録されていたり、明らかに英字表記や読み方が違っていたりという状況が続いています。自分も気が付いたときに直してはいるんですけど焼け石に水ですよねぇ…「人手不足で整備が追いついてないですが。コモンズはウィキデータからデータをとってきてるので、リンクがおかしいのもあるかもしれませんが、そのうち改善されることに期待しましょう」。--126.146.17.85 2019年7月5日 (金) 16:27 (UTC)
 質問 上記、IPv4のSoftbankBBさんとIPv6のIIJさんは同一人物ですか?。--Nami-ja [会話 履歴] 2019年7月6日 (土) 04:57 (UTC)
IPでの投稿のうち、126始まりはすべて私です。2001始まりは別の方です。--126.188.100.47 2019年7月6日 (土) 05:58 (UTC)

副アカウントの使用におけるブロック措置について[編集]

2つのアカウントを告知なく使用しており、こちらに触れた様でブロックされてしまいました。この様な場合はアカウントをブロックした管理者の方へ、方針に従い副アカウントを使用する旨を連絡する事で解除して頂けるのでしょうか?--126.245.76.137 2019年7月5日 (金) 09:36 (UTC)

ブロックされたのだとしたら、ログアウト状態でここに書き込むのもまずくありませんか? 質問なり解除依頼なりは、アカウントの会話ページでするように案内されていると思いますが…--240F:65:86BA:1:B9EC:52EF:90AF:AB0F 2019年7月5日 (金) 18:25 (UTC)
『パスワード紛失等で、当該アカウントにログイン出来ない』のなら兎も角、そうでないならば当該アカウントの会話ページで、質問なり解除依頼を行ってください。会話ページも編集不可でIRC?が使えない環境、という訳でも無さそうですし、ブロック逃れでIPブロックされる可能性がある行為です。--お好みでタピオカをおかけください会話) 2019年7月9日 (火) 19:24 (UTC)

記事「アグアルディエンテ」がスペイン語版からの履歴継承なしの機械翻訳っぽい件について[編集]

解決済み 解決済み 削除されました。初版記事名の「Aguardiente」も{{即時削除|リダイレクト1-3}}貼付により削除されました。--野良人会話履歴 2019年7月15日 (月) 15:18 (UTC)

アグアルディエンテ」なんですが、(初版が)非常にスペイン語版からの機械翻訳っぽいんですね。作成者の投稿記録を見ると、最初の編集がこの記事の作成で、それ以外の記事に全く手を付けておられない。で、作成2分後にIPユーザーの方が「スペイン語版記事からの履歴継承なしの翻訳につきSD」として{{SD|G2}}を貼られたのですが、2日後に別のIPユーザーの方に「酷い翻訳記事というのはSD案件ではないでしょ。」として剥がされてます。私は特に削除派では無いんですが、履歴不継承での記事翻訳はアウトなんじゃないかと気になってしょうがないんですが、どんなもんなんでしょうか?--野良人会話履歴 2019年7月7日 (日) 14:48 (UTC)

コメント 記事の作成者に連絡してWikipedia:翻訳のガイドライン#要約欄への記入忘れ・誤記入を参考に適切なリンクと翻訳情報を要約欄に入れてもらってください。返信がない場合はケースB-1「履歴の不継承」で削除を依頼してください。この事例のような場合は即時削除ではなく「履歴情報の追補」をまず考えてください。--Afaz会話) 2019年7月7日 (日) 23:32 (UTC)
コメント 機械翻訳の場合、該当する削除関連方針はWP:CSD#G2(投稿テスト)ではなくWP:DEL#G(機械翻訳)ですね。そして、初版の履歴不継承ですが、Afazさんが仰っておられる方策の後に、初版から履歴継承された版の直前版までを著作権侵害、WP:DEL#B-1案件として版指定削除依頼することになります(Wikipedia:版指定削除の方針#履歴不継承)。──野良人さんがアカウント作成された2006年以降、10年くらい前?までは初版からの履歴不継承案件は記事削除・履歴継承した上で再立項するしか方法がなかったんですけど、版指定削除(特定版削除)が実装された現在のウィキペディアでは著作権侵害が発生している版のみを指定して削除できるように変化しています。詳しくはWP:RDP#版指定削除機能行使の範囲辺りを確認されてみて下さい。--Nami-ja [会話 履歴] 2019年7月8日 (月) 06:17 (UTC)
コメント 履歴を欠く機械翻訳なので削除依頼は避けられません。Wikipedia:削除依頼/アグアルディエンテを提出しました。なお、機械翻訳の放置はそれ自体が削除対象になりますので、改稿しなければ版指定削除ではなく削除となります。--Open-box会話) 2019年7月8日 (月) 10:24 (UTC)
コメント 感謝 みなさんコメント・情報提供ありがとうございます。頂いた情報については今後同様の案件を見かけた際の参考とさせて頂きます。今回の件については削除依頼で動いて頂いてますので、そちら方面にお詳しい方々にお任せします。--野良人会話履歴 2019年7月9日 (火) 06:44 (UTC)

エラー: #time の呼び出しが多すぎます の解消方法[編集]

ひょんなことから編集に関わったNGT48の脚注欄に「#time の呼び出しが多すぎます」という赤字エラーが出ていたので、調べたところ井戸端/subj/翻訳記事作成時の出典の書き方(互換性なし)についてが見つかりました。そこで{{Cite web}}を{{Cite web2}}に置き換えたところ、節編集のプレビュー段階では解消したのですが、ページ全体をリロードすると別のところでまた同じエラーが起きます。何度か試みましたがモグラたたきなので諦めました。{{Cite web}}を{{Cite web2}}に一斉置換するbotはあるのか、別の回避方法はあるのか、または脚注が385もあるのがそもそも規格外だからあきらめて放置した方が良いのか、ご教授ください。--Topaz2会話) 2019年7月12日 (金) 07:41 (UTC)

コメント ウィキテキストエディターの右上にある虫眼鏡マークをクリックして、ページ内の置換することができます。 {{Cite web{{Cite web2 で「大文字・小文字を区別する」のチェックを外して「すべて置換」を押せば、ページ内ですべて置き換えられます。節名の全角スペースを半角スペースに変更。サブページ化の際に自動で変わるので。--Yuukin0248[会話/履歴] 2019年7月12日 (金) 08:59 (UTC)
コメント 感謝  ウィキテキストエディターの右上にある虫眼鏡マークを、初めてクリックしました。ご助言いただきありがとうございます。エラーも解消したようです。--Topaz2会話) 2019年7月13日 (土) 03:56 (UTC)

インデントの回数の具体的な規定について[編集]

質問なのてすが、インデントの回数に制限はあるのでしょうか?(私には見つけられませんでした。)もしないのであれば、回数に制限を設けるガイドラインの制定を希望します。 ウィキペディアではノートページ、依頼・提案ページでの議論にインデント(字下げ)が使われています。多くの利用者は:コロンや*アスタリスクを使ってインデントしているようです。自分の経験ですが、コロンを使ったインデントでは良くインデント戻しが行われているようです。しかし、アスタリスクを使ったインデント(管理者伝言版等)ではあまりインデント戻しがされない傾向にあるようです。例えばこの井戸端を書いた時点での管理者伝言板/投稿ブロックでは************アスタリスク12個が最大のようです。ここで問題なのが、モバイル版での閲覧です。モバイル版ではアスタリスク10個で右2行、11個で右1行、12個以上は横スクロールして右1行です。実際文として読めるのは右2行が限界です。気になったのでインデントの回数の規定をさがしてみましたが、Help:ページの編集#字下げでの「あまり深くなり過ぎると、読みづらくなるかもしれません。」以上に言及しているガイドラインが見つかりませんでした。どなたかガイドラインの提示、これに関する過去の議論等ご存知でしたらご教示ください。無いようでしたら、ガイドラインでの規定を希望します。(推奨という形でも規定が明文化されていれば利用者に直接トークページでお願いできます。) どこで提起すべきか迷いましたがウィキペディアの編集全体に関わると思い井戸端での意見とします。--そらたこ🐙(会話) 2019年7月13日 (土) 03:59 (UTC)

コメント お気持ちはわかります。「深くなりすぎると読みづらい」のは確かですしね。ただ、閲覧環境というのは日々変わっていくものなので、具体的な回数を数字で規定するというのは悩ましい面があります。一般的なノートページで、複数利用者による対話が進んでインデントが深くなっていく場合には、適当なところでインデントを戻しても、そのことでクレームがつくことはあまりないと思います。その話題が肥大化したときなど状況によっては節を細かくすることもありますね。
しかし管理者伝言板の場合、1案件の途中でインデントを戻されると、案件の見通しが悪くなったり、そのために管理者側としては何が何だかわからなくなり、対処が遅れる的な弊害があるかもしれません。管理者伝言板の場合には肥大化したからと言って節を細かくするわけにもいきませんし。
そういう場合、本当の用法からするとマチガイかもしれないですが、段落の頭下げをして見通しのよさを確保するとかはどうでしょうね。
  • 案件
    • コメント1
      • コメント2「***コメント2」
        • コメント3「****コメント3」
  • コメント4「:*コメント4」
とか。-柒月例祭会話) 2019年7月13日 (土) 04:31 (UTC)
コメント 意外と知られてないみたいですが、インデントを戻した事実を提示する専用のテンプレートとして{{Outdent}}が存在しています。これを利用すると:
* {{コ}} 話題1
** {{コ}} 話題2
*** {{コ}} 話題3
**** {{コ}} 話題4
***** {{コ}} 話題5
****** {{コ}} 話題6
{{Outdent|7}} {{コ}} 話題7
  • コメント 話題1
    • コメント 話題2
      • コメント 話題3
        • コメント 話題4
          • コメント 話題5
            • コメント 話題6

──────────────────────────────────────────────────────────────────────────────────────────────────── コメント 話題7

…といった感じで表示されます。こちらの方法ですと、管理者伝言板/投稿ブロック上でも繋がりのある1案件ツリーであることを視覚的に認識維持した上でインデント戻しが行えますので積極的に活用していいと思います。--Nami-ja [会話 履歴] 2019年7月13日 (土) 05:34 (UTC)
コメント ひとつ問題があるとすれば、
* {{コ}} 話題1
** {{コ}} 話題2
*** {{コ}} 話題3
**** {{コ}} 話題4
***** {{コ}} 話題5
****** {{コ}} 話題6
******* {{コ}} 話題7(= 話題6への返答その1)
******* {{コ}} 話題8(= 話題6への返答その2)
***** {{コ}} 話題9(話題4への返答)
  • コメント 話題1
    • コメント 話題2
      • コメント 話題3
        • コメント 話題4
          • コメント 話題5
            • コメント 話題6
              • コメント 話題7(= 話題6への返答その1)
              • コメント 話題8(= 話題6への返答その2)
          • コメント 話題9(話題4への返答)
などとしたい場合に(↑それこそ見辛い……)、一度でもインデントを戻してしまうと不可能になってしまうことですね(管理者伝言板よりもノートで起こるケースかな?)。これに関しては、私は差分を指定するなどして返答する等の対処をしていますが、直感的に分かりにくくなってしまうのは悩みどころではあります。--610CH-405会話) 2019年7月13日 (土) 06:18 (UTC)
コメント そこまで行っちゃうと無理にツリーに繋げるのではなく、単にWikipedia:管理者伝言板/投稿ブロック/過去ログ/2019/6月#6月12日に報告されている案件と強い関連性を持つ云々~、などと積極的に過去ログを頼って「新規案件として最下段に置いた方が」分かりやすいし対処しやすいだろうと思います。管理者が基本、最下段「だけ」を優先的に見る状況を維持できますから。 / そもそも、同一と思しき案件についてひとまとめに詳細情報を置くのはWP:VIP#警告中WP:AN/S辺りの「中の人が同一人物であることが強く疑われる案件を置く専用、かつその情報集約に主眼を置いている」別ページでやるべきことで、管理者の未対処タスクを「ただ、最下段に順序よく並べる」管理者伝言板の使い方を逸脱していると思いますよ。何しろ、管理者伝言板上の情報は、どんな重要性の高い情報であっても、ある程度時間が経過すると抹消除去されてしまいますから。--Nami-ja [会話 履歴] 2019年7月14日 (日) 05:38 (UTC)
コメント 感謝 @㭍月例祭: ご回答ありがとうございます。確かに管理者伝言板では管理者がわかりやすいのが一番でした。今思うと例が誤りでした。--そらたこ🐙(会話) 2019年7月13日 (土) 06:57
コメント 感謝 @皆さん:例を示してわかりやすく教えてくださりありがとうございます。規定化は色々と難しいようですね。臨機応変に対応していくしかないようです。--そらたこ🐙(会話) 2019年7月13日 (土) 07:01 (UTC)


[取り下げ](提案)即応管理者(仮称)の導入[編集]

最初に、この類の提案が過去になされていないことを私なりに確認しましたが、もしなされており、却下されていたのであればそのページを教えていただけると助かります。またされていない場合、私の提案に対する忌憚なきご意見をいただければと思います。長文ですがご容赦ください。

現在日本語Wikipediaにおいて「荒らし」を見つけた場合、取り消すのが原則になってます。
しかし、その荒らしが(こちらが)取り消してもなんども編集してくる場合、保護半保護することになるのですが、その場合、掲示板に書いて、管理者の方がその依頼に気付き、対処がなされることを待つことになります。
そして、その対処は、掲示板に書かれてから数時間程度経つことが大半です。
もちろん、管理者の方でも管理作業を定期的にする義務があるわけではないことは重々承知していますし、お忙しい中38名という少数で管理業務をされている管理者の方々には感謝しておりますが、数時間の間が空いてしまうことが多い、というのは事実です。
普通、荒らしがこちらの差し戻しを無視し、数分のスパンで荒らし返し(?)をしてくることは少ないでしょうが、そう言うケースもあります。
私が今日経験した石上ひなののページが荒らされた件では、保護依頼されてから対処されるまでの間、一時間足らずでしたが、11回の荒らし→差し戻しが繰り返されました(ちなみに対処は、当該荒らしのブロックとなり、今は収まってます)。
今回の件は管理者の方の対応が早かったこともあり、被害は限定的でした(推測ですが、余りアクセス数の多い記事じゃないのではないでしょうか)。
しかし、今後、大きな被害が出る荒らしになる可能性もあります。
例えば、悪意あるユーザーが政治家の(特に参院選期間の今)ページその政治家にとって有利/不利に虚偽の書き換えをしてしまった場合、その虚偽記載が最もらしく行われたら、Wikipediaは必ずしも(100パーセントの)信頼の置ける記事であることを知らない人や、理屈では知っていても「まさか、(嘘は)ないだろう」と考える人はその虚偽記載に騙されるかもしれません。
最悪の場合、選挙に影響することも考えられます。 まあこれは極端な例なのですが、他にも名誉毀損を含む荒らし、或いは犯行予告など、とにかく人に見せるべきではない類の荒らしもありますし、そうでなくても荒らされたページが見る人を騙し、若しくは不快にさせる可能性は大いにあります。

そうした時、その荒らしに対して、見つけた人は差し戻そうとするでしょうし、そうなれば荒らしと善意で差し戻す人の間で編集合戦のようなものが起きることになります。(荒らしが1度差し戻しただけで諦めるような人であればまだいいのですが。)その場合、善意の差し戻す人は荒らしが書き換えた回数に応じて編集(差し戻し)しなければなりませんし、かといって放置すれば(数時間のことであっても)人の目につき、先程言ったデメリット、リスクになります。
しかし、多忙な管理者さんに即時対応という負担を求めることはできませんし、管理者さんを増やすにしても厳格な要件があります。

そこで以下の提案をさせていただきます。
①「ページの一時保護権限」を作る
②その権限者は、荒らしなどで保護を求められた場合、12時間を限度にそのページを保護することができる
③管理者の方は、当該権限で一時保護されたページを見た場合、改めて正当性をチェックし、正当なものであった場合はその保護を通常の保護期間(1週間など)に延長する。
④当該権限者は、管理者が自由に任命/罷免することができる

その権限者になる要件は、④にある通り管理者に比べて緩く、人数も大幅に増やすことは可能でしょう。(勿論、作成してからの日数、編集回数に一定の規定は必要かと思います)
管理者、或いは新設された権限者にこれ以上の過度な負担をかけずとも、人数が増えれば対応も早くすることができるのではないか?という理屈です。

以上、私の提案です。ご意見をお聞かせください。--Y.iwamoto-0810会話) 2019年7月14日 (日) 12:09 (UTC)

  • コメント そのような権限はないため難しいかと思います。個別の記事に半保護をかけるためには管理者権限を持つしかなく、この権限は管理者権限では付与できません。管理者権限はビューロクラットやスチュワードにしか付与できず、解任はスチュワードしかできません。そのため今挙げられている条件で即応管理者(仮称をお借りします)をつくるのはかなり不可能に近いと思います。巻き戻しや編集フィルターで対処しきれるかと思います。
これは経験ですが、IPによる荒らしがかなりの数繰り返されている場合早い段階で管理者の方が気づかれる事がほとんどです。また、よほど大規模な荒らしであれば上にあるように臨時権限の付与で対応できると思います。(参考 利用者保護) P.S 荒らしの差し戻しは編集合戦ではありません--そらたこ🐙(会話) 2019年7月14日 (日) 15:42 (UTC)
    • まず、色々と言葉が足りませんでした。お詫び申し上げます。私の提案は、そういう権限者をシステム改変の上で導入したらどうか、という要旨です。Wikipedia:井戸端/subj/新しい利用者グループの作成のように、もし全体で合意できたらシステム改変の提案をする(このように)つもりでした。ですのでその際、管理者に任命/罷免権限を与える、という仕様にしたいと考えています。切干大根さんのおっしゃった例については存じていますが、この提案でカバーしたいと思ってるのはそのような大掛かりな荒らしではなく、小規模な(1記事程度の)荒らしです。ビューロクラット権限で他人を管理者にすることができるようですが、「〇〇に12時間を上限に保護できる権限を付与」などということは恐らくできないようですし、また管理者は一度任命するとビューロクラットでは除去できないという問題もあります。従って、ビューロクラット権限で管理者を新たに任命するのは、利用者さん達の合意、それに見合う信頼が必要になりますが、それでは前述した問題の解決策にはならない、と考えます。(そもそもその条件2つを満たし、本人が立候補して管理者になった人数が38名と、英語版の30分の1しかいない)最後にそらたこさんがおっしゃった点ですが、荒らしと善意で差し戻してる人の間で、荒らし→取り消しが繰り返されることを「編集合戦のようなもの」と例えました。私の語彙力では他に適切な言葉が出なかったもので・・・--Y.iwamoto-0810会話) 2019年7月15日 (月) 04:12 (UTC)
失礼しました。そこまでご存知の上での提案であれば話がはやいです。時間指定は無理でしょうが、保護のみ可能な利用者グループをつくることは可能かもしれません。保護のみ可能といっても保護はかなり大きな権限であり、その権限を管理者1人の裁量で付与するのは問題です。管理者と同様に信任が必要かと思います。--そらたこ🐙(会話) 2019年7月15日 (月) 05:12 (UTC)
管理者の権限の一部である保護も大きな権限であるのは確かにその通りです。しかし、私は管理者と同程度の信任が必要ではないと考えます。(そらたこさんが「管理者と同様に」とおっしゃったのはあくまで信任が必要という部分だと思うのですが)先程触れたのですが、管理者と同一の信任要件では38名しか管理者がいない、というのがこの問題提起、提案の原点です。私が「管理者が自由に任命/罷免することができる(管理者なら誰でもいつでも権限を与奪できる)」としたのはあくまで一例ですし、あるいはこの要件は緩すぎるかもしれません。他方、管理者と同様に、「3/4の信任が必要で、実質的に3ヶ月以上のログイン、500回以上の編集が求められる」というのはハードルが高すぎると思います(管理者への要件としてはそれでいいと思いますが、私の提案する即応管理者、つまり権限の限られた管理者としては高すぎる、という意味です)。重要なのは、保護ひとつ取ってもWikipedia:保護の方針に従ってある程度自分で判断しなければならない管理者と、現在進行形で荒らされてるページを取り敢えず(管理者の方が来るまで)保護する即応管理者では、やはり権限の重みは全く違うということです。①今荒らしが起きていると通報があった(掲示板に書かれた)②即応管理者が確認したら、たしかに荒らしと利用者間で荒らし・差し戻しが続いている(編集合戦のようなものが起きている)③保護!となるので、極端な言い方をすればボタン押し係となります。さらに管理者の方が問題だと感じればいつでも剥奪できるので、もし問題行動を起こしても影響は12時間に限定されます。もちろん「自動承認された利用者に限る」程度の条件は必要でしょうが、コミュニティに諮る必要のある役職か、というのは疑問です。管理者、つまりコミュニティの信任を得てる方が直接任免するので。例えば管理者3名の同意で権限を与えるというのはいかがでしょうか?--Y.iwamoto-0810会話) 2019年7月15日 (月) 09:01 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────12時間のみの保護をする権限を持つためには、保護権限(protect)をもつしかなく実質的に全ページの全保護が可能になります。そのため即応管理者は全ページの保護ができてしまう強い権限を持つことになります。また、その権限を管理者が裁量で持たせるということは権限を持たせた即応管理者の権限行使に責任を持たなくてはいけなくなります。さらに、即応管理者が行なった対処の確認を義務化されるため結果的に管理者の方の仕事量が増えると考えます。管理者はコミュニティから信頼を受けた上で、方針に従って行動するものです。信任によりある程度は裁量で行使できますが、基本的には方針の遂行が仕事です。そのことから管理者の裁量での付与には反対です。すくなくとも削除者になるための合意条件は必要でしょう。--そらたこ🐙(会話) 2019年7月15日 (月) 11:03 (UTC)

  • コメント 議論に集中して即応管理者をつくる方向に考えてしまっていました。現状管理者の方で対処しきれているので必要ないでしょう。利用者グループの作成の議論にコストをかけるより記事の質の向上を優先しましょう。--そらたこ🐙(会話) 2019年7月15日 (月) 11:09 (UTC)
つまり12時間だけの限定保護権限というのはそもそもシステム的に不可能なようですね。知りませんでした・・・取り敢えず私が考えていたような気軽な即応管理者構想は実現不可能なようなので(提案を)取り下げます。切干大根さん、そらたこさん、ありがとうございました。--Y.iwamoto-0810会話) 2019年7月15日 (月) 11:10 (UTC)

インデントの修正だけでも発言の改竄に当たるのか?[編集]

ここでブロックされたみたいですが、このIPの挿入したインデント(たぶん修正なんだろう)を巡って別の方が発言の改竄になるとあったのでこちらで「インデント修正程度であれば発言改竄には当たらない」と忠告しときました。ここで問題提起なんですが、インデントの修正程度では発言改竄には当たらないのではないかと思うんですが、これについて意見や反論を聞かせてほしいです。--だいじょうぶだぁ会話) 2019年7月14日 (日) 13:53 (UTC)

あくまで私見ですが、私は当たらないと考えます。

署名された他のユーザーのコメントを、その意味を変えるように編集すること(例えば、誰かの票を変える)は、個人攻撃の除去および空白の除去や、可読性を高めるためのインデントの修正や空白の除去・挿入などの例外を除いて、荒らしと見なされます。ただし、そのコメントが無記名であることを明示することは問題ありません。例: (fooによる無記名のコメント)

Wikipedia:荒らしから引用

ここに書かれている通り、インデントの修正は荒らし扱いの例外となっているため、この文を見るに荒らしとは呼べないのではないでしょうか?--Y.iwamoto-0810会話) 2019年7月14日 (日) 14:08 (UTC)

コメント ねんのため。内容自体には特に反論はありませんが、その方針の太字の引用部分はさきほど質問者さんが加筆されたのではないでしょうか?質問者さんご自身が加筆された内容をこの場で質問者さんにたいして引用するのは意味がないかと思います。--Aiwokusai会話) 2019年7月14日 (日) 14:24 (UTC)

コメント そのIPのブロック事由は「多重アカウントの不適切な使用: 大チャンス系」です。--柒月例祭会話) 2019年7月14日 (日) 14:15 (UTC)

コメント 人によっては削除・ブロック依頼などでもコメントアイコンテンプレートを一切使用しない方もいらっしゃいますのでその場合の付与はわざわざやらなくてもよいし余計かもしれません。しかし字下げ(というか視野性アップ?)目的のマークアップ付与は改竄や荒らしとまで言えないと思いますし、余計なお世話だと主張することはあっても改竄を指摘するテンプレートの使用はやりすぎではないかとも思います。それとブロック理由は大チャンス系でしょう。--Aiwokusai会話) 2019年7月14日 (日) 14:20 (UTC)

  • Y.iwamoto-0810 さんが「Wikipedia:荒らし」から引用した「および空白の除去や、可読性を高めるためのインデントの修正や空白の除去・挿入などの例外」というのはだいじょうぶだぁ さんが直前に追加した部分ですね‥‥‥。とはいえ、それだけで改竄とするのはどうかと思います。 By 健ちゃん会話) 2019年7月14日 (日) 14:30 (UTC)
返信 「だいじょうぶだぁ さんが直前に追加した」-これは気がつきませんでした。Wikipedia:荒らし方針文書であり、「変更はコミュニティーの合意を反映している必要があります」。
それほど無茶苦茶な修正ではないようには思いますが、事前の合意形成を欠いているようなので、いったん差し戻しました。必要であれば合意形成をお願いします。--柒月例祭会話) 2019年7月14日 (日) 14:36 (UTC)
    • ほんとだ・・・気付きませんでした。合意形成なく編集したのはどうかと思いますが、それは置いといて、健ちゃんさんのおっしゃる通り善意で行われたマーク一つの訂正は改ざんにならないでしょうし、仮になったとしてもそれがブロックの対象という警告は行き過ぎだと私は考えます。もちろん当該利用者がそれとは別の理由でブロックされたのならそれはそれで正当でしょうが、その前に行われた警告の内容についてはいかがなものかと・・・--Y.iwamoto-0810会話) 2019年7月14日 (日) 14:40 (UTC)

コメント 一般論としては、他の方々もおっしゃっているように、軽微なインデントの修正を以て「荒らしだ」「ブロックだ」と即断することは無さそうです。ただし荒らしとかブロックだとかには、状況や程度というものも関わります。

ノートページなどで協力的に議論を重ねているときに、当事者が相手方のインデントをいくらか修正したところで、それを荒らしとみることはないでしょう。一方、対立してヒートアップしているときには、相手方の些細な言動を取り上げて「荒らしだ!」と批難合戦に陥ることはままあります。

削除依頼など、投票やコメントに資格が設けられている場面に、関係のないIPが急に出てきて、あまり意味のない修正をし始めたら、たいていは訝しがるのではないでしょうか。何か後ろ暗いところのある(「ウィキペディアの方針に沿っていないことを自覚している」Wikipedia:説明責任)利用者が、IPで何か始めたのではないか、と怪しんだとしてもそう不思議ではないでしょう。同じことを十分に信用がある利用者が行えば、誰も変だとは思わないでしょう。それがWikipedia:説明責任の結果というものです。

件のIPの場合には、(私にはわかりませんが)おそらく何かしら怪しい部分があって目をつけられブロック破りと看過されたのでしょう。仮定ですが、削除依頼にちょっかい出すのが特徴のブロック破り、みたいな場合もあるのかもしれません・・・詳しくはわかりませんけれど。説明責任を欠く利用者に対して、なにか怪しいぞとブロック破りの疑いを抱いたときにすぐに「ブロック破りだろ」と言うと、まだ十分に説得力のある根拠が積み重なっていない時点では逆に自分が批難されてしまう的なところもあり、まずは外堀から・・・というのはあります。そういう色々な文脈のなかにおいたときに総合的にみてどうかな、ということで「荒らし」とか「ブロック」とか判断していくことになるかと思います。

だいじょうぶだぁさんによるWikipedia:荒らしの修正は、一見さほど変ではないと思います。が、もしも依頼系投票系のページで他利用者のインデントの修正をしまくるような利用者が現れれば、ちょっと待てとなるでしょう。そのときに「これはWikipedia:荒らしで例外と認められてるからいくらやっても批難されるいわれはない」などと開き直られても困りますよね・・・。そこらへん、方針文書のような根幹文書で、あまり具体的に例を絞るのは止しとこう、みたいな考えもあります。--柒月例祭会話) 2019年7月14日 (日) 15:43 (UTC)

コンテンツ翻訳ツールにおける日本語への機械翻訳をツール側で禁止する提案[編集]

Wikipedia:井戸端/subj/翻訳ツール(ベータ)を用いた編集の増加と、機械翻訳の取り扱いWikipedia:井戸端/subj/コンテンツ翻訳ツールの是非などで度々話題となっている通り、現在広く使われているコンテンツ翻訳ツールでは機械翻訳をそのまま投稿することが可能となっています。Wikipedia‐ノート:削除の方針/2019年#ケース_Gの改訂提案-201901の改訂である程度対処できるようになりましたが、見つけ次第削除するという事後策のため、機械翻訳をそのまま投稿するケースは後を絶えません。つきまして、根本的な解決策として、コンテンツ翻訳ツール側で日本語への機械翻訳を禁止するようPhabricatorにて提起すべきか、ウィキペディア日本語版のコミュニティで合意を形成したいと思います。

提案[編集]

  • 合意が形成された場合、Phabricatorでタスクを作成し、主な論点を英語に翻訳して記載します。
  • 具体的な実装としては、コンテンツ翻訳ツールで日本語への翻訳を行うとき、「Google Translate を使用」「Yandex.Translate を使用」「LingoCloud を使用」「Youdao を使用」を選べなくなるようにします。追記--ネイ会話) 2019年7月17日 (水) 03:45 (UTC)
  • 2019年4月にインドネシア語版での合意に基づきphab:T219851が提出されましたが、ウィキメディア財団の方からの反論があり、最終的には「3割以上の内容が機械翻訳そのままの場合、投稿を禁止する」ことが実装されました(既定では8割以上で警告、99%以上で禁止)。そのため、日本語版での合意があっても実装されるとは限りません。財団の方からの反論への返答について、予めここに記しておきます。
    • Category:未査読の翻訳があるページというカテゴリがあるため、コンテンツ翻訳で作成されたページの追跡はできる - インドネシア語版と同じ状況ですが、そもそも人手不足なので、これ以上コミュニティへの負担を増やすべきではありません。現時点で当該カテゴリには800件以上のページがあり、追跡としての機能が果たされていないことが明らかとなっています。
    • 特別:ContentTranslationStatsで示されている通り、多くの記事がコンテンツ翻訳ツールを通じて日本語版に投稿されている。そのうち削除されたものの少なさからして、機械翻訳問題はそれほど深刻ではない - 上記で示されている通り、日本語版では人手不足でチェックがそれほど行き届いておらず、全ての機械翻訳そのままの投稿が削除済みというわけではありません。
    • 現在のところ、コンテンツ翻訳ツールでは8割以上が機械翻訳そのままの場合、投稿する前に警告メッセージを表示させており、99%以上の場合は投稿が禁止される - 日本語への機械翻訳ではGoogle翻訳でもYandex翻訳でも本文ほぼ全てを手直しする必要があるため、インドネシア語版で実装された「3割以上で投稿を禁止する」では不十分です。
    • 見出しの翻訳などごく短い文では正しく機能することが多いので、「8割そのまま」で投稿を禁止するという基準を低くしすぎた場合、そのように使うこともできなくなる - 見出しを翻訳するだけならば、機械翻訳を使う利便性はかなり少ないのでは?また、日本語への翻訳ではごく短い文でも正しく機能しないことが多い。
    • どこまで編集すれば、「機械翻訳そのまま、または軽く手直ししただけの文」にならなくなるか - 一から書き直さなければならないほどであり、そのように編集することはほかにも問題があります。利用者の私論ですが、利用者:McYata/コンテンツ翻訳についてにて例示があります。
  • 英語版のen:Wikipedia:Content translation toolによると、英語版への機械翻訳は2016年7月に停止されています。また、英語版への投稿は英語版の「拡張承認された利用者」に限定されています。追記--ネイ会話) 2019年7月16日 (火) 10:30 (UTC)

コメント[編集]

  • コメント 現在のところ、2週間後の提出を目処としています。なお、コンテンツ翻訳ツールを完全に無効化するという提案ではなく、提案通りに実装されたとしても編集ツールとしての機能は残す予定となっております。--ネイ会話) 2019年7月16日 (火) 05:38 (UTC)
  •  質問 機械翻訳投稿の実態には詳しくない、というよりは殆ど無知に近いのですが。禁止した所で、直接Google翻訳等にコピペして翻訳し、機械翻訳という事を隠して投稿されるだけなのでは無いでしょうか? その機能を未使用の僕が言うのもアレなのですけども、意味が有るのか疑問です。--お好みでタピオカをおかけください会話) 2019年7月16日 (火) 06:45 (UTC)
    • コメント コンテンツ翻訳ツールが利用できるようになった以降に機械翻訳そのままの投稿が増えたように見えます(詳しい統計データがあるわけではありませんが)ので、機械翻訳を使えなくすることは一定の効果があるだろうと予想しています。--ネイ会話) 2019年7月16日 (火) 08:18 (UTC)
  • 賛成 ご提案に賛成いたします。コンテンツ翻訳のツールを使った投稿はかなり見かけますが、見つけて対処するだけで大変な労力ですし、日本語への機械翻訳はほぼ全て意味不明・不正確になる状態なので、使えないようにするだけでいくぶんか効果があると思います。--さえぼー会話) 2019年7月16日 (火) 09:21 (UTC)
  • 賛成 私は機械によって自動翻訳されたものがどんなのか、(Wikipedia歴が浅いのもあって)知らず、この井戸端にあったリンクで調べてみたのですが、これはひどい・・・。McYataさんがこの翻訳例を調べて書いてくださったのが半年前とのことで、この半年の間に多少進歩があったとしても、使える域に達しているとは思えませんし、増してネイティブな日本人のチェックなしに機械任せにまでできる域に達してるとはとても思えません。禁止に賛成します。とはいえ、将来的に質が上がる可能性はありますよね?(McYataさんがおっしゃってた通り、翻訳の精度は日々向上します。Google翻訳は今はある程度使える水準にありますが、昔はひどいもんでした)その場合はネイティブ日本人(きちんと自然な日本語を操れる方なら外国人でも構わないのですが)がチェックをした上で機械翻訳に委ねるというのは考えられると思います。とはいえそれまでには年単位でかかるでしょうし、そう考えるととりあえず禁止にすべきであると考えます。ので賛成。--Y.iwamoto-0810会話) 2019年7月16日 (火) 10:16 (UTC)
    • ちなみに質問なのですが、今機械翻訳任せにすることを禁止する(最低限人間のチェック)方針やガイドラインはあるのでしょうか?先ほどのリンクは「私論」という形でしたが・・・--Y.iwamoto-0810会話) 2019年7月16日 (火) 10:18 (UTC)
      • Wikipedia:翻訳のガイドライン#機械翻訳にてそのような文言があり、またWikipedia:削除の方針#ケース G: 他言語・翻訳についての問題がある場合でも似たような文言があります。--ネイ会話) 2019年7月16日 (火) 14:46 (UTC)
        • ありがとうございます。しかし、翻訳のガイドラインはあくまでガイドラインですし、削除の方針は削除されるたくさんあるケースのうち一つに過ぎません。(知らない人もいるでしょう)この提案の議論は引き続きするとして、並行して方針で「機械翻訳をそのまま使わない」と言うようなものを(方針の一項目ではなく、方針そのものとして)置いたらどうでしょうか?(方針の改定手続きは詳しくは知りませんが、コミュニティの同意でできるんでしたよね)いっそのこと機械翻訳そのものを方針で禁止するとか・・・方針の改定はこちらで決めれることですし。いずれにせよ財団の返事を待たないといけない翻訳の禁止よりは早くできるでしょう。最もそもそも機械翻訳の内容に違和感を覚えない人間が方針が読めるのかと言うのは若干微妙ではありますが、やらないよりはましかと思います。楽観視しすぎでしょうけど、それで機械翻訳の問題が減ったら儲けもんですし、その方針を置いたから増えると言うことはないでしょう。--Y.iwamoto-0810会話) 2019年7月18日 (木) 10:07 (UTC)
          • 今気づいたんですが、ガイドライン含めて聞いといて「あくまでガイドライン」って失礼でしたね。すみません。要点は、方針、ガイドラインの一項目である機械翻訳に関する記述やコミュニティの考え方を方針そのものとして(格上げ?)分かりやすくする、と言うことです。--Y.iwamoto-0810会話) 2019年7月18日 (木) 10:29 (UTC)
  • 保留 ネイさん提案の背景・目的には大いに共感しますが、手段をもう少し煮詰めてもいいのかなと感じました。翻訳ツールによって低質な記事が濫造されている現状は嘆かわしい一方で、一部ユーザはツールをうまく活用して、高品質で効率的な記事執筆に役立てています。つまりツールの問題というより、個々のユーザのスキルや意識の問題だと思います。そこで、以下の2案を代替として考えられないでしょうか?
  • 代替案 (A): 原則はツール使用NGとするが、使用したい優良ユーザがいれば、審査の上で許可する。「Wikipedia:Bot/使用申請」や「Wikipedia:権限申請/アカウント作成者」のイメージに近いです。
  • 代替案 (B): 原則はツール使用OKとするが、粗悪な翻訳記事を繰り返し濫造する問題ユーザがいれば、ツール使用禁止令を出す。ある意味部分ブロックの翻訳版みたいなイメージです。
さらにこれを実現するにあたり、管理者さんの作業負荷をなるべく減らすために、2つほど前提となる環境整備もあわせて提示させて頂きます。
  • 前提 (1): 「プロジェクト:翻訳」みたいなものを立ち上げ、翻訳執筆に長けた方々でなるべく自律的に運営できるとベターかなと思いました (既に存在していたらすみません)。このようなバーチャル組織があれば、上述の (A) 案を採用した場合の審査事務を担えますし、直接Google翻訳等にコピペする抜け穴ユーザへの対応や、ツール類は一切使っていないけれど低質な翻訳記事を作ってしまう方へのアドバイスなど、より広く対処できると思います。
  • 前提 (2): 英語版にあるen: Wikipedia:Drafts (標準名前空間からドラフト空間への移動) を導入してはいかがでしょうか? 「低質な翻訳記事を表に出すのは嫌だけど、さりとて記事の主題そのものは重要なので削除依頼はできれば出したくない」というケースに対応できます。加えて、こちらが一発削除するよりも、ドラフトに戻して本人に直させる方が、今後は濫造をやめようと感じて抑止効果につながるかもしれません。
ぽっと思いつきで提示した案なので、詰めが甘いかもしれません。皆さまのご意見お聞かせ下さい。--ProfessorPine会話) 2019年7月16日 (火) 13:15 (UTC)
コメント 翻訳ツール自体の廃止は提案しておらず、「翻訳ツールの機械翻訳機能」のみの廃止を提案しています。上記の利用者の私論でも示されている通り、現時点の日本語への機械翻訳には活用できる場合が全くないため、一部利用者が翻訳ツールを活用しているとはいっても、機械翻訳機能を活用しているとは考えられません。機械翻訳なしにツール自体をエディターとして使用するだけならば、現時点では特に審査などが必要であるとは考えていません。プロジェクト立ち上げやドラフト名前空間の導入などは現時点で意見はなく、本提案とは別に議論を提起してもいいと思います。--ネイ会話) 2019年7月16日 (火) 14:31 (UTC)
コメント 「一部ユーザはツールをうまく活用して、高品質で効率的な記事執筆に役立てています」となる可能性は、機械翻訳に限れば無視してよい程度でしかありません。また、高品質を生み出せるような僅かな利用者のために大多数に損害を与えることは許容されません。高品質な記事の存在は、数百倍の粗雑な記事をなかったことにできないのです。つまり代替案Aについては、許可制にするよりは単純に翻訳部分だけを停止した方が現実的でしょう。これでも対訳ツールとしてなら使えますので。代替案Bは問題を起こすアカウントの主力は他言語版の利用者と新規アカウントですから塞いだところで追いつきませんし、逐一個別対応を行うことでは網をかけて対処する提案の代替とすることはできません。これは現在の放置よりはましという程度の効力しかなく、負担は多大なものになります。オプション的に付け加えるならまだ使えますが、これをもって代替とすることは無理でしょう。環境整備ですが、プロジェクトについては個々にそのような対応を行う利用者は少なからずおり、それでも対処しきれないからこその現状です。つまり既に自律的に活動は行われており、残念ながらそれで対処の代替・補完とするのは非現実的です。加えて、日本語版のプロジェクトは管理権限を担うことはありませんから、審査事務をプロジェクトに委ねる可能性は無いでしょう。Draft案は私も考えたのですが、移動権限がネックで扱いきれないかなと。Draftは、コンテンツ翻訳を強制的に放り込むなら意味はあると思いますが、任意なら無意味になります。当初より品質に疑問を持つような利用者なら、そもそも現在でも問題を起こさないでしょうし、問題利用者が任意でDraft化する可能性に期待することはできません。またDraftは必ずしも本人に直させるものではありませんし(それは利用者ページに置く下書きの役目です)、標準からDraftへの移動を認めている英語版の運用は、運用上移動者に根拠のない承認権限を与えるに等しいという重大な問題があります。まして目の行き届かない日本語版では悪用の危険性が高いです。日本語版で導入するなら、Draft関係の移動を特殊な権限として扱えなければ運用できないでしょう。英語版もまた問題が多く人数も違うので、そのまま導入すれば良くなるというものでもないのです。--Open-box会話) 2019年7月16日 (火) 16:54 (UTC)
「数百倍」というのは何処から出てきた数字でしょうか? 単に、非常に多い気がする、ということを仰りたかったのでしょうか? それとも「仮に数百倍になったとすれば」という意味で仰ったのでしょうか? --2001:240:2404:4E48:84C6:5BEA:DBCE:3CA6 2019年7月17日 (水) 03:21 (UTC)
実感優先ではありますが、今のところ「コンテンツ翻訳の機械翻訳により作成された優秀な記事」はありません。なので数百倍でも甘い評価をしているんです。これは比較的大規模な一覧系でなら機械翻訳が有効に働く可能性がある事は見通せるからですが、結局手直しが大規模に必要であることと、機械翻訳の利用にコンテンツ翻訳を経由する必要がないという単純な事実から、「コンテンツ翻訳の機械翻訳」はかなり分が悪いです。--Open-box会話) 2019年7月17日 (水) 12:48 (UTC)
  • 賛成 現状は深刻であり、対処の余裕を確保するためにも応急処置は必要と考えます。現状ははっきり言ってしまえば確認すらままならない状況であり、「機械翻訳」だけではなく「コンテンツ翻訳」機能を停止してもらってCategory:未査読の翻訳があるページではなく、「タグ:コンテンツ翻訳」の総チェックが必要です(特別:タグ一覧によればこれを書いている時点で7785回)。その結果はほぼ確実に「機械翻訳」の「停止」になると思われます。--Open-box会話) 2019年7月16日 (火) 16:54 (UTC)
    • (追記)YoudaoとLingoCloudが提案から抜けています。これらも日本語対応です。--Open-box会話) 2019年7月17日 (水) 00:37 (UTC)
      • YoudaoとLingoCloudを提案に追加しました。機械翻訳さえ停止すればあとは普通の翻訳と同じ状態になりますので、コンテンツ翻訳を完全停止する必要はないかと思います。--ネイ会話) 2019年7月17日 (水) 03:47 (UTC)
        • コンテンツ翻訳の一時停止は別の問題です。下で㭍月例祭さんが提案しているような検証作業中にノイズを入れないためなので。--Open-box会話) 2019年7月17日 (水) 12:48 (UTC)
  • コメント ツールを使ってから3回の問題のない公開と2週間~1ヶ月の経過で、オプションとして機械翻訳の選択肢が選べるような仕様とかができればいいのですが。それなら機械翻訳を最初は選択できないようにする提案には賛成です。--Afaz会話) 2019年7月16日 (火) 23:33 (UTC)
    • コメント 今回の提案でそれは確実にセキュリティホールになります。まず提案の中身を考えますと、最初は選択できないとしておきながらオプションとすることは一見可能ですが、現在でも問題のある機械翻訳の処理に数ヶ月を要しますので、投下直後に発覚する状況でもなければクリアできてしまいます。しかもその状況を作り出す運用はツールを使って骨組みを作ってから機械翻訳を貼り付けるだけで行えます。つまり、「公開と経過」は資格を与えるふるいとしては機能しないのです。それ以上に深刻なのは、あなたの提案を読んだ財団は「機械翻訳を受け入れようとしている人もいる」とつけ込み、現状維持の口実にできることです。何とかして使えないかという善意は通常であればとても良いことなのですが、このような場では相手に武器を与えることになります。実地における評価段階を経ず、実装をしてしまう不注意な運用を行う相手であることを、そして押しつける手段として拒否を繰り返すという方法を採った前科がある相手であることを考慮しなければなりません。インドネシア語版ではいつまでも納得しない財団を相手に妥協案(30%)を提出した管理者がいたために、結局財団は30%を押しつけることに成功しました。そしてその結果は、機械翻訳を続けようとしている人からの不満と、すりぬけた機械翻訳に対する不満であり、財団は後者を無視し前者の緩和を試みるほどです。拒否を繰り返すことで根負けを誘発すれば、妥協案を持ち出す者がいるので勝てる、妥協案が出たらもう耳を貸さないという前例がある以上これを踏襲し、財団は最低でも30%を押しつけようとするでしょうし、受け入れたら不具合が生じても無視するでしょう。日本語版はインドネシア語版の二の舞は避けなければならないのです。--Open-box会話) 2019年7月17日 (水) 00:37 (UTC)
返信 セキュリティホール?機械翻訳は別に問題ないですよ。ただ「日本語として可読な状態にしようとしない行為」だけが問題なだけで。包丁が悪いのではなく、包丁を振り回す行為が悪い。あなたが言うような悪意をもった運用者は、今までどおりブロックすればいいだけの話です。--Afaz会話) 2019年7月17日 (水) 03:05 (UTC)
包丁の例えは、道具だから悪くないという価値観を利用して、道具には問題が無いという前提をすり込ませている典型的な詭弁です。しかもこの問題は「機械翻訳が悪いと理解できない」利用者以前に、問題だらけの機械翻訳を手軽に乱用できるツールが悪いと判っているのですから、不適切です。包丁の例えが詭弁であることを免れるのは、道具側に問題が無いときなのです。加えて「日本語として可読な状態にしようとしない行為」であるという認識を持っているかは、疑問です。機械翻訳がある=当然通用する翻訳になる程度に考えていても不思議ではないのですから、悪意があって荒らしているという前提すら必ずしも成り立ちません。そして、残念ながらブロックは有効ではありません。ブロックは事後の手当に過ぎませんし、ブロックされるほどの粘着性を発揮する機械翻訳常習者は僅かで、実際には単発です。僅かな常習者を後からブロックしても効果は薄いのです。--Open-box会話) 2019年7月17日 (水) 12:48 (UTC)
ツールを利用した「善意だが能力の低い利用者」を排除したいのは分かりますが、ただ、機械翻訳がデフォルトのツールの現状に賛成しているわけではないので。英語版は導入予定ではなかったのにミスで機械翻訳が有効になっていたということらしいので、停止されましたが、インドネシア語版の場合はコミュニティの全会一致の意見ということを言っても停止していません。ギズモードの記事によるとこのツールはgoogleが協力して作ったものらしいので機械翻訳はセットなのかもしれません。--Afaz会話) 2019年7月17日 (水) 23:55 (UTC)
この提案の結果、ちゃんと使える人には変わりがないはずなんです。「機械翻訳がデフォルト」ではなく「機械翻訳とリンク確認は自分でやってきてね」というツールに変わるだけなので。Gizmodeの記事は、今年に入ってから追加されたGoogle機械翻訳の追加についてです。(英語版に機械翻訳が実装されないのは不自然ですが)Googleとの絡みで停止できないなら、財団側がそう言ってしまえば済むんですけどね。もっともあの記事は日本語版が無いApertiumを使っていることにした直後に日本語が無いことを書くように、よくわかってない人が書いた気配があります。--Open-box会話) 2019年7月18日 (木) 09:07 (UTC)
    • 「3回の問題のない公開と2週間から1か月の経過」が技術上実装できるか、というか日本語版だけのためにそれを実装してくれるかが不明である、と申し上げておきます。一方で機械翻訳の完全禁止は英語版ですでに実施されているため、実装に必要な時間がそれより少ないのは明らかです。日本語への機械翻訳は上のほうでも述べている通り、現時点では全くと言っていいほど役に立たないため、わざわざ実装の手間が多い提案を選ぶことに相応の利点があるとは思えません。「拡張承認された利用者」のグループがあれば実装がより簡単になりますが、本提案で想定されるであろうタイムラインより長い時間をかけて議論する必要があると考えますので、機械翻訳の抑止を早急に行うという意味では今回は見送りにするしかありません。--ネイ会話) 2019年7月17日 (水) 03:40 (UTC)
  • コメント 方向性というか考え方は共感できるのですが、いろいろなお話を読むと「2週間後に」という見通しはむつかしいのではないかなと思いました。
  • 「財団を説得する」という過程があることを思うと、私だったらたとえばこんな感じのロードマップを考えます。
  • (1)コンテンツ翻訳ツールにより投稿された記事のうちランダムにX件(少なすぎず、適度に多くて、現実的に多すぎない)を抽出
  • (2)そのうち日本語に問題がある記事の数をカウント(問題を、「文法の問題 大中小(致命的←→変だが理解できる)」「用語の問題 大中小」みたいに類型化して数をだしておくのもよい)
  • (3)削除を検討した数・実際に削除になった数(割合)をカウント
  • (4)この数字を交渉の根拠にする。
  • (5)財団にはコンテンツ翻訳ツールの全面廃止を求める
  • (6)最終的に譲歩と妥協により機能の一部制限をとりつける?
  • 申し立て文書を完全に日本語で書き、それを機械翻訳で英語にして、それをそのまま送る。(半分冗談)
  • 56あたりはともかく、2や3あたりは根拠として持っといたほうが説得力がある。その数字を出すには少なくない手間と時間を要します・・・でも機械翻訳を放置しておくよりは、将来的な手間は少ないはず。。。
  • 実際に1-3をやるには、もう「検証委員会」みたいのをつくるところからでしょうか・・・。--柒月例祭会話) 2019年7月17日 (水) 09:59 (UTC)
恐らく、(1)と(2)が難しいです。抽出できるのはいいのですが、サンプリングをどうするか(母数考えると100ぐらい?)。また、(2)を考えるとコンテンツ翻訳を単純に対訳ツールとして使ったケースや事後に再訳・修正したケースを「問題なし」としてカウントしても意味がありません。なのでこの段階で機械翻訳に限定する方がいいです。ついでにそれができるならチェックを容易にするようにできないかなと。数千のページにタグが付いていても、それを辿る手段がないのでは困りますから。(2)は、(1)=機械翻訳ではないので、ここは機械翻訳で限定をかけた方がいいです。(5)の廃止は無理でしょうから、狙いは停止ですね。機械翻訳だけでも止まれば何とかなるのかは、機械翻訳を止めなければ判りませんが、止めてもなお手作業による機械翻訳が相次げば止める材料にはなるでしょう。(6)はあまりよい策ではないと思います。譲歩や妥協前提は突破口にされるだけです。提案者のネイさんは英語版で停止できたのだからと考えていますが、私は逆に停止した前例がありながらインドネシア語版に対して抵抗を続けて30%を引き出した結果から、有利な前例を主張するのは予想できるのです。--Open-box会話) 2019年7月17日 (水) 12:48 (UTC)--切り貼りミスのdel化--Open-box会話) 2019年7月17日 (水) 12:51 (UTC)
  • コメント コンテンツ翻訳ツールの話ではないのですが、他言語版の記事を読むときにGOOGLE翻訳をよく使うので、その時の経験から感じたことを書きます。韓国語版(あるいは朝鮮語版)については、そもそもハングルが読めないので、GOOGLE翻訳に頼らざるを得ません。それでGOOGLE翻訳で読むと、たまに「これは訳語が間違っているな」ということがあるものの、文脈・文法などはほぼ自然な日本語と呼べるものになっています。訳語に「?」がつく箇所だけを別途オンラインの辞書で調べて埋めればOKというところです。一方英語の場合文脈・文法がおかしいと思う場合が大部分です。そこで、GOOGLE翻訳はあくまで辞書代わりと心得て、原文と日本語訳を並べて読むことになります。ドイツ語、フランス語などは日本語に翻訳すると英語同様の状態なのですが、英語に翻訳すると私の英語力程度では文脈・文法の間違いが気にならないので、ざっと読む段には問題ないなと感じています。以上のような経験があるので、韓国語版(あるいは朝鮮語版)からの翻訳については機械翻訳でもそれほどひどいものになならないと思います。翻訳ツールの実験は大変そうですが、GOOGLE翻訳の実験なら簡単にできるので一度お試しください。--2001:268:C02C:6A6F:101:C596:CCB7:F2DB 2019年7月17日 (水) 14:05 (UTC)
  • コメント(追加)韓国語版(あるいは朝鮮語版)からの翻訳で?になるのは、漢字を音写したと思われる言葉です。元々韓国語(あるいは朝鮮語)には漢字から音写した言葉が多いらしい(例えば「대한민국(大韓民国)」はすべて音写です)のですが、母音・子音の種類が多いこともあって、日本語に比べると同音異語というのははるかに少ないようです。ハングルだけの文章が見事に漢字かな交じり文に翻訳されるのを見るとちょっと驚きます。--2001:268:C02C:6A6F:101:C596:CCB7:F2DB 2019年7月17日 (水) 14:13 (UTC)
それはハングルの同音異義語が多い表音文字という特徴によるものですね。日本語と文法が近いとされることもあって「定型的」な文章はそこそこ読めるのですが、問題はその定形外で発生します。ハングルに限らず定型で行ける記事って薄いというか、割と辞書片手でも何とかなるんですけど、それでも変ところは発生します。それでも近縁の言語かつ定型なら不気味の谷を覗くところまでは来ているかもしれません。なので自己責任で機械翻訳を使うなって話にはなってないんです。ついでに他の機械翻訳と比べると判りますけど、Googleは日韓に限らずアジア系についてはまだまだというか、アジア系はやっぱり餅は餅屋的なところはあります。--Open-box会話) 2019年7月18日 (木) 09:07 (UTC)

コメント(区切り1)[編集]

  • 報告 コンテンツ翻訳ツールの中身を見たことがない方もいると思うので、画面キャプチャして機能説明しました。こちらの画像もご参照下さい。--ProfessorPine会話) 2019年7月18日 (木) 03:39 (UTC)
  • 機械翻訳機能 (ドロップダウン選択) を無効にすると、日本語版Wikipediaの内部リンク自動挿入機能も奪われるデメリットがあります。たぶんこの内部リンク自動挿入は重宝している人もいるはず。
  • 文全体の品質はダメだけど、単語ベースで訳の候補を活用している人もいるはず。
  • なお、実際にツールを活用しているユーザさんに、どのように使用して効率性を上げているのか、現状ヒアリング中です。
  • コメント 私も@㭍月例祭さんの「財団を説得する」という観点は大変重要だと考えます。また、@Afazさんの「包丁が悪いのではなく、包丁を振り回す行為が悪い」ご発言も賛同です。「mw: Content_translation/V2/ja#新バージョンを試用する」をご覧頂ければ分かりますが、基本はツールを利用してもらってバグを出して改善していこう!という路線です。したがって、ネイさんの提案では「改善さえもいらねーよ」と財団や開発者に伝えることになり、交渉戦術としては正直難しいと思います。私が (A) 案を提示した背景には、「一部優良ユーザは使い続けることができるので、ツール改善に役立てられますよ」とexcuse (交渉の材料) として使えると思ったからです。もちろん、実際にツールを利用している優良ユーザが私の活動領域に実在するから、その方々からツールの機能を奪うのは適切ではないとも考えています。また、㭍月例祭さんの「検証委員会」が私が提案したプロジェクト:翻訳と近しいです。暫定組織か常設組織かの違いですが。あと、Afazさんの「ツールを使ってから3回の問題のない公開と2週間~1ヶ月の経過で、オプションとして機械翻訳の選択肢が選べる」という案ですが、これも私の (A) 案と路線は近いです。形式基準をクリアしたら自動承認にするか、より厳しい審査制にするかの違いはありますが。--ProfessorPine会話) 2019年7月18日 (木) 03:39 (UTC) --リンク不備修正: ProfessorPine会話) 2019年7月18日 (木) 03:45 (UTC)
「日本語版Wikipediaの内部リンク自動挿入機能も奪われるデメリット」自力で確認すれば済むことであって、機械翻訳有効化とのトレードオフにできるメリットではありません。また、不適切なリンクは見逃されるでしょう。
「単語ベースで訳の候補を活用している人もいるはず」それは機械翻訳を組み込む理由にはなりません。むしろその用途であれば、ツール外である方が楽です。 
「改善さえもいらねーよ」悪質な印象操作です。そもそもコンテンツ翻訳ツールそれ自体には機械翻訳の機能がなく、外部から提供されている物を使用しているのは、容易に知ることのできる事実です。「機械翻訳の提供者」は、APIを通じてデータを得て「機械翻訳の改善」に繋げることになっていますが、それすらコンテンツ翻訳ツールで行う必要はありません。「ツールを利用してもらってバグを出して改善していこう」にも通じますが、機械翻訳無効化とコンテンツ翻訳ツールの改善とは別なのです。そもそもツールの無効化ではなく、既存の機能である「機械翻訳無効化」の要望なのですから、ツール改善に貢献しないという前提が既に無理があります。
詰まるところ、使いたいんだから特権を与えろって主張をしていることは理解していますか? みんな犠牲になれって現状は論外ですが、特権を与えるには相応の体制が必要です。特権を与えるのは権限申請になりますので(拡張半保護程度ですと、条件を満たすのは容易なので申請する権限になるでしょう)、『「検証委員会」が私が提案したプロジェクト:翻訳と近しいです』とする時点でずれています。㭍月例祭さんの提案は、現状で問題がどの程度あるかを洗い出して検討材料にする考えであって、翻訳支援((3)の存在により削除依頼に回付されることに注意)や設置不可能な審査機関のことではありません。この違いは暫定組織か常設組織かの違いで済む範囲ではないのです。さらに困ったことに優良ユーザーと判定できるだけ使いこなすなら、機械翻訳は要らないんです。そしてこれが意外に重要なんですが、スイッチを日本語版が握れるかって問題があります。新規開発になることもあり、ローカルに個別のユーザーに対して機械翻訳有効化/無効化機能を解放するって機能を付けてくれるように説得するのは難しく、実装はさらに時間を要すると予想しています。
原案は「ツール外での機械翻訳」まで禁止したり、恒久的に「ツールそのものを止める」提案ではないので、代案としてもローリターンかつ時間がかかりすぎます。しかもこの提案をもってしても、結局大多数は止めなきゃならないのです。--Open-box会話) 2019年7月18日 (木) 09:07 (UTC)
  • コメント 私はあくまで皆さんの解説を読んで、間接的にしか状況(財団がどうの)を理解していません。だからおかしなことを言ってたらごめんなさい。
  • Open-boxさんがおっしゃってくださったとおり、私の意図は「いかに機械翻訳に問題があるかを示す」ところにあり、「問題の多さ」を数とか量とかで数値化する作業に過ぎません。「問題がすごい多いです」よりは「108件の問題がある」のほうが具体的で説得力があるからです。そしてその作業をする目的は、ネイさんの当初提案である機械翻訳の禁止を実現しやすくすることです。(無数に生まれてくる機械翻訳記事をなおしていこうぜ、ではなく、説得材料が一定数揃えば終了です。)
  • 前のコメントよりもちょっと手の届く、省コストで現実的なことを考えてみました。1件の記事を機械翻訳してどれだけ問題が生じるかを数える、というのはどうかな。たとえば「そもそも日本語の文章として意味が取れない」から「専門用語・術語・定訳の選択に誤りがある」まで、数種類に類型化して、数える。それには、その記事を人力翻訳できる人のマンパワーが必要です。(記事の選択とかで偏りが生じることはめをつぶる。)
  • ここの議論には私も存じ上げている方がチラホラいらっしゃるので・・・たとえば、さえぼーさんがイギリス文学に関する記事を1つ、ネイさんが歴史記事を1つ、私が競走馬の記事を1つ、みたいに人力翻訳を行って、機械翻訳と比較し、問題点をカウントするとかね。翻訳前の記事の大きさを「10000バイト程度」とか揃えておけば、「10000バイトにつき平均○件の致命的なエラーがある」みたいにできる。とかね。
  • ネイさんの思いとは違うかもしれないのですが、手順として「機械翻訳を制限すべきだ」という基本的で巨大な合意をまずつくる。「制限すべきだ/一切制限すべきでない」で調査投票するとかね。そのうえで「どのぐらい制限すべきだ」についても簡便な投票を行う。(100%不可、記事の50%までは機械翻訳を可とする、25%、から択一、とか。)管理者の信任などでは30とか50ぐらいの票が集まるわけですから、できれば少なくともそのぐらいのまとまった人数による大きな合意をつくって、それを示す・・・とか・・・--柒月例祭会話) 2019年7月19日 (金) 13:08 (UTC)
  • ためしにやってみた。自分の守備範囲で辞書無しで翻訳できるような記事で、人力で90分、機械で15分といったところ。で、「正答率」は文の数ベースで2/34(6%)、原文のバイトベースで122/8903(1%)てとこですね。「日本語として意味が取れない」モノが文ベースで6割あって、それだけでも十分アカンのですが、一見文章になっているようだが本来の意味と逆になっている(馬が騎手に乗っていたり、父と子が入れ替わっていたり、生まれたと死んだが逆だったり。)のが25%ぐらいある。--柒月例祭会話) 2019年7月20日 (土) 03:48 (UTC)
  • 私もやってみました。割と定型が多い航空記事2本です。節名称含めて50件ぐらいで、正解と言えるのは2つ(しかも一方は節)、よみにくいけど放置レベルまで含めても10から12ぐらいでしょうか。こちらは用語間違いで意味がまるで違うのに機械的に文章が読めてしまうパターンが頻出しまして、使い物になりそうにありません。これらは多分「日本語として意味が取れない」モノになると思われます。不時着が撤退だったり、事故が殺人だったり、コクピットに20人詰め込んだりします。--Open-box会話) 2019年7月20日 (土) 09:22 (UTC)
  • コメント コンテンツ翻訳を利用している者です。私が翻訳記事を書くときは機械翻訳をオフにして、分からない単語や専門用語など何らかのサポートが欲しいときはGoogle検索などを使っています。現状では(少なくとも英語では)機械翻訳の文章は出発点にすることすら難しい状態です。機械翻訳で重大な問題が出ている以上、機械翻訳は停止すべきと考えます。--プログラム会話) 2019年7月19日 (金) 11:36 (UTC)
  • 情報 インドネシア語版の交渉履歴をお読みになっていない方々がいるように感じますので、途中まで日本語で意訳しました。当井戸端の「ノートページ」をご参照下さい。どれだけ泥仕合を繰り広げたか、この過去事例を踏まえて、現実的な交渉戦術のご議論を頂けますようお願いします。今の丸腰のままでネイさんに交渉をお願いしたら、ネイさんの胃に穴が開かないか心配なレベルです。--ProfessorPine会話) 2019年7月19日 (金) 13:16 (UTC)
  • コメント 分かりやすかったです。外国語は分からないので、出来ればですが、残りもまとめて頂けると助かります。--お好みでタピオカをおかけください会話) 2019年7月19日 (金) 23:14 (UTC)
  • コメント 現実的ではありません。提案と異なるより不利な落としどころを提示するような甘さを見せれば、「押しまくれば折れる、もっと取れる」と考えるのが交渉です。これは典型的な日本外交の弱点として知られる「勝手に妥協線を引く」行動と同じで、丸腰どころか後ろから撃っているのがあなたの提案です。しかも財団は0回答を繰り返し、わざと現実を無視し続けてインドネシア語版の管理者の愚行を引き出しました。この前例があることから、機能を押しつける側という絶対的な優越性を持つ彼らが成功体験から脱却することは至難です。--Open-box会話) 2019年7月20日 (土) 02:13 (UTC)
  • コメント 例えば10~20個英語記事を持ってきて機械翻訳し、どう思うか?と言うアンケートにするのはどうでしょう?つまり、例えば
    • ①10個(程度、ランダムに)記事を機械翻訳して投稿する(もちろん普通の記事ではなく、他の場所に。このページの子ページでもいいかも)
    • ②アンケート。違和感があるか?で「大いにある」「少しある」「全くない」というような形式(ただ単に2択ではあるかないかになりますし、多いと集計が難しい。3、4択程度が現実的と思います)
    • ③集計して、その結果を交渉材料。(例えば、『10記事中9記事で「多いにある」と答えた人が〇パーセントを超える結果となりました』『「多いにある」と答えた人は10記事平均で〇パーセントとなりました』)のように。
いかがでしょうか?--Y.iwamoto-0810会話) 2019年7月19日 (金) 13:38 (UTC)
  • コメント 良いと思います。(テストケースの翻訳元記事の)選定は『おまかせ表示』で選べば良いと思いますし(存命中および近年まで存命だった故人の記事は除外すべきでしょうけども)。元々がスタブだったら意味が薄いので、『秀逸な記事』から選ぶべきかも知れませんが。--お好みでタピオカをおかけください会話) 2019年7月19日 (金) 23:14 (UTC)
  • コメント ただ機械翻訳をコピペしただけの記事を削除するのにどれだけの手間がかかっているかを思えば、日本語への機械翻訳をツール側で禁止するのは妥当だと思います。また、Y.iwamoto-0810さんご提案の「アンケート」も財団の連中との交渉材料として有用と考えます。ProfessorPineさんが翻訳してくださっている「インドネシア語版の交渉履歴」を見るかぎり、インドネシア語版側の利用者と財団の連中とで、全く話が噛み合っていなかったことがわかります。財団の連中はコンテンツ翻訳ツールを「導入」した側ですから、自分たちの不手際、技術不足を認めたくない。だから「ツールゴミ!使うのムリ!」という叫びに対して「でも削除率低いやんけ」という返しにしかならない。そこで思ったのですが、交渉材料として「英→日」の機械翻訳でアンケートをとることはもちろんなのですが、「日→英」の機械翻訳も財団の連中に見せてやって「どれだけゴミツールか」ということを思い知らせる、というのが早道ではないかと思いました。(極論、インドネシア語版のケースの「わからずや」ぶりからみて、「英→日の機械翻訳結果に基づくアンケート」の結果だけでは、「それはツールの問題やのうて、おたくらの語学力の問題ちゃうん」という返ししか来ない懸念もあります。ですから「日→英」の翻訳結果を出して、「あんたらこれ読めるか?理解できるか?これで一切修正なしに投稿しても大丈夫だと思うか?」と迫った方が、財団の連中も多少は話が通じるんじゃないですかね)彼らは、基本的には英語話者であり、「記事の翻訳」の必要性に迫られていない人達なので、言葉は悪いですが、自分たちが提供する翻訳ツールの精度を真剣に確認してなどいないんじゃないかと・・・。--Rienzi会話) 2019年7月20日 (土) 01:51 (UTC)
  • コメント 「削除率低いやんけ」は、「てめーらのせいで確認すらおいつかねーんだよ!」って返しはできますけど、無視するでしょうね。上でも書きましたが、「無視を続ければ折れる」って前例が強すぎます。なお機械翻訳の弊害一番わかってるのは英語話者ですよ。英語版が機能停止してるんですから。率直に言ってこれ、ただの差別なんですね。まぁ、差別だって突きつけたら後に引けなくなるので暴走するのは確実ですけど。--Open-box会話) 2019年7月20日 (土) 02:13 (UTC)
  • 反対 インドネシア語版の代表者はひたすら「機械翻訳のクオリティがいかに低いか?」をリンクを貼って例証し続け、財団側が「そこが論点じゃない」と却下しています。ですから、クオリティの低さを例示するY.iwamoto-0810さんの案も、Rienziさんの案も、失敗例をそのまま踏襲して徒労に終わるのでは?
  • コメント 私は@Afazさんの推測に同感なのですが、ツールの利用はGoogleと財団のビジネスディールが背景にあると思いますよ。つまり、Google翻訳の品質を上げるためにWikipediaに翻訳ツールを提供し、ユーザが機械翻訳からどこをどう直しているのかビッグデータを集めて、アルゴリズムの改善インプットにしているのだと思います。もっと邪推すると、Phabricator上で対応している財団の人が、そもそもGoogle本社から人材派遣されている可能性や、Googleから財団に寄付金が流れている可能性だってあります。特に日本語のGoogle翻訳の品質が低いと分かっているのだから、改良するためには優良ユーザに使い続けてもらう必要があるわけで。
仮に機械翻訳機能を停止させるならば、「優良ユーザは誰も機械翻訳機能を使っておらず、単に転写機能しか使ってない」ことを証明するしかないでしょう。問題ユーザや問題記事ではなく、優良ユーザにフォーカスすべきです。ちなみに私は、優良ユーザの一部は機械翻訳も部分的に使用しているケースを知っているので、証明しようとしても失敗すると思っています。だからこそ、優良ユーザを問題ユーザと切り分ける手段として、許可制を提案したわけです。
  • @Open-boxさん、この場では愚痴の垂れ流しではなく、具体的にどのように交渉するか議論しています。ご自身が交渉代表ならば、どのような文面や材料を携えて交渉に臨むのでしょうか?--ProfessorPine会話) 2019年7月20日 (土) 02:35 (UTC)
何度も大前提として、不利になる余計な提案を持ち込むな、ここでの妥協的な議論すら悪材料になるって指摘しているんですよ。隙を与えないというのは交渉の基本です。
愚痴? 自らの問題点を指摘されて対手を罵倒するとは何事か。そもそも問題点の指摘をされていることを理解できていないのでは、議論に参加することはできません。あなたの提案では交渉にはなりません。物理的な面を無視しても過去に提案された案ですし、「だったらそれで」とか「使いたい人いるんだからそのままね」って材料にすらなります。ですからこの方向性は無理があるのです。
「問題ユーザや問題記事ではなく、優良ユーザにフォーカス」問題ユーザや問題記事ではなく優良ユーザにフォーカスするのは、財団側が前回用いた言い訳です。そんな手に乗る時点で甘い。0とする証明を要求するのは悪魔の証明ですし、「機械翻訳をそのまま貼り付けているか検証できないし、回避手段のあるわずかな優良ユーザ」を「機械翻訳をそのまま貼り付けている多数の問題ユーザや問題記事に対する対策」より優越させる根拠はありません。
「許可制を提案した」時間的・物理的にできないし、そこを解決しても抜け道が確保でき、なおかつ許可されるような利用者には必要ないって指摘されてるの判ってます? 指摘を無視してもなかったことになりませんよ。
「そこが論点じゃない」「例証し続け」あなたの主張を検証しましょう。最初は[1]利用者の制限で何とかできないか? 検証してという提案。まぁこれはいいでしょう。単に提案ですし、問題ありません。実際、ここでも検証案は出ていますしね。が、次からは問題だらけです。まず[2]、統計を無視し問題点に目をつぶって有効な物もあるんだからしきい値で何とかしようとします。これが案に留まるならよかったのですが、ここから「しきい値」への固執が始まります。まず[3]、指摘済みの人員問題を無視してコンテンツ翻訳の問題とイタズラ対処他を含む通常の削除を同一視して正当化、上手く使えている人のためにと主張し、英語版と同じにしろという要求を無視し、しきい値を繰り返します。統計の意図的な悪用と拒否ではなく無視というのが肝心です。これを指摘されると次に[4]「最近の更新」の悪用を始めます(これをやるなら「新しいページ」を「contenttranslation-v2」で絞り込むんだってのはミス扱いとして)。そもそも査読しなくても巡回=査読できるという致命的な問題点があるので「査読」確認には全く使えないシステムですが、それを無視した上、またしきい値を要求します。次いで[5]英語版の存在を無視して、有効な機械翻訳を防ぐなんてと言い訳を行い、なおかつ機械翻訳の停止が選択肢にあることを認めます。直後にインドネシア語版管理者の一人が致命的な過ちを犯します。30%(機能面では70%になります、ここは相互理解に問題があったようです)の提案です(個人的な案[6][7]であることは後に指摘されました)。財団はこの案に飛びつきます。この後は、検証作業に入ります。確かにコンテンツ翻訳は減少しましたが、バグがあって有効に機能していないことも理解しました[8]。そして変更によって対応しました[9]。しかしこれでよかったとならないバグが見つかり、60%への緩和が検討されました[10]。そして、誰も検証してない! って落ちが残ったのです[11]
これを例証とするのは無理でしょう。無視と統計の悪用を組み合わせて「しきい値」への固執を見せた財団と、うかつに妥協を提案したインドネシア語版の問題です。
「しきい値」は、データ中心の移植を行うときに邪魔になるって欠点があるので、技術的にも上手くないんです。
この前例から学ぶべきは、「こちらからの譲歩は悪手」です。元々論理的には勝ち目がない戦いを撤収寸前で財団が粘り勝ちしたのです。これは財団にとっての成功であり、成功を繰り返したいと考えるのは自然なことなのです。--Open-box会話) 2019年7月20日 (土) 04:30 (UTC)
  • コメント 機械翻訳を「完全禁止」というのは少し違うのではないでしょうか。機械翻訳というのはAIを使ったものでしょうが、それなら学習により発展(改善)の余地は大いにあります。我々が今、機械翻訳により質の悪い記事が量産され、困ってるからといって、それを完全禁止し、今後の改善の可能性を潰してしまうのは・・・例えば、5年後には、95%正確になるかもしれません。そしてユーザーの8割が機械翻訳によって作った文章を自分でチェックし、手直しするようになれば、0.05(5%)×0.2(2割)=0.01(1%)程度まで質の悪い記事の割合は落とせる(一例ですが)訳で、1%程度ならば、見つけ次第誰かが直す、ということはできます。しかし今、完全に禁止したら、そうなる見込みもなくなる。(学習にはデータを要しますが、→日本語のデータは我々日本語版にしか提供できません)もちろん、今現在のグダグダ機械翻訳はなんとかしないといけないので、例えば誰でも機械翻訳で記事を作れるようにした上で、機械翻訳により作られた記事は一旦非公開。誰か別の人がチェック(きちんとした文章か)をした上(チェックできる人の要件は別に考えるとして・・・例えば自動承認された利用者とか)で公開するとか。--Y.iwamoto-0810会話) 2019年7月20日 (土) 03:04 (UTC)
コメント 重大な認識ミスがあります。この案は機械翻訳を「完全禁止」どころか、機械翻訳そのものは完全に自由です。ここを間違えていると議論がおかしくなります。この案は、機械翻訳を改訳・調整・検証せずに貼り付けてる原因の「コンテンツ翻訳ツールの内蔵機能」を止めようって提案です。「→日本語のデータは我々日本語版にしか提供できません」は、間違いです。それには「コンテンツ翻訳ツール」を経由する必要はありませんし、Google他のために日本語版が犠牲になる必要もありません。「機械翻訳により作られた記事は一旦非公開」それが先に出たDraft案です。副作用がひどいので、作成と移動の権限を整備しないと無理ですね。許可制案にも通じますが、この両案はそんなことをできるだけの体制がないんです。体制を整えるとしても、ランク制になりかねないが拡張半保護や巡回者すらなくIP及び一般利用者の権限が強すぎる現状に対処するには、時間も人手も足りないので近いうちの改善の見込みが立たないので、そんな余裕がないのです。--Open-box会話) 2019年7月20日 (土) 04:30 (UTC)
コメント 我々は誰も、機械翻訳の改善の可能性まで否定するわけではないです。それは他所でやってね、というだけ。--柒月例祭会話) 2019年7月20日 (土) 04:42 (UTC)
  • 2013年の議論ですが、翻訳の専門家の間で「翻訳の初歩が分かっていないような人は機械翻訳に手を加える(post edit)手法で翻訳した方がまだましである、一方翻訳のプロはpost edit法を使っても余計な手間がかかるばかりで変な訳文も引きずられて品質も落ちがちでメリットがない」(大意)というような知見があります[12](立教大学異文化コミュニケーション研究科/立教SFR翻訳研究プロジェクト)。Wikipediaに翻訳を投稿する人は翻訳を職業とする人もいれば素人もいるでしょう。上記の知見を踏まえると、「実際に機械翻訳をベースに作業してみたが話にならない」という経験を持つ人は、どちらかと言えば能力の高い人の方に偏りそうな気がします。その逆側の人はおそらく井戸端等には顔を出さないのでしょう。つまり翻訳の下手な人が機械翻訳を使わず独力でやるようになったとすると、機械翻訳があるときよりひどい翻訳をしてしまう可能性がある、ということも考慮する必要があるのでは、と思います。機械翻訳停止が「成功」したとして、意図したような成果が得られたか、意図に反して事態が悪化してしまわなかったか、しばらく時間を置いてから調査する用意もあった方がいいでしょう。せっかく苦労して停止にこぎつけたからには成果が得られたと思いたくなるのが人情ですので、できれば今回の議論に関係していない人が評価するといいと思います。 --2001:240:240F:FE0F:BDD9:A3B5:84FE:6EAB 2019年7月20日 (土) 08:08 (UTC) 書き忘れましたが2001:240で始まっているIPは同一人物です(今の所)。 --2001:240:240F:FE0F:BDD9:A3B5:84FE:6EAB 2019年7月20日 (土) 08:25 (UTC)

ビジュアルエディタでCitation toolを使う時に書誌情報が英語になる問題[編集]

日本語版のWikipedia:ビジュアルエディターでツールバーの「引用」をクリックし、Citation toolを使ってISBNなどを用いて単行本の書誌情報を呼びだそうとすると、和書であっても書名などが全てアルファベット表記で出てくるという問題があります。以下に例を示します。

ウィリアム・シェイクスピア『新訳夏の夜の夢』河合祥一郎訳、角川文庫、2013[1]
  1. ^ Shin'yaku natsu no yo no yume.. Shakespeare, William, 1564-1616, Kawai, Shoichiro, 1960-, 河合, 祥一郎, 1960-. Kadokawa. (2013.10). ISBN 9784041010495. OCLC 867733940. https://www.worldcat.org/oclc/867733940. 

これはどうも書誌情報をWorldCatから呼び出しているからではないかと思うのですが、日本語の本の情報をCite bookテンプレートに入れたい時はとても不便です。国立国会図書館とか、Webcat Plusあたりから書誌情報を呼んでくる形にするのは無理でしょうか?詳しい方がいましたら是非コメントを頂きたいと思います。(Wikipedia:ビジュアルエディター/フィードバックはあまりにも人目につかないのでここに投稿しました。)--さえぼー会話) 2019年7月16日 (火) 09:12 (UTC)

日本語文献の場合はNDLからデータを取得するようにするのはCite tool導入時に提案され、phabricator:T192528で修正を依頼していますが、1年以上経ってもまだ修正実施されていません。。。--翼のない堕天使会話) 2019年7月16日 (火) 14:00 (UTC)
  • ありがとうございます、既に去年井戸端で議論があったのですね。気付きませんでした。しかしまだ実施されていないということは、しばらく実施は見込めないのでしょうか…--さえぼー会話) 2019年7月16日 (火) 14:05 (UTC)
  • そうですね。早期の解消は見込めないと思います。--翼のない堕天使会話) 2019年7月16日 (火) 14:14 (UTC)
コメント 書き換えまではできませんが、ISBNからタイトル、著者名などを参照表示するGreasemonkeyの即席スクリプトです。APIはopenbdを使ってます。参照できるだけでコピペは必要です。
// ==UserScript==
// @name     ISBN参照
// @description 	wikipedia用スクリプト
// @version  1
// @grant    none
// @include  https://ja.wikipedia.org/wiki/*
// @require  https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js
// ==/UserScript==
(function () {
   $("#p-views > ul").append($("<li><br />ISBN</li>").attr({'id':'cnv_btn', 'title':'ISBNから検索'}).css({'color':'#0000ff','font-size':'13px', 'cursor':'pointer'}).css({'color':'#0000ff','cursor':'pointer'}));
   $('#cnv_btn').click(function() {
// var isbnx = document.getElementByXpath('//div/input')[2].value;
 
      var isbnx = window.prompt("ISBNを入力してください", "");
      const url = "https://api.openbd.jp/v1/get?isbn=" + isbnx;
      $.getJSON( url, function( data ) {
                   if( data[0] == null ) {
                       alert("該当データがありません");
                    } else {
                       alert('ISBN: '+isbnx+"\nタイトル: "+ data[0].summary.title+"\n著者: "+data[0].summary.author +"\n出版社: "+data[0].summary.publisher);
                    }
      });
   });    
})();

値書き換えられないかと考えましたがモーダルウィンドウなので諦めました。ユーザスクリプト化する人がいれば参考まで。--115.38.216.15 2019年7月21日 (日) 12:39 (UTC)

故人のプライバシー総合について[編集]

暫定的に以下のように分類しますが、議論の行方次第では変更するかも知れません。また追加するかも知れません。

実名記述[編集]

有名人や著名人の場合、広く知られていたり本人が希望して主に使用していた名前、また本名をそのまま公称していた場合などはここでは議論の対象外とさせていただきます。ここでは主に過去の事件等について、被害者や加害者(被疑者、被告、容疑者などとされる場合も含む)が著名でなく一般人の時、「故人にプライバシーはない」ことを理由に躊躇なく記事に実名を記述することについての是非を問いたいとおもいます。

自宅の場所[編集]

故人が死亡時、自宅の場所を積極的に公開していなかった場合、Wikipediaにその詳細な場所を記述して良いものでしょうか。故人にプライバシーはないから、削除の対象にはならないのでしょうか。


広く意見をお聞かせいただきたいと思います。またできれば方針とか私論とかのレベルまで持っていければと思います。では言葉足らずかも知れませんが一旦これで失礼します。(以上、万が一何か重大な勘違い等あるのであれば是非指摘していただきたく思います。)--ボンバスパンチ会話) 2019年7月17日 (水) 10:01 (UTC)
  • コメント 実名については加害者の家族のプライバシーの考慮を理由に、削除依頼とまではいかなくても編集除去が試みられるケースを見た事があります。いずれにしてもこれといった決まりはないでしょうし、ケースバイケースで話あうべきではないでしょうか。たとえばWP:DP#B-2には「歴史的な記事(ほとんどの関係者が既に死亡している場合)」は削除されず、伝統的に認められている例として挙げられています。
自宅にかんしては、そもそも著名人全般においても、その自宅が文化財等に指定されていたり一般公開されている場合をのぞいて「詳細な場所」を通常記載することはほぼないように思うのですが、実際にそういう例があるということでしょうか?事件現場の写真程度であれば掲載されているのを見ますが、先にもうしあげた文化財指定や資料的価値を見出した上での一般公開をのぞいては、住所等詳細を記したものはほぼお目にかかったことがありません。というか、Wikipediaでやることはないと思われます(もしかしたら海外では歴史的な事件現場が観光地化しているケースがあるかもしれませんが)。--Aiwokusai会話) 2019年7月18日 (木) 06:41 (UTC)

:「被害者や加害者…が著名でなく一般人の時」とのことですが、そのようなケースでは特筆性がないのではないでしょうか。差し支えない範囲で具体的にどのような記事を想定されているかお伺いできますと、議論がより実り多くなるかと思います。--たっとむ会話) 2019年7月18日 (木) 09:26 (UTC)

コメント 特筆性云々に関しては、例え著名な人物でなくても被害者の数がとても多く社会的に重大な衝撃を与えたものについては特筆性があるかと思料いたします。--ボンバスパンチ会話) 2019年7月18日 (木) 13:29 (UTC)

  • コメント 事件の被害者を実名記載することは、被害者自身がウィキペディアに立項されるほど著名であり、かつ本名を公開されている場合を除いて削除されるべきものと思います。一方、加害者にも親類縁者がいるわけで故人であれば実名記載をOKとすべきものではありません。従って現行の削除規定に準ずるものであると考えます。その上でAiwokusaiさんがおっしゃるように、該当事件、事故が歴史的な記事とすべきかどうかは実名記載する前にノートで議論すべきものではないでしょうか。--たびびと551会話) 2019年7月19日 (金) 07:33 (UTC)
  • コメント ノートで議論する前に実名記載されてしまった場合は如何すべきとお考えでしょうか。--ボンバスパンチ会話) 2019年7月19日 (金) 08:27 (UTC)
    • 返信 状況にもよりますが、場合によっては削除依頼にかけるべきでしょう--たびびと551会話) 2019年7月19日 (金) 15:26 (UTC)

ガラホで見たときの文字の大きさについての質問です。[編集]

ガラホで見たときの文字の大きさについての質問です。今、デスクトップモードで見て編集しているのですが、文字の大きさに大小があって見にくくてしかたがありません。例えば上の「題名」の文字は私が入力したタイトルの文字の4倍ぐらいの大きさに見えています。なぜこのようなことになるのでしょうか。またガラホの設定を変更することで解決できるならその方法をお教え下さい。ーー36.11.224.90 2019年7月21日 (日) 01:31 (UTC)ーー36.11.224.35 2019年7月21日 (日) 19:15 (UTC)

過去ログ化とインデックスについて[編集]

サブページは過去ログとは違うと思いますが、ページの外形は変化しないと思います。サブページは過去ログ用テンプレートのインデックスに組み込めないんでしょうか。典型例としてWikipedia‐ノート:検証可能性など。

それとHelp:過去ログには過去ログ化の手順は書いてあるものの、過去ログ化すべきでない範囲は慣習で決まっているのですか。カットアンドペースト方式によるとサブページに移すのは「ログ化したい部分」、固定リンク方式でもノートページから除去するのは「過去ログ化する古い議論」と書かれています。

過去ログ化すべきでない範囲は「管理者によって荒らしと判断されブロックされたアカウント利用者の会話ページに書かれた警告文」(ブロック解除申請の承認まで)だけしか書かれていませんけど、それ以外にも過去ログ化から除外されている範囲があり区別があるようですが任意なのでしょうか。

これらは過去ログ化の対象外でしょうか。Help:過去ログに説明はありません。過去ログ化の作業をする予定はありませんがノートページにある過去ログとサブページの関係がよくわかりませんでした。--Stmbbcc会話) 2019年7月22日 (月) 00:27 (UTC)