미디어위키

미디어위키

스크린샷 The Main Page of the English Wikipedia running MediaWiki 1.36
원저자	매그너스 만스케 , 리 다니엘 크로커
개발자	위키미디어 재단
초판	2002년 1월 25일 ; 19년 전 (2002-01-25)
안정적인 출시	1.36.2 [1]  / 2021년 9월 30일 ; 35일 전 (30 September 2021)
저장소	리트 .wikimedia .ORG / g / 위키 / 코어 /
쓰여진	PHP [2]
운영 체제	윈도우 , 맥OS , 리눅스 , FreeBSD , OpenBSD , 솔라리스
크기	~  48MB (압축)
가능	459 [3] 언어
유형	위키 소프트웨어
특허	GPLv2+ [4]
웹사이트	WWW .mediawiki .ORG

MediaWiki 는 무료 오픈 소스 위키 소프트웨어 입니다. 2002년 Wikipedia 에서 사용하기 위해 개발 되었으며 2003년에 "MediaWiki"라는 이름이 주어졌습니다. ^[5] Wiktionary , Wikimedia Commons 및 Wikidata를 포함하여 Wikipedia 및 거의 모든 기타 Wikimedia 웹사이트 에서 계속 사용되고 있습니다 . 이러한 사이트는 계속해서 MediaWiki에 대한 요구 사항 집합의 많은 부분을 정의합니다. ^[6] MediaWiki는 원래 Magnus Manske가 개발 하고 Lee Daniel Crocker가 개선했습니다 . ^{[7] [8]} 그 이후로 개발은 다음과 같이 조정되었습니다.위키미디어 재단 .

MediaWiki는 PHP 프로그래밍 언어로 작성되었으며 모든 텍스트 콘텐츠를 데이터베이스에 저장 합니다 . 이 소프트웨어는 테라바이트의 콘텐츠와 초당 수십만 뷰를 가질 수 있는 대규모 프로젝트를 효율적으로 처리하도록 최적화되어 있습니다 . ^{[6] [9]} Wikipedia는 세계 최대 웹 사이트 중 하나이기 때문에 여러 계층의 캐싱 및 데이터베이스 복제를 통해 확장성을 달성하는 것이 개발자의 주요 관심사였습니다. MediaWiki의 또 다른 주요 측면은 국제화입니다. 인터페이스는 300개 이상의 언어로 제공됩니다. ^[10] 소프트웨어에는 1,000개 이상의 구성 설정이 있습니다. ^[11]다양한 기능을 추가하거나 변경할 수 있도록 1,800개 이상의 확장을 사용할 수 있습니다. ^[12]

Wikimedia 사이트에서 사용하는 것 외에도 MediaWiki는 Fandom , wikiHow 및 Intellipedia 및 Diplopedia 와 같은 주요 내부 설치를 포함하여 수천 개의 공개 및 비공개 웹 사이트에서 지식 관리 및 콘텐츠 관리 시스템 으로 사용되었습니다 .

라이센스

MediaWiki는 무료이며 오픈 소스 이며 GNU General Public License 버전 2 또는 이후 버전 의 조건에 따라 배포됩니다 . www.mediawiki.org에 있는 문서는 Creative Commons BY-SA 3.0 라이선스에 따라 공개 되며 부분적으로는 공개 도메인 입니다. ^[13] 특히 MediaWiki.org의 매뉴얼 및 기타 콘텐츠는 Creative Commons 라이선스를 받은 반면, 새로운 Wiki 설치에 자유롭게 복사하거나 MediaWiki 소프트웨어와 함께 배포하기 위한 도움말 페이지 세트는 공개 도메인입니다. 이는 Creative Commons 라이선스와 호환되지 않는 라이선스가 있는 Wiki로 도움말 페이지를 가져올 때 발생하는 법적 문제를 제거하기 위해 수행되었습니다.^[14] MediaWiki의 개발은 일반적으로 오픈 소스 미디어 형식 의 사용을 선호했습니다. ^[15]

개발

MediaWiki에는 개발 및 유지 관리를 위한 활발한 자원 봉사 커뮤니티가 있습니다. 패치 를 제출하여 프로젝트에 의미 있는 기여를 한 사용자 는 일반적으로 요청 시 프로젝트의 Git / Gerrit 리포지토리 에 대한 수정 버전을 커밋할 수 있는 액세스 권한이 부여 됩니다. ^[16] 위키미디어 재단을 위한 프로젝트를 주로 개발하는 유료 프로그래머도 있습니다 . MediaWiki 개발자 는 MediaWiki 핵심 및 확장 프로젝트에서 작업하고자 하는 학생에게 멘토 지정을 용이하게 하여 Google Summer of Code 에 참여합니다. ^[17] 2012년 11월 이전 한 해 동안 약 200명의 개발자가 MediaWiki 코어 또는 확장에 대한 변경을 커밋했습니다. ^[18] 주요 MediaWiki 릴리스는 실행 가능한 상태로 지속적으로 유지되는 개발 분기의 스냅샷을 만들어 대략 6개월마다 생성됩니다. ^[19] 마이너 릴리스 또는 포인트 릴리스 는 버그 (특히 보안 문제) 를 수정하기 위해 필요에 따라 발행됩니다 .

MediaWiki는 소프트웨어 변경 사항이 정기적으로 Wikimedia 사이트에 실시간으로 푸시되는 지속적인 통합 개발 모델로 개발되었습니다. ^[19]

MediaWiki에는 또한 Phabricator 를 실행 하는 공개 버그 추적기 phabricator.wikimedia.org 가 있습니다. 이 사이트는 기능 및 개선 요청 에도 사용됩니다 .

역사

2012년 마그누스 만스케

Wikipedia가 2001년 1월에 출시되었을 때, Wikipedia는 기존 Wiki 소프트웨어 시스템인 UseModWiki에서 실행되었습니다 . UseModWiki는 Perl 프로그래밍 언어로 작성되었으며 모든 위키 페이지를 텍스트( .txt ) 파일로 저장 합니다. 이 소프트웨어는 곧 기능과 성능 면에서 한계가 있는 것으로 판명되었습니다. 2001년 중반 에 Wikipedia 편집자 이자 쾰른 대학의 개발자이자 학생 인 Magnus Manske 는 특별히 Wikipedia에서 사용하도록 설계된 UseModWiki를 대체할 새로운 소프트웨어 작업을 시작했습니다. 이 소프트웨어는 PHP 스크립팅 언어 로 작성되었으며 모든 정보를 MySQL 에 저장했습니다.엔진 데이터베이스. 새 소프트웨어는 2001년 8월 24일에 크게 개발되었으며 얼마 지나지 않아 이에 대한 테스트 위키가 설립되었습니다.

이 소프트웨어의 첫 번째 완전한 구현은 2001년 11월 9일 의 새로운 Meta Wikipedia 였습니다. 영어 Wikipedia에서 즉시 구현되기를 원했지만 ^[20] Manske는 초기 웹사이트에 해를 끼치는 잠재적인 버그에 대해 우려했습니다. 기말 시험 기간 동안 그는 크리스마스 직전에 완료해야 했습니다. ^[21] 이로 인해 영어 Wikipedia의 출시가 2002년 1월 25일까지 연기되었습니다. 그 후 소프트웨어는 그 당시의 모든 Wikipedia 언어 사이트에 점차적으로 배포되었습니다. 이 소프트웨어는 "PHP 스크립트" 및 "단계 II"로 언급되었으며, UseModWiki 사용에 소급하여 "단계 I"라는 이름이 붙었습니다.

