도움말 대화:Citation Style 1인용 스타일 1

Help talk:
NewFavicon icon.svg 기타 토크 페이지 배너
인용 템플릿
…의 개념으로
...그리고 현실에서

매개변수 제안: 페이지-url=

내가 archive.org의 참고문헌을 가리키는 많은 인용문에는 다음 페이지의 특정 페이지에 대한 URL이 포함되어 있다. page= 에 있는 것과 같은 매개변수 page=[https://archive.org/details/cihm_07495/page/n255 237]. 추가 파라미터로, 아마도 이름 붙여진 것 같다. page-url= 는 이 정보를 별도로 추적하는 데 유용할 것이다. 지금까지 링크가 아직 깨지지 않은 것 같아 이렇게 남겨두고 왔다. 슬램보(Speak) 15:43, 2021년 7월 20일 (UTC)[]

의 가명이어야 한다. url=, 새로운 매개변수가 아니다. 인용문, 페이지 또는 페이지 범위의 첫 번째 페이지인 1개의 URL만 입력하십시오. 어쨌든 페이지 파라미터에서 url을 제거하고 url param을 삽입하겠다. 인용문에 페이지 번호가 포함된 경우, 해당 링크가 해당 페이지로 이어질 수 있음을 이해한다. 여러 페이지를 연결해야 할 경우 짧은 ref가 더 적합할 것이다. 50.74.114.218 (대화) 17:46, 2021년 7월 20일 (UTC)[]
왜? 출판물의 URL은 인용된 페이지의 문맥에 대한 정보에 대한 접근을 제공한다. --Shmuel (Symour J.) Metz 사용자 이름:차툴 (대화) 14:04, 2021년 7월 21일 (UTC)[]
그 말이 옳다. 그러나 다른 것을 가리키는 두 개의 URL, 즉 작업에 대한 정보/컨텍스트(작업의 URL)와 작업 중인 위치(페이지의 URL)를 가진다는 점에서 또한 잠재적으로 혼란스러울 수 있다. 나는 일반 독자들이 이것을 쉽게 이해할 수 있을지 확신할 수 없다. 나는 개인적으로 작품의 URL을 전체 인용문에 포함시키고, 페이지 URL은 짧은 참고문헌에 포함시킬 것이라고 생각한다. 그러나 이것은 단지 선호에 불과하다. 65.88.88.126 (대화) 16:54, 2021년 7월 21일 (UTC)[]
최근 Help Talk에서 관련 논의를 진행했었습니다.인용 스타일 1/아카이브 78#다중 구성요소 출판물의 구성요소를 연결하는 방법.
이 페이지 링크는 일반적으로 봇에 의해 추가된다. 몇 년 전 처음 기사에 그것들이 추가되는 것을 보았을 때 나도 그들이 나쁜 생각일 것이라고 생각했다(그것들이 더 복잡하기 때문이다). pages= 그러나 매개변수)는 첫눈에 보이는 것만큼 나쁘지 않다: 이미 관찰한 바와 같이, 페이지 정보를 메타데이터에 사용하기 전에 링크가 자동으로 제거되기 때문에 (페이지 관련 매개변수 중 어떤 것에서도) 어떤 것도 파괴하지 않는다.
다음 중 하나의 별칭만 사용할 것을 제안하는 경우 url= 페이지 링크와 제안서에 페이지 매개변수가 번호가 매겨지는 경우(다른 스레드에 있음) 이것은 작동하지 않을 것이다.
IP가 진술한 것과는 반대로, the pages= 매개변수는 종종 페이지 또는 심지어 페이지 범위의 목록을 포함하며, 개별 페이지로 분할하거나 짧은 참조를 사용하는 것은 전혀 바람직하지 않다. 개별 페이지로 분할하는 것은 복수의 독립문이 출처된 정확한 위치를 문서화하는 것이 특히 중요한 경우에만 필요하다. 대부분의 경우, 이것은 중요하지 않으며, 단일 출판물에 대한 모든 참조를 결합하고 페이지 목록을 제공하는 것으로 충분하다. 대부분의 경우, 특정 문구를 뒷받침하는 문구를 찾기 위해 이 페이지를 넘기는 것이 충분히 쉬우므로, 각 문장에 대한 개별적인 참조를 갖는 것은 기사에 중복성과 잡동사니를 더할 뿐이다. 짧은 참고문헌은 추가적인 간접적인 층을 더하고, 백링크를 허용하지 않기 때문에, 그것들은 종종 사용하기 불편하다 - 그들은 많은 다른 문제들을 추가함으로써 하나의 문제를 해결한다. WP별:CITEVAR, 그것들은 사용할 필요가 전혀 없고 많은 사람들이 그들의 단점 때문에 그것들을 사용하지 않는다(원한다. 따라서, 인용구들을 나누도록 강요하는 어떤 것을 제안하는 것은 전혀 해결책이 되지 않는다.
번호가 매겨진 페이지 링크(다른 스레드에서 제안된 바와 같이)에 대해서는 번호가 매겨진 페이지 링크 매개변수뿐만 아니라 번호가 매겨진 페이지 매개변수도 필요할 것이다. 그렇지 않으면 어떤 링크가 어느 페이지에 속하는지 알 수 없기 때문이다. 이것이 기술적으로 실행 가능한 해결책이 되겠지만, 그것은 좋은 해결책이 아닐 것이다. 왜냐하면 그것은 페이지 목록을 읽는 것을 더욱 어렵게 만들고 인용구에 엄청난 양의 매개 변수 잡음을 더하기 때문이다. 그것은 또한 코드를 훨씬 더 복잡하고 유지하기 어렵게 만들 것이다. 제 말은, 우리는 다양한 유형의 기여자에 대해 번호를 매긴 매개 변수를 가지고 있지만, 이것은 특별히 좋은 아이디어일 수 있기 때문에 그런 매개 변수를 가지고 있지 않지만, 단순히 템플릿이 주어진 이름, 성, 그리고 선택적으로 이것으로부터 디스플레이와 메타데이터 목적을 위한 적절한 표현과 복잡성을 생성하기 위한 링크를 알아야 하기 때문이다. 이름 지정 체계를 통해 이름 목록을 제공하고 템플릿에서 정보 비트를 안정적으로 추출할 수 없다. 경우에 따라서는 효과가 있겠지만, 일반적으로는 그렇지 않기 때문에 이름에 번호가 매겨진 매개 변수 집합이 필요한 겁니다. 그러나 페이지 번호 매기기 체계는 매우 다양하지만, 그것들은 여전히 이름보다 훨씬 단순하기 때문에, 단일 매개변수 인수에서 모든 필요한 정보를 신뢰성 있게 추출할 수 있을 만큼 충분히 스마트하게 만들 수 있다.
마지막으로, 매개변수가 여러 종류의 입력을 수용하는 것은 나쁜 설계 결정이 될 것이라는 불만이 있었다. 나는 이것이 어디에서 왔는지 알 수 있고, 때때로 그것은 사실이지만 위키피디아에 있는 인용문 템플릿은 그렇지 않다. 나는 우리의 접근방식이 일종의 객체 지향적이라고 생각한다. 한계가 있지만, 이상적으로는 관련 정보를 매개변수로 고정하는 모든 종류의 "데이터 객체"를 던질 수 있으며, 템플릿은 스스로 모든 것을 파악할 수 있을 것이다. 사용자의 관점에서 링크를 제공하는 가장 직관적인 방법은 표준 미디어위키 위키텍스트 구문을 사용하는 것이다. 또한 단일 페이지, 페이지 범위, 단일 페이지 목록, 페이지 범위 목록, 모든 종류의 조합, 연결된 페이지, 링크된 페이지 범위, 링크된 페이지 목록 또는 링크된 범위를 제공하더라도 문제가 되지 않아야 한다. (페이지 관련 파라미터의 경우는 아니지만, 완전성을 위해, 경우에 따라서는 텍스트 오브젝트 외에 일부 기호 키워드도 수용한다.) 일반적인 Wikitext 구문을 사용하고 데이터 항목 목록을 제공하는 것보다 사용자의 관점에서 더 간단하고 직관적인 것은 무엇인가? 사실 이것보다 쉽지는 않을 것이다.(불행히도 우리는 이름에 대해 이런 일을 할 수 없다, 적어도 특별한 구문을 도입하지 않고는, 그 생각을 물리칠 수 없을 것이다.)
이것에 대해 한 번 더 생각해 보자. 이미 위에서 말한 바와 같이 나 역시 이런 긴 끈을 특별히 좋아하지 않는다. page=[https://archive.org/details/cihm_07495/page/n255 237] (그러나 그들이 독자들을 위해 유용한 정보를 추가하고, 인용문은 이것을 위해 특별한 매개변수를 사용할 때에만 더 길어질 것이라는 점을 감안하여 나는 그것들을 받아들이게 되었다.) 그러나, 많은 경우, 이러한 링크의 첫 번째 부분은 에 제공된 링크와 같다. url= 매개 변수, 예: url=https://archive.org/details/cihm_07495이런 경우에, 나는 다음과 같은 지름길 표기법을 상상할 수 있다. page=[*/page/n255 237] url=https://archive.org/details/cihm_07495이것은 분명히 모든 경우에 효과가 있는 것은 아니지만, 많은 경우에 이미 복잡함과 중복성을 줄일 수 있을 것이다.
어느 정도 관련이 있음:
--Matthiaspaul (토크) 12:11, 2021년 7월 21일 (UTC) (업데이트 13:45, 2021년 8월 13일 (UTC)[]
너는 말한다 짧은 참조는 추가적인 간접적인 계층을 추가하며 백링크는 허용하지 않지만, IBM 3270#Reference와 같은 3270Intro에 대한 역 참조를 볼 수 있다. 인정하건대 좀 투박하지만 효과가 있다. --슈무엘 (시모어 J. Metz 사용자 이름:차툴 (대화) 14:04, 2021년 7월 21일 (UTC)[]
나는 "기본 인용문"에서 다양한 짧은 인용문까지 백링크를 의미했다. 예를 들어, "3270인트로" 인용문에 도달하면 이 항목을 가리키는 모든 짧은 참조로 연결되는 링크가 없으므로, 모든 참조를 검토하여 해당 참조를 검색해야 한다. 하지만, 만약 내가 그곳에 도착한다면, 나는 이 출판물을 인용한 다른 모든 장소들을 보고 싶어. 극도의 작업량으로 이와 같은 것을 수동으로 구성할 수 있지만, 오류가 발생하기 쉽고 유지하기가 매우 어려울 것이다. "3270인트로"의 구체적인 예에서 그곳에는 단 두 개의 짧은 참조가 있을 뿐이므로, 그것들은 정보의 손실 없이 하나로 쉽게 병합될 수 있다. 짧은 참조가 더 많은 "3270DS"와 같은 경우에도 대부분 3장의 인접 페이지를 언급하고 있으므로, 3장과 아마도 페이지 범위를 참조하는 것으로 충분하지만, 개별 페이지는 참조하지 않고, 따라서 그러한 짧은 참조가 모두 아니더라도 대부분 피한다. 특별히 언급해야 할 중요한 진술이 있다면, quote= , 그리고 quote-pages= 도움이 될 수도 있다. 개별 페이지 번호를 보존해야 할 경우, {{rp}}을(를) 개별 페이지별로 사용할 수 있으며, pages= 합본으로 이렇게 하면 추가적인 방향 전환 층을 피할 수 있고 자동 백링크가 가능하다.
--Matthiaspaul (대화) 15:00, 2021년 7월 21일 (UTC)[]
사용 <ref name=foo />{{rp bar}} 기본 인용문에만 페이지 번호를 추가할 때 잘 작동하지만, 이에 해당하는 것은 무엇인가? {{sfn foo p=bar loc=baz}}? --슈무엘 (시모어 J.) Metz 사용자 이름:차툴 (대화) 21:52, 2021년 7월 21일 (UTC)[]
그냥 콤마로 구분해서 붙이곤 했는데, 예를 들면. <ref name="foo" />{{rp bar, baz}}. 또는, 당신은 아마도 다음과 같은 것을 사용할 수 있을 것이다. {{rp at=p. bar, baz}} , 또는 {{rp at=baz}}짝수 페이지 링크는 다음과 같이 사용될 수 있다. {{rp}}이 경우 [업데이트 2021-08-11: 통화 규약이 개선되었으며, 이제 더 이상 필요하지 않다]와 같은 번호 매개 변수를 사용해야 할 수 있다.
그러나 WP:CITEVAR 적용 및 사용 가능 {{sfn}} 원하신다면 등등. 위의 제 요점은 인용문에는 여러 페이지가 완벽히 양호하며(한 기사에서 여러 개의 독립된 문구를 뒷받침하는 데 사용되는 경우에도) 개별적인 짧은 인용문으로 인용문을 분할하는 요건이 없고 편익도 종종 없다는 것이었다(가격과 함께 제공되며 단점도 종종 장점보다 크다). 보통, 그것은 상황에 따라 달라진다. 나는 왜 우리가 여러 페이지를 지원해야 하는지 그리고 왜 인용문의 단일 페이지(또는 관련 페이지)만을 다룰 수 있는 제안들이 그 어느 곳에서도 이끌어지지 않는지를 설명하기 위해 이 점을 지적하였다.
--Matthiaspaul (대화) 12:53, 2021년 7월 22일 (UTC)[]
하나의 인용문에 서로 다른 문장을 지원하는 여러 페이지 번호를 추가하는 것은 문제가 되지 않지만, 이 논의는 페이지 링크에 관한 것이 아닌가? 내가 보기엔 페이지 링크가 여러 개 달린 인용문은 다루기 힘들고 어수선하다. 특정 위키텍스트에 대한 특정 페이지 링크를 간단히 참조하면 보다 직관적이고 이해하기 쉬워 보인다. 65.88.88.127 (대화) 17:10, 2021년 7월 22일 (UTC)[]
사용 {{rp bar at=baz}}, {{rp bar, baz}} , 그리고 {{rp at=p. bar, baz}} 나에게, 그리고: bar, baz . 두 번째와 세 번째가 올바른 정보를 갖고 있지만, 위치가 길어질 가능성이 높고 인라인보다는 참조 리스트에 있어야 한다. --슈무엘(Symour J). Metz 사용자 이름:차툴 (대화) 19:35, 2021년 7월 22일 (UTC)[]

여전히 책의 분량에 대한 문제

이 몇 달 후, 책과 관련된 문제는 여전히 다루어지지 않고 있다. 나는 왜 우리가 저널/매거진이 있는 노골적인 "책"을 원하지 않는지 이해한다. 나는 책에 관한 문제를 이해할 수 없다. 북아메리카의 새들이 13권의 책을 가지고 있고, "북미 새들. 2"가 대부분의 인간들에게 2권을 언급하고 있지 않다면, 특히 평균적인 독자들은 아마도 그 세트에 13권이 있다는 것을 전혀 모르고 있다는 점을 고려할 때, 2권이 2권을 언급하고 있지 않다. 왜 템플릿은 그 아이템이 책인지 저널인지에 따라 다르게 동작하지 않는가?! 나는 그렇게 하는 것이 가능하다는 것을 알고 있기 때문에, 누군가가 우리가 왜 그렇게 하지 않는지에 대한 약간의 근거를 가지고 있어야 한다. 설명 좀 해줘! MeegsC (대화) 20:25, 2021년 7월 27일 (UTC)[]

기본적으로 관성.
이전 논의에서는 렌더링에 대해 제안된 두 가지 대체 스타일을 제시하였다. volume=, number=/ issue= (일지와 함께만 사용) 및 pages=:
저널 저널이 아님 메모들
현재 3 (4): 12–56. 3, 페이지 12-56. 긴 볼륨 이름은 굵게 표시되지 않지만 volume=vol. 3 오류로 간주된다.
제안 1 3 (4): 12–56. 제3권, 페이지 12-56
제안 2 제3권, 제4권, 페이지 12~56. 비저널리스트는 숫자나 이슈를 가지고 있지 않을 것이다.
현재 "저널"의 정의는
나는 우리가 더 넓은 고려를 위해 이러한 대안을 제시해야 한다고 믿는다. Kanguole 09:37, 2021년 7월 28일 (UTC)[]
{{cite magazine}}?
—스승 (대화) 11:07, 2021년 7월 28일 (UTC)[]
현재 행에 매거진 추가:
잡지를 만들다 잡지 다른이들
현재 3 (4): 12–56. 제3권 제4권 제12-56호. 3, 페이지 12-56.
제안 1 3 (4): 12–56. 제3권, 제4권, 페이지 12~56.
제안 2 제3권, 제4권, 페이지 12~56.
Kanguole 14:10, 2021년 7월 28일 (UTC)[]
나는 제안된 표준화를 지지하지만, 나는 "과학적" 명명법이 학술적인 논문에서 여전히 바람직할 수 있다고 생각한다. 따라서, 나는 A를 도입할 것을 제안한다. periodical-style= , 또는 serial-style= (또는 그 무엇이든) 매개 변수를 사용하여 이것이 아직 기본값이 아닌 경우 원하는 형식을 선택할 수 있다.(나중 단계에서 이 매개 변수는 다음과 유사한 템플릿에서 지원될 수 있다. cs1-dates= 템플릿의 파라미터 {{use dmy date}/{{use mdy date}}}는 개별 인용문에 사용할 필요 없이 기사의 모든 인용문 표시 형식을 전역적으로 전환한다. 1년 전에 이것에 대한 실험 코드가 좀 있었지만, 현재 상당히 변화된 코드 베이스에 맞게 조정되어야 할 것이다.)
채무 불이행을 무효화할 수 있는 그러한 선택권을 갖는 것은 보다 표준화된 형식으로의 일반적인 변화에 대한 지역 사회의 수용도를 크게 높일 것이라고 믿는다. 그것이 없다면, 나는 이미 이러한 형태의 호전적인 제안자들로부터 다음 번 소동이 일어나는 것을 본다. 그러한 매개변수가 구현되면, 우리는 여전히 즉시 대부분의 기사(목표, 우리가 달성하고자 하는 목표)에서 일관된 형식을 가질 수 있지만, 편집자들이 특정 인용문(및 기사)의 특별한 요구를 다루기 위해 디폴트를 무효화할 수 있도록 허용한다. 둘 다 최고지
제안서 1을 다양한 템플릿의 기본 형식으로 사용할 수 있고 매개변수는 기본값을 재정의하고 다른 형식을 선택할 수 있으며, 또는 제안 2를 모든 인용 유형에 대한 새로운 일반 기본 형식으로 선택할 수 있으며, 매개변수는 과학적 형식으로 전환하기 위해 개별 인용구에 사용되어야 한다.
--Matthiaspaul (talk) 16:53, 2021년 7월 28일 (UTC)[]
나는 다른 스타일의 구성 매개변수를 도입하는 것에 강력히 반대할 것이다. 사람들이 빙글빙글 돌면서 싸우는 것은 또 다른 고리가 될 것이다. 그리고 우리는 이미 우리의 워치리스트를 방해하는 많은 것들을 가지고 있다. 나는 그것보다 덜 선호되는 선택권을 갖고 싶다.
수용도를 높이는 것에 대해서는, 나는 어느 누구도 책을 위해 대담한 책을 좋아하지 않는다고 생각한다. 다른 둘 사이의 선택은 RFC에서 해결되어야 한다. Kanguole 17:11, 2021년 7월 28일 (UTC)[]
rfc에 의한 디자인; 얼마나 끔찍할까.
나 역시 아직 다른 스타일의 파라미터에 반대한다. {{cite journal}} 학구적 양식을 확립하다 싫으면 쓰세요. {{cite magazine}} , 또는 {{cite periodical}}. 특별한 매개 변수 필요 없음.
—스승 (대화) 17:58, 2021년 7월 28일 (UTC)[]
만약 우리가 사람들이 인용 잡지를 사용할 수 있기를 원한다면 - 위키피디아에 추가할 필요가 있다.RefToolbar/2.0 - 그렇지 않으면 대부분의 편집자는 도구가 강제로 사용하는 템플릿을 사용한다.나이젤 이스 (토크) 18:29, 2021년 7월 28일 (UTC)[]
너는 나에게서 아무런 반대도 받지 못할 것이다. 하지만 행운을 빈다.
아마도, 충분한 편집자들이 그것에 대해 떠들어대면, 누군가가 그들이 원하는 것을 그들에게 줄 필요(고맙지 않은) 노동을 할 것이다. 아마도 당신은?
—스승 (대화) 19:12, 2021년 7월 28일 (UTC)[]
RefToolbar 페이지에 대한 논의에서 알 수 있듯이 툴이 유지되고 있지 않다면 비활성화해야 한다.나이젤 이스 (토크) 20:34, 2021년 7월 28일 (UTC)[]
나는 네가 틀렸다고 생각한다. 복수의 자바스크립트 페이지는 WP:RefToolbar를 구현한다. 공구는 대부분 안정적이어서 할 일이 거의 없다. 그럼에도 불구하고 이 부분들은 올해 업데이트되었다.
앞에서 말했듯이, 만약 충분한 편집자들이 그것에 대해 떠들면, 누군가는 그들이 원하는 것을 줄 필요(무감하게) 노동을 할 것이다. 만약 당신이 변화를 원한다면, 변화를 원하는 편집자를 충분히 모집하거나, 아니면 실패하더라도, 스스로 그것을 해라.
—스승 (대화) 13:10, 2021년 7월 29일 (UTC)[]
RfC에 의한 설계는 일관성이 없고 일관성이 없으며 일반적으로 힘이 덜 드는 솔루션이라는 것이 입증되었다. 그러나 우리 자신의 (일반적으로 위대하다;-) 생각을 공동체에 강요하는 것 역시 선택사항이 아니다. 내 말은, 우리 대부분이 인용 형식에 대한 경험이 꽤 많은 이 헌신적인 장소에서조차 우리는 종종 문제에 대한 최선의 해결책에 관해 매우 다른 관점을 가지고 있다는 것을 분명하게 보여주며, 우리가 다양한 종류의 니즈를 가지고 있고 따라서 그것들을 다룰 수 있는 융통성이 필요하다는 것을 분명히 보여준다. 그렇기 때문에 사용자들에게 (합리적인 채무불이행과 양호한 문서화의 형태로) 어느 정도 지침을 주어야 할 뿐만 아니라, 그들이 더 특별한 요건에 부합하고자 하는 결과를 (필요하다면) 얻을 수 있도록 필요한 유연성을 주어야 한다고 생각한다. 그렇지 않으면 그들은 우리의 템플릿에 대해 불평하거나 사용하지 않을 것이다. 둘 다 그들과 우리 모두에게 불만족스럽다 - 그리고 프로젝트 전체에도.
나는 교장에 충분할 것이라고{{ 들고 일기}}은 과학적 형식과{{잡지 인용하다.}}는 장황한 형식-기본적으로 그것은 style-parameter 사용하도록 의견에 동의한다. 하지만, 우리는 독자들이 샘플 템플릿은 그 생각의 탬플릿을 전광판 포맷에 따라 선택할 이길 것이다 정기의 본성에 기반한 간을 전환하고 있다.
, style-parameter 선택적으로 나는 아직도 제안 1을 지원할 수 있는 기본을 무시할 수는 있었지만 제안 2없이 요약하면.
--마티아스폴 (토크) 02:05, 2021년 7월 29일 (UTC)[]
@ Matthiaspaul:우리는-나는 종종 어떤 사람들은 부적절하게 사용하는 것 같아 나는 자주(예), 그렇게 하고 독자들이 샘플 템플릿은 정기의 본성에 기반한 간을 전환하고 있다. {{cite journal}}, {{cite news}} , 그리고 {{cite web}} 잡지에 나에게 choos[ing] 탬플릿을 전광판 포맷에 기초하지만 발생원에 대해 가장 적절한 템플릿을 선택하는데-, 상황이 아니다 각각의 이러한 네개 특성의: 같은 충고를 해 줘 문서를 가지고 있다.
  • {{cite journal}} -학술적 및 과학적 서류 진정한 저널에 발표되었습니다.
  • {{cite magazine}} 잡지와 뉴스 레터에서-기사.
  • {{cite news}} 인쇄, 비디오, 오디오 또는 웹에서-뉴스 기사.
  • {{cite web}} -웹 다른 CS1 템플릿에 의해 특징 지어지지도 않다.
나는 사용하지 않는 사람들은 {{cite magazine}} 문서를 읽지 않기 때문에 부분적으로 그렇게 하는 것도 있지만, 주로 그들이 사용하는 인용 도구에 의해 제공되지 않기 때문이다(Nigel Ish가 2021년 7월 28일(UTC)의 게시물 및 트라피스트의 회신 참조). 그것이 그대로 남아 있는 한 인용문 수정의 필요성은 언제나 있을 것이다. --Redrose64 🌹 (대화) 09:58, 2021년 7월 29일 (UTC)[]
네, 그말이 맞아요. 사실 나도 하지만 합리적으로 출력 형식으로{{ 들고 일기}사이의 차이를 가지고}과{{잡지 인용하다.}}행복해요 이 일을 하는 거야 나는 우리가 가장 적합한 매개 변수를 선택하여 이 아이디어를 유지해 나가야 한다고 생각한다. journal= , 또는 magazine= 정기의 자연에 기초를 둔다. 일반적으로 우리는 사용할 수 있을까 journal= {{ 들고 일기}에}과 magazine= {{잡지 인용하다.}}지만, 트라피스트 회의의 발언은 탬플릿을 원하는 출력 형식 위에 따라 선택할 이에 따라 여기는 사람들 일부러에{{ 들고 일기}}를 이용하는 선택을 할 수 있음을 인정해야 할 것이다. magazine= 또는{{잡지 인용하다.}}에 journal=이것이 전체적으로 특별한 조항이 렌더링에 일리가 있어요, 그리고 저,, 우리는 혼자서 이 떠나야 한다.
--Matthiaspaul (talk) 10:14, 2021년 7월 29일 (UTC)[]
나는 당신이 실제로 그것은 얘기 없이 무엇이라고 말한다고 생각합니다. {{cite journal}}, {{cite magazine}}, {{cite news}} 정식 템플릿에 모든이 리디렉션. {{cite periodical}}.{{나 정기 간행물을 인용하다.}}다음 스타일은 그에 의해 지시된 대로 volume/issue/page가 없어진다. work= 템플릿에 사용되는 매개 변수 별칭. 이는 대부분 모듈 이외의 다른 곳에서 중대한 과제가 될 수 있다.인용/CS1. 일부 또는 일부 일련의 봇은 기존 템플릿을 변환해야 할 것이다; WP:RefToolbar와 같은 도구는 업데이트 등이 필요할 것이다. 나는 이 아이디어가 더 좋지만 횃불과 포크를 예상한다. 왜냐하면.위키 편집자들은 싫어하고, 싫어하고, 싫어하고, 싫어하고...
—스승 (대화) 13:10, 2021년 7월 29일 (UTC)[]

나는 일반적으로 제안서 1의 어떤 형태를 선호한다. {{cite journal}}}은(는) 더 짧은 포맷을 사용한다. {{cite magazine}}에서, 부피와 발행 번호 옆에 있는 페이지 번호를 구한다.(현재 발행자가 지정되어 있으면 페이지 번호로부터 발행물/발행을 분리한다.) {{cite map}}, 외, 출력물을 ({cite map})에 연결한다. journal= , 또는 magazine= 사용된다.

그러나 책의 경우, 제목 옆에 볼륨 번호를 두고 페이지 번호를 마지막에 유지하지만, 그렇지 않으면 볼륨 번호에 "vol" 텍스트를 추가하여 일관성을 유지하려고 한다. 임자디 1979 → 22:46, 2021년 7월 28일 (UTC)[]

제안 2는 위키피디아와 같은 프로젝트에 이치에 맞는 유일한 계획이다. 독자들은 쉽게 이해할 수 있다. 쉼표 구분 기호는 스타일을 위반하기 때문에 편집자에게 설명해야 할 것이다. 이는 현재 기능적 효용이 없는 "스타일 1"과 "스타일 2"로 분리기를 경직적으로 구현하고 있기 때문이다. 64.18.9.208 (대화) 23:40, 2021년 7월 28일 (UTC)[]

  • 지원 제안 2 제안서 1에 만족한다. 타이틀을 볼륨에서 분할하지 않는 것에 대해 임자디와 동의하라. 나는 관리자들이 이미 이것을 거절했다고 생각했다. 호크예7(토론) 23:49, 2021년 7월 28일 (UTC)[]
    • 나는 개인적으로 프로포즈 2를 선호하지만, 나는 줄여서 쓴 저널 형식에서 완전히 벗어나기에는 너무 많은 관성이 있을 것이라고 생각한다. 임자디 1979 → 00:16, 2021년 7월 29일 (UTC)[]
  • 1을 강하게 선호하지만 2와 함께 살 수 있다. 현상유지는 용납할 수 없다. 헤드폭탄 {t · c · p · b} 01:22, 2021년 7월 29일(UTC)[]
  • 지지 제안 1; 나는 현 상태가 전혀 작동하지 않는다는 것에 동의한다. 그리고 익명의 IP가 주장할 수 있는 것에도 불구하고, 제안 2는 확실히 "이치에 맞는 유일한 것이 아니다". "숫자" 필드를 공백으로 두면 해당 매개변수가 전혀 나타나지 않을 것으로 가정한다. (예: vol. 2, 페이지 12–56). MeegsC (대화) 10:28, 2021년 7월 29일 (UTC)[]
독자들이 전혀 모르는 템플릿의 사용에 따라 이슈와 볼륨의 서로 다른(그리고 난해한) 렌즈가 더 잘 제공된다는 말인가? 그리고 왜 "MeegsC"라고 불리는 것에 의한 주장이 그것보다 더 나은가? 64.18.9.201 (대화) 11:16, 2021년 7월 29일 (UTC)[]
  • 제안 2를 선호하되 제안 1도 지지하고 현 상태보다 어느 하나를 강력히 선호한다. 나는 저널 기사에 인용구를 추가하는 대다수의 편집자들이 아마도 그것에 익숙하기 때문에 학문적인 속기에 만족하고 있다고 생각한다; 따라서 스타일 변화는 항상 짜증나기 때문에 그들을 짜증나게 할 것이다. 반면에, (아직 증거에 근거하지 않고) 우리의 평균적인 독자들은 아마도 학술지를 거의 보지 않고, 테르스 인코딩이 무엇을 의미하는지 추측하도록 남겨져 있다. 나는 우리가 편집자에게 친숙함의 편안함보다 독자를 위해 명료함을 우선시해야 한다고 생각한다. 내가 아는 한 속기가 널리 쓰이지 않는 책의 경우 이것은 두 배로 늘어난다. Wham2001 (대화) 11:11, 2021년 7월 29일 (UTC)[]
  • 제안서 1에 대한 강력한 지원. 이것은 내가 과학 문헌에서 보길 기대했던 저널과 책의 결과물을 제공한다. 책은 Volume 또는 Vol을 사용하는 반면, 저널은 단지 숫자를 가지고 있는데, 이것은 굵은 (가장?), 이탤릭체 (몇 개) 또는 강조 없이 나타날 수 있다. — Jts1882 talk 12:17, 2021년 7월 29일 (UTC)[]
  • 제안서 2 - 제안서 1은 모호함을 남기고, 숫자가 무엇을 의미하는지 머리를 긁적거리게 하는 모호하지 않은 제안서 2는 명확하다. 그리고 한 글에 스타일을 섞을 수 있는 기회는 그리 좋지 않다. 키스 D (토크) 12:50, 2021년 7월 29일 (UTC)[]
  • 제안서 1에 대한 강력한 지원. 생물학적 관점에서 대부분의 과학 저널 인용문은 8권, 10권을 8(10) 또는 8(10) 또는 8(10)로 렌더링하는 APA 스타일이다. 생물학 인용문에 "vol"을 포함시키는 것은 이상할 것 같지만, 들어보지 못한 것은 아니다. 그러나 MeegsC에 따르면, 정말 변화가 필요하다. 책으로 출판되고 그 책들을 메모하기 위해 단어와 함께 인용된 과학 서적들이 너무나 많다. 잭 (토크) 14:11, 2021년 8월 22일 (UTC)[]
  • 제안 1 - 지역 사회로부터 많은 즉각적인 마찰을 받지 않고 제안 2를 할 수 있는 방법은 없으며, 제안된 것과 같은 해결책이 불가피하다. periodical-style= 그 위에선 더 복잡하게 만들었지 자동화된 방법을 통해 인용문을 작성하고 특정 기사에 사용할 올바른 스타일을 결정하는 문제를 상상해 보십시오. 그런 다음 다음과 같은 것이 필요함 {{use dmy}} 모든 기사의 정상을 뒤죽박죽으로 만들다 아니, 그 길로 가지 마. 제안서 1은 이미 존재하는 것 중에서 가장 큰 것으로서 다른 작은 템플릿과의 문제를 해결하는 동안 가장 적은 마찰력을 가질 것을 유지한다. -- GreenC 14:40, 2021년 8월 22일 (UTC)[]
위키피디아는 과학 출판물이 아니다. 그것은 또한 생물학 분야를 포함한 어떤 종류의 전문가들을 위한 특별한 목적의 수단이 아니다. 소수자(편집인 또는 그 일부)가 소란을 일으킬 수 있기 때문에 전체 커뮤니티(독자)에 맞춘 해결책은 우회해야 한다는 주장도 있다. 별로 놀랍지 않다. "위키페디아인" :) 자주 주인의식을 가지고 행동하고, 또한 자주 발작을 일으키기도 한다. 한편 위키피디아는 다소 사심 없이 자신의 가치 없는 것을 선언한다. 195.1233.197 (대화) 15:55, 2021년 8월 22일 (UTC)[]
여기에서 IP에 확실히 동의하십시오. 조항은 WP가 아니다.특정 개인이 소유하고 있으며, 여기서 3권 2번을 사용하는 것이 내가 강력히 동의하는 제안인 3(2)를 사용하는 것보다 낫다고 결정한다면, 우리의 독자들이 저널을 인용하는 모든 기사에 그것을 전파하도록 허용하는 것이 옳고 적절하다. — 아마쿠루 (토크) 10:51, 2021년 8월 23일 (UTC)[]
"우리"가 누구야? 경험에 따르면, 백만 플러스 공동체는 현상 변화에 민감하다는 것을 반복적으로 보여주었고, "우리"가 우리의 전문가에 따라 그들의 "독자" 자신의 이익을 위해 사물을 바꾸기로 결정했을 때, '피치포크'가 나오고 참호를 파낸다. IMO 이것은 보다 중요한 변화라고 말할 수 있다. accessdate= 대 access-date= 어떻게 됐는지 알잖아, 전선이 너무 딱딱해져서 이제 완전히 굳어버렸으니 절대 고쳐지지 않을 거야. 일단 그 문제에 대한 광범위한 관심이 집중되면, 당신은 느슨한 통제력을 갖게 된다. 가능한 한 현 상태를 유지하고 실제로 고쳐야 하는 작은 것들을 수정하면 성공할 수 있다. 나중에 돌아와서 인용 저널을 별개의 문제로 다루어라. 왜냐하면 그것이 불협화음이 될 가능성이 있기 때문이다.-- GreenC 20:47, 2021년 8월 23일 (UTC)[]
현상에 대한 어떤 도전도 소란을 일으킬 것이라는 네 말이 옳다. 그것이 더 나은 해결책을 적용하는 것을 만류해야 하는지가 문제다. 만약 그렇다면, 평범함이 다시 승리한다. 이것은 이곳의 규범이다. 결국 이 사업은 아이러니함이나 자각의식이 전혀 없는 상태에서 내용 대다수가 디폴트로 피의자로 지정되는 사업이다. 이른바 '착한 기사'는 소수다. 누가 생각하겠는가 하면, 왜 백과사전은 자신이 비재능으로 지정한 기사를 출판해야 하는가?라는 질문을 즉시 제기해야 할 것이다. 그러한 제도적 정신분열증에 비해 이미 이 실 위에서 갈고 있는 피치포크는 틀림없이 이쑤시개처럼 보인다. 195.1233.197 (토크) 00:21, 2021년 8월 24일 (UTC)[]
  • 제안 2. 나는 3(2)형식이 대부분의 독자들이 전문가가 아니어서 그것이 무엇을 의미하는지 자동으로 알지 못하는 백과사전에서 사용하기에 이상적이지 않다고 오랫동안 생각해 왔다. 시카고나 MLA 인용 스타일에 따라, 볼륨과 번호 명명법을 사용하여, 무엇을 의미하는지 명시적으로 설명하는 것이 훨씬 낫다. 이는 저널, 책, 잡지 또는 기타 모든 출판물에 적용되어야 한다. — 아마쿠루 (토크) 10:47, 2021년 8월 23일 (UTC)[]
  • 제안서 1. 다만, {{cite magazine}}}이(가) 발행인과 동일한 명칭을 사용해 줄 것을 요청할 수 있는 수단을 요청하고 싶다. --슈무엘(Symour J.) Metz 사용자 이름:차툴(대화) 19:18, 2021년 8월 23일 (UTC)[]

