위키백과 대화:링크로트

위키프로젝트 에세이 hide
WikiProject icon 페이지는 위키프로젝트 위키백과 에세이의 영향을 조직하고 감시하기 위한 공동 노력인 위키프로젝트 위키백과 에세이의 범위 내에 있다. 참여하려면 토론에 참여할 수 있는 프로젝트 페이지를 방문하십시오. 에세이의 목록을 보려면 에세이 목록을 참조하십시오.
이 페이지는 프로젝트의 영향 규모에 대한 가장 큰 영향을 미치는 것으로 평가되었다.
Note icon
위의 등급은 페이지뷰, 감시자, 수신 링크의 데이터를 사용하여 자동으로 평가되었다.
위키백과 도움말 프로젝트 (등급 B급, 중간중간)
WikiProject icon이 페이지는 독자와 기고자를 위한 위키백과의 도움말 문서를 개선하기 위한 공동 노력인 위키백과 도움말 프로젝트의 범위 내에 있다. 참여하려면 프로젝트 페이지를 방문하여 토론에 참여하고 열려 있는 태스크 목록을 확인하십시오. 도움말 관련 리소스를 찾아보려면 도움말 메뉴 또는 도움말 디렉토리를 참조하십시오. 아니면 당신의 토크 페이지에서 도움을 요청하면 자원봉사자가 당신을 방문할 것이다.
B-Class article B 이 페이지에는 프로젝트의 품질 척도에 대한 등급이 필요하지 않다.
중앙의 이 페이지는 프로젝트의 중요도에 대한 중간 평가로 평가되었다.

"죽은/ 썩은 링크 서명"에 대한 섹션이 있어야 하고, 코드를 고급 편집 메뉴에 넣어야 하지 않을까?

사용자가 하나를 찾는다고 상상해 보십시오. 데드 링크 옆에 코드를 남기는 것처럼 사용자가 신호를 하면 이미 대단하지 않은가? 누군가 남긴 코드를 봤는데, 이제는 코드를 찾을 수가 없어. 아마도?[dead link] 그리고 고급 편집 메뉴에 코드를 넣는 것이 이치에 맞지 않을까? Thy --SvenAERTS (talk) 13:21, 2016년 1월 31일 (UTC)[]

유튜브 동영상 보관

링크가 부패하지 않도록 유튜브 동영상을 보관하는 방법을 정확히 어떻게 해야 할까? 유튜브 동영상의 URL을 인터넷 아카이브(Wipedia의 다른 곳에서 볼 수 있음)에 넣으려고 했지만, 아카이브 링크에 접속하면 동영상이 재생되는 것을 거부하는 것 같다.

유튜브 영상을 보관하는 다른 방법은 없을까? 8bitW (토크) 23:47, 2016년 2월 8일 (UTC)[]

archive.is을 사용해 보셨습니까? 그들은 웨이백이 어려움을 겪고 있는 어려운 페이지를 보관할 수 있는 경향이 있다. 다른 사용자가 이 목록 위키백과에서 시도해 보려면:위키백과의 자료 목록 - GreenC 17:01, 2017년 3월 16일 (UTC)[]

요청 편집

"웹 아카이브 서비스" 섹션의 하단에서 "Javascript"를 "JavaScript"("플래시")로 변경하십시오. 고마워!211.100.57.47 (대화) 14:12, 2016년 3월 19일 (UTC)[]

완료 - Arjayay (talk) 15:31, 2016년 3월 19일 (UTC)[]

보관 소스는 필수 사항인가?

결국, 링크 부패를 되돌리는 것은 때때로 불가능하고 처음부터 그 빌어먹을 소스를 그냥 보관하는 것이 훨씬 더 쉽다. 만약 링크가 고장나면, 그것은 처음에 그것을 추가하는 것을 무효화한다. 로빙로버트 (토크) 07:47, 2016년 5월 5일 (UTC)[]

웨이백은 위키피디아에 추가된 모든 외부 링크를 자동으로 보관한다. 페이지에 아카이브 링크를 추가하는 작업은 2016년 현재 IaBot이 수행하고 있다. -- GreenC 16:36, 2016년 12월 13일 (UTC)[]
@GreenC: 그렇지 않아요. 나는 봇을 통해 보관소를 추가한 적이 있는데, 그것이 사용 가능한 보관소가 없는 몇몇 링크들을 죽은 것으로 태그한 적이 있다. 사무라이 쿵푸 카우보이 (토크) 16:34, 2021년 2월 7일 (UTC)[]
바라건대, 봇은 어떤 아카이브 스냅샷도 찾지 않는 것을 정확하게 보고하고 있다. 아카이브가 처음에는 존재하더라도(예: 저작권 청구로 인해 나중에 해체됨) 어떤 아카이브도 발생할 수 없다. 비슷하게, 나는 죽은 링크를 찾고, 내 기억으로는, 적절한 링크를 제공하는 편집자가 만든 거대한 봇 런을 만났다. 그것은 원래 링크가 라이브로 결정되었을 때 기사에 링크를 추가하지 않고도 이루어질 수 있다. 이러한 봇이 실행되는 범위까지 아카이브에서 적절한 스냅샷의 존재 여부를 확인하고 원본 링크가 소멸될 때 인용구에 링크를 배치하는 것이 좋으며, 원본 링크가 여전히 활성 상태일 때 링크를 추가하지 않고도 링크를 실행할 수 있다. Dhtwiki (대화) 21:04, 2021년 2월 7일 (UTC)[]

archive.is?

링크 블랙리스트에 예전의 Archive.is이 추가된 것 같아. 왜? 사용자:jdavis699 16:40, 2016년 5월 18일 (UTC) — Jjdavis699가 추가한 사전 서명되지 않은 의견(대화 기여)

더 이상 블랙리스트에 올라 있지 않다. WP:archive.is 사용 -- GreenC 16:38, 2016년 12월 13일 (UTC)[]

그래서 나는 여기에 정보를 업데이트했다. 오직 오늘만 나는 archive.is이 여전히 여기서 금지되어 있다고 생각하면서 웹사이트를 사용하면서 시간을 낭비했다. 제젠(토크) 11:21, 2017년 8월 24일 (UTC)[]

Archive.org의 새로운 문제

archive.org은 현재 위키백과에 매우 중요한 베타 버전을 구현하고 있는 것으로 보인다. 어디서 논의해야 할지 모르겠는데, 이 토크 페이지 말고 다른 곳에서 얘기하면 좋을지 알려줘. 아니면 누군가가 이미 그 얘기를 꺼냈는지도 모른다.

보아하니 우리는 지금 archive.org에서만 메인 페이지를 검색할 수 있지만 서브 페이지는 검색할 수 없다. 동시에, 아마존닷컴은 우리가 원하는 어떤 하위 페이지에도 영구적인 링크를 제공하는 것처럼 보인다.

그러므로 봇이 위키피디아의 모든 외부 링크를 링크된 웹사이트가 사라지기 전에 archive.org 링크로 대체하는 것이 현명할 수 있다. 그것이 죽은 후에, 고리를 썩게 할 방법은 없어 보인다.Anythingyyouwant (대화) 21:12, 2017년 4월 9일 (UTC)[]

우리는 지금 archive.org에서 메인 페이지를 검색할 수 있을 뿐이다. 이 페이지 https://web-beta.archive.org/에서 오른쪽 상단 모서리에 있는 "검색" 상자를 말하는 겁니까? 그것은 새로운 특징이다. 그들은 현재 기본 URL만 하고 있다. 전체 URL은 여전히 https://web.archive.org/web/*/http://www.yahoo.com/news 또는 https://web.archive.org/http://www.yahoo.com/news과 같은 여러 가지 방법으로 찾을 수 있다. -- GreenC 22:08, 2017년 4월 9일 (UTC)[]
여기 내가 archive.org 링크로 바꾸려고 했던 죽은 링크가 있다: http://www.rhapsody.com/#artist/elvis-costello/앨범/elvis-costello-costello-the rhapsody-track/track/on-ronstadts-redition-rend-reditions. 이제 그렇게 하는 것은 불가능하지?Anythingyyouwant (대화) 00:09, 2017년 4월 10일 (UTC)[]
이 경우 Wayback은 #가 페이지 섹션에 불과하기 때문에 # 이상의 모든 것을 제거한다. # 부분이 있든 없든 같은 내용이야. -- GreenC 01:17, 2017년 4월 10일 (UTC)[]
하지만 그들이 내게 주는 내용은 엘비스 코스텔로나 린다 론스타트에 대해서는 언급하지 않았다. 나는 마침내 여기서 그 내용을 찾았다: http://us.napster.com/artist/elvis-costello/album/elvis-costello-the-rhapsody-interview/track/on-linda-ronstadts-rendition-of-alison 그러나, 나는 "#"이 문제를 일으켰다는 것이 네가 옳다고 생각한다. 고마워. Anythingyyouwant (대화) 01:26, 2017년 4월 10일 (UTC)[]