사용량이 늘어나자 곧 로드 문제가 다시 발생했고 얼마 지나지 않아 소프트웨어의 또 다른 재작성이 시작되었습니다. 이번에는 "3단계"로 알려지게 된 Lee Daniel Crocker 가 수행했습니다 . 이 새로운 소프트웨어는 MySQL 백엔드와 함께 PHP로 작성되었으며 2단계 소프트웨어의 기본 인터페이스를 유지했지만 더 넓은 확장성의 기능이 추가되었습니다 . "3단계" 소프트웨어는 2002년 7월 Wikipedia에 게시되었습니다.

위키 미디어 재단은 7 월에 6 월 20 일 2003 년에 발표 된, 위키 백과 기여자 다니엘 메이어는 "위키 미디어"에 놀이로, 소프트웨어의 이름 "미디어 위키"을 제안했다. ^[22] MediaWiki 이름은 2003년 8월부터 점진적으로 도입되었습니다. 이름은 "Wikimedia" 이름(자체가 "Wikipedia"와 유사)과 (의도적인) 유사성으로 인해 자주 혼동을 일으켰습니다. ^[23]

2021년 4월 1일까지 MediaWiki 로고

구형 제품 로고 는 플로렌스 니바르 드부아르가 찍은 꽃 사진을 사용하여 Erik Möller 가 제작했으며 원래 2003년 7월 20일부터 8월 27일까지 개최된 새로운 Wikipedia 로고 로고 공모전에 출품되었습니다 . ^{[24] [ 25]} 로고는 3위를 차지했으며 Wikipedia가 아닌 MediaWiki를 대표하도록 선택되었으며 2위 로고는 Wikimedia Foundation에 사용되었습니다. ^[26] 이중 대괄호( [[ ]] )는 MediaWiki가 다른 위키 페이지에 대한 하이퍼링크 를 만드는 데 사용 하는 구문을 상징합니다 . 동안 해바라기Wikipedia의 콘텐츠의 다양성, 끊임없는 성장, 그리고 야생성을 나타냅니다. ^[27]

나중, 리옹 Vibber 의 최고 기술 책임자 의 위키 미디어 재단은 , ^[28] 의 역할까지했다 릴리스 관리자 , 가장 활동적인 개발자를 . ^{[5] [29]}

MediaWiki 개발의 주요 이정표는 다음과 같습니다. 분류 시스템(2004); 파서 기능 , (2006); 플래그가 지정된 개정 , (2008); ^[30] CSS 및 JavaScript 용 전달 시스템인 " ResourceLoader " (2011); ^[31] 및 VisualEditor , "보이는 대로 얻는 것"( WYSIWYG ) 편집 플랫폼(2013). ^[32]

2020년 6월 22일 새 로고 디자인 공모 가 시작되었는데, 기존 로고가 비트맵 이미지이고 "높은 디테일"을 가지고 있어 각각 고해상도 및 저해상도로 렌더링할 때 문제가 발생했기 때문입니다. 두 번의 투표를 거쳐 Serhio Magpie 가 디자인한 새로운 현재 MediaWiki 로고 가 2020년 10월 24일에 선택되었으며 2021년 4월 1일에 공식적으로 채택되었습니다. ^[33]

버전 기록

미디어위키의 첫 번째 버전인 1.1은 2003년 12월에 출시되었습니다.

MediaWiki를 사용하는 사이트

FANDOM 은 또한 MediaWiki를 사용합니다.

MediaWiki의 가장 유명한 사용은 Wikipedia 와 Wikimedia Foundation의 다른 프로젝트에서 사용되었습니다. 팬덤 하는 위키 호스팅 서비스 이전에 익명으로 알려진, 미디어 위키에서 실행됩니다. 미디어위키에서 실행되는 다른 공개 위키에는 wikiHow 및 SNPedia가 있습니다. WikiLeaks 는 MediaWiki 기반 사이트로 시작했지만 더 이상 Wiki가 아닙니다.

를 포함한 미디어 위키에서 실행 위키 백과 대안 위키 백과 사전, 다수의 디움 , 메타 피디아 , Scholarpedia 및 컨 서버 피디아 . MediaWiki는 Novell 및 Intel을 비롯한 많은 회사에서도 내부적으로 사용 하고 있습니다. ^{[34] [35]}

정부 내 미디어 위키의 주목할만한 용도는 다음과 인텔리 피디아 에 의해 사용, 미국 정보 기관 , Diplopedia 에 의해 사용, 미국 국무부 의 일부, 그리고 milWiki, milSuite가 에 의해 사용되는 미국 국방부를 . UN 개발 프로그램 및 INSTRAW 와 같은 UN 기관"이 소프트웨어는 Wikipedia를 실행하므로 철저한 테스트가 보장되며 미래에도 계속 잘 개발될 것이며 이 Wiki의 미래 기술자는 다른 어떤 것보다 MediaWiki에 노출될 가능성이 더 높기 때문에 MediaWiki를 사용하여 Wiki를 구현하기로 결정했습니다. 다른 위키 소프트웨어." ^[36]

자유 소프트웨어 재단은 구현하는 미디어 위키를 사용 LibrePlanet의 사이트를. ^[37]

주요 기능

MediaWiki는 풍부한 핵심 기능 세트와 추가 기능을 제공하기 위해 확장 을 첨부하는 메커니즘 을 제공합니다.

국제화 및 현지화

미디어 재생

Niklas Laxström은 translatewiki.net 이 MediaWiki에 300개 이상의 로케일을 제공 할 수 있었던 기능에 대해 설명 합니다.

Wikimedia 프로젝트에서 다국어에 대한 강한 강조로 인해 국제화 및 현지화 는 개발자들로부터 상당한 관심을 받았습니다. 사용자 인터페이스는 완전히 또는 부분적으로에 300 개 이상의 언어로 번역 한 translatewiki.net , ^[10] 또한 현장 관리자 (전체 인터페이스 위키 통해 편집 가능)에 의해 정의 될 수있다.

MediaWiki Language Extension Bundle에 수집된 여러 확장 기능은 MediaWiki 의 다국어 사용과 국제화를 더욱 향상시키도록 설계되었습니다.

설치 및 구성

미디어위키를 설치하려면 사용자가 PHP와 호환 가능한 유형의 SQL 데이터베이스를 실행하는 서버에 대한 관리 권한 이 있어야 합니다 . 일부 사용자 는 사이트의 대부분이 MediaWiki와 크게 호환되지 않는 프레임워크( Zope 또는 Ruby on Rails 등 ) 에서 실행되는 경우 가상 호스트 를 설정하는 것이 유용 하다는 것을 알게 됩니다. ^[38] 클라우드 호스팅 새 서버를 구축 할 필요성을 제거 할 수 있습니다. ^[39]

웹 브라우저 를 통해 설치 PHP 스크립트에 액세스 하여 위키 설정을 초기화합니다. 업로드 활성화, ^[40] 사이트 로고 추가, ^[41] 확장 설치 와 같은 추가 변경 사항 은 LocalSettings.php. ^[42] 위키의 일부 양상들은 특별 페이지를 통해 또는 특정 페이지를 편집하여 구성 할 수있다; 예를 들어, 남용 필터는 특수 페이지를 통해 구성할 수 있으며 ^[43] MediaWiki 네임스페이스에 JavaScript 페이지를 생성하여 특정 가젯을 추가할 수 있습니다 . ^[44]MediaWiki 커뮤니티는 종합적인 설치 가이드를 발행합니다. ^[45]

마크업

