모듈 토크:일반 텍스트
Module talk| 이 모듈은 2018년 5월 5일에 삭제될 것으로 고려되었습니다.토론의 결과는 "합의 없음"이었습니다. |
strip_snotrophe_snots
@갤러벗:string.gsub() 함수는 매우 관대하므로 각 대소문자에 대해 테스트할 필요가 없습니다.또한 '는 검색 패턴으로 사용할 때 이스케이프할 필요가 없습니다.strip_apostrophe_markup 함수는 의미 있게 내보낼 수 없으므로 로컬 함수이거나 인라인 함수여야 합니다.strip_apostrophe_markup을 다음과 같이 단순화할 수 있습니다.
local function strip_subrophe_sub(txt) txt = txt:gsub("''', "):gsub("'', "":gsub("'', "):gsub("'', "" 반환 txt 끝 주 기능에서 텍스트는 로컬 변수여야 합니다.
로컬 텍스트 = frame.args[1]
다른 사람들이 코드를 개발하는 동안 코드를 변경하는 것을 좋아하지 않으므로, 당신이 적합하다고 생각하는 대로 업데이트하도록 남겨두겠습니다. -- RexxS (talk) 19:56, 2018년 4월 14일 (UTC)
- RexxS의 두 번째 포인트 - 네, 현지화하는 것을 잊었습니다 - strip_apostrophe_markup(txt)과 관련하여, 예, 저도 왜 그렇게 많은 if 등이 있는지 궁금했지만, 검토하기가 너무 귀찮았습니다(보시다시피, 저는 방금 모듈에서 복사했습니다).인용문/CS1/COINS).모듈에서 동일한 변경을 수행해야 하는지 궁금합니다.인용/CS1/COINS - 2018년 4월 14일 (UTC) :05 Galobter (pingómió)에 대한 수도승 Trappist 답변
- 모듈이 다른 언어로 재사용될 가능성이 높기 때문에 새로운 코드가 간단하지는 않지만 여전히 문제가 없기 때문에 ustring 라이브러리를 사용하는 것이 가장 좋습니다.수고하셨습니다! -- RexxS (talk) 20:36, 2018년 4월 14일 (UTC []
- 감사합니다! 네, 쉽게 재사용할 수 있어서 좋습니다. 게다가 우리 자신도 가끔 유니코드 문자를 사용하는 곳이 있을 거예요. 갤로버트(핑고미오) 20:43, 2018년 4월 14일 (UTC)
- 우리는 때때로 장소에 유니코드 문자를 사용하지만, 흥미롭게도 string.gsub는 제가 시도한 모든 라틴어 분음 부호와 그리스어 또는 키릴 문자와 완벽하게 일치합니다.모듈 토크:RexxS #테스트 스트립A 게시.거의 틀림없이 실패하는 캐릭터들이 있겠지만, 흔하지는 않을 것입니다. -- RexxS (대화) 21:16, 2018년 4월 14일 (UTC) [
- 감사합니다! 네, 쉽게 재사용할 수 있어서 좋습니다. 게다가 우리 자신도 가끔 유니코드 문자를 사용하는 곳이 있을 거예요. 갤로버트(핑고미오) 20:43, 2018년 4월 14일 (UTC)
- 모듈이 다른 언어로 재사용될 가능성이 높기 때문에 새로운 코드가 간단하지는 않지만 여전히 문제가 없기 때문에 ustring 라이브러리를 사용하는 것이 가장 좋습니다.수고하셨습니다! -- RexxS (talk) 20:36, 2018년 4월 14일 (UTC []
나는 ustring이 gsub보다 훨씬 느리고 이 모듈에서 필요하지 않기 때문에 mw.ustring.gsub을 plain gsub으로 대체했습니다.최적화는 필요하지 않지만 사람들이 코드를 보고 있기 때문에 저는 위키텍스트가 항상 UTF-8을 사용할 것이며 이 모듈의 패턴을 가진 루아섭이 잘 작동할 것이라는 것을 언급할 가치가 있다고 생각했습니다.루아섭은 다음과 같은 패턴을 가진 모든 언어로 작동합니다.'[12]'('1' 또는 '2') 그러나 mw.ustring.gsub은 다음과 같은 패턴에 필요합니다.['১২'](이는 벵골어 위키백과에서 동등한 것을 검색하는 데 사용될 수 있습니다.)첫 번째 경우(Luagsub)에서 패턴은 다음 사이의 바이트 중 하나와 일치하는 첫 번째 위치를 찾습니다.[그리고.]벵골어의 경우 UTF-8에서 각 자리는 3바이트이므로 대괄호 사이에 6바이트가 있습니다.Luagsub을 사용하면 해당 바이트를 찾을 수 있습니다.Johnuniq (대화) 2018년 4월 18일 09:47 (UTC [
들여쓰기를 제거할 수 있습니다.
선행 공백과 결합할 수 있습니다.gsub("^[:;%s]+", "") 2021년 5월 24일 (UTC) 20:31, 20:31 (talk)[
샌드박스의 성능 향상(및 기타)
Module을 사용한 작업을 기반으로 샌드박스에서 이 모듈의 성능을 몇 가지 개선했습니다.모듈을 사용하기 시작한 사용자 스크립트 테이블:일반 텍스트를 사용하면 필요에 따라 포크를 사용하여 커스터마이징할 수 있습니다.두 가지 성능 향상은 다음과 같습니다.
- 탐욕스러운 사용가능할 때마다 ungreedy .-x 대신 [^x]+x; 그리고
- 모든 파일:, 범주:, 미디어: 등에 대해 각 gsub 대신 단일 gsub를 사용합니다.
𝐆𝐚𝐫𝐩𝐢𝐚𝐧𝐠𝐚𝐫𝐚𝐮☎ ☎ 2021년 6월 21일(UTC) :48 답변
nowiki 텍스트가 제거되었습니까?
설명서의 예는 다음과 같습니다.<nowiki>?</nowiki>(노위키 태그의 물음표).
모듈은 물음표를 포함하여 이 위키 텍스트를 모두 제거합니다.왜 이 "다른 것들"은 제거되어야 합니까? -디피프 (대화) 13:41, 2021년 9월 2일 (UTC) [
태그 제거
현재 이 모듈은 다음을 제외한 모든 HTML 스타일 태그에 대한 태그와 내용을 모두 제거합니다.<span>,<i>,<b>,<em>,그리고.<strong>(그리고 마지막 세 개는 사례를 추가했기 때문입니다.)그러나 위키 텍스트에서 유효하고 태그 자체를 폐기한 후 보관해야 하는 내용 등 다양한 태그가 있습니다.<h2>,<dfn>,<sup>,<u>여기에 개별적으로 추가할 수는 있지만 모듈의 동작을 되돌리고 큐레이션된 목록에 대한 태그의 내용만 삭제하고, 그렇지 않으면 내용을 유지하는 것이 더 간단하다고 생각합니다.
제가 볼 수 있는 주요 문제는 다음과 같습니다.<sub>그리고.<sup>여기서 단순히 "232"를 벗기면 "232" 또는 "ve"가 생성되어 "ve"가 생성되는 등 혼동되는 텍스트가 종종 발생합니다. 이러한 경우 태그를 "^"/"_"(앞에서 언급한 예제의 경우, "2^32"와 "v_e"의 출력) 또는 다른 적절한 문자로 대체하는 것이 더 나을 수 있습니다.포맷 옵션이 제한된 경우 슈퍼/슈퍼를 나타내는 데 가장 자주 사용됩니다.)「ディノ奴千?2021년☎ Dinoguy1000 10월 6일 04:13 (UTC) [
- 합리적입니다. 특히 화이트리스트/블랙리스트가 체계적으로 논쟁될 때 더욱 안정적입니다.모듈 기록에 따르면 이 방법은 결코 체계적으로 접근하지 않았습니다.
- 이제, 문서에는 "짧은 설명에서 제거해야 하는 다른 것들"이라는 특이한 문장이 있습니다.WP:SHORTDESC, WP:SDFORMAT용으로 제작된 것 같습니다.하지만 실제로 {{짧은 설명}}에서 사용되지 않았습니다. WP:WP SHORTDESC?그리고 기존 1M+ 사용량(즉, 모듈; {{일반 텍스트}: 35k)에 어떤 영향을 미칩니까?이를 위해 제안된 확장 제거는 별도의 기능에 포함됩니까? -DePiep (talk) 06:06, 2021년 10월 6일 (UTC)
- 모듈을 편집하고 이 토론을 시작하기 전에 원래 의도가 SHORTDESC를 위한 것이라는 것을 알았지만, 실제로 모듈이 현재 사용되고 있는지 확인하지는 않았습니다. 그렇지 않다는 것이 약간 재미있습니다.
- 솔직히 말해서, 저는 이 변화가 현재 사용에 어떤 영향을 미칠지 전혀 모르겠습니다.성능이 크게 문제가 되지 않는 경우에는 특정 태그가 제거되는 경우에 대한 추적을 추가하고 해당 태그를 살펴보고 흥미로운 내용이 나타나는지 확인하기 전에 필터링할 시간을 조금 더 주면 됩니다.즉, 대부분의 사용은 다른 템플릿 또는 모듈을 통해 이루어질 것으로 예상됩니다. 일부 빠른 검색에서는 이 기능이 최대 3개의 템플릿 및 모듈에서만 직접 사용되고 있으며, 이는 손으로 살펴보는 것이 그리 어렵지 않을 것입니다(TBH는 제가 무엇을 찾고 있는지는 모르지만).
- 그렇다면 어떤 태그를 완전히 버려야 할까요?명백한 사실이 있습니다.
<br />(매우 견고하지는 않지만 이미 벗겨져 있음), 그리고 현재 사용되지 않는 것.<hr />,<wbr />대부분(대부분이?)의 파서/스캐너 태그(그리고 아마도)<!-- comment -->표시되지는 않지만);<table>그리고.<div>적어도 가끔은 그들의 콘텐츠를 유지해야 한다는 주장을 분명히 볼 수 있었지만, 잠재적인 후보자들입니다(그래서 어떻게든 그들을 선택적으로 만들 수 있을까요?). - 반대로, WP:HTML을 통해 보면 생각납니다.
<abbr>아마도 그것과 유사한 구체적인 고려가 필요할 것입니다.<sup>/<sub>의 내용<bdi>/<bdo>원래 문자열 그대로 표시할 수도 있지만, 저는 이 분야의 전문가가 아니기 때문에 적어도 약간의 논의가 필요할 것입니다. - 저는 이 시점에서 이 논의에서 벗어나고 있지만, 앞서 생각한 후에 템플릿을 제거하는 가장 좋은 방법은 템플릿/모듈이 선택적으로 일부 내용을 유지하면서 일종의 "일반 출력" 모드를 갖는 것이며, 이는 이와 같은 애플리케이션이나 WP:NAVPOP,현재 대부분의 템플릿을 완전히 삭제합니다.이를 위해서는 상당한 작업과 구현에 대한 계획/검토가 필요할 것이 분명하지만(나 자신에 대한 생각은 많지 않지만, 템플릿 데이터에 "안전한" 매개 변수를 표시하기 위해 템플릿 데이터에 일부 기능을 추가하여 직접 출력하는 것이 한 가지 아이디어일 수 있습니다.)「ディノ奴千?2021년☎ Dinoguy1000 10월 6일 08:39 (UTC) [
- 관련 내용을 확인하기 위해 {{Navbox wikite text-handling templates}}을(를) 시작했습니다. -DePiep (talk) 20:06, 2021년 10월 6일 (UTC)
링크 스트리핑
어쨌든 오늘 이 모듈에 대해 생각해 본 결과, 여기 링크 스트리핑이 모듈이 수행한 스트리핑과 중복된다는 것을 깨달았습니다.Delink, 아마도 덜 강건하고 (내 생각에는?) 사례를 많이 잡지 못합니다.모듈만 사용하는 것이 아니라 성능 이외의 주요 이유가 있습니까?이 모듈의 해당 기능에 대한 링크를 해제하시겠습니까?「ディノ奴千?2021년☎ Dinoguy1000 10월 6일 08:42 (UTC) [
- "비아스키" 스트리핑에 대한 보다 일반적인 접근 방식이 필요합니다.HTML, html-태그, wm-확장 태그, {{!}}]], 파서-스트립 등 -디피프 (토크) 20:27, 2021년 10월 6일 (UTC) [
<sup>/<sub>의 내용 유지
(#태그 스트리핑이 오래되어 사이드 코멘트로 이 태그만 터치하므로 새로운 주제 시작)
WP:VPT#Wikilinks에서 한 편집자의 문제(선박 이름의 이탤릭체)에 대한 해결책으로 이 템플릿을 발견했지만, 다른 관련 용도(화학 이름)에 대한 상위 스크립트/서브스크립트 텍스트 중단에 대한 보존이 부족했습니다.일반적인 목표는 적절하게 형식화된 시각적 텍스트를 파란색 링크로 변환하는 것입니다.하지만 현재 그러한 용도로는 제대로 작동하지 않는 간단한 예로서, 우리는 원합니다.H<sub>2</sub>O(HO2) "HO"가 아닌 "H2O"가 되는 것.<sup>3</sup>HH가3 아닌 3H가 되기 위해. 디맥스 (토크) 16:04, 2022년 6월 26일 (UTC) [
- 이것은 21번 라인 때문에 발생합니다.21행 앞에 다음 행을 추가하여 수정할 수 있습니다.
:gsub('<sub.->(./sub>, '%1') --첨자 마크업 제거; 내용 유지:gsub('<sup.->(./sup>, '%1') --위스크립트 마크업 제거; 내용 유지
- 주의 사항: 테스트되지 않음
- —Trapist the monk (talk) 16:25, 2022년 6월 26일 (UTC) [
- 저는 이 기능을 다시 한 번 요청하기 위해 이곳에 왔습니다.기존의 행동과 사용법을 고려할 때, 저는 이것이 매개변수에 의한 옵트인이 되어야 한다고 제안합니다.
"keep-tag-content"=T [F-by-default](또는 포크별) - 기타 태그 내용을 보관하시겠습니까?
<sup>,<sub>,<hn>,<dfn>,<u>?<nowiki>알 수 없는 코드 주입으로 인해 내용을 유지할 수 없습니다. - #태그 제거에서: 교체
<sup>... ^" 또는 일반 공백 등을 사용합니까?옵션으로? - 드피프 (대화) 2023년 2월 21일 (UTC) 07:53 [
- 저는 이 기능을 다시 한 번 요청하기 위해 이곳에 왔습니다.기존의 행동과 사용법을 고려할 때, 저는 이것이 매개변수에 의한 옵트인이 되어야 한다고 제안합니다.