모듈 토크:임의 포털 구성 요소

	포털
이 페이지는 Wikipedia의 포털을 개선하기 위한 공동 노력인 Wikipedia Project Portals의 범위 내에 있습니다.참여를 원하는 경우, 토론에 참여하고 열려 있는 작업 목록을 볼 수 있는 프로젝트 페이지를 방문하십시오.포털위키백과:Wiki 프로젝트 포털템플릿:Wiki 프로젝트 포털 페이지 템플릿 이 모듈은 프로젝트의 품질 척도에 대한 등급이 필요하지 않습니다. 참고 항목:포털 목록

@스트라디바리우스 씨:이 모듈의 최근 변경 사항으로 인해 페이지가 누락된 모든 포털이 카테고리:스크립트 오류가 있는 페이지입니다.우리는 이것을 어떻게 해야 할까요?Jackmcbarn (대화) 2014년 12월 4일 23:07, UTC 답변 [답장]

@Jackmcbarn:오류를 파악하여 별도의 추적 범주에 넣는 것이 가장 좋을 것 같습니다.Stradivarius^{♪ talk ♪} 씨, 2014년 12월 4일 23:21 (UTC) 회신 [답장]

존재하지 않는 콘텐츠 하위 페이지가 있는 포털에서 오류를 감지하도록 모듈을 변경하여 범주:주의가 필요한 포털입니다.Stradivarius^{♪ talk ♪} 씨, 2014년 12월 4일 23:39 (UTC) 회신 [답장]

@브라운 헤어걸:최근 하위 페이지 추적 코드를 추가해 주셔서 감사합니다.:) 템플릿에서 발견했습니다.하위 페이지 수 추적 범주가 있는 포털에서는 51–100, 101–200, 201–500, 501–1000 및 >1000의 하위 페이지 수에 대한 범주를 설명했습니다. 이는 해당 범주를 확인하면 값비싼 기능 수를 초과할 수 있기 때문일 것입니다.모든 페이지가 존재하는지 확인하지 말고 경계 페이지만 존재하는지 확인하는 바로가기를 사용하면 어떨까요?알고리즘은 다음과 같습니다.

1. 하위 페이지 #2가 존재하는지 확인합니다.버전이 있는 경우 2단계로 이동합니다.그렇지 않으면 페이지를 카테고리:사용 가능한 하위 페이지가 2개 미만인 임의 포털 구성 요소를 종료합니다.
2. #6 하위 페이지가 존재하는지 확인합니다.버전이 있는 경우 3단계로 이동합니다.그렇지 않으면 페이지를 카테고리:2-5개의 사용 가능한 하위 페이지가 있는 임의 포털 구성요소를 종료합니다.
3. #11, #16, #21, #26, #31, #41, #51, #101, #201, #501 페이지를 반복합니다.
4. 마지막으로 서브페이지 #1001이 존재하는지 확인합니다.페이지가 존재하는 경우, 페이지를 카테고리:사용 가능한 하위 페이지가 1000개 이상인 임의 포털 구성 요소입니다.그렇지 않으면 페이지를 카테고리:501–1000개의 사용 가능한 하위 페이지를 포함하는 임의 포털 구성요소.

이렇게 하면 각 범주당 하나씩, 최대 13개의 값비싼 함수 호출을 사용할 수 있습니다.하지만 서브페이지 번호에 공백이 생기면 알고리즘이 제대로 작동하지 않는다는 단점이 있습니다.예를 들어, 포털에 #1, #3 및 #4 하위 페이지가 있지만 #2가 존재하지 않는 경우 알고리즘은 "2-5" 범주에 있어야 할 때 "2 미만" 범주에 포털을 배치합니다.이것이 허용 가능한 절충안이라고 생각하는지 아닌지 알려주십시오.베스트 — Stradivarius 씨, 2019년 5월 2일 06:17 (UTC) 회신 [회신]

감사합니다, 스트라디바리우스 씨.그것은 매우 사려 깊은 제안이고, 네, 비싼 함수 수가 문제였습니다.그것은 모듈들이 큰 세트에서 고장을 일으켜 빨간 링크와 오류 메시지를 남겼고 슬프게도 MFD: 주 수준의 도로 포털과 같은 일부 드라마를 촉발시켰습니다.