구현

비저널에 대한 대담한 수량은 받아들일 수 없다는 것이 보편적으로 동의하는 것으로 보이지만, 이를 저널에 보존할 것인지, 즉 그곳에는 변화에 대한 공감대가 없는지에 대해서는 의견이 분분하다. 그래서 나는 잡지의 포맷을 모든 비저널로 확장하기 위해 샌드박스를 바꿨다.

인용도서비교
위키텍스트 {{cite book first=Ann last=Author pages=12–34 title=Book volume=3 year=2000}}
Live Author, Ann (2000). Book. 3. pp. 12–34.
샌드박스 Author, Ann (2000). Book. Vol. 3. pp. 12–34.
Cite 저널 비교
위키텍스트 {{cite journal first=Ann journal=Journal last=Author number=5 pages=12–34 title=Article volume=3 year=2000}}
Live Author, Ann (2000). "Article". Journal. 3 (5): 12–34.
샌드박스 Author, Ann (2000). "Article". Journal. 3 (5): 12–34.
인용비교
위키텍스트 {{citation first=Ann last=Author pages=12–34 title=Book volume=3 year=2000}}
Live Author, Ann (2000), Book, 3, pp. 12–34
샌드박스 Author, Ann (2000), Book, vol. 3, pp. 12–34
인용비교
위키텍스트 {{citation first=Ann journal=Journal last=Author number=5 pages=12–34 title=Article volume=3 year=2000}}
Live Author, Ann (2000), "Article", Journal, 3 (5): 12–34
샌드박스 Author, Ann (2000), "Article", Journal, 3 (5): 12–34

