위키백과:마을 펌프(제안)/아카이브 10

학술적(및 기타) 출처 목록

특정 책이나 책을 소유하거나 접근할 수 있는 사람들의 목록(또는 더 가능성이 높은 몇 개의 목록)을 갖는 것이 유용하다고 생각한다. 그 목록은 저자별로 구성될 수 있고, 그 다음에 서명처럼 책이 추가된 책을 말한 모든 사람의 사용자 이름과 함께 제목이 붙을 수 있다.이것은 작가들이 팩트체크나 그런 것들을 서로 돕는데 도움을 줄 것이다.SJMNY (대화) 2007년 12월 18일 (UTC) 22:54 [응답]

불행히도 나는 그것이 어떻게 작동할지 상상할 수 없다.거의 유지될 수 없을 것이다. - Rjd0060 (대화) 23:00, 2007년 12월 18일 (UTC)[응답하라]

상상할 수 없는 상황에 온 것을 환영한다. [Wikipedia:Wiki프로젝트 리소스 교환.존보드 (토크) 02:15, 2007년 12월 19일 (UTC)[응답]

와우 고마워. 검색으로는 못 찾겠는데, 대부분의 사람들이 알고 있는 거야?SJMNY (대화) 02:16, 2007년 12월 19일 (UTC)[응답하라]

대부분의 사람들이 지수에 대해 모르기 때문에 여기서는 물건을 찾기가 어렵다.예를 들어, 그것은 또한 도서관의 위키백과 그룹을 나열한다.Thing.com. -- -- John Brown (삼겹살) 2007년 12월 19일 (UTC) 13:38[응답]

다양한 주제 영역에 대한 임의의 기사

나는 그들이 다양한 과목의 무작위 기사 생성기가 되어야 한다고 생각한다. 예를 들어 수학에 관한 무작위 기사를 원한다면 수학 포털로 가서 무작위 기사 링크를 클릭할 것이다.자이펀 (대화) 04:50, 2007년 12월 13일 (UTC)[응답]

나는 지지한다.나는 또한 무작위 피처링 기사와 무작위 FA/GA 기사를 선택할 수 있는 방법이 있어야 한다고 생각한다.아마도 우리는 임의의 기사 생성 페이지를 가질 수 있을 것이다.과목별 현명한 무작위화는 위키피디아가 할 수 있다.2007년 12월 13일 아르만 08:17 (UTC)[응답하라]

FA의 수가 한정되어 있기 때문에(GA와 통화하지 않을 것이다) 임의의 기사 페이지를 설정하는 것은 그다지 어렵지 않아 보인다 - 예를 들어, 포털:중간지점/랜덤 기사.

독자들이 그것을 알게 하는 한, 아마도 메인 페이지의 "오늘의 특집 기사" 섹션에 있는 링크일 것이다. 그래서 페이지 하단의 링크는 Archive – By e-mail – More f특집 기사 - Random 피처링 기사 - John Bringon (기억) 19:53, 2007년 12월 13일 (UTC)[응답]을 읽게 될 것이다.

bugzilla:2170을 참조하십시오.범주(예: 범주:FA-Class 기사) 그러나 성능상의 이유로 위키미디어 위키에서는 이 기능을 사용할 수 없다.Gracenotes^T § 20:31, 2007년 12월 13일 (UTC)[응답]

범주는 여기서 일관성 있게 구성되지 않는다.주어진 위키프로젝트의 기치 아래 임의의 기사를 입수하는 것이 좋을 것이다.--파로스 (토크) 05:20, 2007년 12월 21일 (UTC)[응답]

메인 스페이스에 대한 중요 문서 통계

위키피디아의 주요 비판 중 하나는 위키피디아의 글이 종종 신뢰할 수 없다는 것이다.위키백과나 위키백과 팬들이 이 불만을 변호하려고 할 때마다, 그들은 일반적으로 위키백과 기사의 신뢰도를 몇 가지 간단한 테스트로 확인할 수 있다고 강조한다.다음과 같은 경우:

• 만약 그 기사가 검증가능성/사실적 정확성/중립성 태그를 가지고 있다면, 그것은 신뢰할 수 없을 것이다.이 경우 기사 페이지와 함께 토론 페이지를 참조하는 것이 바람직하다.
• 기사가 오래될수록 기사가 안정적이고 믿을 수 있는 가능성이 높아진다.
• 여러 명의 독특한 편집자가 기고한 기사는 한 명 또는 몇 명의 편집자만이 편집한 기사보다 더 신뢰할 수 있을 것 같다.
• 최근 변경 또는 변경 빈도가 매우 높은 기사의 경우 다른 편집자가 아직 이러한 변경사항을 검증할 기회를 얻지 못했기 때문에 신뢰성이 떨어질 수 있다.

이 모든 것들이 경험이 많은 위키피디아 사람들에게는 매우 단순하게 들리지만, 대부분의 새로운 사용자들은 이 모든 것을 확인하는 방법에 익숙하지 않다.

그래서 나는 다음과 같이 제안한다.

기사 메인 스페이스의 가시적인 위치에 기사의 중요한 정보를 보여주는 작지만 눈에 띄는 상자(글꼴이 작음)가 있어야 한다.기사 머리글, 바닥글 또는 심지어 왼쪽의 위키백과 로고 바로 아래에 있을 수 있다.상자에는 다음 정보가 포함되어야 한다.

1. 기사가 FA인지 GA인지.이 선이 아니라면 생략하십시오.
2. 기사의 검증 가능성/사실적 정확성/중립성/공명성 여부가 논란이 되고 있다."disputed" 단어는 토크 페이지에 연결될 수 있다.분쟁이 없다면 이 선은 생략해야 한다.또한 이것이 실행된다면, 현재 기사 시작 부분에 나타나는 "못된" 태그는 모두 제거되어야 한다.
3. 그 기사는 몇 년이고 언제 마지막으로 편집되었는가.
4. 얼마나 많은 독특한 편집자들이 이 기사에 기고했는가.
5. 지난 24시간 동안 받은 편집 횟수최근 24시간 동안 편집이 없으면 이 행을 생략할 수 있다.

내가 5개의 문장을 제안했지만, 제안된 누락과 함께, 대부분의 기사의 문장 수는 2-3개로 줄어들 것이다.

이것은 글을 어떻게 사용할지, 어느 정도까지 기사에 의존할 수 있는지를 결정하기 위해 독자가 알아야 할 중요한 정보들이다.그래서 나는 이 정보들이 기사 페이지에 속한다고 생각한다.아르만 06:28, 2007년 12월 13일 (UTC)[응답]

이것은 나쁜 생각이 아니다.사실, 그것은 좋은 생각이다.일화적으로 위키피디아를 사용하는 무심코 비편집자에 대한 경험으로 보아 '토론'이나 '역사' 탭을 확인하는 것에 대해 전혀 알지 못한다.그들은 그저 기사를 읽었을 뿐이다.이 사람들은 제안된 유형의 정보 상자를 보게 될 것이고, 나는 그들이 위키피디아의 가장 일반적인 사용자라고 생각한다.건배!Wassupwestcoast (대화) 13:55, 2007년 12월 13일 (UTC)[응답]

지금 있는 거대하고 추한 현수막보다 확실히 낫다.
그러나, 나는 한가지 제안이 있다.보호 기사에 추가된 현재의 배너는 추악하다(그래서 일부 관리자가 자물쇠로 교체한다).아마도 이것은 상자 안에 언급될 수 있을 것이다(그리고 페이지가 보호되지 않는 경우 생략).
게다가, 만약 합의가 이루어진다면, 우리는 현재의 배너를 이 콤팩트 박스로 변형시킬 수 있는 봇을 얻을 수 있을 것이다.
내가 확신할 수 없는 것은 이 상자의 배치다.나는 바닥글이 눈에 띄는 장소로는 부족하다고 생각하는데, 네가 지적했듯이, 이것은 사용자들이 알기에 중요한 것이다.내 아이디어는 (인터위키 링크와 함께) 도구상자인데, 머리글에 있는 것이 더 좋다.푸치코 (토크-이메일) 2007년 12월 13일 (UTC) 14:48 [응답]

개념적으로는 좋은 생각이지만 나는 대부분의 독자들이 그 통계들을 어떻게 생각해야 할지 전혀 알지 못할 것이라고 생각한다.통계치를 신뢰도 등급이라는 단일 숫자로 요약하는 것이 가능하다고 생각하십니까?Sbowers3 (대화) 17:01, 2007년 12월 13일 (UTC)[응답]

위키피디아는 그 기사의 신뢰성에 대해 부인하지 않으며, 경험적으로 근거한 거부권은 득보다 실이 많을 수 있다.Sbowers3가 말했듯이, 대부분의 독자들은 그 통계가 무엇을 의미하는지 이해하지 못할 수도 있다(그리고 심지어 부정확한 추측을 할 수도 있다).캐시할 수 없기 때문에 24시간 줄이 문제가 될 수 있다. 사용자가 페이지를 방문할 때마다 이 줄이 계산되어야 한다고 생각한다.위키피디아의 서버가 효율적인 이유는 다음에 누군가 요청할 때 페이지를 캐시(복사본 보유)하기 때문이다.그가 마지막으로 찍은 날짜는 기사 하단의 오렌지색 테두리가 있는 흰색 상자 안에 있다.나머지 통계는 캐시할 수 있지만, 그 모든 것의 데이터베이스 부하가 너무 클 수 있다.Gracenotes § 17:55, 2007년^T 12월 13일 (UTC)[응답]

그것은 개념적으로는 훌륭한 아이디어처럼 들리지만, 기술적으로는 Gracenotes가 지적하는 바와 같이 비용이 많이 든다.나는 우리가 어쨌든 더 효과적일 수 있는 FlagedRevs를 구현하기 위한 노력을 사용하는 것에 찬성하기 위해 이것을 포기하는 것이 더 낫다고 생각한다.:) 니힐트레스^{t.l} 18:24, 2007년 12월 13일 (UTC)[응답]