제시된 바와 같이 경계 페이지만 생성하여 시스템을 게임화할 수 있다고 생각합니다. 하지만 경계 사이의 페이지를 무작위로 검사하는 것이 수반된다면 게임화는 피할 수 있습니다.예를 들어 101페이지가 존재하는 경우 51-100 범위의 페이지 랜덤 샘플을 확인하고 누락된 페이지가 있으면 어떻게든 분류합니다.그것은 아마도 여전히 불일치 검사의 종료를 의미할 것이고, 이것은 유감스러운 일입니다.

하지만 추적 시스템을 만든 후의 정말 사려 깊은 피드백은 제가 처음에 가졌던 가정을 다시 평가하게 만들었습니다.저는 자동화된 포털에 사용했던 코드를 복사하고 해킹하는 것으로 시작하여 동일한 임계값을 유지했습니다.하지만 이제 결과를 살펴보니 숫자가 높은 범주가 유용하다는 확신이 덜 듭니다.저는 50이 넘는 모든 세트를 "충분히 큰" 세트로 보고, 그것을 "충분히 큰" 세트, "충분히 큰" 세트, "충분히 큰" 세트, "충분히 큰" 세트 등으로 나눌 가치가 있다고 확신합니다.

저는 @에스프레소 어딕트가 그 숫자를 아마도 분할이 필요한 집합으로 간주한다고 생각합니다.EA의 입에 말을 넣지 않았으면 좋겠지만, 아마도 EA가 핑에 반응하여 50세트 이상을 소유하는 것에 대해 어떻게 생각하는지 우리에게 알려줄 것입니다. --Brown Haired Girl (talk) • (기여) 2019년 5월 2일 20:30, (UTC)응답[응답]

개인적인 견해일 뿐이지만, 20-40 범위의 것이 각 포털 텍스트 상자에 가장 적합하다는 것을 알게 되었습니다.이렇게 하면 보통 새로 고칠 때 다른 내용이 나타납니다(열이 두 개 나란히 있는 경우에는 적어도 하나는 항상 변경됩니다). 하지만 독자들은 실제로 내용을 볼 수 있는 가능성이 있습니다.따라서 50개 이상의 추적 범주를 나누는 것이 그렇게 유용한지 확신할 수 없습니다. 분할해야 하는 선택 항목이 너무 많은 포털을 식별하는 것 외에는요.하지만 그것은 삭제 토론에 포털을 가져가기에 좋은 이유가 아니기 때문에, 그러한 추적 범주가 그렇게 유용할지 확신할 수 없습니다.에스프레소 어딕트(talk) 21:10, 2019년 5월 2일 (UTC) 회신 [답장]

@브라운 헤어걸과 에스프레소 중독자:저는 아이디어가 있습니다. 지수 검색 알고리즘을 사용하여 가장 높은 하위 페이지 번호를 찾는 것은 어떨까요?지수 검색은 log(n) 시간에 실행되므로 포털에 1000개의 하위 페이지가 있더라도 알고리즘은 약 20개의 값비싼 함수 호출만 수행하면 됩니다.이런 식으로 우리는 그것을 더 이상 사용하지 않을 수 있습니다. max=매개 변수; 지수 검색에서 가장 높은 하위 페이지 번호를 찾을 수 있다면 하위 페이지 추적 범주와 임의 페이지 생성 모두에 해당 번호를 사용할 수 있으며, 포털 관리자가 하위 페이지 수 자체를 추적하는 수고를 덜 수 있습니다.알고리즘 작동 방식에 대한 아이디어를 제공하려면 #1, #2, #3, #4 및 #5의 5개 하위 페이지가 있는 페이지를 생각해 보십시오.하위 페이지 #1에서 확인을 시작하면 다음과 같이 작동합니다.

1. 하위 페이지 #1이 존재하는지 확인합니다.그렇습니다. 따라서 하위 페이지가 하나 이상 있어야 합니다.
2. 하위 페이지 번호를 두 배로 늘립니다.이것은 우리에게 서브페이지 #2를 제공합니다.하위 페이지 #2가 존재하므로 하위 페이지가 2개 이상 있어야 합니다.
3. 하위 페이지 번호를 두 배로 늘립니다.이것은 우리에게 서브페이지 #4를 제공합니다.하위 페이지 #4가 존재하므로 하위 페이지가 4개 이상 있어야 합니다.
4. 하위 페이지 번호를 두 배로 늘립니다.이것은 우리에게 서브페이지 #8을 제공합니다.하위 페이지 #8이 존재하지 않으므로 하위 페이지가 4개에서 7개 사이여야 합니다.
5. 4와 8 사이의 중간 지점을 찾으십시오.이것은 우리에게 6페이지 하위 페이지를 줍니다.하위 페이지 #6이 존재하지 않으므로 하위 페이지가 4개 또는 5개여야 합니다.
6. 4와 6 사이의 중간 지점을 찾으십시오.이것은 우리에게 서브페이지 #5를 제공합니다.하위 페이지 #5가 존재하므로 하위 페이지가 5개여야 한다는 것을 알고 있습니다.

