コンテンツにスキップ

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

Wikipedia:リダイレクトの削除依頼/2024年7月

2024年6月 - 2024年7月 - 2024年8月
ここは、リダイレクトの削除依頼の過去ログページです一覧)。
新規依頼は、Wikipedia:リダイレクトの削除依頼/受付へお願いします。


審議が終了した項目にリンクするには [[Wikipedia:リダイレクトの削除依頼/2024年7月#RFDリダイレクト名]] として下さい。


リダイレクトの削除依頼 2024年7月

[編集]
  • ノート:金子 遊非転送 / 本文 / 履歴 / リンク元 / 削除ノート:金子遊 (版画研究者)履歴 - 削除 依頼者票。漢字表記の姓名間空白があり、本来は記事名の付け方違反で即時削除対象のため。--メンテマン会話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)[返信]
      • (終了)存続としました。--柏尾菓子会話2024年8月4日 (日) 05:30 (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)[返信]
保留 Future (プログラミング)Future パターンかそれ以外か、対象の記事の名称が定まってから、このリダイレクトの要否を判断したいです。
なお、このままFuture (プログラミング)とするならFuture パターンの削除に賛成するつもりです。Futureはデザインパターンであると思っていますが、これは過剰なリダイレクトであると考えます。WP:CRDには明確に書かれていませんが、WP:Rには以下のように書かれているので、削除対象になり得ると思っています。
> 補記の入ったリダイレクトは、その補記込みで使われることが多いもの以外は作成しなくてかまいません(過剰なものはリダイレクトの削除依頼による削除・即時削除の対象となる場合があります)。--Wdpp会話2024年8月4日 (日) 17:22 (UTC)[返信]
すみません。上記について考え直します(打ち消し線を入れました)。--Wdpp会話2024年8月5日 (月) 15:02 (UTC)[返信]