현재 번역은 완벽하지 않습니다. 한국어로 문서 번역에 동참해주세요.

문서 태그는 방문자에게 유용한 컨텐츠를 제공하는 중요한 방법입니다. 각 페이지에는 컨텐츠가 정리될 수 있도록 보통 몇 개씩 태그가 있습니다. 이 페이지는 독자들이 정보를 찾고 체계적으로 유지시키기 위해 필요한 페이지 태그를 하는 가장 좋은 방법을 설명합니다.

태그 편집하는 사용자 인터페이스에 대한 도움이 필요하시면, 저희의 편집 가이드의 태그 섹션을 참고하세요.

아래 설명대로 태그를 적절히 사용하세요. 그렇지 않으면, 저희의 자동 시스템이 컨텐츠, 방문 페이지, URL링크의 목록을 정확히 생성하지 못 합니다.

MDN이 태그를 사용하는 방법

태그는 MDN에서 여러가지 방법으로 사용됩니다:

문서 분류
어떤 종류의 문서일까요? 레퍼런스? 튜토리얼? 방문 페이지? 방문자는 태그를 사용해 검색을 필터링 할 수 있으므로 매우 중요합니다.
항목 식별
무엇에 관한 글입니까? API에 관한 글인가요? DOM? 그래픽? 다시 말해, 태그를 통해 검색을 필터링 할 수 있으므로 태그는 중요합니다.
API 식별
API에 관한 레퍼런스 페이지는 문서화된 API의 특정 구성요소를 식별할 수 있어야 합니다.(즉, 어떤 인터페이스인지, 그리고 해당되는 경우에 페이지가 다루는 속성이나 방법).
기술 현황
이 기술은 어떤가요? 비표준인가요? 더 이상 사용되지 않나요? 실험 단계인가요?
기술 수준
튜토리얼이나 가이드의 경우, 이 글이 다루는 내용이 얼마나 전문적인가요?
문서 메타데이터
글쓰기 커뮤니티는 태그를 사용하여 어떤 페이지에 어떤 작업이 필요한지 추적합니다.

태그 유형별 가이드

다음은 태그 유형 및 가능한 값에 대한 빠른 가이드입니다.

문서 카테고리

여기에 있는 카테고리들로 글을 태그하면, 자동화 시스템이 방문 페이지, 목차 등을 좀 더 정확하게 생성할 수 있습니다. 저희의 새로운 검색 시스템은 이런 용어들을 사용해서 방문자들이 레퍼런스나 가이드 정보를 찾을 수 있을 겁니다.

다음과 같은 카테고리 이름을 표준 태그 용어로 사용하고 있습니다:

이 글은 주제에 관한 입문 자료를 제공합니다. 이상적으로는 각 기술 영역에는 오직 하나의 "인트로"가 있어야 합니다.

이 글에는 API, 요소(Element), 속성 등에 관한 참조 자료가 포함되어 있습니다.
이 페이지는 방문한 페이지입니다.
이 글은 어떻게 하는지 알려주는 가이드 페이지입니다.
이 글을 코드 샘플 페이지이거나, 코드 샘플을 포함하고 있습니다.(즉, 한 줄짜리 "구문 예제"가 아닌 실제 유용한 코드 조각).

주제

주제 범위를 식별해서, 더 나은 검색 결과를 생성하는데 도움을 줍니다(또한 방문한 페이지와 네비게이션에도 도움을 줍니다).

새로운 주제 영역을 식별할 때 유연성을 위한 여지가 있긴 하지만, 저희는 API나 기술의 이름을 제한하려고 합니다. 예를 들어 이렇게 있습니다:

대체로, your topic identification tag should be the name of an interface with a number of related pages (like Node, which has many pages for its various properties and methods), or the name of an overall technology type. You might tag a page about WebGL with Graphics and WebGL, for example, but a page about <canvas> with HTML, Element, Canvas, and Graphics.

모질라-관련-컨텐츠

이 태그들은 단 모질라 관련 컨텐츠에 사용됩니다:

API 식별

Within the API reference, each article should identify which part of the API it covers:

The main article for an interface should have this tag. For example, RTCPeerConnection.
Each interface may have up to one page tagged "Constructor"; this is the interface's constructor. The page should have the same name as the interface, like RTCPeerConnection.RTCPeerConnection().
Every article describing a particular property within an interface needs this tag. See RTCPeerConnection.connectionState, for example.
Each article documenting an interface method needs this tag. See RTCPeerConnection.createOffer() for example.

In addition, the reference pages need to include interface, property, and method names among their tags. Some examples:

The interface RTCPeerConnection
Include the tag "RTCPeerConnection" along with the other relevant tags ("Interface", "WebRTC", "WebRTC API", "API", "Reference", and so forth).
The method RTCPeerConnection.createOffer()
Include the tags "RTCPeerConnection" and "createOffer" (note no parentheses in tag names!) along with the other relevant tags, including "WebRTC", "WebRTC API", "API", "Reference", and so forth. Consider including things like "Offer" and "SDP", which are also relevant here.
The property RTCPeerConnection.iceConnectionState
Include the tags "RTCPeerConnection" and "iceConnectionState" along with the other relevant tags, including "WebRTC", "WebRTC API", "API" and "Reference". Also consider including "ICE".

Technology status