그러나 이 알고리즘은 하위 페이지 번호에 공백이 있을 경우 부정확한 결과를 생성한다는 단점도 있습니다.예를 들어, 위의 예에서 #4 하위 페이지가 없는 경우 알고리즘은 #4보다 높은 하위 페이지를 찾는 것을 중지하고 #3 하위 페이지를 가장 높은 하위 페이지로 반환합니다.하위 페이지 번호에 공백이 있는 경우, 누락된 정확한 하위 페이지 번호와 검색을 시작하는 번호에 따라 일부 하위 페이지가 완전히 표시되지 않음을 의미할 수 있습니다.그것들을 찾기 위해, 아마도 우리는 봇을 사용할 수 있습니다. (아마도 우리는 모든 사용되지 않는 것들을 제거하기 위해 봇을 사용해야 할 것입니다. max= 어쨌든, 만약 우리가 이것이 좋은 생각이라고 결정한다면.)당신의 의견을 저에게 알려주십시오.베스트 — Stradivarius^{♪ talk ♪} 씨, 2019년 5월 3일 09:05 (UTC) 회신 [회신]

@Stradivarius씨, 몇 가지 장점과 단점이 있는 흥미로운 아이디어입니다.

개인적으로, 저는 잘 개발된 포털과 사산된 포털을 구별하는 것을 돕기 위해 이러한 추적기를 주로 즉시 거친 분류를 위해 이러한 추적기를 만들었습니다.그러나 잡지 스타일의 포털을 유지하고 싶다면(@EA는 하지만 저는 훨씬 덜 관심이 있습니다), 콘텐츠 포크 하위 페이지의 끔찍한 확산을 가능한 한 해체하고, 작년에 개발된 코드 중 일부를 단순히 기사 목록을 가지고 MOS:LED를 자동으로 추출하는 것이 최우선 과제라고 생각합니다.그래서 저는 포크 시스템을 닦는 데 많은 시간을 쓰고 싶지 않습니다. --Brown Hair Girl (talk) • (기여) 2019년 5월 3일 (UTC) 09:17, 답장[회신]

@갈색 머리 소녀와 스트라디바리우스 씨:만약 max가 실제 서브페이지 수와 맞지 않거나 서브페이지 목록에 공백이 있다면 포털 관리자의 역량이 많이 부족했고 또 다른 중대한 결함이 있을 것이라고 생각합니다.저는 지나치게 다듬어진 수동 포털을 좋아하지만, 블러를 만드는 데 많은 시간을 할애하는 포털 관리자(오페라 프로젝트를 제외하고)를 잘 알지 못합니다.그러나 리드 추출 프로세스는 정렬되지 않았고 (나 같은 프로그래머가 아닌 사람이 생각하는 것보다 더 어려울 수도 있음) 품질에 상당한 문제가 있습니다.관리되지 않는 낮은 품질의 포털에는 없는 것보다 나을 수도 있지만, 이 포털에 대한 제 실험은 중간 품질의 포털을 생성하는 데 긍정적이지 않았습니다.브라운 헤어걸의 매우 다중 서브 페이지 모델에 대한 문제를 볼 수 있어서 매우 답답합니다.에스프레소 어딕트 (talk) 10:07, 2019년 5월 3일 (UTC) 회신 [답장]

포털에서 값비싼 파서 기능 제한을 해결하려고 노력해 왔습니다.샌프란시스코 베이 에어리어입니다만, 제가 예상했던 것과는 전혀 다르게 작동하고 있지 않습니다.하나의 임의 포털 구성요소를 호출할 때는 카운트를 1만큼 줄이지만, 두 개를 호출할 때는 하위 페이지가 몇 개 있더라도 제거됩니다.사용된 하위 페이지의 양을 변경해도 아무런 효과가 없습니다.왜 이런 일이 일어나는지 저는 전혀 모르고 도움을 주시면 감사하겠습니다.페이지가 존재하는지 확인하지 않는 모드가 유용할까요? --Trialpears (talk) 2019년 9월 22일 (UTC) 22:25, Reply [reply]