적어도 기사 앞면에 {{기사 히스토리}}을(를) 붙이기 시작한다면 우리 캐주얼 독자들에게는 유익한 일이 될 수 있을 것이다.--파로스 (토크) 06:38, 2007년 12월 14일 (UTC)[응답]

기술 타당성 제안 단순화

모두들 피드백을 보내줘서 고마워.일반적으로 이것은 좋은 생각이라는 공감대가 있는 것 같다 - 적어도 지금 우리가 가지고 있는 "미운" 꼬리표보다 낫다.기사 등급 제안에 관한 한 너무 주관적이고 논쟁의 여지가 있는 기사의 신뢰성에 대해 단정적인 발언을 하기보다는 독자들이 상자에 제시된 '사실'을 해석할 수 있도록 해야 한다.지금까지 이것에 대한 가장 강력한 반대는 기술적 제한에 관한 것이었다.나는 기술적 한계가 단명하는 경향이 있다고 강하게 느낀다.오늘날 비현실적으로 보이는 것은 몇 년 안에 매우 간단해질 수 있다.그러나 여전히, 다음의 제안이 오늘날의 기술을 감안할 때 더 실용적이게 하는지는 생각해 보자.첫 번째 3가지 포인트가 있는 박스로 GA-FA 상태, 품질 태그, 첫 번째 & 마지막 편집 날짜.그러면 클릭할 경우 두 가지 더 처리 용량 집약적인 지점, 즉 지난 24시간 동안 고유 편집기 수와 편집 횟수를 검색할 수 있는 (추가 표시) 링크가 있다.어쩌면 우리가 몇 가지 더 생각해 볼 수도 있을 것이다.이제 좀 더 실용적으로 들리니?아르만 08:58, 2007년 12월 14일 (UTC)[응답]

기사신뢰성 문제에 대한 고객/브라우저측 해결책을 검토 중인 학술연구 프로젝트가 있다는 점은 언급할 가치가 있다.다음과 같은 외부 사이트를 확인하십시오.U of California Santa Cruz Wiki Lab's Wiki Trust Coloring, PARC의 Wikidashboard 및 The Chronicle of High Education의 기사.건배!Wassupwestcoast (대화) 2007년 12월 14일 (UTC) 17:34[응답]

그렇다, 원칙적으로는 현재 토크 페이지에 '숨겨져 있는' 정보의 상당부분이 위키-언소(우리 독자의 대다수가)가 접근할 수 있는 메인 스페이스에도 나타나야 한다고 생각한다.--파로스 (대화) 05:24, 2007년 12월 21일 (UTC)[응답]

일몰 및 일출 시간에 대한 제안

예를 들어 http://en.wikipedia.org/wiki/December_19,을 방문하면 그날의 기념일과 사망 소식은 더 많이 볼 수 있지만 그날의 일출과 일몰 시간은 아무것도 볼 수 없다.당신은 이 날짜들이 적어도 그리니치 표준시의 날짜들을 포함할 수 있다고 생각하는가?이것은 분명 몇몇 사람들의 흥미를 끌 것이다.석양에 관한 기사는 유용한 외부 링크를 가지고 있기 때문에 시간이 너무 힘들지 않아야 한다.ACEOREVIVEED (토크) 20:52, 2007년 12월 18일 (UTC)[응답]

몇 년도에 시간을 정해야 할까?바뀐다. --카르닐도 (토크) 21:12, 2007년 12월 18일 (UTC)[응답하라]

같은 날의 일출과 일몰 시간은 시간대에서 관찰자의 위치(동서)와 적도와의 거리, 국지 지형에 따라 달라진다.나는 우리가 사실상의 세계 일출과 일몰 시간으로 하나의 장소를 선정하는 것은 특별히 유용하지 않을 것이라고 생각한다.—Twigboy (대화) 22:43, 2007년 12월 18일 (UTC)[응답]

어떤 시간대에 있는지 자동으로 감지할 수 있는 컴퓨터 코드가 없는 거야?저스 (대화) 2007년 12월 19일 00:34 (UTC)[응답]

그것은 시간대가 문제가 아니다 - 그것은 동부 시간 75°W에서 같은 위도에 있다면 중앙 시간 90°W에서 동일할 것이다.문제는 당신이 67°W일 때 입니다; 그리고 위도 또한 중요하다.—Random832 15:03, 2007년 12월 20일 (UTC)[응답]

싱가포르나 에콰도르와 같은 어떤 곳에서는 일몰과 일출 시간이 거의 같은 해이다.오전 6시 30분, 오후 6시 30분쯤이다.Archtransit (대화) 2007년 12월 20일 19:32, (UTC)[응답]

검색 엔진에서 사용자 이름 제거

나는 이것을 VP(기술)에서 꺼내서 (그러나 이 특정한 스레드는 다른 사람이 시작한 것이다, moot point) 이 페이지를 참조했다.사용자 네임스페이스 페이지가 검색 엔진에 표시되는 이유가 무엇이며 이러한 검색에서 제거할 수 있는가?

그 이유는 A) 누군가 "Old Hoss"에 타이핑을 하면, 그들이 절대 원하지 않는 것은 나(구글에서는 #4이고 야후에서는 #2이다![2] 내 시험 페이지에 #5)와 B) 그들이 나를 원하면 (사용자로서) Special:목록 사용자.검색 엔진에서 "올드 호스"를 타이핑하는 보통 사람들은 분명히 나를 원하지 않는다. (그들은 아마도 내가 19세기 야구 팬임에도 불구하고 내가 이 이름을 선택할 때 생각하지 않았던 올드 호스 래드번을 원할 것이다.)

사용자 페이지와 사용자 대화 페이지(및 모든 부속 하위 페이지)를 검색 엔진에서 제외할 것을 제안한다.나는 그것이 로봇에 추가될 수 있다고 들었다.그게 무슨 뜻인지 전혀 모르겠는데생각?---올드 호스 (토크) 02:44, 2007년 12월 19일 (UTC)[응답]

이것도 여러 번 부탁한 바 있다.외부 검색 엔진에 의해 색인화되어야 하는 WP의 부분은 메인 스페이스일 뿐 메인 스페이스일 뿐이다.우리가 만들고 있는 것은 '백과사전'이며, 그 기구는 부차적이다. DGG (대화) 02:49, 2007년 12월 19일 (UTC)[응답]

미디어위키 검색은 상당히 쓸모없기 때문에 우리는 내부적인 것들을 검색하기 위해 구글을 사용하는 것을 좋아한다.검색 엔진 캐싱을 차단하는 것은 그것을 불가능하게 만들 것이다.프로데고 02:55, 2007년 12월 19일 (UTC)[응답]

더 좋은 해결책은 구글과 야후!가 위키 검색 시 사용자 네임스페이스 페이지를 자동으로 제외하는 것이다.하지만 우리는 그것을 우리의 목적에 맞게 고칠 수 없다.—2007년 12월 19일 02:57, 점 기억[응답⁽talk)]