링크 로트

나는 IT 보안 회사인 Symantec에 소속되어 있다. 이 페이지에서 "연결 끊김" 태그를 지정하려고 했는데, Symantec의 인수 합병 목록 한때 FA 기사였던 톰슨 로이터 통신과의 연결고리는 70개 이상이었다. 나는 웹사이트와 인터넷을 검색해봤지만 그 보고서들에 접근할 수 있는 다른 방법을 찾지 못했다. 또한 인용 템플릿은 이미 "dead-url=yes"로 표시되어 있어 인용의 1차 링크가 작동 중인 보관 버전이다. 이 페이지의 지시사항에 따르면, 이것은 모든 것이 정돈되어 있고 태그에 주소를 붙이기 위해 추가로 할 일이 없다는 것을 의미하는가? 나는 이미 페이지의 다른 끊어진 링크를 모두 수정했다. 기업M (Talk) 14:08, 2017년 4월 14일 (UTC)[]

Bot WaybackMedic은 3월 23일에 44개의 아카이브 링크를 추가했는데, 대부분 문제를 해결했는데, 왜 지금 끊어진 링크 태그가 필요한지 모르겠다. -- GreenC 15:11, 2017년 4월 14일 (UTC)[]

끊어진 연결 고리에 대해 해야 할 올바른 일은 무엇인가?

나는 위키피디아를 자주 읽으며, 가끔 깨지거나 '죽은' 고리를 접하기도 한다. 하지만 옳은 일은 무엇일까? 무시한다고? 토크페이지에 언급해 주시겠습니까? 끊어진 링크를 기사 자체에 "추가"? (나는 제대로 된 위키백과 편집자가 아니다) FAQ를 읽고, '끊긴 링크'를 검색했는데 - 질의와 일치하는 결과가 없다. 감사 — 79.76.99.144가 추가된 선행 서명되지 않은 의견(대화 기여)

  • 일반적으로, 수리, 태그, 제거 -- 순서대로. 사이트 구문이 변경되었거나 인터넷 보관과 같은 보관된 복사본이 있을 수 있는 경우 복구하십시오. 만약 당신이 수리를 할 수 없다면, {{dead link}}}}로 태그를 붙이면, 결국 다른 사람이 그것을 잡을 수 있을 것이다. 우리 또한 몇 개의 봇을 가지고 있다. 만약 여러분이 모든 곳을 찾아봤지만 결코 복구될 수 없다면 -- 그것을 제거하십시오. (그리고 바라건대 교체하면, 많은 편집자들이 대체 소스를 제공하지 않고는 죽은 링크조차 제거하지 않을 것이다.) 대부분의 경우, 아무것도 할 필요가 없습니다 -- 우리는 수백만 개의 죽은 링크를 가지고 있고, 실제로 고치지 않는 한, 그것들은 개별적으로 죽은 링크 태그를 배치하는 것 외에는 보고할 가치가 없습니다, 봇도 결국에 가서 수리하거나 태그를 붙일 것이다.—HELLKOWZ zTALK 12:00, 2017년 9월 3일 (UTC)[]
3단계에 도달한 경우: 전체 인용 부호가 아닌 링크만 해당. 작업 URL은 필요하지 않다. Right Hellknowz--50.201.195.170 (대화) 20:06, 2021년 5월 4일 (UTC)[]
내 말은 인용문 전체를 말하는 거야. 만약 출처를 검증할 수 없다면, 그것은 진짜 출처가 아니다. 위키피디아의 핵심은 검증이 이뤄질 수 있다는 것이다. 링크 없는 인용문은 정보를 검증할 수 있는 방법을 제공하지 않는다. 인용을 없애는 것은 정말 최후의 수단이다. 그래서 나는 그것이 "복원될 수 없는" 경우를 위한 것이라고 상세히 기술했다.HELLKOWNZ TALK 20:17, 2021년 5월 4일 (UTC)[]
Bull. 내가 성경에서 무언가를 인용한다면, 나는 그것을 증명할 수 있도록 URL을 필요로 하지 않는다. FS. --50.201.195.170 (대화) 21:55, 2021년 5월 4일 (UTC)[]
이것은 분명히 인터넷에만 존재하는 콘텐츠에 대해 이야기하고 있다. 왜 이 페이지에 있는 어떤 것이 물리적인 책에 적용되는가? 당신의 질문은 실제로 링크 부패에 대한 것이 아니라 인용에 URL이 필요한지 아닌지에 대한 것 같다.HELLKOWNZ 22:15, 2021년 5월 4일 (UTC)[]
아니, 당연하지 아니, 내 질문은 인용문 전체를 삭제하라는 당신의 조언이 일반적이지 않고 오히려 버가 인터넷에만 존재하는 내용에만 적용된다는 것에 동의하라는 것이었다. 어느 정도는 해냈을 거야 고마워요. 오프라인 전용 소스는 100% 허용된다.--50.201.195.170(대화) 22:26, 2021년 5월 4일(UTC)[]

도구를 사용하여 실시간 링크 보관

기사에 참조를 보관할 때 모든 참조(생존 및 사망)를 보관해야 하는가, 아니면 죽은 참조만 보관해야 하는가? 위키피디아에서 이 문제를 제기했다.Bots/Noticeboard#라이브 링크 보관 - Redex위키백과의 이전 토론 참조:Bots/Noticeboard/Archive 11#죽지 않은 링크 보관 - 좋은 생각? 나는 이 링크로트 토크 페이지가 그것에 대해 논의하기에 적절한 장소일 수도 있다는 조언을 들었다. 분명히 IABot v1.5.2와 같은 도구의 기본 설정은 죽은 링크만 보관하는 것이지만, 일부 사람들은 모든 것을 보관하는 옵션을 선택하고 있다. 이러한 관행은 버락 오바마 기사에 대한 편집으로 주목을 받게 되었다: IABot v1.5.2를 사용하는 누군가가 392개의 참조를 보관하고, 기사에 74,894바이트를 추가하고, 이미 거대한 크기를 333,241바이트에서 405,135바이트로 22.6% 늘렸다. (사용자는 내 요청에 따라 되돌아갔다.) 사람들은 이런 종류의 결과가 좋은 것이라고 생각하는가? Should some kind of consensus be developed, as to when and whether to use the "rescue all" option? --MelanieN (talk) 15:07, 4 October 2017 (UTC) On second thought I am going to post this question at Village Pump so as to get a wider readership and more input. --MelanieN (talk) 15:28, 4 October 2017 (UTC)[]

토론은 위키백과에서 한다.마을 펌프(기타)/아카이브 56#활선 링크를 보관하는 도구 사용.우안팔라 (대화) 13:39, 2018년 5월 15일 (UTC)[]

도메인 그래버 & 코퍼레이션이 인수한 데드 링크

관심 대상: 대부분의 자동 데드 링크 탐지 도우미들은 원래 대상 페이지가 도메인 그래버에 의한 광고로 대체되었음에도 불구하고 http://www.bigshoegames.com/about-us.html과 같은 링크가 제대로 작동하는 것으로 인식한다. 따라서, 그러한 도구들이 HTTP 상태 코드뿐만 아니라 페이지 내용을 살펴봄으로써 그러한 데드 링크를 탐지할 수 있다면 정말 좋을 것이다. 예를 들어 on-wiki와 같은 도메인 그래버를 나타내는 일치 패턴 목록을 컴파일하고 유지관리할 수 있으며, 수동 검토 후 다양한 도구와 동기화할 수 있다. 웨이백 머신(Wayback Machine)에서 마지막 "좋은" 스냅샷을 신뢰성 있게 자동 판단하기는 어려울 것 같지만, 이러한 종류의 링크를 유지관리가 필요하다고 표시하면 큰 진전이 있을 것이다. --Tim Landsheidt (talk) 08:35, 2017년 11월 5일 (UTC)

