위키백과:마을 펌프(제안서)

10년 전에 갤러리가 업데이트되었습니다.이전에는 갤러리의 유일한 옵션은 다음과 같습니다.

• 

  리푸 리

• 

  진실의 궁전에서 W. H. 켄달과 매지 켄달

• 

  데일 크릭 크로싱

이제 네 가지 다른 갤러리 모드 중에서 선택할 수 있습니다. 그 중 "포장됨"이 기본값이 되었습니다.

• 

  리푸 리

• 

  진실의 궁전

• 

  데일 크릭 크로싱

그 당시에는 매개변수가 설정되지 않은 경우 사용되는 기본 스타일이 잠시 후 패킹으로 변경될 것으로 가정했습니다.

그럼 우리는...이것에 대해 잊었습니다.

그래서, 저는 제안합니다, 아마도 봇이 추가하는 데 사용된 후에.mode=traditional잠재적인 혼란을 최소화하기 위해 나머지 모든 불특정 갤러리로 이동하여 최종적으로 포장된 기본값으로 만듭니다.포장된 이미지에 대한 기본 높이 매개변수를 200px로 설정하는 것이 좋습니다. 왜냐하면 요즘에는 그게 기본값인 것 같기 때문입니다.드물게 모드=가 아닌 갤러리가 보이고 높이는 180-250입니다.기본값은 여전히 120px로, 거의 모든 경우에서 현대의 고해상도 모니터에 비해 너무 작습니다(아래 참조).

• 

  리푸 리

• 

  진실의 궁전

• 

  데일 크릭 크로싱

Adam Cuerden 05:32, 2023년 5월 24일 (UTC) 응답 [응답]

수천 페이지를 변경하는 것이 아니라 서버 측 구성 옵션을 사용하여 변경해야 하는 것처럼 들립니다.—DJ(대화 • 기여) 2023년 5월 25일(UTC) 12:29 응답[응답]