MediaWiki(및 그 전신인 UseModWiki )와 다른 위키 엔진 간의 초기 차이점 중 하나는 CamelCase 대신 " 자유 링크 "를 사용했다는 것입니다 . MediaWiki가 만들어졌을 때, 위키는 World Wide Web에 대한 페이지에 대한 링크를 만들기 위해 "WorldWideWeb"과 같은 텍스트를 요구하는 것이 일반적이었습니다 . 반면에 미디어위키의 링크는 이중 대괄호로 단어를 둘러싸서 생성되며, 그 사이의 공백은 그대로 유지 됩니다. 이 변경은 제목의 정확성이 중요한 백과사전을 만드는 목적으로 논리적이었습니다. [[World Wide Web]]

미디어 위키 확장 사용 ^[46] 경량 위키 마크 업을 사용하여보다 쉽게 배울 수 있도록 설계 HTML을 . 미디어위키 마크업과 HTML 간에 표 와 같은 콘텐츠를 변환하기 위한 도구가 존재합니다 . ^[47] MediaWiki 마크업 사양을 만들려는 노력이 있었지만 Wikicode가 문맥에 민감한 문법 규칙을 요구한다는 합의에 도달한 것 같습니다 . ^{[48] [49]} 다음 나란히 비교 위키 마크 업 HTML과의 차이를 나타낸다 :

==== 대화 ====

"받아 일부는 더 [[차] "월 토끼는 아주 진지하게, 앨리스에게 말했다.

앨리스는 화난 어조로 "아직 아무것도 가진 게 없어서 더는 못 가져요."라고 대답했습니다.

"당신은 당신이 취할 수없는 것은 ' 덜 '을 ' 의"모자 장수는 말했다 : "그건 ' '' 매우 '' ' 걸릴 쉽게 ' ' 더 '를 ' 아무것도보다."

< h4 > 대화 </ h4 >

< p > "좀 더 드세요 < a  href = "/wiki/Tea"  title = "Tea" > 차 </ a > " 삼월 토끼가 아주 진지하게 앨리스에게 말했습니다. </ p >

< p > "아직 아무것도 가지고 있지 않습니다." 앨리스가 불쾌한 어조로 대답했습니다. "그래서 더는 가질 수 없습니다." </ p >

< P > "당신은 당신이 취할 수없는 것은 < 난 > 이하 </ 난 > ,"는 모자 장수는 말했다 : "그것의 < B > 매우 </ B > 쉽게 취할 < 난 > 보다 </ I > 아무것도보다." </ p >

(견적 위에서 이상한 나라의 앨리스의 모험 에 의해 루이스 캐롤 )

편집 인터페이스

MediaWiki 1.36( wmf ) 의 편집 인터페이스 , 편집 도구 모음과 위키 구문의 몇 가지 예를 보여줍니다.

MediaWiki의 기본 페이지 편집 도구는 배우기 다소 어렵다고 설명되어 있습니다. ^[50] 미디어위키 기반 위키를 사용하도록 배정된 학생들을 대상으로 한 설문조사에서 위키의 주요 문제에 대한 공개 질문 을 받았을 때 24%가 서식 지정과 관련된 기술적인 문제를 언급했습니다. 이미지 입력. 단어가 포함된 링크를 표시하는 방법을 알 수 없습니다. 숫자가 삽입됩니다." ^[51]

긴 페이지를 쉽게 편집할 수 있도록 미디어위키는 페이지의 하위 섹션(헤더로 식별됨)의 편집을 허용합니다. 등록된 사용자는 또한 사소한 편집 여부를 나타낼 수 있습니다. 맞춤법, 문법 또는 구두점 수정은 사소한 편집의 예인 반면, 새 텍스트의 단락을 추가하는 것은 사소한 편집이 아닌 편집의 예입니다.

한 사용자가 편집하는 동안 두 번째 사용자가 페이지의 동일한 부분에 편집 내용을 저장하는 경우가 있습니다. 그런 다음 첫 번째 사용자가 페이지를 저장하려고 하면 편집 충돌 이 발생합니다. 그런 다음 두 번째 사용자에게는 첫 번째 사용자의 페이지 저장 후 현재 존재하는 페이지에 자신의 콘텐츠를 병합할 수 있는 기회가 주어집니다.

MediaWiki의 사용자 인터페이스는 다양한 언어로 현지화되었습니다. "Content-Language" HTTP 헤더 및 "lang" HTML 속성 으로 전송되도록 Wiki 콘텐츠 자체에 대한 언어도 설정할 수 있습니다 .

애플리케이션 프로그래밍 인터페이스

MediaWiki에는 MediaWiki 데이터베이스에 포함된 데이터에 대한 높은 수준의 직접 액세스를 제공 하는 확장 가능한 웹 API ( 응용 프로그래밍 인터페이스 )가 있습니다. 클라이언트 프로그램은 API를 사용하여 로그인하고 데이터를 가져오고 변경 사항을 게시할 수 있습니다. API는 씬 웹 기반 JavaScript 클라이언트 및 최종 사용자 애플리케이션(예: 파손 방지 도구)을 지원합니다. API는 다른 웹 사이트 의 백엔드 에서 액세스할 수 있습니다 . ^[52] 광범위한 Python 봇 라이브러리인 Pywikibot ^[53] 과 AutoWikiBrowser 라는 인기 있는 반자동 도구 도 API와 인터페이스합니다. ^[54] API는 다음과 같은 URL을 통해 액세스http://en.wikipedia.org/w/api.php?action=query&list=recentchanges. 이 경우 쿼리는 Wikipedia에 사이트의 마지막 10개 편집과 관련된 정보를 요청합니다. API의 인지된 장점 중 하나는 언어 독립성입니다. 클라이언트의 HTTP 연결을 수신 대기 하고 XML , 직렬화된 PHP 또는 JSON 과 같은 다양한 형식으로 응답을 보낼 수 있습니다 . ^[55] 클라이언트 코드 레이어 제공하기 위해 개발 된 추상화 API로. ^[56]

풍부한 콘텐츠

이미지 는 갤러리에서 정렬할 수 있으며, 이는 Wikimedia의 미디어 아카이브인 Wikimedia Commons에 광범위하게 사용되는 기능입니다 .

미디어위키는 특수 구문을 통해 생성된 풍부한 콘텐츠를 지원 합니다. 예를 들어, 소프트웨어는 LaTeX 와 OCaml로 작성된 특수 파서를 사용하여 수학 공식을 렌더링하기 위한 선택적 지원과 함께 제공됩니다 . 수학적 플로팅 및 악보에 대한 그래픽 타임라인 에서 이집트 상형 문자에 이르기까지 다른 콘텐츠에 대한 유사한 기능을 확장을 통해 사용할 수 있습니다.

소프트웨어는 업로드된 다양한 미디어 파일을 처리하는 데 더욱 강력해졌습니다. 가장 풍부한 기능은 이미지 갤러리와 축소판을 비교적 쉽게 생성할 수 있는 이미지 영역입니다. Exif 메타데이터 도 지원합니다 . 가장 큰 무료 콘텐츠 미디어 아카이브 중 하나인 Wikimedia Commons 를 운영하기 위해 MediaWiki를 사용함으로써 이 영역에서 추가 기능이 필요하게 되었습니다.

WYSIWYG 편집 을 위해 VisualEditor 는 편집자의 편집 프로세스를 단순화하는 MediaWiki에서 사용할 수 있으며 MediaWiki 1.35부터 번들로 제공됩니다. ^[57] 다른 정보는 다른 도로 WYSIWYG 편집 처리를 위해 존재한다. ^[58]

편집 내용 추적