그것은 문제다. 도메인 무단 점유자들을 위한 필터를 쓴 내 경험에 따르면, 그들은 다양성과 이름에서 끝이 없다. 영향을 받는 도메인을 발견했고 IABot가 비활성(dead)으로 표시되도록 목록을 사용자:cyberpower678(로그에서 도메인을 가져오기 위해 먼저 코드를 작성해야 함). 이것은 꽤 어려운 소프트 404 링크의 큰 이슈의 일부분이다. -- GreenC 15:12, 2017년 11월 5일 (UTC)[]
결국 모든 시도는 부질없는 :-)이다. 나는 모든 죽은 링크를 그들의 홈페이지로 돌리는 몇몇 회사들과 단체들을 본 적이 있는데, 아마도 누군가가 그들에게 404가 독자들을 화나게 할 수도 있다고 말했기 때문일 것이다. 혹은 그들은 단지 적절한 오류 페이지를 설정할 수 있는 기술력을 가지고 있지 않다. 그 때 나는 어떤 이성의 목소리를 위해 "쿨 URIs는 변하지 않는다"로 눈을 돌렸다. 그러나 위키백과 규모에서는 하나의 패턴이 많은 페이지와 일치할 수 있으므로, 이것은 가치 있는 것일 수 있다. --Tim Landsheidt (토크) 19:50, 2017년 11월 5일 (UTC)[]

대규모 데이터 집합에 대해 프로그램을 실행했는데 웹 스쿼터(또는 이전 스쿼터들이 현재 완전히 죽은 상태)인 약 76개의 도메인을 발견했고, IABot 데이터베이스를 점검한 결과 대부분이 이미 사망한 것으로 표시되었다. IABot 인터페이스를 통해 수정하고 있지만 대기열은 현재 백업되어 있다(사용자당 한 번에 5개만).[1] 다음은 목록이다.

확장 콘텐츠
  • ahuero.com
  • anotherchance.es
  • bigdekalb.com
  • cooke.ws
  • curnonska.com
  • gabonnationalparks.org
  • kids.activedmonton.ca
  • www.activedmonton.ca
  • 망망상동맥류티브이
  • newsfix.ca
  • newwritinginternational.com
  • newyorknewstoday.com
  • oldwebsite.paralympic.org
  • paralympic.netempire.de
  • payrent.co.uk
  • pfcberkut.ru
  • usautotrails.com
  • verusx.net
  • www.airlineupdate.com
  • www.animacor.com
  • www.apacheness.com
  • www.artsandantique.net
  • www.basketpedya.com
  • www.bndr-mali.org
  • www.buddyhollyonline.com
  • www.chriswhitleydiscography.com
  • www.clannad.org.uk
  • www.claytoday.biz
  • www.comeonboro.com
  • www.detlefmauss.de
  • www.encuentroartesescenicas.com
  • www.fil-amboxers.com
  • www.flfa2010.com
  • www.floridaparks.com
  • www.foundryclimbing.com
  • www.giulianacesariniproart.com
  • www.health7800.com
  • www.hot-iron.co.uk
  • www.hwy56.com
  • www.indyinsiders.com
  • www.iraklis-fc.gr
  • www.kinema2cinema.com
  • www.lbpapalvisit.org
  • www.libertinesecurity.com
  • www.lincolnunitedfc.co.uk
  • www.luckyshow.org
  • www.marioyepes.co
  • www.mercatorgold.com
  • www.mojvikend.info
  • www.multiracialheritageweek.com
  • www.neftchifc.com
  • www.netspinners.co.uk
  • www.nfsbih.net
  • www.nick-kelly.com
  • www.oktoberfest.ca
  • www.olivercromwell.org
  • www.pgxnews.org
  • www.philadelphiabrassdrumcorps.org
  • www.pinrepair.com
  • www.rachelbillington.com
  • www.rlwc08.com
  • www.saintpatrickskilsyth.org.uk
  • www.saints-alive.co.uk
  • www.shipstontennis.org.uk
  • www.simpsonwatch.com
  • www.stroudsfitness.net
  • www.theforgottenimp.co.uk
  • www.thirdfridaywine.com
  • www.timesnews.co.ke
  • www.tonicbooks.com
  • www.usautotrails.com
  • www.versussleep.net
  • www.walbergwatch.com
  • www.webhosting.info
  • www.welsh-canoeing.org.uk
  • www.xblb.com

완전한 목록은 아니지만, 아마도 전체의 상당한 부분을 차지할 것이다. -- GreenC 20:30, 2017년 11월 5일 (UTC)[]

발표: RfC: 인터넷 아카이브에 대한 재정 지원과 관련된 구속력이 없는 조언 RfC

위키백과:마을 펌프(기타)/아카이브 57#RfC: The Internet Archive --Guy Macon (대화) 12:13, 2017년 12월 22일 (UTC)[]

오버홀

이 페이지는 다소 길고 장황하게 되어 대부분의 사람들이 읽지 않는 것 같다. 이것은 지난 몇 년 동안 모든 사람들이 편집하는 위키피디아의 조건과 성격 변화로 인해 일어났다. 중요한 내용이 명확하게 제시될 수 있도록 페이지를 정리한 후 다듬고 싶다. 지금은 정보 포인트와 신입 사원을 위한 튜토리얼이 혼합되어 있다. 그것은 별로 좋지 않다. 자습서는 별도의 문서에 작성될 수 있으며, 이 자습서는 자동화된 시스템과 수동으로 현재 보관되고 있는 다양한 방법에 대한 중요한 정보의 출처를 편집자에게 제공한다. -- GreenC 16:55, 2018년 1월 12일 (UTC)[]

그럴듯하게 들리지만, 악마는 디테일에 있다. 사용자 페이지의 하위 페이지에 개편 초안을 작성하고 이를 실행하기 전에 의견/조정을 요청하는 것이 어떻겠습니까? --Guy Macon (대화) 19:11, 2018년 1월 12일 (UTC)[]

archive.org의 사이트 제외 목록

예를 들어 로봇 때문에 archive.org을 통해 보관할 수 없는 사이트 목록이 있는 것은 유용하지만 유지될 수 없을 것 같다.txt 또는 일반 제외. 예를 들어, eWeek는 웨이백 머신에서 'from the wayback machine'으로 보이지만, archive.is에 보관할 수 있다. 생각? --사용자:Ceyockey (Talk to me) 2018년 4월 14일 12시 50분 (UTC)[]

그것은 웹사이트별로 끊임없이 변화하고 있다. My bot WP:웨이백메딕은 링크가 제외된 시점을 자동 감지해 archive.is과 같은 대안을 찾을 수 있지만 도메인별로 운영되지는 않는다. eWeek URL이 포함된 모든 페이지에서 봇을 실행할 수 있다. -- GreenC 14:28, 2018년 4월 14일(UTC)[]

외부 링크 섹션

아이러니하게도, 외부 링크 섹션의 추가 기능에 대한 외부 링크 중 일부는 죽었다. 코멘트 태그 안에 죽은 URL을 숨겼다 (<!-- -->); 이것들을 대체할 수 있는 다른 추가 기능에 대해 아는 사람? --Hmxhmx 18:34, 2019년 1월 5일(UTC)[]

사용자:Hmxhmx, 나는 내가 개인적으로 사용하고 유용하다고 생각하는 공식적인 웨이백 추가 기능을 방금 추가했어. 두 번째로 큰 아카이브 캐시는 archive.오늘날은 add-on을 모르나 수동으로 확인해야 한다. --GreenC 19:05, 2019년 1월 5일 (UTC)[]

고마워! 이 추가 기능에 대해 몰랐어. --Hmxhmx 11:42, 2019년 1월 6일 (UTC)[]

이 기사는 왜 세미프로토타이틀인가?

위키피디아는 무료 백과사전이 되어야 한다. 이 글은 왜 소위 '반보호'인가? 이 기사를 반보호적으로 쓴 사람은 부끄러워해야 한다. 위키피디아의 소위 보호정책은 마음에 안 들어, 귀찮아. 지금 당장 이 글의 반보호 조치를 없애라고 촉구했잖아! 나는 비슷한 창의력 차이 때문에 3년 전에 위키피디아를 그만두었다. 이른바 보호정책은 농담이다. 이제 '상식'을 가지고 '자유로운 엔씨로피디아'에 프리백을 다시 넣어야 할 때다. 화면 오른쪽에 있는 노 모어 프로텍션 넌센스, 노 모어 골드, 실버 자물쇠. SMH! 스펜서 H. 카터 (토크) 22:18, 2019년 5월 24일 (UTC)[]

