모듈 토크:위키데이터IB/아카이브 3

Module talk
아카이브 1 아카이브 2 아카이브 3 아카이브 4 아카이브 5 → 아카이브 8

getValue의 새 매개 변수가 리디렉션 해결 시도를 피하려고 했습니다.

371행과 372행은 페이지에 트랜스크립션을 기록하는 고비용 작업을 수행합니다.이로 인해 문서가 존재하지만 리디렉션되지 않은 경우 모듈이 플레인 라벨을 출력하는 경우가 있습니다(모듈은 DAB 페이지로 가정함).단, artitle.id 및 artitle.isRedirect 때문에 클릭 가능한 링크는 생성되지 않지만 페이지 링크는 여전히 등록되며 링크가 있는 모호성 해제 페이지에 페이지가 팝업됩니다.371/372 행을 비활성화하는 getValue에 전달할 파라미터를 원합니다.유효한 사이트 링크가 존재하지 않는 경우 로컬 리다이렉트를 체크하지 않고 Wikidata에 링크합니다.매우 장황하지만 "no Redirect Resolution"과 비슷합니다.또는 페이지 링크를 등록하지 않고 페이지 존재 여부를 테스트할 수 있을 때까지 이 섹션을 완전히 비활성화합니다. -- ferret ( talk ) 00:32, 2018년 5월 30일 (UTC)

그 코드의 이유는 Wikidata가 고고학자 (Q3621491)와 같은 엔트리가 고고학자 (Q3621491)가 리다이렉트라는 이유만으로 고고학자 (영어 위키피디아는 '고고고학'을 '고고고학' 기사의 일부로 논의한다)를 갖는 것을 거부하기 때문이다.예를 들어, 이 코드가 없다면, 전기 정보 상자는 많은 직업에 대한 링크를 갖지 못할 것입니다.누가 코드를 비활성화하는 매개 변수를 사용합니까?예기치 않은 수의 값 또는 필드에 대한 링크를 비활성화하는 매개 변수를 정보 상자 설계자가 사용할 수 있습니까?나는 그게 진심으로 의심된다.모듈 내 고가의 콜에는 문제가 없습니다.콜 mw.title.new(id)는 사용되지 않습니다.문제는 mw.title.new(label, namespace)가 라벨은 있지만 사이트 링크는 없는 상태에서 호출된다는 것입니다.이 테이블에는 "What links here"에 사용되는 엔트리가 잘못 작성되어 있습니다.이는 Wikidata뿐만 아니라 해당 콜을 사용하는 모든 Lua 모듈에 영향을 미칩니다.IB, 그리고 그것이 바로 수정이 필요한 문제입니다.라벨이 로컬 위키피디아에서 링크 가능한 기사를 나타내는지 여부를 결정하는 다른 방법을 조사하겠습니다.그 사이에 로컬 값을 지정하면 누구나 문제를 회피할 수 있습니다.--RexxS (talk) 15:07, 2018년 5월 30일 (UTC)
@페레트:샌드박스에서 mw.title.new(label, namespace) 사용을 최소화하려고 노력했지만 당신이 언급한 효과의 예를 찾을 수 없어 테스트에 어려움을 겪고 있습니다.문제가 발생한 기사를 6개 정도 나열해 주시겠습니까?상황을 개선할 수 있는지 알아보겠습니다.--RexS (대화) 2018년 5월 30일 (UTC) 15:50
@RexS: mw.title.new 자체는 문제가 되지 않습니다.결과 객체 상에서 .id 또는 .isRedirect를 호출하고 있습니다.이들은 페이지 링크를 등록하는 사람들입니다.출력에 링크가 포함되어 있지 않은 경우에도 .id/.isRedirect가 사용되면 즉시 트랜슬루션이 등록됩니다.페이지 링크를 등록하지 않는 페이지 존재 여부를 테스트할 수 있는 방법을 찾을 수 없습니다.이 요청의 원인이 되는 불만 사항은 Template talk에서 확인할 수 있습니다.인포박스 비디오 게임 번호시리즈 필드와 템플릿토크:정보박스 비디오 게임 #스케이트(비디오 게임) 및 템플릿:정보 상자 비디오 게임(series= 필드).어느 경우든 DABLINK 보고서를 해결하려고 하는 에디터는 시리즈 파라미터가 Wikidata에서 추출되고 링크된 항목에 enwiki 기사가 없는 경우를 발견했습니다.라인 371 및 372는 링크된 항목의 레이블을 가져와서 리디렉션 여부를 확인한 다음(두 가지 경우 모두 아님) 일반 레이블을 출력합니다(기사를 DAB로 가정).겉으로 보기에는 이게 바로 당신이 원하는 행동이에요.유감스럽게도 .id 및 .isRedirect를 호출하면 페이지 링크가 등록되고 문서가 DABLINK 보고서에 푸시됩니다.Skate(동음이의비디오 게임)에서 앞뒤 편집 내역을 봅니다.테스트 케이스로서 모듈을 참조할 수 있습니다.샌드박스/페럿[ Whats Links ](사용자 링크)를 체크하는 경우:Ferret/sandbox, 사용자:Ferret/sandbox2에서 모듈과 artitle.isRedirect(redirect Target이지만 결과는 동일)를 사용하면 링크된 페이지로 등록됩니다.나는 maketitle을 사용했지만 새로운 작품도 마찬가지이다.링크를 실제로 만드는 것은 mw.title.new가 아니라 타이틀 오브젝트에 대한 호출입니다.-- ferret ( talk ) 2018년 5월 30일 (UTC) 16:42,
@페레트:네, 맞아요.그러나 오브젝트를 작성하자마자 id와 isRedirect 속성을 테스트합니다.그렇지 않으면 오브젝트를 작성해도 의미가 없기 때문에 같은 결과가 됩니다.sitelink가 없는 경우 값 자체(Wikibase-item)가 Wikimedia dismarkeration page(Q4167410)와 동일한 속성 인스턴스를 가지고 있는지 확인하도록 샌드박스 코드를 다시 작성했습니다.만약 그렇다면, 저는 플레인 라벨을 붙이고 기사 존재 여부 및 리다이렉트 여부 확인을 건너뜁니다.현재 wikibase 엔티티가 존재하며, 영어 라벨이 있고, dab 페이지의 인스턴스가 아니며, enwiki의 기사 제목이 라벨과 동일하지만 리다이렉트가 아닌 경우, 그것이 무엇인지 모르지만 링크가 있는 모호성 해제 페이지에 표시됩니다.하지만 샌드박스 코드가 구현되면 그 수가 많지 않길 바랍니다.
당신의 샌드박스나 그 외는 스플리어스 링크에 대해서는 알고 있습니다만, Wikidata를 사용한 실제 기사의 예를 몇 가지 가르쳐 주셨으면 합니다.문제를 일으키는 IB.그러면 샌드박스 코드가 문제를 해결하는지 테스트할 수 있습니다.샌드박스 코드가 예상대로 동작한다는 것을 보여줄 때까지 메인 모듈을 수정하고 싶지 않습니다.도움이 필요하신가요? --RexS (대화) 2018년 5월 30일 (UTC) 18:26
스케이트(동음이의 게임)가 그것을 한다.Wikidata pull이 억제되어 현재는 하고 있지 않습니다.Eye of the Viewer (비디오 게임)도 마찬가지입니다.이것들은 가짜 링크에 대한 논의를 시작한 두 가지입니다.어느쪽인가에서 시리즈를 삭제하면 됩니다.-- ferret ( talk )2018년 5월 30일 (UTC) 21:03
@페레트:감사해요.그래서 다른 가능성을 시험해 볼 수 있어요.mw.title.new(라벨, 네임스페이스) 호출만으로는 스플리어스 링크가 발생하지 않는다는 것에 동의합니다.제목 객체의 ID와 isRedirect 속성을 사용하여 테스트를 제목 객체의 redirect Target 속성을 사용하는 테스트로 대체하면 문제를 회피할 수 있다고 생각했습니다.유감스럽게도 문서에는 기재되어 있지 않지만 스플리어스 링크도 작성됩니다.다시 생각해 보겠습니다.--RexS (대화) 2018년 5월 31일 (UTC) 13:32
저도 같은 문제를 발견했어요.제목 오브젝트 속성 중 일부는 사이트 링크 작성으로 명시적으로 라벨링되지 않지만 작성됩니다.DB 취득의 원인이 되는 고가의 것 같습니다.-- ferret ( talk )2018년 5월 31일 (UTC) 13:36
맞아요.개발팀이 바로 가기를 사용하여 링크와 동일한 테이블에 상태 변화를 기록했기 때문입니다.그리고 나는 지금 이 문제에 대해 mw에서 아노미와 논쟁 중이다.확장 토크:Scribunto/Lua는 매뉴얼 #Title 객체와 가짜 링크를 참조했습니다.그 이유는 제가 감히 그의 문서를 갱신했기 때문입니다.시간이 있으면 이 버그를 수정하는 것이 얼마나 중요한지 강조해 주십시오.그렇지 않으면 위키피디아에서는 제목 라이브러리가 거의 쓸모없기 때문입니다.건배 --RexS (토크) 17:51, 2018년 5월 31일 (UTC)
가장 엄격한 의미에서 아노미가 맞는 것 같다.isRedirect는 링크, redirectTarget은 트랜스클루전입니다.둘 다 "What Links Here"에 표시됩니다.DABLINK 건이 두 가지를 구분하는지는 모르겠습니다.이 경우 리다이렉트 타깃을 사용하여 DABLINK를 트립하지 않고 리다이렉트가 동작하는지 여부를 확인할 필요가 있습니다. -- ferret ( talk ) 2018년 5월 31일 (UTC) 19:06
아노미는 redirect Target이 링크를 만들지 않는다고 주장합니다.따라서 향후 불만을 해결해 줄 수 있도록 기꺼이 그에게 연락하겠습니다.샌드박스 코드는 확실히 트랜스클루전(transclusion)만 생성하기 때문에 개선되는 것은 기쁘지만, Dab 페이지에 대한 링크를 찾는 Gnome은 그렇게 보지 않을 것입니다.현재 샌드박스에 있는 업데이트를 롤아웃하기 전에 정보 상자에서 Wikidata 사용에 대한 RfC가 완료되기를 기다리고 있습니다. 하지만 이러한 RfC가 Wikidata를 가져오는 방법에 대해 사람들이 현재 안고 있는 많은 문제를 해결해 주길 바랍니다.건배 - RexS (토크)20:25, 2018년 5월 31일 (UTC)
또한 사용자: (User)에서 테스트 코드를 다시 활성화했습니다.RexxS/sandbox/Wikidata를 통해 해당 페이지가 다른 보고서의 [Skate]에 대한 링크로 표시되는지 확인할 수 있습니다. --RexS (talk) 2018년 5월 31일 (UTC) 20:29