편집 추적을 지원하는 MediaWiki의 기능 중에는 Wiki에 대한 최근 편집 목록을 제공하는 최근 변경 기능이 있습니다. 이 목록에는 편집 사용자, 편집 요약, 편집된 페이지, 사용자 정의 가능한 남용 필터 및 기타 확장 기능으로 추가된 태그(예: "가능한 멀웨어 링크") ^[59] 와 같은 편집에 대한 기본 정보가 포함되어 있습니다 ^. 도움이 되지 않는 편집. ^[60] 더 활동적인 위키에서는 편집이 너무 많아 최근 변경 사항을 수동으로 추적하기가 어렵습니다. 사용자 지원 도구를 포함한 파손 방지 소프트웨어 ^[61] 는 최근 변경 항목을 처리하기 위해 이러한 위키에서 사용되기도 합니다. 최근 변경 사항의 지속적인 피드를 IRC 채널 에 전송하여 서버 부하를 줄일 수 있습니다.이러한 도구가 모니터링할 수 있으므로 새로 고쳐진 최근 변경 사항 피드에 대한 요청을 API로 보낼 필요가 없습니다. ^{[62] [63]}

또 다른 중요한 도구는 감시 목록입니다. 로그인한 각 사용자에게는 원하는 페이지를 추가할 수 있는 감시 목록이 있습니다. 해당 페이지 중 하나를 편집하면 다음에 새로 고칠 때 해당 편집 요약이 관심 목록에 나타납니다. ^[64] 최근 변경 사항 페이지와 마찬가지로 관심 목록에 나타나는 최근 수정 사항에는 기사 기록 및 특정 변경 사항을 쉽게 검토할 수 있는 클릭 가능한 링크가 포함되어 있습니다.

특정 사용자가 만든 모든 편집 내용을 검토할 수도 있습니다. 이런 식으로 편집이 문제가 있는 것으로 식별되면 사용자의 다른 편집에 문제가 있는지 확인할 수 있습니다.

MediaWiki는 기사의 특정 버전에 대한 링크를 허용합니다. 이것은 전문 피어 리뷰어가 기사를 분석하고 개선하며 해당 기사의 신뢰할 수 있는 버전에 대한 링크를 제공할 수 있다는 점에서 과학 커뮤니티에 유용했습니다. ^[65]

탐색

위키링크

위키를 통한 탐색은 주로 내부 위키링크를 통해 이루어집니다. 미디어위키의 위키링크는 대상 페이지가 로컬 위키에 있으면 링크가 파란색으로, 그렇지 않으면 빨간색으로 표시되는 페이지 존재 감지를 구현합니다. 사용자가 빨간색 링크를 클릭하면 해당 제목으로 기사를 작성하라는 메시지가 표시됩니다. 페이지 존재 감지는 사용자가 "위키화된" 기사, 즉 다른 관련 주제에 대한 링크가 포함된 기사를 아직 존재하지 않는 상태에서 작성하는 것을 실용적으로 만듭니다.

인터위키 링크

Interwiki 링크는 네임스페이스와 거의 같은 방식으로 작동합니다. 예를 들어 의 페이지 제목이 wikiquote:Jimbo Wales사용자를 Wikiquote 의 Jimbo Wales 기사로 안내 하도록 인터위키 접두사 세트를 구성할 수 있습니다 . ^[66] 내부 wikilinks 달리, 위키 링크 페이지의 존재를 감지 기능이 부족하고 그에 따라 파란색 위키 링크가 파손 여부 알 수있는 방법이 없습니다.

언어 간 링크

언어 간 링크의 예

언어 간 링크는 대부분의 MediaWiki 스킨의 사이드바에 표시되는 작은 탐색 링크로, 기사를 동일한 Wiki 패밀리 내의 다른 언어로 된 관련 기사와 연결합니다. 이것은 더 큰 컨텍스트로 연결된 언어별 커뮤니티를 제공할 수 있으며 모든 Wiki는 동일한 서버에 있거나 각각은 자체 서버에 있습니다. ^[67]

이전에 Wikipedia는 언어 간 링크를 사용하여 Wikipedia의 다른 버전에 있는 동일한 주제에 대한 다른 기사에 기사를 연결했습니다. 이것은 Wikidata의 출시로 대체되었습니다. ^[68]

콘텐츠 구성

페이지 탭 및 관련 페이지

"벡터" 스킨을 사용하는 미디어위키 페이지 탭. "토론" 탭의 빨간색은 해당 기사에 아직 토론 페이지가 없음을 나타냅니다. 다른 빨간색 위키링크와 마찬가지로 이를 클릭하면 페이지를 생성하라는 메시지가 표시됩니다.

페이지 탭은 페이지 상단에 표시됩니다. 이러한 탭을 통해 사용자는 작업을 수행하거나 현재 페이지와 관련된 페이지를 볼 수 있습니다. 사용 가능한 기본 작업에는 현재 페이지 보기, 편집 및 토론이 포함됩니다. 표시되는 특정 탭은 사용자가 Wiki에 로그인했는지 여부와 사용자에게 Wiki에 대한 sysop 권한이 있는지 여부에 따라 다릅니다. 예를 들어 페이지를 이동하거나 관심 목록에 추가하는 기능은 일반적으로 로그인한 사용자로 제한됩니다. 사이트 관리자는 JavaScript를 사용하거나 확장 프로그램을 설치하여 탭을 추가하거나 제거할 수 있습니다. ^[69]

각 페이지에는 사용자가 이전에 존재했던 페이지의 모든 버전에 액세스 하고 선택한 두 버전 간에 차이점 을 생성할 수 있는 관련 기록 페이지가 있습니다 . 사용자의 기여는 여기에 표시될 뿐만 아니라 사이드바의 "사용자 기여" 옵션을 통해서도 표시됩니다. Carl Challborn & Teresa Reimann은 "이 기능은 위키 순수주의자의 협동적이고 '자아 없는' 정신에서 약간 벗어날 수 있지만 개별 학생 사용자의 기여도와 참여를 평가해야 하는 교육자에게 매우 유용할 수 있습니다. " ^[70]

네임스페이스

미디어위키는 콘텐츠 구성을 위한 하이퍼링크 이상의 많은 기능을 제공합니다 . 그러한 초기 기능 중 하나는 네임스페이스 입니다. Wikipedia의 초기 문제 중 하나는 백과사전 편집자에 대한 개인 페이지뿐만 아니라 유지 관리 및 공동 토론과 관련된 페이지에서 백과사전 콘텐츠를 분리하는 것이었습니다. 네임스페이스는 페이지 제목 앞의 접두사(예: " User:" 또는 " Talk:")로, 페이지 목적에 대한 설명자 역할을 하며 동일한 제목 아래에 서로 다른 기능을 가진 여러 페이지가 존재할 수 있도록 합니다. 예를 들어, [[The Terminator]]기본 네임스페이스에서 제목이 " "인 페이지는 Arnold Schwarzenegger 가 주연한 1984년 영화를 설명할 수 있는 반면 "[[User:The Terminator]]"는 이 이름을 가명으로 선택한 사용자를 설명하는 프로필이 될 수 있습니다. 더 일반적으로 각 네임스페이스에는 Talk:" User talk:" 또는 " Template talk:" 와 같은 내용을 논의하는 데 사용할 수 있는 연결된 네임스페이스가 있습니다 . 페이지는 콘텐츠를 콘텐츠를 둘러싼 토론과 분리할 수 있도록 하는 것입니다. ^{[71] [72]}

네임스페이스는 서로 다른 기본 유형의 정보 또는 기능을 구분 하는 폴더 로 볼 수 있습니다 . 사이트 관리자가 사용자 지정 네임스페이스를 추가할 수 있습니다. 콘텐츠에는 기본적으로 16개의 네임스페이스가 있으며 동적으로 생성된 " Special:" 페이지와 미디어 파일에 대한 링크에 2개의 "의사 네임스페이스"가 사용됩니다 . 미디어위키의 각 네임스페이스는 번호가 매겨져 있습니다. 콘텐츠 페이지 네임스페이스에는 짝수 번호가 있고 관련 토론 페이지 네임스페이스에는 홀수 번호가 있습니다. ^[73]

