매뉴얼:사용자 지정 이름 공간
기존의 이름공간 이외에도 미디어위키에 사용자 정의 이름공간을 추가할 수 있으며, 이를 통해 컨텐츠를 나누는 것, 보다 논리적으로 위키를 구성하는 것이 가능합니다.
사용자 지정 이름 공간은 $wgExtraNamespaces 구성 지침을 사용하여 관리하기 쉽습니다.
$wgNamespaceAliases 설정 지시어를 사용하여 기본 이름공간 또는 사용자 정의 이름공간에 대해 별칭(alias name)을 정의할 수 있습니다.
일부 확장 기능은 사용자 지정 네임스페이스를 쉽게 만들 수 있도록 해줍니다.
예를 들어 NamespaceManager과 BlueSpiceNamespaceManager가 있습니다.
사용자 정의 이름공간 만들기
추가 네임스페이스를 등록하려면 전역 변수 $wgExtraNamespaces에 파일 "LocalSettings.php"를 추가합니다.
모든 이름공간은 이 배열에서 사용될 유일한 숫자 인덱스가 필요합니다.
사용자 정의 네임스페이스를 간단하게 생성하는 예로, 다음 줄을 "LocalSettings.php" 파일에 추가하면 "Foo" 네임스페이스 3000과 관련된 "Foo_talk" 네임스페이스를 정의할 수 있다.
사용자 정의 네임스페이스와 연결된 토론 네임스페이스를 갖는 것은 현재 필수 요구 사항입니다.
// 내가 추가할 이름공간에 대한 상수를 정의합니다.
define("NS_FOO", 3000); // 이 상수는 반드시 짝수여야 합니다.
define("NS_FOO_TALK", 3001); // 이 값은 반드시 따라나오는(following) 홀수여야 합니다. (*역주: 따라나오는 홀수란 짝수 n의 바로 다음 수인 n+1을 말합니다.)
// 이름공간을 추가합니다.
$wgExtraNamespaces[NS_FOO] = "Foo";
$wgExtraNamespaces[NS_FOO_TALK] = "Foo_talk"; // 이름공간 이름의 밑줄에 주목하십시오.
- 사용되지 않은 수를 고르세요
- 관례적으로, 100-199 숫자가 할당된 이름공간은 특수 목적(site-specific) 이름공간으로 예약되어있습니다. 어떤 확장 도구는 이 관례를 따르지 않기도 합니다. 확장 도구 개발자는 32767까지의 큰 수를 사용합니다. 인덱스를 선택할 때는 extension default namespaces에 이미 포함된 숫자를 피해야 합니다. 나중에 확장 기능을 설치할 수 있도록 하기 위해서입니다. 3000에서 4999 사이의 숫자는 시스템 관리자가 사용자 정의 네임 스페이스를 정의하도록 예약되어 있습니다. (Also, you’ll want to avoid any namespace name that’s already in Extension default namespaces.)
- 짝수 다음 홀수
- 위 예제에서 이름공간 배열의 인덱스가 3000인 것에 주목하십시오.
- 짝수 이름공간 인덱스는 주제 이름공간(subject namespace)를 의미합니다.
- 곧바로 따라오는 홀수 인덱스는 이에 연관된 토론 이름공간(discussion ("talk") namespace)을 의미합니다.
- 토론 이름공간도 같이 만드세요
- 일반적으로 토론 "토크" 네임스페이스와 각 사용자 지정 네임스페이스를 함께 만듭니다 이 예제에서 페이지 이동을 "Foo" 네임스페이스로 이동하면 관련된 대화 페이지를 이동하라는 메시지가 표시되며, 이동을 선택하면 MediaWiki가 대화 페이지를 "Foo talk"에 배치합니다.
- 공백 문자를 쓰지 마세요
- 이름공간 이름을 등록할 때는 공백 대신 밑줄을 사용하세요. "My Namespace"는 올바르지 않습니다. "My_Namespace"를 대신 사용하세요.
- 하이픈(-)을 사용하지 마세요
대문자 부분은 단호가 허용되지 않지만 여전히 사전 제목에 안전하게 추가 할 수 있습니다. 예시:
$wgExtraNamespaces[NS_FOOFOO] = "Foo-Foo";
- 선택한 수에 이름을 지으세요
- 이 예제는 네임스페이스 ID에 대해 상수를 정의합니다. 이를 통해 나중에 구성에서 이러한 네임스페이스를 참조할 수 있습니다. 예를 들어,
$wgNamespaceProtection, $NamespaceWithSubpages 또는$wgExtraGenderNamespaces에서 사용할 수 있습니다.
새 이름공간에 대해 추가적인 설정을 계속할 수 있습니다.
$wgNamespaceProtection[NS_FOO] = [ 'editfoo' ]; // foo 이름공간의 문서를 편집하려면 "editfoo" 퍼미션이 필요합니다
$wgNamespacesWithSubpages[NS_FOO] = true; // foo 이름공간에 대해 하위 문서(subpage)를 활성화 합니다.
$wgGroupPermissions['sysop']['editfoo'] = true; // sysop 그룹의 사용자들에 대해 "editfoo" 퍼미션을 인정합니다
- 일찍 하세요
- 미디어위키 초기화 중에
$wgExtraNamespaces의 조작이 완료되어야 합니다. 즉 확장자 등이 새로 생성된 사용자 지정 이름 공간과 작동해야 하는 경우 해당 확장자를 호출하기 전에 정의하고 이름을 지정하는지 확인하십시오. 예를 들어$wgExtensionFunctions와 같은 초기화 후 할크에서 조작할 수 없습니다.
- URL 프로토콜과 충돌을 주의하십시오
- 미디어위키의 링크 코드는 $wgUrlProtocols 변수에 정의된 여러 URL 프로토콜에 대해 알고 있습니다. 네임스페이스 이름이 이러한 프로토콜 중 하나와 동일하다면 사용자 지정 네임스페이스의 페이지에 <nowiki>wikilinks/<nowiki>를 생성하는 데 어려움을 겪을 것입니다. 이것은 일반적으로 누군가가 "뉴스" 네임스페이스를 만들려고 할 때 발생합니다. 왜냐하면
news:는 NNTP 뉴스 그룹의 URL 프로토콜이기 때문입니다. - 이 문제를 방지하려면 다음 코드를 "LocalSettings.php" 파일에 추가하여 관련 URL 프로토콜의 등록을 취소할 수 있습니다(삭제하려는 프로토콜의 소문자 이름으로
news를 대체):
$wgUrlProtocols = array_diff( $wgUrlProtocols, array( 'news:' ) );
확장기능에서
| 미디어위키 버전: | ≥ 1.25 Gerrit change 166705 |
확장자는 종종 Flow 확장자의 "Topic" 이름 공간과 같은 고유의 이름 공간을 추가합니다.
extension.json 등록 시스템에는 네임스페이스를 나열하는 확장을 위한 namespaces 키가 있습니다.
From the Gadgets extension:
"namespaces": [
{
"id": 2300,
"constant": "NS_GADGET",
"name": "Gadget",
"protection": "gadgets-edit"
},
{
"id": 2301,
"constant": "NS_GADGET_TALK",
"name": "Gadget_talk"
},
]
또한, 다른 네임스페이스 관련 설정을 설정할 수 있습니다. 예를 들어, 콘텐츠 네임스페이스로 사용해야 하는지 아닌지를 설정할 수 있으며, 사용 가능한 속성을 위해 Manual:Extension.json/Schema#namespaces을 참조하십시오.
네임스페이스 등록이 조건부인 경우(예: EventLogging은 스키마를 저장하는 위키에서 해당 네임스페이스의 "Schema" 네임스페이스만 정의합니다), 확장자는 네임스페이스 정의에 extension.json의 "conditional": true를 추가하고, 네임스페이스 등록 여부를 결정하는 CanonicalNamespaces 훅에 대한 핸들러도 등록해야 합니다.
후크 핸들러는 호출되는 $namespaces만 변경해야 하며, 네임스페이스의 다른 모든 설정은 여전히 extension.json에 등록되어야 합니다.
이러한 설정도 동적이어야 한다면, CanonicalNamespaces 후크 핸들러에서 $wgContentNamespaces, $wgNamespaceContentModels 등을 변경하지 마세요(효과 없음 – T288819). 대신 콜백($wgExtensionFunctions)와 같이 더 일찍 설정해야 합니다.
LocalSettings.php에 확장을 추가한다고 해서 반드시 관련 네임스페이스 상수를 다른 확장을 위한 전역으로 사용할 수 있는 것은 아닙니다.
Content namespaces
사이트 통계 페이지를 구축할 때(Special:Statistics 참조), MediaWiki는 데이터베이스에 저장된 값을 사용하여 특정 합계를 계산합니다. 특정 총합 중 하나는 "기사 수" 또는 "콘텐츠 페이지 수" 수치입니다.
페이지가 기사나 적절한 내용으로 간주되기 위해서는 다음을 해야 합니다.
추가 콘텐츠를 저장하기 위해 사용자 지정 이름 공간을 만들 때, 구성에서 이것을 표시하는 것이 좋습니다. 이것은 $wgContentNamespaces 구성 지침을 통해 이루어집니다.
위의 예제를 확장하려면 "LocalSettings.php" 파일에 다음을 추가할 수 있습니다.
$wgContentNamespaces[] = 3000;
- or
$wgContentNamespaces[] = NS_FOO;
MediaWiki는 이제 "Foo" 네임스페이스의 페이지가 나머지 기준을 충족하면 articles로 간주하고 사이트 통계 카운터를 업데이트할 때 이를 포함할 것입니다.
유지관리 스크립트
구성 매개변수 $wgContentNamespaces의 값을 조정할 때는 내부 통계 캐시를 업데이트하기 위해 "path/to/maintenance/updateArticleCount.php 또는 "path/to/maintenance/initSiteStats.php" 스크립트를 실행하는 것이 좋습니다(메뉴얼:유지보수 스크립트 참조).
Why you would want a custom namespace
이 일을 하는 데 몇 가지 이유가 있습니다.
- A custom namespace can be used to hold content that should not be shown on the search results page, for example pages that are used only for transclusion.
- 특정 이름 공간은 편집에 추가 권한 (이) 를 요구합니다.
- You want certain namespaces not to be subjected to certain limitations or default settings ($wgNoFollowNsExceptions for example)
- 특정 내용 (들) 에 대한 일정한 사전자료, 그 이름 공간에서만 검색할 수 있습니다
- MW(Midiawiki?) 개발자라면 확장 프로그램을 위한 사용자 지정 [Special:MyLanguage/Extension default namespaces|이름공간]이 필요할 때가 있습니다
Dealing with existing pages
페이지 레코드를 저장할 때, MediaWiki는 네임스페이스의 숫자 인덱스와 나머지 제목 텍스트를 사용합니다. 따라서, 페이지가 존재하지 않는 네임스페이스에서 생성될 때, 예를 들어 "Bar:Some page"는 주요 네임스페이지에 있는 것처럼 취급됩니다.
이것은 나중에 "Bar"에 대한 사용자 지정 네임스페이스 정의를 추가하면 문제가 발생할 수 있습니다. 미디어 위키는 적절한 네임스페이스를 통해 지표를 표시한 페이지를 찾을 수 있지만 찾을 수 없습니다. 따라서 콘텐츠가 접근성이 떨어집니다.
You can use the NamespaceDupes maintenance script to correct this problem.
본 이름 공간에서 정의된 이름 공간에 해당하는 사전과 함께 페이지들을 찾아서 그 기록을 업데이트합니다.
If you are not able to run maintenance scripts, then the following approach might be suitable:
- Comment out the namespace definition in the configuration file
- Access each affected page (use Special:PrefixIndex on your wiki to find them), and move it out of the pseudo-namespace, e.g. move "Bar:Some page" to "Bar2:Some page"
- Un-comment the namespace definition
- Move the affected pages back into the new namespace
Removing custom namespaces
The problem addressed above also occurs when a custom namespace definition is removed; MediaWiki is no longer aware of the numerical index for the namespace, and attempts to search the main namespace for the desired pages, leading to inaccessible content. This is a rare occurrence, since most sites will not need namespaces removed, but it is a problem.
| 미디어위키 버전: | ≥ 1.43 Gerrit change 1052196 |
You can use the CleanupTitles maintenance script to correct this problem.
It will find pages any namespace that is no longer defined, and update their records.
The pages will be moved to the main namespace with an added prefix like NS123:, unless specified otherwise by parameters to the script.
As above, you can also temporarily restore the namespace configuration and move the pages from the user interface (or delete them).
Renaming custom namespaces
Suppose that you need to rename custom namespace "Foo" to "New" without performing a mass move of pages.
The easiest way to achieve this is to preserve the namespace ID (here "3000") as well as the namespace constant (here "NS_FOO"), modify the (visible) namespace title and add the old one as an alias.
변경
Note that some extensions store namespace names in plain text instead of their internal IDs, and should therefore be dealt with extra care. Examples include:
- The Translate extension creates pages with the source page's name (containing the namespace prefix) under the Translations namespace, e.g. Translations:Manual:Using custom namespaces/117/es for the Spanish translation of the 117th message on this page. When you change the namespace's name, translatable pages should be handled as if they were moved.
Avoid namespace conflicts
In order for you to avoid namespace conflicts e.g. your namespace has the same number as a namespace defined by an extension, the extension namespace list shows you which numbers to avoid to prevent conflicts.
Defining $wgNamespacesToBeSearchedDefault, $wgNamespacesWithSubpages, $wgContentNamespaces or $wgNamespaceAliases for an ID not associated to any existing namespace in $wgExtraNamespaces doesn't break the wiki; MediaWiki gracefully ignores such configurations.
Styling namespaces
The simplest way of setting the background color of pages in a particular namespace (and its associated talk namespace) is by adding the following code to your common.css:
.ns-3000 #content, .ns-3001 #content { background-color: #f3f3ff; }
.ns-3000 div.thumb, .ns-3001 div.thumb { border-color: #f3f3ff; }
where 3000 is the namespace's index and #f3f3ff is the color you want as its background color.
However, unless your needs are very basic you will probably want to support night mode as it is expected by modern standards, and avoid accessibility problems derived from using fixed colors.
See Recommendations for night mode compatibility on Wikimedia wikis for details.
You might also want to change the name of the tab from its default (the namespace's name). This is located in your system messages at MediaWiki:nstab-namespace.
같이 보기
- 메뉴얼:이름공간
- Namespace manager – as originally proposed for MW1.6-wikidata and its successors. Currently in use by the OmegaWiki project.
Site administration
Extensions
- Category:Namespace extensions
- Extension:NamespaceManager – for management of namespaces
- Extension:BlueSpiceNamespaceManager – lets you create custom namespaces
- Extension:SpecialNamespaces – a modified version of the 확장기능:인터위키 which changes it to provide a namespace manager as a special page.
- Extension:Lockdown – to control access to namespaces
For extension developers
- Extension namespace registration – List of custom namespaces registered by extensions. If you define a constant for a custom namespace, list it here, too.