• 기본 유형을 "포장"으로 변경하고 기본 크기를 200px로 변경할 수 있습니다.전통적인 모드는 이미지 자체의 크기를 감소시키는 큰 마진으로 끔찍하게 보입니다.90%의 경우, 기본값이기 때문에 사용된다고 생각합니다.구현의 세부 사항과 관련하여, DJ의 요점은 해당 분야에 정통한 기술자들에게 맡기겠습니다.하지만 그것에 대한 의견 차이가 우리가 전체적인 아이디어를 추진하는 것을 막아서는 안 됩니다.{{uSdkb}}:19:20, 2023년 5월 25일(UTC) 회신 [회신]
• 지원(최적의 구현 방법은 확실하지 않습니다.기한이 지난 IMO입니다.가루다3 (대화) 2023년 5월 25일 20:07, UTC 답변 [답장]
• 매우 강력한 반대입니다. 저는 이 제안에 놀랐습니다.패킹 모드가 기본값이 되었다는 것을 강력히 부인합니다.도시 등에 관한 기사는 흔하지만, 예술, 역사 등에 관한 기사는 그렇지 않습니다.몇 년 전에 여러 가지 예를 시험해 본 긴 토론이 있었는데, 특히 이미지들이 서로 충돌하고 "피를 흘리기" 때문에 이것은 일반적으로 예술을 위한 좋은 선택이 아니라는 결론을 내렸습니다.당신은 지금 기본 높이가 얼마인지 알기가 귀찮지 않나요?변경을 제안하기 전에 그렇게 하십시오.너무 작다는 것은 동의하지만 220px의 주 기본값도 마찬가지입니다.그것을 바꾸는 것이 훨씬 낫습니다.Johnbod (대화) 03:49, 2023년 5월 29일 (UTC) 응답 [응답]

  아마도 대화:Paul Signac #포장된 갤러리의 사용?Dan Cherek (대화) 03:58, 2023년 5월 29일 (UTC) 응답 [응답]

  감사합니다. 이상입니다. 아래의 Rfc 비트입니다.이것은 공식적인 Rfc(아마도 이것이 되어야 했을 것이다)였고, 그 기사에서 "포장"을 사용할 합의를 찾지 못했습니다.결론은 종종 다른 예술품으로 확장되었습니다.Johnbod (대화) 04:06, 2023년 5월 29일 (UTC) 응답 [응답]

  저는 기본값이 무엇이든 상관없습니다. 무엇이 되어야 하는지 관심이 있습니다.상황은 거의 모든 사람들이 포장 모드가 많은 상황에서 최선이라는 것에 동의하는 것처럼 보입니다.연결된 RfC에서와 같이 예술 기사의 경우, (2015년 기준) 절반 이상이 포장된 것을 선호하고 작은 이미지와 큰 마진이 있는 이전 모드를 선호하지 않는 것으로 나타났습니다.그것에 대한 어떤 것도 저에게 설득력이 없습니다.

  이 제안은 기존 기사의 갤러리 유형을 변경하지 않습니다. 예를 들어 2015년 RfC를 무시하지 않습니다.앞으로 기본값을 변경할 수 있습니다.따라서 특정 기사의 편집자들이 이미지에 더 많은 "품위"를 부여하기 위해 작은 이미지와 막대한 마진을 원한다면, 그들은 계속 그렇게 할 수 있을 것입니다.그러나 기본값은 강력하며 편집자는 기본적으로 현대식 압축 형식으로 조정되어야 합니다.{{uSdkb}}:^talk04:29, 2023년 5월 29일(UTC) 회신 [회신]

  @존보드:이것은 기사가 전통적인 스타일의 갤러리를 사용하는 것을 결코 금지하지 않을 것입니다. 실제로 저는 봇을 사용하여 현재 사용 중인 모든 갤러리에 현재 상태를 유지하기 위한 매개 변수가 없는 매개 변수를 추가할 수 있다고 제안하기도 했습니다.

  이것은 기본값이 무엇이어야 하는지에 대한 토론입니다. 예를 들어 사용자가 다른 매개 변수 없이 갤러리를 만들면 어떻게 됩니까?특정 기사에 대한 결정을 무시하기 위한 것이 아니라, 결정이 이루어지지 않을 경우 어떤 일이 발생해야 하는지를 결정하기 위한 것입니다.Adam Cuerden 19:03, 2023년 5월 29일 (UTC) 응답 [응답]

  기본 상태를 변경하면 현재 옵션이 지정되지 않은 갤러리(및 특정 옵션이 지정된 갤러리)를 사용하는 모든 아티클에 영향을 줍니다."앞으로 나아가는" 것이 아니라 회고적인 것입니다.그것이 디폴트가 의미하는 바입니다. --Redrose64 🌹 (대화) 20:42, 2023년 5월 29일 (UTC)응답[응답]

  @Redrose64, 당신은 아담이 제안서와 바로 위에 분명히 제시한 봇의 제안을 무시하고 있습니다.{{uSdkb}}:^talk20:53, 2023년 5월 29일 (UTC) 회신 [회신]

• Support Tiny는 볼 수 없는 이미지가 좋지 않습니다.과도한 마진은 좋지 않습니다.레이주르브 (대화) 6:37, 2023년 5월 29일 (UTC) 회신 [응답]
• Johnbod에 따라 반대합니다.시각 예술 페이지는 갤러리의 주요 사용자이며, Johnbod가 그가 '매우 강한 반대자'라고 말할 때 저는 그가 시각 예술 페이지를 편집하는 거의 모든 편집자들을 대변하고 있다고 생각합니다.Randy Kryn (대화) 23:47, 2023년 5월 29일 (UTC) 응답 [응답]

  @랜디 크린과 존보드:저는 두 분 모두 이 제안을 이해하지 못하고 있다고 생각합니다.이것은 현재의 기본 스타일을 허용하지 않기 위한 것이 아닙니다. 단지 <filename>을 넣을 때 기본이 되는 대신 <filename mode=filename>을 사용하도록 하는 것입니다. 기본 스타일을 변경하기 전에 사용 중인 모든 갤러리에 mode=filename을 추가하여 페이지가 변경되지 않도록 봇을 쉽게 확인할 수 있습니다.Adam Cuerden 04:25, 2023년 5월 30일 (UTC) 응답 [응답]

• 반대합니다. 저는 일반적으로 포장 모드를 좋아하지만, 포장 모드를 선택할 필요가 없는 편리함은 번거롭고 오래된 개정판의 레이아웃을 깨뜨릴 가치가 없다고 생각합니다.템플릿을 사용하면 구성을 변경하지 않고도 유사한 편리성을 얻을 수 있습니다.—Kusma (대화) 2023년 5월 30일 06:01, UTC 답변[답장]

  저는 그것이 단지 편리함에 관한 것이 아니라 오히려 콘텐츠에 영향을 미친다고 주장하고 싶습니다.편집자, 특히 모든 옵션에 정통하지 않은 최신 편집자는 대부분 기본값과 함께 사용됩니다.기존의 자이언트 마진 형식을 기본값으로 유지한다는 것은 실제로 훨씬 더 자주 사용된다는 것을 의미합니다.{{uSdkb}}:^talk2023년 5월 30일 06:11, 30일 (UTC) 회신 [회신

  기본 크기를 늘리고 새 편집자가 사용할 수 있는 많은 옵션을 설명할 수 있는 방법을 찾는 것도 괜찮습니다.Johnbod (대화) 15:02, 2023년 5월 30일 (UTC) 응답 [응답]

  새로 온 사람들에게 선택지를 더 잘 설명하기 위한 당신의 제안은 무엇입니까?{{uSdkb}}:^talk33, 2023년 5월 30일(UTC) 회신 [회신]

  저는 없는데, 다 아시는 것 같은데, 당신은 뭐예요?우리는 또한 "전통적인 갤러리"에서 크기와 모양을 만지작거리기 위한 다양한 옵션을 설명해야 합니다.Johnbod (대화) 03:12, 2023년 6월 5일 (UTC) 응답 [응답]

  저는 좋은 것이 없다고 생각합니다.우리가 덧붙이는 모든 설명은 배너 맹목에 기여합니다.새로 온 사람들에게 가장 쉬운 시스템은 기본적으로 좋은 옵션을 선택하는 것입니다.그래서 제가 그 제안을 지지하는 이유입니다.{{uSdkb}}:^talk01:55, 2023년 6월 6일(UTC) 회신 [회신]

  저는 새로운 편집자들이 다른 곳에서 찾은 것을 복사하거나 편집자의 버튼을 사용할 가능성이 높다고 생각합니다.다양한 편집기(Visual?)에 패킹 모드로 기본 설정되는 갤러리 버튼이 있습니까?저는 편집 도구 모음을 사용하지 않아서 그들이 무엇을 할 수 있는지 기억이 나지 않습니다.—Kusma (대화) 2023년 6월 5일(UTC) 22:53 응답 [응답]

  시각적 편집기에는 "옵션" 탭이 있는 대화 상자가 있으며, 여러 가지 옵션을 사용해 볼 수 있습니다.사용자 시도:WMF(What amiding)/샌드박스#갤러리의 모양을 보려면 다음과 같이 하십시오.편집창 안에 슬라이드 쇼 설정을 제외한 모든 것이 올바르게 표시되는 것 같습니다.What amiding (WMF) (talk) 03:28, 2023년 6월 6일 (UTC) 회신 [답장]

  갤러리를 봤는데 우라노스는 어디에 있나요? (제발 엉덩이 사이에 위치해 있다 같은 바보 같은 소리 하지 마세요.)감사해요.Hugums 537 (talk) 2023년 6월 15일 17:16 (UTC) 응답 [응답]

• 지원: 포장 모드가 대부분의 용도에 더 적합합니다.봇이 "mode=추가" 아트 페이지를 추가하면 영향을 받지 않습니다.실제로 현재 페이지는 모두 영향을 받지 않습니다.영향을 받는 것은 새 페이지뿐이며, 새 페이지에 기존 갤러리가 있는 것을 좋아하는 사람은 충분히 쉽게 가질 수 있습니다("모드=추가"만 추가) 작은_(smalltalk) 본즈 02:07, 2023년 6월 5일 (UTC)응답 [응답]
• 지원 기본 갤러리는 이미지를 너무 작게 만들어 접근성 문제를 발생시킵니다.포장 모드는 공간을 더 잘 사용합니다.카피맵스^{talk to me!} 2023년 6월 5일 03:01 (UTC) 회신 [회신]

  이 제안서가 "모드"와 크기라는 두 가지 문제를 혼동하는 것은 유감스러운 일입니다.아무도 모르는 것처럼 보이는 현재 기본값에서 이미지는 너무 작고 여백은 너무 큽니다.그것은 별개의 것으로 고쳐질 수 있고 고쳐져야 합니다.포장된 모드는 이미지가 단단히 고정된 상태에서 접근성 문제가 있다고 생각합니다.우리는 그 측면을 탐구해야 합니다.Johnbod (대화) 03:12, 2023년 6월 5일 (UTC) 응답 [응답]

• 댓글.WMF는 이미지 크기에 대한 프로젝트 전체의 기본값을 늘려달라는 Wikivoyage의 요청을 거부했습니다. 이는 대부분의 사용되는 이미지의 미리 보기를 만들고 저장하는 서버 부하를 증가시킬 것이기 때문입니다.이는 프로젝트별로 기본 이미지 크기를 변경할 것이 아니라 Wikimedia의 서버를 사용하는 모든 프로젝트에 대해 변경해야 함을 의미합니다.갤러리가 얼마나 흔한지는 모르겠지만, 더 큰 이미지에 대한 욕구가 갤러리에만 국한된 것은 아닌 것 같습니다.에르고, 권력이 다른 사람들에 의해 있기 때문에 실행할 수 없는 결정을 통과시키는 대신, WMF의 기술자들과 이야기하고 그들의 조언을 사용하여 앞으로 나아가야 합니다.다른 프로젝트와 언어 버전을 포함해야 하는 메타에 대한 논의도 있어야 합니다.–LPfi (대화) 2023년 6월 5일 09:43 (UTC) 회신 [회신]

  제가 알기로는 서버에서 모든 것을 한 번에 전환하는 것이 아니라 위키별로 위키를 마이그레이션하는 것이 실제로는 더 쉬울 것입니다. 작은 것부터 시작해서(=매핑 페이지/매핑 이미지).문제는 디스크 공간 자체가 아니라 모든 데이터를 한 번에 다시 분석해야 한다는 것입니다.

  또한 영어 위키백과는 큰 도전이지만, 어느 정도 사전 준비를 하면 가능하다고 알고 있습니다.상위 1,000개의 가장 인기 있는 기사(또는 상위 10K)의 모든 이미지 크기를 몇 주 전에 수동으로 목표 크기로 전환하도록 요청해도 놀라지 않을 것입니다. 하지만 그렇게 할 수도 있습니다.

  그나저나, 하나에서 다음으로 천천히 크기를 늘리는 것은 전혀 바람직하지 않습니다.기본 이미지 크기를 늘리려면 이 작업은 확실히 "밴드를 분리"하는 작업입니다.10년 후에 여러분이 원하는 규모를 생각해 보세요. 사람들이 익숙해지는 데 몇 주가 걸릴 큰 변화가 될 것이라는 것을 기억하고 바로 그것으로 전환하세요.What amiding (WMF) (talk) 19:50, 2023년 6월 5일 (UTC) 회신 [응답]

  현재(그리고 과거 수년간) "직립" 시스템을 사용하든 고정 픽셀을 지정하든 기본값을 초과하는 고정 크기는 되돌릴 가능성이 매우 높습니다.이는 MOS:IMGSIZE가 말하는 것("일반적으로 이미지는 220px(초기 베이스 폭)보다 큰 고정 폭으로 설정해서는 안 되며, 이 일반적인 규칙의 예외가 보장된다면 결과 이미지는 일반적으로 400px 너비(리드 이미지의 경우 300px)와 500px 높이를 초과하지 않아야 합니다."일반적으로 사용하는" 소형 장치에서 편안하게 표시할 수 있습니다(비록 일부 비정상적인 디스플레이에서는 여전히 보기 어려운 문제가 발생할 수 있음).") 하지만 현실입니다.그것은 우선 변화가 필요합니다.Johnbod (대화) 20:09, 2023년 6월 5일 (UTC) 응답 [응답]

  물론이야.하지만 서버가 조정될 때까지 일시적으로 설정할 수 있을 것 같습니다.다른 위키들은 과거에 기본적으로 더 큰 이미지를 얻기 위해 이 작업을 수행했으며, 우리는 여기서 독특하지만, 우리는 능력이 없는 것은 아닙니다.명백한 사람들(예: AWB 사용자)에게 경고하려면 어느 정도의 노력이 필요하지만, 모두 실현 가능합니다.명확한 편집 요약으로 실행되는 봇은 일반적으로 위키텍스트에 대한 "반직관적" 변경에 대해 작동하고, 그 다음 봇을 다시 실행하여 모든 것을 제거합니다. 300px설정을 변경할 수 있습니다.열린 질문은: 경험이 풍부한 편집자들이 변경을 요청하기를 원하느냐는 것입니다.만약 우리가 그렇게 한다면, 그들은 "아니오, 올해가 아닙니다"라고 말할 것입니다.What amiding (WMF) (talk) 03:25, 2023년 6월 6일 (UTC) 회신 [응답]

• 이 세 가지 버전은 모두 내 장치에서 기본적으로 동일하게 보입니다.상단 버전의 각 이미지 주위에는 투명한 상자가 있으며 중간 버전의 이미지는 약간 더 큽니다.저는 이 제안이 무엇을 성취하는 것을 목표로 하는지 잘 모르겠습니다.Fully Mox (talk) 05:16, 2023년 6월 6일 (UTC) 응답 [응답]

  그러면 각 이미지 주위의 투명 상자가 제거됩니다.What amidoing (WMF) (talk) 02:18, 2023년 6월 8일 (UTC) 회신 [응답]

• 기본 해상도를 높이는 강력한 지원, 그것은 제가 오랫동안 제안하고 싶었던 것입니다(200px로 괜찮습니다).120도는 깃발, 아주 단순하고 선명한 이미지의 갤러리에는 괜찮지만, 사진과 같은 세부적인 것들은 끔찍합니다.포장된 것과 전통적인 것에 대한 의견은 없습니다 - Johnbod가 지적했듯이, 저는 확실히 예술과 같은 주제에 전통적인 것을 더 잘 고려할 것입니다.하지만 저는 2-4개의 이미지로 구성된 작은 갤러리에는 "포장"이 더 낫다고 생각합니다.아니면 전통적인 갤러리가 있는 곳을 조건으로 할까요?그러나 그것은 지나치게 복잡할 것이라고 주장할 수 있습니다.SnowFire (대화) 2023년 6월 10일 16:28 (UTC) 응답 [응답]
• 지원 제안.대부분의 상황에서 기본값으로 훨씬 낫고 특정 목적을 위해 이전 버전을 원하거나 필요로 하는 전문 편집자에 의해 쉽게 덮어씁니다.Michael Maggs (대화) 16:38, 2023년 6월 10일 (UTC) 응답 [응답]
• Johnbod와 출혈/충돌 문제에 대해 반대합니다.저는 이것을 했습니다.현재 기본값에는 이 문제가 없습니다.그것은 절충입니다.현재의 것은 포장된 것만큼 시각적으로 예쁘지는 않지만, 더 안정적입니다.Hugums 537 (talk) 2023년 6월 15일 17:53 (UTC) 회신 [답장]

위키백과 강연에서 몇 가지 논의가 있었습니다.위키프로젝트 도시들은 이에 대해 언급했지만, 도시 밖의 많은 기사들이 이에 영향을 받을 것이기 때문에 저는 여기 제안이 더 적절하다고 생각했습니다.현재 정보 상자의 {{multiple image} 갤러리에 캡션을 넣는 두 가지 옵션이 있습니다.

• 

  옵션 1, 이미지당 캡션

• 

  옵션 2, 바닥글의 캡션

모든 기사가 정보 상자에 캡션을 배열하기 위해 어느 쪽이든 따르도록 강요하는 것은 현명하지 않지만, 특정 상황에서 어떤 옵션이 선호되는지에 대한 합의가 있을 수 있다고 생각합니다.

두 가지 접근 방식의 장점은 다음과 같습니다.

옵션 1

• 이해하기 쉬운 캡션 배치, 어색한 "시계 방향으로" 캡션이 필요 없음
• 편집자가 유지보수가 용이함

옵션 2

• 특히 다중 줄 캡션의 경우 더 작고 덜 귀중한 세로 공간을 차지합니다.
• 사용자 지정 갤러리 사용 허용

선인장 스태킹 크레인 (토크) 2023년 5월 25일 08:02, UTC 답변 [답장]

Wiki Project City 토론에서 사용자에게 핑:Dkriegls, Sdkb, 무기화 아키텍처, XerorCactiStacingCrane (대화) 08:06, 2023년 5월 25일 (UTC) 응답 [응답]

무엇을 하든 좁은 화면(적어도 일부 스킨에서는)에서 "왼쪽 위에서 시계 방향"이 잘못되기 때문에 피하십시오.—Kusma (대화) 2023년 5월 25일(UTC) 11:53 응답 [응답]

또한 접근할 수 없습니다.항상 실제 순서를 사용합니다.—DJ(대화 • 기여) 2023년 5월 25일(UTC) 12:32, 답변[응답]

"실제 순서"란 무슨 뜻입니까?동적으로 변경할 수 있다면 좋지 않다는 것을 이해합니다(하지만 잠재적으로 어떤 설명이든 문제가 될 수 있습니다(예: 세 줄의 두 줄이 두 줄의 세 줄이 되는 것). 하지만 변경할 수 없다면(예: 단일 이미지 파일) "시계 방향"에 문제가 있습니까?트뤼두울프 (대화) 13:14, 2023년 5월 25일 (UTC) 응답 [응답]

이러한 영상의 순서(문서에서)는 각 라인에 대해 왼쪽에서 오른쪽으로, 위쪽에서 아래쪽으로 표시됩니다.(서양식) 책처럼.시계 방향은 왼쪽에서 오른쪽으로, 위에서 아래로, 오른쪽에서 왼쪽으로, 그리고 아래에서 위로 가는 시각적 설명입니다.화면 판독기는 문서 순서만 전달하고 모바일과 같은 다양한 시각화에서 순서를 다시 지정할 수 없기 때문에 문서 순서와 일치하지 않으므로 사용해서는 안 됩니다.—DJ(대화 • 기여) 2023년 5월 25일 14:46(UTC)응답[응답]

당신이 쓴 글을 읽는 데 몇 번이 걸렸지만, 이제 이해가 갑니다.감사해요.트뤼둘프 (대화) 20:57, 2023년 5월 27일 (UTC) 회신 [회답]

• 이것은 WP:GALLERY와 반대로 너무 많은 장식 이미지를 정보 상자에 채우는 기능으로 보입니다.둘 중 하나보다 더 나은 선택은 애초에 문제를 만들지 않는 것입니다.CMD (대화) 11:32, 2023년 5월 25일 (UTC) 회신 [회답]
  • 저도 대체로 동의하지만, 당신은 사람들이 매우 자주 그러하듯이 WP:GALLERY를 잘못 읽고 있습니다.Johnbod (대화) 02:25, 2023년 5월 28일 (UTC) 응답 [응답]

    잘 읽고 있습니다, 감사합니다. CMD (talk) 02:28, 2023년 6월 5일 (UTC) 회신 [답장]

• 뉴욕시에는 10개의 작은 정보 상자 이미지가 있습니다.네 개의 캡션이 두 줄로 넘치고 각 줄 아래에 빈 줄이 하나 더 있습니다.갤러리에서만 7인치 스마트폰에서 두 개 이상의 화면을 사용할 수 있습니다(독자의 60%가 모바일에서 발생).이 경우 캡션 하나, 이미지 최대 3개가 권장됩니다.포노르 (대화) 11:55, 2023년 5월 25일 (UTC) 답장 [답장]

  NYC는 2023년 5월 25일 12:00 (UTC) 답변[답장]에서 무기화 아키텍처를 단축해야 합니다.

  개인적으로 저는 스카이라인 사진으로 충분하다고 생각합니다.하지만 사람들은 계속해서 도시의 스카이라인이 같다고 주장했습니다. 그러니 정보 상자에 주목할 만한 장소를 추가해보죠.그리고 또 다른, 또 다른, 그리고 또 다른...선인장 스태킹 크레인 (토크) 12:04, 2023년 5월 25일 (UTC) 회신 [답장]

  저는 개인적으로 옵션 2를 선호합니다.저는 이해하는 것이 너무 어렵다고 생각한 적이 없습니다(이것은 다른 사람들에게는 다를 수도 있습니다). 그리고 저는 그것이 정보 상자를 훨씬 더 깨끗하게 보이게 한다고 믿습니다(캡션과 아래에 있는 이미지 사이에는 눈에 띄는 간격이 있습니다).2023년 5월 25일 12:08, 내게 고함치는 무기화 건축물 (UTC) 응답 [응답]

• 저는 (OP가 지적한 것처럼) 어떤 것이 더 나은지는 특정 상황에 따라 다르기 때문에, 우리가 두 가지 옵션 외에 다른 것을 말하는 것을 왜(또는 필요로) 원하는지 이해할 수 없습니다.어떤 상황에서 하나가 정말 선호된다면(그리고 OP는 예를 제시하지 않는다), 이미 선호되기 때문에 우리는 지침이 필요하지 않습니다.트뤼둘프 (대화) 12:08, 2023년 5월 25일 (UTC) 회신 [회답]

  물리학이나 고대사 같은 넓은 개념의 기사들이 갤러리가 말하는 주제가 너무 광범위해서 갤러리를 이용하는 기사들이 많기 때문에 그렇게 말한 것입니다.이 기사들은 도시 기사의 갤러리에 대한 합의와 동일하게 취급되어야 합니까?선인장 스태킹 크레인 (토크) 12:13, 2023년 5월 25일 (UTC) 회신 [응답]

  저는 당신이 제 의견을 오해했다고 생각합니다. 저는 한 주제 영역에 대한 합의가 다른 주제 영역에 적용되어야 한다고 말하는 것이 아니라, 실제로는 정확히 반대입니다. 사이트 전체 지침은 단순히 두 가지 옵션 중 하나가 허용된다고 명시해야 합니다.서로 다른 유형의 기사가 가장 일반적으로 동일한 옵션을 사용하는지 다른 옵션을 사용하는지 여부는 전혀 중요하지 않으며, 어떤 옵션이 해당되는지도 마찬가지로 중요하지 않습니다.대부분의 도시 기사가 옵션 1과 같은 옵션 1을 사용하는 경우, 도시 기사에 옵션 1이 선호된다고 말할 필요가 없습니다. 현재 상황이기 때문입니다.특정 도시 기사가 옵션 2를 사용하지만 누군가가 옵션 1을 사용하는 것을 선호한다면 대담해지거나 대화 페이지에서 변경을 제안하십시오.트뤼두울프 (대화) 12:30, 2023년 5월 25일 (UTC) 회신[답장]

  확실히 그렇지 않습니다. 특히 만약 그것이 실제로 좋은 생각이 아닌 곳에 그러한 이미지를 포함하도록 압력을 의미한다면 더욱 그렇습니다.Chemistry 기사는 현명하게도 관련성이 있는 이미지로 시작하는 것을 피하고, Physics 기사는 기사의 내용을 말하기도 전에 설명되지 않은 예제 이미지(적어도 내 전화기에 있음)로 가득 찬 화면을 표시하며, 리드 이미지가 없는 것이 더 나을 것입니다(개인적인 의견).모든 위키백과 문서에 걸쳐 이를 통합하는 것은 기껏해야 헛수고이지만, 더 적극적으로 해로울 가능성이 높습니다.—Kusma (대화) 2023년 5월 25일 13:57, UTC 답변[답장]

• 도시는 다른 많은 기사들보다 정보 상자 콜라주에 더 적합하지만, 종종 형편없이 수행되고 너무 많은 이미지로 가득 찬 경우가 있습니다.저는 상황에 따라 펌프에서 우리가 할 일이 없다는 트뤼둘프의 말에 동의합니다.그러나 옵션 1이 차지하는 추가 공간은 특히 이미 너무 긴 정보 상자(갤러리가 있는 많은 정보 상자와 마찬가지로)의 경우에는 비용이 많이 듭니다. 예를 들어 다른 도시가 아닌 동일한 도시를 사용하는 경우 콜라주를 얼마나 더 길게 만드는지가 더 분명합니다.어떤 옵션이 더 나은지에 영향을 미칠 수 있는 다른 요인은 이미지가 얼마나 명확한지, 따라서 독자가 캡션을 찾을 가능성이 얼마나 높은지(가능성이 매우 높은 경우 옵션 1이 더 좋을 수 있음), 그리고 대부분의 장치에서 한 줄로 모든 캡션을 줄일 수 있는지 여부입니다.또한 옵션 1의 추가적인 단점으로, 저는 콜라주의 시각적 응집력을 파괴하는 방법을 좋아하지 않습니다.
  그리고 제가 지난 토론에서 말했듯이, 저는 궁극적으로 포장된 갤러리 태그 옵션처럼 맴도는 캡션이 우리에게 두 세계의 장점을 제공할 수 있다고 생각합니다.{{Multiple image}}에 대해 작동할 수 있는 방법이 있습니까?{{uSdkb}}:^talk2023년 5월 25일(UTC) 18:04, 회신 [회신]

  콜라주와 관련하여 제가 정말 신경 쓰는 한 가지는 이미지 세트를 수정하는 것을 더 어렵게 만들기 때문에 단일 파일만 사용하지 않는다는 것입니다(예: 더 나은 새로운 옵션을 사용할 수 있게 되거나 삭제되는 경우).이미지를 클릭하면 전체 화면이 표시되지 않고 콜라주가 전체 화면으로 표시됩니다.{{uSdkb}}:^talk18:09, 2023년 5월 25일(UTC) 회신 [회신]

  이렇게 하면 모바일과 인쇄 호환성이 깨질 것 같습니다.내 말이 맞습니까?선인장 스태킹 크레인(토크) 2023년 5월 30일 15:03, 30일(UTC) 회신[답장]

  짐 싸는 생각을 말씀하시는 건가요?Packed-hover는 현재 모바일의 "Packed-overlay"로 표시됩니다.기능을 잘 설계했다면 이러한 문제를 해결할 수 있었을 것입니다.{{uSdkb}}:^talk19, 2023년 5월 30일 (UTC) 15:19, 30일 (UTC) 회신 [회신]

  네, 그래요.하지만 인쇄 매체에 있어서는 이것이 이상적이지 않습니다.선인장 스태킹 크레인(토크) 2023년 5월 30일 15:26, 30일(UTC) 회신[답장]

• 콜라주/모시즘을 완전히 피하거나 크게 줄입니다.Johnbod (대화) 02:25, 2023년 5월 28일 (UTC) 응답 [응답]

  이런 종류의 이미지 축소를 장려해야 합니다.Moxy- 11:19, 2023년 5월 29일 (UTC) 회신 [회신]

• 특히 정보 상자에 대해서는 Johnbod와 Moxy의 의견에 동의합니다.일반 갤러리는 괜찮습니다_(smalltalk) 스몰본즈 02:13, 2023년 6월 5일 (UTC) 회신 [답장]

  11개의 파일이 선두에 있는 디트로이트와 같은 기사는 스크롤 악몽입니다.뉴욕시는 더욱 심각합니다.....4개의 정보 단락에 대해 15개의 파일을 스크롤해야 하므로 산문이 나오기 전에 3번 스크롤해야 합니다.. 대부분은 이동하기 전에 첫 번째 단락을 읽지도 못할 것입니다. - dataMoxy- 02:12, 2023년 6월 6일 (UTC)응답[Reply]

• 옵션 1이 더 낫습니다. 독자들이 그것을 알아내려고 애쓰지 마십시오.저는 또한 적은 이미지가 아마도 좋은 생각일 것이라는 것에 동의합니다. SMC Candlish ☏ ¢ 😼 2023년 6월 7일(UTC) 06:21 답변[회신]
• 옵션 1 - 몇 달 전에 이 디자인을 소개받았는데 동의합니다. 이 디자인이 가장 좋은 옵션입니다.네, 2번 옵션이 더 컴팩트하지만 어느 것이 어느 것으로 가는지 찾아서 찾기 때문에 혼란이 발생합니다.하단에 파란색 링크가 많이 있는 것보다 이미지 바로 아래에 캡션이 있는 것이 더 이치에 맞습니다.좋은 하루 되세요!DiscoA340 (토크) 2023년 6월 15일 19:30 (UTC) 회신 [답장]
• 댓글:저는 이 선호도에 대해 관료적 디폴트 옵션을 결정하는 것에 반대합니다.계속해서 결정하는 것은 편집자들에게 맡기세요.이러한 문제가 있는 기사에 대한 반발이 있다면 소유권 문제가 발생할 수 있는 것처럼 들리거나 편집자들이 문제라고 부르는 것이 실제로 문제가 아니라고 생각할 수도 있습니다.Hugums 537 (대화) 20:30, 2023년 6월 15일 (UTC) 회신 [답장]

최근에 archive.org 으로 전송된 인터넷 링크에 액세스하려고 할 때 바보 같은 오류를 범했습니다. "원본"이라는 단어를 클릭하면 인용문을 가져온 원본 문서로 이어질 것이라고 생각하고 링크가 작동하지 않는다는 인상을 받았습니다.데드 링크가 작동 중인 링크와 동일한 형식으로 표시되는 것은 오해의 소지가 있다고 생각합니다.위키백과 프레젠테이션에 능숙하지 않은 사용자의 이익을 위해, 이러한 링크를 구현하는 템플릿을 수정하여 파란색이 아닌 빨간색으로 "원본"이라는 단어를 표시하고 다른 데드 링크와 유사하게 할 수 있습니까?저를 혼란스럽게 한 특정 링크는 "스킨워커 랜치" 기사의 "비판" 섹션에 있는 제임스 랜디 링크 11입니다. 203.221.25.134 (talk) 17:57, 2023년 6월 7일 (UTC) 답변 [응답]

빨간색은 존재하지 않는 위키백과 페이지에만 사용됩니다. 예를 들어, 해당 문서는 없습니다.다른 사이트에 대한 외부 링크는 항상 파란색이며, HTTP 404 페이지 또는 아무 내용도 반환하지 않습니다.외부 사이트는 방문자의 위치, 로그인 상태, 시간 또는 선택한 시간에 따라 이 응답을 변경할 수 있습니다.슬프게도, 위키피디아가 그러한 모든 변화를 추적하는 것은 비현실적일 것입니다.Certes (대화) 18:17, 2023년 6월 7일 (UTC) 응답 [응답]

인용문 템플릿 내에서 텍스트 메트릭을 변경하는 것이 완전히 비현실적이라고 생각하지 않습니다. url-status=원본에 대한 링크가 링크 제목의 대상인지 여부를 이미 결정합니다(url-status=live), "원본과 일치하는" 텍스트에서 "원본"의 대상(url-status=dead), 또는 전혀(url-status=usurped또는unfit) url-status 상태가 언제 변경되는지 추적할 수는 없지만 해당 매개 변수를 사용하여 인용 템플릿이 이미 실행 중인지 확인할 수 있습니다.Fully Mox (대화) 19:16, 2023년 6월 7일 (UTC) 응답 [응답]

예. 이 예들을 비교해보면, 그들 사이의 유일한 차이점은 전달된 값입니다. url-status=:

1. British Transport Commission (1963). "The Reshaping of British Railways – Part 1: Report". Her Majesty's Stationery Office. Archived from the original on 19 October 2010. Retrieved 25 November 2006 – via The Railways Archive.

   이거는. url-status=live제목은 원래 웹 페이지에 연결되고, "보관됨"이라는 단어는 보관 사이트의 페이지에 연결됩니다.원래 페이지가 인용된 내용을 계속 지원하지만 미리 보관된 경우에 사용됩니다.

2. British Transport Commission (1963). "The Reshaping of British Railways – Part 1: Report". Her Majesty's Stationery Office. Archived from the original on 19 October 2010. Retrieved 25 November 2006 – via The Railways Archive.

   이거는. url-status=dead,그렇지만 url-status=deviated그리고. url-status=파라미터를 생략하는 것과 동일하게 동작합니다.제목은 보관된 웹 페이지에 연결되고 "원본"이라는 단어는 원래 웹 페이지에 연결됩니다.

3. British Transport Commission (1963). "The Reshaping of British Railways – Part 1: Report". Her Majesty's Stationery Office. Archived from the original on 19 October 2010. Retrieved 25 November 2006 – via The Railways Archive.{{cite web}}CS1 유지 관리: 부적합한 URL(링크)

   이거는. url-status=unfit,그렇지만 url-status=usurped동일하게 동작합니다.제목은 보관된 웹 페이지에 연결되어 있지만 원래 웹 페이지에 연결되어 있지 않습니다.원래 URL이 스팸, 광고 등의 목적으로 도용되었거나 적합하지 않은 경우에 사용됩니다.

어떤 것을 사용하느냐는 주로 원본 페이지의 링크를 따라가면 어떻게 되는지에 따라 달라집니다. --Redrose64 🌹 (talk) 21:47, 2023년 6월 7일 (UTC)응답[답장]

그렇다면, 예 2에서 "원본"을 빨간색 링크로 만들 것인지 여부에 대한 질문입니까?만약 그렇다면, 답은 무엇입니까?원한다면 그렇게 어렵지 않게 들립니다. ("빨간색"은 "실종된 대상이 있는 링크에 대해 독자가 선택한 스타일로"라는 뜻이며, 실제로 빨간색이 아닌 형광 라임이나 청각적 단서일 수 있습니다.)Certes (대화) 2023년 6월 7일 22:08, UTC 답변 [답장]

저는 그것이 질문이라고 믿지만, 저는 대답이 아니라고 생각합니다.빨간색이지만 클릭할 수 있지만 다양한 상태의 웹 사이트로 이어질 수 있는 외부 사이트에 대한 링크는 의미론적으로 의미가 없습니다.더 나은 해결책은 더 많은 URL을 부적합(또는 다른 단어)으로 태그하거나, 비활성(dead)으로 표시될 때 원래 URL에 대한 링크를 표시하지 않는 것(즉, 부적합과 동일)일 수 있습니다.하지만 매우 똑똑한 사람이 문제를 다시 생각해 보기 전까지는 현재의 시스템은 괜찮다고 생각합니다.최악의 경우, 사용자는 URL이 애초에 "원본에서 보관"된 이유를 알고 돌아와 제목 링크를 클릭해야 합니다. 아마도 원본은 어떤 이유로 보관이 필요했을 것입니다.HTGS (토크) 12:27, 2023년 6월 8일 (UTC) 회신 [답장]

지금까지 이 요청에 대해 언급한 모든 사람은 예 2와 같은 링크에서 서로 다른 파란색 텍스트 블록 간의 차이를 깨닫기 위해 의식적으로 생각할 필요조차 없는 오랜 WP 사용자라고 확신합니다(그리고 제가 이전에 전혀 알지 못했던 차이를 깨닫게 해준 설명에 감사드립니다).

그러나 그러한 링크의 시작 부분에 있는 세부적인 파란색 텍스트는 문서의 세부 내용에 대한 일종의 공식적인 진술일 뿐이라는 잘못된 인상을 가질 수 있는 미숙한 사용자의 상황에 무게를 두시기 바랍니다.그리고 "원본"이라는 간결한 단어(파란색으로 표시되고 WP의 다른 유효한 링크와 동등한 것으로 보임)가 원본 문서에 도달하는 방법입니다.이러한 오해를 가진 사람은 "다른 링크를 클릭하기만 하면 된다"는 것을 깨닫지 못하고 링크가 끊어졌다는 믿음을 가질 수 있습니다.

위의 이전 의견을 읽고 이전에 저를 혼란스럽게 했던 단계를 거치는 것에 대해, 저는 이제 색깔을 바꾸는 것이 최선의 선택이 아닐 수도 있다고 생각합니다(빨간색을 사용하고 싶지 않다면, 갈색은 적절한 인상을 주는 것 같습니다). 그러니 아마도 "원래 링크"라고 말하도록 문구를 변경해 주시겠습니까?원본 링크임에도 불구하고 원본 문서로 이어지지 않을 수 있음을 더 잘 제안하기 위해 194.193.133.100 (대화) 2023년 6월 9일 (UTC) 17:26, (전 203.221.25.134) 회신 [회신]

이 제안에 대한 추가적인 언급은 없었고, 명시적인 수용 또는 거부도 없었습니다.그냥 관심 부족으로 죽는 것일까요?나의 마지막 의견:사례 2 참조에서 "원본"에 "링크"라는 단어를 추가하는 것은 사소한 프로그래밍 작업이 될 것이며, 시스템의 지속적인 운영에 전혀 무시할 수 있는 추가적인 부하가 될 것이며, 현재와 같은 방식으로 보는 것에 익숙한 장기 사용자들의 감성에 작은 부담이 될 뿐이라고 생각합니다.그리고 신규 사용자의 오해를 줄이는 데 작지만 긍정적인 기여, 즉: 여전히 할 가치가 있다고 생각합니다. 124.170.20.251 (talk) 06:50, 2023년 6월 18일 (UTC) (전 203.221.25.134)응답 [응답]

안녕하세요! 제가 개발 중인 새로운 장치를 활성화하는 것을 제안하고 싶습니다.기본적으로 단락 옆에 작은 연필 아이콘을 추가합니다. 이 아이콘을 누르면 페이지를 떠나지 않고 단락 대신 작은 편집기를 로드합니다.mw 참조:데모 비디오를 포함한 중앙 문서에 대한 WikiEdit 또는 다음을 common.js 또는 global.js에 추가하여 테스트합니다.

mw.로더.짐을 싣다( '//www.mediawiki.org/wiki/MediaWiki:WikiEdit.js?action=raw&ctype=text/javascript' ); 

가젯은 스페인어 위키백과에서 이미 활성화되어 있습니다.향후 버전에서는 목록 항목, 표 셀, 이미지 캡션 및 대화 응답을 편집할 수 있도록 확장하고 싶습니다.지원?이의 있습니까?Sophivorus (대화) 11:56, 2023년 6월 8일 (UTC) 응답 [응답]

이미 특정 섹션을 편집할 수 있는 버튼을 추가할 수 있는 옵션이 있다는 점을 고려하면 불필요할 수도 있지만, 제가 틀릴 수도 있습니다. - Aquila Fasciata (대화 기여) 17:38, 2023년 6월 9일 (UTC) 회신 [Reply]

@소피보루스 예: 기사.커리어 ==에는 파라1, 파라2, 파라3의 3가지 파라가 있습니다.이 장치가 커리어 섹션/헤드라인의 3가지 파라 모두에 연필 버튼을 추가한다는 뜻입니까? 저는 현재 커리어 섹션/헤드라인에는 연필 버튼이 하나밖에 없다고 생각합니다.2023년 6월 12일 (UTC) 15:55, 회신[회답]

@Aquila Fasciata 예, 하지만 새로운 연필 아이콘은 섹션 편집 인터페이스를 로드하지 않습니다.그것은 정말 불필요한 것입니다.대신, 페이지를 다시 로드하지 않고 문단 대신 작은 편집기를 로드합니다.mw에서 비디오를 확인합니다.위키 직접 확인할 수 있도록 common.js 또는 global.js에 코드를 편집하거나 추가합니다.Sophivorus (대화) 2023년 6월 12일 16:08, UTC 답변 [답장]

아, 그렇군요.좋은 생각이에요!그렇다면 나도 승선할 거야! - 아퀼라 파시아타 (토크 기고) 17:26, 2023년 6월 12일 (UTC) 회신 [답장]

사용자를 떠올리게 함:브랜든 XLF/빠른 편집. Qwerfjktalk 20:19, 2023년 6월 12일 (UTC) 회신 [답장]

@소피보루스 이 장치가 커리어 섹션/헤드라인의 3개 파라 모두에 연필 버튼을 추가한다는 뜻입니까?스크린샷 참조 [내가 의미한 것은 그림에 표현됨]:

Wikiedit 스크린샷: 각 단락의 연필 아이콘 [녹색 원]

@Qwerfjkl 빠른 편집도 같은 일을 하나요?2023년 6월 13일 (UTC) 02:14 (talk) Reply [reply]

@파일:빠른 편집 스크린샷.png. Qwerfjktalk 11:11, 2023년 6월 13일 (UTC) 응답 [응답]

@예, 스크린샷에서 볼 수 있듯이 가젯은 섹션의 세 단락 모두에 연필 단추를 추가합니다.@Qwerfjkl 가젯은 실제로 QuickEdit과 유사하지만(사실 나는 먼저 QuickEdit이라는 이름을 붙일 생각이었다) 더 정확하게 편집할 수 있습니다(섹션별 대신 단락별, 곧 목록 항목별, 회신별 등).Sophivorus (대화) 12:31, 2023년 6월 13일 (UTC) 응답 [응답]

• 저는 지금 그것을 며칠 동안 먹어봤는데, 꽤 마음에 들어요!사소한 수정을 가속화하고 간단한 인터페이스를 제공합니다.Edward-Woodrow :) 2023년 6월 14일 22:35 (UTC) 회신 [회신]
• 이것은 저처럼 철자 오류를 많이 범하는 사람들에게 좋은 도구가 될 것 같습니다. 그들은 그것을 고쳐야 합니다.조금만 사용하면 피드백을 받을 것입니다.캡틴 잭 스패로우 (대화) 10:42, 2023년 6월 16일 (UTC) 응답 [응답]

  예비 피드백 - 이것은 잘 작동하지만, 대화 페이지 설명에도 추가하는 것이 훨씬 좋습니다.캡틴 잭 스패로우 (대화) 10:48, 2023년 6월 16일 (UTC) 응답 [응답]

안녕하세요, 저는 G 마이너의 키인데 사람들이 페이지를 제안할 수 있는 내부 페이지를 제안하려고 합니다.WP:NPOV를 깨지 않으려는 것, 어떻게 해야 할지 모르는 것(제한된 정보 또는 지불 요구 사항, AFC 프로세스에 대한 제한된 지식) 등과 같은 다양한 이유가 있을 수 있습니다.프로세스는 다음과 같습니다.

1. 사용자가 제안 항목을 입력합니다.
2. 이를 중심으로 논의가 진행됩니다.
3. 편집이 합의에 따라 시작되거나 시작되지 않습니다.이 과정에서 유용성에 대한 논의가 다시 한 번 제기될 수 있습니다.유용한 경우 편집을 다시 시작합니다.그렇지 않으면 편집이 중지됩니다.
4. WP:AFC를 거치거나 기사의 품질 여부에 대한 논의를 거칩니다.
5. 그렇다면 게시됩니다.그렇지 않으면 편집이 재개되거나 중지됩니다.

제 제안서를 읽어주셔서 감사하고 좋은 하루 보내세요.키 오브 지 마이너 (대화) 18:18, 2023년 6월 12일 (UTC) 회신 [회답]

위키피디아처럼 말이죠.요청된 기사?돈 이아고 (대화) 19:26, 2023년 6월 12일 (UTC) 회신 [회답]

RA에서 드래프트로 가는 도구 지원 프로세스가 있다면 흥미로울 수 있습니다(누구든 관심을 잃고 드래프트가 G13'ed가 되면 RA로 다시 돌아갑니다).잠재적인 참고 자료를 수집하고 정리하여 유용성에 대한 평가를 추적할 수도 있습니다.하지만 후반부는 과도한 스코프 크리프일 수 있습니다.알파 3031 (t • c) 13:55, 2023년 6월 13일 (UTC) 회신 [회신]

주제에 대한 기사를 작성해야 하는지에 대한 논의의 범위에 적합한 출처 식별이 필수적이라고 생각합니다.AfD처럼 역으로?Fully Mox (대화) 18:08, 2023년 6월 13일 (UTC) 회신 [회답]

네. 대부분의 초안은 한 사람이 모든 작업을 수행하는 반면, 일종의 협력적인 것일 것입니다.이 과정을 통해, 그것은 여러 사람들에게 분산됩니다.진심으로, G단조의 키.^Tools: (토크, 기여) 18:50, 2023년 6월 13일 (UTC) 회신 [응답]

일종의, 내 생각에.하지만 그것은 더 협력적입니다.진심으로, G단조의 키.^Tools: (토크, 기여) 2023년 6월 13일(UTC) 18:51 응답 [응답]

저는 이것이 잠재적으로 좋은 위키백과가 될 수 있다고 생각합니다.Wiki 프로젝트.얼마나 많은 사람들이 관심을 가질지는 모르겠지만, IMO를 시도해 볼 가치가 충분히 있습니다.알파 3031 (t • c) 13:12, 2023년 6월 14일 (UTC) 회신 [회신]

이미 위키백과가 있습니다.개선을 위한 기사, 아마도 협업 제도에 관심이 있을 것입니다. CMD (대화) 13:25, 2023년 6월 14일 (UTC) 회신 [답장]

최근에 저는 퍼커션 카테고리와 하위 카테고리의 기사에 많은 짧은 설명을 추가했습니다.그것은 오랜 시간이 걸렸고 힘든 과정이었습니다.오늘 저는 UrbanBot을 만들었고 이 문제를 해결하기 위해 Pywikibot에 코드를 썼습니다.이 아이디어는 봇 운영자(나)가 범주와 짧은 설명을 지정하고 봇이 범주에 없는 모든 기사에 짧은 설명을 작성한다는 것입니다.따라서 봇은 반자동입니다.소스 코드는 여기 깃허브에 있습니다.위키백과에서 요청을 제출하기 전에 여기에 이것을 넣고 싶었습니다.봇/승인 요청.이 아이디어에 대한 팁이나 정보를 주시면 감사하겠습니다.감사합니다, Urban Versis^KB 32 ⚡ 2023년 6월 12일 19:41 (UTC) 회신 [답장]

• @Urban Versis 32, 제가 알기로는 이 봇이 Wikidata를 편집하므로 Wikidata에 대해 논의해야 합니다. Qwerfjktalk 11:12, 2023년 6월 13일 (UTC) 회신 [답장]

  그럴지도 모르지만, 봇이 작동하는 방식은 영어 위키백과에 있는 기사의 범주를 기반으로 한 짧은 설명을 기사에 추가하기 때문에 아마도 위키백과에 더 적합할 것입니다.제가 놓친 게 있다면요?저는 위키백과 봇을 처음 접하지만, 제가 알기로는 위키데이터의 영어 기사 카테고리에 액세스하는 것이 불가능합니다.Urban Versis^KB 32 ⚡ 2023년 6월 13일 17:49 (UTC) 회신 [회신]

  @Urban Versis 32, 코드는 다음을 사용합니다.

  페이지입니다..편집설명({위치.랑그: 단신의}, 요약='UrbanBot 과제 1 - 간단한 설명 추가') 

  그러면 엔위키가 아닌 위키데이터가 편집됩니다. Qwerfjktalk 18:57, 2023년 6월 13일 (UTC) 회신 [회신]

  오, 알았어, 내 잘못.저는 봇이 위키백과를 기반으로 할 것이라고 생각했는데, 영어 위키백과에서 범주 정보만 가져올 뿐 실제로 위키데이터를 편집하기 때문에 봇이 위키데이터를 기반으로 할 것이라는 것이 더 말이 됩니다.정보 감사합니다!Urban Versis^KB 32 ⚡ 20:21, 2023년 6월 13일 (UTC) 회신 [회신]

이런 종류의 다른 옵션은 텍스트 파일을 만드는 것입니다.

제인 앤 기어 영국의 외발자전거 선수

후안 휠러 스페인 외발자전거 선수

JWB의 기사 목록으로, ^을 {{짧은 설명 $x}}(으)로 대체합니다.(JWB는 $x를 파이프 뒤의 텍스트로 대체합니다.)Certes (대화) 12:55, 2023년 6월 13일 (UTC) 회신 [답장]

이것은 사실 제안서는 아니지만 요청서를 어디에 올려야 할지 모르겠습니다.기사 삭제 토론에 참여하려면 관리자 몇 명과 숙련된 편집자 수십 명이 더 필요합니다.현재, 제가 대단히 감사하게 생각하는 소수의 단골들이 있지만, 그들은 프로젝트에서 어떤 기사가 보관되거나 삭제되는지에 대해 엄청난 영향력을 가지고 있습니다.추천 및 추천에 동의하는 편집자 한 명을 기준으로 기사를 삭제할 수 있습니다.우리는 그들이 그 프로젝트에 어떤 기사가 실릴 만하다고 생각하는지에 대해 더 많은 편집자들로부터 들을 필요가 있습니다.우리는 또한 AFD에 참여하기 위해 많은 새로운 편집자들과 양말 인형들이 등장하는 것을 보아왔고 그들의 경험 부족이나 그들의 가짜가 항상 최종적으로 명백한 것은 아닙니다.토론 중인 주제와 관련 출처에 대해 알고 있는 훌륭한 콘텐츠 제작자들이 너무 많은데 수십 개의 편집을 한 편집자들이 기사의 삭제를 저울질하는 것은 실망스러운 일입니다.저는 AFD가 참여해야 하는 긴장된 영역이 될 수 있고 시간과 노력의 투자가 수반될 수 있다는 것을 알고 있지만, 일주일 또는 그 이상의 몇 가지 토론에 여러분의 참여를 정말로 사용할 수 있습니다.삭제 정렬 항목 중 하나를 따라 관심 있는 항목에 초점을 맞춥니다.어느 정도의 지원을 고려해 주셔서 감사합니다.리즈^{Read! Talk!} 2:42, 2023년 6월 14일 (UTC) 회신 [회신]

이 호소는 제가 2022년 1월부터 AFD 분야에 참여한 경험을 바탕으로 한 것임을 명시해야 합니다.예전에는 이 분야에 더 많은 편집자들이 참여했던 것처럼 보이지만, 그들은 이미 녹초가 되었을 수도 있습니다.우리는 그들과 새로운 피가 필요합니다!리즈^{Read! Talk!} 2:44, 2023년 6월 14일 (UTC) 회신 [회신]

이 스레드의 존재는 AfD 논의에 대한 논의가 있다는 점을 감안할 때 아이러니합니다. 2005년부터 관리자를 맡고 있는 선의의 참가자들 중 한 명은 "AfD에서 파괴적으로 참여하는 것을 중단해야 한다"는 것이 중요합니다. (제가 말할 수 있는 한,)그 사람들은 그들의 추정된 "공격적인" 행동이 논의 중이었다는 사실에 대해 경고를 받지 않은 것으로 보입니다.)Gnomingstuff (대화) 2023년 6월 15일 03:11, UTC 답장 [답장]

네, 알겠습니다. 곧 제외하겠습니다. jp×g 2023년 6월 16일 (UTC) 07:33, 회신 [회신]

Wikipedia에서 토론에 참여해 주시기 바랍니다.Wiki 프로젝트 협의회/제안/Projekt Kateryna. Robertsilen (대화) 06:52, 2023년 6월 14일 (UTC) 회신[답장]

안녕하세요 위키피디아 사용자 여러분

저는 위키피디아를 사랑합니다!제가 고쳐야 한다고 생각하는 몇 안 되는 것 중 하나는 발음을 위해 IPA 스타일을 단독으로 사용하는 것입니다.저는 당신이 IPA와 사용 가능한 스타일을 모두 가지고 있어야 한다고 생각합니다.제가 사용 가능하다고 말할 때, 저는 대부분의 사전에서 사용되는 것과 같은 것을 의미합니다.나는 IPA 스타일이 더 정확하고 정의되어 있다는 것을 알지만, 당신이 그것을 배우려고 애쓴 백만 명 중 한 명이 아니라면 대부분 쓸모가 없습니다(그것은 규모 추정 방법을 사용한 나의 최선의 추측입니다, 다시 말해, 나는 또한 십만 명 중 한 명을 기꺼이 받아들일 것입니다, 거의 아무도 없습니다).또한 IPA는 기껏해야 불완전한 시스템입니다.그렇다면 왜 거의 아무도 이해하지 못하는 상당히 결함이 있는 시스템만을 사용하는 것일까요?

빌 힉스 2601:548:C203:1F70:54FA:7FF:E5C3:5E80 (토크) 12:26, 2023년 6월 14일 (UTC) 회신[회신]

IPA가 smwʌtkɹptɪk (어느 정도는 암호화된, 즉)일 수 있다는 것에 동의하지만, 어떤 단순화된 발음도 실질적인 유용성은 말할 것도 없고 응집력을 보장하기 위해 엄격하게 규제되어야 할 것입니다.모음의 해석은 방언뿐만 아니라 같은 방언의 단어 자체(예: 비트, 바이트) 간에 매우 다양하며, 어떤 종류의 단순화된 라틴 알파벳 발음 가이드를 만드는 것은 아무리 적게 말해도 매우 어려운 작업일 것입니다.Edward-Woodrow :) 2023년 6월 14일 22:45 (UTC) 회신 [회신]

단어를 말하기 위한 IPA 도구가 연구되고 있지만 외부 발음에 의존하기 때문에 어려운 프로젝트입니다. 일부 초기 목업은 테스트위키에 있습니다.Phonos. — xaosflux^Talk 23:16, 2023년 6월 14일(UTC) 회신 [회신]

저는 우리가 기사의 상단 인치에 넣는 내용이 아닌 다양한 것들의 수에 대해 주의를 촉구하고 싶습니다.발음, 모자 노트... 이 모든 것이 내용을 페이지 아래로 밀어넣습니다. --Webhalt (대화) 23:00, 2023년 6월 14일 (UTC) 회신[회신]

동의합니다. Hoelun의 개정 1159880420은 발음, 날짜, 대체 이름 및 어원이 납의 고기를 밀어내는 이것의 한 예입니다.Edward-Woodrow :) 2023년 6월 14일 23:03, UTC 답변 [답장]

IPA 템플릿은 설명할 차트와 연결되어야 하며, 정확한 발음을 배우고 사전에 사용되는 기호와 멀지 않은 곳에 있는 사람들에게 그 기호가 낯설지 않아야 합니다.그러나 템플릿도 있습니다.레스펠은 영어 단어만을 위한 것이고 어떤 음절이 강조되는지와 같은 중요한 것들을 전달하는 더 접근하기 쉬운 방법이 될 수 있습니다.Dhtwiki (대화) 23:26, 2023년 6월 14일 (UTC) 회신 [회답]

이것은 매우 미국적인 불만입니다.IPA는 미국과 아마도 영어권 캐나다를 제외한 모든 곳에서 "대부분의 사전에서 사용되는 것"인 반면, 위키피디아는 글로벌 프로젝트입니다.그리고 영어를 위한 발음 수정의 표가 명확하게 보여주듯이, 단일 표준이나 지배적인 스타일의 수정은 없습니다(그래서 위키백과는 자체적으로 사용합니다).Nardog (대화) 23:34, 2023년 6월 14일 (UTC) 회신 [응답]

저는 IPA를 배우려고 애쓴 적은 없지만, 도움말:IPA/English 링크를 따라 IPA 기호를 디코딩하는 데 키를 사용하는 데 문제가 있었던 적도 없습니다.Barnards.tar.gz (talk) 11:53, 2023년 6월 16일 (UTC) 회신 [응답]

안녕하세요. 특정 지형(수역, 주립/국립공원 등)의 이름이 템플릿에 포함되어야 한다고 생각합니다.지도 링크.현재 표시된 라벨은 인간 거주지와 도로뿐입니다.그것들이 가장 많이 사용하는 페이지인 것은 이해하지만, 그것 이외의 페이지에서도 사용됩니다.일반적으로 보호 구역에 대한 단일 녹색과 수역에 대한 파란색은 두 가지 단일 색상으로 혼합됩니다. 이는 서로 다른 여러 공원/수역이 서로 가까이 있는 경우 문제가 될 수 있습니다.감사합니다. 좋은 하루 보내세요!DiscoA340 (토크) 2023년 6월 15일 19:45 (UTC) 회신 [답장]

Wikipedia_talk에는 다음과 같은 제안이 있습니다.Manual_of_Style/Lead_section#Proposal:_first_tents_should_be_definitioning을 통해 보다 광범위한 커뮤니티 입력의 이점을 얻을 수 있습니다.Barnards.tar.gz (대화) 2023년 6월 16일(UTC) 08:15, 답장 [응답]