카테고리 태그

사용자는 콘텐츠 텍스트에 하나 이상의 범주 태그를 추가하여 새 범주를 만들고 페이지와 파일을 해당 범주에 추가할 수 있습니다. 이러한 태그를 추가하면 해당 카테고리의 모든 페이지 목록으로 독자를 안내하는 링크가 페이지 하단에 생성되어 관련 기사를 쉽게 탐색할 수 있습니다. ^[74] 의 콘텐츠를 구성하는 카테고리의 사용을 조합하여 설명되었다 :

• 공동 태그 시스템 과 같은 del.icio.us 와
• Dewey Decimal Classification 과 같은 계층적 분류 . ^[75]

하위 페이지

네임스페이스 외에도 콘텐츠는 하위 페이지를 사용하여 주문할 수 있습니다 . 이 간단한 기능은 슬래시 뒤 페이지(이 경우 "서브 페이지 제목")에서 슬래시 앞 페이지(이 경우 "페이지 제목")까지 패턴의 자동 이동 경로 를 제공합니다 [[Page title/Subpage title]].

커스터마이징

사용자는 모든 페이지뷰에서 실행되는 사용자 정의 JavaScript 를 구성할 수 있습니다 . 이것은 사용자가 "설치"할 수 있는 JavaScript 도구로 이어졌으며 여기에 표시된 "탐색 팝업" 도구는 링크 제목 위로 마우스를 가져갈 때 기사의 작은 미리보기를 표시합니다.

이 기능이 활성화된 경우 사용자는 스타일시트를 사용자 정의하고 모든 페이지뷰와 함께 실행되도록 클라이언트 측 JavaScript 를 구성할 수 있습니다 . Wikipedia에서 이는 Wiki를 통해 개발되고 사용자 간에 공유되는 수많은 추가 도구와 도우미로 이어졌습니다. 예를 들어 탐색 팝업 은 사용자가 링크 위로 마우스를 가져갈 때 기사 미리보기를 표시하고 일반적인 유지 관리 작업에 대한 바로 가기를 제공하는 사용자 지정 JavaScript 도구입니다. ^[76]

맞춤형 스킨이 있는 MediaWiki를 사용하는 Wiki 의 스크린샷

전체 미디어위키 사용자 인터페이스는 필요한 권한을 가진 사용자(일반적으로 "관리자"라고 함)가 위키 자체를 통해 편집할 수 있습니다. 이것은 각 페이지 제목이 특정 사용자 인터페이스 메시지를 식별하는 접두사 "MediaWiki:"가 있는 특수 네임스페이스를 통해 수행됩니다. 확장을 사용하여 ^[77] 사용자가 개인 스크립트를 만들고 사용자 기본 설정 페이지에서 적절한 옵션을 토글하여 특정 사이트 전체 스크립트를 적용할지 여부를 선택할 수도 있습니다.

템플릿

"MediaWiki:" 네임스페이스는 원래 특수 구문을 사용하여 다른 페이지에 동적으로 로드할 수 있는 사용자 정의 텍스트 블록을 만드는 데 사용되었습니다. 이 콘텐츠는 나중에 자체 네임스페이스인 "Template:"으로 이동되었습니다.

템플릿은 해당 페이지가 요청될 때마다 다른 페이지 내에서 동적으로 로드될 수 있는 텍스트 블록입니다. 템플릿은 이중 중괄호로 묶인 특수 링크 (예: " {{Disputed|date=October 2018}}")로 템플릿 호출 대신 로드 할 템플릿(이 경우 Template:Disputed 에 있음 )을 호출합니다.

템플릿은 속성-값 쌍을 포함하는 구조화된 문서 입니다. 그들은 기사 페이지에 포함될 때 값 이 할당되는 매개변수 로 정의됩니다 . 매개변수의 이름은 등호로 값과 구분 됩니다 . 로 알려진 템플릿 클래스 infoboxes를 수집하고 일반적으로 상단 (모바일보기) 또는 문서의 오른쪽 상단 (바탕 화면보기)에 그 주제에 대한 정보의 하위 집합을 제시하는 위키 백과에 사용됩니다.

템플릿 대체 ( subst:템플릿 링크의 시작 부분 에 추가하여 호출) 라는 관련 메서드 는 페이지가 로드될 때마다 템플릿 콘텐츠를 동적으로 로드하는 대신 대상 페이지에 템플릿 콘텐츠를 삽입합니다(예: 복사 및 붙여넣기 작업). . 이로 인해 템플릿을 사용할 때 불일치가 발생할 수 있지만 특정 경우에 유용할 수 있으며 대부분의 경우 더 적은 서버 리소스 가 필요 합니다(실제 절약량은 wiki 구성 및 템플릿의 복잡성에 따라 다를 수 있음).

템플릿은 다양한 용도로 사용됩니다. 템플릿을 사용하면 여러 페이지에서 일관되게 사용되는 복잡한 테이블 레이아웃을 만들 수 있으며 템플릿 매개변수를 사용하여 테이블의 내용만 삽입됩니다. 템플릿은 문서에 템플릿을 넣어 Wikipedia 문서의 문제를 식별하는 데 자주 사용됩니다. 그런 다음 이 템플릿은 기사 내용이 논쟁의 여지가 있거나 다른 주의가 필요함을 나타내는 그래픽 상자를 출력하고 이러한 성격의 기사를 찾을 수 있도록 분류합니다. 템플릿은 또한 사용자 페이지에서 사이트를 환영하는 표준 메시지를 사용자에게 전송하는 데 사용되며, ^[78] 뛰어난 기여에 대해 상을 주고, ^{[79] [80]} 행동이 부적절하다고 간주될 때 경고하고, ^[81]편집이 차단되면 알림 ^[82] 등.

그룹 및 접근 제한

MediaWiki는 사용자 그룹을 만들고 정의하는 데 유연성을 제공합니다. 예를 들어 사용자를 차단하고 페이지를 삭제할 수 있으며 최근 변경 사항 로그에서 기본적으로 편집 내용이 숨겨져 있는 임의의 "닌자" 그룹을 만들 수 있습니다. 특정 수의 편집을 수행하고 특정 일 수를 기다린 후에 구성원이 되는 "자동 확인" 사용자 그룹을 설정할 수도 있습니다. ^[83] 기본적으로 사용되는 일부 그룹은 관료와 가능 관리자입니다. 관료는 다른 사용자의 권리를 변경할 권한이 있습니다. Sysops는 페이지 보호 및 삭제 와 사용자의 편집 차단에 대한 권한이 있습니다 . 미디어위키'편집 권한에 대한 가용한 통제는 다음의 매뉴얼과 같은 중요한 문서를 게시하고 유지하는 데 충분하다고 간주되었습니다.병원의 표준 수술 절차 . ^[84]