프로데고에게: 그러나 특별하지는 않다:Mediawiki 검색과 별개의 목록 사용자?--Old Hoss (대화) 03:00, 2007년 12월 19일 (UTC)[응답]

그래, 하지만 그건 그냥 목록일 뿐이야.마이애미처럼 사용자 페이지를 검색하려면 구글 검색을 이용해야죠분명히 그것은 미디어위키 검색이 아마 그렇게 할 수 있을 것이다, 하지만 당신은 그 아이디어를 알 것이다.프로데고 03:05, 2007년 12월 19일 (UTC)[응답]

알았어. 그러니까, 확실히 하자면, 이 제안의 한 가지 결점은 현재 미디어위키 검색의 약점이다.따라서, 현재 어떤 것이 더 중요한가 하는 질문이 뒤따를 것이다.나는 결국 미디어위키 검색이 개선될 것이라고 상상한다(어디선가 읽은 것 같다), 그래서 어쩌면 이 제안은 그것과 함께 포장되어야 할지도 모른다.그래서 이제 물어봐야겠다, 만약 이것이 전거제안이 되었다면, 그때는 왜 실패했는가, 그리고 이것은 지금 다시 추구할 가치가 있는가?--올드 호스 (토크) 03:14, 2007년 12월 19일 (UTC)[응답]

특정 HTTP 헤더 또는 동등한 HTML 메타 태그를 사용하여 사용자 네임스페이스를 자동으로 제외할 수 있다는 점을 기억하십시오.나는 모든 사용자 및 사용자 대화 페이지에서 noindex 메타 태그를 사용하는 것을 강력히 지지할 것이다.— 칼 (CBM · talk) 03:16, 2007년 12월 19일 (UTC)[응답]

나는 적절한 내부 검색이 가능할 때까지 그것에 강력히 반대할 것이다.일단 그렇게 되면 확실히 외부 검색은 기사 공간에 국한될 수 있다.—Random832 14:37, 2007년 12월 19일 (UTC)[응답]

실제로 사용자 공간에서 텍스트 콘텐츠를 검색해야 하는 빈도는?우리는 이것이 필요한 드문 경우에 충분히 잘 작동하는 검색 엔진을 가지고 있다.— 칼 (CBM · talk) 2007년 12월 19일 (UTC) 14:51[응답]

충분히?난 거기에 동의하지 않아.2007년 12월^T 19일 (UTC) Gracenotes§ 18:02[응답]

나도 몰라나는 미디어위키와 구글에서 "검색 엔진에서 사용자 이름 삭제"를 검색했다.구글은 아직 인덱싱하지 않았지만 미디어위키는 히트를 돌려준다. (어느 쪽도 안 맞네. "글쎄요?나는 거기에 동의하지 않을 것이다."라고 기자 회견을 통해 말했다.– Quadell^{(talk) (random)} 18:21, 2007년 12월 19일 (UTC)[응답]

문자 검색을 위해 MediaWiki는 훌륭하다 – 그것은 루센의 가장 강한 옷이다.그러나 좀 더 의미 있는 검색을 위해서는 (백링크 &c) 구글이 더 낫다.미디어위키는 검색에 활용되지 않는 백링크가 내장되어 있는 것으로 알고 있다.Gracenotes^T § 2007년 12월 19일 (UTC)[응답]

User: 및 User_talk 페이지의 색인화를 차단하는 것은 기술적 관점에서 분명히 가능하다.그러나, 그렇게 하는 것은 이 프로젝트(즉, 영어 위키백과)에 큰 변화가 될 것이다.이 제안이 진지하게 고려되고 논의되기 위해서는 RfC 또는 별도의 위키백과(이 제안의 이점/유해점에 대해 토론한 페이지)를 시작하고 지역사회의 토론과 합의를 얻을 것을 제안한다.건배. --MZMcBride (대화) 20:20, 2007년 12월 19일 (UTC)[응답]

나는 종종 외부 검색을 사용하여 사용자 및 프로젝트 네임스페이스에서 토론, 템플릿 및 기타 사항을 찾아보았다.아이디어는, 단기적으로 노인덱스를 어떤 종류의 옵트인 옵션으로 둘 수 있을까?자신의 페이지가 색인화되는 것을 염려하는 사용자들은 특정 페이지에 태그를 붙일 수 있다. -- 네드 스콧은 2007년 12월 19일 (UTC)[응답]

노인덱스와 노 팔로우 플래그가 있는 것을 예전에 생각해 본 적이 있는데, 그러한 기능은 예절 블랭킹을 대체하는데 유용할 것이다.하지만, 그것은 가치 있는 것 보다 더 많은 드라마를 유발할 수 있다. 단지 그것이 예의상 공백에 유용하다는 사실 때문이다.우리는 논란의 여지가 있는 페이지들에 휠 전쟁을 태그하는 것은 말할 것도 없고 그것에 대한 편집 전쟁을 충분히 가지고 있다:) Gracenotes^T § 20:33, 2007년 12월 19일 (UTC)[응답]

WMF는 구글에 사용자공간의 호출기를 내려달라고만 하는 것이 비합리적인 처지는 아니라고 생각한다.그들은 분명히 그렇게 할 능력이 있다.상위 결과로 나타나는 사용자 페이지는 그 누구에게도 도움이 되지 않는다.그러면 구글봇을 제외한 모든 사람에게 사용자 페이지를 인덱싱하지 말고 구글 전용으로 사용하라고 말할 수 있을 것이다.음, 이게 나쁜 생각의 시작이지?- RockMFR 06:02, 2007년 12월 21일 (UTC)[응답하라]

아마도 구글에 대한 제안은 그들의 검색 알고리즘이 일반적인 웹 검색을 위해 메인 스페이스만 검색하도록 하는 것일 것이다.그러나 "site:" 명령이 웹사이트 내에서만 검색하는 데 사용되는 경우(예: 위키피디아) 네임스페이스에 관계 없이 모든 결과를 반환한다. --Breno 11:40, 2008년 1월 11일(UTC)[응답]

포럼

너희들은 확실히 포럼을 가져야 한다...그것은 또한 공공 기물 파손을 억제할 것이다. 왜냐하면 사람들이 기물을 파손하는 주된 이유는 그들이 지루하기 때문이다.네가 원한다면 내가 너를 위한 포럼을 만들어 줄게.먼저 무료 포럼을 만들어 어떻게 돌아가는지 보기 위해서>>>>>>>> www.setbb.com을 추천한다.

이것을 참작해 주십시요>>><<<>><<<KC (토크) 17:32, 2007년 12월 19일 (UTC)[응답]

나는 채팅 포럼을 만드는 것이 공공 기물 파손을 줄일 수 있을지 의심스럽다.사실, 나는 반대의 효과를 볼 수 있다고 본다.온라인상의 모든 종류의 채팅 사이트와 포럼이 이용가능하다는 점을 고려할 때, 나는 우리가 그들의 지루함을 되돌릴 것이라고 생각하지 않는다; 만약 그들의 욕구가 파괴하기 보다는 채팅을 원한다면, 그들은 어디로 가야 할지 확실히 알고 있다.우리가 하고 있는 것은 위키피디아가 백과사전의 구축과 무관한 활동을 위해 사용자들을 사이트로 끌어들이도록 하는 것이고, 따라서, 이러한 오프 토픽 활동을 암묵적으로 승인하는 것인데, 이것은 모든 영역으로 이어질 수 있다.백과사전을 블로그/마이 스페이스/소셜 네트워킹으로부터 완전히 분리하는 것은 우리의 건강과 평판에 중요하다.위키피디아는 채팅 포럼이나 놀이장이 아니다.나는 그렇게 하는 것이 가끔 밤에 벽에 페인트를 뿌리는 아이들을 어떻게든 산만하게 하고 단념시키기를 바라는 마음에서 술 취한 기관의 앞 로비에 아케이드를 설치하는 것이나 마찬가지일 것이라고 생각한다.—Fuhgetaboutit (대화) 20:23, 2007년 12월 19일 (UTC)[응답]