a) 어떤 기사를 말하는지는 아무도 알 수 없다. b) WP:비강제적이야 마넷DTalk 23:25, 2019년 5월 24일 (UTC)[]
c) 이 토크 페이지와 관련된 페이지를 말하는 경우, 해당 페이지가 기사가 아님을 알려야 한다. 당신이 생각하기에 당신이 편집해야 한다고 생각되는 편집이 있다면 당신은 이 대화 페이지에 편집 요청을 할 수 있다. MarnettD Talk 23:35, 2019년 5월 24일 (UTC)

도움이 안 되는 페이지

나는 이것이 도움이 되지 않는 페이지라고 생각한다. 나는 죽은 링크가 있는 페이지를 보고 있다; 나는 웨이백 기계에서 보관된 버전을 찾았고, 나는 인용문에 이 보관된 버전이 포함되도록 하고 싶다. 그렇게 하려면 인용문에 어떤 형식을 넣어야 하는가? 제프리.랜디스 (대화) 15:55, 2019년 10월 3일 (UTC)[]

이것은 § 인터넷 아카이브 섹션에서 다루어진다. 기본적으로 추가해야 함 archive-url=archive.org/example archive-date=3 October 2019 인용 템플릿 안에 (또는 다른 날짜 형식 - 항상 잊어버린다) 나는 이 정보가 어쩌면 단순한 전후 예를 통해 더 명확하고 두드러지게 전달될 수 있다는 것에 동의한다. 콜린 M (토크) 16:12, 2019년 10월 3일 (UTC)[]
나는 더 자세한 지시를 덧붙였다. 그게 도움이 되었으면 좋겠어.AlanBarrett (대화) 16:59, 2020년 1월 18일 (UTC)[]

라이브 링크의 아카이브 세부 정보를 페이지에 추가해야 하는가?

1년 전 부터 이 문제에 대한 간단한 논의가 있지만, 해결책은 없다. 실시간 링크의 아카이브 세부사항을 기사 페이지에 추가하는 것이 허용될 수 있는가? 이 문제는 여기서 [2] 제기되는 문제인데, 적어도 라이브 링크에 대해서는 추가할 문제가 없다고 생각했었다(이 문제는 선택 사항이지만 IABot을 통해 할 수 있다). 그러나 위의 논의와 이 확산 문제는 라이브 링크로 원치 않는 것으로 제안하는가?(이러한 링크의 아카이브 버전이 자동으로 만들어지는 것으로 알고 있다. 아카이브가 만들어져야 하는 것이 아니라 연결만 하면 되는 것이다.) --Masem (t) 06:34, 2020년 1월 18일 (UTC)[]