페이지가 쓸모없는 콘텐츠로만 구성된 경우 해당 콘텐츠를 제거하는 몇 가지 방법이 있습니다. 모든 사용자가 사용할 수 있는 가장 간단한 방법은 페이지를 비우는 것입니다. 그러나 이는 비어 있는 페이지를 존재하지 않는 것처럼 처리하는 확장 프로그램이 설치되어 있지 않는 한 페이지 존재 감지를 방해합니다. ^[85] 블랭킹은 또한 기록 페이지를 통해 콘텐츠에 액세스할 수 있도록 하며, 비-sysops가 콘텐츠 제거 결정을 적절하게 쉽게 검토할 수 있도록 하여 잠재적으로 투명성 을 높이지만 허용되지 않거나 심지어 불법일 수 있습니다. ^[86]일부 경우에. 또 다른 옵션은 sysop이 페이지를 삭제하여 sysop이 아닌 사용자가 페이지를 볼 수 없도록 하는 것입니다. RevisionDelete라고 하는 또 다른 삭제 수준은 그룹(예: "감독자")에서 해당 그룹의 비회원이 페이지를 보는 것을 방지하는 데 사용할 수 있습니다. ^[87] 또한 특정 확장 기능을 사용하여 위키의 일반 채널을 통해 볼 수 있는 콘텐츠를 제거 하거나 ^[88] 데이터베이스에서 개정판을 완전히 삭제할 수도 있습니다. ^[89]

MediaWiki는 접근 제한과 관련된 기본 기능 세트와 함께 제공되지만 독창적이고 지속적인 디자인은 콘텐츠 분리가 아닌 주로 콘텐츠와 관련된 기능에 의해 주도됩니다. 결과적으로, 최소한의 예외(특정 도구 및 관련 "특수" 페이지 관련)를 제외하고, 페이지 액세스 제어는 핵심 개발에서 결코 높은 우선순위가 아니었으며 개발자는 보안 사용자 액세스 및 권한 제어가 필요한 사용자가 다음에 의존해서는 안 된다고 명시했습니다. MediaWiki는 이러한 상황을 위해 설계된 적이 없기 때문입니다. 예를 들어, 특정 사용자만 일부 페이지를 읽고 액세스할 수 있는 위키를 만드는 것은 매우 어렵습니다. ^[90] 여기에서 Foswiki , MoinMoin 및 Confluence 와 같은 위키 엔진액세스 제어 목록 과 같은 고급 보안 메커니즘을 지원하여 더 많은 유연성을 제공 합니다 .

확장성

MediaWiki 코드베이스에는 확장 가능한 방식으로 PHP 코드를 추가하기 위해 콜백 함수 를 사용하는 다양한 후크 가 포함되어 있습니다 . 이를 통해 개발자는 코어를 수정하거나 검토를 위해 코드를 제출할 필요 없이 확장을 작성할 수 있습니다. 확장 설치는 일반적으로 구성 파일에 행을 추가하는 것으로 구성되지만 일부 경우에는 데이터베이스 업데이트 또는 코어 패치와 같은 추가 변경이 필요합니다.