푸시테타가 말했듯이, 인터넷은 함께 모여서 대화할 장소의 측면에서 부족함이 거의 없다.인터넷이 한정된 공급을 가지고 있는 것은 신뢰할 수 있고 편집이 자유로운 백과사전이다.위키피디아는 그대로 두고 채팅 사이트는 채팅 사이트로 하자. --Jayron32 talk는 02:21, 2007년 12월 21일 (UTC)[응답]

페이지당 IP 범위 차단

나는 이것을 다른 사람들이 그것이 좋은 생각이라고 생각하는지 보기 위해 여기에 나열하는 것이다. 왜냐하면 실행하려면 기술적 그리고 정책적 변화가 필요하기 때문이다.일반적으로 말해서, 나는 가장 끈질긴 IP 반달들은 그들의 반달리즘에 좁은 초점을 두고 인터넷에 접속할 때마다 다른 IP를 제공하는 ISP를 사용하는 경향이 있다는 것을 알아챘다.그러한 ISP는 또한 비반달적인 익명 사용자를 갖는 경향이 있기 때문에, 단순히 IP의 전체 범위를 차단하는 것은 실용적이지도 바람직하지도 않지만, 특정 페이지에서 그러한 범위를 차단할 수 있다면, 최소한 단순한 반보호보다 더 구체적인 블록을 허용하고, 보다 구체적이기 때문에, 아마도 그것을 그대로 두는 것이 가능할 것이다.더 긴 시간 동안 배치한다.Caerwine Caer's singing 21:59, 2007년 12월 20일 (UTC)[응답하라]

이것은 재미있는 생각이다.그것을 실행하는데 무엇이 필요할지는 모르겠지만, 나는 그것이 깔끔한 생각이라고 생각한다. --Jayron32 talk는 02:17, 2007년 12월 21일 (UTC)[응답]

간단한 영어 위키백과

이것은 분명히 다뤄질 필요가 있는 것이다.영어 위키피디아는 가장 헌신적인 위키피디아인들만이 그 존재를 알고 있는 다른 언어들과 함께 알파벳 순으로 숨겨져 있는 단순한 영어 위키피디아를 더 인식할 필요가 있다.미국 혁명에 관한 보고서를 써야 하는 어린 초등학생을 상상해 보라.그는 구글이나 야후!에 가서 '아메리칸 레볼루션'을 친다.물론 첫 번째 결과는 위키백과다.그는 그것을 클릭하지만 복잡한 영어를 읽을 수 없다.(이미 간단한 영어 위키백과가 있으니) 그가 실제로 읽을 수 있다면 좋지 않을까.나는 이것과 비슷한 Simple English를 가진 모든 영어 위키백과 기사에 간단한 템플리트를 추가한다고 생각한다.

무료 백과사전인 마을 펌프(제안)/아카이브 10판 위키백과

See also 또는 External links에 있는 기사의 끝부분에서 대부분의 경우 문제를 해결해야 한다.

왜 이게 좋은 거지?

• 간단한 영어 위키백과의 성장을 돕다
• 배우려는 젊은이들을 돕다
• 어린 아이가 연결고리를 찾을 수 없다면 간단한 영어 위키백과를 갖는 것은 의미가 없다.

바라건대 이것은 어떻게든 시행되기를 바란다.-- Penubag 05:49, 2007년 11월 25일(UTC)

SEEIKipedia(및 다른 모든 언어 위키백과)는 별도의 프로젝트다."우리" (잉글 위키백과 사용자에서와 같이)는 그들의 콘텐츠나 광고에 대한 책임이 없다.그 한 가지 특정 프로젝트가 왜 더 주목을 받아야 하는지 모르겠다. - 코웨자 (대화) 06:38, 2007년 11월 25일 (UTC)[응답]

위의 설명을 읽어보십시오. 왜 SE 위키백과 링크가 영어 기사에 매우 유용한가?간단한 영어는 분리된 프로젝트임에도 불구하고 영어의 일부분이다.나는 최근에 SE 위키피디아에 대해 알게 되었는데(약 1년 반 전) 좀 더 빨리 알았더라면 충분히 사용할 수 있었을지도 모른다.또한 구글 프랑스어는 위키백과 영어 기사를 싣지 않을 것이다. 그래서 우리는 영어 기사를 위해 프랑스어 위키백과 페이지에 추가 고지가 필요하지 않다.물론, 어쩌면 우리가 그들을 책임지지는 않을 수도 있지만, 그것이 아이들과 영어를 배우는 사람들 모두에게 얼마나 많은 도움을 줄 수 있을지 생각해 보십시오.나는 단지 그들이 별개의 프로젝트라고 해서 우리가 모두를 도울 수 있는 것을 도와서는 안 된다는 뜻은 아니라고 생각한다.-- Penubag 07:03, 2007년 11월 25일 (UTC)[응답]

Penubag의 의견에 동의하십시오.코웨자, 우리 사용자들의 도움의 한계를 영어 위키피디아에만 두어서는 안 된다.사실, 다른 사용자들이 그 언어를 이해한다면 당신은 다른 위키피디아에 가입하도록 장려해야 한다.우리는 모두 위키미디어 재단 산하에 있고, 비록 우리가 모두 다른 웹사이트라고 할지라도, 우리는 여전히 무료 신뢰할 수 있는 정보 백과사전이라는 공통의 목표를 위해 봉사한다. 피드백 07:20, 2007년 11월 25일 (UTC)[응답]

그게 그의 요점이다.우리 모두 재단 산하에 있는데 왜 영어 위키피디아가 다른 특정한 프로젝트에 특별 대우를 해야 하는가? - 아마르코브무!2007년 11월 25일 07:32(UTC)[응답하라]

음, 그건 별개의 프로젝트지만 위키와 연결돼 있어.-- Penubag 09:16, 2007년 11월 25일 (UTC)[응답]

왜냐하면 심플한 영어는 영어에서 파생된 것이기 때문이다.그래서, 우리는 그들에게 부모 위키와 같다.따라서, 그것은 특별 대우를 받아야 한다.피드백 07:34, 2007년 11월 25일 (UTC)[응답]

응, 게다가, 그것은 학습자들에게 큰 도움이 될 수 있어.SE는 같은 언어로 된 기사를 찾는 사람들에게 도움을 주기 때문에 특별 대우를 받아야 한다.그것이 위키피디아의 주요 목표가 아닌 것인가?우리는 영어에 매우 유창하고 지식이 풍부한 사람들뿐만 아니라 젊은 세대에게도 초점을 넓혀야 한다. 그들은 학교를 거치는 사람들이고 그들이 이해할 수 있는 정보가 가장 필요한 사람들이기 때문이다."지식은 젊음의 집적, 그것이 먼저 문을 열어야 할 곳"-- 페누바그 07:38, 2007년 11월 25일 (UTC)[응답]

확신이 안 서네.우선, 나는 영어 위키피디아가 9살 어린이들에게 그렇게 이해하기 어렵다고 생각하지 않는다.그 글들은 보통 꽤 선명하게 쓰여진다.이 질문은 거의 대답하기 불가능하지만, 어쨌든 물어봐야겠다-영문 기사에 오는 사람들 중 얼마나 많은 사람들이 읽기가 너무 어렵다고 생각하는가?물론, 어린 초등학생들은 위키피디아를 사용한다.대학생들도 마찬가지다.어른들도 마찬가지야.또 다른 대답할 수 없는 질문-우리 독자들 중 얼마나 많은 사람들이 이 링크를 귀찮게 여길지/불신할 것인지/쓸데없이/쓸데없이 떠들어댈 것인지에 반하여 얼마나 많은 사람들이 이 링크를 통해 혜택을 볼 것인가?
마지막으로, 간단한 영어판과의 링크는 그다지 유용하지 않을 수도 있고, POV가 짧으며, ...와 같은 놀라운 산문을 가지고 있다.식민지들은 이 법에 협력하는 것을 완전히 거부했다.Puchiko (Talk-email) 2007년 11월 25일 (UTC) 12:00[응답]