To help the reader understand how viable a technology is, we use tags to label pages as to the status of the technology's specification. This isn't as detailed as actually explaining what the spec is and how far the technology has come in the specification process (that's what the Specifications table is for), but it helps the reader judge, at a glance, whether it's a good idea to use the technology described in the article.

Here are possible values for these tags:

Apply this tag to reference pages which describe a property or attribute which is read-only.
Indicates that the technology or API described on the page is not part of a standard, whether it's stable or not in any browsers which implement it (if it's not stable, it should also be ). If you don't use this tag, your readers will assume the technology is standard. The compatibility table on the page should clarify which browser(s) support this technology or API.
The technology or API covered on the page is marked as deprecated in the specification, and is likely to eventually be removed, but is generally still available in current versions of browsers.
The technology or API has been deemed obsolete and has been removed (or is actively being removed) from all or most current browsers.
The technology is not standardized, and is an experimental technology or API that may or may not ever become part of a standard. It is also subject to change in the browser engine (typically only one) that implements it. If the technology isn't part of any specification (even in draft form), it should also have the tag.
The API requires privileged access to the device on which the code is running.
The API only works in certified code.

These tags are no excuse to leave out the compatibility table in your article! That should always be present.

Skill level

Use the skill-level tag type only for guides and tutorials (that is, pages tagged Guide) to help users choose tutorials based on how familiar they are with a technology. There are three values for this:

Articles designed to introduce the reader to a technology they've never used or have only a passing familiarity with.
Articles for users who have gotten started with the technology but aren't experts.
Articles about stretching the capabilities of a technology and of the reader.

문서 메타데이터

The writing community uses tags to label articles as requiring specific types of work. Here's a list of the ones we use most:

The article is not complete, and is at least in theory still actively being updated (although it's also possible it's been forgotten about). Try to check with the most recent contributors before making changes, in order to avoid potential content collisions.
The article is a stub, or is otherwise lacking information. This tag means that someone should review the content and add more details and/or finish writing the article.
The article needs one or more examples created to help illustrate the article's point. These examples should use the live sample system.
The article has one or more examples that need to be updated to use the live sample system.
The content is out of date and needs to be updated.
The content is not really worth localizing and will not appear on localization status pages.
The content is important and should be marked as a priority for MDN translators. Shows up in an extra priority table on localization status pages.

Putting it all together

So to each page you assign tags from several tag types, for example

A tutorial about WebGL for beginners
WebGL, Graphics, Guide, Beginner
Reference page for <canvas>
Canvas, HTML, Element, Graphics, Reference
A landing page for Firefox OS developer tools
Tools, Firefox OS, Landing

태그 추가 및 검색 필터

Search filters won't work properly unless we tag MDN pages properly. Here's a table of search filters and which tags they look for.

Note: If multiple tags are listed under "Tag name," that means any one or more of these tags must be present for the article to match.

필터
그룹
검색명 태그명
주제 Open Web Apps
  HTML
  CSS
  JavaScript
  APIs and DOM
  Canvas
  SVG
  MathML
  WebGL
  XUL
  Marketplace
  Firefox
  안드로이드 용 Firefox
  데스크탑 용Firefox
  Firefox 운영체제
  모바일
  웹 개발
 

에드온 &
확장프로그램

|| || ||
  게임
기술
수준
전문가입니다
  중급자입니다
  초급자입니다

문서 
형식

문서 This restricts the search to docs content, leaving out Hacks and other MDN content.
  체험판 This includes Demo Studio content in the search results.
  도구
  코드 샘플
  튜토리얼
  개발자
프로필
This includes developer profiles from the MDN site in the search results.
  외부
리소스
The dev team is still figuring this out...

해결할 수 있는 태그 추가 문제

해결할 수 있는 여러 종류의 태그 추가 문제가 있습니다:

태그 없음
Generally articles should have at least a "category" tag and a "topic" tag. Usually other tags are appropriate as well, but if you can help us ensure that the minimum tags are present, you'll be a documentation hero!
표준을 따르지 않은 태그
Please fix any documents whose tags don't follow the standards on this page.
Note that you may occasionally see some localized tags (such as Référence) showing up on some English pages. This was due to a bug in Kuma, which caused the tags to reappear even if they were deleted. That bug has since been fixed, so any remaining localized tags can be cleaned up if they're spotted.
올바르지 않은 태그
If you're looking at an article about HTML and it's tagged "JavaScript", that's probably wrong! Likewise, if an article discusses Mozilla internals but has a "Web" tag, that's probably wrong too. Remove these tags and add the right tags if they aren't already there. Please also correct misspelled tags (e.g., "Javascript" will still match, since tags are case-insensitive, but let's not be sloppy!).
누락된 태그
If an article has some but not all of the tags it needs, feel free to add more. For example, if a page in JavaScript reference is (correctly) tagged "JavaScript" but nothing else, you're invited to tag the page "Reference" as well!
Tag spam
This insidious beast is the most revolting tag problem of all: some Web vermin has deposited its droppings in the page tags (like "Free warez!" or "Hey I was browsing your site and wanted to ask you if you could help me solve this problem I'm having with Flash crashing all the time"). We've got to delete these right away! They're ugly, they're hard to manage if they're allowed to linger too long, and they're terrible for SEO.

If you see one (or more) of these problems, please log into MDN and click EDIT at the top right of the MDN window. Once the editor loads up, scroll down to the bottom of the page, where you'll see the tag box. For more details on the tagging interface, see "The tags box" in the MDN editor guide.

문서 태그 및 공헌자

 이 페이지의 공헌자: plzfday
 최종 변경: plzfday,