Kanguole 19:11, 2021년 9월 10일 (UTC)[]

부피와 숫자 사이의 구분 기호

좋아 보인다. 비교를 위한 두 가지 추가 사항(변경 없음):
인용비교
위키텍스트 {{citation date=2000 first=Ann last=Author magazine=Magazine number=5,7 pages=12–34 title=Article volume=3,5}}
Live Author, Ann (2000), "Article", Magazine, vol. 3, 5 no. 5, 7, pp. 12–34
샌드박스 Author, Ann (2000), "Article", Magazine, vol. 3, 5, no. 5, 7, pp. 12–34
Cite 잡지 비교
위키텍스트 {{cite magazine date=2000 first=Ann last=Author magazine=Magazine number=5,7 pages=12–34 title=Article volume=3,5}}
Live Author, Ann (2000). "Article". Magazine. Vol. 3, 5 no. 5, 7. pp. 12–34.
샌드박스 Author, Ann (2000). "Article". Magazine. Vol. 3, 5, no. 5, 7. pp. 12–34.
다만, 볼륨과 숫자 정보 사이에 최소한 쉼표(CS1의 점일 가능성이 있음)를 넣어야 한다고 생각한다. 위의 간단한 경우에서도 그들 사이에 구분자가 없는 것이 이상해 보이지만, 더욱 복잡한 경우에는 더욱 그렇다(설명 목적으로 나는 그 내용을 바꾸었다. volume= , 그리고 number= 목록을 포함하는 매개 변수).
--Matthiaspaul (talk) 14:48, 2021년 9월 15일 (UTC)[]
예, 현재 프레젠테이션의 {{cite magazine}} 변경되지 않고, 이제 다른 비이동성으로 확장된다. 그러나, 의 조합. volume= , 그리고 number= 잡지와 저널에서만 발생해야 하며, 따라서 그들의 형식은 이러한 변화와 무관하다. Kanguole 15:27, 2021년 9월 15일 (UTC)[]
리스트를 본 적이 없다고 덧붙이고 싶네 volume= , 또는 number= 야생에서 – 보통 3/4 또는 3–4이다. 만약 기사가 다른 이슈/볼륨의 페이지 범위가 다른 여러 파트로 출판된다면, 그것들은 별도의 시트가 되어야 할 것이다. Kanguole 15:34, 2021년 9월 15일 (UTC)[]
나는 비록 드물지만 두 가지 모두를 합친 적은 없다. volume= , 그리고 number=. 볼륨과 숫자 사이에 뭔가 빠진 것이 있다는 것을 좀 더 명확하게 보여주기 위해 여기서 예시로 삼았다. 나는 기본적으로 쉼표(또는 점)를 추가하는 것에 대한 가능한 논의를 위해 이 실을 "잡았다" 왜냐하면 이것은 대중에게 받아들여질 수 있는 또 다른 사소한 변화일 수 있고, 이 실에는 이미 출력의 빠른 비교를 위해 렌더링된 인용 템플릿의 훌륭한 목록이 있기 때문이다.
--Matthiaspaul (talk) 16:48, 2021년 9월 15일 (UTC)[]
완료. --Matthiaspaul (대화) 14:19, 2021년 9월 24일 (UTC)[]