믿어봐, 만약 당신이 9살이고 스트링 이론에 관한 기사를 읽으려고 한다면, 그것은 이해하기 매우 어려워.그리고 우리가 영어 페이지에 템플릿을 추가하면 SE 위키피디아가 성장하지 않을 것이라고 누가 말해야 할 것인가.한번 더 주목받으면 여느 위키백과 못지 않게 잘 나올 수 있다고 믿는다.SE가 "조금 짧은 POV, 놀라운 산문을 가지고 있다"는 이유는 기사 편집은커녕 그 존재를 아는 사람이 거의 없기 때문이다.-- Penubag 21:13, 2007년 11월 25일 (UTC)[응답]

9살짜리 아이가 SE 위키피디아에서 끈 이론을 이해하게 될 거라고 확신해?:) 아마도, 여기서 끈 이론을 읽는 당신의 말이 맞을지도 모르지만, 그 아이는 어려운 영어를 이해하는 것(어린이 기준당)과 끈 이론 자체의 개념을 해독하는 것, 즉 두 가지 어려움을 가지고 있다.적어도 첫 번째 과제는 SE 위키백과에서 희석될 것이다.하지만 아이들이 더 잘 이해할 수 있도록 SE에서 그 이론 자체의 위협적인 용어를 어떻게 변환시킬지 궁금했다. - 디사찬 (토크) 21:34, 2007년 11월 25일 (UTC)[응답하라]