원래 URL이 여전히 작동하고 있는 경우에도 아카이브 링크가 유용하다고 생각한다. 예를 들어, 미래 링크 부패 및 참조 페이지의 미래 변경으로부터 보호한다. 그러나 url-status=live시 {{Citation} 템플릿이 아카이브에 덜 중점을 두도록 변경하는 것이 타당할 수 있다. 예를 들어, 이렇게 렌더링하는 대신
"도리를 찾아서"애니메이션 영화 개봉 기록을 깨뜨린다. 연합통신. 2016년 6월 20일. 2016년 6월 21일 원본에서 보관. 2016년 8월 11일 회수.
다음과 같이 기록물을 해체할 수 있다.
"도리를 찾아서"애니메이션 영화 개봉 기록을 깨뜨린다. 연합통신. 2016년 6월 20일. 2016년 8월 11일 회수. 2016년 6월 21일 보관.
AlanBarrett (대화) 16:26, 2020년 1월 18일 (UTC)[]

토이 스토리 3에서 위 예시를 들자면, 나는 페이지의 모든 링크를 미리 보관하는 것이 불쾌하다는 것에 동의한다. 아카이브 URL 자체는 부패 및 문제를 연결하기 쉬우며 유지 보수와 확인이 필요하다는 점을 명심하십시오. 그것은 또한 위키텍스트에 추가된 복잡성의 덩어리다. 모든 링크를 보관하는 IABot의 특징은 많은 토론이 시작되었고 해결책이 없는 상태에서 항상 논란이 되어왔다. IMO는 관리자로 제한되어야 하며, 약간의 명분이 있을 때만 실행되어야 한다. -- GreenC 17:14, 2020년 1월 18일 (UTC)[]

나는 이것이 논란이 될 수 있다는 것을 전혀 몰랐다. 독자들이 보는 콘텐츠에 대한 참조의 무결성은 의심할 여지 없이 원본 편집기를 사용하는 사람들을 위해 일부 추가 텍스트의 사소한 불편함보다 우선되어야 한다. 물론 우리는 문제가 발생하기를 기다리기 보다는 사전에 링크가 부패하지 않도록 해야 하며, 나중에 보관된 버전이 있으면 좋겠다는 희망을 가지고 링크를 고치려고 노력해야 한다. 소스 편집기에서 인용 부호를 많이 검색하는 것에 대한 좌절감은 공감하지만, 그것은 우리가 두 개의 매개 변수를 사용하는지 여부에 관계없이 어드레싱을 사용할 수 있는 문제다. 편집기에서 기본적으로 마크업되는 붕괴에서부터 메타에 있는 사람들에 이르기까지 많은 기술적 개입이 있다.위키사이트가 작업 중이다. 그 모든 개입은 편집자들에게 유용할 것이다. 그러나 우리의 우선 순위는 독자들이다. \\ 18:09, 2020년 1월 18일 (UTC)[]

IABot은 (IABot 데이터베이스에서 볼 수 있는 것처럼) 마주치는 모든 링크를 보관하지만 기본적으로 링크가 소멸될 때까지 아카이브를 위키백스트에 로드하지 않는다. 그런 일에는 의견 일치가 없다. IABot의 수동 선택사항은 항상 논란의 여지가 많았다. 당신은 그것을 디폴트한 행동으로 만드는 것에 대해 결코 공감대를 얻지 못할 것이다. 당신이 그러한 논의에서 위에 제시해 주는 주장은 상당히 표준적인 것이지만 또한 반대되는 주장과 의견들도 있다. -- GreenC 18:29, 2020년 1월 18일 (UTC)[]
만약 우리가 일반적으로 라이브 링크를 보관하는 것을 피해야 한다는 것을 과거의 토론으로 확립했다면, 나는 이것을 이 페이지에 포함시킬 것을 권고하고 싶다 (그리고 다시 한 번 강조하면서, 이것은 모두 자동 도구를 통해 이루어지기 때문에 archive.org이나 이와 유사한 것에 참조가 적절하게 저장되어 있는지 확인하기 위해 IABot 같은 것을 사용할 필요는 없으며, 우리는 다시 한번 말하겠다.IABot을 통해 라이브 링크가 소멸되고, 그렇지 않으면 라이브 링크의 아카이브가 과도한 Wikitext를 추가하며, 그 자체가 소멸될 수 있다.) 그러나 만약 누군가가 그것들을 포함하기로 결정한다면, 그러한 추가 사항들을 되돌리는 것 또한 DATERET의 작동 방식과 같은 방식으로 피하거나 부적절하다고 판단되어야 한다. 그러나, 이것에 대한 주요 합의 논의가 어디에 있는지 확실하지 않다. --Masem (t) 18:37, 2020년 1월 18일 (UTC)[]
라이브 아카이브 링크를 대량 추가하는 IABot 옵션 기능(컨트롤 페이지의 체크박스)이 논란이 되고 있다. IABot 기능이 존재하기 전에는 라이브 링크를 추가하는 데 문제가 없었다. 모든 논의는 IABot 기능과 봇을 통해 맹목적으로 대규모 링크를 추가하는 IABot 기능에 한정되어 있다. 토이 스토리 3은 이 IABot 기능의 사용에 관한 것이다. 예를 들어, 봇을 배치한 사람이 실제로 아카이브 링크가 정확하고 작동하는지 확인했는가? 아니면, 그들은 단지 봇이 항상 제대로 이해하고 가장 잘 안다고 가정할 때 점검이나 검증 없이 링크를 대량으로 추가하는 것인가? BTW, IABot은 이 기능에 대한 합의를 본 적이 없으며, 이와 같은 지속적인 스레드에도 불구하고 논의나 구체적인 승인 없이 봇 운영으로 인해 만들어졌다. -- GreenC 19:31, 2020년 1월 18일 (UTC)[]
그래, 그게 말이 돼. 그리고 그건 이 페이지에 기록되어 있는 것이어야 해. 다른 사람이 라이브 링크 아카이브 링크를 모두 수동으로 파악하여 추가했는지 확인하기 위해 - 선의로 아카이브 링크가 제대로 작동하는 페이지인지, 그리고 해당 링크의 출처를 뒷받침하는 정보를 확인했다면, 이는 괜찮지만, 아마도 "바쁜 작업"의 성격일 것이다. --Masem (t) 20:39, 18 2020년 1월(UTC)[]
네, 링크를 추가하는 데 수동으로 이의를 제기하는 사람은 본 적이 없습니다만 -- GreenC 17:51, 2020년 1월 19일 (UTC)[]
나는 내가 기분이 좋다면, 단수는 아니지만, 심지어 작은 추가 (< 10K 문자)에도 이의를 제기하는 사람이다. 다만 인용문 원본을 추가할 때 아카이브 연계설정을 독려하는 방침은 이를 긍정적으로 위축시킬 필요가 있는 대규모 증설을 부추기는 것으로 보인다. 다른 사람들이 말한 것 외에도 불필요한 아카이브 링크는 시각적 잡동사니 텍스트 편집자가 반드시 원시 편집 모드로 분류해야 한다(나는 그러한 잡동사니, 아카이브 링크니 아니니 하는 많은 참조가 많은 기사를 구문 분석하기 위해 Wiked를 사용하지만, 그 도구는 텍스트를 가리는 것과 같은 결함을 가지고 있다. 그런 다음 다운로드 시간을 추가해야 하는 문제가 있다(아카이브 링크가 있을 때 추가 설정 시간이 있는가? 참조 렌더링이 페이지 다운로드 시간, 특히 느린 컴퓨터에서 어떻게 추가되는지를 잘 알고 있다). Dhtwiki (대화) 20:03, 2021년 2월 6일 (UTC)[]

페이지 기록 탭에서 이 신비한 r "고장 링크 수정" 옵션은 어디에서 찾을 수 있는가?

나는 그런 것을 볼 수 없다. 유화성은 언어에 따라 달라지는가, 주제 설정에 따라 달라지는가? Dqeswn(대화 기여) 20:52, 2020년 1월 21일(UTC)[]에 의해 추가된 서명되지 않은 이전 의견

"아래 나열된 버전에 대해"를 시작하는 줄 바로 위에 있다. -- GreenC 21:00, 2020년 1월 21일 (UTC)[]
그래, 그 페이지 역사를 보면 페이지 제목 바로 근처에 있어. 여기 스크린샷 오른쪽 하단에. [3] --Masem (t) 01:56, 2020년 1월 22일 (UTC)[]

아카이브 서비스 선택에 대한 지침

사용자가 만든 수많은 아카이브 링크:InternetArchiveBot, 다른 아카이브 서비스보다 Wayback Machine을 사용하는 것으로 추정되지만 Wayback에는 몇 가지 단점이 있다.

오늘 Archive.에서 보고된 바와 같이, 기존의 웨이백 페이지는 로봇을 통해 사실 이후에 차단될 수 있다.txt. 대안으로 (그리고 동일한 효과로) 웨이백 머신을 사용하여 웨이백 운영자에게 전자 메일로 요청을 보내 블록을 요청할 수 있다는 것을 문서화한다.

이것은 오늘날 아카이브의 사용을 선호하기 위한 설득력 있는 이유(적어도 많은 경우)를 제공한다. 물론, archive.org이나 일부 다른 아카이빙 서비스가 오늘 아카이빙보다 선호되는 다른 시나리오가 있을 수 있다.

위키백과 페이지에 대한 보관 서비스를 선택할 때 고려해야 할 사항은 복잡하고 명확하지 않다. 그것은 개별 편집자에게 맡겨서 알아내야 할 것이 아니다. 링크 부패의 부정적 영향을 최소화하기 위해 필요한 수집된 지식을 수집하는 페이지가 바람직해 보인다. 파브릭레이터(토크) 03:15, 2020년 3월 18일 (UTC)[]

만약 이것이 중앙에서 결정된다면, 그 결정은 분명히 인터넷 아카이브가 될 것이다. 위키미디어 재단이 지속 가능한 경쟁자를 개발하기 위해 수백만 달러를 투자하기를 원한다고 해도 말이 되겠는가?
웨이백 머신의 단점은 대개 특정 URL(예: 이상한 JavaScript, AJAX, iframe 또는 쿠키 요구사항이 있는 페이지)에서 볼 수 있기 때문에 개별 편집기는 보관된 버전이 목적에 맞지 않고 다른 것으로 교체해야 함을 알 수 있도록 배치된다. 나는 특정 URL을 더 "강력한" (그리고 비싼) 탐색으로 보관하는 것에 대해 추가 지원을 받는 것이 좋을 것이라는 것에 동의하지만, 어떻게 그것이 무분별하게 제공될 수 있을지는 잘 모르겠다.
구체적인 사례에 대해서는 ArchiveTeam by ArchiveBot by ArchiveTeam도 이용할 수 있다. 한 가지 가능한 요청(아마도 다음 m:Community Wishlist Survey에서조차)은 사용자가 일반적인 웨이백 크롤에서 특정 제한 집합을 우회하기 위해 해당 방법을 통해 보관용 URL을 제안(제한된 수)할 수 있는 방법을 제공하는 것일 수 있다. (어떤 URL을 지정할 필요가 있다.) 저작권 문제를 무시하는 것은 아카이브가 지속되는 경우 집중해야 할 "문제"가 아닐 수 있다. 네모 07:16, 2020년 3월 18일 (UTC)[]

My bot WP:WAYBACKMEDIC은 아카이브의 가용성을 테스트하고 있으며 그렇지 않을 경우 다른 제공업체로 전환한다. 그것은 문제가 얼마나 흔한지 기록한다. 그것은 존재하지만 지나치게 걱정할 것은 아니다. 어떤 순간에도 웨이백 링크의 2% 미만이 문제를 가지고 있을 것이다. 웨이백은 장점이 많다. 위키피디아에 추가된 모든 새로운 URL은 24시간 이내에 웨이백에 보관된다. 이것은 콘텐츠 저장 이유 즉, 중요한 것이다. 페이지의 내용이 시간이 지남에 따라 변경될 때 웨이백은 사용자가 원하는 경우 새로운 버전을 선택할 수 있도록 시간이 지남에 따라 페이지를 계속 보관한다. 웨이백은 다른 어떤 공급자보다 더 많은, 훨씬 더 많은 것을 가지고 있다. Wayback은 아카이브가 있는 소프트 404s에 대해 꽤 좋다.오늘날 50% 이상이 대규모에서 해당 서비스로 자동화된 아카이빙을 하고 있다.이 서비스를 게시하기 전에 각 페이지를 수동으로 확인해야 한다.내가 작성한 자동 소프트 404 체커는 그것을 15%로 줄여야 하지만 여전히 너무 높아서 수작업 점검이 매우 힘들다. -- GreenC 14:59, 2020년 3월 18일 (UTC)[]

나는 모든 위키피디아에서 효과가 있는 대답을 갖는 것이 중요하다고 생각하지 않는다.
봇들만이 아카이브 URL을 추가해야 한다고 말하려는 것이 아니라면, 편집자가 아카이브 URL을 추가하기로 선택할 수 있는 경우가 있을 것이고, 아카이브할 때가 있다는 점을 고려할 때.오늘은 웨이백에 대한 좋은 복사본이 있지만, 웨이백은 그렇지 않다. 그렇다면 우리는 반드시 공식적인 정책이 아니라 몇 가지 지침이 필요하다. 예, WP:archive.today를 사용하는 것은 올바른 장소처럼 보일 수 있지만, 적어도 오늘날에는 아카이브를 사용하는 "너츠 앤 볼트"가 누락되어 있다. 그리고 나는 다른 관점으로 인해 문제가 있는 장소가 될 수 있다고 생각한다. 반드시 합의를 대표하지 않는 "이해"를 갖는 것이 허용될 수 있는가? 파브릭레이터 (토크) 08:35, 2020년 3월 21일 (UTC)[]
물론 누구나 에세이를 만들 수 있다. -- GreenC 11:44, 2020년 3월 21일 (UTC)[]

아카이브 URL의 데드 링크 수정

플래시댄스(사운드트랙) 기사를 쓰고 있는데, 참조번호 27번은 url-상태=dead가 있는 아카이브-url을 가지고 있다. 나는 27개의 포인트가 있는 archive.org 페이지와 거의 동일한 새로운 위치를 발견했다. 새로운 버전은 다음과 같다.

https://www.ifpi.fi/tutkimukset-ja-tilastot/kaikkien-aikojen-myydyimmat/ulkomaiset/albumit/

27개를 모두 이것으로 교체해도 괜찮을까? 아카이브 url을 이것으로 교체하고 상태를 제거하면 되는 겁니까? 나는 이런 상황에 대처할 수 있는 최선의 방법을 배우기를 기대한다. 정말 고마워! 다나필레 (대화) 00:16, 2020년 3월 23일 (UTC)[]

다음은 url을 라이브 작업 URL로 설정하고 url을 그대로 두며 url-status를 "live"로 설정하십시오.
IABot은 이것을 망치는 경향이 있으므로 ''{cbignore bot='를 추가한다.닫는 'ref' 태그에 이어 'InternetArchiveBot}' (다른 봇들이 이렇게 하지 않을 것이라는 생각에 손가락을 교차하고 있다.)
나의 근거는 이 콘텐츠를 사용할 수 있게 된 두 개의 다른 URL의 존재에 "빵 조각"을 남기고 싶다는 것이다(아카이브 서버 무시). 라이브 URL이 작동을 중지하면 편집자는 적절한 보관 복사본을 선택할 수 있는 두 개의 URL을 모두 가지고 있다. 또한 내용에서 유의미한(그러나 확실하지 않을 수 있음) 차이가 있다면, 우리는 참조할 수 있는 이전 URL을 가지고 있다. 파브릭레이터 (토크) 03:48, 2020년 3월 23일 (UTC)[]
파브릭레이터 제발 시스템을 해킹하지 마십시오. 우리는 이런 종류의 상황을 정리/수정하기 위해 봇을 연구하고 있다. url= 그리고 archiveurl= 일치해야 하고 그렇지 않으면 고쳐야 해 문제는 에 다른 URL을 넣었을 때 archiveurl= 에 존재한다. url=나중에 죽는 경우 슬롯이 이미 다른 URL로 사용되었고 이제 링크가 썩은 상태로 고착되었기 때문에 아카이브를 배치할 곳이 없다. 여러 개의 다른 URL을 사용하려면 두 개의 인용구를 사용하십시오.
다나필레, 이 상황에서 삭제 archiveurl=, archivedate= 그리고 url-status= 전적으로, 그리고 대체하다 url= 새로운 작업 URL로 -- GreenC 12:11, 2020년 3월 23일 (UTC)[]
정말 고마워! 다나필레(대화) 13:31, 2020년 3월 23일 (UTC)[]

'수동 보관'에 메멘토 프로젝트 추가

나는 메멘토 프로젝트가 편리한 웹 아카이브 사이트 목록에 추가되어야 한다고 생각한다. 즉, "인터넷 아카이브Archive.is같은아카이빙 서비스 사용"이라는 문장과 "인터넷 아카이브, Archive.is 또는 메멘토 프로젝트같은 웹 아카이빙 서비스 사용"이라는 문장을 교환한다. 내 생각에는 메멘토 프로젝트가 한 번에 너무 많은 아카이브들을 검색할 수 있다는 사실(항상 100% 성능을 가진 것은 아니지만)은 추가적인 최소 사용자 노력의 가격으로 그러한 기회를 놓치기에는 너무 중요하다고 생각한다. --Entrpix (대화) 20:08, 2020년 4월 11일 (UTC)[]

나는 그것을 눈에 띄게 추천하는 데 방해가 되지 않을 것이다. 그들은 두 개의 시스템을 가지고 있는데, 하나는 사용자 대면의 "모든 제공자의 모든 링크 표시" 데이터베이스다. 다른 하나는 각 아카이브 제공자를 직접 폴링하는 DIY입니다. 후자는 확인 당시 아카이브 제공자에 실제로 존재하는 내용을 반영하기 때문에 상당히 신뢰할 수 있지만, 물론 각 제공업체 사이트를 직접 폴링해야 하기 때문에 시간이 오래 걸릴 수 있어 속도가 느리다. 전자는 각 제공자에 한 번에 존재했던 것을 메멘토 웹사이트에 유지 관리하는 캐시된 데이터베이스지만, 현재 상태로 유지되지 않기 때문에, 당신은 보관 제공자 끝의 변경으로 인해 나쁜 데이터를 갖게 되고, 이는 메멘토 데이터베이스에 반영되지 않는다. 캐시인 만큼 결과가 DIY 방식보다 빠르게 돌아오는 것이 장점이다. 또한 최종 목적지 보관소에 직접 연결하는 것이 바람직하다. -- GreenC 22:22, 2020년 4월 11일 (UTC)[]

단면 썩음(단면

무료오픈 소스 소프트웨어 라이센스의 비교#승인, "유니센스" 행에서 OSI 승인 링크는 섹션에 대한 닻을 포함한다. unlicense 링크 자체는 기사를 반환하지만 섹션이 제거되어 브라우저가 닻을 무시한다. 이것을 여러 번 보았다(비율은 낮지만). 표시를 할 수 있는 방법이 없을까? {{데드링크}}}}은(는) 부적절하다고 생각하지만 대안은 찾지 못했다.--프랭클린 유(토크) 22:32, 2020년 5월 16일(UTC) 레슨 1-1 컴퓨터 기본 https://totalemitranews.blogspot.com/2020/10/lesson-1-1-computer-fundamentals.html— Vicckymm123(토크 기여) 10:20, 2020년 10월 3일(UTC)[]

보관하다.오늘(2010-2012년)

그 기사는 아카이브를 주장하고 있다.현재 2010년과 2012년 사이에 보관된 URL.

하지만 아카이브.오늘날2012년 이후에만 존재한다. --84.147.40.124 (대화) 10:21, 2020년 7월 17일 (UTC)[]

자동 보관 질문

자동 보관소는 나에게 경험적으로 사실이 아니다. 나는 15페이지 이상의 위키피디아 페이지를 만들고 상당히 다시 쓰고 개선해 왔으며, 매번 일부 또는 반만 작성하거나 운이 좋으면 대부분 내가 IABot을 사용할 때 보관된다. 하지만 매번 내가 직접 웨이백 머신이나 Archive.is을 통해 사용자 지정 아카이브 URL을 만들어야 한다는 것을 알게 된다. 그래서 어떻게 된 거야? 리드 섹션의 이 진술이 부정확한 것인가, 내가 잘못하고 있는 것인가, 아니면 둘 다인가? 위키백과 자동보관을 고칠 필요가 있는가? 그리고 만약 그렇다면, 보관 사항을 수정하거나 담당자에게 통보하는 방법은? Factfanatic1 (대화) 13:53, 2020년 8월 18일 (UTC)[]

검증이 된다면 프로그램을 관리하는 인터넷아카이브에 보고할 수 있다. 간단하다. 페이지에 URL을 추가하고 WaybackMachine에 아카이브가 표시되는지 확인하십시오. 만약 그들이 추가된 URL의 diff를 여기에 올리지 않는다면. -- GreenC 14:19, 2020년 8월 18일 (UTC)[]
@GreenC: 그러나 앞으로 내가 다시 쓰고 더 많은 페이지를 만들 때, 나는 어떻게 해야 할까?
새 URL을 추가하십시오. 해당 URL이 WaybackMachine에 아카이브되는지 확인하십시오. 24시간 안에 자동적으로 일어날 겁니다. 24시간 후에 archive.org에 없을 경우 여기에 URL을 게시하십시오. -- GreenC 18:19, 2020년 8월 18일(UTC)[]
@Factfanatic1: 보관 봇을 통해 페이지를 실행할 수 있다. 그리고 자동으로 링크를 보관하고 페이지에 추가할 것이다. 사실, 나는 당신처럼 이렇게 함으로써 보관될 수 없는 죽은 링크들을 발견했으므로, 이렇게 하는 것을 추천한다. 그러면 나는 페이지의 링크와 관련된 정보뿐만 아니라 그 링크들을 모두 삭제해야 했다. 사무라이 쿵푸 카우보이 (토크) 16:44, 2021년 2월 7일 (UTC)[]
@사무라이 쿵푸 카우보이: 봇(더 이상)이 웨이백머신(WaybackMachine)에서 자동적으로 새로운 기록물을 만들어내는데, 이것은 별도의 프로세스에 의해 이루어진다. IABot은 위키백과에 보관 URL을 추가하는데, 이는 웨이백(Wayback의 캐시인 IABot database iabot.org에 있는 것)의 preeback(Wayback)의 캐쉬인 IABot database iabot.org에서 찾을 수 있다. -- GreenC 17:09, 2021년 2월 7일 (UTC)[]

재조정을 통해 링크가 썩음

이런 건 전에 본 적이 있지만 지금까지 물어볼 생각은 없었다. 베네수엘라에서 범죄를 편집하는 동안 나는 웹사이트 http://www.scotsman.com/news/venezuela-police-corruption-blamed-for-kidnapping-epidemic-1-1667444에 대한 링크를 발견했다.

링크를 따라가면 HTTP 301 또는 https://www.scotsman.com/news/wait-justice-over-teachers-killer-gets-life-prison-1667444으로 리디렉션된다.

인터넷 아카이브에는 원본 기사의 아카이브가 있지만, 최근 아카이브도 사이트 #2로 리디렉션되어 대신 저장되었다. 이런 상황에서 어떻게 해야 할까? 이전 보관 사이트를 연결하고 추가 링크가 모두 끊어지므로 링크를 업데이트하지 말라고 경고하시겠습니까? 조언: Ph03n1x77 (대화) 20:29, 2020년 8월 18일 (UTC)[]

오 부드러운 404s, 그것들은 어렵다. 나는 단지 그 기사를 사용하기 위해 편집했을 뿐이다. {{cbignore}} 이는 봇들이 인용구를 건드리지 말라는 것이다. -- GreenC 00:01, 2020년 8월 19일 (UTC)[]

템플릿용 인터넷 아카이브 백업:외부 매체

나는 위키피디아에서 URL을 참조로 사용할 때, 인터넷 아카이브는 아직 그렇게 하지 않았다면 곧 바로 백업하도록 한다는 것을 알고 있다. 템플릿에 사용되는 URL에 대해서도 유사한 방법이 있는가?외부 매체? 우리가 부패와 싸우기 위해 최선을 다하고 싶다고 생각했어. {{u Sdkb}}} 05:38, 2020년 8월 28일(UTC)[]

mw:externalinks 테이블에 링크가 등록되어 있는 한, 픽업된다. 네모 07:03, 2020년 8월 28일 (UTC)[]
니모 bis, 오 대박, 그럼 벌써 준비가 다 된 것 같군. (미디어위키에 대해서는 잘 모르는데 어떻게든 등록이 되어 있을 것 같아.) {{u Sdkb} 07:56, 2020년 8월 28일 (UTC)[]

YouTube 링크 보관

안녕. 내가 위키피디아에서 실제로 작동하는 유튜브 비디오 보관기를 본 것 같아. 한동안 이 사이트를 찾았는데 다시 찾을 수가 없어. 내가 어디서 찾을 수 있는지 아는 사람 있어? 응, #유튜브 영상 아카이브에서 지적한 대로 archive.is을 시도해봤지만 소용이 없었어. 웨이백머신과 내가 생각할 수 있는 모든 주류 보관자들은 유튜브 동영상을 올바르게 보관하지 않기 때문에, 동영상을 실제로 보관하는 사이트는 유튜브가 부패하는 것을 막는 데 매우 도움이 될 것이다. 나는 그것이 존재한다는 것을 알고 있고, AFAIK, 그것은 유튜브 링크/링크 부패/등등에 관한 위키백과 정책에서 연결되었지만, 나는 그것을 다시 찾을 수 없다. 고스트P. 21:20, 2020년 11월 9일 (UTC)[]

사용자:GhostP, 내가 아는 유일한 방법은 침엽수(이전의 Webrecorder.io)뿐이다. A을(를) 배치해야 할 경우 {{cbignore}} 인용 템플릿의 마지막에 (폐쇄 후 }) 그렇지 않으면 봇들이 그것을 인식하지 못하고 링크를 제거할 수 있다. -- GreenC 21:59, 2020년 11월 9일 (UTC)[]
침엽수의 가장 큰 문제는 당신의 계정이 디스크 공간 사용 한도를 가지고 있어서 당신은 고갈되기 전에 많은 링크만 보관할 수 있다는 것이다. 아마도 여러 개의 계정을 등록할 수 있지만, 결국 그들은 인기를 얻게 될 것이다. 그들은 또한 완전히 무료하지 않은 것은 불확실한 미래를 가질 수 있도록 저작권 내용을 눈살을 찌푸리는 경향이 있다. 그것은 학술과 예술을 위해 디자인된 것이 아니라 대량 보존을 위해 디자인된 것이다. 차별이 있으면 효과가 있다. -- GreenC 22:04, 2020년 11월 9일 (UTC)[]
내가 찾던 사이트야, 고마워 :) 고스트P.talk 22:18, 2020년 11월 9일 (UTC)[]
비디오를 로컬로 다운로드한 다음 Web Archive의 템플릿에 맞게 필요한 메타데이터를 생성한 다음 거기에 자동으로 업로드하는 스크립트인 tubeup.py도 사용할 수 있다. --94.168.120 (토크) 04:51, 2021년 2월 2일 (UTC)[]

실시간 URL이 있는 인용구에 링크를 보관하시겠습니까?

안녕, 질문 몇 개.

  • 실시간 URL이 포함된 인용구에 아카이브 링크를 넣으십니까? 아니면 생략하기로 되어 있는가?
  • 이번 브룩스 브라더스 폭동의 개정에서는 인용 #2에 대해서는 인용문이 url-status=live로 설정되어 있음에도 불구하고 여전히 아카이브 링크를 먼저 표시하고 있다. 이게 정상이야? URL이 라이브일 경우 라이브 URL만 표시하거나, 둘 다 표시하되 라이브 URL을 먼저 배치해야 하지 않을까?

고마워요. 당신의 피드백을 기다리세요.Novm Languageae (토크) 00:08, 2021년 2월 12일 (UTC)[]

Novm Languageae 하루 정도 후에 여기서 답을 얻지 못하면 WP에서 다음과 같이 물어보십시오.VPT. MarnettD Talk 00:55, 2021년 2월 12일 (UTC)[]
  • @Novm Languageae: 나는 이 페이지가 현재 아카이브 링크를 제외하기 때문에 이것이 해결되지 않았다고 생각한다. 그러나 질문에 대답하기 위해 CS1 템플릿은 "아카이브-url" 매개변수가 채워지면 원래 url이 dead로 자동으로 가정하여, 사실상 "url-status=dead"를 기본값으로 설정한다. CS1 템플릿에 수동으로 "url-status=live"를 삽입하여 오버라이드해야 한다. 사이트가 죽어서 다른 사이트로 대체되는 경우(예: 도메인이 판매용이라는 광고)에는 콘텐츠가 더 이상 존재하지 않을 때 라이브로 탐지되기 때문에 이러한 현상이 자동으로 감지될 수 없다고 생각한다.

    당신이 게시한 개정판에서

    <ref name="MillerWapo">{{Cite news url=https://www.washingtonpost.com/history/2018/11/15/its-insanity-how-brooks-brothers-riot-killed-recount-miami/ title=‘It’s insanity!’: How the ‘Brooks Brothers Riot’ killed the 2000 recount in Miami first=Michael E. last=Miller work=Washington Post date=2018-11-15 archive-url=https://web.archive.org/web/20181212221657/https://www.washingtonpost.com/history/2018/11/15/its-insanity-how-brooks-brothers-riot-killed-recount-miami/ archive-date=2018-12-12}}</ref>

    CS1 템플릿에는 "url-status=live"가 포함되지 않는다. 따라서 죽은 것으로 추정하고 있다. 추가 파라미터 "url-status=live"를 삽입하면 라이브 사이트를 먼저 나열했을 것이다. -2pou(토크) 17:54, 2021년 4월 28일(UTC)[]
    2pou, 자세한 답변 고마워. 정말 고마워. 또 한 가지 빠른 질문. 라이브 링크에 대해 IABot을 실행하거나 아카이브 URL을 추가하는 것이 좋은 방법인가? 나는 지금 기사에서 이런 일이 일어나는 것을 두어 번 보았고, 지금도 링크가 살아 있으면 제거하는 사람들도 보았기 때문에 어떤 관행이 최선인지 알 수 없다. 우리의 목표는 모든 인용문을 사전 보관하는 것인가? 그게 좋은 연습이야? 아니면 링크가 죽을 때까지 기다렸다가 보관해야 할까? 고마워요.Novm Languageae(토크) 23:34, 2021년 4월 28일(UTC)[]
    Novm Languagae You는 마을 펌프에서 모든 토론을 통해 추가적인 생각을 확인할 수 있지만, 개인적으로 링크를 보관하는 것은 좋은 일이라고 생각한다. 때때로 사이트 전체가 어딘가로 이동되고, 많은 오래된 콘텐츠가 손실된다. 항상 나중에 회수할 수 있다는 것을 알고는 하지 않는 편이지만, 편집자에 따라 다르다고 생각한다. 하지만 사람들이 그것들을 없앨 수 있다는 것이 놀랍다. 나는, 그 링크된 스레드당, 많은 사람들이 GA/FA 검토를 준비하기 위해 아카이브의 모든 링크 기능을 사용한다고 믿는다. -2pou (토크) 17:49, 2021년 4월 29일 (UTC)[]

다른 자동 보관 질문

설명은 URL이 메인 스페이스 아티클에 추가될 때 링크가 자동으로 보관된다는 것을 명시한다. 이 동작이 사용자 공간 또는 초안 공간에서 기본 공간으로 이동하는 기사의 모든 링크에 전달되는지 아는 사람? 모든 링크가 메인 스페이스에 도달할 때 보관될 것인가, 아니면 기존의 메인 스페이스에 새로운 URL이 추가될 때만 메커니즘이 트리거되는가? 새로운 페이지 피드의 검토된 상태를 통해 페이지가 아직 인덱싱되지 않은 것이 문제가 되는가? (Courtesy ping @GreenC: 이전의 유사한 질문에 응답한 사람. 또한 이 질문을 하기에 가장 적합한 포럼인지 확실하지 않음...) -2pou (대화) 17:53, 2021년 4월 28일 (UTC)[]

이것은 좋은 포럼이다. 좋은 질문이야. 나는 확실히는 모른다. 하지만, 나는 그것이 메인 스페이스만을 감시한다고 믿는다. 그리고 이전에 웨이백 머신에 URL이 추가되지 않은 경우에만 트리거(테스트도 용이함). NPP를 통한 인덱싱은 해당 레벨의 사물을 인식하지 못하는 EventStream API를 사용하고 있으므로 문제가 되지 않는다.-- GreenC 21:07, 2021년 4월 28일(UTC)[]

경고! 잠재적인 검열 우려. 'Working Links' 및 작업 보관 파일을 MASS에서 삭제하는 것이 적절한 시기인용문의 URL? 더 많은 눈이 필요하며, 이에 대한 정책적 도움이 필요하다.

나는 위키피디아를 가로질러 참조에서 매우 많은 수의 URL을 삭제하는 과묵한 사용자와 상의하고 있으며, 편집 요약 사용을 거부하고 URL 및 아카이브URL을 삭제해도 괜찮다고 주장한다(예: "expect=http://www.biology.leeds.ac.uk/staff/tbt/Papers/JLTetal_TREE04.pdf archive-properties= all").https://web.archive.org/web/20060321002708/http://www.biology.leeds.ac.uk/staff/tbt/Papers/JLTetal_TREE04.pdf").

사용자는 처음에는 저작권 침해에 근거한 것으로 정당화했고, 그것이 날아가지 않자 결국 doi= 매개변수가 있기 때문이라고 말했다. DOI는 집요해야 하지만 실제로는 그렇지 않다. 그것들은 때때로 정치적인 이유로 삭제되기도 한다. 예를 들어, 주최국 정부들에게 정치적으로 당혹스러운 신문들은 부패를 폭로한다. 예를 들었지만 사용자가 가지고 있지 않다. 이것들이 MASS 삭제되는 것을 허용하지 않는 것이 중요하다. PAG가 이미 이것을 금지하고 있다면, 나는 해명 및 집행에 대한 도움을 구하고, 그렇지 않다면, 그렇게 하는 데 도움을 구하고 있다. --50.201.195.170 (대화) 21:52, 2021년 5월 4일 (UTC)[]

KDL 예시 URL이 정말 대표적이니?

내가 폐기하고 싶은 데드 링크의 종류는 KDL 섹션의 예시 URL과 같은 어떤 것보다도 훨씬 덜 복구 가능하다. 예를 들어, 대학 축구에서, EBSCO Information Services의 어떤 것에 대한 플로리다 대학교 건강 과학 센터 라이브러리 프록시 링크가 있지만, URL은 플로리다에서 누구와 접촉하든 아무도 접근할 수 없는 일부 만료된 세션 항목일 뿐이다.

Chris Capoccia 💬 22:18, 2021년 6월 3일 (UTC)[]

YouTube 목록에 없는 동영상 변경

유튜브는 채널이 달리 요청하지 않는보안상의 이유로 2017년 이전 목록에 없는 동영상에 대한 링크를 30일 만에 끊고 있다.

목록에 없는 동영상에 대한 인용문이 있는 한 기사를 알고 있다. Programadora (ref 41). 더 많은 링크가 끊어진 경우 및 이 상황에서 동영상을 보관하기 위해 수행할 수 있는 작업이 있는지 알려드리고자 한다. 삼미 브리(그녀 • t • c) 05:36, 2021년 6월 24일 (UTC)[]

아마존닷컴은 유튜브 동영상을 보관할 수 있어야 한다. 그렇지 않다면 메타데이터와 아카이브된 페이지(비디오가 없는 경우)가 있어야 하므로 목록에 없는 동영상이 발견될 경우 최소한 이 페이지를 사용하십시오.

당신의 경우, 그들은 메타데이터와 비디오를 가지고 있다: https://web.archive.org/web/20160309105430/https://www.youtube.com/watch?v=hLQkvxYPHUw. 네가 말한 기사에 링크를 추가했어.

하지만, 나는 archive.org이 특정한 비디오만 보관한다고 생각한다. 주문형 비디오를 보관할 수 있는 사이트가 곧 출시되길 바란다. Rlink2 (대화) 15:19, 2021년 9월 5일 (UTC)[]

인용 URL 상태에 대한 또 다른 질문: 사망 대 부적합으로 간주되는 것은?

인용문의 링크가 동일한 웹사이트를 가리키지만 기사 자체는 삭제된 경우, 적절한 URL-상태는 무엇인가? 나는 그것을 부적격으로 표시할지 아니면 그냥 죽은 것으로 표시할지 확실하지 않다. 아니면, 그 문제에 대해서, 내가 처음에 여기서 토크 페이지와 토크 기록 보관소를 통해 확인한 "부적합한" 것으로 중요한 것은, 그러나 나는 다른 사람이 이것을 묻는 것을 보지 못했다. 그리고 나는 이것이 디스플레이와 봇 행동에 어떤 영향을 미치는지 완전히 이해하지는 못한다. 누가 좀 도와줄래? Macks2008(대화 기여) 21:23, 2021년 7월 3일(UTC)[]이(가) 추가된 선행 서명되지 않은 논평

부적합으로 설정하면 URL이 더 이상 하이퍼링크가 되지 않는다는 한 가지 결과만 얻을 수 있다(파란색). 이것은 보통 당신이 사람들이 링크를 클릭하는 것을 원하지 않는 경우에만 이루어질 것이다. 보통 이 도메인이 스팸 발송자나 포르노 사이트에 의해 납치된 경우다. 그렇지 않으면, 404나 소프트-404(예: 같은 웹사이트에, 그러나 기사 자체는 삭제)일 경우, 사망으로 설정될 것이다. -- GreenC 00:47, 2021년 7월 4일 (UTC)[]

웹 사이트 다운?

아마존닷컴은 지금 약 1, 2주 정도 다운된 상태인가? 혹시 무슨 일이 있는지 알아봐 줄 사람? Rlink2 (대화) 20:52, 2021년 9월 2일 (UTC)[]

WP의 토크 페이지 참조:WEBCITEWebCite. -- GreenC 01:37, 2021년 9월 3일 (UTC)[]