조테로가 COinS를 읽지 않음

나는 최근 몇 차례 (Firefox의) 조테로가 우리의 인용 템플릿에 의해 배출된 COinS 메타데이터를 탐지하지 않고 있다는 것을 알아챘다. 예를 들어, 벨센을 도왔던 런던의 의대생들의 리스트에서 말이다.

로그인하지 않았을 때도 같은 문제가 발생하기 때문에 내 가젯이나 사용자 스크립트와 관련이 없는 것 같아.

우리의 COinS에 알려진 문제가 있는가?

한 가지 가능한 원인(JavaScript 관련, 따라서 관련이 없을 수 있음)은 Zotero 포럼의 "Connector가 간헐적으로 COinS를 인식하지 못함"에 설명되어 있다. 그것은 또한 수정안을 제시하지만 우리가 템플릿으로 적용할 수 있는 것은 아니다.

다른 원인이나 해결책을 제시할 수 있는 사람이 있는가? Andy Mabbett (Pigsonthewing); 앤디와 대화; 앤디의 편집 13:49, 2021년 8월 28일 (UTC)[]

얼마 전이야? 마지막 cs1 2 모듈-사이트 업데이트는 2021년 4월 10일이었다. 우리 인용문 때문에 이 문제를 겪고 있는 편집자는 당신뿐인가요? 메타데이터를 가져오는 데 문제가 있으십니까? {{cite patent}} 인용문? 그 템플릿은 메타데이터를 내보내는 데 cs1 2 모듈 제품군을 사용하지 않는다.
—Trappist 그 수도사(이야기)14:10, 28일 8월 2021년(CoordinatedUniversalTime)[].
지난 몇 주 동안, 비록 그것이 매주 하는 일은 아니지만. 나는 다른 편집자들의 시스템을 조사하지 않았다. Zotero가 템플릿에서 COinS를 찾음:첫 번째 시도에서 특허/시험장을 인용하십시오. "런던 의대생 명단..."을 재조사한 결과, 이 문제는 간헐적인 것으로 보이며, 예상대로 재현될 수 없는 것으로 보인다. Andy Mabbett (Pigsonthewing); 앤디와 대화; 앤디의 편집 2021년 8월 28일(UTC)[]
아직 못 봤어.
다시 이 문제에 직면했을 때, 로드된 웹 페이지에 COinS 데이터가 실제로 포함되어 있는지(아마도 여기에 예시를 게시) 확인할 수 있는가?
어림짐작일 뿐이지만, 아마도 빈 스팬이라는 이유로 COinS 스팬을 제거하는 사례가 있을 것이다. 현재 구현에서는 마감 직후에 해당 항목을 찾을 수 있다. </cite>:
<cite>...</cite><span title="ctx_ver=Z39.88-2004..." class="Z3988"></span>
자바스크립트가 비활성화된 경우에도 이러한 현상이 발생하는지 확인할 필요가 있다.
--Matthiaspaul (talk) 17:32, 2021년 8월 28일 (UTC)[]

s2cid 한계에 달한

그냥이 있는 기사 카테고리에 종부터 시작하니, 이끌고 있다.값 237000000보다 더 큰와의 정확한 것 같아CS1 오류:S2CID.Lightlowemon(이야기)13:55, 8월 31일, 2021년까지(CoordinatedUniversalTime)[].

기록으로, 이 즉시 240000000에 2021-08-31 트라피스트 회의에 의해 이미 시작했다.
--Matthiaspaul(이야기)19:08, 269월 2021년(CoordinatedUniversalTime)[].

일러스트레이터

추가 제출하다. illustrator 로 {{cite book}} 그리고 다른 사람들:

illustrator-last1= illustrator-first1= illustrator-link1=

.... 0mtwb9gd5wx(이야기)19:02, 9월 2일, 2021년까지(CoordinatedUniversalTime)[].
또한 비슷한 주제 위에 있다. 개인적으로, 나는 책 일러스트레이터의 명확한 이는 책의 내용을 확인할 수 있는 상황의 상상이 안 된다. 그것은 책의 삽화가 참조 데이터베이스에, 그리고 따라서 매우(또는 원천을 찾는데 도와)그 특정한 정보가 원천을 찾기 힘든 인덱싱 된 것 같지 않다. 이 audiobooks에서 중요한 역할로 간주된다 이와는 대조적으로,"서술자"논의 이전에 연결과 관련된, 나는, 그"서술자"분야 index 몇개 상호 데이터베이스 65.88.88.76(이야기)20:41, 9월 2일, 2021년까지(CoordinatedUniversalTime)[]을 보았다.
그냥 내 위의 의견{{책을 인용하다.}에}제한되어 있다. 65.88.88.76(이야기)20:44, 9월 2일, 2021년까지(CoordinatedUniversalTime)[]을 첨가한 것이다.
나는 이것에 대해 너무 궁금해 했다. 나는 한국에는 삽화가 주목할 만한 것은 많은 경우들이 있고 그들에게 wikilink이 있으면 좋을 것으로 생각합니다. Laterthanyouthink(이야기)05:51, 59월 2021년(CoordinatedUniversalTime)[].
상황은 충분히 그 드문 일이다. others= 담당으로 사용할 수 있다. others=illus. [[Quentin Blake]]. Redrose64, 59월 2021년(CoordinatedUniversalTime)[](이야기)08:16 🌹.

템플릿을 바꾸기 위해 제안.

Please forgive me if this idea has has already been "considered" and rejected ... 아니면 그런 비슷한 것.