• Penubag의 제안에 대한 지지.영어는 모국어보다 더 많고, 국제적인 의사소통 수단이기 때문에 다른 언어와 비교했을 때 다른 치료가 필요하다.나는 영어를 외국어로 사용하며, 나는 Simple English Wikipedia가 비 모국어 영어 사용자들에게 중요한 정보원이 될 수 있는 유용한 프로젝트라고 생각한다.현재에 와서 보면 글들이 뭉툭하거나 누락되거나 잘 쓰이지 않지만, 앞으로 바뀔 수 있다.나는 그것이 다른 어떤 위키백과보다 더 풍부하고 질이 높아져야 한다고 생각한다.한편으로 영어위키의 기사들은 간결한 형태로(언어적으로 단순화되나 내용은 그렇지 않다!), 한편으로 영어를 국제적인 도구로 사용하는 비 모국어 영어 사용자들은 그 안에 기사를 써야 한다.(아마 나의 간단한 인턴쉽의 차이점을 이해할 수 있을 것이다.알 영어와 루나 산틴의 진짜 영어 여기 모국어: [3] 다시 우리의 주제로 돌아가자:Simple English Wikipedia에 고품질의 기사가 있다면, Penubag가 시사하는 바와 같이 본 통신원의 영어 위키백과 기사에서 연계가 될 수 있다고 생각한다. --Hunadam (talk) 20:45, 2007년 11월 25일 (UTC)[응답]
• 응, 우리는 영어 위키백과 기사를 복사해서 간단한 영어 위키백과로 만드는 팀을 만들 수 있고, 어려운 단어들을 모두가 이해할 수 있는 단어로 바꿀 수 있어.-- Penubag 21:07, 2007년 11월 25일 (UTC)[응답]

• 미안하지만, 아니야.영어와 심플한 영어 사이에 밀접한 관계가 있다고 해서 우리가 그들의 기사를 밀고 나가야 한다는 뜻은 아니다.밀접한 관련이 있는 몇 가지 다른 언어 쌍이 있다(예를 들어, 선호에서 선택할 수 있는 9가지 중국어 변종이 있다).기껏해야 [[단순:] 인터위키스를 목록의 맨 위에 밀어넣는 것을 지지하지만(히브리어 위키백과에서 인터위키스를 맨 위에 놓는 것과 유사함), 그것 외에는 프로젝트에 해가 될 것이라고 생각한다.EVula // talk // talk // 21:38, 2007년 11월 25일 (UTC)[응답]

아니, 단순히 영어/SE와 밀접한 관계가 있기 때문이 아니라, 젊은 독자들의 이익을 위해서야.아무도 모르는 SE 위키피디아를 가지고 있는 목적을 나는 보지 못한다.나는 봇이 우리의 영어 기사에 SE 템플릿을 추가하게 하는 것이 뭐가 그렇게 나쁜지 모르겠다.누구나 그 덕을 볼 수 있다, 그 덕택에 크게 다칠 수 있는 사람이 없어, 젊은이나 영어 학습자를 돕고 싶지 않다.-- Penubag 22:45, 2007년 11월 25일 (UTC)[응답]

• 지원 비 원어민 영어 사용자 수는 원어민 영어 사용자 수의 두 세 배다.심플한 영어 위키피디아에 링크를 추가하면 원어민이 아닌 사람들과 어린 아이들에게 도움이 될 것이다.또한, 더 많은 사람들이 심플한 영어 위키피디아에 기사를 쓸 것이다.'단순 중국어 위키백과'가 있는 것처럼 '단순 중국어 위키백과'도 연계해야 한다고 생각한다(단순 중국어 위키백과는 없다).--Kaypoh (대화) 09:45, 2007년 11월 26일 (UTC)[응답]
• 지지하다.불행히도, 간단한 중국어 위키백과는 없다.요청할 수도 있을 것 같아. 2007년 11월 27일 (UTC)Bibliomaniac15 00:25 (UTC)[응답하라]

그렇다면 SE 템플릿을 영어 기사에 배치할 봇을 만드는 데 충분한 지원인가?-- Penubag 03:41, 2007년 11월 29일 (UTC)[응답]

나는 그렇지 않기를 바란다; 나는 개인적으로 이것에 반대할 뿐만 아니라, 나는 그것이 진짜 기사에서 어떻게 보일지 심각한 우려를 가지고 있다."SE" 링크를 infobox와 다른 정보 위에 놓으면 페이지가 쓰레기처럼 보일 것이다.우리는 우리 자신의 물건을 뒤죽박죽으로 만들 필요가 없다.EVULA// talk // talk // 15:50, 2007년 11월 29일 (UTC)[응답]

당신은 이해하지 못한다.템플릿은 페이지의 아래쪽에 외부 링크 근처/Wiktionary 링크 바로 위에 있는 참고 항목으로 배치된다.링크가 필요한 사람만 볼 수 있다.-- Penubag 16:41, 2007년 11월 29일 (UTC)[응답]

나 역시 이것에 다소 반대한다.현재 우리는 Wiktionary 및 Commons 링크 템플릿과 같은 템플릿을 사용하여 다른 형식의 유사한 정보가 아닌 더 많은 정보를 얻을 수 있는 곳으로 사람들을 안내한다.그리고 나는 21,000개의 기사에 대한 템플릿을 붙이기 위해서는 이것보다 더 넓은 합의가 필요하다고 생각한다.미스터 지맨 2007년 11월 29일 (UTC) 18:16 (응답)

내 의견의 폭이 얼마나 넓어질 수 있을까?경우, 그것은 결국(그리고 아마도, 소리가 너무 아이들과 영어를 배우는 학습자들 을 포함했다 고등 학교( 새로운 개념이 소개됩니다)에서 모든 사람을 도울 것이다, 단지 너가 이:을 읽을 수 있는 것을 전부 advantages/dis의 금액을 원한다.그것은 쉬운 영어 위키 피디아의 품질과 수량을 향상시키고 도움이 될 것이다.그것은 속에서 다른 언어 바를 빠져나가고, somewh에 SE을 받을 것이다.유창한 영어 스피커의 게으른 사람들에게 Ere 어린이들이 이용하는 대신에 알파벳 리스트 을을 뒤지고의 링크를 찾을 수 있고, 가장 중요한 사실은 짧은 요약(나처럼)는 그냥(비록 영어에 언급된 어느 쪽 싸움 연합국들을 위해, 이 중요한 전투에 있는으로 알아보기 위해 제2차 세계 대전에 대한 전체의 기사를 읽을 수 없다.강한 불SE에서 훨씬 더 일찍 시행되어 독자들이 게을러질 때 도움이 된다) 동의> 약간의 클러스터 문제 외에는 해결 가능한 것이 전혀 없다(아래 편집 참조).-- Penubag 03:31, 2007년 11월 30일 (UTC)[응답]

아, 오해하고 있었는데, 그래도 어수선할 것 같아.우리는 현재 이 공간을 기사와 관련된 다른 WMF 프로젝트로 사용자를 안내하는데 사용한다. 처음 두 임계값 내에 왼쪽에 링크가 있는데, 왜 누군가가 페이지 하단으로 스크롤을 내려갈까?{{commons}, {{wikispeech}}, 기타 템플릿으로 충분히 어수선해진다; 위키피디아와 위키피디아의 구별을 그리는 것은 별개의 프로젝트인 만큼 좋지만, 일단 언어판을 추가하기 시작하면 상당히 덜 명확해진다.EVULA// talk // talk // 18:45, 2007년 11월 29일 (UTC)[응답]

옆면이 아닌 페이지 하단에 템플릿을 넣어야 하는 이유는 SE가 저쪽 편이라는 것을 아무도 모르기 때문이다(그것은 고사하고 다른 언어도 아니다).경험이 풍부한 위키백과 사용자만이 그 존재를 알 수 있을 것이다(그 때쯤에는 SE가 그들에게 필요하지 않다). 그래서 그것은 당신에게 단지 두 가지 한계점일 뿐이다.간단한 영어는 특히 새로운 개념을 배우는 고등학생들과 다른 젊은이들 또는 외국인들에게 매우 유익할 수 있다.참고 항목과 외부 링크가 너무 복잡해질 수 있다는 우려에 대응.: 보통 템플리트를 추가하면 SE 링크가 있는 젊은 독자들을 도울 수 없을 정도로 체계적이지 못한 곳이 그리 어수선하지 않다.하지만, 나는 네가 걱정하는 것을 안다.템플릿 크기를 작게 추가하면 다음과 같은 문제가 발생할 수 있다.

간단한 영어 위키백과의 기사 참조

이 템플릿으로 어린 독자들은 거의 모든 위키백과 기사를 찾아보고, 그들이 원하는 것을 입력하고, 페이지 하단으로 스크롤하여 링크를 클릭할 수 있다.처음에는 바보같이 들리지만, 정말 열심히 생각하면 많은 아이들이 그렇게 할 것 같아.-- 페누백 02:56, 2007년 11월 30일 (UTC)[응답]

나는 여전히 이것에 반대한다; 나는 이것이 막연한 "아이들을 생각하라" 타입의 가설들 외에 도움이 된다는 어떤 증거도 아직 보지 못했다.나는 Simple English 프로젝트의 전반적인 목적에 동의하지만, 정보를 더 쉽게 접근할 수 있도록 하는 더 큰 이익에 관해서만 동의한다.리디렉션되는 것을 별로 좋아하지 않을지도 모르는 사람들을 리디렉션하기 위한 화려한 템플릿을 만드는 것은 좋은 아이디어로 떠오르지 않는다; 그것에 대해 생각할수록, 나는 단순한 인터위키를 목록의 맨 위로 이동시킴으로써 이것이 가장 잘 제공될 것이라고 생각한다.
제안: 사용자 공간에 있는 소수의 기존 위키백과 기사의 임시 버전을 만들어 템플릿이 어떻게 작동하는지 설명하십시오.일하는 예를 보는 것은 상상하는 것보다 생각을 더 많이 바꿀 수 있다(예를 들어, 내가 생각하는 것보다 더 잘 될 수도 있고, 네가 생각하는 것보다 더 나쁘게 될 수도 있다).EVULA// talk // talk // 04:09, 2007년 12월 6일 (UTC)[응답]

아흐 미안, 이 게시물을 놓쳤어... 네 게시물에 대한 응답으로, 단순함을 더 잘 알리기 위해 노력한 모든 것이 더 낫다고 생각해. (예를 들어 인터위키스 꼭대기로 옮기고 대담하게 만드는 것 등.) 하지만 템플릿의 훌륭한 대용품이긴 하지만, 템플릿은 여전히 더 두드러지기 때문에, 나는 템플릿이 더 낫다고 믿어.나는 내 페이지에서 몇 가지 예를 작업하고 있을 것이다. 그리고 그것이 끝나면 그것들을 발표할 것이다.-- penubag 05:59, 2007년 12월 22일 (UTC)
나는 내가 그것을 인터위키스의 꼭대기로 옮기는 것을 지지할 수 있다고 생각한다 - 우리는 특히 이 변화에 대한 합의를 얻을 수 있을까? 왜냐하면 개발자들은 명확한 합의 없이는 그것을 하지 않을 것이기 때문이다.—Random832 14:32, 2007년 11월 30일 (UTC)[응답]

특히 이 변화를 위해서?위에 있는 작은 템플릿 말씀이세요?위에서 여러 번 언급했듯이, 그 작은 템플릿은 Simple English Wikipedia를 옆쪽에서 다른 언어 모음에서 꺼내게 할 것이다. 물론, 그것은 아무도 필요로 하지 않을 것이다. 그리고 그것은 SE의 성장을 촉진하고 도울 수 있다.그것이 devs를 납득시키기를 바라며;)-- Penubag 08:58, 2007년 12월 2일 (UTC)[응답]

[[단순:] 링크를 목록 맨 위로 이동하려면 목록 맨 위로 이동하면 된다. 인터위키스는 기사에 제공된 순서대로 표시된다.개발 참여가 필요하지는 않지만, 모든 변경을 위해 봇이 필요할 것이다.EVULA// talk // talk // 04:09, 2007년 12월 6일 (UTC)[응답]

좋아, 인터위키스의 상단으로 옮겨서 대담하게 만들 수도 있지만, 그래도 충분히 눈에 띄지는 않을 것 같은데, 위의 작은 템플릿에 대한 당신의 (모든 프로젝트에 당신이 관리인이니까) 확인을 받을 수 있을까? -- Penubag 04:21, 2007년 12월 6일 (UTC)[응답]

제안서 지원, 그러나 SE 페이지에 단순화 지침의 가시적인 링크가 있는 경우에만.많은 사람들이 사물을 단순화하는 것은 생각보다 어려운 일이기 때문에 가이드가 없으면 우리는 지나친 설명과 단순화에서 이해의 목적을 해치는 혼란의 지점으로 지나치게 길어질 수 있다.나는 SE 페이지가 특별 대우를 받는 것을 보고 싶다. 여기서 비친화적인 단어 목록은 편집자들이 기여하는 내부 데이터베이스와 상호 참조된다.그래서 SE에 글을 쓰는 사람이 있으면 불친절한 단어가 낮은 음색(Vey light gray?)으로 부각되고, 사용자는 비우호적인 단어 옆에 어떤 대안이 있을 수 있는가에 대한 내부 데이터베이스를 다시 확인할 수 있다. -boozerker 01:12, 01 2007년 12월 01 (UTC)[응답]

그건 완전히 새로운 제안이야. 하지만 네 말에 동의해. 2007년 12월 2일 페누바그 08:58, (UTC)[응답하라]

그래서? 이제 봇에 대한 지원이 제대로 된 걸까?다음 단계는? -- 페누백 07:55, 2007년 12월 4일 (UTC)[응답]

간단한 영어 위키백과 이동을 지원하면 인터위키스 상단으로 연결되고 심지어 다른 링크보다 더 두드러지게 된다.아르만 03:26, 2007년 12월 6일 (UTC)[응답]

지원 우리는 간단한 위키피디아를 더 쉽게 찾고 개발하는데 도움을 줄 필요가 있다.브리태니커 백과사전은 난이도와 정교함의 수준이 다른 6단계의 기사를 가지고 있다.간단한 위키백과로 우리는 많은 기사에 대해 2단계를 가질 수 있다.간단한 위키피디아와 함께 진화에 대한 소개와 같은 소개 기사로 우리는 3가지 기사로 몇 가지 기사를 볼 수 있다.EB가 6단계를 가질 수 있다면 2, 3단계를 가질 수 없을까?--필(토크) 05:31, 2007년 12월 6일 (UTC)[응답]

윽. 반대하다.이것은 형편없는 생각이고, 만약 누군가가 그것을 봇으로 실행하기 위해 지치면 더 나쁜 생각이다.나는 내가 따라잡는 모든 기사의 영어판과 간단한 영어판 모두를 볼 수 없다. 그리고 만약 당신이 그 간단한 기사를 en 기사와 두드러지게 연결하려고 노력한다면, 그것은 독자들에게 그저 선을 긋는다.독자들을 생각하면 안 될까?Simple에서 POV 포크로 끝나는 그들 대다수는 "Wikipeida에서 그것을 읽는다"고 생각할 것이다.이것을 장려할 필요는 없다.단순은 다른 언어의 위키백과와 같은 대우를 받을 수 있고, 자신의 장점이나 그 부족함을 지지할 수 있다.➪HiDrNick! 07:23, 2007년 12월 6일 (UTC)[응답]

우리가 독자들에게 링크를 제공한다고 해서 둘 다 시청자가 되어야 하는 것은 아니다.링크만 있으면 심플이 채워지고 그들은 그들만의 시계탑을 쌓을 것이다.그리고, "독자를 생각해봐"라고 말하겠지. 바로 그거야.우리는 너처럼 영어를 유창하게 이해할 만큼 운이 좋지 않은 사람들을 생각하고 있어.게다가, 페이지 하단의 작은 쪽지가 얼마나 아플까?-- penubag 05:30, 2007년 12월 19일 (UTC)[응답]

아닌 것 같아.우리는 이미 다른 프로젝트와의 연관성 면에서 충분히 복잡하다.지니 03:51, 2007년 12월 9일 (UTC)[응답]

음, 지니의 몇 가지 좋은 점들, 그리고 일반 위키백과의 기사 분할, 페이지 리디렉션 등이 단순 상대편에서 미러링되지 않는 것은 지저분해질 수 있다.두 버전이 서로 긴밀하게 연결되어 있다면 그것은 큰 문제다.동시에 Simple의 독자층이 늘어난다는 것은 그들 자신의 파수꾼들의 건강한 인구를 가지고 있다는 것을 의미하므로 그곳에서는 크게 걱정할 필요가 없다. --Boozerker (토크) 07:47, 2007년 12월 9일 (UTC)[응답]

위와 같은 작은 템플릿?전혀 아프지 않을 것이고, 파수꾼들에 대한 당신의 의견에 동의한다.-- penubag 05:30, 2007년 12월 19일 (UTC)[응답]

반대 내 말을 오해하지 마, 난 간단한 영어 위키피디아를 좋아해. 그리고 나는 때때로 그것을 9살짜리 아이에게 재료의 메카니즘을 설명하는데 사용했어.lol. 하지만 간단한 영어는 다른 형태의 영어일 뿐이다.중국어 위키백과는 중국어 간체, 중국어 번체, 대만 중국어 번체, 중화인민공화국 간체, 중국어 간체, 홍콩/마카우 중국어, 말레이시아 중국어 등 총 6종류의 중국어가 있다.이들은 모두 제대로 연결되면 별개의 언어처럼 보인다(단, 'History' 탭 옆에 풀다운 메뉴가 있어 어떤 6가지 중국어 버전을 사용할지 다시 선택할 수 있다).그럼에도 불구하고, 그들은 다른 형태의 중국어 아래 같은 글에 있는 동안에도 6개의 중국어 양식(최대)을 모두 다른 언어로 나열하고 있기 때문에, 나는 어떻게 Simple English와 일반 위키피디아가 이미 가지고 있는 것보다 더 많은 구분을 필요로 하는지 모르겠다. - Jameson L. 타이 07:37, 2007년 12월 12일 (UTC)[응답]

그래, 너는 심플한 영어의 존재를 알기 때문에 사용하는 반면, 다른 많은 사람들은 그렇지 않다.내 말은 링크를 좀 더 돋보이게 만들자는 거야. 페이지 하단에 작은 템플릿을 추가해야 할지도 모르니까어떤 아이도 옆에 있는 다른 언어 바에서 Simple English 링크를 찾을 수 없을 것이다.-- penubag 05:30, 2007년 12월 19일 (UTC)[응답]

보다 일반화된 솔루션으로 확장

지지하되 "그들은 우리가 아닌데 왜 우리가 그들을 위해 광고해야 하는가"라는 고도의 편협(그리고 조금 이상 유치한) 태도를 중단할 때라고 생각한다.인정하건대, 다른 초기 프로젝트들은 정말 힘든 부분이 있었다...하지만 그 다음엔 우리 기사도 마찬가지지.이제 그 "합의 결정"을 다시 생각해 볼 때야 만약 그들이 정상적인 경우가 아니었다면...정말 관여된 사람들이 따라잡을 시간이 적은 사람들을 괴롭히는 무리들. (개인적으로, "쿼럼 플로어"가 있기 전까지는, 그리고 우리가 "쿼럼 플로어"가 없는 한, 나는 우리가 합의의 주장을 반영하는 메커니즘을 가지고 있다고 생각하지 않는다.이제 성숙하고 안정된 프로젝트로서, 그것도 좋은 다음 단계일 수 있지만, 난 그걸 알아!미안해.)

인터위키의 기사는 많은 외국인들에게 알려져 있고, 아마도 국내의 새로운 편집자들에게는 거의 알려지지 않았을 것이다.더 나쁜 것은, 그들은 우리의 자매 사이트와 연결되지 않고, 많은 사이트들이 똑같이 상속되지 않고 있지만, 우리의 독자들에게 흥미로울 것이다.위 내용을 보기 전까진 '단순 영어 위키백과'에 대해 몰랐고, 대부분의 자매에 대해 설명했어!우리의 기사 위에 '배너'라는 한 페이지 넓이가 있다면 어떤 해로움이 있을 것이다.그것은 우리가 {{ambox}}}에 깔고 있는 자신감보다 훨씬 덜 논란이 될 것이다. 그것은 모든 청소 템플릿에 관한 것이다.더 좋은 것은, 적어도 디팩토(defacto)로 한 자매(위키온서리의 {{wiktionary}) 템플릿이 페이지 상단에서 견딜 수 있고, 다른 자매들은 다른 링크들과 함께 "외부 링크"로 강등되어 사실상 모욕당한 현재 상태와 더 일치할 것이다.나는 개인적으로 이 문제가 어떤 자매들이 여기서 비롯되는 어떤 아이디어에 대해 거의 적대적인 태도를 보이는 큰 요인이라고 확신한다...사람들은 그들의 노고가 해고되는 것을 싫어하고, 재단이 그들에게 자금을 지원하고 있다면, 나는 그들이 여기서 좀 유명해지고 인정을 받을 자격이 있다고 말한다.

이러한 배너 템플릿이 동일한 주제, 위키북, 위키리듬, 위키다양성, 커먼즈(때로는 아틀라스에 주어진 두 개의 항목이 필요할 수 있음), 위키포트와 기타 콘텐츠 사이트(적용, 메타 및 미디어위키는 거의 연결되지 않지만, 그것들은 하나의 콘텐츠 사이트가 아니라 행정 또는 소스 저장소)에 연결되도록 한다.무슨 일이 있어도...그리고 우리 자매들을 그저 또 하나의 외부 연결고리인 것처럼 폄하하는 것을 그만두게 할 것이다.그들은 아니에요.

다른 항해 상자처럼 얇고 눈에 띄지 않을 수 있으며, 공동체가 원할 경우 보일러를 생성하도록 명명된 매개변수로 프로그래밍할 수 있다.다른 대부분의 내비게이션 박스와는 달리, 나는 이것이 헤더 배치여야 한다고 생각한다.나는 상당히 눈에 띄지 않지만, 여기 한 페이지에서 볼 수 있는 {{commons}}의 절제된 크기와 높이를 따라 표준화 된 것을 제안하고 있다.우리가 '어글리 화이트 스페이스'로 만드는 모든 낭비 공간을 고려하면(긴 목차만 가득 채운 화면은 얼마나 프로페셔널해 보이는가!)?, 자매 간 연결에 작은 배너 테두리를 부여하는 것은 사소한 페이지 형식 지정 문제다.사실, 구현은 꽤 사소한 것일 수 있는데, 적용된 템플릿에서 몇 가지 파서 기능 테스트는 테이블 형식인 {{commons}에 모델링된 일부 하위 템플리트를 호출하면 테이블이 가로로 배열된다.순서는 알파벳순으로 표준화 될 것이고, 링크는 디스플레이 아이콘, sans 텍스트...공간 과밀을 방지하고, 동일한 재료를 포함하는 약간 다른 단어 제목에 대한 연결을 가능하게 한다.어떤 템플릿에 정통한 편집자는 몇 시간 안에 그와 같은 것을 조립할 수 있을 것이다.템플릿에는 포맷하는 방법을 알려주는 명령이 필요할 수 있다.아이콘으로 된 3개 또는 4개의 링크는 현재 자매 링크 템플릿의 250 픽셀 너비에 쉽게 맞으며, "커먼즈"는 그림과 같이 적게 들어갈 것이다.몇 개의 링크가 두 줄로 늘어선 아이콘 형식으로 축소될 수 있다.따라서 각 자매에 대한 링크 이름 트리거에서, 포맷을 제어하기 위해 얼마나 많은 링크가 포함되는지 나타내는 숫자 명령 1개.그것은 어떤 infobox 등 위에 나타나지만, 만약 페이지에 많은 링크가 있다면, 떠서 페이지 인트로 위의 아이콘 배너 하나로 나타날 수 있다.// FrankB 17:37, 2007년 12월 14일 (UTC)[응답]

우리는 이미 충분한 태그를 가지고 있다.네가 지금 중세시대로의 변화를 보면, 나는 이 생각이 전혀 마음에 들지 않아.존보드 (대화) 2007년 12월 14일 (UTC) 18:10 (답변)

나는 내가 중세시대에 본 것에 전혀 동의하지 않았다.특히 거추장스럽고 다소 불필요하게 복잡해 보였다.모더니스트 (토크) 2007년 12월 14일 (UTC) 20:31[응답]

적어도 내 모니터에는 너의 편집이 아주 엉망으로 디스플레이 된다.한 단어("The")가 왼쪽 상단에 분리되어 있고, 내용상자와 두 개의 탐색상자와 이미지가 있으며, 문장의 나머지를 찾으려면 일부 스크롤이 필요하다. "중세는 중세를 형성한다.눈에 띄지 않는 페이지 전체의 노프린트 배너는 괜찮겠지만, 눈에 띄지 않으면 쉽게 간과될 것이다. 그렇지 않은가?사용자가 외부 링크에 있는 탐색 상자를 찾는 데 문제가 있었다는 증거가 있는가?Ewulp (대화) 22:41, 2007년 12월 14일 (UTC)[응답]

아주 흥미로운 아이디어지만, 네가 제안한 템플릿/배너는 추악하고 불신하기 때문에 절대 통과하지 못할 것 같아.나는 작은 템플릿 박스가 이것과 같은 것이라고 생각한다.

간단한 영어 위키백과의 기사 참조

참고 항목 또는 외부 링크의 페이지 하단에 있는 정보는 매우 유용하며 주의를 산만하게 하지 않는다.크기를 바꾸기 위해 템플릿을 고칠 수 있는데도 너무 어수선해질 것 같아 아무도 그냥 지나치려 하지 않는 것 같다.-- penubag 05:44, 2007년 12월 19일 (UTC)[응답하라]

TOC 랩

기본 왼쪽-TOC의 오른쪽 텍스트 랩을 오른쪽-TOC의 왼쪽 텍스트 랩과 동일하게 만드는 방법은?예를 들어 위키백과:위키프로젝트 트리비아와 대중문화.특히 긴 TOC의 경우 공간을 더 효율적으로 사용할 수 있을 것이다.

{{TOCleft}}? –폼테 12:55, 2007년 12월 21일 (UTC)[응답]

그것은 효과가 있다.하지만 나는 그것이 기본 행동이 될 수 있을까?/그것이 되어야 할까?많은 대형 오토-토씨들이 불필요한 공백을 많이 만든다.

2007년 12시 57분, 12월 21일

헬싱키와 같은 기사를 낮은 해상도나 작은 창에서 본다면, 첫 번째 섹션은 TOC와 인포박스 사이에 정말 꽉 차 있는 것처럼 보인다.많은 경우에, 공백은 좋은 호흡 공간을 허용한다.–폼테 13:04, 2007년 12월 21일 (UTC)[응답]

나는 그것이 "clear"s를 사용하여 처리될 수 있는 특별한 경우라고 생각한다.나는 대부분의 기사가 디폴트 랩의 혜택을 받을 것이라고 생각하며, 현재와 같이 다른 방향 대신에 필요한 곳에 클리어(clear)를 삽입할 수 있을 것이라고 생각한다.

Equazcion •1999/C • 2007년 13:10, 12/21/2007

클릭 한 번으로 긴 TOC를 숨길 수 있으며, 클릭 한 번으로 기사 본문의 첫 번째 섹션으로 점프할 수 있다.나는 화이트 스페이스의 미학을 크게 좋아하지는 않지만, 이것은 저해상도 모니터가 줄어들 때까지 몇 년 동안 따로 두어야 할 것이라고 생각한다. -- John Brabton (주:52, 2007년 12월 21일 (UTC)[응답]

"기본 행동"의 문제는 두 가지다: 1) 처음이며 주로 페이지 통합의 하나이다...각각의 페이지들이 다소 독특하고, 신뢰할 수 없는...그게 그 페이지의 편집자들이 한 일이니까...예측 가능한 (MOS/위키프로젝트 가이드라인 등) 사물을 혼합하고 페이지 니즈나 제안과 같은 사용자 정의도 허용한다(이야기의 일부를 말해주거나 주제의 일부 면을 보여 주는 흥미로운 정보 이미지 2차) 200만 장의 기존 페이지가 현재 기본 행동의 변화를 확인하기 위해 모두 재검증되어야 한다.에드... 그리고 바람직하고, 따라서 두 가지 악 중 덜 나쁜 것이 된다...

간단히 말해서, 누가 시간을 낼 수 있을까...그 지역사회는 강 한가운데에서 급류로 바꾸려고 하지 말고 현재의 말에 머물러 있는 것이 좋을 것이다!세 번째 문제가 있어...MOS는 특히 직사각형 그래픽 요소 사이에 텍스트를 끼우는 것을 금하는데, 기본적으로 우리는 보통 오른쪽으로 떠 있다.모든 인포박스와 다른 것들...

(1)과 (3)을 모두 만족시키는 것은 TOCleft를 사용하는 경우가 거의 없고, TOCright를 사용하는 경우가 더 많으며, 화학 물질 infobox 또는 history box와 같은 상단 섹션 그래픽이 없는 페이지가 필요하다...그러면 보기 흉한 백색 공간이 있는 페이지에 대한 옵션이 하나 남는데, TOC 입력선이 많은 페이지에서만 그런 일이 일어난다고 생각하면...{{TOCnestright}}}.그것은 MOS에 따라 고정하지 않고 텍스트가 왼쪽 여백에 머물도록 하면서 키 큰 인포박스에 버팀목이 될 것이다. 다른 브라우저들은 페이지를 다른 순서로 렌더링하기 때문에 코너에서 발생할 수 있는 정렬 문제를 방지하는 안티펀칭 고정 템플릿 {{FixBunching}}}과 함께 사용하는 것이 가장 좋다... 주로 evi브라우저 제품군 중 가장 흔한 것, 즉 Internet Explorer(인터넷 익스플로러)를 이용하는 것.불행히도, 그것은 오랫동안 가장 흔한 브라우저가 될 것이고, 어떤 페이지 구성도 적어도 80%의 독자들이 그것을 사용할 것이라고 가정해야 한다...토씨네스트의 또 다른 두 가지 좋은 특징...더 넓은 TOC의 너비를 제한할 수 있고, 최대 너비 옵션을 사용하여 포스 래핑을 할 수 있다.몇 개의 단면선만 길고 문제가 있는 곳에 주의해서 사용한다. 두 번째로, 요소 내에서 접미사로 작은 엄지손가락 이미지를 기본적으로 추가할 수 있다.이것은 특히 전기에서 왼쪽 배치와 같은 MOS 핀칭 문제에 의존하지 않고 "젊은 사진"을 기사에 높게 유지하는데 유용할 수 있다.//FrankB 15:34, 2007년 12월 21일 (UTC)[응답]

그래, 문제들이 보여.나는 TOCnestright에 대해 들어본 적이 없지만 그것을 시험해 봐야 할 것이다.나는 포괄적인 답변을 고맙게 생각한다.

그러나 모든 공백을 없애고자 하는 차원에서, 다중 열 TOCs를 어떻게 해결하시겠습니까?그것들은 브라우저 폭이 허락할 때 수평으로 확장될 수 있기 때문에 수직으로 길어질 필요가 없다.

2007년 15:59, 12/21/2007년 15:59, 12/21/2007

나도 같은 욕구를 가지고 있었어...Common.css를 변경해야 함...이에 대한 "기술 토론 스레드"는 사용자 토크에서 찾을 수 있다.CBDUNKerson은 약 2주 전에.나는 치과에 가야 한다.건배! // 프랭크비 16:32, 2007년 12월 21일 (UTC)[응답하라]