모듈 토크:네임스페이스 검출

Module talk

매개 변수 별칭 허용

안녕하세요 스트라디바리우스 씨!

설정을 변경할 수 있습니까?cfg.main,cfg.talk,cfg.other,cfg.subjectns,cfg.demospace그리고.cfg.page파라미터 이름의 에일리어스가 되는 문자열 배열(및 하위 호환성을 위해 문자열만)을 가져오려면 어떻게 해야 합니다.이 모듈을 다른 Wiki로 이식하는 것은 도움이 됩니다.영어 파라미터명과 변환 파라미터명이 모두 받아들여지는 것이 일반적이기 때문입니다( 참조).{{{Localized parameter {{{English parameter }}}}}}또는 같은 파라미터에 대해2개의 다른 변환도 가능합니다.헬더wiki 19:23, 2014년 3월 6일 (UTC)응답[응답]

모듈에서 발생할 수 있는 성능 문제:네임스페이스_detect

내 사용자 토크 페이지에서 여기로 이동했습니다.- Stradivarius님♪ talk ♪ 09:37, 2014년 3월 20일 (UTC)답글[답글]

안녕하세요 귀찮게 해서 죄송합니다저는 단지 이 문제를 당신에게 알려주고 싶었어요.

모듈: Namespace_detect는 일부 성능 문제의 근원으로 보입니다.예를 들어 모듈 때문이라고 생각합니다.Namespace_detect는 List_of_에서 편집을 미리 보는 데 약 30초가 소요됩니다.Unicode_문자

리스트Unicode_characters는 큰 페이지입니다.그러나 대부분의 시간은 모듈을 호출하는 유니코드 차트 중 몇 개에 의해 소비된다고 생각합니다.템플릿을 통해 간접적으로 Namespace_detect:랭

예를 들어 다음과 같습니다.

 위해서 nsid, ns 에 쌍들(음.위치.subject 네임스페이스) 하다   한다면 nsid ~= 0 그리고나서 -- 메인 네임스페이스를 제외합니다.    현지의 nsname = 음.스트링.더 낮게(ns.이름.)    현지의 표준명 = 음.스트링.더 낮게(ns.표준명)    매핑[nsname] = {nsname}    한다면 표준명 ~= nsname 그리고나서     table.insert(매핑[nsname], 표준명)    끝.    위해서 _, 에일리어스 에 아이페어(ns.에일리어스) 하다     table.insert(매핑[nsname], 음.스트링.더 낮게(에일리어스))    끝.   끝.  끝.
  • 이 코드는 15회 루프하는 것에 주의해 주세요(15개의 서브젝트네임스페이스가 있기 때문에).
  • 각 루프는 mw.ustring.lower를 2회 호출합니다(간단하게 하기 위해 mw.ustring.lower(에일리어스)는 무시해도 됩니다).
  • 따라서 템플릿의 경우:Unicode_chart_Kannada, mw.ustring.lower (86 * 15 * 2)에 대한 2,580 콜이 있습니다.
  • 페이지에는 lang을 호출하는 Unicode 차트가 몇 개 더 있습니다.예: Template:유니코드 차트 미얀마
  • 이 페이지를 편집한 결과 mw.ustring.lower에는 약 100,000개의 콜이 있습니다.
  • mw.ustring.lower와 Language:lc는 비교적 단순한 프로세서이지만 Lua/PHP를 오갈 경우 오버헤드가 발생합니다.초당 3,300콜의 콜에서도, 상기의 편집 내용을 프리뷰 하려면 30초가 걸립니다.

나는 또한 이 상황의 변형이 다른 페이지에서도 반복되고 있다고 믿을 만한 이유가 있다.참고로 저는 XOWA(오프라인 위키앱)의 개발자로 영어 위키피디아 440만 건의 메인스페이스 기사를 매달 파싱하고 있습니다.모듈:네임스페이스_detect는 가장 시간이 많이 걸리는 # 호출 중 하나로 플래그가 지정됩니다.오늘 밤까진 왜 그랬는지 모르겠어