개발자가 MediaWiki에 기능을 추가할 수 있도록 5개의 주요 확장 지점이 만들어졌습니다. 후크는 특정 이벤트가 발생할 때마다 실행됩니다. 예를 들어, ArticleSaveComplete저장 아티클 요청이 처리된 후에 후크가 발생합니다. ^[91] 예를 들어, 새 사용자 또는 익명 사용자가 위키에서 페이지 편집이 발생할 때마다 선택된 사용자에게 알리는 확장 프로그램에서 사용할 수 있습니다. ^[92] 새로운 태그가 개폐 태그 처리 데이터를 생성 할 수있다 ( <newtag>...</newtag>). ^[93] 파서 함수는 새로운 명령을 생성하는데 사용될 수있다 ( {{#if:...|...|...}}). ^[94]특정 기능을 수행하기 위해 새로운 특수 페이지를 생성할 수 있습니다. 이러한 페이지는 동적으로 생성됩니다. 예를 들어, 특수 페이지는 외부 사이트에 대한 하나 이상의 링크가 있는 모든 페이지를 표시하거나 사용자가 제출한 피드백을 제공하는 양식을 생성할 수 있습니다. ^[95] 스킨은 사용자가 미디어 위키의 모양과 느낌을 사용자 정의 할 수 있습니다. ^[96] 부 확장점을 통해 Amazon S3 를 사용 하여 이미지 파일을 호스팅 할 수 있습니다. ^[97]

확장

개발자를 위한 리소스

미디어위키는 그 확장을 통해 다양한 목적을 위해 더욱 발전되고 유용하게 만들어질 수 있습니다. 이러한 확장은 복잡성이 크게 다릅니다.

Wikimedia Foundation은 많은 확장이 저장소를 호스팅 하는 Git 서버를 운영 합니다. 그들 대부분은 또한 MediaWiki 웹사이트에 문서 페이지가 있습니다.

MediaWiki 코드 검토 는 그 자체로 MediaWiki 확장을 통해 역사적으로 촉진되었습니다. ^[98] 2012년 3월 현재 Gerrit를 통해 수행되었습니다 .

버전 1.16부터 미디어위키는 jQuery 라이브러리를 사용합니다 . ^[99]

텍스트 조작

2008년 팀 스탈링

가장 널리 사용되는 확장 기능은 구문 분석기 기능 확장인 ParserFunctions로, 조건문의 결과에 따라 다양한 콘텐츠를 렌더링할 수 있습니다 . ^[100] 이 조건식은, 문자열을 비교하는 파라미터가 비어 있는지 여부를 평가하기 수학 식을 평가하고, 페이지가 존재하는지 여부에 따라 두 개의 값 중 하나를 반환하는 등의 기능을 수행 할 수있다. {{Qif}}라는 악명 높은 비효율적인 템플릿을 대체하기 위해 설계되었습니다. ^[101] 다음 들러는 ParserFunctions 연장 과거 회상 : ^[30]

2006년에 일부 Wikipedia 사용자는 템플릿 기능과 CSS의 복잡하고 복잡한 상호 작용을 통해 조건부 Wiki 텍스트, 즉 템플릿 매개변수에 특정 값이 있는 경우 표시되는 텍스트를 만들 수 있다는 것을 발견했습니다. 여기에는 템플릿 내 템플릿의 반복적인 호출이 포함되어 전체 시스템의 성능이 저하되었습니다. 개발자는 그러한 사용을 감지하고 소프트웨어 내에서 명시적으로 허용하지 않음으로써 분명히 원하는 기능의 확산을 허용하지 않거나 효율적인 대안을 제공하는 선택에 직면했습니다. 후자는 기본 소프트웨어에 구현된 기능을 호출하는 위키 텍스트인 파서 기능의 도입을 발표한 Tim Starling에 의해 수행되었습니다. 처음에는 조건부 텍스트와 간단한 수학식의 계산만 구현했지만,그러나 이것은 이미 위키 편집자들의 가능성을 엄청나게 증가시켰습니다. 시간이 지남에 따라 추가 파서 기능이 도입되어 마침내 확장 기능을 간단하게 작성하여 예를 들어 지오코딩 서비스 또는 위젯과 같은 임의의 기능을 추가할 수 있는 프레임워크로 이어졌습니다. 이번에는 개발자들이 커뮤니티의 요구에 명확하게 반응하여 커뮤니티가 가진 문제(예: 조건부 텍스트)의 솔루션과 싸우거나 이전 관행을 대체하고 전반적으로 더 나은 결과를 얻기 위해 향상된 기술 구현을 제공해야 했습니다. 성능.이번에는 개발자들이 커뮤니티의 요구에 명확하게 반응하여 커뮤니티가 가진 문제(예: 조건부 텍스트)의 솔루션과 싸우거나 이전 관행을 대체하고 전반적으로 더 나은 결과를 얻기 위해 향상된 기술 구현을 제공해야 했습니다. 성능.이번에는 개발자들이 커뮤니티의 요구에 명확하게 반응하여 커뮤니티가 가진 문제(예: 조건부 텍스트)의 솔루션과 싸우거나 이전 관행을 대체하고 전반적으로 더 나은 결과를 얻기 위해 향상된 기술 구현을 제공해야 했습니다. 성능.

또 다른 파서 함수 확장인 StringFunctions는 문자열 길이, 문자열 위치 등을 평가할 수 있도록 개발되었습니다. 동일한 기능을 수행하기 위해 어색한 해결 방법을 만든 Wikimedia 커뮤니티는 ^[102] 프로젝트에서 이 기능을 사용할 수 있도록 요구했습니다. ^[103] 그 기능의 대부분은 결국 ParserFunctions 확장에 통합 되었지만 ^[104] 기본적으로 비활성화되어 있고 문자열 기능을 활성화하면 사용자가 "가장 추악하고 가장 비효율적인 프로그래밍에서 자신의 파서를 구현할 수 있음"이라는 Tim Starling의 경고가 수반되었습니다. 사람에게 알려진 언어: ParserFunctions가 있는 MediaWiki 위키텍스트." ^[105]

2012년부터 확장 프로그램인 Scribunto가 존재하여 "모듈"(스크립팅 언어 Lua 로 작성된 Wiki 페이지)을 생성  할 수 있으며 템플릿 및 표준 Wiki 페이지 내에서 실행할 수 있습니다. Scribunto는 2013년부터 Wikipedia 및 기타 Wikimedia 사이트에 설치되었으며 해당 사이트에서 많이 사용됩니다. Scribunto 코드는 ParserFunctions를 사용하는 해당 wikitext 코드보다 훨씬 빠르게 실행됩니다. ^[106]

각주 및 학술 관련 전시용

또 다른 인기 있는 확장은 인라인 참조를 사용하여 페이지에 각주를 추가할 수 있는 인용 확장입니다. ^[107] 이 확장하지만, 사용하기 불편하고 복잡한되는 신택스를 기억하도록 사용자에게 요구하는 비판되었다. RefToolbar 라는 가젯은 일반적인 템플릿을 사용하여 인용을 쉽게 만들 수 있도록 합니다. MediaWiki에는 수학 확장 ^[108] 및 분자를 3D 로 렌더링할 수 있는 확장 과 같이 학계에 적합한 몇 가지 확장이 있습니다 . ^[109]

통합

MediaWiki가 거의 모든 것과 통합될 수 있도록 하는 일반 위젯 확장이 존재합니다. 위키를 개선할 수 있는 확장의 다른 예로는 카테고리 제안 확장 ^[110] 과 Flash 비디오 , ^[111] YouTube 비디오, ^[112] 및 RSS 피드 를 포함하기 위한 확장이 있습니다 . ^[113] 미국 상원 및 하원 회의록을 비디오로 보관하는 사이트인 Metavid 는 MediaWiki를 공동 비디오 제작 영역으로 확장하는 코드를 사용하여 만들었습니다. ^[114]

링크스팸 퇴치

MediaWiki가 검색 엔진 최적화 에서 이러한 시도를 억제하기 위해 nofollow 속성을 사용한다는 사실에도 불구하고 MediaWiki 설치를 위해 웹을 검색하고 링크 스팸 을 추가하는 많은 스팸봇 이 있습니다 . ^[115] 문제의 일부는 미러 와 같은 제3자 재출판자가 웹사이트에 nofollow 태그를 독립적으로 구현하지 않을 수 있으므로 마케터는 해당 항목이 제3자 웹사이트에 나타날 때 페이지에 링크를 삽입하여 PageRank 혜택을 계속 얻을 수 있다는 것 입니다. ^[116] CAPTCHA 를 도입하여 문제를 해결하기 위해 스팸 방지 확장이 개발되었습니다 . ^[117] 특정 URL을 블랙리스트에 추가하고 ^[118] 특정 사용자가 최근에 추가한 페이지의 대량 삭제를 허용합니다. ^[119]

검색 및 쿼리

MediaWiki에는 표준 텍스트 기반 검색이 사전 설치되어 있습니다. Elasticsearch (2014년부터 Wikipedia에서 사용), Lucene ^[120] 및 Sphinx를 포함하여 MediaWiki가 보다 정교한 타사 검색 엔진을 사용할 수 있도록 하는 확장이 존재합니다 . ^[121]

다양한 MediaWiki 확장 기능도 생성되어 위키 내에 입력된 데이터 와 페이지의 개정 기록과 같은 메타 데이터 모두에 대해 보다 복잡하고 패싯 검색 이 가능합니다 . ^{[122] [123]} 시맨틱 위키가 이러한 하나 개의 확장이다. ^{[124] [125]}

데이터베이스

미디어위키 데이터베이스 구조의 개략도

MediaWiki는 MySQL / MariaDB , PostgreSQL 또는 SQLite 관계형 데이터베이스 관리 시스템을 사용할 수 있습니다. Oracle Database 및 Microsoft SQL Server에 대한 지원은 MediaWiki 1.34부터 중단되었습니다. ^[126] 미디어 위키 데이터베이스 수십 포함 표 A 이하, page페이지의 제목, 페이지 식별자 및 다른 메타 데이터를 포함 테이블; ^[127] 그리고revision페이지 ID, 수행된 변경 사항에 대한 간략한 텍스트 요약, 기사 편집자의 사용자 이름(또는 등록되지 않은 사용자의 경우 해당 IP 주소) 및 타임스탬프. ^{[128] [129]}

4년 반 동안 미디어위키 데이터베이스에는 170개의 스키마 버전 이 있었습니다 . ^[130] 의 메타 데이터가 저장 성과 유연성을 향상시키기 위해, 해당 콘텐츠로부터 분리되었을 때 아마도 가장 스키마 변경은 위키 1.5에서 수행 하였다. 이 업그레이드가 위키백과에 적용되었을 때 사이트는 편집을 위해 잠겨 있었고 약 22시간 만에 스키마가 새 버전으로 변환되었습니다. 관심 목록을 통해 기사 섹션을 볼 수 있도록 하는 제안과 같은 일부 소프트웨어 개선 제안은 필요한 스키마 변경으로 인해 과도한 Wikipedia 가동 중지 시간이 필요했기 때문에 거부되었습니다. ^[131]

성능 및 스토리지

웹상에서 가장 트래픽이 많은 사이트 중 하나인 Wikipedia를 실행하는 데 사용되기 때문에 MediaWiki의 성능과 확장성은 고도로 최적화되었습니다. ^[29] MediaWiki는 Squid , 로드 밸런싱된 데이터베이스 복제, 클라이언트 측 캐싱, 자주 액세스하는 쿼리 결과 처리를 위한 memcached 또는 테이블 기반 캐싱, 단순 정적 파일 캐시, 기능 축소 작업, 개정 압축 및 작업 대기열을 지원합니다. 데이터베이스 작업을 위해. MediaWiki 개발자는 값비싼 알고리즘, 데이터베이스 쿼리 등을 피하고, 비용이 많이 들고 참조의 시간적 지역성을 갖는 모든 결과를 캐싱하고, 프로파일링을 통해 코드의 핫스팟에 집중함으로써 소프트웨어 최적화를 시도했습니다.. ^[132]

MediaWiki 코드는 읽기-쓰기 데이터베이스에 데이터를 쓰고 읽기 전용 데이터베이스에서 읽을 수 있도록 설계되었습니다. 그러나 읽기 전용 데이터베이스가 아직 최신 버전이 아닌 경우 일부 읽기 작업에 읽기-쓰기 데이터베이스를 사용할 수 있습니다. . 기사 개정 이력, 기사 관계(링크, 카테고리 등), 사용자 계정 및 설정과 같은 메타데이터 는 핵심 데이터베이스에 저장되고 캐시될 수 있습니다. 더 드물게 사용되는 실제 개정 텍스트 는 외부 저장소에 추가 전용 Blob 으로 저장할 수 있습니다 . 이 소프트웨어는 2011년 8월 현재 약 800개의 위키가 있는 위키미디어 와 같은 대규모 위키 팜 의 운영에 적합합니다 . 그러나 미디어위키는 그러한 설치를 관리하기 위한 내장 GUI가 제공되지 않습니다.

경험적 증거에 따르면 미디어위키 데이터베이스의 대부분의 개정판은 이전 개정판과 약간만 다른 경향이 있습니다. 따라서 기사의 후속 개정판을 연결한 다음 압축 하여 최대 100배의 매우 높은 데이터 압축률을 달성할 수 있습니다 . ^[132]

위키텍스트를 저장하고 페이지를 조합하는 방법과 같은 아키텍처에 대한 자세한 내용은 외부 링크를 참조하십시오 .

제한 사항

형식 구문이 정의되지 않았기 때문에 파서는 MediaWiki 구문에 대한 사실상의 표준 역할을 합니다 . 이러한 형식적 정의가 없기 때문에 MediaWiki용 WYSIWYG 편집기 를 만드는 것이 어려웠 지만 인기 있는 VisualEditor 를 포함하여 여러 WYSIWYG 확장이 존재합니다 .

MediaWiki는 전용 온라인 포럼 이나 블로깅 소프트웨어 ^[133]를 대체하도록 설계되지 않았지만 ^[133] 이 두 가지를 모두 허용하는 확장 기능이 존재합니다. ^{[134] [135]}

새로운 미디어위키 사용자는 4개의 물결표(~~~~)로 게시물에 서명하는 것을 잊어버리거나 ^[136] 일반 텍스트 서명을 수동으로 입력하는 것과 같은 특정 실수를 하는 것이 일반적입니다 . ^[137]MediaWiki 토론 페이지의 커뮤니케이션과 관련된 특이한 세부 사항에 익숙하지 않기 때문입니다. 반면에 한 교육자는 이러한 토론 페이지의 형식이 기존의 스레드 토론 포럼보다 토론에 더 세분화된 기능을 제공한다고 언급한 장점으로 인용했습니다. 예를 들어, 전체 메시지에 '회신'하는 대신 토론 참가자는 원본 페이지의 모든 단어에서 새 Wiki 페이지에 대한 하이퍼링크를 만들 수 있습니다. 기존의 스레드 토론 포럼에서 일련의 응답 메시지가 아니라 하이퍼링크로 연결된 위키 페이지를 통해 콘텐츠를 사용할 수 있으므로 토론을 더 쉽게 따라갈 수 있습니다. 그러나 몇몇 경우를 제외하고 학생들은 이 기능을 사용하지 않았고,아마도 전통적인 선형 토론 스타일에 익숙하고 내용을 더 많이 만드는 방법에 대한 지침이 부족하기 때문일 수 있습니다.링크가 풍부한 '. ^[138]

기본적으로 MediaWiki는 동적으로 조합된 문서 또는 다른 페이지의 데이터를 집계하는 페이지 생성을 거의 지원하지 않습니다. MediaWiki 내에서 직접 이러한 기능을 활성화하는 방법에 대한 연구가 수행되었습니다. ^[139] 시맨틱 위키의 확장은 이러한 기능을 제공한다. Wikipedia에서는 사용되지 않지만 1,600개 이상의 다른 MediaWiki 설치에서 사용됩니다. ^[140] Wikibase 저장고 Wikibase 저장소 클라이언트 단에서 구현되는 위키 데이터 및 위키 각각 어느 정도 제공하는 시맨틱 웹 기능 및 각종 위키 기사 infoboxes 중앙부에 저장된 데이터의 링크.

MediaWiki 업그레이드는 일반적으로 완전히 자동화되어 사이트 콘텐츠나 템플릿 프로그래밍을 변경할 필요가 없습니다. 역사적으로 상당히 오래된 버전에서 업그레이드할 때 문제가 발생했습니다. ^[141]

보안

MediaWiki 개발자는 핵심 코드와 확장에 대한 보안 표준을 제정했습니다. ^[142] SQL 쿼리 와 HTML 출력은 보통 예방 필터링 핸들 검증 탈출 랩퍼 기능을 통해 수행되는 사이트 간 스크립팅 및 SQL 인젝션 . ^[143] 많은 보안 문제가 MediaWiki 버전 릴리스 이후에 패치되어야 했으며 ^[144] 이에 따라 MediaWiki.org에서는 "가장 중요한 보안 단계는 소프트웨어를 최신 상태로 유지하는 것"이라고 공지를 구독하고 있습니다. listserv 및 발표된 보안 업데이트 설치. ^[145]

개발자 커뮤니티

MediaWiki 개발자는 미국과 유럽에 대다수가 있지만 전 세계에 퍼져 있습니다. 미디어위키 개발자를 위한 대면 회의 및 프로그래밍 세션은 2004년부터 1년에 한 번 또는 여러 번 개최되었습니다. ^[146]

지원

MediaWiki 사용자에 대한 지원은 다음으로 구성됩니다.

• 지원 데스크를 포함한 MediaWiki.org .
• 공식 메일링 리스트, Mediawiki-l .
• 여러 책, 미디어 위키 관리에 대해 기록 된 ^[147] 일부 무료 온라인 도서를 포함하여. ^{[148] [149]}

다른 온라인 협업 소프트웨어와 비교

온라인 협업 소프트웨어 사용자는 Wikipedia에서 잘 사용되기 때문에 MediaWiki의 기능과 레이아웃에 익숙합니다. 다른 위키와 비교할 때 미디어위키는 단순하지만 미학적으로 상당히 만족스럽고 쉽게 사용자 정의할 수 있는 사이드 메뉴와 스타일시트가 있습니다. ^[150] 그러나 2006년 한 평가에서 Confluence 는 매우 유용한 API와 여러 위키를 더 잘 지원할 수 있는 능력으로 인해 우수한 제품으로 간주되었습니다. ^[109] 위키 제공자 소셜 텍스트 와 잣 스팟은 / 있었다 프로젝트 관리는 미디어 위키가 결여되어 있습니다. ^[151]

홍콩 대학에서 TWiki 와 MediaWiki를 비교 하는 연구가 수행되었습니다 . 저자들은 TWiki가 교육 논문 및 기술 프로젝트 개발을 위한 공동 도구로 간주되는 반면 MediaWiki의 가장 주목할만한 사용은 Wikipedia에 있다고 언급했습니다. 두 플랫폼 모두 진행 상황에 대한 토론과 추적을 허용하지만 TWiki에는 MediaWiki에 없는 "보고" 부분이 있습니다. 학생들은 MediaWiki가 TWiki보다 사용하기 쉽고 더 즐겁다고 인식했습니다. 지식경영 과정 그룹 프로젝트에 미디어위키 사용을 권장하느냐는 질문에 응답자 16명 중 15명은 미디어위키를 선호한다고 답해 "당연하다", "확실하다" 등의 답을 내놓았다. ^[152]TWiki와 MediaWiki는 모두 유연한 플러그인 아키텍처를 가지고 있습니다. ^[153]

MediaWiki에 대한 학생들의 경험을 Google 문서에 대한 경험과 비교한 연구에 따르면 학생들은 사용자 친화적인 레이아웃에서 후자에게 훨씬 더 높은 점수를 주었습니다. ^[154]

참조

• 콘텐츠 관리 시스템 목록
• 위키 소프트웨어 목록
• BlueSpice 미디어위키
• 시맨틱 미디어위키
• XOWA  — 오프라인에서 Wikipedia 및 기타 Wiki 보기
• PHP --- 미디어위키를 구동하는 프로그래밍 언어.

참고문헌