메이저 업데이트(2018년 6월)

Wikipedia에서는:Wikidata/2018 Infox RfC가 실행되고 있으며, 메인 모듈을 업데이트하지 않고 샌드박스에 개발을 남겨두고 있습니다.RfC가 종료되었으므로 샌드박스에서 메인 모듈을 업데이트했습니다.이로 인해 성능과 기능 모두에서 몇 가지 개선이 이루어졌습니다.

  • 모듈이 콜에 필요한 Wikidata 엔트리의 일부만 로드하기 때문에 퍼포먼스가 향상됩니다.Wikidata 엔트리는 Wikidata 엔트리의 전체(이전에는 데이터에 액세스하는 유일한 방법)가 아닙니다.페이지와 직접 관련지어지지 않은 다른 Wikidata 엔트리에 대한 콜은 더 이상 비용이 들지 않습니다.
  • getValue 호출은 파라미터를 통해 순위를 지원하므로 getPreferredValue를 사용할 때보다 유연성이 높아졌습니다(지금은 순위가 "best"로 설정된 getValue 호출에 불과합니다).
  • getValue 호출은 속성 값 뒤에 괄호 안의 값으로 수식자를 반환하는 기능을 지원합니다.
  • getValue 호출을 사용하면 반환되는 값의 수를 제한하거나 반환되는 값의 수가 지정된 수를 초과할 경우 반환되는 값의 목록을 자동으로 조합하는 등의 추가 기능을 제공할 수 있습니다.상세한 것에 대하여는, 「모듈」의 메뉴얼을 참조해 주세요.위키데이터IB/doc #값 취득 파라미터.
  • getValue와 동일하게 동작하지만 지정된 값을 가진 특정 한정자를 가진 값만 반환하는 getValueByQual이라는 새로운 호출이 있습니다.상세한 것에 대하여는, 「모듈」의 메뉴얼을 참조해 주세요.위키데이터IB/doc #함수 getValueByQual.
  • getValue와 동일하게 동작하는 getValueByLang이라는 새로운 콜이 있습니다.단, 특정 언어 코드를 값으로 하는 수식자 작업 언어 또는 이름(P407)이 있는 값만 반환됩니다.상세한 것에 대하여는, 「모듈」의 메뉴얼을 참조해 주세요.위키데이터IB/doc #ValueByLang을 취득하는 파라미터.
  • 반환된 값에 sitelink를 사용할 수 있는 경우 getValue 호출은 결과를 조금 다르게 표시합니다.이 경우 링크는 사이트 링크에 남지만 표시되는 텍스트는 라벨 대신 사이트 링크(명확한 텍스트 제거)를 사용합니다.이것은 Wikidata의 반달리즘에 대한 라벨의 취약성에 대한 대응입니다.
  • 래퍼 템플릿{{wdib}}에는 편리한 지름길입니다.{{#invoke:WikidataIB getValue ...}}동일한 매개 변수를 사용합니다.예를 들어, Douglas Adams(Q42)의 배우자(P26)는 다음과 같다.{{wdib P26 qid=Q42 fwd=ALL qual=DATES}}Give Jane Belson(1991 ~2001)

모듈 토크에는 수많은 테스트 사례/예제가 있습니다.위키데이터IB/테스트 중문제가 발생하면 ping해 주세요.--RexS (talk) 2018년 6월 13일 (UTC)

이 모듈은 터무니없이 비대해지고 있다.{{3x p}}ery (토크) 2018년 6월 13일 (UTC) 21:24
그렇게 무례하게 굴지 마세요.단, 모듈을 개선하기 위해 어떤 기능을 삭제할지에 대해서는 건설적인 제안을 해 주십시오.--RexS (토크) 2018년 6월 13일 (UTC)

getPreferredValue가 WD 아이템이 없는 페이지에서 문제를 일으키고 있습니까?

알아요, 간단한 대답은 "그래서 아이템을 만들어라"예요.

싱킹시티에서 사용 중인 {{Infobox video game}}이(가) image=에 대해 로컬로 정의된 값을 표시하지 않습니다.현재 이 기사에는 연결된 WD 항목이 없습니다.테스트용으로 랜덤 QID를 대체하면 이미지가 나타납니다.QID가 없을 때 문제가 발생하지 않는 것 같습니다.-- ferret ( talk ) 2:28, 2018년 6월 14일 (UTC)

나는 이것이 이제 고쳐졌다고 믿는다.{{3x p}}ery (토크) 2018년 6월 14일 02:38 (UTC)
확인, 수정, 감사합니다. -- ferret ( talk ) 2:40, 2018년 6월 14일 (UTC)

유틸리티 기능

Wikidata를 다른 Wikimedia 프로젝트로 Import하는 방법을 개발하는 데 따른 중요한 결과 중 하나는 한 프로젝트에서 수행된 작업을 다른 프로젝트에 사용할 수 있다는 것입니다.이 모듈은 현재 Commons를 포함한 40개의 다른 프로젝트에 사용되고 있습니다.emptyor, getLang, formatNumber, expect 등의 유틸리티 함수는 디버깅, 정보 상자 구성 또는 기능 개발에 사용됩니다.이들 중 몇 개는 1개 또는 여러 개의 다른 모듈로 이동할 수 있지만, 이는 단순히 이들 모듈을 사용하려는 다른 프로젝트가 여러 개의 모듈을 무상으로 Import하게 된다는 것을 의미합니다.메인 모듈에서 모든 유틸리티 기능을 유지한다는 것은 다른 프로젝트에서 코드를 디버깅하라는 메시지가 표시되면 언어를 읽을 수 없는 경우에도 이러한 도구를 사용할 수 있다는 것을 합리적으로 확신할 수 있다는 것을 의미합니다.

따라서 Pppery 삭제 유틸리티 함수는 Wikidata와 무관한 미사용 삭제(문서 페이지 예외) 기능 이외에는 반대합니다.단순히 미리보기 모드로 무언가를 확인하거나 디버깅하기 위해 사용하는 경우가 많기 때문에 저장된 페이지가 없는 것은 그 유용성과 관련이 없습니다.솔직히 Wikidata와 직접 관련된 기능만 이 모듈에 속한다는 전제는 받아들일 수 없습니다.Wikidata를 정보 상자에 포함시키는 메커니즘을 구현하기 위해 만들어졌습니다.Wikidata에 직접 접속하지 않더라도 정보 상자를 구성할 때 유용한 빈 함수와 같은 함수는 모듈에 속합니다.마찬가지로 특정 언어로 숫자를 어떻게 포맷해야 하는지 확인하거나 현재 콘텐츠 언어 코드 또는 이름을 확인할 수 있는 기능은 모든 다국어 위키에서 유용하게 사용됩니다.모듈이 어떤 프로젝트를 진행 중인지 감지하는 코드와 같이 이러한 코드를 그대로 두면 여러 프로젝트에서 하나의 코드 세트를 사용할 수 있습니다(물론 로컬 국제화).

기능을 제거하여 모듈을 짧게 하면 성능이 향상된다는 증거가 있다면 프로젝트 전체에서 하나의 코드 세트를 유지하는 목표를 재고할 것입니다.다만, 현시점에서는, 기능을 삭제하는 보다 좋은 이유를 제시할 필요가 있다고 생각합니다.--RexxS (talk) 2018년 6월 15일 (UTC) 01:18

이 모듈이 지나치게 비대해지지 않도록 하고 싶은 것은 모듈의 퍼포먼스를 향상시키고 싶어서라기보다는 이 모듈이 관련 없는 툴의 일원화되지 않도록 하기 위해서입니다.각 모듈에는 직접 사용하는 장소에만 필요한 것이 있어야 합니다.랜덤한 다른 잡동사니가 아니라 약간 다른 컨텍스트에서만 유용한 것이어야 합니다(다른 Wiki와 같이).따라서 이 목적에 기여하지 않는 것은 필요하지 않으므로 삭제해야 합니다.영어 위키피디아는 다국어가 아니기 때문에특정 언어로 숫자를 포맷하는 방법을 확인하거나 현재 컨텐츠 언어 코드 또는 이름을 확인하는 기능은 다국어 위키에서 중요한 것이 아닙니다.앞에서 설명한 바와 같이 이것은 모듈입니다.위키데이터IB는 Wikidata와 정보 상자를 실제로 포함하는 기능만 포함해야 하며, 다른 랜덤한 잡셀러리는 포함하지 않아야 합니다.{{3x p}}ery (토크) 2018년 6월 15일 01:41, UTC
모든 사람들이 이런 일을 하는 템플릿이 있는 것을 우습게 생각할 것이다.{{#switch:{{{1 }}} foo = <code foo> bar = <unrelated code bar> baz = <unrelated code baz> quux = <unrelated code quux>}}이 모듈은 어떻게 다른가요?{{3x p}}ery (토크) 2018년 6월 15일 01:45 (UTC)
(ec) 나중에 상황을 정리하도록 하겠습니다.Pppery의 모든 조정은 종종 불필요하고 거칠었기 때문에 되돌리려고 생각했지만, 유지되어야 할 몇 가지 포인트가 있었을지도 모릅니다.특히 수천 개의 트랜슬루션이 있는 활성 모듈을 만지작거리는 절차는 좋지 않은 방향으로 대담하게 진행됩니다.템플릿 에디터 권한은 기술 영역에서 협업하기에 적합한 편집자만 보유해야 합니다.이 모듈을 enwiki에 사용하기 위해 의미 없는 최적화로 다른 프로젝트에 사용하기 어렵게 하는 것은 좋지 않습니다.최적화를 통해 상당한 시간 또는 리소스를 절약했다는 테스트 사례가 있다면 어느 정도 의미가 있을 수 있지만, 눈에 띄는 개선 사항이 없기 때문에 물론 없습니다.Johnuniq (토크) 2018년 6월 15일 (UTC) 01:46
@pppery:편집 전쟁 게임은 하지 않겠습니다만, 모듈이 「관련되지 않은 툴의 모노리스」가 되어 가는 것에 대해서는 반대합니다.Wikidata를 infobox에 통합할 때 사용하는 툴인데, "관련성이 없다"는 당신의 제안에 감명받지 못했습니다.이 모듈로 작업할 때 사용하는 것으로 인해 관련성이 있습니다.
"각 모듈은 직접 사용하는 장소에 필요한 것만 갖추어야 합니다."누가 그래요? 당신이요? 모듈은 템플릿과 근본적으로 달라요.템플릿에는 단일 입구가 있지만 모듈은 여러 개의 독립된 기능을 가지도록 설계되어 있어 독립 실행형 프로그램보다는 공유 라이브러리와 유사합니다.나에게 도움이 되는 기능(그리고 다른 기능에도 도움이 되는 기능)의 그룹을 모을 수 있다면, 어떤 철학적인 반대나 모듈에 대한 오해 때문에 거부권을 행사해야 하는 이유는 무엇입니까?
1개의 모듈에 다수의 독립된 기능이 있어 측정 가능한 퍼포먼스에 영향을 주는 일은 없습니다.또, 그러한 코드를 문서화된 코드 소스에 보관 유지해도 문제가 없습니다.모듈에 이러한 기능이 있는 것은 단점이 없기 때문에 사용할 수 있도록 하고 싶습니다.
영어 위키피디아는 다국어가 아니기 때문에 특정 언어로 숫자를 포맷하는 방법을 보거나 현재 콘텐츠 언어 코드나 이름을 확인하는 기능은 다국어 위키에서 가치가 있습니다.반짝반짝 빛나죠.다국어 Wiki에서는 다국어 기능이 필수적이며 모듈을 다른 위키피디아로 전송할 때 필요한 국제화의 양을 줄이는 데 유용합니다.우리가 하는 일은 영어 위키피디아뿐만 아니라 그것을 사용하고자 하는 모든 프로젝트를 위한 것이다.따라서 업데이트 및 유지 보수 측면에서 공통 코드의 양을 최대화하는 데 상당한 이점이 있기 때문에 모듈(또는 로컬 서브 모듈) 시작 시 국제화를 넘어서는 코드 포크를 사용하고 싶지 않습니다.이러한 기능을 삭제해도 아무에게도 도움이 되지 않습니다.지금 바로 되돌리도록 하겠습니다.--RexS ( talk ) 2018년 6월 15일 (UTC) 19:20
모듈은 템플릿과 근본적으로 다르지 않습니다.위에서 말한 것처럼 템플릿의 시작에는#switch첫 번째 파라미터에 따라 관련이 없는 것과 관련이 있지만 아무도 그런 템플릿을 코드화하지 않습니다.당신은 정확히 같은 것을 제안하고 있습니다.이 모듈이 다음과 같기를 원합니다.{{#switch:{{{1 }}} getValue={{#property:{{{2 }}} from={{{3 }}}}} formatNum={{formatnum:{{{2 }}}}}...}}미디어위키에서는 템플릿을 코드화하는 방법이 아닙니다.유틸리티 함수는 다른 모듈로 이동할 경우 다음과 같이 보일러 플레이트 이외의 코드 라인이 없다는 점에서 관련이 없습니다. local p = {} ... return p두 모듈에 모두 포함되어야 하며, 다른 모듈과 달리 다음과 같은 환경에서 작동해야 합니다.내선번호:Wikibase 클라이언트가 설치되지 않았습니다.저는 모듈이 무엇인지 오해하는 것이 아닙니다.모듈이 무엇인지에 대한 생각이 다를 뿐입니다.
공통 코드를 갖는 것이 좋은 목표라는 것에는 이의를 제기하지 않지만, 그렇다고 해서 미리 정의된 섹션을 제외한 모든 코드 행이 똑같을 필요는 없습니다.다국어 Wiki는 적절한 {{int:lang}}개의 코드를 장소에 붙이기 위해 포크할 수 있으며, 공용은 사이트링크 대신 라벨을 사용하기 위해 포크할 수 있습니다.코드 한 줄 한 줄 집중하려고 하는 것은 잘못된 목표이며 모듈 같은 몬스터에게만 이어집니다.자전거 경주는 다음과 같은 코드들로 뒤섞여 있습니다. if wiki == "mk" or wiki == "ja" or wiki == "ru" then ... 그래서 나는 자기반복하지 않을게요.{{3x p}}ery (토크) 2018년 6월 15일 (UTC) 19:51)
모듈은 제가 설명한 템플릿과 근본적으로 다릅니다.이 예에서는 서로 관련이 없는 다른 것 사이를 전환하기 위해 매개 변수를 사용한 하나의 함수를 포함하는 모듈을 작성하는 것과 유사합니다.아무도 그런 모듈을 쓰지 않을 거예요.단, 필요에 따라 기능 그룹을 하나의 모듈로 통합하는 기능은 모듈이 MediaWiki에 구현되는 방법의 기본 기능입니다.저는 위에서 설명한 바와 같이 특별한 컬렉션을 만들어야 할 실질적인 이유가 있습니다.기능 제거로 성능, 편의성, 휴대성 또는 기타 객관적인 고려사항에서 모듈이 개선되는 이유를 제시하지 않았습니다.
일부 사전 정의된 섹션을 제외한 모든 코드 행이 동일해야 합니다. 단일 복사 및 붙여넣기로 간편하게 업데이트할 수 있기 때문입니다.편집자의 요구를 충족시키기 위해 여전히 성장하고 있는 코드, 따라서 빈번한 업데이트가 필요한 코드, 이것이 바로 강력한 이유입니다.다른 Wiki의 요건에 따라 두 가지 옵션을 전환하는 코드가 있는 주요 섹션은 전혀 문제가 없습니다.이것은 단순히 {int:lang}에 대한 질문 이상의 것입니다.Commons와 같은 Wiki는 페이지 제목이 완전히 다르기 때문에 라벨 대신 sitelink를 사용하는 것은 바람직하지 않습니다.하나의 코드로 모든 Wiki를 처리할 수 있는 경우, 다른 Wiki의 코드를 포킹하는 것은 전혀 도움이 되지 않습니다.당신의 '피흘림'에 대한 두려움은 전혀 근거가 없습니다.getValue의 프로그램 흐름에 따라 문제가 발생하고 있지 않습니까?그렇지 않습니까?그러면 Wiki 대응 스위치로 인해 발생하는 문제에 대해 설명하겠습니다.
제3의 의견을 구해야 할 때라고 생각합니다만, 제3의 의견을 구해야 할 때라고 생각합니다.또, 이 모듈을 유지하는 것을 단순히 개선의 욕구를 만족시키기 위해서가 아니라, 단지 당신의 개입의 욕구를 만족시키기 위해서만 어렵게 할 생각은 없습니다.--RexS (토크) 2018년 6월 15일 (UTC) 20:47 (토크)
서로 동기화하기 어려운 다른 버전이 있는 것이 아니라 서로 다른 Wiki 간에 동일한 버전을 유지하는 것이 확실한 가치가 있으며, 이는 약간의 중복 코드를 갖는 것보다 더 중요합니다.({convert}가 몇 가지 다른 서브모듈을 사용하는 것과 같은 방법으로) 이 기능을 호출하는 별도의 유틸리티 모듈을 사용하는 것을 고려해 볼 필요가 있습니다.단, 그렇게 함으로써 명확한 이점이 있는 경우에만 이 모듈을 사용할 수 있습니다.감사해요.Mike Peel (토크) 2018년 6월 15일 (UTC) 21:36

Wikidata에서 가져오기가 더 이상 작동하지 않습니다.

@RexS: 최근에 모듈을 변경하셨습니다.@DBD: 최근 {Ordination}이(가) Wikidata 값 가져오기 기능을 제대로 호출하지 않게 되었습니다.이것이 최근 편집과 관련이 있는지 알고 계십니까?Ergo Sum 2018년 6월 26일(UTC) 01:33

Template talk에서 토론:주문 번호단편화를 피하기 위한 Wikidata 오류입니다. --RexxS (talk) 2:25, 2018년 6월 26일 (UTC)

세기에 걸친 코드 조각의 의미

Wikidata에서 데이터를 가져오는 다양한 것들이 수 세기를 어떻게 해석하는지 알아보려다 우연히 이 코드 조각을 발견했다.

else dateprecision == 7이면 --century local century = math.floor((fpvdate - 1) / 100) + 1 fdate = makeOrdinal(세기) .."..i18n["세기""

저는 Lua에서 매우 처음이지만, 만약 제가 이것을 제대로 이해한다면, 작업 전에 올해의 4자리 숫자가 구문 분석되고(연도에 5자리 이상 실패하며, 작업 범위를 문서화하는 것이 좋을 수 있습니다) 숫자 fpvdate를 입력합니다.그런 다음 fpvdate에서 1을 뺀 후 100으로 나누어 반올림합니다.그래서 2001년은 20살이 된다.그리고 1을 더하면 21세기입니다.

2000. floor(1999/100) = foor(19.99) = 19라고 가정합니다.1을 더하면 20세기가 된다.하지만 미디어위키를 읽으면서:Wikibase/Indexing/RDF 덤프 형식 및 미디어위키:Wikibase/Data Model/JSON 정밀도는 타임스탬프의 특정 부분을 무시하는 명령으로 취급됩니다.Precision 7에서는 타임스탬프 내의 수백 자리보다 작은 자리수는 모두 무시하도록 지시하고 있습니다.따라서 +2000-01-01T00:00:00Z는 +20으로 취급되며, 이를 충족하는 연수는 2000~29999년입니다.(그런데 타임스탬프는 JSON RDF 또는 기타 RDF 등)

실제로 세기의 일반적인 해석(년 > = 100)은 마지막 2자리가 01인 해에 시작하여 마지막 2자리가 00인 해에 12월 31일 끝나는 기간이다.'세기'에 대한 공통의 이해는 위키데이터의 모델과 일치하지 않기 때문에 '세기'라는 단어는 아예 사용하지 않는 것이 좋을지도 모른다.'2000~2099년 포함' 정도.Jc3s5h (대화) 2018년 7월 18일 05:23 (UTC)

악티움 해전(Q160387)은 기원전 9월 31일(현지시간)의 속성 시점(P585)을 가지고 있다.다음 형식으로 저장됩니다.
표 #1 { table #2 { " id " ] = "Q160387$e2a5cc8e-4b09-83ec-21a8-cb01a5a092d9", "mainsnak" = 표 #3 {"["datatype" = "time, [datavalue]" = #4"["time"] = "http://www.wikidata.org/entity/Q1985786", [time"] = 11, [time] = - 0031-09-02T00:00:00Z", ["timezone"], ["timezone"]= 0, }, ["snaktype"] = "value", [rank"] = "normal", ["references" = table #6 { table#7 {\"} = "0540"["snaks"] = table#8 {"P248"] = table#9 {table#10 {["datatype"] = "table#11 {"type"] = "table#11 {"type" = "table#9"["value"] = table#12 {"tem-type"] = "item", [id" = "Q24329384", ["tem-id"] = 24329384, },["snaktype" = "P248", ["snaktype"] = "value", }, }, ["snaks-order"] = 테이블 #13 {"P248", },표 #14 {"table" = "f8f8b2ec64c447e7f49866b"(182114d82c6", ["snaks"] = table#15 {"P248"] = table#16 {table#17 {"datype] = "table#17 [" datype" = "timebase-item"["datavalue"] = table#18 {["type"] = "table"-type", [value"] = table#19 {"["tem", ["id"] = "Q25369108",["value-id"] = 25369108, }, ["value"] = "P248", ["snaktype"] = "value", }, },["snaks-order"] = 테이블 #20 {"P248", }, }, ["type"] = "statement", }, }
따라서 JSON 또는 RDF에 대한 우려는 생략할 수 있습니다.데이터베이스는 RDF로 유지되지만 표시되는 포맷은 XSD 1.0(ISO 8601:1988)입니다.즉, BCE 9월 31일은 다음과 같이 반환됩니다."-0031-09-02T00:00:00Z", precision=11 입니다.
Wikidata 인터페이스에서 수동으로 1세기를 입력하는 경우 정밀도를 "세기"로 설정하고 1년을 입력해야 합니다.1901년부터 2000년까지의 임의의 연도는 "20"으로 표시됩니다.Wikidata 뷰인터페이스에 센츄리"가 표시됩니다.1925년을 입력하면 다음과 같이 저장됩니다.["precision"] = 7, ["time"] = "+1925-00-00T00:00:00Z"년도에 2000을 입력하면 다음과 같이 저장됩니다.["precision"] = 7, ["time"] = "+2000-00-00T00:00:00Z"이 문서에는 통상적인 잡동사니가 실려 있습니다.직접 확인함으로써 이러한 문제를 해결할 필요가 있습니다.
예를 들어, "리처드 버튼은 20세기에 태어났다"와 같이 적절한 세기의 날짜 표시를 지원할 수 있는 어떤 시점에서든 사용할 수 있기를 원했기 때문에, 저는 제가 했던 방식으로 코드를 작성했습니다.1925년과 2000년 모두 20세기이기 때문에 "타임스탬프의 수백 자리보다 낮은 자리수를 모두 무시하라"는 지시를 따른다면 그렇게 할 수 없다.MediaWiki의 문서는 매우 빈약하고 개선할 수 없기 때문에 스스로 해결해야 합니다.--RexS (토크) 13:53, 2018년 7월 18일 (UTC)
우리는 영어를 다루는 것이 아니라 여러 개의 API와 하나의 대화형 사용자 인터페이스를 다루고 있다는 것을 명심해야 한다고 생각합니다.이 예의 정보를 생성하는 API는 "inspect" 파라미터를 사용하여 가장 무겁게 평가합니다.사용하고 있는 API이기 때문에 어떤 API인지 알 수 없습니다.mediawikiwiki일 수 있습니다.Wikibase/Indexing/RDF 덤프 형식 및 미디어위키:Wikibase/Data Model/J손, 둘 다 합리적인 문서를 가지고 있기 때문에 무게를 많이 두는 편이에요인터랙티브 유저 인터페이스에 메뉴얼이 있는 경우는, 유저로부터 잘 숨겨져 있어 많은 버그가 발생하고 있습니다.그 중 일부는 수정되어 있고 일부는 수정되어 있지 않으며, 또 일부는 방금 지적한 것입니다.어떻게 작동하는지는 실험으로 결정해야 합니다.그래서 나는 그것의 무게를 가볍게 쟀다.또 다른 고려사항은 Wikimedia 내부와 외부의 사람들이 문서를 읽고 이를 따르기 위해 코드를 작성했을 수 있다는 것입니다.확실히 사용자 인터페이스는 적은 양의 정보를 읽거나 쓰는 데만 적합하며 대부분의 정보는 다른 인터페이스를 통해 읽거나 쓰입니다.그러나 다른 인터페이스 개발자들이 설명서를 읽었는지, 사용자 인터페이스를 실험했는지, 아니면 그들이 해야 할 일이 너무나 명백해 보였기 때문에 더 이상 생각하지 않고 자연스럽게 보이는 어떤 규칙을 따랐는지 알 수 없다.
JSON API는 10년간 정밀도가 특정 숫자를 무시하는 명령이라는 명확한 예를 제시합니다.이 예는 100년의 정밀도에도 적용되어야 합니다.예를 들어 정밀도7의 0200은 02로 해석되어야 하기 때문에 200~299의 불확도 범위에 들어가야 합니다.RDF API는 덜 명확하지만 ISO 8601을 참조하는 문서는 숫자를 잘라 정밀도를 나타내므로 동일한 결과를 얻을 수 있습니다.
Wikidata가 있습니다.Wikidata:Bot requests #저정밀 Bot request로 날짜를 정규화하고 매일 데이터베이스를 통해 모든 애매한 날짜(수세기 동안 00으로 끝나는 AD 연도 또는 밀레니아의 경우 000으로 끝나는 날짜)를 봇이 해결해야 한다고 생각하는 중간 날짜로 변환합니다(어떤 규칙을 따를지는 아직 논의 중임).예를 들어 2000-2099 규약을 따를 경우 봇은 2000 정밀도7을 2050 정밀도7로 변환합니다만약 그렇게 된다면, 그 문제는 당신의 어깨에서 벗어납니다.
출처에 날짜를 쓰는 방법에 문제가 있다.만약 한 학자가 존스가 1925년에서 1933년 사이에 태어났다고 말한다면 1950년 정밀도 7이 완벽할 것이다.출처에 "Smith born in 1700s"라고 쓰여 있고, 문맥상으로는 1700-1709가 아니라 1700-1799로 되어 있고, JSON 문서가 맞는다면 1750 precision 7은 완벽합니다.브라운이 16세기 로마에서 태어났다고 하는데 JSON이 맞다면 정확한 날짜는 없다.학회 출처는 보통 XX01 - XX00 규약을 따르기 때문에 브라운은 1700년에 태어났지만 1650 정밀도 7에는 1700이 포함되지 않습니다.그뿐만 아니라 학계에서는 그 시기의 시작은 율리우스이고, 끝은 그레고리우스이다.
그러나 만약 출처의 저자가 1601에서 1700을 의미하고 새로운 출처가 그것이 정말로 1600임을 보여준다면, 나는 그 저자가 그 위에 삼베를 두르고 재를 뒤집어쓴 것을 기대하지 않을 것이다; 어쨌든 저자는 그것을 애매한 수치로 의미했을 것이다.Jc3s5h (대화) 2018년 7월 18일 14:57 (UTC)

날짜 형식

이 모듈을 광둥어 위키피디아로 이식하려고 하는데 날짜 형식의 현지화 방법을 잘 몰라서 잘 모르겠어요.모듈에서와 같이 i18n 서브모듈에서 기본 날짜 형식 세트를 지정할 수 있습니까?위키데이터?Wikidata는 현재 비-dmy 날짜 형식을 처리하는 데 서툴러서 동아시아 언어에서 유용하게 사용하기 위해서는 날짜 형식의 현지화를 가져와야 합니다. (답변으로 ping해주세요) Deryck C. 15:20, 2018년 8월 20일 (UTC)

@데릭:저는 영어 위키피디아와 커먼즈 모두에서 이 모듈을 적극적으로 유지하고 있기 때문에 광둥어 현지화 작성에 관심이 있습니다.유감스럽게도 저는 광둥어를 할 줄 모르며 날짜의 형식을 광둥어로 알 수 없습니다.2018년 4월 1일, 기원전 8월 20일, 17세기 등의 날짜 형식이 어떻게 되어 있는지 예를 들어 주시면 샌드박스 중 하나에 구현해 보겠습니다.고객이 원하는 대로 될 때까지 수정할 수 있습니다.--RexS (대화) 2018년 8월 20일 (UTC) 15:38
@RexS::
  • 2018年4月1號
  • 公元前30年8月20號
  • 17世紀
참조:모듈: 모듈의 기존 형식 문자열에 대한 Wikidata/i18n:Wikidata.Deryck C. 15:51, 2018년 8월 20일 (UTC)
@Derick: WP: 참조IDGAP과거로 돌아가서 모듈에서는 다음과 같이 시도했습니다.위키데이터IB/sandbox2는 광둥어 날짜 형식을 구현합니다(내 추측으로는!).모듈에는 테스트를 위해 private format_Date 함수를 공개하는 퍼블릭 기능이 있습니다.그래서:
  • {{#invoke:WikidataIB/sandbox2 formatDate 1 April 2018}}→ 스크립트 오류: 해당 모듈 "Wikidata"는 없습니다.IB/샌드박스2"
  • {{#invoke:WikidataIB/sandbox2 formatDate 1 April 2018 df=y}}→ 스크립트 오류: 해당 모듈 "Wikidata"는 없습니다.IB/샌드박스2"
  • {{#invoke:WikidataIB/sandbox2 formatDate 20 August 30 BC}}→ 스크립트 오류: 해당 모듈 "Wikidata"는 없습니다.IB/샌드박스2"
  • {{#invoke:WikidataIB/sandbox2 formatDate 20 August 30 BC df=y}}→ 스크립트 오류: 해당 모듈 "Wikidata"는 없습니다.IB/샌드박스2"
  • {{#invoke:WikidataIB/sandbox2 formatDate January 2018}}→ 스크립트 오류: 해당 모듈 "Wikidata"는 없습니다.IB/샌드박스2"
  • {{#invoke:WikidataIB/sandbox2 formatDate 753 BCE}}→ 스크립트 오류: 해당 모듈 "Wikidata"는 없습니다.IB/샌드박스2"
리처드 버튼의 생년월일(P569) (Q151973)
  • {{#invoke:WikidataIB/sandbox2 getValue P569 qid=Q151973 fwd=ALL osd=no}}→ 스크립트 오류: 해당 모듈 "Wikidata"는 없습니다.IB/샌드박스2"
율리우스 시저의 사망일(P570) (Q1048)
  • {{#invoke:WikidataIB/sandbox2 getValue P570 qid=Q1048 fwd=ALL osd=no}}→ 스크립트 오류: 해당 모듈 "Wikidata"는 없습니다.IB/샌드박스2"
Wikidata에서 세기를 날짜로 취급하는 예를 찾고 있습니다만, 날짜가 아닌 예외가 발견되었습니다.카테고리:이집트의 10세기 시설(Q7213033)의 토픽을 조합한 것입니다.
  • {{#invoke:WikidataIB/sandbox2 getValue P971 qid=Q7213033 fwd=ALL osd=no}}→ 스크립트 오류: 해당 모듈 "Wikidata"는 없습니다.IB/샌드박스2"
좀 더 테스트해보고 경과를 알려주세요.건배 - RexS (토크) 2018년 8월 20일 (UTC) 18:19
  • 당신이 나중에 광둥어 위키피디아에 쓴 샌드박스 버전을 전부 복사해서 그곳에서 테스트해 볼 수도 있습니다.사이트명이 ISO-639와 일치하지 않는, 서픽스가 제거되어 있는 예외적인 기능도 있었습니다.광둥어도 그 중 하나입니다(사이트명 z_yuewiki/zh-yue).wikipedia.org, ISO-639 yue).그래서 우리는 그것을 고쳐야 할지도 모른다.Deryck C. 2018년 8월 21일 (UTC) 14:41
    • 물론이지, 데릭.사이트아이디(또는 프로지)ID) 기능은 루트 코드명이 필요할 때 사용할 수 있습니다.다른 예외를 제공하려면 elseif를 사용하십시오.코드는 필요에 따라 템플릿 내에서 사용할 수 있습니다.도움이 필요하시면 연락주세요.--RexS ( talk ) 2018년 8월 21일 (UTC) 17:07
      • 광둥어 위키피디아에서 테스트를 시작했습니다.날짜 이외의 값은 기능하는 것 같습니다(소스와 순위만 이미 유효합니다). 그러나 Lua 스크립트는 광둥어 Wikipedia에서 실행되면 포기됩니다.이 토론은 다음 시간에 진행합시다.모듈 토크:위키데이터IB. Deryck C. 14:34, 2018년 8월 23일 (UTC)

wikilink 항목의 접두사/postfix?

@RexS: 문서에서는 프리픽스/포스트픽스를 Wikibase 항목에서 사용할 수 있다고 합니다만, 이러한 동작은 보이지 않습니다.linkedItem()은 linkprefix/linkpostfix만을 대상으로 하는 것 같습니다.내가 뭘 빼놓았나요?제 경우, 특정 정보 상자 필드에 대해 결과 항목을 이탤릭체로 포장하고 싶습니다. -- ferret ( talk ) 2018년 9월 11일 (UTC)

@Ferret: 원래 사용법은 문자열 타입의 Wikidata 항목(urls 등)에만 사용되었기 때문에 대부분의 문서에서는 링크와 일반 접두사 및 접미사를 문자열 타입에만 사용하도록 규정하고 있습니다.결국 누군가(아마도 Mike)가 Wikibase 항목에 링크 프리픽스/포스트픽스 기능을 원했기 때문에 그것을 실장했습니다(일반 프리픽스/포스트픽스 기능은 제외).하지만 제가 서류를 업데이트하지 못해서 잘못된 인상을 주었어요.그 점 사과드립니다.구현할 코드를 업그레이드했습니다. prefix=그리고. postfix=모든 Wikibase 항목 및 문자열:
문제가 발견되면 알려주세요.(코드가 의도적으로 파라미터에서 큰따옴표를 삭제한다는 것을 잊지 마십시오.)건배 - RexS (토크)2018년 9월 13일 (UTC) 22:10
@RexS: 알겠습니다.감사합니다! -- 페렛 (토크)2018년 9월 13일 (UTC) 22:17

모듈 복합 날짜

이제 이 모듈은 모듈의 기능을 사용하도록 업데이트되었습니다.복잡한 날짜.

이 모듈에는 삭제가 지정되어 있습니다.모듈에 필요한 Formatnum:이 모듈로 인해 날짜가 복잡합니다.Wikipedia에서 후보 지명에 대해 코멘트를 할 수 있습니다.토론/로그/2018년 9월 21일 #모듈:Formatnum. --RexS (토크) 20:27, 2018년 9월 21일 (UTC)

Wikipedia도 참조해 주세요.Templates_for_discription/Log/2018_9월_25# 모듈:언어학.감사해요.Mike Peel (토크) 2018년 9월 25일 (UTC) 18:45

리다이렉트용 Wikilinks

{{Infobox person/Wikidata}}: 이 모듈에서 getPreferredValue를 호출하여 linkedItem을 간접적으로 호출합니다.Wikidata 항목에 연결된 enwiki 페이지가 없는 경우 linkedItem은 제목이 Wikidata 레이블과 일치하는 페이지를 찾습니다.해당 페이지가 리다이렉트일 경우 Wikilink로 반환됩니다.예를 들어 마리 L. Shadlock은 리다이렉트스토리텔러로서 「직업」을 표시합니다.이러한 타이틀은 Q16023925의 라벨과 일치합니다.유감스럽게도 리다이렉트 대상은 기사가 아니라 Storyteller 페이지입니다.Story-teller가 리다이렉트가 아닌 실제 페이지였다면 linkedItem은 링크되지 않은 일반 텍스트 "Story-teller"를 올바르게 표시할 것입니다.관련 없는 기사나 다른 페이지로 이어지는 리다이렉트도 링크할 필요가 있습니까?Wikipedia의 관련성이 있는 기사에 링크하고 싶은 충동은 이해하지만, 모듈의 저자들은 실제 페이지에 대한 유혹을 거부해 왔고, 리다이렉트에도 같은 정책을 채택할 수 있다면 도움이 될 것입니다.

Wikipedia 리다이렉트는 Wikidata 항목에 링크할 수 없기 때문에 최적의 링크가 추가되지 않고 추측해야 하는 경우가 있습니다.그래서 과감하게 모듈 변경을 자제하고 있습니다.하지만, 저는 해가 득보다 실이 많을 수 있다고 생각하며, 우리는 리다이렉트에 대한 특별 대우를 하는 것을 재고해야 한다고 생각합니다.증명서(토크) 2018년 9월 23일(UTC) 19:31

@증명서:Wikidata에 영어 사이트링크가 없는 직업도 많습니다.linkedItem이 Howard Carter(Q133682)의 직업(P106)에 대한 고고학자(Q3621491)의 값을 얻는 경우, 이 값과 어떤 관계가 있습니까?영어 위키피디아는 고고학에서 고고학으로 리다이렉트 할 수 있는데도 그 실체에 대한 영어 사이트 링크는 고고학으로 리다이렉트 할 수 있습니다.이는 수천 개의 아이템에 공통되는 경우이기 때문에 리다이렉트일 경우 라벨에서 링크를 작성하기로 했습니다.이것에 의해, 다음과 같은 것이 가능하게 됩니다.
당신은 우리가 단순히 그 정보를 표시해야 한다고 주장하고 있다.
하지만 누가 그것으로부터 이익을 얻는가?리다이렉트가 실제로 Dab 페이지로 연결되는 극히 적은 수의 경우, 다음과 같이 문서 수준에서 재정의할 수 있습니다. occupation=[[Storytelling Storyteller]]자동화된 결과가 차선책일 때처럼 정보 상자에 저장해야 합니다.수많은 케이스에서 기능을 줄이는 것이 엣지 케이스에 대한 좋은 해결책이라는 것에 동의하지 않습니다.또한 Storyteller의 영문 라벨(Q16023925)을 story-teller(방향 수정과 일치)에서 storyteller(dab 페이지만 일치하므로 링크되지 않음)로 변경함으로써 이 문제를 단번에 해결할 수 있습니다.
Story-teller가 리다이렉트가 아닌 실제 페이지라고 가정하면 linkedItem은 링크되지 않은 일반 텍스트 "Story-teller"를 올바르게 표시할 것입니다.실제 페이지(탭이나 리다이렉트가 아닌)라면 Wikidata에 sitelink가 있기 때문에 실제로는 링크된 영어 sitelink가 표시됩니다.--RexxS (talk) 20:53, 2018년 9월 23일 (UTC)
@RexxS: Wikidata를 제안대로 편집한 것은 효과가 있었던 것 같습니다.감사해요.마지막 포인트는 다음과 같습니다.기사가 있으면 Wikidata에 sitelink가 있어야 하고 링크로 올바르게 표시됩니다.나는 Storyteller와 같이 연결할 기사가 없고 모호성이 없는 페이지를 언급하고 있었다.언젠가 Wikidata가 고고학자와 같은 사이트링크에 의한 리다이렉트도 허용해 주었으면 한다.증명서 (토크)2018년 9월 23일 (UTC) 21:42
사용자: DPL 봇이 Marie L의 스토리텔러에 대한 링크를 올바르게 보고했습니다. WP로서의 분리:INTDABLINK 오류입니다.
Wikidata에서 발생한 오류를 이전에 본 적이 있지만, 오류의 원인을 파악하고 도움을 요청하는 글을 올리는 데 5분 정도 걸렸습니다.이런 걸 처음 접했을 때 절망에 빠지기까지 30~40분 정도 걸렸어요.
"리다이렉트가 실제로 Dab 페이지로 연결되는 극히 적은 수의 경우, 이 리다이렉트는 다음 방법으로 기사 수준에서 덮어쓸 수 있습니다. occupation=[[Storytelling Storyteller]]자동화된 결과가 차선책일 때처럼 인포박스에서도 마찬가지입니다."진심이야?나는 적어도 20개의 위키피디아 템플릿으로 인해 야기된 문제들을 해결하기 위한 요령을 알고 있는데, 당신은 나에게 또 다른 전혀 불필요한 것을 배우라고 말하는 건가요?
그것은 모두 독자에 관한 것이다.그와 같은 나쁜 링크는 프로젝트에 좋지 않습니다.이 에러에 의해, 보다 유익한 작업을 실시할 수 있었던 에디터 3명의 작업이 적어도 30분 이상 경과했을 것으로 추측됩니다.Narky Blert (토크) 2018년 9월 23일 (UTC) 22:06
"진정이야?"네, 물론 진심입니다.문제를 발견하면 수정하거나 수정에 도움을 요청합니다.이 경우의 수정은 사소한 것이었고, 당신이 그것을 이해할 수 없다니 놀랍습니다.위키피디아에는 아무것도 필요 없고 아무도 당신에게 편집을 강요하지 않습니다.표시된 내용이 마음에 들지 않으면 정보 상자에서 변경합니다.이것은 로켓 과학이 아닙니다.또한 이 템플릿들은 모두 처음 사용하는 사람에게 도움이 되는 문서를 가지고 있습니다.상자를 표시하려면[[Storytelling Storyteller]]그 직업에 대해, 당신은 occupation=[[Storytelling Storyteller]]인포박스에 넣습니다.어떤 정보 상자를 사용하든 동일한 솔루션입니다.
이러한 정보 상자는 2013년부터 사용되었으며, 표시되는 DAB 페이지로 리디렉션되는 것을 발견한 것은 이번이 처음입니다.왜 Dab 페이지로 리다이렉트 하는지 물어보는 것이 좋을 것 같습니다.제가 아는 모든 검색엔진은 "스토리텔러"를 "스토리텔러"와 동일하게 취급합니다. 저희는 탭 페이지와 링크하지 않기 때문에 분명히 산문 실행과 연관짓지 않을 것입니다.그렇다면 스토리텔러 리다이렉트의 목적은 생산적인 편집자의 시간을 낭비하는 것 외에 무엇인가?어쩌면 당신은 그것을 "더 적절하다"고 지적한 Neelix에게 분노를 표출해야 할지도 모른다.--RexS (토크) 2018년 9월 23일 (UTC) 22:26
스토리텔러는 위키피디아 독자들이 검색창에 타이핑하여 찾고 있는 기사를 찾을 수 있도록 도와줍니다.Neelix의 편집은 의심할 여지 없이 정확했다.
특히 인포박스 담당자와 관련된 문제는 이번이 처음일 수도 있고 아닐 수도 있습니다.이런 종류의 인포박스/위키다타 문제는 처음 있는 일이 아닙니다.내가 도움을 청한 후 다른 편집자가 발명적인 슬러지로 문제를 해결한 사례가 적어도 한 건은 기억난다. 추악하지만 효과적이다.
만약 10만 클럽의 편집자가 이러한 문제를 쉽게 풀지 못한다면, 사소한 것으로 치부하는 것은 잘못된 것이라고 생각합니다.Narky Blert (토크) 2018년 9월 24일 (UTC) 20:48
"스토리텔러는 위키피디아 독자들이 검색창에 타이핑해서 찾고 있는 기사를 찾을 수 있도록 도와준다." 완전히 말도 안 되는 소리입니다.검색창에 스토리텔러를 입력하면 리다이렉트 도움 없이 스토리텔러, 스토리텔러(잡지), 스토리텔러, 스토리텔러를 찾을 수 있다.탭 페이지로 리다이렉트 하는 것은 아무에게도 도움이 되지 않으며, 부주의하고 쓸모없는 작업입니다.
이전에 Dab 페이지로의 리다이렉트로 인해 문제가 발생한 적이 있는 경우, 그 차이를 설명하십시오.그렇지 않으면 믿을 수 없습니다.흔들리는 말보다 더 드물기 때문입니다.
이런 문제를 해결하기 위해 오랑우탄을 훈련시킬 수 있어요.10만 클럽 편집자가 쉽게 할 수 없다면 귀에서 솜털을 빼서 입에 넣어야 한다.--RexS(토크) 22:16, 2018년 9월 24일(UTC)
@RexS: WP를 읽고 내적으로 요약하는 것이 좋습니다.AGF 및 WP:퍼스널Narky Blert (토크) 2018년 9월 25일 (UTC) 20:14
@Narky Blert: 제안해 주셔서 감사합니다.검토해 보겠습니다.나는 항상 첫 번째 것이 꽤 유용하다고 생각해 왔다. 그리고 아마 당신이 그것을 읽는다면 당신도 유용하다고 생각할 것이다.두 번째 것은 불행히도 디바들이 화를 내는 핑계일 뿐이지만, 최근 개선되고 있는지 확인해 보겠습니다.--RexxS (talk) 2018년 9월 25일 (UTC)
(편집 충돌) @Certes:죄송합니다, '실제 페이지'라는 말의 의미를 잘못 이해했습니다만, 지금은 이해했습니다.맞습니다. 사이트 링크가 없고 라벨이 탭 페이지를 나타내면 일반 언링크 라벨이 표시됩니다.
짜증스럽게도 리다이렉트 사이트 링크를 d:에서 허용해야 한다는 의견이 이미 다수를 차지하고 있습니다.Wikidata:코멘트 요청/Wikidata에서 리다이렉트 링크 작성을 허용하지만, 플레이스를 운영하는 사람들은 사람들이 원하는 것을 제공하는 데 관심이 없습니다.--RexxS (토크) 22:09, 2018년 9월 23일 (UTC)
좋습니다. Wikipedia 페이지를 이동하면 WP:2REDIR 오류가 발생하거나 WP 후에 발생할 수 있습니다.RM, 잘못된 타겟으로의 리다이렉트 링크.Narky Blert (토크) 2018년 9월 24일 (UTC) 20:48
리다이렉트가 어떻게 작동하는지 아세요?리디렉션 대상인 페이지를 이동하면 더 이상 작동하지 않는 첫 번째 리디렉션입니다.Wikidata 엔티티가 가리키는지에 관계없이 수정해야 합니다.당신의 주장은 Wikidata의 사이트링크가 어떻게 기능하는지와는 완전히 무관하며, 이런 종류의 터무니없는 말을 하기 전에 잘 생각해 볼 필요가 있습니다.--RexS (토크) 22:16, 2018년 9월 24일 (UTC)

mediawiki로 이동

최근 RexS에 의한 놀라운 업데이트 후 모듈은 언어 독립적이기 때문에 소스 코드를 mediawiki로 이동하여 다른 Wiki에서 업데이트를 자동화하는 것이 좋을까요?'모듈'예를 들어 TNT.카판카즈밀요(Talk Infobox assistance) 2018년 11월 1일 17:44 (UTC)

친절한 말씀 감사합니다, 카판카즈밀요.다만, 이 모듈이 완전히 언어에 의존하지 않는지는 아직 확신할 수 없기 때문에, 그러한 주장을 하기 전에 사람들이 어떤 문제에 대해서도 피드백을 할 수 있는 시간을 주고 싶습니다.물론 국제화에 관한 법규에 문제가 있으면 기꺼이 듣고 싶지만, 그 피드백의 대부분은 하원에서 나올 것으로 생각합니다.어쨌든, 다른 사람에게 도움이 된다고 생각되면, 코드의 카피를 중앙의 장소에 두지 않을 이유가 없습니다.건배 - RexS (토크) 18:46, 2018년 11월 1일 (UTC)

소스별 값 검색

특정 소스에 따라 값을 검색할 수 있습니까?동일한 속성을 사용하는 여러 개의 문장이 있고 특정 소스에 의해 주어진 속성의 값을 추출하고 싶다면, 그 함수에 대한 함수가 있습니까?프랑스 WP는 P248을 사용하여 함수를 개발했으며, 그 소스에 따라 다른 가치 후보를 필터링할 수 있는 기준을 가지고 있다.Snippre (토크) 2018년 10월 30일 (UTC) 10:14

@Snipre:모듈을 보면:위키데이터IB#Function_getValueByQual 수식자 값이 Wikibase-Entity이므로 논리 프레임워크가 이미 존재하는 한 수식자 값을 가져오는 방법을 볼 수 있습니다.참조에 관한 문제는 (P248), (P3452), (P143), (P1343), (P854), (P1476) 등 소스를 나타내는 (Wikidata 속성에 대한 SPARQL 쿼리)에 기재되어 있는 (P248), (P3452), (P143), (P1476) 등, (Wikidata 속성에 대한)의 SPARQL 쿼리가 매우 다양하다는 것입니다.특히 소스의 데이터형이 항목, URL 또는 단일 언어 텍스트일 경우 일치할 값을 검색하기 위해 각각 다른 코드를 필요로 하는 경우, 참조를 소싱할 수 있는 24개 이상의 가능한 수단을 각 속성 값에 체크하는 코드를 쓰는 것은 싫습니다.
다만, 마음에 두고 있는 구체적인 케이스가 있거나, 보다 구체적으로 하고 싶은 일의 예를 공유할 수 있다면, 그 일이 훨씬 작아져, 내가 당신에게 기능을 제공할 수 있을지도 모릅니다.
BTW(Wikidata)IB, "Wikipedia"라는 단어를 포함하는 모든 참조는 소스 없이 할인됩니다. 만약 당신이 가치 필터링에 관심이 있다면, 그것은 쉽게 구축할 수 있습니다.또,{{#invoke:Sandbox/RexxS/WdRefs seeRefs}}(이 문서는 임의의 기사 섹션에 붙여넣을 수 있습니다 – 참조 섹션을 사용하여 Wikidata 및 그 참조에서 사용할 수 있는 속성을 미리 볼 수 있습니다.) - RexS (토크) 2018년 10월 30일 (UTC) 22:49
@RexsS: 스테이트먼트에서 소스를 설명하는 방법은 다음 두 가지뿐입니다.도움말에서 설명하는 방법은 다음과 같습니다.출처.또 다른 방법으로는 WD 규칙을 따르지 않으려는 경우나 출처가 무엇인지에 대한 오해 등이 있습니다.P248 속성을 참조를 필터링하는 주요 속성으로 사용하면 대부분의 경우에 해당됩니다.대부분의 경우 데이터의 80%를 사용하면 상황의 주요 특성을 모형화하는 데 충분하며, 나머지는 시간 낭비입니다.저격수 (토크) 2018년 10월 30일 (UTC) 23:37
@Snipre:d:Property를 참조하는 경우:P248 #P2559는 "이 속성을 사용하면 정보가 링크된 정보 소스에 의해 표현되는 엔티티(도서, 기사 등)에 포함되어 있음을 나타냅니다. 정보가 다른 Wikidata 항목에 포함된 정보에서 나온 것임을 기술하려면 P3452."를 사용하십시오.이것은 WD "규칙"이 Wikidata 속성의 명백한 인스턴스로서 (P3452)에서 추론된 것을 포함하므로 d:를 나타내는 소스(Q18608359)를 알 수 있습니다.도움말:소스에 "일반적으로 소스에 사용되는 속성은 두 가지 옵션 중 하나입니다."라고 기술할 때 소스에 포함되지 않았습니다.그래서 내 요점은 성립한다.
단, 특정 항목에 "기재된" 참조가 있는 속성의 값만 함수로 가져오기를 원하는 경우에는 가능합니다.무엇이 필요한지 확인했습니다.내일 추가 코드를 실행합니다.--RexS ( talk ) 2018년 10월 31일 (UTC) 01:25
@RexxS: 소스 정의의 문제가 있습니다.Wikimedia 프로젝트 또는 추정된 데이터는 Wikimedia 세계의 2차 소스 및 참조 소스를 취급하는 가이드라인에 따라 소스가 아닙니다.기여자가 가능한 기준으로 모든 데이터 집합을 필터링할 수 있습니다.단, 가장 일반적인 경우는 다음과 같습니다.하나의 스테이트먼트에 여러 개의 값이 있으며 신뢰할 수 있는 특정 소스에 따라 값을 추출하거나 신뢰할 수 있는 것으로 검증되었습니다.또는 고유한 소스에서 값을 추출하여 동종 데이터 집합을 가져올 수도 있습니다.우선 그것에 집중해서 무슨 일이 일어나는지 봐야 할 것 같아요.따라서 P248이 올바른 시작점입니다.
여러 개의 값을 사용할 수 있을 때 값을 추출하는 방법을 묻는 기고자의 질문에 대한 답변입니다(여기를 참조).
P248을 사용하여 getValueByRef 함수를 추가해주시면 감사하겠습니다.
@Datawiki30: 데이터 추출 요청의 적절한 형식은 RexxS에 문의하십시오.저격수 (토크) 2018년 10월 31일 (UTC) 13:05
@Snipre와 Datawiki30: 코드를 작성했습니다. (P248)에 기재되어 있는 것이 우리가 생각하는 것만큼 일반적인 것은 아닌 것 같습니다.테스트할 예를 찾는 데 많은 어려움을 겪고 있습니다.어쨌든 첫 번째 시도입니다.영국(Q21)의 경우, (P248)BnF 당국(Q20666306)에 명시된 ISNI(P213)의 값을 구하면 다음과 같은 결과를 얻을 수 있습니다.
  • {{#invoke:WikidataIB/sandbox getValueByRefSource qid=Q21 P213 match=Q20666306 fwd=ALL osd=n}}→
테스트해 볼 수 있는 예가 더 있는지, 또는 문제가 생기면 알려주세요.--RexxS (talk) 17:45, 2018년 10월 31일 (UTC)
[추가:] 현재 d: 토론에 ping을 보내고 있습니다.Wikidata:프로젝트 채팅 #통계 데이터 모델링 속성에 대한 몇 가지 기본적인 질문입니다.
Wikidata Sandbox(Q4115189)의 경우, (P248) World Bank Open Data(Q21540096)에 기재된 명목 GDP(P2131)의 가치를 찾습니다.
  • {{#invoke:WikidataIB/sandbox getValueByRefSource qid=Q4115189 P2131 match=Q21540096 fwd=ALL osd=n rank=best}}→
  • {{#invoke:WikidataIB/sandbox getValueByRefSource qid=Q4115189 P2131 match=Q21540096 fwd=ALL osd=n rank=preferred normal}}→
  • {{#invoke:WikidataIB/sandbox getValueByRefSource qid=Q4115189 P2131 match=Q21540096 fwd=ALL osd=n rank=preferred normal deprecated}}→
Wikidata Sandbox(Q4115189)의 경우, (P248)에 기재되어 있는 명목 GDP(P2131)의 가치 검색국제통화기금(Q7804) :
  • {{#invoke:WikidataIB/sandbox getValueByRefSource qid=Q4115189 P2131 match=Q7804 fwd=ALL osd=n rank=b}}→
  • {{#invoke:WikidataIB/sandbox getValueByRefSource qid=Q4115189 P2131 match=Q7804 fwd=ALL osd=n rank=p n}}→
  • {{#invoke:WikidataIB/sandbox getValueByRefSource qid=Q4115189 P2131 match=Q7804 fwd=ALL osd=n rank=p n d}}→
동작하고 있는 것처럼 보이지만, 아마 더 많은 테스트가 필요할 것입니다.--RexxS (talk) 2018년 10월 31일 (UTC) 18:10
@RexxS: 안녕하세요.계약해 주셔서 감사합니다.우리가 "진술된" 소스를 사용하여 부동산의 가치에 접근할 수 있다는 것은 훌륭한 일입니다.이 경우, 「세계은행 데이타베이스」의 「표시」의 속성은 불충분하다고 생각됩니다.이것은, 같은 「표시」의 소스에 대해서, 미 달러와 유로로 가치가 있기 때문입니다.유일한 시스템상의 차이는 URL입니다.https://data.worldbank.org/indicator/NY.GDP.MKTP.CD?locations=FR은 US Dollar, https://data.worldbank.org/indicator/NY.GDP.MKTP.CN?locations=FR은 Euro의 가치를 나타냅니다.각각의 값을 개별적으로 취득하는 경우는, 어떻게 하는 것이 가장 좋을까요.이 경우 각 편집에 대한 자세한 정보(예: 수식자 ID 등)가 필요합니까?기타:
- 수백만 단위 또는 수십억 단위로 값을 회수할 수 있습니까?위키피디아의 정보상자에는 십진법이 너무 길 것 같습니다.
- 샌드박스에서 검색된 값 중 소수점 뒤의 두 번째 값이 잘려나간 것 같습니다.건배!Datawiki30 (토크) 2018년 10월 31일 (UTC) 23:28
@Datawiki30: Wikidata에서 기능을 유지하려고 합니다.다양한 시나리오에서 사용할 수 있도록 가능한 한 일반적인 IB입니다.만약 당신이 달러와 유로를 구별하기 위해 루틴을 더 다듬고 싶다면, 당신은 범용 기능에서 맞춤형 기능으로 전환하고 있다고 생각합니다.그리고 당신은 그것을 하나의 애플리케이션에 할 시간을 할애할 사람을 찾아야 할 것입니다.
유감스럽게도 Wikidata에는 "통화" 데이터형이 없습니다.따라서 "3달러 50센트"와 같은 값이 "3.5달러"로 저장되므로 함수가 반환됩니다.단순히 '3.50달러'로 바꾸는 것만으로 기존의 통화 단위별로 거대한 룩업 테이블을 만들고 싶지 않기 때문에, 표준 문자열 포맷 기능을 사용하여 미묘한 표시를 처리하는 것이 특정 어플리케이션에서 가장 좋다고 생각합니다.
수백만 단위 또는 수십억 단위로 표시하는 문제는 더 복잡합니다."100만 파운드" 또는 "100만 파운드" 중 어느 쪽을 표시할지를 루틴에서 어떻게 결정해야 하는가?수량이 "123만4567달러"인 경우 "123만4567달러"를 표시하면 실제로 더 많은 공간을 차지합니다.물론 다른 파라미터를 추가하여 두 형식 간에 디스플레이를 전환할 수도 있지만, 이미 30개가 넘는 파라미터(및 일부 문서화되어 있지 않은 파라미터)가 있기 때문에 다른 파라미터를 추가하기 위한 설득력 있는 사용사례 또는 모든 용도에 대해 자동으로 결정을 내릴 수 있는 강력한 알고리즘이 필요합니다. --RexS (talk) 18:32,2018년 11월 1일 (UTC)
@RexS: 제가 염두에 두고 있는 사용 사례는 우선 모든 국가뿐만 아니라 도시와 지역의 정보박스입니다.예를 들어 영국의 영어 위키피디아에서는 Wikidata를 Puppulation, GDP(PPP) 총계 및 1인당 명목 총계, Gini 및 HDI에 사용할 수 있다.GDP PPP와 명목의 경우, 우리는 다른 출처의 위키데이터에서 다른 통화를 갖게 될 것이다.Birmingam의 경우 우리는 또한 USD로 GDP 견적을 가지고 있다.
나는 복잡한 해결책을 선호하지 않는다.Wikidata의 각 문장에 대한 표준 제목 속성을 추가하면 어떨까요?이것은, 다음의 설명에 준거하고 있을 필요가 있습니다.이제 적절한 제목 속성을 Wikidata의 샌드박스 문에 추가했습니다."stated in"과 "title"의 조합을 필터로 사용하여 우선 순위에서 각 명목 gdp 값을 검색할 수 있습니까?이 조합은 보통 다른 값을 식별하기에 충분한 원자성이어야 합니다.
값 자르기: 모든 값에는 소수점 쉼표 뒤에 두 개의 디지스트가 있어야 합니다(wikidata 샌드박스 확인).명목 GDP의 경우 그러한 정밀도는 절대 중요하지 않지만, 다른 특성(함수가 값을 반올림합니까?)의 경우:
*{{#invoke:WikidataIB/sandbox getValueByRefSource qid=Q4115189 P2131 match=Q21540096 fwd=ALL osd=n rank=preferred normal}}→
나는 백만 단위의 가치 등에 대한 예를 가지고 있다.: 두 가지 파라미터를 사용할 수 있습니다.값이 분할된 10^x 포텐션과 그 후 값을 절단해야 합니다.함수는 값만 취득하고 유니티(USD 등)는 취득하지 않습니다.Infobox에서는 값을 취득하는 함수를 사용하여 예를 들어 "in billion USD"를 추가해야 합니다.이 작업은 Wikidata에서 새로운 값이 생성되면 자동으로 값이 업데이트됩니다.예: function(123,456,789,012.34567 US Dollar, 10^9, 1) = 123.4.이것에 대해 어떻게 생각하세요?건배! --Datawiki30 (토크)2018년 11월 1일 (UTC) 21:54
@Datawiki30: 현시점에서는 Wikidata Sandbox (Q4115189)를 보고 있습니다.이제 당신이 발견한 잘린 부분을 볼 수 있습니다.Sandbox-Quantity(P1106)에 대해 세 가지 값을 추가했습니다.USD465,134,297,438.91, USD12,465,134,297,438.91, USD112,465,134,297,438.91 - 함수는 실제로 14자리 이후에 값을 반올림하는 것으로 생각됩니다.이것은 mw.language formatNum() 메서드에서만 발생합니다.
{{wdib ps=1 qid=Q4115189 P1106 uabbr=y}}→
더 조사해 볼 수는 있지만, 그것에 대해 제가 현명하게 할 수 있는 일이 별로 없을 것 같습니다.개인적으로는 2조 달러에 10센트까지 손해를 보는 것에 대해 걱정하지 않습니다.--RexS(대화) 00:13, 2018년 11월 2일(UTC)
@RexS : 통화 데이터형은 없지만, 기재된 데이터는 수치 데이터형으로 저장됩니다.수치 데이터형은 값과 단위로 정의되므로 단위 값을 사용하여 유로 값이 아닌 달러 값을 필터링 및 추출할 수 있습니다.그러나 일반적인 함수에서는 여러 필터링을 수행할 수 없으며 특별한 데이터 형식을 사용하여 복잡한 추출을 수행하려면 lus의 정보 상자를 코딩해야 합니다.스나이프(토크) 2018년 11월 2일(UTC) 20:20
@Datawiki30: 위와 같이 복잡한 데이터 추출 및 특별한 데이터 형성을 수행할 때는 단순한 lua 기능보다 더 많은 가능성을 제공하는 lua 코드 인포박스로 전환하는 것이 좋습니다.스나이프(토크) 2018년 11월 2일(UTC) 20:20
@Snipre:네, 위에서 통화 데이터형이 없다고 말씀드렸습니다.또, 그 값이 값 플러스 단위로 보존되어 있기 때문에, 유로가 아닌 달러 가치를 반환하도록 필터링 할 수 있는 것도 알고 있습니다.하지만 달러로 환산한 가치가 없다면 무엇을 반환해야 할까요?다음 응용 프로그램에서 파운드 단위로 금액을 원하는 경우 어떻게 해야 합니까?아니면 유로화?아니면 루피?또는 kgrames, 또는 데이터 타입 "type"이 들어갈 수 있는 다른 단위가 있습니까?명목 GDP(P2131)의 달러 값을 가져와 특정 형식으로 포맷하는 맞춤형 함수를 요구하는 경우 해당 함수를 작성하는 것은 완벽하게 가능하지만 이 스레드의 원래 요청은 그렇지 않습니다. --RexS (talk) 20:49, 2018년 11월 2일 (UTC)

@Datawiki30:세계은행 오픈 데이터(Q21540096), 국제통화기금(Q7804), 미국 달러(Q4917), 유로(Q4916):

  • {{#invoke:WikidataIB/sandbox getValueByRefSource qid=Q4115189 P2131 match=Q21540096 unit=Q4917 fwd=ALL rank=p n}}→
  • {{#invoke:WikidataIB/sandbox getValueByRefSource qid=Q4115189 P2131 match=Q7804 unit=Q4917 fwd=ALL rank=p n}}→
  • {{#invoke:WikidataIB/sandbox getValueByRefSource qid=Q4115189 P2131 match=Q21540096 unit=Q4916 fwd=ALL rank=p n}}→
  • {{#invoke:WikidataIB/sandbox getValueByRefSource qid=Q4115189 P2131 match=Q7804 unit=Q4916 fwd=ALL rank=p n}}→

원하는 것에 가깝습니까?--RexS (대화) 2018년 11월 2일 (UTC) 23:01

최고의 순위를 매기려고 합니다.

  • {{#invoke:WikidataIB/sandbox getValueByRefSource qid=Q4115189 P2131 match=Q21540096 unit=Q4917 fwd=ALL osd=n rank=best}}→
  • {{#invoke:WikidataIB/sandbox getValueByRefSource qid=Q4115189 P2131 match=Q7804 unit=Q4917 fwd=ALL osd=n rank=best}}→
  • {{#invoke:WikidataIB/sandbox getValueByRefSource qid=Q4115189 P2131 match=Q21540096 unit=Q4916 fwd=ALL osd=n rank=best}}→
  • {{#invoke:WikidataIB/sandbox getValueByRefSource qid=Q4115189 P2131 match=Q7804 unit=Q4916 fwd=ALL osd=n rank=best}}→

--Datawiki30 (토크) 2018년 11월 2일 (UTC) 23:17

@Datawiki30: 파라미터 1개 추가, scale=추가됨. 숫자 값 3 ~ 12 또는 "auto"/"a" 중 하나를 사용하여 수천, 수백만, 수십억, 수조 또는 자동으로 확장할 수 있습니다.
예에 대해서는 모듈토크를 참조해 주세요.위키데이터IB/샌드박스/테스트 #스케일링 수량. --RexS(토크) 15:22, 2018년 11월 3일(UTC)

테스트 데이터?

@RexS: 모듈에 얼마나 체크코드를 삽입하고 싶은지는 모르겠지만 부록(해부학)은 현재 카테고리에 있습니다.스크립트 오류가 있는 페이지("모듈의 Lua 오류:위키데이터426행의 IB: Mike Peel이 {Commons category}을(를) 편집하고 부록(Q9656)에 토픽의 메인 카테고리(P910)가 파손되어 있기 때문에, 「datavalue」필드의 인덱스를 작성하려고 합니다.에러를 트리거하는 아티클의 코드(렌더된 페이지에는 표시되지 않음)는 다음과 같습니다.{{Commons category Vermiform appendix Appendix (anatomy)}}이러한 에러는 Wikidata 문제를 인식 및 수정하는 기능으로 간주해야 합니까?아니면 모듈이 존재하지 않는 P910과 같은 방법으로 제로 데이터 베이스를 취급해야 합니까?잘 모르겠지만, 만약 전자라면 더 좋은 오류 메시지가 좋을 것 같아요.모듈의 함수를 사용하여 getBestStatements를 호출하여 원하는 속성을 얻을 수 있습니다.데이터값이 0일 경우 0을 반환할 수 없습니다.또는 무효일 경우 보다 명확한 이유를 가진 오류를 발생시키는가?참고로 저는 글로벌 변수를 체크하기 위해 스크립트를 사용합니다.bestval checkLanguage dsep dv found pd froppes v1.Johnuniq (토크) 2018년 11월 15일 (UTC) 09:08

알아봐줘서 고마워, 존오류를 포착하여 대처하는 것이 최선인지, 아니면 오류를 일으킨 Wikidata 엔트리를 오류로 인해 회수하는 것이 최선인지 잘 모르겠습니다.이 경우 부록(Q9656)에서 토픽의 메인 카테고리(P910)의 엔트리는 "값 없음"으로 설정해서는 안 되기 때문에 무시하도록 코드를 수정할 필요가 없습니다(그냥 사용할 수 있습니다).if prop910 and prop.mainsnak.datavalue then)) 이 시점에서 적절한 에러 메시지를 송신하려면 , 상당한 재기입을 실시할 필요가 있습니다.다만, 어느 토픽의 메인 카테고리(P910)에서도 「값 없음」이나 「값」의 엔트리에 대해서는 생각할 수 있는 이유를 알 수 없기 때문에, 공통 카테고리(P373)에서도 마찬가지로 Wikidata 엔트리를 수정하는 것이 바람직하다고 생각합니다.나중에 P910="no value"인 엔트리에 대한 WDQS 검색을 실행하여 잠재적인 문제가 얼마나 큰지 알아보겠습니다.현재 ns0의 스크립트 오류는 3개의 엔트리만 표시하고 있습니다.
그거 도움이 되네, 대본다 살펴봤는데 네가 찾은 지구촌은 다 청소한 것 같아코드는 깨끗한 것 같다.테스트 페이지에 에러는 표시되지 않는다.감사합니다! --RexS (토크) 15:57, 2018년 11월 15일 (UTC)

cywiki에서의 갱신

참조: 지리 태그가 달린 모든 기사에 대한 새로운 Wikidata Infobox.

모듈을 업데이트했습니다.위키데이터9월 21일까지 IB가 싸이위키를 사용하다가 오류가 발생했습니다.아이디어나 도움이 필요하세요?모듈을 직접 편집하십시오(샌독스/테스트 불필요).Lywelyn2000 (토크) 2018년 11월 15일 (UTC) 15:14

@Lywelyn2000: 이 편집에서는 cy:Modywl:I18n/date, "복잡한 날짜" 시리즈 모듈에서 사용되는 원래 버전에서 타임라인을 생성하는 버전으로 완전히 변경했습니다.왜 그랬는지 기억나요?제가 본 바로는 이 모듈은 다른 cy-wiki에서는 사용되지 않기 때문에 이전 버전을 복원했습니다.다른 문제가 있으면 알려주시고 다른 해결책을 찾아보겠습니다.cy 버전을 업데이트했습니다.Modiwl: I18n/복잡한 날짜로 인해 오류가 발생하였습니다.현재는 정상적으로 동작하고 있다고 생각합니다(계속 업데이트 할 수 있습니다).하지만 문제가 발생하면 알려주세요.--RexS ( talk ) 2018년 11월 15일 (UTC) 18:05
안녕, 더그, 그리고 도와줘서 고마워!효과가 없어서 변경한 것 같아요.그때 wd infobox에서 작업을 하고 있었기 때문에 Commons나 WD 자체를 선택했습니다.하지만 내가 틀릴 수도 있어!하지만 좋은 자리야, 다시 한 번 고마워!한 가지 요약: 템플릿에서 회색 헤더는 정상인 것 같습니다.Gwybodlen lle 예 과테말라(왼쪽 아래).그러나 w:cy의 동일한 정보 상자:과테말라 기사, 단 하나: 'Daearyddiaeth' (지리)왜 다른 사람들이 나타나지 않는지 알아?잘 부탁드립니다...Lywelyn2000 (토크) 2018년 11월 15일 19:21 (UTC)
@RexS: Bore da Doug!이제 업데이트가 w:cy: 에 영향을 줍니다.Nodyn:Gwybodlen person/Wikidata(바이오그 템플릿)는 다음과 같습니다.Lywelyn2000 (토크) 2018년 11월 16일 (UTC) 05:25
지루해, 로빈!문제는 템플릿 w:cy:Gwybodlen person/Wikidata는 아직 반밖에 완성되지 않았습니다.Diflanodd와 같은 18개 필드에는 Wikidata 속성을 위한 자리 표시자("P0")만 있습니다.그들은 적절한 숫자를 알아낼 누군가가 필요하다.그 중 8개를 관리했습니다만, 대부분의 경우 어떤 P값을 사용할지 충분히 번역할 수 없습니다.또한 Wikidata 속성을 찾을 수 없습니다.나머지 10개는 운이 더 좋을 수 있습니다.--RexS (대화) 2018년 11월 16일 (UTC) 11:57
감사합니다! 네, 저는 이 스위치를 켜지 않았습니다.그때는 WD에 관한 것이 거의 없었기 때문입니다.가능한 한 빨리 살펴보도록 하겠습니다. 다시 한 번 더그에게 감사드립니다!WD에 대한 당신의 연구는 앞으로 몇 년 동안 많은 위키피디아에 결실을 맺을 것입니다!Lywelyn2000 (토크) 2018년 11월 16일 12:06 (UTC)
업데이트는 보다 효율적인 Wikibase 클라이언트에 대한 새로운 호출을 사용하지만 잘못된 속성 번호가 제공되면 오류가 발생한다고 말했어야 합니다.잘못된 속성 번호를 자동으로 거부하도록 코드를 수정했으므로 "P0"을 다시 템플릿에 자리 표시자로 남겨도 문제가 없습니다.건배! --RexS (토크) 2018년 11월 16일 (UTC) 12:10
@Lywelyn2000: 기사 cy:Gwothema가 템플릿 문서와 다른 정보 상자를 표시하는 이유는 템플릿 문서 내에 있는 정보가 있기 때문입니다.fetchwikidata=ALL하지만 기사에서는 그렇지 않습니다.디폴트로 ALL을 추가했습니다.{{{fetchwikidata }}}(과 같이){{{fetchwikidata ALL}}})를 사용하면 놓쳐도 서브패킷이 표시됩니다.fetchwikidata=ALL템플릿 콜에서. --RexS (talk) 22:40, 2018년 11월 16일 (UTC)
그리고 그들이 돌아왔어!더그 고마워요!Lywelyn2000 (토크) 2018년 11월 17일 05:09 (UTC)