getParamMappings를 새 모듈로 이동하는 것이 좋습니다.Namespace_detect/Data 페이지에서 "return mw.loadData"('Module:네임스페이스_detect/Data'''이 변경은 간단하며 성능이 향상되지만 휴대용 cfg 테이블을 유지하려면 모듈을 변경해야 합니다.

더 필요한 정보가 있으면 알려주세요.

감사해요.

gnosygnu 2014년 3월 20일 08:28 (UTC)응답[응답]

템플릿/모듈 토크페이지에 링크만 있으면 됩니다.아마도 Mr.S는 이 모든 것을 옮기고 싶은가?이 문제에 대해서는 조사하지 않았지만, 네임스페이스를 여러 번 검출할 필요는 없어져야 합니다(분명히!).10초 동안 조사한 결과, {{Lang}}은(는) 카테고리를 추가할지 여부를 결정하기 위해 호출할 때마다 네임스페이스를 검출하는 것으로 추측됩니다.이는 {{Lang}}개의 유니코드 문자를 여러 번 사용하고 있는 목록과 같은 페이지에서 너무 과장되어 있습니다.현명한 템플릿코더는 모든 오버헤드를 생략하기 위해 사용할 수 있는 파라미터를 추가해야 합니다.Johnuniq (토크) 09:27, 2014년 3월 20일 (UTC)응답[응답]
(편집 충돌) Gnosygnu님 안녕하세요, 자세한 분석 감사합니다!모듈:네임스페이스는 제가 Lua에 대해 잘 모르던 시절로 거슬러 올라가 봐야겠다고 생각했습니다.이제 모듈도 몇 개 늘어났기 때문입니다.(아마도) 이전 Wikitext 버전보다 더 빠를 것입니다만, 확실히 상황을 개선할 수 있습니다.확인해 보고, 제안하신 내용을 실행해 보고, 그 외에 변경해야 할 사항이 있는지 알아보겠습니다.베스트 — Stradivarius님♪ talk ♪ 09:34, 2014년 3월 20일 (UTC)응답[응답]
잘못된 배치에 대해 사과드립니다.gnosygnu 03:08, 2014년 3월 21일(UTC)응답[응답]

페이지 내용을 이것으로 대체해 주세요.이로 인해 getParamMappings는 위의 설명에 따라 #invoke당1회가 아니라 페이지당1회만 실행됩니다.Jackmcbarn (대화) 2014년 3월 20일 (UTC)응답[응답]

잠시만요. 라이브로 올리기 전에 코드를 변경하고 싶은 것이 있습니다.예를 들어, 현재 우리는 통과된 모든 논쟁을 확장하고 있다.페이지가 호출된 네임스페이스에 필요한 것만 펼치는 것이 좋습니다.그리고 위의 Helder의 제안도 실천하고 싶습니다.- Stradivarius님♪ talk ♪ 2:32, 2014년 3월 21일 (UTC)응답[응답]
제안해 주셔서 감사합니다.이제 두 가지 변경을 가했습니다.
  • p.getParamMappings는 퍼블릭이고 다른 모듈에서 호출하기 때문에 다시 추가했습니다.예를 들어 Module:Category_handler에는 다음이 있습니다.local mappings = nsDetect.getParamMappings()
  • 나는 그것이 바뀌어야 하는지 확신하지 못했다. 나는 그것을 현재 버전으로 되돌렸다. 고의로 변경한 경우 언제든지 버전을 되돌릴 수 있습니다.이건 고의로 한 것 같아죄송합니다.
그렇지 않으면, 내 기계에서 제한된 테스트에서 정상적으로 테스트되었습니다.
FWIW: 10만 콜의 최초 추정치는 85,000 콜에 가까운 것 같습니다.즉, 모듈에는 약 2,833개의 콜이 있었습니다.네임스페이스_detect.(85,000 / (15 * 2))
이 페이지는 matchesBlacklist 함수의 약 27,000 콜 b/c를 계속 수행합니다.이는 위의 수치와 관련이 있습니다: 27,000 콜 / 9개의 블랙리스트 용어 => 모듈에 대한 3,000 콜:카테고리_핸들러matchesBlacklist는 정적 변수가 될 수 없으며 no_cat = false가 기본이므로 쉽게 수정할 수 있을지 모르겠습니다.
어쨌든 List_of_는 떨어졌으면 좋겠어요.Unicode_문자는 렌더링에 6~8초(현재 약 30초)gnosygnu 03:08, 2014년 3월 21일(UTC)응답[응답]
mw: 를 사용할 수 있습니다.내선번호:Template Sandbox를 테스트합니다.(또한 Template Sandbox의 문서에도 도움이 된다면 도움이 필요할 것입니다.)Anomie⚔ 2014년 3월 22일 12:26 (UTC)응답[응답]
@Anomie: 링크 감사합니다.이전에는 이 확장에 대해 몰랐습니다.
지금 시도해 봤는데 결과가 엇갈렸어요.동일한 프로파일 렌더 시간(25초)이 표시되지만 Lua 프로파일테이블은 확실히 다릅니다.
리스트Unicode_문자
Lua 프로파일:스크라이브런토...Lua Sandbox Callback : : get All Expanded Arguments 4540 ms 49.3% Scribunto _Lua Sandbox Callback : : lc 1660 ms 18.0 % Scribunto _Lua Sandbox Callback : : match 1140 ms 12.4% recursive Clone <mw.lua : 109 > 620 ms 6.7% Scribunto _Lua Sandbox Callback ::gsub 360 ms 3.9% 타입 100 ms 1.1% (제너레이터의 경우)100 ms 1.1% <MW.languagelua:87> 80 ms 0.9% getParamMappings < 모듈:Namespace_detect:69>80 ms 0.9% Scribunto_Lua Sandbox Callback : : load Package 60 ms 0.7% [기타] 460 ms 5.0 %
샌드박스
Lua 프로파일:스크라이브런토...Lua Sandbox Callback : : get All Expanded Arguments 3420 ms 57.0 % Scribunto _Lua Sandbox Callback : : match 760 ms 12.7% recursive Clone <mw.lua : 109 > 540 ms 9.0 % Scribunto _Lua Sandbox Callback:: gsub 320 ms 5.3% 데이터랩퍼 <mw.lua:698> 140 ms 2.3% (제너레이터용) 140 ms 2.3% 스크리번토_Lua Sandbox Callback : : get Expanded Argument 140 ms 2.3% 타입 120 ms 2.0% Scribunto_Lua Sandbox Callback::lc 60ms 1.0% <mw.title.lua:50> 60ms 1.0% [기타] 300ms 5.0%
확실히 샌드박스는 새로운 변경을 받아들이고 있습니다(LC는 18%에서 1%로 떨어집니다).올바른 접두사를 사용하고 있는 것이 확실합니다.Gnosygnu/샌드박스.User와 같이 잘못된 프레픽스를 사용하는 경우:Gnosygnu/sandbox_invalid, 현재 페이지와 동일한 Lua 프로파일을 가져옵니다.
나중에 더 가지고 놀겠지만 알려주고 싶었어요.더 자세히 조사해보니 LuaSandbox보다 LuaStandalone에서 여러 lc Scribunto 호출이 더 극적인 영향을 미친다는 생각이 들기 시작했습니다.아마 LuaStandalone이 모든 메시지를 앞뒤로 시리얼링하기 때문일 것입니다.따라서 스페셜:TemplateSandbox는 매우 정확할 수 있습니다.새로운 변경에 의해 lc 콜의 수는 감소하지만 실제로는 의미 있는 효과는 없습니다(아마도1초 빨라집니다).현재 페이지의 성능 문제는 정기적인 템플릿 확장 때문일 수 있습니다.gnosygnu 2014년 3월 22일 (UTC) 16:47 (응답)

@Gnosygnu 및 Jackmcbarn:모듈 변경이 완료되었습니다.네임스페이스 탐지/샌드박스:

  • 구성을 다른 페이지로 이동했습니다.모듈:네임스페이스 검출/구성.이것은, 코드와 설정의 구별을 명확하게 하기 위해서입니다.
  • Helder의 제안도 실장했습니다.파라미터 설정 값은 문자열 배열 또는 문자열로만 지정할 수 있습니다.
  • 이것으로 모든 config 값은 옵션입니다.
  • 이제 p.main 함수는 Module을 사용합니다.인수, 즉 인수가 필요할 때만 가져옵니다(p._main으로 전달되기 전에 모두 확장되었습니다).
  • 또한 불필요한 루프를 피하기 위해 p._main 코드를 단순화했습니다.그 일환으로 p.main에서 p._main으로의 테일콜을 retval로 대체했습니다.이는 일치하는 것이 전혀 검출되지 않은 경우 모듈이 다른 Lua 모듈에 대해서는 0을 반환하고 #invoke에 대해서는 공백 문자열을 반환해야 함을 더욱 명확히 하기 위함입니다.이에 대한 이의가 있는 경우 언제든지 암묵적인 반환값으로 되돌릴 수 있습니다.
  • 마지막으로 네임스페이스가 순서대로 표시되도록 p.table 코드를 수정했습니다. talk=yes실제로 효과가 있습니다.

변경사항에 대해 어떻게 생각하시는지 알려주시고, 모든 것이 좋아 보이면 메인 모듈을 업데이트 할 수 있습니다.- Stradivarius님 2014년 3월 22일 (UTC)응답[응답]

@Stradivarius씨:변경해 주셔서 감사합니다.괜찮은 것 같아요.머신과 Template Sandbox에서 수정 테스트를 실시했습니다(위의 코멘트를 참조)."lc"는 더 이상 실행 시간의 중요한 부분이 아닙니다.일치시키기 위한 콜 수는 동일하지만 호출 템플릿을 변경해야 할 것 같습니다.FWIW, 자체 테스트(XOWA 사용)에서는 최신 변경과 성능 차이가 없습니다.이는 LuaStandalone vs LuaSandbox를 사용하고 있기 때문일 수 있습니다.(LuaSandbox는 Windows/Java 환경에서는 사용할 수 없습니다).다른 사과에서 오렌지에 대한 문제도 있을 수 있지만, 여전히 "lc"는 상당한 퍼포먼스 비용 gnosygnu 15:44, 2014년 3월 22일(UTC)응답[응답]
네, 최근에 변경한 내용이 대부분의 페이지에서 성능을 향상시키지 못할 것으로 예상했습니다.{{namespace detect}를 직접 사용하는 페이지의 경우 모듈로 전환합니다.그렇지 않으면 확장되었을 Wikitext에 따라 인수가 크게 증가할 수 있습니다.그러나 모듈의 대부분의 트랜스클루전스:네임스페이스 검출은 모듈을 통해 이루어집니다.카테고리 핸들러 및 이러한 용도는 변경의 영향을 받지 않습니다.당신의 독창적인 제안은 확실히 큰 퍼포먼스 세이버입니다.퍼포먼스 절감을 위해 페이지 파라미터와 데스페이스 파라미터를 삭제하는 것을 검토해 주십시오.그러면 mw.loadData로 네임스페이스 데이터를 캐싱할 수 있기 때문입니다.모듈에서도 같은 작업을 수행한 경우:카테고리 핸들러, 블랙리스트 체크도 캐시할 수 있습니다.그것의 단점은 모듈 테스트 케이스가 더 이상 작동하지 않는다는 것이지만, 나는 그 단점보다 성능상의 이점이 더 크다고 생각한다.모듈을 변경하여 다른 성능을 절감할 수 있습니다.필요한 경우에만 인수를 확장하는 범주 핸들러입니다.이 작업은 모듈을 사용하여 수행할 수 있습니다.인수 및 메타테이블을 사용하여 모듈에 인수를 전달합니다.네임스페이스가 프록시로 탐지되었습니다.- Stradivarius님♪ talk ♪ 2014년 3월 22일 (UTC)응답[응답]
좋아요, 설명해줘서 고마워요LuaSandbox와 LuaStandalone의 차이 때문에 "lc" 콜도 큰 차이가 없다고 생각하기 시작했습니다.(위의 코멘트를 참조).그렇다면 실제 퍼포먼스 문제는 모듈과 관련이 없을 수 있지만 무엇을 제안해야 할지 막막합니다. (템플릿?) gnosygnu 16:47, 2014년 3월 22일 (UTC)응답[응답]
@Stradivarius씨:테이블 조회를 피하기 위한 로컬 변수는 좋아하지 않습니다.이로 인해 코드가 더욱 혼란스러워지고 성능에 큰 도움이 되지 않는다고 생각합니다.그것 말고는 좋아 보이네요.Jackmcbarn (대화) 00:51, 2014년 3월 23일 (UTC)응답[응답]
이 모듈이 퍼포먼스가 그다지 중요하지 않은 모듈이었다면 저는 아마 당신의 의견에 동의했을 것입니다.그리고 저는 이 기술을 과도하게 사용한 것에 대해 유죄를 인정합니다.그러나 페이지가 해석될 때마다 루프를 호출하는 수만 개의 콜을 말한다면 충분히 가치가 있는 차이를 만들어 낼 수 있다고 생각합니다.이것은 Roberto Ierusalimschy의 Lua Performance Tips에 근거하고 있습니다.이것은 로컬 변수를 사용하는 것이 테이블 룩업을 사용하는 것보다 30% 빠릅니다.물론 거의 아무것도 아닌 것보다 30% 빠른 것은 여전히 거의 아무것도 아니기 때문에 코드를 읽기 쉽게 하기 위해 이러한 로컬 변수 중 일부를 테이블 룩업으로 다시 변경하는 것이 이치에 맞을 수 있습니다.특히 /data 페이지에서 사용하는 것은 중요하지 않다고 생각합니다.이는 mw.loadData로 캐시되기 때문입니다.단, #invoke마다 여러 번 호출되는 함수에 로컬 변수를 사용하는 것이 좋습니다.- Stradivarius님♪ talk ♪ 2014년 3월 23일 11:06 (UTC)응답[응답]
@Gnosygnu:실제 퍼포먼스 문제는 모듈과는 전혀 관계가 없습니다.이전 버전의 모듈을 사용하여 유니코드 문자 목록을 미리 봤을 때:네임스페이스 검출, 해석에 40초 걸렸지만 Lua 시간 사용량은 약 4.3초밖에 보고되지 않았습니다.나머지 36초는 루아가 아닌 다른 무언가에서 온 것이 틀림없어요.템플릿은 매우 가능성이 높은 후보입니다.현재 확장 후 크기는 1944444/2048000바이트이며 사용된 템플릿과 모듈은 207개입니다.다만, 이미지가 많은 페이지에서도 이러한 퍼포먼스의 문제가 발생하고 있습니다.이것은 WP에서 질문할 수 있는 좋은 질문입니다.VPT인 것 같아요.- Stradivarius님♪ talk ♪ 2014년 3월 23일 11:06 (UTC)응답[응답]
@Stradivarius씨:네, 미안해요처음에 프로파일을 확인했어야 했는데제 기계에서는 스크리번토에 대한 lc 콜이 훨씬 더 큰 영향을 미치지만, 저는 이것이 다음 이유라고 생각하기 시작했습니다.
  • 유니코드 문자 목록을 부분적으로 재구성했을 뿐 대부분의 템플릿은 가져오지 않았습니다.
  • Windows 를 사용하고 있기 때문에, Lua Standalone 을 사용하고 있습니다.Lua Standalone은 Lua에서 PHP로 모든 메시지를 직렬화합니다(반대로 위키피디아는 PHP를 Lua에 직접 연결하는 LuaSandbox를 사용합니다).
  • lc에는 85,000 이상의 콜이 있습니다.이 섹션을 건너뛰는 것으로 큰 차이를 알 수 있었습니다.
앞으로 파서 출력에 대해 좀 더 자세히 알아보겠습니다.또, 이쪽의 기계에 완전한 엔위키 환경을 설정해, 비교하기 쉽게 해 보겠습니다.
변경해 주셔서 감사합니다.그래도 도움이 되었으면 합니다.gnosygnu 21:07, 2014년 3월 23일 (UTC)응답[응답]
사과할 것 없습니다.당신의 우려는 완전히 타당합니다.이 모듈을 영어 위키피디아뿐만 아니라 모든 위키에서 잘 실행해 주셨으면 합니다.메인 모듈을 샌드박스 버전으로 업데이트했으므로, 우리의 노력이 성과를 거두었는지 알아보겠습니다. :) 이상한 일이 있으면 알려주세요.베스트 — Stradivarius님♪ talk ♪ 2014년 3월 24일 (UTC)응답[응답]
그래, 1초도 안 차이가 나는 것 같아.아, 그렇군요.(*syslog*)
변경해 주셔서 다시 한 번 감사드립니다.gnosygnu 2014년 3월 25일 (UTC) 02:43, 답장

모듈: 네임스페이스 검출/데이터

내 토크 페이지에서 이동했다.Stradivarius♪ talk ♪ 씨 2014년 3월 25일 14:30 (UTC)답글[답글]

안녕하세요. 여기 이 모든 것을 포함시켜야 할 타당한 이유가 있나요?local cfg = require('Module:Namespace detect/config')엔위키에서.구성 파일이 "빈" 상태입니다.Christian75 (대화) 2014년 3월 25일 09:13 (UTC)응답[응답]

모듈은 /config 페이지를 체크하여 처리해야 할 설정 차이가 있는지 확인해야 합니다.이를 통해 enwiki에서도 다른 언어를 사용하는 다른 Wiki와 동일한 기본 코드를 사용할 수 있습니다.이러한 차이가 /config 파일에 없는 경우 메인 모듈코드에 넣어야 합니다.즉, 현지화하는 모든 언어에 대해 다른 모듈을 작성해야 합니다.이것은 노동력을 절약하는 장치입니다.여기서 현지화 작업을 하지 않으면 모듈 코드를 직접 변경하는 것은 다른 Wiki의 편집자에게 맡겨집니다.나는 현지화에서 일하는 편집자들이 이 일을 하는 방식이 훨씬 이해하기 쉽다고 추측한다.퍼포먼스가 걱정되는 경우 /data 페이지에 mw.loadData가 로드됩니다.즉, 구성 테이블은 페이지별로 캐시되므로 로드 시 오버헤드가 최소화됩니다.- Stradivarius님♪ talk ♪ 2014년 3월 25일 (UTC)응답[응답]
아니면 그냥 바꿀 수도 있어요.
현지의 cfg = 요구하다('모듈:네임스페이스 검출/구성')

와 함께

-- local cfg = required('모듈:네임스페이스 검출/구성' -- 출력을 현지화하려면 이 행을 활성화하고 다음 행을 비활성화합니다.   현지의 cfg = {}

엔위키에서 99만 건의 환상이 일어났어Christian75 (토크) 2014년 3월 26일 10:35 (UTC)응답[응답]

그렇게 할 수 있지만 이는 사용자가 컨피규레이션파일뿐만 아니라 모듈을 설정하기 위해 모듈코드를 편집해야 함을 의미합니다.enwiki에 컨피규레이션파일을 로드하는 데 실제로 문제가 있고 트랜슬루전 카운트가 높은 모듈로는 충분한 이유가 없다고 생각합니다.- Stradivarius님♪ talk ♪ 2014년 3월 26일 11:01 (UTC)응답[응답]
문제가 있는 경우 모듈에 "no config" 인수를 전달할 수 있습니다.이 인수가 설정되어 있으면 설정 로드를 건너뜁니다.그러나 Stradivarius씨의 의견에 동의합니다.아마 오버헤드는 매우 작을 것이고 설정을 생략해도 아무것도 달성할 수 있다는 증거는 없습니다.모듈을 필요로 하는 데 상당한 시간이 걸리더라도(그렇지 않은 경우), 990만 페이지의 캐싱은 필요한 오버헤드가 여전히 작다는 것을 의미합니다.흥미로운 점은 메인 모듈은 데이터 모듈에서 "loadData"를 사용하고, 후자는 구성 모듈에서 "require"를 사용한다는 것입니다.loadData에 의해 금지되는 것이 config에 있으면 어떻게 되는지 궁금합니다.언젠가는 검사를 해봐야 할 것 같아요.Johnuniq (대화) 2014년 3월 26일 11:27 (UTC)응답[응답]
mw.loadData는 전달된 테이블을 스캔하여 잘못된 데이터를 수신하지 않았는지 확인합니다.(여기는 검증 코드입니다.)따라서 비활성 데이터는 /data 페이지에는 정상적으로 전달되지만 /data에서 메인 모듈로 테이블이 로드되면 오류가 발생합니다.하지만 네, 직접 시도해 보세요.:) - Stradivarius님♪ talk ♪ 2014년 3월 26일 12:39 (UTC)응답[응답]
또한 "no config" 인수를 체크하는 것은 /config 모듈을 로드하는 것보다 오버헤드가 클 수 있습니다.특히 인수로 간주되는 경우는 #invoke별로 체크되며 페이지별로 체크되는 것은 아닙니다.만약 누군가 테스트를 하고 싶어한다면 그 숫자를 보고 싶군요.Stradivarius님♪ talk ♪ 2014년 3월 26일 12:49 (UTC)응답[응답]
「공백」의 설정을 로딩해도 문제가 없다고는 생각되지 않습니다.내 생각에 그런 수표를 추가하는 것은 너무 복잡할 것 같다.Jackmcbarn (대화) 2014년 3월 27일 (UTC)응답[응답]

Talk의 WikiProject 배너 스크립트 오류:에어 마일리지

토크 상단에 있는 Wiki Project 배너:에어 마일리지에는 다음이 포함됩니다.

  • 이 스크립트 오류는 프로젝트의 품질 척도에 대한 평가를 요구하지 않습니다.
  • 이 스크립트 오류는 항공사 프로젝트에서 지원됩니다.

두 경우 모두 에러 메시지는 다음과 같습니다.모듈의 Lua error:32행의 namespace_detect: 인수 #1에서 'ipairs'(테이블 예상, 0).@Stradivarius: ping.Jackmcbarn (대화) 2014년 4월 13일 (UTC)응답[응답]

지금은 그 페이지에서 사라졌지만, 그 후 Talk에 게재되었습니다.불법 전공 및 토크:리오 니그로(신문사).Jackmcbarn (대화) 03:06, 2014년 4월 14일 (UTC)응답[응답]
마지막으로 모듈을 업데이트한 후에 오류가 캐시될 수 있습니까?/config 모듈을 업데이트한 후 /data 모듈을 업데이트한 후 몇 초 안에 스크립트 오류가 발생할 수 있습니다.이 모듈에 포함된 트랜슬레이션의 수를 고려할 때 일부는 그 이후로 계속 남아있을 가능성이 높습니다.페이지를 삭제한 후에도 오류가 계속 나타나면 알려주세요.- Stradivarius님♪ talk ♪ 2014년 4월 14일 04:23 (UTC)응답[응답]

2014년 5월 14일 편집 요청 보호

77.30.122.165 (대화) 2014년 5월 14일 08:20 (UTC)응답[응답]

Red question icon with gradient background.svg 미완료: 원하는 변경이 명확하지 않습니다.구체적인 변경 내용은 "X에서 Y로 변경" 형식으로 기재해 주십시오.- Stradivarius님♪ talk ♪ 2014년 5월 14일 08:36 (UTC)응답[응답]

로컬 Wiki로 이동할 때 발생하는 문제

Wikipedia(위키피디아)의 정보가 망가질 가능성이 있기 때문에 변경을 요구하는 것은 아닙니다.그냥 참고용이에요.

왜 내 지역 위키에서 작동하지 않는지 알아내는데 시간이 좀 걸렸어하지만 모듈의 다음 행을 변경하여 해결했다고 생각합니다.네임스페이스_detect/data.64행부터 시작

 위해서 nsid, ns 에 쌍들(음.위치.subject 네임스페이스) 하다   한다면 nsid ~= 0 그리고나서 -- 메인 네임스페이스를 제외합니다.    현지의 nsname = ns.이름.    현지의 lcNsname(이름) = 음.스트링.더 낮게(ns.이름.)    현지의 표준명 = 음.스트링.더 낮게(ns.표준명)     -- 커스텀 네임스페이스(커스텀 Wiki)에서는 케이스가 중요합니다.    -- 보존할 필요가 있습니다.    한다면 표준명 == lcNsname(이름) 그리고나서     nsname = lcNsname(이름)    끝.    매핑[nsname] = {nsname}     한다면 표준명 ~= nsname 그리고나서     table.insert(매핑[nsname], 표준명)    끝.    위해서 _, 에일리어스 에 아이페어(ns.에일리어스) 하다     table.insert(매핑[nsname], 음.스트링.더 낮게(에일리어스))    끝.   끝.  끝.

-Rineelli (대화) 18:59, 2016년 3월 30일 (UTC)응답[응답]