내 제안은 이미 어떤 곳에서("Wikipedia:. 입력되었다Teahouseᆩnewᆪ[ 죽은 링크]"한번은 새로운 섹션을 가져오"archived" cm이다. ( 그렇죠?)

그러나"DIFF"URL은"편집"에 대한 링크로서 기능을 한다...더 오랜 시간 동안...또한 편집되어 그 페이지(이 경우, 'Teahouse의 페이지에)의 낡은["non-latest"]버전은 여전히 남아 있유효합니다. 여기 그러한"DIFF"URL한 예이다.

https://en.wikipedia.org/w/index.php?title=Wikipedia:Teahouse&diff=prev&oldid=1042098412

... 그리고, 해당 ['Teahouse' 페이지] 섹션이 "보관"될 때 ^H가 되더라도, 해당 섹션의 항목 내에 검색될 수 있을 만큼 고유한 텍스트가 있을 것이다. 다른 URL로 "이동"된 후에도 '잃어버린'("보관된") 섹션을 찾을 수 있다.

...사실, 아래에 나와 있는 URL도 업데이트 할 수 있어! ...잊지 않으면. 그 동안(적어도 새로운 섹션이 "보관"될 때까지), 여기서 나의 "제안"을 볼 수 있다.

위키백과:찻집#템플릿 변경 제안

그래서 ... 여기서 그 제안이 "반복"될 필요는 없다. (맞지?)

--Mike Schwartz (대화) 06:39, 2021년 9월 3일 (UTC)[]

The url-access= 매개변수에는 4개의 가능한 값이 사용된다: "[]free]", "subscription", "registration", "limited". 매개변수 url-status= 소요 시간: "dead", "live", "unfit", "usurped" (그리고 곧 "deviated"). 내가 당신을 이해할 수 있는 한, 당신은 덧붙이려 하고 있었다. url-access=paywall [1]을(를) 가리키는 정치가의 인용문. 그러나 인용문 템플릿에 의해 오류 메시지와 함께 거부되었으므로 다음 주소로 변경하십시오. url-status=unfit 대신 HTML 설명 추가:
"실제로 [불합격] 적합하지 않지만, "불가능한" [...]에서 웹페이지에 접속하는 것은 유료화 ['해당되는 경우]로 인해 어떤 불편이나 다른 문제가 발생할 수 있다; [...] 누구나 "불가능한"에서 웹페이지에 접속할 수 있다.)
이게 정말 당신이 의도한 거라면, url-status= 사용할 잘못된 매개 변수(또는 짝수) url-status=live 유효할 것이다) 그리고 당신은 대신 다음 중 하나를 추가했어야 한다. url-access=registration , 또는 url-access=subscription 당신이 보는 "paywall"의 종류에 따라.
나는 네가 "해당되는 경우"가 무슨 뜻인지 잘 모르겠다. URL을 볼 수 있는 경우(및 비교) archive-url= [2]), 전체 기사로 보이는 것을 볼 수 있으므로(무료 및 등록 종류 없음) url-access= 적절하지 않을 겁니다 아니면 구독 후 더 긴 버전의 기사가 있는가? 만약 그렇다면, 다음 조합은 url-access=subscription , 그리고 url-status=limited 가는 길이 될 거야
다른 종류의 접근 제한사항이 보이십니까? 기존 사전 정의된 값 집합에서 아직 제대로 다루지 않은 상태가 누락되었다고 생각하십니까?
--Matthiaspaul (talk) 07:59, 2021년 9월 3일 (UTC)[]
여기 설명서에 대한 링크가 있다. 또한, 질문이 있을 때, 그것에 대해 간단한 영어로 간결하게 말하는 것이 도움이 된다. – Jonsey95 (대화) 13:40, 2021년 9월 3일 (UTC)[]
응답해주신 모든 분들께 감사드린다.
나는 이 부분을 찾을 수 있었다. (이 부분은 아마도 [모두 또는 ...]를 위한 영구적인 집일 것이다. "적어도" 이 [특정] "적어도"에 대한 논의 -- 이 토론에 대한 직접적인 링크를 클릭함으로써, 누군가가 제공한 것이다.
(그러나, 그 직접적인 링크를 찾기 위해, 나의 원래 "제안" 섹션 뒤에
[처음에는 '위키피디아:찻집#템플릿의 변경 제안', ...어쩌면 어설프게]
이미 보관되어 있는 상태였기 때문에 검색 작업을 해야 했고, https://en.wikipedia.org/w/index.php?title=Wikipedia:Teahouse&diff=prev&oldid=1042098412에서 "검색"의 전체 텍스트에 액세스할 수 있었던 것은 이 보관된 버전으로 나를 안내할 수 있는 몇 가지 검색어를 "검색"할 수 있게 해준다는 점에서 나에게 도움이 되었다. 위키백과:찻집/질문/아카이브_1122#템플릿 변경 제안... 여기서 이 섹션의 ["Talk:"] 페이지에 대한 특정 직접 링크 [THANK!]를 찾을 수 있었다.
나는 (그리고 내가 잊지 않는다면) 다음과 같은 몇 가지 질문에 대답하고 싶다.
  • "다른 종류의 접근 제한을 보고 있나?"
, 그리고
  • "기존의 사전 정의된 값 집합에서 아직 제대로 다루지 않은 상태를 놓치고 있다고 생각하십니까?" --
그리고 (필요하다면) 내가 << "아카이브-url" 필드 primary에서 URL을 만드는 것>>이라는 문구를 사용하여 무슨 뜻인지 설명하려고 한다(아마도).
하지만 지금은 시간이 부족해서... 아마도 나중에.
고마워, --Mike Schwartz (토크) 17:32, 2021년 9월 15일 (UTC)[]

쉼표가 있는 개별 항목에서는 이 형식 마크업이 작동하지 않음

Accept-as-the-sword markup 섹션은 마크업을 전체 또는 개별 목록 항목에 적용할 수 있다고 말하지만, 예를 들어, 쉼표가 있는 숫자에는 적용되지 않는 것 같다. {{cite book title=Title pages=999, ((1,001))}} 돌아온다 Title. pp. 999, ((1, 001)).. 이것은 상부에 다음과 같은 것을 더하면 해결될 수 있었다. hyphen_to_dash(): 

발을 동동 구르다 = 발을 동동 구르다:gsub("(%(%(.-%)%))", 기능을 하다(m) 돌아오다 m:gsub(",", "，"):gsub(";", "；") 종지부를 찍다)

해당 선이 쉼표와 세미콜론을 전체 너비 동등으로 바꾼 후 분할을 수행한 다음 반환하십시오. 

발을 동동 구르다:gsub("，", ","):gsub("；", ";")

함수의 끝에 여기 샌드박스에서 조롱해 놨어. --아헤흐트 (TOKPAGE
) 17:30, 2021년 9월 3일 (UTC)[]

{{cite book title=Title pages=((999, 1,001))}} 돌아온다 Title. pp. 999, 1,001. 헤드폭탄 {t · c · p · b} 17:47, 2021년 9월 3일(UTC)[]
@Headbombum Yes, 그러나 설명서에는 개별 목록 항목에도 적용할 수 있으며 전체 항목에도 적용할 필요가 없다고 되어 있다. 내 변경 사항이 포함된 샌드박스 버전(예: {{cite book/sandbox title=Title pages=999, ((1,001))}}는 돌아온다. Title. pp. 999, 1,001. --아헤흐트 (TOKPAGE
) 20:36, 2021년 9월 3일 (UTC)[]
기고해 주셔서 감사하겠지만, 현재 생산 코드와 일치하도록 문서를 수정하는 것이 더 쉽지 않을까? 또한 편집자 설명서는 필드 리스트 분리기를 포함한 필드 레벨 연산에 초점을 맞춘다는 점에서 모듈 코딩을 따른다. 나는 이것이 현재 좋은 디자인/코딩 결정이라고 생각한다. 개별 필드 리스트 항목의 형식(이 논의의 표기 문제 등)은 지적한 바와 같이 특별 마크업으로 처리할 수 있다. 이미 비틀거리는 편집자 설명서의 복잡성은 다른 좋은 해결책을 적용하는데 있어 증가할 것이다. 좋지 않은 것 같아. 65.88.88.126 (대화) 21:43, 2021년 9월 3일 (UTC)[]
구문은 목록의 개별 항목뿐 아니라 세계적으로도 통용되는 것도 중요하지만 몇 가지 미묘한 점이 있어 주의가 필요하다. 예를 들어, 샌드박스의 코드는 외부 목록 요소에만 구문이 있을 뿐 중간 요소가 아닌 경우 데이터를 추적하는 버그를 다시 도입한다. 자세한 내용은 다음을 참조하십시오.
참고 항목:
--Matthiaspaul (talk) 00:19, 2021년 9월 4일 (UTC)[]
@Matthiaspaul 좋은 점, 그것은 내가 평가하지 않았던 시험 사례다. 샌드박스 버전은 지금 고정되어 있으며, 아카이브 73 섹션의 모든 예시들은 일반 버전과 샌드박스 버전에 대해 동일하게 평가한다. --Ahecht (TOKPAGE
) 05:06, 2021년 9월 4일 (UTC)[]
어느 시점에서는 이러한 미니티와 특수 사례의 끊임없는 "고정"은 합리적인 재설계와 보다 시급한 문제들에 자리를 내주어야 할 것이다. 그렇지 않으면 그것은 그 자체의 복잡성에 의해 붕괴될 것이다. 이 특별한 문제는 불필요하고 피할 수 있다. 이를 처리하는 방법은 이미 두 가지가 있는데, 즉 전체 필드에 마크업을 적용하거나 수천 개의 표기법을 피한다. 나는 문서가 제안된 변경사항을 어떻게 설명하여 이치에 맞는지를 보고 싶다. 소스 필드는 이미 복잡한 문서를 가지고 있으며, 이제 모듈의 전체 범위는 아마도 모든 인용문 중 <0.001>에 나타나는 사례를 다루기 위해 변경된다. 현재 범위는 적절하다: 편집자는 목록 구분자를 포함하는 필드(논론) 수준에 대한 지시를 받는다. 개별 목록 항목의 형식은 완전히 다른 수준이다. 모듈 수준에서 이것을 문서화하고 편집자에게 이러한 템플릿은 수천 개의 표기법을 사용하지 않으며, 그렇게 하면 디스플레이 문제가 발생할 수 있다고 말하는 것이 훨씬 간단할 것이다. 104.247.55.106 (토크) 14:13, 2021년 9월 4일 (UTC)[]
@104.247.55.106: 내 변경이 실행되면 문서의 변경은 전혀 필요하지 않다. 이렇게 하면 "Accept-this-as-is" 구문이 개별 목록 항목 또는 전체 문자열에서 작동한다는 현재 문서를 그대로 유지할 수 있기 때문에 설명서가 단순화된다. 대안으로 문서를 변경하여 개별 목록 항목에 대해 때때로 현행 표기법을 사용할 수 있지만 항상은 아니다. --Ahecht (TOKPAGE
) 18:12, 2021년 9월 4일 (UTC)[]
편집자가 매개변수 값의 일부에 마크업을 적용해야 하는 새로움이 단순화인가? 그런 것 같지 않다. 그러나 그 문제를 과장하지 않기 위해서. 내 의견일 뿐이다. 24.103.101.218 (대화) 23:27, 2021년 9월 4일 (UTC)[]
이러한 변화는 코드에 상당한 복잡성을 불러 일으키는데, 이미 무명에는 부족함이 없다. 또 다른 관심사는 추가 런타임이다. 비록 작지만, 그것은 단지 예외적인 경우를 지지하기 위해서 모두에게 추가될 것이다. 그리고 왜 페이지 번호로 쉼표(또는 세미콜론)를 지원하려고 하는가? 코드와 문서화는 전체 문자열에서만 작동한다고 말해 코드와 문서 모두를 단순화시키겠다. Kanguole 09:14, 2021년 9월 5일 (UTC)[]

언어 추가

안녕.

지원되는 ISO 639-2 3문자 코드의 목록에 ajp(사우스 레반타인)와 apc(노스 레반타인)를 추가하려면 어떻게 해야 하는가?

다른 아랍의 품종들은 이미 aeb(투니시안), arq(알제리안), ars(나즈디), ary(모로칸), arz(이집트인), shu(차디안)가 지원되어 있기 때문에 나는 레반틴 품종(남과 북)은 아랍 세계에서 가장 많이 사용되고 널리 이해되고 있는 것만큼 잘 알려져 있어야 한다고 생각한다. A455bcd9 (대화) 08:18, 2021년 9월 7일 (UTC)[]

안녕 @Ira Leviton:,
레반타인 아랍어 편집본 봤어 너는 해결책이 없다고 썼다. 정말 그럴까? 어째서 다른 아랍 품종은 지원되지만 ajp와 apc는 지원하지 않는 것일까? 우리는 그들이 지원되는 코드 목록에 포함되게 한 것과 같은 과정을 따를 수 없었는가?
당신이 제공할 수 있는 모든 도움에 감사함 :) A455bcd9 (대화) 08:45, 2021년 9월 9일 (UTC)[]
그것이 바로 그 이유야. MediaWiki가 인식하지 못함 ajp , 그리고 apc:
{{#language:ajp en}} → agp
{{#language:apc en}} → apc
그러나:
{{#language:aeb en}} → 튀니지 아랍어
다음과 같이 쓸 수 있다.
language=South Levantine Arabic
language=North Levantine Arabic
그 언어는 여전히 인정받지 못하겠지만 적어도 인용된 것이 그렇게 애매하지는 않을 것이다.
{{Cite book title=Gospel of St. Mark in South Levantine Spoken Arabic last1=Bishop first1=E. F. F. last2=George first2=Surayya date=1940 location=Cairo language=ajp oclc=77662380}}
Bishop, E. F. F.; George, Surayya (1940). Gospel of St. Mark in South Levantine Spoken Arabic (in ajp). Cairo. OCLC 77662380.CS1 maint: 인식되지 않는 언어(링크)
{{Cite book title=Gospel of St. Mark in South Levantine Spoken Arabic last1=Bishop first1=E. F. F. last2=George first2=Surayya date=1940 location=Cairo language=South Levantine Arabic oclc=77662380}}
Bishop, E. F. F.; George, Surayya (1940). Gospel of St. Mark in South Levantine Spoken Arabic (in South Levantine Arabic). Cairo. OCLC 77662380.CS1 maint: 인식되지 않는 언어(링크)
MediaWiki가 지원하도록 제안할 수 있음 ajp , 그리고 apc 페이브리케이터에 표를 제출해서
—스승 (대화) 11:48, 2021년 9월 9일 (UTC)[]
고마워
사실 나는 2021년 7월에 티켓을 개통했다. 여기서 나는 문제가 해결되었다고 생각했다.
보아하니 이건 또 다른 문제인 것 같아. 여기 위키다타 출품작과 관련한 티켓이 2018년 개설(2021년 6월 업데이트)됐다. 관련이 있을 수도 있어? 그래서 거기서 새 티켓을 열었어. A455bcd9 (대화) 12:17, 2021년 9월 9일 (UTC)[]
@A455bcd9:
Mediawiki에서 인식한 언어 및 코드의 전체 목록은 Template에 있다.인용_Style_documentation/언어/doc 의 많은 출품작들은 미디어위키에 의해 인식되지 않는 언어 코드 때문에 무기한 그곳에 갇혀 있다. 코딩에는 모두 그렇게 쓰여 있는 노트가 숨겨져 있다. 나는 그 노트의 일부를 추가했다.
나도 네가 했던 것처럼 표를 추가해서 인식되지 않는 언어 태그를 모두 추가하도록 노력할 거야.
Ira Leviton (대화) 21:59, 2021년 9월 9일 (UTC)[]
고마워!
이 문제는 인용 템플릿보다 더 광범위하기 때문에 정말 도움이 될 것이다: 그것은 분명 이러한 언어의 항목이 추가될 수 없는 위키다타에도 영향을 미친다. A455bcd9 (토크) 07:41, 2021년 9월 10일 (UTC)[]
Wikidata 추가는 추가적인 노력이 필요하며 자체적인 작업이 있어야 한다. 이즈노(토크) 13:20, 2021년 9월 10일 (UTC)[]

언어 이름/태그 재정의, 제거

또 다른 대화에서는 미디어에 변화가 있었다는 것을 상기시켰다.위키 언어 이름 지원.

예전에 미디어위키가 'Criman Turkey'를 언어 태그에 할당했던 적이 있었다. crh 그러나 지금:

{{#language:crh en}} → 크림타타르

cs1 2는 태그를 재정의하여 crh '크리먼 타타르'에게, 그 오버라이드는 더 이상 필요하지 않다.

나는 미디어위키가 지원하는 IETF와 같은 언어 태그를 더 잘 다루기 위해 언어 처리 코드를 몇 개 수정했다. 그렇게 하면 다음 작업을 수행할 수 있다. nrf-GG (게르네시아스) 그리고 nrf-JE (제리아리스) 오버라이드 테이블에서.

{{cite book/new title=Title language=crh}}

Title (in Crimean Tatar).

{{cite book/new title=Title language=Crimean Tatar}}

Title (in Crimean Tatar).

{{cite book/new title=Title language=nrf-gg}}

Title (in Guernésiais).

{{cite book/new title=Title language=Guernésiais}}

Title (in Guernésiais).

{{cite book/new title=Title language=nrf-je}}

Title (in Jèrriais).

{{cite book/new title=Title language=Jèrriais}}

Title (in Jèrriais).

재정의가 중단되지 않음: {{cite book/new title=Title language=ksh-x-colog}}

Title (in Colognian).

{{cite book/new title=Title language=Colognian}}

Title (in Colognian).

비강화물이 파손되지 않은 경우: {{cite book/new title=Title language=es}}

Title (in Spanish).

{{cite book/new title=Title language=Spanish}}

Title (in Spanish).

인식되지 않는 언어 태그 및 이름: {{cite book/new title=Title language=xax}}

Title (in xax).{{cite book}}: CS1 maint: 인식되지 않는 언어(링크)

{{cite book/new title=Title language=abcdefgh}}

Title (in abcdefgh).{{cite book}}: CS1 maint: 인식되지 않는 언어(링크)

—스승 (대화) 15:18, 2021년 9월 9일 (UTC)[]

[템플릿:인용책] 본래의 언어와 제목이 무엇인지를 나타낼 방법이 없는가?

작업 템플릿:인용문에는 작품의 원어와 제목을 추가할 수 있는 매개변수가 없는가? Veverve (대화) 17:59, 2021년 9월 11일 (UTC)[]

Veverve, 당신은 인용문에 실제 언어로 된 실제 제목을 사용해야 한다 - 그것을 영어로 번역하지 마라. 로저(Dodger67) (토크) 18:24, 2021년 9월 11일 (UTC)[]
@Dodger67: 상황이 이렇다:내가 영어로 번역한 책(내가 아니라 책의 번역기로 번역한 책)이 있다면, 책의 원어와 제목을 표시할 수 있는 곳이 없을까? Veverve (대화) 18:27, 2021년 9월 11일 (UTC)[]
(ec) 번역되지 않은 원작을 인용하는 경우에 해당하며, 이 경우 원제목이 제목이 되고, 영어 번역이 (필요한 경우) trans-title=로 갈 수 있다. 만약 당신이 영어 제목이 있는 영어로 번역하는 것을 인용하는 것이라면, 영어 제목은 제목이 제목 필드에 들어간다.나이젤 이스 (토크) 18:31, 2021년 9월 11일 (UTC)[]
Veverve 그것은 출판된 번역에 적용된다. 만약 당신이 영어 이외의 원작을 인용한다면 당신은 출처로부터의 간단한 인용과 번역본을 제공할 수 있다. 템플릿:를 참조하라.관련 매개 변수에 대한 인용 책#인용을 참조하십시오. 로저 (Dodger67) (토크) 18:42, 2021년 9월 11일 (UTC)[]
나는 영어 제목 케이스가 있는 영어로 번역된 작품을 인용하고 있다. 그렇다면 번역 제목 앞에 원어와 원어를 어떤 파라미터에 추가할 수 있을까? Veverve (대화) 18:51, 2021년 9월 11일 (UTC)[]
한 번에 그것은 종이접기 날짜= 분야(즉, 종이접기 날짜와 같은 스머싱=1934년 처음 "Le Jardin de Les Flics"로 출판되었다)에 들어갈 수 있다. 인용문은 독자가 그것을 찾고 그 내용을 확인할 수 있도록 충분한 정보를 주기 위한 것이다.나이젤 이스 (토크) 19:02, 2021년 9월 11일 (UTC)[]
(편집-갈등) 이미 명시적으로 언급되지 않았기 때문에 인용된 책이 영어로 되어 있지 않다면 그 언어는 다음에 명시되어야 한다. language= 매개 변수
만약 당신이 출판된 영어 번역본에서 다른 언어로 쓰여진 책을 인용하고 있다면, 물론 이것은 적용되지 않는다. 만약 그 책이 번역본이라는 것을 나타내는 것이 유용하다면, 당신은 번역기를 다음과 같이 지정할 수 있다. translator-last=/ translator-first=. 원어 또한 알아야 할 중요한 경우 인용, 즉 템플릿의 닫힘과 닫힘 사이에 코멘트를 추가할 수 있다. </ref>. 나는 전형적으로 (NB)처럼 포맷한다. 이것은 프랑스어로 "xyz"라는 제목의 원작을 번역한 것이다. 어떤 경우에는, 외국어 원판을 다음과 같은 다른 인용문에 언급하는 것 조차 유용할 수 있다. <ref name="TranslatedWork">...</ref><ref name="OriginalWork">...</ref>또는 같은 것으로 묶음 <ref>...</ref> 같은 입장 <ref>Work translated into English; Work in original language.</ref>
--Matthiaspaul (talk) 19:08, 2021년 9월 11일 (UTC)[]
위에 언급된 번역기 매개변수와 함께, 영어로 번역된 책의 경우 자유 형식 매개변수 orig-year= 사용될 수 있다(예: orig-year=originally published [year] in [language] as [foreign title].선택적으로 외국 타이틀을 따라 나는 종종 (외국)을 추가한다. location: publisher 점 분리기 뒤에 외국 원본을 위치 및 출판사의 추가로 더 쉽게 찾을 수 있다고 생각하지만, 나는 실질적인 개념 증명서가 없다. 68.173.76.118 (대화) 01:37, 2021년 9월 12일 (UTC)[]
출판 장소와 출판사도 분명히 유용하지만(번역된 작품에도 역시 유용하다), 이 모든 정보가 이미 알려져 있다면 이는 암시만을 의미하는 것이 아니라 그 나름대로의 인용을 구성한다. 나는 ISBN이나 정확한 페이지 번호를 원본에서 알 수 없더라도 별도의 {{cite 책자로 옮기는 것이 더 적절하다고 생각한다. 이렇게 하면 번역뿐만 아니라 원작에 대해서도 적절한 메타데이터가 생성될 것이고, 따라서 원작의 사본을 찾는 것이 매우 쉬워질 수 있다.
--Matthiaspaul (talk) 08:50, 2021년 9월 12일 (UTC)[]
불필요한 인용문을 하나 더 추가하면 더 복잡해질 것 같다. 번역기 매개변수를 검증하는 독자에게 유용함을 알 수 있다(같은 출판사와 다른 번역기가 있을 수 있다). 다음과 같은 원본 정보의 유용성도 알 수 있다. orig-year= 작품의 첫 판을 가리키는 데 도움이 될 수 있을 겁니다 이것은 디테일이며 또 하나의 긴 토론이지만 요지는 제1판이 대부분의 경우 확정판(저자가 만든 수정판/조정을 포함하는 판외)으로 간주된다는 것이다. 출판사/작업 편집자에 따라 판본마다 미묘한 차이가 있을 수 있다. 위키텍스트 기고자가 판별 차이에 근거하여 사실을 주장할 수 있는 매우 드문 경우에서 그러한 차이를 비교하는 것은 중요하다. 아니면 사실로서 클레임을 확립하는 것을 돕기 위해 에디션 쇼핑을 하러 간다. 독자에게 원본을 찾는데 힌트를 주는 것도 좋지만 유용성이 매우 협소하기 때문에 완전히 새로운 인용문을 추가하는 것은 볼 수 없다. 65.88.88.57 (토크) 11:53, 2021년 9월 12일 (UTC)[]

HTML 마크업

@트래피스트 스님:안녕하십니까! 이 되돌리기에서 제기된 질문에 답하기 위해 Sbb는 사용자 토크에서 스레드를 시작했다.Beland#인용 템플릿 내의 템플릿, HTML 및 HTML 엔티티 사용. MOS:FRAC와 위키피디아에 부합하기 위해 (인용을 포함한) 기사를 바꾸느라 그런 일이 생긴 것 같다.스타일/위첨자 및 첨자 설명서와 현재 지침에서는 유니코드 사전 컴파일 분수, 상위 첨자, 첨자 대신 HTML 마크업으로 작성된다. 위첨자, 분수(사전 컴파일 문자로 사용할 수 없는 문자 포함), 기울임꼴 및 필드의 기타 마크업을 처리하는 방법을 설명하는 권위 있는 COinS 규격을 찾을 수 없었다. 나는 sb가 마크업 대신 유니코드 문자를 사용한다고 반대 없이 옹호하고 있다고 생각했고, 나는 당신의 관심을 받았을 때 그것을 반영하기 위해 가이드라인을 바꾸기 시작했다. sbb는 또한 위키백과 강연에서 반대가 있었다고 지적했다.스타일/요약서 및 첨자 설명서. 그래서, 필요하다면 철자 검사 코드와 가이드라인 페이지를 업데이트 할 수 있도록 여기서 어떤 합의가 이루어졌는지에 대한 설명을 들을 수 있도록 토론하는 것이 좋을 것 같다. 어떻게 해야 할지 몇 가지 가능성이 있다.

  • 가능한 경우 유니코드 문자 사용(대개의 경우 100% 표시는 피하기 어려움)
  • 필요한 경우 HTML을 사용하여 MOS 지침을 따르되 원치 않는 HTML 마크업을 스푸핑하는 경향이 있으므로 템플릿을 피하고 다운스트림 소비자가 구문 분석하기를 기대하십시오. <sup>...</sup> 등
  • Headbombum이 제안한 대로, 표시 목적으로 위키피디아 지침을 따르되, 인용 템플릿이 다운스트림 COinS 소비자에게 노마크업 유니코드로 변환된 출력물 또는 특정 경우에 필요한 모든 것을 제공하도록 코드를 작성한다.

생각? -- 벨란드 (대화) 02:59, 2021년 9월 12일 (UTC)[]

나는 트라피스트는 아니지만, 참고문헌에 유니코드 대체물을 사용하자는 당신의 제안과 참고문헌의 수학 형식에 대한 적절한 대체물이 될 수 있다는 함축에 전적으로 반대한다. 그들은 적절한 대체품이 아니다. 특히 응용이 매우 제한적이며, 한계에 도달할 때 요구되는 적절한 수학 형식과 외관상 양립할 수 없는 경우가 많다. —David Eppstein (대화) 04:33, 2021년 9월 12일 (UTC)[]
COinS 메타데이터는 다음에서 전송된다. title="..." 빈 HTML 속성 <span>...</span> 속성도 있는 요소 class="Z3988". HTML 속성에는 어떤 종류의 마크업도 포함될 수 없으므로 마크업을 제거하기 위해 소독을 할 수 없는 경우에는 처음부터 생략해야 한다. --Redrose64 🌹 (토크) 07:22, 2021년 9월 12일 (UTC)[]
@Redros64: 마크업이 거기에 나타날 수 있지만, 암호화 되어 있어야 한다. Sbb가 내 토크 페이지에 남긴 예들은 백분율 인코딩을 사용하므로, 예를 들면 <sup>은 로 암호화된다. %3Csub%3E. 다른 필드(페이지의 URL과 같이)도 백분율 인코딩을 사용하는 것처럼 보이므로 다운스트림 소비자는 당연히 백분율 디코딩을 하지 않을 것으로 예상할 수 있는가? 그 디코딩의 결과는 HTML이나 노마크업 유니코드, MathML 또는 그 무엇이든 될 수 있다. -- Beland (talk) 16:49, 2021년 9월 12일 (UTC)[]
내 결론은, 차라리, 코인이 정확한 참조를 나타낼 수 없다면, 우리의 참조가 부정확하도록 강요하기 위한 구실로 사용하지 말고 코인을 떨어뜨려야 한다는 것이다. 꼬리가 개를 흔들고 있다. 우리는, 말하자면 Pintér, Ákos처럼 서류를 인용하는 것이;Weger 드, 벤저민 M.M.(1997년)수 있어야 한다."210=14×15=5× 6×7자 모양(212)=(104){\textstyle 210=14\times 15=5\times 6\times 7={\binom{21}{2}}){\binom{10}{4}}}". Publicationes Mathematicae 데브레첸. 51(1–2):175–189.MR1468225..때문에 전산기 정보 시스템 같은 제목을 대표하는 할 수가 없다 만약 우리 COINS 변환"rft.atitle=MATH+RENDER+ERROR"처럼 쓰레기 생산한다면, 그 nowrap 따옴표와 제목의 시작, 혹은 더 나쁜 사람들 사이의 끔찍한 배관 파손을 방지하기 등에서, 심지어 s을 지정할 수 있는 것을 막아 주는 것을 막아 주uch 제목, 그렇다면 문제는 CONESS. 메타데이터 스크래핑 수정 방법을 다른 방법으로 찾아 보십시오. —David Eppstein (토크) 07:24, 2021년 9월 12일 (UTC)[]
이 "MATH+RENDER+ERROR"는 우리가 감각적인 메타데이터를 생성할 수 없는 수학 객체를 위해 삽입한 자리 표시자 입니다. 이미 정확히 지적된 바와 같이, COinS는 기본적으로 일반 텍스트를 원하지만, 모든 데이터가 암호화되기 때문에 HTML 제목=속성이 허용하는 것으로 한정되지 않으며, 또한 거의 모든 종류의 다른 것들을 전달할 수 있다. 문제는 수신기에서 '다른 것'이 말이 안 된다는 점이다. 내 생각에, 제목에 가끔 다음과 같은 간단한 마크업이 들어 있는 한. <sup></sup> 이것은 심지어 사람에 의해서도 정확하게 구문 분석될 수 있을 만큼 충분히 쉽지만, 대부분의 수학적인 것들은 더 복잡하다.
이런 경우 다른 COinS 생산자들은 무엇을 하는가?
수학을 ASCII로 변환하는 표준 표기법이 예전 뉴스그룹 게시물에서 있었는가? 그렇다면 수학 블록을 이렇게 번역해서 메타데이터의 일부로 만들 수 있을 겁니다.
어떤 경우에는 모든 표시를 벗겨내고 평범한 텍스트와 숫자만 남기는 끈을 만들 수도 있는데, 이는 여전히 인간이 제목을 인식하거나 검색 패턴으로 작업하기에 충분할 정도로 좋은 것일 수 있지만, 이상적이지는 않을 것이다.
그러나 또 다른 해결책은 소위 서술적 제목을 제공하는 것일 수 있다. descriptive-title= 적절한 칭호 외에 title= 그리고 적절한 제목이 너무 복잡하여 메타데이터에 사용할 수 없는 경우에는 기술 제목을 대신 전달한다. --Matthiaspaul (토크) 09:34, 2021년 9월 12일 (UTC)[]
네가 지금 랩에 대해 한 말은 더블 인용과 타이틀 시작 사이의 끔찍한 대목을 막는 것에 대해, 나는 아직 이것을 본 적이 없다. 예를 들어줄 수 있나? --Matthiaspaul (대화) 09:43, 2021년 9월 12일 (UTC)[]
나는 지금 네가 위에 있는 nowrap을 사용해서 예를 추가한 것을 보았기 때문에 더 이상 이것은 필요하지 않다. 여기서 당신의 말을 설명하기 위해 지금 함정이 없는 예를 들 수 있다.
Pintér, Ákos; de Weger, Benjamin M. M. (1997). "". Publicationes Mathematicae Debrecen. 51 (1–2): 175–189. MR 1468225.
--Matthiaspaul (talk) 11:53, 2021년 9월 12일 (UTC)[]
가장 명심해야 할 것은 인용문이 정보 발견 도우미라는 점이며, 인용문이 지니고 있는 데이터는 출처 정보가 제시하는 대로 가장 쉽게 찾을 수 있는 형식이어야 한다는 점, 즉 "재미있는" 문자와 모든 것을 담고 있다는 점이다. "출처 정보"에 의해 나는 다양한 분류 데이터베이스의 작업에 대한 색인 항목을 의미하며, 이것은 출처를 발견할 때 독자가 제시할 것이다. WP에 관계없이:MOS는 부차적인 것이라고 말한다. 그리고, COinS가 이 데이터를 적절히 대표할 수 없을 경우 COinS를 떨어뜨리자는 제안은 적합하다. 65.88.88.57 (대화) 12:12, 2021년 9월 12일 (UTC)[]
COinS는 실제로 그 자체로 어떤 것을 '표현'하는 것이 아니라 Open을 이용하여 데이터를 전송하는 방법이다.구조화된 방식으로 URL. 우리는 데이빗의 예에 담긴 수학 blob을 수신자에게 전달하는 데 아무런 문제가 없을 것이다. 문제는 수신자가 그것을 전혀 이해하지 못할 가능성이 높다는 것이다. 그리고 오히려 그들에게 단지 이상한 2진수 데이터의 blob에 지나지 않는 것, 우리는 최소한 타이틀의 나머지가 usefu이기를 바라는 자리 표시자를 삽입한다.나는 수신자가 그것을 이해할 수 있을 만큼 충분히.
나는 이 문제에 대한 믿을 만한 해결책을 가지고 있는 또 다른 메타데이터 표준에 대해 알지 못한다. 너는?
당신이 언급한 색인 항목에 관하여, David의 예와 같은 작업이 당신의 분류 데이터베이스에 어떻게 표현될 것인가? 문제는 시각적 외관뿐만 아니라 그것이 거기에 어떻게 암호화되어 있는지와 관련되어 있다. 이것은 적절한 제목에서 파생될 수 있는 것인가, 아니면 서술적인 제목인가?
--Matthiaspaul (토크) 12:53, 2021년 9월 12일 (UTC)[]
David가 COinS나 어떤 메타데이터에 관해 위에서 언급했듯이, 이것은 문제를 잘못된 관점에서 바라보고 있다. 모든 종류의 메타데이터 표현(현재로서는 OpenURL의 근본적인 문제는 잊어버리자)은 이차적인 것이다. 이것은 (인류독자에게) 자료를 제시하는 것에 관한 것이다. 수학작품의 전문 데이터베이스를 포함한 참조 데이터베이스는 참조/분류 데이터베이스가 이상한 데이터 입력 쿼리를 가지지 않는 한, 작업 자체에 나타나는 대로 입력된 데이터를 사용하여 인덱스를 작성한다. 인용문은 "있는 그대로" 인덱스 데이터를 통과해야 하는데, 이는 극히 소수의 예외만 제외하고 기초 소스를 찾는 가장 쉬운 방법이기 때문이다. 그만큼 간단하다. 유니코드, COinS 또는 다른 어떤 것이라도 그것을 처리할 수 없다면, 그들은 밖으로 나가야 한다. 98.0.246.242 (대화) 13:52, 2021년 9월 12일 (UTC)[]
마티아스폴: https://publi.math.unideb.hu/searchb.php의 목록에는 이 논문이 "1998 = 14 × 15 = 5 × 6 × 7 = {21 2} = {10 4}"로 표시되어 있다. 그 클릭 가능한 링크는 JPEG를 표시하는 https://publi.math.unideb.hu/load_jpg.php?p=391으로 연결된다. -- Michael Bednarek (대화) 14:00, 2021년 9월 12일 (UTC)[]
고마워, 마이클 도움이 됐어 그러나 그것으로부터 패턴을 도출하기 위해서는 더 많은 그러한 예, 더 복잡한 예들이 필요하다. --Matthiaspaul (토크) 20:18, 2021년 9월 12일 (UTC)[]
다른 사이트들이 참조 제목을 제대로 표시하지 않는 것이 우리가 같은 일에 실패하는 핑계가 되어서는 안 된다. 그 사이트에서 실제 종이로 연결되는 pdf 링크는 그것이 어떻게 포맷되어야 하는지를 보여준다. —David Eppstein (대화) 21:48, 2021년 9월 12일 (UTC)[]
IP와 David에게 오해를 받은 것 같아. 나는 이 말을 한 적이 없다. 정반대의 말이다. 나는 변명하는 것이 아니라 해결책을 찾고 있는 것이다.
그러나 제안된 바와 같이 COinS를 끄는 것은 좋은 생각이 아니다. 그것은 여전히 유용한 정보를 전달하기 때문이다. 최악의 경우 불쾌감을 주는 데이터만 음소거해야 하며, 기본적으로 "MATH+RENDER+ERROR" 자리 표시자로 지금 바로 그렇게 해야 한다.
PDF도, 제안된 대로, 도움이 되지 않을 것이다. 그것은 단지 이진일 뿐이고, 인쇄된 책 제목 사진이나 지역 렌더링의 그래픽 이미지를 넘겨주는 것과 크게 다르지 않다. 우선, 우리는 사진이나 PDF를 수신자의 끝에서 볼 수 있다고 가정할 수 없지만, 검색에도 사용할 수 없다. 우리에게 필요한 것은 어떤 기계식, 그리고 사람이 읽을 수 있는 공식 표기법으로서 텍스트로 인코딩되어 검색 패턴이 그것으로부터 파생될 수 있도록 하는 것이다. 그래서 나는 그러한 경우에 다른 COinS 생산자들이 어떤 것을 전송하고 있는지, 그리고 그러한 작품 제목들이 외부 데이터베이스의 (텍스트) 제목 항목에 어떻게 저장되어 있는지 묻고 있었다.
--Matthiaspaul (talk) 16:37, 2021년 9월 15일 (UTC)[]

두 가지. 1) 유니코드 문자 없음. 저것들은 불찰이며, 눈에 보이는 대로 숙청해야 한다.2) 독자와 정확한 정보 렌더링이 우선이다. COinS가 처리할 수 없으면 COinS를 나사로 처리하십시오. COinS를 준수하지 않는 것을 COinS를 준수하지 않는 것으로 변환하기 위해 마법 코데푸를 수행할 수 있는 경우(예: COinS를 준수하는 것) ''H''<sub>x</sub>20<sup>6</sup> → H_{x}20^{6} 또는 COinS 표준이 무엇이든), 훌륭하지만 편집자가 정확한 렌더링을 희생하도록 요구해서는 안 된다. 헤드폭탄 {t · c · p · b} 14:51, 2021년 9월 12일(UTC)[]

몇 가지 고려 사항 및 질문:

  • 나는 MOS: SEQUILITY를 인용구에 일반적으로 적용하기 때문에, 우리는 일반적으로 문장 부호 및 기타 특수 문자를 원본 자료에서와 같이 그대로 두지 않고 위키백과 스타일에 맞게 변경하고 있다고 생각한다. 대부분 이것은 직설적인 인용 부호를 사용하는 것에 관한 것이다. 더 이국적인 경우는 어떤 사람이 모든 칠판에 굵은 글씨로 트윗을 할 때인데, 이것은 위키백과 인용문의 모든 대문자로 표현된다.
  • 인용문의 특수 등장인물을 정리할 때, 나는 종종 모히바케나 다른 잘못 처리 때문에 우리가 인용하고 있는 문서에서 잘못된 제목을 발견하곤 한다. 나는 항상 그것을 수정해서 눈으로 위키피디아를 읽는 사람이 진짜 제목을 볼 수 있도록 한다. 그러나 만약 그들이 특정 데이터베이스를 검색하고 있다면 그들은 그 제목을 말 그대로 찾을 수 없을지도 모른다. 그래서 나는 이론상 "사람들이 원본을 찾을 수 있도록 정확하게 복사"하는 아이디어를 좋아하지만, 실제로 우리는 양립할 수 없는 많은 다른 데이터베이스와 어떤 경우에는 표현이 깨진 것을 통합하고 있다. 대안은 "위키피디아에 대한 일관된 표현을 사용"이며, 만약 우리의 표현이 합리적이라면, 다른 데이터베이스들이 (위키피아를 검색하는 웹사이트는 말할 것도 없고) 검색할 때 같은 것을 사용하거나 최소한 우리의 표현을 정상화 할 수 있기를 바란다. 최악의 경우 저널, 작성자, 날짜 등을 사용하여 검색 매개변수로 제목이 없는 저널 기사 전문을 찾을 수 있어야 하는데, 이는 분명 이상적이지 않다.
  • COinS를 위한 위키피디아 결과물은 마크업 이슈에 대한 공식적인 표준이 없어 보이고 우리는 주요 웹 사이트이고 그것을 사용하는 사이트가 많지 않기 때문에 실제로 표준 수용 형식(및 COinS의 인기 여부에 영향을 미칠 수 있다)에 영향을 미칠 수 있다. 우리는 또한 COinS에 나열된 다른 사이트들을 볼 수 있고 그들이 특별한 캐릭터들을 어떻게 다루는지 볼 수 있다.
  • 과학 및 수학 기사의 경우, MOS:FRAC는 우리가 {{sfrac}}이나 "1/2"와 같은 ASCII 분수를 사용할 수 있다고 말한다. 일반 기사에는 {{frac}}만 사용해야 한다. 그렇다면 MOS: SQUILITY 접근법을 사용하는 경우 MOS:FRAC를 변경하여 모든 유형의 기사에 ASCII 분율만 사용하는 것이 바람직한 결과인가? (물론 더 복잡한 수학 공식의 일부가 아니라면) 아니면 HTML 마크업으로 COinS 출력을 오염시키는 비용을 들여서 약 {{frac}}을(를) 사용해야 할까?

-- Beland (대화) 17:29, 2021년 9월 12일 (UTC)[]

우리의 스타일 가이드라인이 우리 자신의 텍스트에서 같은 의미의 공식에 대해 다른 스타일을 사용하라고 지시할 때 조차 참조가 포맷된 방식을 참조에 공식으로 인용해야 한다. 따라서 예를 들면 다음과 같이 인용하는 것이 옳을 것이다. Bandukwala, J.; Shay, D. (February 1974). "Theory of free, spin-½ tachyons". Physical Review D. 9 (4): 889–895. doi:10.1103/physrevd.9.889. 여기서 유니코드 ½을 사용해 보았지만 {{frac 1}}}}을(를) 사용하는 것이 좋을 것 같다. ½과 템플릿이 버그라는 것을 허용하지 않음: 위치 22(도움말)의 템플리트 프리스타일 스트립마커 —David Eppstein (토크) 18:57, 2021년 9월 12일 (UTC)[]
이 제목에 대한 COinS 데이터에는 스트립마커(전송하는 것이 타당하지 않으므로 경고)가 포함된다.
&rft.atitle=Theory+of+free%2C+spin-%7F%27%22%60UNIQ--templatestyles-0000001B-QINU%60%22%27%7F%3Cspan+class%3D%22frac%22+role%3D%22math%22%3E%3Cspan+class%3D%22num%22%3E1%3C%2Fspan%3E%26frasl%3B%3Cspan+class%3D%22den%22%3E2%3C%2Fspan%3E%3C%2Fspan%3E+tachyons
우리는 스트립마커를 떼어내고 남은 HTML을 전달할 수 있다. 디코딩하면 다음과 같은 문자열이 나올 것이다.
Theory of free, spin-<span class="frac" role="math"><span class="num">1</span>⁄<span class="den">2</span></span> tachyons
다음과 같이 멋지게 렌더링(배터링)한다.
자유, 스핀 ½ 타키온 이론
그러나 수신기의 끝에서 HTML 렌더링 엔진을 가정할 수 있는 경우에만(불행히도 그럴 수 없다).
속성을 자동으로 제거하면 HTML:
Theory of free, spin-<span><span>1</span>⁄<span>2</span></span> tachyons
또는 다음과 같은 간단한 경우:
Theory of free, spin-1⁄2 tachyons
다음 기간:
자유, 스핀 ½ 타키온 이론
메타데이터를 완전히 음소거하는 것보다 이것을 전달하는 것이 확실히 더 낫지만, 이것은 분명히 모든 경우에 작용하는 좋은 해결책은 아니다.
아마도, 코드는 이미 특정 수학 스트립마커로부터 COinS 메타데이터에 대한 유용한 텍스트를 추출했을 것이다. alt= 속성:PNG, 일반 텍스트(TeX) 또는 내용 <annotation> MathML을 사용하는 요소) 그러나 이것이 모든 경우를 포함하지는 않는다. 이것을 더 개선하려고 노력할 가치가 있을 수도 있지만, 우리는 또한 아마도 또한 필요했을 것이다. descriptive-title= 편집자가 메타데이터로 전달해야 할 내용을 스스로 지정할 수 있도록 허용한다.
--Matthiaspaul (talk) 20:18, 2021년 9월 12일 (UTC)[]
만약 당신이 "자유, 스핀 ½ 타키온의 이론"이 "아주 잘" 렌더링한다고 생각한다면, 당신은 2가 거대하고 /에 의해 덮어쓰여지는 나의 것과 매우 다른 브라우저 설정을 사용하고 있을 것이다. 또한, 우리는 코인에 맞추기 위해 참조를 다시 작성해서는 안 된다. 다시 작성되어야 할 것은 코인 메타데이터에 나타나는 것뿐이다. "TeX를 사용한 일반 텍스트"의 경우: no. TeX에서 현재 구현을 통해 얻을 수 있는 것은 코인 메타데이터의 "MATH+RENDER+ERROR"이다. —David Eppstein (대화) 21:44, 2021년 9월 12일 (UTC)[]
음, 그래서 내가 "거의"라고 썼어. ;-) 기본적으로, 우리는 여기서 동의해. 여기서 중요한 것은 의미 정보를 이월한다는 것이지, 예쁘게 보인다는 것이 아니다. 우리의 CSS 정의는 수신자의 끝에서 이용할 수 없으며, 그래서 내 예가 약간 왜곡되어 보이는 것이다. 그러나 다른 렌더링 엔진의 출력에는 항상 차이가 있을 것이다. 이것이 우리의 인용구 표시에 사용된다면 문제가 되겠지만, 메타데이터 목적에는 별로 문제가 되지 않는다. 우리에게 필요한 것은 메타데이터의 시각적 표현이 아니라 수학의 정확한 의미적 서술이다.
--Matthiaspaul (talk) 16:37, 2021년 9월 15일 (UTC)[]
이전 토론: 도움말 대화:인용 스타일 1/Archive 19 § 산술 ml 렌더링 변경사항 및 메타데이터
페이브리케이터에서 추적됨
과제 T138229
예전에는 수학 스트립마커의 내용을 추출할 수 있었고 그 내용으로부터 메타데이터에 넣을 수 있는 인간이 읽을 수 있는 방정식의 복사본을 추출할 수 있었다. 수학 스트립마커에 있던 것은 기사를 마지막으로 저장한 편집자의 수학 선호 설정에 달려 있었다. 다음은 이 방정식 예제의 예였습니다. 
<산술 디스플레이=14\times15=5\times6\times7=\binom{21}{2}=\binom{10}{4}</math>
다양한 산술 기본 설정의 경우:
MathML(SVG 또는 PNG 폴백 포함)(현대 브라우저 및 내게 필요한 옵션 도구 권장) 
<>class="mwe-math-element"> 깨끗합니다;<>class="mwe-math-mathml-inline mwe-math-mathml-a11y"style="디스플레이:아무도."> 깨끗합니다;<, 수학 xmlns="http://www.w3.org/1998/Math/MathML"alttext="{\textstyle 210=14\times 15=5\times 6\times 7={\binom{21}{2}}){\binom{10}{4}}}">,<>semantics>,>mrow class="MJX-TeXAtom-ORD">, <,mstyle displaystyle=."거짓"scriptlevel="0">,<>mn>, 210<./mn>,<>mo>, =<, /mo>,<>mn>, 14<, /mn>,<>mo>,&#x00D7,>!--×--><>/mo>,<>mn>, 15<, /mn>,<>mo>, =<, /mo>,<>mn>, 5<, /mn>,<>mo>,&#x00D7,>!--×--><>/mo>,<>mn>, 6<, /mn>,<>mo>,&#x00D7,>!--×--><>/mo>,<>mn>, 7<, /mn>,<>mo>, =<, /mo>,<>차례예요아야 class="MJX-TeXAtom-ORD">,<>mrow>,<>mrow class="MJX-TeXAtom-OPEN">,<>mo maxsize="1.2em"minsize="1.2em">.(<>/mo>,<>/mrow>,<>mfrac linethickness="0">,<>mn>, 21<, /mn>,<>mn>, 2<, /mn>,<>./mfrac>,<>mrow class="MJX-TeXAtom-CLOSE">,<>mo maxsize="1.2em"minsize="1.2em">^<>/mo>,<>/mrow>,<>/mrow>,<>/mrow>,<>mo>, =<, /mo>,<>mrow class="MJX-TeXAtom-ORD">,<>mrow>,<>mrow class="MJX-TeXAtom-OPEN">,<>mo maxsize="1.2em"minsize="1.2em">.(<>/mo>,<>/mrow>,<>mfrac linethickness.="0">,<>mn>, 10<, /mn>,<>mn>, 4<, /mn>,<>/mfrac>,<>mrow class="MJX-TeXAtom-CLOSE">,<>mo maxsize="1.2em". Minsize="1.2em">^<>/mo>,<>/mrow>,<>/mrow>,<>/mrow>,<>/mstyle>,<>/mrow>, <, 주석 encoding="application/x-tex">,{\textstyle 210=14\times 15=5\times 6\times 7={\binom{21}{2}}={\binom{10}{4}}}<>/annotation>,<>/semantics>,<>/math>,<>/span>,<>img src=".https://wikimedia.org/api/rest_v1/media/math/render/svg/4012a8a0261dae95c0a7443dbf67dcb58800df0c"class="mwe-math-fallback-image-migration="true" style="bari-migration: -1.005ex; width:40.087ex; 높이:3.343ex;" alt="{\textstyle 210=14\cs15=6\binom 7={2}}={{10}}}}}}}}}}}}}}}}/>
LaTeX 원본(텍스트 브라우저용): 
<span class="mwe-math-fallback-source-ltr" dir="ltr"$ {\textstyle 210=14\5\niform 6={\binom {21}={\binom{10}{4}}}${\span}
PNG 이미지: 
<img src="https://wikimedia.org/api/rest_v1/media/math/render/png/4012a8a0261dae95c0a7443dbf67dcb58800df0c" 계급="mwe-math-fallback-image-properties" 아리아를 함유한="진짜" 문체를 하다="높이: -1.005ex, 너비:40.087ex, 높이:3.343ex;" 알트="{\textstyle 210=14\data 15=5\data 6\data 7={\binom {21}{2}}={\binom {10}{4}}}}}" />
PNG의 경우, 우리는 의 내용을 가져갔다. alt= 속성; LaTeX의 경우 쌍을 이룬 것 사이의 모든 것을 가져갔다. $...$; MathML을 위해 우리는 의 내용을 가져갔다. <annotation>...</annotation> 꼬리표를 달다
그리고 나서, 갑자기, 그 능력은 우리에게서 빼앗겼다; Phabrication 링크를 보라. 수학 스트립마커는 메타데이터를 통해 cs1 2 인용문을 소비하는 누구에게나 전적으로 무의미하기 때문에, 나는 스트립마커를 다음과 같은 텍스트로 대체했다. MATH+RENDER+ERROR. 이를 제외하고 나머지 메타데이터는 모두 정확하다. 
<span ...>... &rft.genre=article &rft.jtitle=Publicationes+Mathematicae+Debrecen &rft.atitle=MATH+RENDER+ERROR &rft.volume=51 &rft.issue=1%E2%80%932 &rft.pages=175-189 &rft.date=1997 &rft_id=%2F%2Fwww.ams.org%2Fmathscinet-getitem%3FMR%3D1468225%23id-name%3DMR &rft.aulast=Pint%C3%A9r &rft.aufirst=%C3%81kos &rft.au=de+웨거%2C+벤자민+M+M. </span>
따라서 메타데이터를 통해 인용문을 소비하는 독자는 출처를 찾을 수 있을 것 같다(특히 제목이 방정식보다 더 중요한 경우). 이런 '고치기'에도 불구하고, 실제로 어떤 일이 일어나게 되는가. &rft.atitle= 문서를 마지막으로 저장한 편집자의 기본 설정에 따라 다름:
PNG: 
&rft.atitle=%3Cspan+class%3D%22nowrap%22%3E%7B%5Cdisplaystyle+210%3D14%5Ctimes+15%3D5%5Ctimes+6%5Ctimes+7%3D7%7B%7Bbinom+%7B21%7D7%7D2%7D3D%7%7D7%7B%7B%7B%5Cbinom+%7%7B10%7D%7B4%7D7%7D%7D%3C%2Fspan%3e
LaTeX: 
&rft.atitle=%3Cspan+class%3D%22nowrap%22%3E210%3D14%5Ctimes+15%3D5%5Ctimes+6%5Ctimes+7%3D7%7B%7Bbinom+%7B21%7D7%7D2%7D3D%7%7D7%7B%7B%7B%5Cbinom+%7%7B10%7D%7B4%7D%7D%3C%2Fspan%3e
매트릭스ML 
&rft.atitle=%3Cspan+class%3D%22nowrap%22%3EMATH+RENDER+ERR%3C%2Fspan%3e
세 가지 사건이 모두 언급했던 것을 떠올리는 것 같아 이 문제를 마지막으로 살펴본 이후 이런 행동은 새로운 것이라고 생각한다. MATH+RENDER+ERROR 메타 데이터에서 아아, 우리는 편집자들에게 PNG나 LaTeX 렌더링을 사용하도록 강요할 수도 없고, MediaWiki가 우리에게 수학 스트립마커에서 콘텐츠를 추출할 수 있는 능력을 되돌려주도록 강요할 수도 없다.
내가 생각할 수 있는 유일한 방법은 수학 점수를 포함시키는 것이다. title= 대안이 있는 것이다. math-title= 아니면 특별한 비밀 마크를 필요로 하는 그런 어떤 것. <math>...</math> 보통 어떤 것이든 포장할 수 있는 태그 <math>...</math> 예를 들어 태그:
math-title=A title with some text and $210=14\times15=5\times6\times7=\binom{21}{2}=\binom{10}{4}$ and yet more text
그런 다음 모듈은 할당된 값의 복사본을 만든다. math-title= 특수 비밀 마크업을 제거하고 그 결과를 메타데이터에 넣는다. 그러면 모듈이 특수 비밀 마크업을 실제 개폐로 대체하게 된다. <math>...</math> 태그를 지정한 다음 수학 제목을 렌더링하는 특수 템플릿을 사전 처리하십시오. 그러면 렌더링은 title=그래, 꽤 못생겼는데 그게 먹힐지 모르겠어
이 검색은 약 650개의 기사를 찾아낸다. title= A과 함께 <math> 꼬리표를 달다 title= 매개변수는 cs1 2)와 연관된다.
—스승 (대화) 23:19, 2021년 9월 12일 (UTC)[]
아주 간단한 개념 증명. 샌드박스 모듈을 해킹했어 텍스트 문자열을 단일 매개 변수로 사용 math-title= 을 가질 수도 있고 그렇지 않을 수도 있다. $ 구분된 수학 텍스트 일치하는 의 쌍을 찾을 경우 $ 구분 기호, 구분 기호를 다음으로 바꾼다. <math display=inline> 그리고 </math> 그런 다음 해당 문자열을 사전 처리하여 인용문 제목에 사용할 수 있는 연산 렌더링을 얻으십시오.
{{#invoke:Sandbox/trappist_the_monk/math math-title math-title=$210=14\times15=5\times6\times7=\binom{21}{2}=\binom{10}{4}$}}
수학 제목: = = =( ) ={\ 메타데이터: $210=14\times15=5\times6\times7=\binom{21}{2}=\binom{10}{4}$
원본 값: math-title= 메타데이터에 있는 그대로 사용될 수 있는 이유는 $ 구분 기호는 LaTex / TeX에 'native'이다.
수행할 작업: 탈출 지원 \$ (수학 텍스트에 '
가 표시됨), 수학 텍스트가 아닌 일반 텍스트에 '