From ee778d6eea54935fd05022e0ba8c49456003381a Mon Sep 17 00:00:00 2001 From: Florian Merz Date: Thu, 11 Feb 2021 14:48:24 +0100 Subject: unslug ko: move --- files/ko/mdn/about/mdn_services/index.html | 15 - files/ko/mdn/at_ten/index.html | 43 ++ files/ko/mdn/community/conversations/index.html | 63 -- files/ko/mdn/community/index.html | 46 -- .../mdn/community/working_in_community/index.html | 110 --- .../creating_and_editing_pages/index.html | 166 ---- .../ko/mdn/contribute/does_this_belong/index.html | 139 ---- .../convert_code_samples_to_be_live/index.html | 39 + .../howto/create_and_edit_pages/index.html | 166 ++++ .../howto/do_a_technical_review/index.html | 41 - .../howto/do_an_editorial_review/index.html | 48 -- .../index.html" | 32 - .../howto/set_the_summary_for_a_page/index.html | 53 -- .../howto/tag_javascript_pages/index.html | 69 -- .../write_an_api_reference/sidebars/index.html | 114 +++ .../index.html | 108 --- .../index.html" | 39 - files/ko/mdn/editor/index.html | 19 - files/ko/mdn/editor/links/index.html | 181 ----- files/ko/mdn/guidelines/best_practices/index.html | 34 - .../code_guidelines/code_guidelines/index.html | 159 ---- .../guidelines/code_guidelines/general/index.html | 159 ++++ .../guidelines/conventions_definitions/index.html | 34 + .../guidelines/does_this_belong_on_mdn/index.html | 139 ++++ files/ko/mdn/guidelines/style_guide/index.html | 833 --------------------- .../mdn/guidelines/writing_style_guide/index.html | 833 +++++++++++++++++++++ files/ko/mdn/kuma/index.html | 26 - .../api_reference_sidebars/index.html | 114 --- files/ko/mdn/structures/api_references/index.html | 58 -- .../index.html" | 34 - files/ko/mdn/user_guide/index.html | 12 - files/ko/mdn/yari/index.html | 26 + 32 files changed, 1553 insertions(+), 2399 deletions(-) delete mode 100644 files/ko/mdn/about/mdn_services/index.html create mode 100644 files/ko/mdn/at_ten/index.html delete mode 100644 files/ko/mdn/community/conversations/index.html delete mode 100644 files/ko/mdn/community/index.html delete mode 100644 files/ko/mdn/community/working_in_community/index.html delete mode 100644 files/ko/mdn/contribute/creating_and_editing_pages/index.html delete mode 100644 files/ko/mdn/contribute/does_this_belong/index.html create mode 100644 files/ko/mdn/contribute/howto/convert_code_samples_to_be_live/index.html create mode 100644 files/ko/mdn/contribute/howto/create_and_edit_pages/index.html delete mode 100644 files/ko/mdn/contribute/howto/do_a_technical_review/index.html delete mode 100644 files/ko/mdn/contribute/howto/do_an_editorial_review/index.html delete mode 100644 "files/ko/mdn/contribute/howto/mdn_\352\263\204\354\240\225_\354\203\235\354\204\261\355\225\230\352\270\260/index.html" delete mode 100644 files/ko/mdn/contribute/howto/set_the_summary_for_a_page/index.html delete mode 100644 files/ko/mdn/contribute/howto/tag_javascript_pages/index.html create mode 100644 files/ko/mdn/contribute/howto/write_an_api_reference/sidebars/index.html delete mode 100644 files/ko/mdn/contribute/howto/write_an_article_to_help_learn_about_the_web/index.html delete mode 100644 "files/ko/mdn/contribute/howto/\354\202\264\354\225\204\354\236\210\353\212\224_\354\275\224\353\223\234_\354\203\230\355\224\214\353\241\234_\353\263\200\355\231\230\355\225\230\352\270\260/index.html" delete mode 100644 files/ko/mdn/editor/index.html delete mode 100644 files/ko/mdn/editor/links/index.html delete mode 100644 files/ko/mdn/guidelines/best_practices/index.html delete mode 100644 files/ko/mdn/guidelines/code_guidelines/code_guidelines/index.html create mode 100644 files/ko/mdn/guidelines/code_guidelines/general/index.html create mode 100644 files/ko/mdn/guidelines/conventions_definitions/index.html create mode 100644 files/ko/mdn/guidelines/does_this_belong_on_mdn/index.html delete mode 100644 files/ko/mdn/guidelines/style_guide/index.html create mode 100644 files/ko/mdn/guidelines/writing_style_guide/index.html delete mode 100644 files/ko/mdn/kuma/index.html delete mode 100644 files/ko/mdn/structures/api_references/api_reference_sidebars/index.html delete mode 100644 files/ko/mdn/structures/api_references/index.html delete mode 100644 "files/ko/mdn/tools/\355\216\230\354\235\264\354\247\200_\354\236\254\354\203\235\354\204\261/index.html" delete mode 100644 files/ko/mdn/user_guide/index.html create mode 100644 files/ko/mdn/yari/index.html (limited to 'files/ko/mdn') diff --git a/files/ko/mdn/about/mdn_services/index.html b/files/ko/mdn/about/mdn_services/index.html deleted file mode 100644 index 1d04e3d468..0000000000 --- a/files/ko/mdn/about/mdn_services/index.html +++ /dev/null @@ -1,15 +0,0 @@ ---- -title: MDN Services -slug: MDN/About/MDN_services -tags: - - Landing - - MDN Meta -translation_of: MDN/About/MDN_services ---- -
{{MDNSidebar}}
- -

MDN 서비스는 기존 워크플로우에 적합하고 개발자가 웹 코드를 개선할 수 있도록 설계된 웹 개개발자를 위한 실험적 유틸리티입니다. 모든 MDN 서비스는 개발 초기 알파 단계에 있으므로, 아직 코드 품질 보장에 의존하지 않는 것이 좋습니다. 만약 프로토타입으로 실험하고 싶다면, 아래의 서비스들은 실험할 준비가 되어있으며, 우리는 그것에 대해 당신의 피드백을 받고 싶습니다.

- -

웹 호환성 서비스 ("Discord")

- -

Discord는 당신의 코드에서 호환성 문제를 포착하기 위한 GitHub webhook 입니다. 현재 CSS 코드를 doiuse로 스캔하고 GitHub의 코드 커밋에 주석을 추가합니다.

diff --git a/files/ko/mdn/at_ten/index.html b/files/ko/mdn/at_ten/index.html new file mode 100644 index 0000000000..d4883ca7cd --- /dev/null +++ b/files/ko/mdn/at_ten/index.html @@ -0,0 +1,43 @@ +--- +title: MDN at 10 +slug: MDN_at_ten +tags: + - MDN + - MDN 메타 + - MDN 변천 + - 역사 + - 출발 +translation_of: MDN_at_ten +--- + + +
+
+

MDN의 역사

+ +

2005년, 이상주의자들로 이루어진 작은 팀은 웹 개발자들을 위한 새롭고 무료이며 협력으로 만들어진 온라인 리소스를 만들었습니다. 그들의 뛰어난, 그러나 색다른 아이디어는 오늘날의 오픈 웹 기술자들을 위한 최고의 리소스인 Mozilla 개발자 네트워크로 성장되었습니다. 10년뒤, 우리의 세계적 커뮤니티는 역대 최고이며, 우리는 여전히 함께 문서를 만들고 코드를 작성하며 오픈 웹을 현재와 같이 강력하게 만들어주는 CSS, HTML, 자바스크립트 등과 같은 오픈 웹 기술자들을 위한 리소스들을 배웁니다.

+ +

더 알아보기about the history

+ + +

MDN에 공헌하기

+ +

10년동안 MDN 커뮤니티는 오픈 웹을 기록해왔습니다. 간단한 오탈자 수정에서부터 새로운 API의 전체를 작성하는 것까지, 모두가 무언가를 제공했고, 어떠한 기여도 적지 않았습니다. 우리는 Mozillians의 뛰어난 맴버들이 작성하거나 번역한 9만 페이지 이상의 자료들이 있습니다. 당신도 그중 하나가 될 수 있습니다.

+ +

더 알아보기about contributing

+ +

 

+ +

 

+
+ +
{{TenthCampaignQuote}}
+ +

추가정보

+ +
    +
  1. MDN 10주년
    2. +
  2. MDN의 역사
    3. +
  3. MDN에 기여하기
    4. +
+
diff --git a/files/ko/mdn/community/conversations/index.html b/files/ko/mdn/community/conversations/index.html deleted file mode 100644 index 9d41e6c30c..0000000000 --- a/files/ko/mdn/community/conversations/index.html +++ /dev/null @@ -1,63 +0,0 @@ ---- -title: MDN community conversations -slug: MDN/Community/Conversations -tags: - - Community - - Guide - - MDN Meta -translation_of: MDN/Community/Conversations ---- -
{{MDNSidebar}}
- -

MDN "활동"은 MDN 웹사이트에서 발생하지만, "커뮤니티"는 별도의 온라인 토론과 채팅으로 발생합니다.

- -

비동기적 토론

- -

정보를 공유하고 토론을 계속하기 위해, MDN은 Mozilla Discourse 포럼에 자체 카테고리("MDN")를 가지고 있습니다. 문서 생성-번역-유지관리, MDN 플랫폼 개발, 미래계획, 목표설정, 진행상황 추적 등 MDN과 관련된 모든 글을 MDN 카테고리로 작성할 수 있습니다.

- - - -

보존용 기록

- -

2017년 6월 이전에는 MDN 관련 토론이 Google 그룹과 함께 게이트웨이되고 보관 된 메일 링리스트에서 진행되었습니다. 이전 토론을 검색하려면 이전 메일 링리스트에 해당하는 Google 그룹을 살펴보십시오. (예, 우리는이 이름들이 겹쳐지고 혼동을 일으킨다는 것을 알고 있습니다. 역사적인 사고입니다. 죄송합니다.)

- -
-
mozilla.dev.mdc a.k.a dev-mdc
-
이 목록은 MDN의 문서 내용에 대한 토론 용이었습니다.
-
mozilla.dev.mdn a.k.a dev-mdn
-
이 목록은 MDN의 기본 Kuma 플랫폼 개발 작업에 관한 것입니다.
-
mozilla.mdn a.k.a mdn@
-
이 포럼은 MDN 웹 사이트 및 기타 관련 이니셔티브를위한 높은 수준의 계획 및 우선 순위 토론을위한 것입니다.
-
- -

IRC 채팅하기

- -

IRC(Internet Relay Chat)는 커뮤니티 멤버들끼리 매일 채팅하고 실시간으로 토론하기 위한 방법으로 선호됩니다. 저희는 MDN에 관련된 토론을 위해 irc.mozilla.org 서버에 있는 몇 가지 채널을 사용합니다.

- -
-
#mdn
-
이 채널은 MDN 콘텐츠에 대해 토론하기 위한 기본적인 채널입니다. 저희는 작성, 콘텐츠 구성 등등에 대해 얘기합니다. 또한 저희는 여기서 "water cooler" 대화를 가집니다. 이는 저희의 커뮤니티가 연락을 유지하고 어울리기 위한 방법입니다. 또한 이는 데모 스튜디오, 프로필 등과 같이 MDN의 다른 측면(플래폼 개발이 아닌 부분)에 대해 토론하는 곳입니다.
-
 
-
#mdndev
-
이 채널은 우리의 개발 팀 - MDN이 작동하도록 코드를 작성하는 사람들 - 이 어울리고 그들의 일과를 토론하기 위한 곳입니다. 당신이 이 채널에 합류하고 개발에 참여하거나 혹은 단순히 당신이 소프트웨어에 대한 이슈에 관해 질문을 하는 것을 환영합니다.
-
- -

이 채널들은 대부분 북미 지역에서 주중에 활발합니다.

- -

당신은 IRC에 대해서 좀 더 알고 싶어하고, ChatZilla와 같은 설치형 IRC 클라이언트를 사용하고 싶어 할 것입니다. 이는 쉽고 빠르게 설치하고 사용할 수 있는 Firefox add-on에서 실행될 수 있습니다. 만약 IRC에 익숙하지 않다면, 참여하기 쉬운 방법에는 미리 mdn과 mdndev 채널들에 맞추어 설계된 mibit과 같은 웹기반 IRC 클라이언트를 사용하는 것이 있습니다. 

- -

회의 (및 기타 행사)에 참가

- -

MDN 팀은 MDN 커뮤니티에 열려있는 여러 정기 모임을 개최합니다. 일정, 의제 및 메모, 참여 방법에 대한 자세한 내용은 Mozilla wiki의 MDN Meetings 페이지를 참조하십시오.

- -

이 회의 및 기타 회의, 지역 회의 및 기타 행사에 대한 MDN 이벤트 달력을보십시오. 되풀이 모임은 MDN Meetings wiki 페이지에 요약되어 있습니다.

- -

 

- -

If you see a meeting which takes place in the "mdn" channel on our Vidyo videoconferencing system, you can join the conversation on the web.

- -

 

diff --git a/files/ko/mdn/community/index.html b/files/ko/mdn/community/index.html deleted file mode 100644 index faff8c5f2e..0000000000 --- a/files/ko/mdn/community/index.html +++ /dev/null @@ -1,46 +0,0 @@ ---- -title: MDN 커뮤니티 참여하기 -slug: MDN/Community -tags: - - Community - - Guide - - Landing - - MDN Meta -translation_of: MDN/Community ---- -
{{MDNSidebar}}
- -
{{IncludeSubnav("/ko/docs/MDN")}}
- -
-

MDN 웹 문서는 위키 그 이상입니다. MDN은 공개 웹 기술을 사용하는 개발자들을 위해 뛰어난 자료를 만드는 사람들이 함께 작업하는 커뮤니티입니다.

-
- -

당신이 MDN에 기여하시는 것도 물론 좋지만, 더 나아가 공식 커뮤니티에 참여하시면 정말 기쁘겠습니다. 참여하시는 방법은 다음 세 단계면 됩니다. 

- -
    -
  1. 먼저 MDN 계정 생성을 만들고
    2. -
  2. 토론에 참여하고
    3. -
  3. 어떤 일이 일어나는지 지켜보세요.
    4. -
- -

커뮤니티가 돌아가는 방법

- -

MDN 커뮤니티를 더 자세히 설명하는 글입니다.

- -
-
-
커뮤니티의 역할
-
MDN 커뮤니티에는 특정 책임이 주어진 몇가지 역할들이 있습니다. 
-
문서화 스프린트
-
문서화 스프린트 운영 가이드입니다. 스프린트를 운영해온 사람들의 유익한 조언과 팁이 포함되어있습니다. 
-
어떤일이 일어나는지 지켜보기 
-
MDN은 Mozilla Developer Network community가 제공합니다. 하고있는 일에 대한 정보를 공유하는 몇가지 방법을 소개합니다. 
-
MDN 커뮤니티의 토론
-
MDN의 "작업"은 MDN 사이트에서 하지만, "소통"은 (비동기)  토론과 (실시간) 온라인 채팅을 통해 일어납니다.
-
커뮤니티에서 작업하기
-
규모와 관계 없이 MDN 문서 기여시 반드시 알아야 할 것은  MDN 커뮤니티의 일원으로 어떻게 일할는지를 아는 것입니다. 이 글은 다른 글쓴이, 기술팀과 상호작용을 어떻게 잘 할 수 있는지를 알려줍니다. 
-
-
-
-
diff --git a/files/ko/mdn/community/working_in_community/index.html b/files/ko/mdn/community/working_in_community/index.html deleted file mode 100644 index 0398e29823..0000000000 --- a/files/ko/mdn/community/working_in_community/index.html +++ /dev/null @@ -1,110 +0,0 @@ ---- -title: 커뮤니티에서의 활동 -slug: MDN/Community/Working_in_community -translation_of: MDN/Community/Working_in_community ---- -
{{MDNSidebar}}
- -

A major part of contributing to MDN documentation on any significant scale is knowing how to work as part of the MDN community. This article offers tips to help you make the most of your interactions with both other writers and with development teams.

- -

에티켓 가이드라인

- -

Mozilla 커뮤니티와 함께 일하면서 지켜주셨으면 하는 사항들입니다.

- - - -

Be tactful

- -

Always be tactful and respectful when communicating with others.

- -

Politely pointing out mistakes

- -

If your purpose in contacting someone is to ask them to do something differently, or to point out a mistake they've been making (especially if they repeatedly do it), start your message with a positive comment. This softens the blow, so to speak, and it demonstrates that you're trying to be helpful, rather than setting you up as the bad guy.

- -

For example, if a new contributor has been creating lots of pages without tags, and you'd like to point out this problem, your message to them might look like this (the stuff you'd need to change for each case is underlined):

- -
-

안녕하세요 홍길동씨, 웜홀 API 문서 에 대한 홍길동씨의 기여에 대해 감사드립니다. 저는 특히 홍길동씨께서 가독성과 세부정보를 균형있게 서술한 점을 인상깊게 보았습니다. 아마도 작업하시면서 correct tag를 페이지마다 추가해주신다면 이 문서를 더 유익하고 잘 만들어 나갈 수 있을 것 같습니다.

- -

자세한 사항은 MDN 태그가이드를 이용해 주세요(https://developer.mozilla.org/en-US/docs/MDN/Contribute/Howto/Tag)

- -

다시 한번 감사를 드리며 앞으로의 기여활동도 기대하겠습니다!

-
- -

지식 공유

- -

MDN 프로젝트에 참여하면서 무슨 일들이 일어나는지 파악하고 다른 멤버들과 소통하는 것이 본인에게 도움이 됩니다. 커뮤니티 내의 다른 분들과 소통하므로 아이디어를 얻거나 공유할 수 있습니다. 우리는 누가 주체가 되어 무슨 일을 진행하는지 알 수 있는 도구들과 리소스들을 제공하고 있습니다.

- -

Communication channels

- -

There are several ways you can engage with community members (either developers or writers), each of which has some of its own particular rules of etiquette.

- -

Discourse

- -

The MDN Discourse forum is a good place to ask general questions about MDN contribution and start discussions.

- -

Chat

- -

Use the Matrix chat system to reach people in real time. MDN staff members are available in the MDN Web Docs room, and are active during work days in Europe and North America. Explore the other chat rooms to find people involved in topics you're interested in.

- -

GitHub

- -

If you find a problem on MDN, or want to ask a question, you can file an issue over on our GitHub sprints repo issues! They will then be triaged and actioned at some point in the future.

- -

Email

- -

Sometimes, a private email exchange between you and one or more other people is the way to go, if you have their email address.

- -
-

Note: As a general rule, if someone has posted their email address on documents about the technology you're documenting, has given you their email address personally, or generally has a well-known email address, email is an acceptable "first contact" approach. If you have to dig for it, you probably should try to get permission Discourse or a mailing list first, unless you've exhausted all other attempts at getting in touch.

-
- -

Content status tools

- -

We have several useful tools that provide information about the status of documentation content.

- -
-
Revision dashboard
-
The revision dashboard provides a fantastic tool to review changes made to MDN content. You can see recent history, choose a range of time to view, and filter based on things like locale, contributor's name, and topic. Once you're looking at a set of revisions, you can view the changes made in each revision, quickly open the page, see a full history, or even revert the changes (if you have those privileges).
-
Documentation status overview
-
Our documentation status overview page provides a list of all the areas of MDN that have been configured for status tracking, with information about how many pages therein need different types of work done. Click through to a particular topic area to see detailed lists of content that needs work, such as pages that have no tags, or are tagged with indicators that certain types of work need to be done. You can even see lists of pages that haven't been updated in a long time and may be out of date, as well as a list of bugs that have been flagged as impacting the documentation in that area.
-
Documentation project plans
-
We have a number of writing projects that are in the planning stages, or are large and ongoing, for which we have written planning documents to help us keep track of what we need to get done.
-
MDN Taiga
-
The MDN staff writers use a tool called Taiga to manage current and future documentation projects. You can take a look to see what we're doing and how it's going, and you can see what projects we'd like to see happen soon. Some of those will be taken on by staff writers, but you should feel free to take one over if you like! For more information about the agile processes followed by the MDN team, see our Process page on the Mozilla wiki.
-
- -

The development community

- -

Possibly the most important relationships to develop and maintain, as a member of the MDN writing community, are those you develop and sustain with the developers. They create the software we're developing, but they're also the most useful source of information we have. It's crucial that we maintain good relations with developers—the more they like you, the more likely they are to answer your questions quickly, accurately, and thoroughly!

- -

In addition, you represent the MDN writing community. Please help ensure we keep our excellent working relationship with the dev team by making every interaction they have with the writing team be a good one.

- -

On a related note, a great way to find the right person to talk to is to look at the module owners lists.

- -

The writing community

- -

The writing community is a large one. While the number of extremely frequent, or large-scale contributors is relatively small, there are many dozens or hundreds of people who contribute at least now and then. Fortunately, these are by and large awesome people with a genuine love of the Web, Mozilla, and/or documentation, and interacting with them is almost always pretty easy.

- -

See the article Join the community for more information about the MDN community.

- -

The most frequent place you'll directly interact with other writers is in the Discourse forum.

- -

By keeping in mind the {{anch("General etiquette guidelines")}}, you'll find that usually, things go very smoothly.

- -

See also

- - diff --git a/files/ko/mdn/contribute/creating_and_editing_pages/index.html b/files/ko/mdn/contribute/creating_and_editing_pages/index.html deleted file mode 100644 index 6993674a4f..0000000000 --- a/files/ko/mdn/contribute/creating_and_editing_pages/index.html +++ /dev/null @@ -1,166 +0,0 @@ ---- -title: 페이지 생성 및 수정 -slug: MDN/Contribute/Creating_and_editing_pages -tags: - - 초보자 - - 페이지생성 - - 페이지수정 - - 페이지편집 -translation_of: MDN/Contribute/Howto/Create_and_edit_pages ---- -
{{MDNSidebar}}

신규 공헌자가 이미 있는 문서를 수정하거나 신규 문서를 생성하는 법에 대해 설명합니다. 

- -

기존 페이지 수정하기

- -

페이지를 수정하기 위해서:

- - - -

MDN에 탑재된 편집기 사용에 대한 좀 더 세부적인 내용은 MDN 편집기 가이드에 있는 편집기 UI 요소를 참고하세요.

- -

변경 내용 미리보기

- -

수정한 내용이 어떤 모습일지 보기 위해서는...

- - - -

하지만!! 미리보기는 저장된 페이지가 아닙니다. 저장 전 편집 페이지를 닫지 않도록 주의하세요!!

- -

리비전 답글

- -

 미리보기로 확인했다면, 변경사항(리비전)를 저장하고 싶을 겁니다. 저장 전, 편집영역 아래 있는 리비전 답글 영역에 변경 사유를 남겨주세요. 다른 공헌자들이 참고할 수 있도록요. 예를 들면, 새로운 섹션을 추가했거나, 좀 더 정확한 용어를 쓰기 위해 단어를 수정했거나, 언어를 구분하기 위해 문장을 다시 썼거나, 중복되는 내용이기 때문에 정보를 제거했다 등을 적으면 됩니다. 

- -

목차

- -

페이지 상단에 "이동"이라는 목차 영역은 페이지에 있는 소제목 이동 링크를 자동으로 만들어준 것입니다.  소제목을 바꾸면 목차명도 바뀝니다. 편집화면 '설명 번역'의 "TOC" 드롭다운 메뉴를 통해서 목차를 제거하거나 목차 깊이를 조절할 수 있습니다. 

- -

태그

- -

페이지 내용과 기능을 설명하는 태그를 페이지의 편집 섹션 아래에서 추가하거나 제거할 수 있습니다. 어떤 태그를 적용할 것인지에 대해 자세히 알고 싶으면 페이지에 알맞은 태그를 붙이는 방법을 보세요.

- -

검토가 필요한가요?

- -

전문가 또는 숙련된 공헌자의 검토가 필요하다고 생각되면, 저장하기 전에, 검토 요청 체크박스를 이용하여, (코드 샘플, API 혹은 테크놀로지에 대한) 기술상의 검토, (산문, 문법 및 내용에 대한) 편집상의 검토, (KumaScript 코드에 대한) 템플릿 검토를 요청할 수 있습니다.

- -

자료 첨부

- -

자세한 설명을 추가하기 위해 자료를 첨부하고 싶다면, 페이지 하단에서 첨부할 수 있습니다. 

- -

개시, 버리기 또는 개시하고 계속 편집

- -

편집을 완료하고, 미리보기 한 결과에도 만족했다면, 페이지 제목의 오른쪽이나 페이지 하단에 있는 녹색의 "변경 사항 저장"을 클릭하여 작업한 결과와 답글을 저장할 수 있습니다. 마음이 바뀌었다면, 페이지 제목의 오른쪽에 있는 붉은색의 "변경 파기"를 클릭하여 그 동안 작업한 것을 버릴 수 있습니다.

- -

리비전 답글에서 답글을 달고 엔터키를 누르는 것은 "저장하고 계속 수정"하는 것을 클릭하는 것과 같습니다.

- -
-

변경내용을 저장하려 할 때, 밴경내용이 실제 MDN에는 적절한 내용인데 유효하지 않다는 이유로 거절된다면, 작성팀에 콘텐츠가 게시되게 도와 달라는메일을 보내야만 합니다. 

-
- -

새로운 페이지 생성하기

- -

만약 당신이 어디에 새로운 글을 써야할지 모른다고해도 , 걱정하지마세요! 어디든 적으세요 그러면 우리가 그 문서를 찾고 있어야 할 장소로 옴기고 새로 쓴 글이 해당 문서에 적합하다면 , 존재하는 문서에 합칠 거에요. 당신은 또한 완벽하게 해야한다는 것에 대한 걱정을 할 필요가 없어요. 우리는 도움을 주는 행복한 요정들을 가지고 있고  요정들은 당신의 글을 깔끔하고 아주 부드럽게 만드는 것을 도와 줄 것 입니다.

- -

새로운 페이지를 만드는 몇 가지 방법이 있습니다:

- - - -

페이지 생성 권한  얻기

- -

보안의 이유로, 새롭게 생성된 계정은 새로운 페이지를 생성할 수 있는 능력이 없습니다. 페이지 생성을 하고 싶다면, 페이지 생성 방법을 안내하는 페이지를 보게 될 것입니다. 두가지 선택이 있습니다.

- - - -
-
- -

"누락된 페이지" 링크

- -

대부분의 위키가 그러하듯,  MDN에서도 아직 존재하지 않는 페이지로 링크를 연결하는 것이 가능합니다.  예를 들어, 작성자가 어떤 API의  개별 항목에 대한 페이지를 생성하기 전에, 항목의 모든 리스트를 생성할 수 있습니다. MDN에서 존재하지 않는 페이지로 링크를 연결하면 통상 빨간색으로 표시됩니다.

- -

"누락된 페이지" 링크로 페이지를 생성하기 위해서는:

- -
    -
  1. MDN에 로그인 합니다. (로그인 하지 않고, "누락된 페이지" 링크를 클릭하면 404(페이지 없음) 에러가 발생합니다.)
    2. -
  2. "누락된 페이지" 링크를 클릭합니다. MDN 편집기 UI가 열리고,  누락된 페이지를 생성할 수 있는 준비가 됩니다.
    3. -
  3. 페이지의 내용을 작성하고, 저장합니다.
    4. -
- -

링크가 없는 새로운 페이지

- -

다른 페이지의 링크를 걸지 않은  새로운 페이지를 만들기 위해서는,  브라우저의 URL  항목에 고유한 페이지 이름을 입력합니다.  예를 들면,  아래와 같이 입력한다면..

- -
https://developer.mozilla.org/en-US/docs/FooBar
- -

MDN은 제목이 "FooBar"로 된 새로운 페이지가 생성하고,  편집기가 실행되어 새로운 페이지에 내용을 추가할 수 있게 해줍니다.  편집기 모드를 이용하는 방법에 대한 내용은  이 글의 이미 존재하는 페이지 편집하기 섹션을 참고하세요.

- -

이미 존재하는 페이지의 하위 페이지

- -

페이지의 계층 구조에서 이미 존재하는 페이지 하위로 페이지를 생성하고 싶다면:

- -
    -
  1. "부모" 페이지에서, Advanced 메뉴(툴바의 기어 아이콘)를 클릭하고, New sub-page를 클릭합니다. 새로운 문서를 생성하기 위한 편집기 화면이 열립니다.
    2. -
  2. Title 항목에 문서의 제목을 입력합니다.
    3. -
  3. 필요하다면 Slug 항목을 수정합니다.  예를 들어,  제목이 너무 길어서 단축 URL을  입력할 수 있습니다. 이 항목은 에디터에서 제목의 공백을 언더스코어로 연결하여 자동적으로 채워줍니다.  이 경우,  문서의 URL  중 가장 마지막 부분만 수정할 수 있습니다.
    4. -
  4. TOC 항목에서,  페이지의 목차에 자동적으로 노출되기 원하는 헤드라인을 선택하거나, 페이지에서 필요가 없다면 "목차 없음(No table of contents)"을 선택합니다.
    5. -
  5. 편집 패널에서 페이지의  내용을 작성하고 변경사항을 저장합니다.  편집 모드 사용에 대한 방법은  이 글의 이미 존재하는 페이지 편집하기  섹션을 참고하세요.
    6. -
- -

이미 존재하는 페이지 복제

- -

새로운 페이지를 위해 사용하고자 하는 페이지의 포멧이 이미 존재한다면,  페이지를 '복제'하여 내용을 수정할 수 있습니다.

- -
    -
  1. 복제하려는 원래 페이지에서,  Advanced  메뉴(툴바의 기어 아이콘)을 클릭하고,  이 페이지 복제하기(Clone this page)를 클릭합니다. 새로운 문서를 생성하기 위한 편집기 화면이 열립니다.
    2. -
  2. 페이지의 타이틀(Title)을 새로운 내용에 맞게 적절하게 바꿉니다. Slug 항목은  타이틀(Title) 항목을 바꾸면 자동적으로 반영됩니다.
    3. -
  3. 필요하다면, 문서의 계층구조의 다른 부분에 새로운 문서를 넣기 위해 Slug 항목의 경로 부분도 변경합니다. (대부분의 경우, 복제된 페이지가 원래 페이지와 유사한 내용을  가지고 있고, 따라서 위치도 비슷하기 때문에  이 과정은 필요하지 않습니다.)
    4. -
  4. TOC 항목에서,  페이지의 목자에 자동적으로 노출되기 원하는 헤드라인을 선택하거나,  목차를 가지고 있지 않다면 "목차 없음(No table of contenst)"을 선택합니다.
    5. -
  5. 편집 패널에서 페이지의  내용을 작성하고,  변경사항을 저장합니다. 편집 모드 사용에 대한 방법은  이 글의 이미 존재하는 페이지 편집하기  섹션을 참고하세요.
    6. -
- -

이미 존재하는 페이지의 링크

- -

이 방법은 다소 복합적입니다.  다른 페이지에 링크를 만들고,  새로운 페이지를 만들기 위해  삽입한 링크를 클릭합니다.

- -
    -
  1. 이미 존재하는 페이지의 텍스트 안에  넣고자 하는 새로운 페이지의 이름을 입력합니다.
    2. -
  2. 이름을 선택하고,  편집기의 툴바에서 링크 아이콘 클릭(click the Link icon ())을 클릭합니다. "Update Link" 다이얼로그가 열리고,  "Link To" 항목에 선택된 텍스트로 채워집니다.
    3. -
  3. 기본적으로, URL 항목의 시작  부분은  "/en-US/docs/"가 삽입됩니다.  "/en-US/docs/"  다음에 페이지의 이름을 입력하세요. (페이지 이름은 링크 텍스트와 동일하지 않아도 됩니다.)
    4. -
  4. 링크를 생성하고 삽입하기 위해 OK를 클릭합니다.
    5. -
- -

페이지가 존재하지 않는다면,  링크는 붉은색으로 보여집니다. 페이지가 존재한다면 링크는 파란색으로 보여집니다. 새로운 페이지를 만들고 싶은데 원하는 페이지 제목이 이미 존재한다면, 먼저 해당 페이지에 있는 내용을  추가 편집하거나 좀 더 개선할 부분은 없는지 확인하십시오. 아니면,  생성하고자 하는 페이지에 대한 다른 제목을 고민해보고 링크를 만들어 보세요. 페이지 이름에 대한 안내는 페이지 네이밍 가이드를 참고하세요.

- -

새로운 페이지에 내용을 추가하기 위해, 저장하고 편집기를 닫은 후에 이제 막 추가된 붉은색 링크를 클릭합니다. 편집 모드에 새로운 페이지가 열리고,  작성을 할 수 있습니다.  편집 모드 사용에 대한 방법은  이 글의 이미 존재하는 페이지 편집하기 섹션을 참고하세요.

- -

페이지 콘텐츠 새로고침하기

- -

MDN의 KumaScript 매크로와 페이지의 콘텐츠를 다른 페이지로 넣을 수 있는 트랜스클루젼(transclusion)의 지원은 성능 향상을 위해  생성된 페이지의 캐시의 필요에 의해 종종 방해될 수 있다. 페이지는 그 소스로부터 만들어지고, 이후에 있을 요청을 위해 산출물을 캐시로 저장해둔다. 그  때부터  어떤 매크로(템플릿),  페이지의 Page 매트로를 이용하는 트랜스클루젼도 매크로나 매크로의 산출물,  혹은 삽입되어 추가된 원래 자료의 변경에도 영향이 없을 것이다.

- - - -

함께 보기

- - diff --git a/files/ko/mdn/contribute/does_this_belong/index.html b/files/ko/mdn/contribute/does_this_belong/index.html deleted file mode 100644 index 46f6395a52..0000000000 --- a/files/ko/mdn/contribute/does_this_belong/index.html +++ /dev/null @@ -1,139 +0,0 @@ ---- -title: 이건 MDN에 있나요? -slug: MDN/Contribute/Does_this_belong -translation_of: MDN/Guidelines/Does_this_belong_on_MDN ---- -
{{MDNSidebar}}
{{IncludeSubnav("/ko/docs/MDN")}}
- -

무엇인가를 문서로 남겨두겠다는 생각을 하기 시작했다면,  그 문서를 어디에 둘지도 고민해보았을 겁니다. 문서가 위치할 수 있는 몇 가지 장소가 있고, MDN이 웹에서 가장 큰 문서 저장소 중 하나이지만 유일한 옵션은 아닙니다. 또한 소스 코드에 문서를 보관해둘 수도 있고, Mozilla 위키나 git 저장소의 README 파일에 저장해 두어도 좋습니다. 이 글에서는 어느 방법이 여러분들의 문서와 어울릴지를 판단하는데 도움이 되기 위해서 쓰였습니다.

- -

MDN에는 뭐가 있죠?

- -

우리는 MDN에 정말 다양한 주제를 다룹니다. 하지만 완전히 MDN에 있어서는 안될 몇 가지도 있습니다. 이 섹션은 여러분의 문서가 MDN에 있어도 괜찮은지 판단할 수 있도록 도와주겠습니다.

- -

MDN에서 다루는 것

- -

우리는 MDN에서 정말 많은 내용을 다루고 있습니다. 일반적으로 완전히 제작되었거나 배포 중인 Mozilla 제품이나, 웹에 공개된 열린 기술이라면, MDN에 문서로 남겨둡니다.

- -

우리들이 다루고 있는 내용 몇가지를 맛보기로 보여드리겠습니다. 전체 리스트는 아니지만 몇가지 아이디어는 줄 수 있을 겁니다.

- - - -
-

참고하세요: 우리는 Mozilla 기술이 아니더라도 Web에 공개되어 있는 한 다룰 수 있다는 점이 중요합니다. 가령, 우리는 Webkit 전용 CSS 프로퍼티를 설명해놓은 문서도 있습니다.

-
- -

우리가 다루지 않는 것

- -

MDN에 문서로 남겨져서는 안되는 명백한 것인지 아닌지에 대해 스스로 질문해볼 수 있습니다.

- - - -

저 질문 중 하나라도 "예"라고 답변할 수 있다면, MDN에 있어서는 안될 문서입니다. 저 질문 모두에 "아니요"라고 대답할 수 있다면, MDN에 문서로 보관할지 진지하게 고민할 때가 되었다는 겁니다!

- -

MDN에 문서로 남겨두면 좋은 점

- -

MDN에 문서로 남겨두면 좋은 점이 굉장히 많답니다.

- -

글을 쓰는 사람들이 굉장히 많습니다

- -

MDN 공동체는 굉장히 큽니다. 정말 큽니다. 큰 것들을 작게 보이게 만들 정도로 큽니다. 농담이 아니라, 우리는 굉장히 많은 사람들과 MDN에 있는 자료를 만들어내며 관리하고 있습니다. 전세계 모든 땅(인정할게요. 남극까지는 잘 모르겠어요.)의 작가, 편집자들과 함께하고 있기 때문에, 글을 쓰려는 사람들은 무조건 득 보는 거에요.

- - - -

Do you want your development team to be entirely responsible for the production of documentation? That's likely if your documentation is maintained elsewhere.

- -

유지보수

- -

Because of the sheer number of contributors, there's usually someone on hand to watch for problems with your content: from spam control to copy-editing, things can happen around the clock. Here's just a taste of what our team can do:

- -
-
스팸 제거
-
스팸이 발생하면 우리들이 처리합니다.
-
편집
-
여러분 생각보다 필력이 달려도 걱정하실 것 없습니다. 여러분이 쓴 글을 다른 사람들이 읽을 수 있도록 해주겠습니다.
-
스타일의 일관성
-
여러분이 작성한 문서 하나에서만 지켜지는 일관성이 아니라, 다른 문서와 함께 있을 때에도 일관적인 스타일을 가지고 있을지 봐주겠습니다.
-
컨텐츠 관리
-
Our team will help ensure that the documentation is cross-linked with other relevant materials, that articles are put in the right places, and that menus and other infrastructure is built to make it easy to follow and understand.
-
- -

다른 곳에 문서로 남겨두는 경우

- -

MDN 말고 다른 곳에다가 여러분이 만든 작업물을 문서로 남겨둘 이유도 없는 건 아닙니다. 그런 이유에 대해서 몇가지 살펴보도록 하고, 각각 장단점을 찾아보도록 할게요.

- -

계획이나 진행 상황

- -

간단합니다. 계획, 진행 상황, 요청에 대한 문서는 MDN에 남기면 안됩니다.

- -

Github에 올라온 프로젝트

- -

Mozilla의 몇몇 프로젝트는 Github에 올라와 있습니다. 또, Github에는 문서를 보관하기 위해 자기네들만의 위키 비스무리한 시스템을 가지고 있어요. 몇몇 팀은 거기에다가 문서를 남겨두기를 더 좋아합니다. 여러분만의 문서를 만들어갈 생각이라면 아무래도 그쪽이 더 편하고 좋겠죠. 하지만 몇가지 사실을 기억하세요.

- - - -

물론 이런 점들이 여러분들에게 별로 문제가 되지 않거나 문제가 되더라도 딱히 불편한 점이 없을 수도 있습니다. 몇몇 팀은 문서로 남기겠다는 필요성이 별로 없어서 코드 안에서만 작업하고 문서를 남겨두기도 합니다.

- -

소스 안에 문서를 남겨두고 싶은 경우

- -

몇몇 팀은 소스 저장소에다가 자신들의 문서를 저장하는 걸 더 선호하기도 합니다. 내부 프로젝트나 라이브러리 프로젝트에서는 꽤나 흔한 일이긴 한데요. 코드를 쓰듯이 자신들의 기술을 문서로 남길 수 있다는 점에서 이점이 있기는 합니다. 하지만 그만큼 단점도 있지요.

- - - -

여전히 몇몇 프로젝트에서 이런 방법을 사용할 수 없는 건 아닙니다. (오히려 좋은 방법일 수도 있습니다.) 작은 프로젝트나 별로 관심을 얻을 생각을 하지 않는 프로젝트에는 특히 그렇죠.

- -

나중에는

- -

It's worth mentioning that someday we intend to make it possible to present off-site content as if it were part of MDN, and that we hope to one day have tools to actually import content from other sites onto MDN. However, there's no timeline in place for making this happen, and even once it does, it will not be as effective as building the documentation directly on MDN.

diff --git a/files/ko/mdn/contribute/howto/convert_code_samples_to_be_live/index.html b/files/ko/mdn/contribute/howto/convert_code_samples_to_be_live/index.html new file mode 100644 index 0000000000..27ac6774f1 --- /dev/null +++ b/files/ko/mdn/contribute/howto/convert_code_samples_to_be_live/index.html @@ -0,0 +1,39 @@ +--- +title: '"살아있는" 코드 샘플로 변환하기' +slug: MDN/Contribute/Howto/살아있는_코드_샘플로_변환하기 +tags: + - 라이브샘플 + - 살아있는 코드 + - 샘플코드 +translation_of: MDN/Contribute/Howto/Convert_code_samples_to_be_live +--- +
{{MDNSidebar}}

MDN의 라이브 샘플 시스템이란, 페이지에서 보여주는 샘플 코드를 수정하면 이 샘플 코드의 실행 결과도 달라지는 기능을 말합니다. 많은 문서에 샘플 코드들이 있지만 모든 샘플이 이 시스템을 사용하고 있지는 않으며, 생명력을 불어 넣어줘야 합니다.

+ + + + + + + + + + + + + + + +
어디서부터 시작해야 하나요?라이브 샘플이 필요한 글 목록을 참고하세요.
작업을 위해 알아 두어야 할 사항은 무엇인가요? +
    +
  • HTML, CSS에 대한 이해가 필요합니다. 샘플에 따라 JavaScript에 대한 지식을 요구할 수도 있습니다.
    • +
  • MDN 문서 내에서 쿠마 스크립트(en) 매크로를 사용할 수 있어야 합니다.
    • +
+
작업 진행 절차는 어떻게 되나요? +

라이브 샘플을 삽입하는 방법을 포함하여, 올바른 라이브 샘플을 작성하려면 라이브 샘플 시스템 사용하기(en) 문서를 참고하세요.

+
    +
  1. 라이브 샘플이 필요한 글 목록에서 마음에 드는 글을 고르세요.
    2. +
  2. 샘플에 "생명력을 불어 넣으세요".
    3. +
  3. 과거의 것들은 지워버리세요.
    4. +
+
+

 

diff --git a/files/ko/mdn/contribute/howto/create_and_edit_pages/index.html b/files/ko/mdn/contribute/howto/create_and_edit_pages/index.html new file mode 100644 index 0000000000..6993674a4f --- /dev/null +++ b/files/ko/mdn/contribute/howto/create_and_edit_pages/index.html @@ -0,0 +1,166 @@ +--- +title: 페이지 생성 및 수정 +slug: MDN/Contribute/Creating_and_editing_pages +tags: + - 초보자 + - 페이지생성 + - 페이지수정 + - 페이지편집 +translation_of: MDN/Contribute/Howto/Create_and_edit_pages +--- +
{{MDNSidebar}}

신규 공헌자가 이미 있는 문서를 수정하거나 신규 문서를 생성하는 법에 대해 설명합니다. 

+ +

기존 페이지 수정하기

+ +

페이지를 수정하기 위해서:

+ + + +

MDN에 탑재된 편집기 사용에 대한 좀 더 세부적인 내용은 MDN 편집기 가이드에 있는 편집기 UI 요소를 참고하세요.

+ +

변경 내용 미리보기

+ +

수정한 내용이 어떤 모습일지 보기 위해서는...

+ + + +

하지만!! 미리보기는 저장된 페이지가 아닙니다. 저장 전 편집 페이지를 닫지 않도록 주의하세요!!

+ +

리비전 답글

+ +

 미리보기로 확인했다면, 변경사항(리비전)를 저장하고 싶을 겁니다. 저장 전, 편집영역 아래 있는 리비전 답글 영역에 변경 사유를 남겨주세요. 다른 공헌자들이 참고할 수 있도록요. 예를 들면, 새로운 섹션을 추가했거나, 좀 더 정확한 용어를 쓰기 위해 단어를 수정했거나, 언어를 구분하기 위해 문장을 다시 썼거나, 중복되는 내용이기 때문에 정보를 제거했다 등을 적으면 됩니다. 

+ +

목차

+ +

페이지 상단에 "이동"이라는 목차 영역은 페이지에 있는 소제목 이동 링크를 자동으로 만들어준 것입니다.  소제목을 바꾸면 목차명도 바뀝니다. 편집화면 '설명 번역'의 "TOC" 드롭다운 메뉴를 통해서 목차를 제거하거나 목차 깊이를 조절할 수 있습니다. 

+ +

태그

+ +

페이지 내용과 기능을 설명하는 태그를 페이지의 편집 섹션 아래에서 추가하거나 제거할 수 있습니다. 어떤 태그를 적용할 것인지에 대해 자세히 알고 싶으면 페이지에 알맞은 태그를 붙이는 방법을 보세요.

+ +

검토가 필요한가요?

+ +

전문가 또는 숙련된 공헌자의 검토가 필요하다고 생각되면, 저장하기 전에, 검토 요청 체크박스를 이용하여, (코드 샘플, API 혹은 테크놀로지에 대한) 기술상의 검토, (산문, 문법 및 내용에 대한) 편집상의 검토, (KumaScript 코드에 대한) 템플릿 검토를 요청할 수 있습니다.

+ +

자료 첨부

+ +

자세한 설명을 추가하기 위해 자료를 첨부하고 싶다면, 페이지 하단에서 첨부할 수 있습니다. 

+ +

개시, 버리기 또는 개시하고 계속 편집

+ +

편집을 완료하고, 미리보기 한 결과에도 만족했다면, 페이지 제목의 오른쪽이나 페이지 하단에 있는 녹색의 "변경 사항 저장"을 클릭하여 작업한 결과와 답글을 저장할 수 있습니다. 마음이 바뀌었다면, 페이지 제목의 오른쪽에 있는 붉은색의 "변경 파기"를 클릭하여 그 동안 작업한 것을 버릴 수 있습니다.

+ +

리비전 답글에서 답글을 달고 엔터키를 누르는 것은 "저장하고 계속 수정"하는 것을 클릭하는 것과 같습니다.

+ +
+

변경내용을 저장하려 할 때, 밴경내용이 실제 MDN에는 적절한 내용인데 유효하지 않다는 이유로 거절된다면, 작성팀에 콘텐츠가 게시되게 도와 달라는메일을 보내야만 합니다. 

+
+ +

새로운 페이지 생성하기

+ +

만약 당신이 어디에 새로운 글을 써야할지 모른다고해도 , 걱정하지마세요! 어디든 적으세요 그러면 우리가 그 문서를 찾고 있어야 할 장소로 옴기고 새로 쓴 글이 해당 문서에 적합하다면 , 존재하는 문서에 합칠 거에요. 당신은 또한 완벽하게 해야한다는 것에 대한 걱정을 할 필요가 없어요. 우리는 도움을 주는 행복한 요정들을 가지고 있고  요정들은 당신의 글을 깔끔하고 아주 부드럽게 만드는 것을 도와 줄 것 입니다.

+ +

새로운 페이지를 만드는 몇 가지 방법이 있습니다:

+ + + +

페이지 생성 권한  얻기

+ +

보안의 이유로, 새롭게 생성된 계정은 새로운 페이지를 생성할 수 있는 능력이 없습니다. 페이지 생성을 하고 싶다면, 페이지 생성 방법을 안내하는 페이지를 보게 될 것입니다. 두가지 선택이 있습니다.

+ + + +
+
+ +

"누락된 페이지" 링크

+ +

대부분의 위키가 그러하듯,  MDN에서도 아직 존재하지 않는 페이지로 링크를 연결하는 것이 가능합니다.  예를 들어, 작성자가 어떤 API의  개별 항목에 대한 페이지를 생성하기 전에, 항목의 모든 리스트를 생성할 수 있습니다. MDN에서 존재하지 않는 페이지로 링크를 연결하면 통상 빨간색으로 표시됩니다.

+ +

"누락된 페이지" 링크로 페이지를 생성하기 위해서는:

+ +
    +
  1. MDN에 로그인 합니다. (로그인 하지 않고, "누락된 페이지" 링크를 클릭하면 404(페이지 없음) 에러가 발생합니다.)
    2. +
  2. "누락된 페이지" 링크를 클릭합니다. MDN 편집기 UI가 열리고,  누락된 페이지를 생성할 수 있는 준비가 됩니다.
    3. +
  3. 페이지의 내용을 작성하고, 저장합니다.
    4. +
+ +

링크가 없는 새로운 페이지

+ +

다른 페이지의 링크를 걸지 않은  새로운 페이지를 만들기 위해서는,  브라우저의 URL  항목에 고유한 페이지 이름을 입력합니다.  예를 들면,  아래와 같이 입력한다면..

+ +
https://developer.mozilla.org/en-US/docs/FooBar
+ +

MDN은 제목이 "FooBar"로 된 새로운 페이지가 생성하고,  편집기가 실행되어 새로운 페이지에 내용을 추가할 수 있게 해줍니다.  편집기 모드를 이용하는 방법에 대한 내용은  이 글의 이미 존재하는 페이지 편집하기 섹션을 참고하세요.

+ +

이미 존재하는 페이지의 하위 페이지

+ +

페이지의 계층 구조에서 이미 존재하는 페이지 하위로 페이지를 생성하고 싶다면:

+ +
    +
  1. "부모" 페이지에서, Advanced 메뉴(툴바의 기어 아이콘)를 클릭하고, New sub-page를 클릭합니다. 새로운 문서를 생성하기 위한 편집기 화면이 열립니다.
    2. +
  2. Title 항목에 문서의 제목을 입력합니다.
    3. +
  3. 필요하다면 Slug 항목을 수정합니다.  예를 들어,  제목이 너무 길어서 단축 URL을  입력할 수 있습니다. 이 항목은 에디터에서 제목의 공백을 언더스코어로 연결하여 자동적으로 채워줍니다.  이 경우,  문서의 URL  중 가장 마지막 부분만 수정할 수 있습니다.
    4. +
  4. TOC 항목에서,  페이지의 목차에 자동적으로 노출되기 원하는 헤드라인을 선택하거나, 페이지에서 필요가 없다면 "목차 없음(No table of contents)"을 선택합니다.
    5. +
  5. 편집 패널에서 페이지의  내용을 작성하고 변경사항을 저장합니다.  편집 모드 사용에 대한 방법은  이 글의 이미 존재하는 페이지 편집하기  섹션을 참고하세요.
    6. +
+ +

이미 존재하는 페이지 복제

+ +

새로운 페이지를 위해 사용하고자 하는 페이지의 포멧이 이미 존재한다면,  페이지를 '복제'하여 내용을 수정할 수 있습니다.

+ +
    +
  1. 복제하려는 원래 페이지에서,  Advanced  메뉴(툴바의 기어 아이콘)을 클릭하고,  이 페이지 복제하기(Clone this page)를 클릭합니다. 새로운 문서를 생성하기 위한 편집기 화면이 열립니다.
    2. +
  2. 페이지의 타이틀(Title)을 새로운 내용에 맞게 적절하게 바꿉니다. Slug 항목은  타이틀(Title) 항목을 바꾸면 자동적으로 반영됩니다.
    3. +
  3. 필요하다면, 문서의 계층구조의 다른 부분에 새로운 문서를 넣기 위해 Slug 항목의 경로 부분도 변경합니다. (대부분의 경우, 복제된 페이지가 원래 페이지와 유사한 내용을  가지고 있고, 따라서 위치도 비슷하기 때문에  이 과정은 필요하지 않습니다.)
    4. +
  4. TOC 항목에서,  페이지의 목자에 자동적으로 노출되기 원하는 헤드라인을 선택하거나,  목차를 가지고 있지 않다면 "목차 없음(No table of contenst)"을 선택합니다.
    5. +
  5. 편집 패널에서 페이지의  내용을 작성하고,  변경사항을 저장합니다. 편집 모드 사용에 대한 방법은  이 글의 이미 존재하는 페이지 편집하기  섹션을 참고하세요.
    6. +
+ +

이미 존재하는 페이지의 링크

+ +

이 방법은 다소 복합적입니다.  다른 페이지에 링크를 만들고,  새로운 페이지를 만들기 위해  삽입한 링크를 클릭합니다.

+ +
    +
  1. 이미 존재하는 페이지의 텍스트 안에  넣고자 하는 새로운 페이지의 이름을 입력합니다.
    2. +
  2. 이름을 선택하고,  편집기의 툴바에서 링크 아이콘 클릭(click the Link icon ())을 클릭합니다. "Update Link" 다이얼로그가 열리고,  "Link To" 항목에 선택된 텍스트로 채워집니다.
    3. +
  3. 기본적으로, URL 항목의 시작  부분은  "/en-US/docs/"가 삽입됩니다.  "/en-US/docs/"  다음에 페이지의 이름을 입력하세요. (페이지 이름은 링크 텍스트와 동일하지 않아도 됩니다.)
    4. +
  4. 링크를 생성하고 삽입하기 위해 OK를 클릭합니다.
    5. +
+ +

페이지가 존재하지 않는다면,  링크는 붉은색으로 보여집니다. 페이지가 존재한다면 링크는 파란색으로 보여집니다. 새로운 페이지를 만들고 싶은데 원하는 페이지 제목이 이미 존재한다면, 먼저 해당 페이지에 있는 내용을  추가 편집하거나 좀 더 개선할 부분은 없는지 확인하십시오. 아니면,  생성하고자 하는 페이지에 대한 다른 제목을 고민해보고 링크를 만들어 보세요. 페이지 이름에 대한 안내는 페이지 네이밍 가이드를 참고하세요.

+ +

새로운 페이지에 내용을 추가하기 위해, 저장하고 편집기를 닫은 후에 이제 막 추가된 붉은색 링크를 클릭합니다. 편집 모드에 새로운 페이지가 열리고,  작성을 할 수 있습니다.  편집 모드 사용에 대한 방법은  이 글의 이미 존재하는 페이지 편집하기 섹션을 참고하세요.

+ +

페이지 콘텐츠 새로고침하기

+ +

MDN의 KumaScript 매크로와 페이지의 콘텐츠를 다른 페이지로 넣을 수 있는 트랜스클루젼(transclusion)의 지원은 성능 향상을 위해  생성된 페이지의 캐시의 필요에 의해 종종 방해될 수 있다. 페이지는 그 소스로부터 만들어지고, 이후에 있을 요청을 위해 산출물을 캐시로 저장해둔다. 그  때부터  어떤 매크로(템플릿),  페이지의 Page 매트로를 이용하는 트랜스클루젼도 매크로나 매크로의 산출물,  혹은 삽입되어 추가된 원래 자료의 변경에도 영향이 없을 것이다.

+ + + +

함께 보기

+ + diff --git a/files/ko/mdn/contribute/howto/do_a_technical_review/index.html b/files/ko/mdn/contribute/howto/do_a_technical_review/index.html deleted file mode 100644 index 9b648a8d0c..0000000000 --- a/files/ko/mdn/contribute/howto/do_a_technical_review/index.html +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: 기술 리뷰를 하는 방법 -slug: MDN/Contribute/Howto/Do_a_technical_review -translation_of: MDN/Contribute/Howto/Do_a_technical_review ---- -
{{MDNSidebar}}

기술 리뷰는 기술적 정확성과 글의 완결성을 검토하는 것, 필요하다면 수정하는 것으로 이루어집니다. 글의 작성자가 다른 사람이 글의 기술적 내용을 확인하는 것을 바란다면, 작성자는 편집을 하는동안 "Technical review" 체크박스에 체크합니다. 작성자는 대개 기술 리뷰를 위해 특정한 엔지니어와 접촉하지만, 해당 주제에 대한 전문가라면 누구라도 가능합니다.

-

이 글은 기술 리뷰를 어떻게 하는지에 대해 기술하고, 그에 따라서 MDN의 컨텐츠들이 정확하도록 도움을 줍니다.

- - - - - - - - - - - - - - - -
어떤 부분에 이 일이 필요하나요?technical review가 필요하다고 표시된 특정 글
이 일을 하기 위해 무엇을 알아야 하나요? -
    -
  • 리뷰를 하고 있는 글의 주제에 대한 전문 지식.
    • -
  • MDN의 위키 글을 편집할 수 있는 능력.
    • -
-
어떤 단계를 거쳐야 하나요? -
    -
  1. technical reviews가 필요한 페이지 목록으로 갑니다. 기술 리뷰가 요청된 모든 페이지들이 보여집니다.
    2. -
  2. 친숙한 주제를 가진 페이지를 고르세요.
    3. -
  3. 링크를 클릭하여서 페이지를 부르세요.
    4. -
  4. 페이지가 불려지면, 최상단 근처의 EDIT 버튼을 클릭하세요; MDN 에디터로 갑니다. 처음에 고른 페이지가 당신한테 맞지 않는다면 다른 페이지로 바꾸는 것을 주저하지 마세요.
    5. -
  5. 글을 읽으면서 틀린 기술 정보를 고치고 빠진 중요한 정보를 추가하세요.
    6. -
  6. 글 아래에 당신이 한 일에 대해서 기술하는 다음과 같은 코멘트를 입력하세요, '기술 리뷰 완료.' 정보를 수정한다면, 그것을 코멘트에 포함시키세요, 예를 들어 '기술 리뷰: fixed parameter descriptions.'
    7. -
  7. SAVE CHANGES 버튼을 클릭하세요 .
    8. -
  8. 에디터를 닫고 난 후 올바른 글이 화면에 뜨고 나면, 측면의 Technical 엔트리를 체크하여 (다음의 리뷰가 요청되었습니다 아래) SUBMIT REVIEW 버튼을 클릭하세요.
    9. -
  9. 끝났습니다!
    10. -
-
-

 

diff --git a/files/ko/mdn/contribute/howto/do_an_editorial_review/index.html b/files/ko/mdn/contribute/howto/do_an_editorial_review/index.html deleted file mode 100644 index 13b2f0d4a1..0000000000 --- a/files/ko/mdn/contribute/howto/do_an_editorial_review/index.html +++ /dev/null @@ -1,48 +0,0 @@ ---- -title: 편집 검토를 하는 방법 -slug: MDN/Contribute/Howto/Do_an_editorial_review -translation_of: MDN/Contribute/Howto/Do_an_editorial_review ---- -
{{MDNSidebar}}
{{IncludeSubnav("/ko-KR/docs/MDN")}}
- -

편집자 검토는 글의 오타와 맞춤법, 문법, 단어의 용법, 또는 원문의 오류를 고치는 일입니다. 모든 공헌자분들은 자신의 지식을 사용해 유용하고 가치있는 글을 만드는 데 기여하고 있습니다만, 이분들이 모두 어학전문가는 아닙니다. 따라서 언어적인 측면에서 교열과 교정이 종종 필요해집니다. 이 교열과 교정 작업이 바로 편집자 검토입니다.

- -

이 글은 어떻게 편집자 검토를 수행하는지, 그리하여 MDN 컨텐츠들의 정확도를 높일 수 있게 되는 지에 대해 설명합니다.

- -
-
편집자 검토는 어떤 일입니까?
-
편집자 검토가 필요하다고 표시된 글들을 교열하고 교정하는 것.
-
어떤 글에서 편집자 검토가 필요합니까?
-
편집자 검토가 필요하다고 표시된 특별한 글들.
-
편집자 검토를 하기 위해서 알아야 하는 것이 있습니까?
-
괜찮은 문법과 맞춤법 실력이 필요합니다. 예를 들어 편집 검토는 문법과 철자에 대한 확인을 해야합니다.
-
편집자 검토는 어떤 단계를 거칩니까?
-
-
    -
  1. 검토할 글을 선택합니다: -
      -
    1. 편집자 검토가 필요한 글 목록으로 이동합니다. 이곳에는 편집자 검토가 필요한 페이지들이 나열되어 있습니다.
      2. -
    2. 경로가 Template:으로 시작하지 않는 한국어 제목을 가진 페이지를 선택합니다.(Template:페이지는 MDN 매크로코드를 포함하고 있습니다)
      3. -
    3. 글 링크를 클릭해서 페이지를 불러옵니다.
      4. -
    -
    2. -
  2. 글의 오탈자, 철자, 문법 및 어법상의 오류에 주의를 기울이며 읽습니다. 만일 선택한 글이 능력에 부친다고 생각되면, 다른 글을 새로 선택하십시오.
    3. -
  3. 만일 살펴본 글에 오류가 없다면, 페이지 왼쪽 사이드바에서 "quick review" 상자를 찾아보십시오:
    - Screenshot of Korean version of the editorial review request sidebar box
    4. -
  4. 편집 상자의 선택을 해제하고, 저장 버튼을 클릭합니다.
    5. -
  5. 오류를 발견했다면, 수정을 해야합니다: -
      -
    1. 페이지 상단의 편집 버튼을 클릭합니다. MDN editor가 열립니다.
      2. -
    2. 발견한 오탈자, 문법, 어법상의 오류를 수정 합니다. 모든 오류를 한번에 다 고치지 않아도 괜찮습니다만, 남은 오류가 없다는 확신을 갖기 어렵다면 편집자 검토 요청 상태를 유지해주십시오.
      3. -
    3. 글 하단의 리비전 답글 항목을 입력합니다; '편집자 검토: 오타, 문법, 맞춤법 수정됨.'같은 식으로 적으시면 됩니다. 이 리비전 답글의 내용으로 다른 공헌자들이나 사이트 편집자들이 어떤 것이 수정되었는지, 왜 수정했는 지에 대해 알 수 있습니다.
      4. -
    4. 검토가 필요한가요? 에서 편집 체크상자를 해제해주십시오. 이 내용은 리비전 답글 항목의 바로 위에 있습니다.
      5. -
    5. 게시 버튼을 클릭해주세요
      6. -
    -
    6. -
- -
-

수정 내용은 저장 직후에 바로 보이지 않을 수 있습니다. 페이지 내용이 처리되고 저장되기 까지는 약간의 시간지연이 있을 수 있습니다.

-
-
-
diff --git "a/files/ko/mdn/contribute/howto/mdn_\352\263\204\354\240\225_\354\203\235\354\204\261\355\225\230\352\270\260/index.html" "b/files/ko/mdn/contribute/howto/mdn_\352\263\204\354\240\225_\354\203\235\354\204\261\355\225\230\352\270\260/index.html" deleted file mode 100644 index b3b84a92b1..0000000000 --- "a/files/ko/mdn/contribute/howto/mdn_\352\263\204\354\240\225_\354\203\235\354\204\261\355\225\230\352\270\260/index.html" +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: MDN 계정 생성 -slug: MDN/Contribute/Howto/MDN_계정_생성하기 -tags: - - 가입 - - 계정 - - 시작하기 - - 인증 -translation_of: MDN/Contribute/Howto/Create_an_MDN_account ---- -
{{MDNSidebar}}

페이지를 수정하거나 데모에 기여하는 등 MDN의 컨텐츠를 변경하려면 MDN 프로필이 필요합니다. 단지 내용을 읽거나 검색하는 것에는 프로필이 필요없으니 걱정하지 마세요. 아래는 MDN 프로필을 설정하기 위한 가이드입니다.

- -

MDN에 기여하기로 마음 먹었다면 여러분이 할 일은 다음과 같습니다. :

- -
    -
  1. 모든 MDN 페이지의 최상단에는 "Sign in with"(또는 '로그인') 버튼이 있습니다. 마우스를 포인터를 올려 놓으면(모바일 디바이스에서는 탭) MDN에서 사용 가능한 인증 서비스 목록이 나타납니다.
    2. -
  2. 로그인 할 서비스를 선택하세요. Persona 가 아닌 인증 서비스를 선택했다면 여러분의 공개 프로필에 여러분이 어떤 인증 방법으로 인증했는지 표시됩니다.
    3. -
  3. 각 서비스별 인증 단계를 따르십시오.
    4. -
  4. 각 서비스별 인증 단계를 마치고 MDN 페이지로 돌아오면,  이름과 이메일 주소를 입력해야 합니다. 입력한 이름은 모든 작업물에 공개적으로 표시되므로, 메일 주소를 이름으로 사용하지 마십시오.
    5. -
  5. 'MDN 프로필 생성' 버튼을 클릭합니다.
    6. -
  6. 4단계에서 입력한 이메일 주소가 여러분이 인증한 서비스 프로필 상의 이메일 주소와 다르면, 입력한 이메일 주소가 올바른지 확인하게 됩니다. 입력한 이메일 주소로 발송된 확인 메일의 링크를 클릭하세요.
    7. -
- -

이게 전부입니다! 이제 여러분의 MDN 계정이 생겼으니, 지금 당장 페이지들을 수정하거나 태그를 달 수 있습니다.

- -

모든 MDN 페이지의 최상단에 있는 여러분의 이름을 클릭하면 여러분의 공개 프로필을 볼 수 있으며, "편집" 버튼을 눌러 새로운 정보를 업데이트 할 수 있습니다. 여러분의 관심사나 블로그 주소, 트위터 계정, 혹은 그 외의 어떤 것이라도 나누어 보세요.

- -
-

참고: 새로운 사용자 이름에 공백이나 '@' 문자를 포함할 수 없습니다. 사용자 이름은 당신의 모든 작업물에서 공개적으로 보여진다는 것을 기억하세요!

-
- -

 

diff --git a/files/ko/mdn/contribute/howto/set_the_summary_for_a_page/index.html b/files/ko/mdn/contribute/howto/set_the_summary_for_a_page/index.html deleted file mode 100644 index e26a3d3a05..0000000000 --- a/files/ko/mdn/contribute/howto/set_the_summary_for_a_page/index.html +++ /dev/null @@ -1,53 +0,0 @@ ---- -title: 페이지에 대한 요약을 설정하는 방법 -slug: MDN/Contribute/Howto/Set_the_summary_for_a_page -translation_of: MDN/Contribute/Howto/Set_the_summary_for_a_page ---- -
{{MDNSidebar}}
- -

MDN의 페이지에 대한 요약을 정의할 수 있습니다. 이 요약은 검색 엔진의 결과, 시사적인 랜딩 페이지와 같은 다른 MDN 페이지 또는 툴팁에서 다양하게 사용됩니다. 요약은 페이지 내용의 나머지가 없이도 페이지의 문맥과 다른 문맥에서 보여졌을 때 모두 의미가 통해야 합니다.

- -

요약은 한 페이지 이내로 분명하게 정의됩니다. 요약이 분명하게 정의되지 않았다면, 보통 첫 번째 문장 정도가 사용되는데 이는 언제나 목적을 위한 최고의 텍스트가 아닙니다.

- - - - - - - - - - - - - - - - - - - - -
어떤 일을 해야 하나요?다른 문맥에서 요약으로 사용되어야 하는 페이지 내의 텍스트를 표시하기; 필요하다면 이 작업은 적합한 텍스트를 작성하는 것을 포함할 수 있습니다.
어디서 이 일이 필요하나요?요약이 부족하거나 미흡한 페이지.
이 일을 하기 위해 무엇을 알아야 하나요?MDN 에디터 사용 능력; 좋은 영작문 솜씨; 좋은 요약을 작성하기 위한 주제에 대한 충분한 친숙도
이 일을 하기 위한 단계는 어떻게 되나요? -
    -
  1. 요약을 설정할 페이지를 고릅니다: -
      -
    1. MDN documentation status 페이지에서, Sections 아래에서 알고 있는 주제의 링크를 클릭합니다.(예를 들어, HTML).
      2. -
    2. 주제의 문서 상태 페이지에서 Summary 테이블의 Pages 헤더를 클릭합니다. 해당 주제 섹션의 모든 페이지 인덱스로 이동됩니다.; 왼쪽 열에는 페이지 링크들이, 오른쪽 열에는 태그와 요약들이 보입니다.
      3. -
    3. 요약이 없거나, 좋지 않은 요약을 가진 페이지를 고릅니다.
      4. -
    4. 링크를 클릭하여 해당 페이지로 갑니다.
      5. -
    -
    2. -
  2. Edit를 클릭하여서 MDN 에디터로 페이지를 엽니다.
    3. -
  3. 문맥과 상관없이 요약으로 사용될 한 문장 또는 두 문장을 찾습니다. 필요하다면, 기존의 내용을 수정하여서 문장이 좋은 요약이 되도록 만들거나 수정합니다.
    4. -
  4. 요약으로 사용될 텍스트를 선택합니다.
    5. -
  5. 에디터 툴바의 Styles 위젯에서 SEO Summary를 선택합니다. (이것은 페이지 소스에서 선택된 텍스트에 class="seoSummary"를 가진 {{HTMLElement("span")}} 엘레멘트를 추가합니다. )
    6. -
  6. "페이지 요약 설정"과 같은 수정 코멘트와 함께 변경사항을 저장합니다.
    7. -
-
- -

 

- -

 

- -

 

diff --git a/files/ko/mdn/contribute/howto/tag_javascript_pages/index.html b/files/ko/mdn/contribute/howto/tag_javascript_pages/index.html deleted file mode 100644 index 8825a20a62..0000000000 --- a/files/ko/mdn/contribute/howto/tag_javascript_pages/index.html +++ /dev/null @@ -1,69 +0,0 @@ ---- -title: JavaScript tag를 다는 방법 -slug: MDN/Contribute/Howto/Tag_JavaScript_pages -translation_of: MDN/Contribute/Howto/Tag_JavaScript_pages ---- -
{{MDNSidebar}}

태그달기는 페이지에 메타 정보를 추가함을 통해 관련된 내용이 묶여질수 있도록 하는 작업을 포함합니다.

- -
-
어디서 필요한가요?
-
태그가 없는 JavaScript에 관련된 특정한 페이지안에서 필요합니다.
-
작업을 위해서 무엇을 알 필요가 있나요?
-
메소드나 변수들과 같은 기본적 JavaScript 코딩 지식이 필요합니다.
-
어떤 절차가 있나요?
-
-
    -
  1. 위에 링크된 페이지들중 하나를 선택하세요
    2. -
  2. 페이지를 로드하기위해 기사링크를 클릭하세요
    3. -
  3. 페이지가 로드됐다면, 맨 위 있는EDIT버튼을 클릭하세요; 이는 당신을 MDN 에디터로 만들어줍니다.
    4. -
  4. 적어도 JavaScript 태그가 추가돼야 합니다. 아래에는 가능한 다른 태그들입니다. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    TagWhat pages to use it on
    Methodmethods
    Propertyproperties
    prototypeprototypes
    Object type namemethods of an object; for example String.fromCharCode should have the tag String
    ECMAScript6 and Experimentalfeatures added in a new ECMAScript version
    Deprecateddeprecated features (whose use is discouraged but still supported)
    Obsoleteobsolete features (which are no longer supported in modern browsers)
    othersSee MDN tagging standards for other possible tags to apply
    -
    5. -
  5. Save with a comment.
    6. -
  6. You're done!
    7. -
-
-
- -

 

diff --git a/files/ko/mdn/contribute/howto/write_an_api_reference/sidebars/index.html b/files/ko/mdn/contribute/howto/write_an_api_reference/sidebars/index.html new file mode 100644 index 0000000000..fd8be5585d --- /dev/null +++ b/files/ko/mdn/contribute/howto/write_an_api_reference/sidebars/index.html @@ -0,0 +1,114 @@ +--- +title: API 레퍼런스의 사이드바 +slug: MDN/Structures/API_references/API_reference_sidebars +translation_of: MDN/Structures/API_references/API_reference_sidebars +--- +
{{MDNSidebar}}
+ +

API 레퍼런스 문서에는 수정 가능한 사이드바 를 추가할 수 있습니다. 이 사이드바에 인터페이스, 튜토리얼, 혹은 API와 관련된 자료 링크를 노출합니다. 그 사용법을 설명합니다. 

+ +

뭘 해야 하나요?

+ +

사이드바 생성은 다음 세 단계로 나뉩니다. 

+ +
    +
  1. API 레퍼런스 페이지를 만듭니다. 
    2. +
  2. KumaScript 레파지토리의 GroupData.json 데이터 파일에 그 API를 위한 엔트리를 추가합니다. 
    3. +
  3. 사이드바가 필요한 페이지에 \{{APIRef}} 메크로를 추가합니다.
    4. +
+ +

Fetch API를 샘플로 삼아서 단계별로 살펴 보겠습니다. 

+ +

신규 API 레퍼런스 페이지 만들기

+ +

페이지에 사이드바를 추가하기 전에 여러분은 페이지를 만들어야 합니다. (자세한건 API 레퍼런스 문서에 필요한건 무엇일까요? 마이드 문서를 보세요)

+ +

GroupData.json에 API의 엔트리를 추가하기

+ +

GroupData.json 파일은 API 레퍼런스 문서의 사이드바 안에 담아야 하는 모든 데이타를 담고 있습니다. API를 파라미터로 주고 \{{APIRef}}메크로를 실행하면, GroupData.json에서 탐색해서 사이드바를 생성하고 페이지에 추가합니다. 

+ +

GroupData.json에 엔트리를 추가하려면 다음을 따르세요.

+ +
    +
  1. GitHub 계정이 필요합니다. 
    2. +
  2. KumaScript 레파지토리를 포크뜨고, 작업할 브랜치를 생성하고 로컬에 클론을 뜹니다. 
    3. +
  3. 생성한 브랜치로 체크아웃을 하고 작업후 오리진으로 푸시합니다. 
    4. +
  4. MDN 팀이 리뷰할 수 있도록 풀 리퀘스트를 날려주시고, 필요하다 생각이 들면 변경 요청을 주세요.
    5. +
+ +

GitHub 사용법을 잘 모르겠으면 호환성 테이블 가이드 문서를 참고하세요. 자세한 내용이 있습니다. 

+ +

GroupData.json은 KumaScript 레파지토리의 macros 폴더 안에 있습니다. 파일을 열어보면 API별로 자기 내용을 가진 거대한 JSON 구조체를 볼 수 있습니다. 키는 API명이고, 값은 사이드바 링크를 생성하기 위해 정의된 하위 멤버를 담은 객체입니다. 

+ +

Fetch API 를 예로 들면 일치하는 GroupData.json의 엔트리가 다음과 같습니다. 

+ +
"Fetch API": {
+    "overview":   [ "Fetch API"],
+    "interfaces": [ "Body",
+                    "Headers",
+                    "Request",
+                    "Response",
+                    "FetchController",
+                    "FetchObserver",
+                    "FetchSignal",
+                    "ObserverCallback" ],
+    "methods":    [ "WindowOrWorkerGlobalScope.fetch()" ],
+    "properties": [],
+    "events":     []
+},
+
+ +

보다시피 키 명을 "Fetch API"으로 명명 하고 있고, 하위 멤버들을 담은 객체를 가지고 있습니다. 

+ +

GroupData 엔트리에 담긴 하위 멤버들

+ +

GroupData 엔트리에 추가할 수 있는 하위 멤버 목록입니다. 

+ +

리스트업된 하위 멤버값 대부분은 링크걸 텍스트와 링크 생성을 위해 메인 API 색인 페이지(https://developer.mozilla.org/<language-code>/docs/Web/API) 끝에 추가될 슬러그입니다. 예를 들어 en-US 로케일에서 "Body"는 아래 링크를 만듭니다. 

+ +
<li><a href="https://developer.mozilla.org/en-US/docs/Web/API">Body</a></li>
+
+ +

몇가지 예외가 있습니다.. 예를 들어 "guides" 하위 멤버는 가이드/튜토리얼 관련 링크를 정의할 하나이상의 링크 정보(타이틀과 슬러그)를 갖고 있는데, 이경우 슬러그는 MDN 어디든 추가될 수 있도록 MDN 문서 루트(https://developer.mozilla.org/<language-code>/docs)의 끝에 추가됩니다. 

+ +

사용가능한 멤버들입니다. 로케일은 en-US로 가정합니다. 

+ +
    +
  1. +

    "overview" — 값은 배열이고, API 오버뷰 문서의 슬러그입니다. 하나인 경우 "Fetch API"이면 다음 같은 링크를 만듭니다. https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API.

    +
    2. +
  2. +

    "interfaces" — 해당 API의 인터페이스 전체 목록을 담은 배열 입니다. 값이 "Body"이면 다음 과 같은 링크를 만듭니다. https://developer.mozilla.org/en-US/docs/Web/API/Body.

    +
    3. +
  3. +

    "methods" — the value is an array that should contain any methods the spec adds to interfaces associated with other APIs, such as instantiation methods created on {{domxref("Navigator")}} or {{domxref("Window")}}. If there are a huge number of methods, you might want to consider only listing the most popular ones, or putting them first in the list. "WindowOrWorkerGlobalScope.fetch()" results in a link being made to https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/fetch.

    +
    4. +
  4. +

    "properties" — the value is an array that should contain all of the properties associated with the API. This can include properties that are members of interfaces defined in the API spec, and properties the API defines on other interfaces. If there are a huge number of properties, you might want to consider only listing the most popular ones, or putting them first in the list. "Headers.append" results in a link being made to https://developer.mozilla.org/en-US/docs/Web/API/Headers/append.

    +
    5. +
  5. +

    "events" — the value is an array that should contain all of the events associated with the API, defined in the API spec, or elsewhere. If there are a huge number of events, you might want to consider only listing the most popular ones, or putting them first in the list. "animationstart" results in a link being made to https://developer.mozilla.org/en-US/docs/Web/Events/animationstart.

    +
    6. +
  6. +

    "guides" — the value is an array containing one or more objects that define links to guides explain how to use the API. Each object contains two submembers — "url", which contains the partial URL pointing to the guide article, and "title", which defines the link test for the link. As an example, the following object:

    + + 
    { "url":   "/docs/Web/API/Detecting_device_orientation",
+"title": "Detecting device orientation" }
    + +

    Creates a link with the title "Detecting device orientation", which points to https://developer.mozilla.org/en-US/docs/Web/API/Detecting_device_orientation.

    +
    7. +
+ +

API Submembers and Tags

+ +

Some submembers are automatically discovered from child pages, based on page tags.  Pages under the top-level API are crawled each time the sidebar is rendered, and entries are automatically created for methods ("Method" tag), properties ("Property" tag), and constructors ("Constructor" tag).

+ +

Submembers are automatically decorated with warning icons based on tags as well.  Decorations are added for experimental ("Experimental" tag), non-standard ("Non Standard" or "Non-standard" tag), deprecated ("Deprecated" tag), or obsolete ("Obsolete" tag) submembers.

+ +

Further information about tag-based processing is available in the APIRef source.

+ +

Inserting the sidebar in your pages

+ +

Once you've added an entry for your API into GroupData.json, submitted it as a pull request and had the change accepted into the main repo, you can include it in your API reference pages using the \{{APIRef}} macro, which takes the name you used for your API in GroupData as a parameter. As an example, the WebVR API's sidebar is included in its pages with the following:

+ +

\{{APIRef("WebVR API")}}

diff --git a/files/ko/mdn/contribute/howto/write_an_article_to_help_learn_about_the_web/index.html b/files/ko/mdn/contribute/howto/write_an_article_to_help_learn_about_the_web/index.html deleted file mode 100644 index 1eddcc7383..0000000000 --- a/files/ko/mdn/contribute/howto/write_an_article_to_help_learn_about_the_web/index.html +++ /dev/null @@ -1,108 +0,0 @@ ---- -title: 사람들이 웹에 대해 알 수 있도록 기사를 작성하는 방법 -slug: MDN/Contribute/Howto/Write_an_article_to_help_learn_about_the_Web -translation_of: MDN/Contribute/Howto/Write_an_article_to_help_learn_about_the_Web ---- -
{{MDNSidebar}}
- -

MDN의 학습 영역(Learning Area)은 새로운 개발자들에게 웹 개념을 소개하는 글들을 위한 우리의 집입니다. 왜냐하면 학습 영역의 콘텐츠는 대부분 초보자를 위한 것들이고, 당신의 지식을 공유하고 웹에 대해서 알고 싶은 사람들을 돕는 좋은 공간이기 때문입니다. 새로운 개발자들이 이 콘텐츠를 따라 할 수 있도록 하는 것이 중요합니다. 따라서 우리는 특별히 관심을 기울여야 합니다. 

- -

이 글에서는 학습 영역(Learning Area)을 위한 페이지를 작성하는 방법을 설명합니다.

- -

학습 영역 기사를 작성하는 방법

- -

당신의 지식을 공유하려면 아래의 큰 초록색 버튼을 누르세요. 그러면 다섯 단계로 이어집니다. 만약 당신이 아이디어를 찾는다면, 우리의 트렐로 보드(our team Trello board)를 살펴보세요.

- -

새 학습 기사 작성

- -

이 기사는 정확한 위치에 도달할 수 없을지도 모르지만, 최소한 그것은 MDN에게 달려 있습니다. 만약 당신이 정확한 위치로 옮기고 싶다면 우리(Contact us)에게 연락해 주세요.

- -

1단계 : 두개의 요약문 작성

- -

기사의 첫 문장은 당신이 다루고자 하는 주제를 요약해야 하고, 두번째 문장은 당신이 기사에 실린 물건들을 좀 더 구체적으로 다루어야 합니다. 예를 들어 :

- -
-

{{glossary("HTML")}}  HTML파일에는 정형 콘텐츠, {{Glossary("CSS")}}, 또 다른 주요 웹 기술이 포함되어 있어 콘텐츠를 원하는 대로 바라볼 수 있습니다.  이 기사에서는 이 기술이 어떻게 작동하는지, 어떻게 기본적인 예제를 작성하는지 살펴보겠습니다. 

-
- -

예를 들어 CSS가 페이지 스타일에 사용되는 핵심 웹 기술이라고 간단히 설명해 주세요. 그것은 독자들이 기사의 주제가 무엇인지에 대한 꽤 좋은 아이디어를 얻을 수 있는 충분한 근거가 됩니다. 

- -

왜냐하면 학습 영역 기사들은 주로 초보자를 대상으로 하고, 각각의 기사는 너무 많은 새로운 정보로 독자들을 압도하지 않도록 한가지 간단한 주제를 다루어야 하기 때문입니다. 만약 당신이 기사를 한 문장으로 요악하지 못하면,  너무 많은 것을 하나의 기사에서 다뤄야 할 지도 모릅니다.

- -

2단계 : 상단 상자 추가

- -

그리곤 독자들의 학습 과정에서 어떤 영향이 있는지 파악하는 것을 돕기 위해서 상단 상자를 추가합니다.  하단에 하나의 예로"URL과 그 구조의 이해(Understanding URLs and their structure)"에 대한 상단 상자가 있습니다. 당신의 기사를 쓰는 데 이 기사를 참고할 수 있습니다.

- - - - - - - - - - - - -
필수 조건:먼저 인터넷이 어떻게 작동하는지(how the Internet works), 웹서버가 무엇인지(what a Web server is), 웹에서 링크의 개념(the concepts behind links on the web)을 알아야 합니다.
목표:URL에 대해서와 URL이 어떻게 웹에서 작동하는지를 배웁니다.
- -
-
필수 조건
-
독자가 이 기사를 이해하기 위해 반드시 알고 있어야 할 것이 무엇인가요? 가능한 한 각 필수 요소에 대한 링크를 해당 개념을 다루는 다른 학습 영역 문서에 연결하세요. (사전 지식이 필요 없는 기초적인 기사가 아니라면)
-
목표
-
-

이 섹션에서는 독자가 글을 통해 습득할 내용을 간략하게 설명합니다. 이것은 요약문과는 좀 다릅니다, 요약문에서는 기사의 주제를 요약하지만 목표 부분은 독자들이 기사의 과정을 통해 달성할 수 있는 것을 구체적으로 제시합니다.

-
-
- -
-

Note: 이 테이블을 생성하려면, 위의 예제 테이블을 복사하여 붙여 넣을 수 있으며, MDN의 editor의 table tool을 사용할 수 있습니다. 테이블 도구를 사용하도록 선택한 경우에는 기본 standard-table 클래스 이외에 learn-box CSS 클래스를 추가해야 합니다. 이렇게 하려면 테이블 속성을 생성하거나 편집할 때"Advanced"패널로 이동하여 스타일시트 클래스 필드를 "standard-table learn-box"로 설정합니다. 

-
- -

3단계 : 전체 설명 작성

- -

다음으로 가장 중요한 개념을 강조하는 기사를 좀 더 자세히 설명하는 더 긴 설명을 작성합니다. 왜 독자들이 이 주제를 배우고 당신의 기사를 읽는 데 시간을 할애해야 하는지 설명하는 것을 잊지 마세요!

- -

4단계 : 깊이 들어가기

- -

모든 작업을 마친 후, 마침내 주제에 더욱 깊이 들어갈 수 있습니다. 원하는 대로 이 분야의 기사를 작성합니다(우리의 style guide를 자유롭게 참고하셔도 됩니다).  당신이 빛날 수 있는 기회입니다! 작성하는 주제에 대해 자세히 설명합니다. 전체 참조 문서에 대한 링크를 제공하고, 기술이 어떻게 작동하는지 설명하고, 구문 및 사용 상세 내역을 제공하는 방법을 설명합니다. 당신이 하고 싶은 대로 하세요!

- -

가이드로서, 여기에 초보자들을 위한 몇가지 조언이 있습니다:

- - - -

우리 기능의 첫번째 섹션을 살펴보세요. 몇가지 좋은 설명 섹션을 볼 수 있는 코드 문서를 보세요.(Functions — reusable blocks of code)

- -

5단계 : "능동적 학습" 자료 제공

- -

기사에 삽화를 넣는 것은 독자들이 더 쉽게 이해하고 배우는데 도움이 된다. 완수할 수 있는 연습, 튜토리얼 과제를 제공하세요. 여러분의 기사를 적극적으로 사용하고 실험하고 실험하고 실험하는 것을 통해, 여러분은 그들의 뇌에 정보를 "잠금" 하는 것을 도울 수 있습니다.

- -

직접 예제(live samples)로 페이지 안에 포함시키거나 직접 예제처럼 제대로 작동하지 않는 경우 링크하는 것(link to them)을 선택할 수 있습니다. 만약 여러분이 이 가치있는 자료를 만드는데 관심이 있다면, 웹을 배우는 것을 돕기 위한 대화형 연습 만들기(Create an interactive exercise to help learning the Web) 에 대한 기사를 읽어보세요.

- -

기존의 능동적인 학습 자료에 대한 링크를 제공할 수 없는 경우(관련 자료에 대해서 모르거나 만들 시간이 없을 경우) "NeedsActiveLearning"를 문서에 태그하세요. 다른 기여자들은 능동적인 학습 자료가 필요한 기사를 찾을 수 있고 당신이 그것들을 고안해 낼 수 있도록 도와 줄 지도 모릅니다.

- -

실시간 상호적인 학습 연습에 대한 Active learning: selecting different elements를 살펴보거나 Active learning: Playing with scope를 통해 로컬에서 탬플릿을 다운로드하고 수정하는 다양한 형태의 연습이 제공한 단계를 따라가세요.

- -

6단계 : 문서를 검토하고 탐색 영역 메뉴에 추가하세요

- -

기사를 쓰고 난 후, 우리가 보고 검토하고 개선점을 제안할 수 있도록 알려주세요. 연락할 수 있는 가장 좋은 방법은 당사의 연락처(Contact us) 섹션을 참조하는 것입니다.

- -

당신의 기사를 마무리하는 또 다른 방법은 학습 영역 기본 탐색 메뉴에 넣는 것입니다. 이 메뉴는 LearnSidebar 매크로에 의해 생성되어 편집할 특별한 권한이 필요합니다. 따라서 팀에서 추가한 내용에 대해 다시 한번 말씀 드리겠습니다.

- -

당신의 페이지에 기사를 추가해야 합니다. 이것은 당신의 페이지 맨 위에 있는 단락에 매크로(\{{LearnSidebar}})를 추가함으로써 이루어집니다.

- - - -

추천 기사

- -

기여를 하고 싶은데 어떤 것을 써야 할 지를 모르겠나요?

- -

학습 영역 팀은 글을 쓰기 위한 아이디어가 담긴 트렐로 보드(a Trello board with ideas of articles)를 유지합니다. 하나를 골라서 자유롭게 작성하세요! 

diff --git "a/files/ko/mdn/contribute/howto/\354\202\264\354\225\204\354\236\210\353\212\224_\354\275\224\353\223\234_\354\203\230\355\224\214\353\241\234_\353\263\200\355\231\230\355\225\230\352\270\260/index.html" "b/files/ko/mdn/contribute/howto/\354\202\264\354\225\204\354\236\210\353\212\224_\354\275\224\353\223\234_\354\203\230\355\224\214\353\241\234_\353\263\200\355\231\230\355\225\230\352\270\260/index.html" deleted file mode 100644 index 27ac6774f1..0000000000 --- "a/files/ko/mdn/contribute/howto/\354\202\264\354\225\204\354\236\210\353\212\224_\354\275\224\353\223\234_\354\203\230\355\224\214\353\241\234_\353\263\200\355\231\230\355\225\230\352\270\260/index.html" +++ /dev/null @@ -1,39 +0,0 @@ ---- -title: '"살아있는" 코드 샘플로 변환하기' -slug: MDN/Contribute/Howto/살아있는_코드_샘플로_변환하기 -tags: - - 라이브샘플 - - 살아있는 코드 - - 샘플코드 -translation_of: MDN/Contribute/Howto/Convert_code_samples_to_be_live ---- -
{{MDNSidebar}}

MDN의 라이브 샘플 시스템이란, 페이지에서 보여주는 샘플 코드를 수정하면 이 샘플 코드의 실행 결과도 달라지는 기능을 말합니다. 많은 문서에 샘플 코드들이 있지만 모든 샘플이 이 시스템을 사용하고 있지는 않으며, 생명력을 불어 넣어줘야 합니다.

- - - - - - - - - - - - - - - -
어디서부터 시작해야 하나요?라이브 샘플이 필요한 글 목록을 참고하세요.
작업을 위해 알아 두어야 할 사항은 무엇인가요? -
    -
  • HTML, CSS에 대한 이해가 필요합니다. 샘플에 따라 JavaScript에 대한 지식을 요구할 수도 있습니다.
    • -
  • MDN 문서 내에서 쿠마 스크립트(en) 매크로를 사용할 수 있어야 합니다.
    • -
-
작업 진행 절차는 어떻게 되나요? -

라이브 샘플을 삽입하는 방법을 포함하여, 올바른 라이브 샘플을 작성하려면 라이브 샘플 시스템 사용하기(en) 문서를 참고하세요.

-
    -
  1. 라이브 샘플이 필요한 글 목록에서 마음에 드는 글을 고르세요.
    2. -
  2. 샘플에 "생명력을 불어 넣으세요".
    3. -
  3. 과거의 것들은 지워버리세요.
    4. -
-
-

 

diff --git a/files/ko/mdn/editor/index.html b/files/ko/mdn/editor/index.html deleted file mode 100644 index a327f0fd89..0000000000 --- a/files/ko/mdn/editor/index.html +++ /dev/null @@ -1,19 +0,0 @@ ---- -title: MDN 에디터 UI 가이드 -slug: MDN/Editor -tags: - - Landing - - MDN -translation_of: MDN/Editor ---- -
{{MDNSidebar}}
- -
{{IncludeSubnav("ko/docs/MDN")}}
- -

MDN 위키가 제공하는 위지윅(WYSIWYG) 에디터를 통해 새로운 컨텐츠에 쉽게 기여할 수 있습니다. 이 글은 에디터의 사용법과 작업 생산성을 향상시킬 수 있는 기능들에 대해 상세히 설명하고 있습니다. 새로운 페이지를 생성하거나 편집하기 전에 모질라의 법적고지를 읽고 여기에 따라주십시오.

- -

MDN 스타일 지침을 통해 MDN이 지향하는 형식, 스타일, 선호하는 문법과 스펠링 규칙에 대해 자세히 알 수 있습니다.

- -

{{LandingPageListSubpages}}

- -

{{EditorGuideQuicklinks}}

diff --git a/files/ko/mdn/editor/links/index.html b/files/ko/mdn/editor/links/index.html deleted file mode 100644 index f6217db92c..0000000000 --- a/files/ko/mdn/editor/links/index.html +++ /dev/null @@ -1,181 +0,0 @@ ---- -title: Links -slug: MDN/Editor/Links -tags: - - MDN - - 가이드 - - 문서화 - - 에디터 -translation_of: MDN/Editor/Links ---- -
{{MDNSidebar}}
- - - -
-

주목할 점: 특별히 링크시에 선호되는 작성방법이 있습니다;  MDN  작성 스타일 가이드에 설명되어 있습니다.

-
- -

툴바 사용하기

- -

링크를 만드는 가장 확실한 방법은 툴바의  "link" 버튼을 클릭하거나, Ctl+K (맥에서는 Command-K )를 누르는 것입니다. 링크 버튼은 이렇게 생겼습니다: The link button (as of 2015-12-04). 문자열 선택없이 링크 작성시에, 혹은 기존에 있는 문자열을 선택하여 링크 작성시에 이 기능을 이용할 수 있습니다.

- -

문자열 선택없이 링크 작성하기

- -

일단 링크 버튼을 클릭하면, 아래에 보이는 링크 에디터 다이얼로그로 진입합니다:

- -

Screenshot of the Link dialog box, showing the Link Info tab

- -

여기서 새로운 링크를 구성할 수 있습니다. 이 다이얼로그의 콘트롤은 다음과 같습니다:

- -
-
링크 종류
-
생성중인 링크의 종류입니다. URL의 기본값은, MDN이든 오프사이트이든, 웹상 어딘가에 있는 URL입니다. 텍스트내의 앵커 (anchor)또는 "이메일"을 선택할 수도 있습니다. 앵커 링크 옵션은 툴바의 Anchor 버튼 으로 이전에 삽입된 anchor로의 링크를, 목록에서 골라서 생성할 수 있도록 합니다. 이메일 옵션은 받는사람의 이메일 주소와 제목 기본 메시지 콘텐츠를 입력하여 mailto: URL 이 구성되도록 합니다. 대부분의 경우 URL optin을 사용하게 될 겁니다.
-
문서 제목 찾기 / 링크 텍스트
-
이 필드는 두가지 목적을 수행합니다: 첫째는, 링크 대상으로 사용할 텍스트를 지정할 수 있습니다 (또는 대화 상자를 열기 전에 텍스트를 선택한 경우, 해당 텍스트가 이곳에 링크 대상으로 표시됩니다). 두번째로, 이 곳에 입력된 텍스트를 MDN내 등록된 문서와 대조하여 가능한 목적지 페이지를 찾아내는데 사용됩니다. 예를 들어, 이 박스안에 "Array"라고 타이핑하면, 아래와 같은 상황을 볼 수 있습니다:
- Screenshot of the Link dialog box, showing a lookup menu for the text "Array"
-
- -
-
Here, you can see a list of all the pages on MDN whose titles include the text you've typed. You can then scroll through the list and select one of those pages, or keep typing to narrow down the list. Note that the items in the list display their locale ("[en-US]" in this case). That text is not used in the link target text; it is there to help you ensure that you are linking to an article in the same locale as the one you are editing.
-
Attachments
-
Alternatively, you may make the link be a link to one of the files attached to the current page by selecting the attachment from this list. This is a great way to offer links to download code samples and the like.
-
URL
-
Finally, the URL field lets you actually directly enter the URL; it also shows the URL of whatever you've selected in either the Article Title Lookup or Attachments menus, if you've used those. A common practice is to paste URLs to pages you're working on elsewhere on MDN. If you link to another article on MDN, remove the domain name ("https://developer.mozilla.org") from the beginning of the URL, since that's implied.
-
- -

Once the link is configured, click the OK button to insert it.

- -
-

If you're paying attention, you'll see that there's a second tab—Advanced—in the link editor dialog. There are no options there that we advise you to use on a regular basis, at least at this time. It's possible that in the future there will be alternate styles for links, but we will likely add new toolbar widgets to use those features when they're available.

-
- -

기존 텍스트에 링크 생성하기

- -

If you have existing text that you'd like to turn into a link, you can simplify the process somewhat. Highlight the text you'd like to turn into a link before opening the link editor; this will pre-populate the Article Title/Lookup Text field with the selected text. For example, let's say we have the following text:

- -
-

You may find it useful to use JavaScript arrays when working on this project.

-
- -

We'd like to turn "arrays" into a link to the appropriate content. Just highlight that word and invoke the link editor; you'll get a pre-populated dialog similar to the previous case. By "hovering" your mouse over a suggested article, you can see its relative slug (its URL relative to developer.mozilla.org), which can give you a better idea of where it is located and what type of article it is.

- -

Screenshot of the Link dialog box, showing a lookup menu and a URL tooltip

- -

Here, of the articles suggested as possible matches. "Arrays" looks like a good choice, so we can choose that. This automatically fills in the URL field, so you can just click OK and the text gets turned into a link, like this:

- -
-

You may find it useful to use JavaScript arrays when working on this project.

-
- -

링크 매크로 사용하기

- -

MDN은, 선택된 용어에 적절한 콘텐츠로의 링크가 자동적으로 생성되는 동시에 스타일 가이드에 맞게 링크가 생성되도록 하는 작업을 매크로에 크게 의존합니다. 이 예를 보세요: 우리의 스타일 가이드는 API 용어 이름, HTML 요소와 속성, CSS 속성, 함수 이름등이 {{HTMLElement("code")}} 형식을 권장한다( 사실상 그대로 되어야 합니다)라고 되어있습니다. 그것들은 또한 MDN상의 적절한 페이지로 링크가 연결되어있어야 합니다.

- -

매크로를 이용하여 이런 링크들을 만드는 것은 익숙해지기에 약간 시간이 걸리지만 많은 장점이 있습니다:

- - - -

이런 종류의 매크로가 많이 있으며, 여기서 모든 매크로를 다 보지는 않을 겁니다. 대신, 가장 일반적인  몇가지 특별한 예를 살펴볼 것입니다. 더 완벽한 목록은  MDN 커스텀 매크로 가이드의 "하이퍼링크 생성하기" 섹션을 보세요. 모든 매크로에 대해서 KumaScript 소스 코드를 확인할 수 있다는 점은 주목할만 합니다. 대부분의 경우 소스코드 상단에 작동 방식과 다양한 매개변수가 무엏인지 설명하는 주석이 있습니다.

- -

API 문서에 링크걸기

- -

We have a number of extremely helpful macros for creating styled links to APIs. Here are a few of the most useful ones; in each case, there may be added parameters available to give you more control over the output (such as suppressing the automatic addition of the <code> styling). Each macro name below can be clicked upon to read the macro code itself; they all have comments at the top explaining what they do and all of their parameters.

- -
-
{{TemplateLink("HTMLElement")}}
-
Inserts an HTML element's name, properly styled and linked. For example: \{{HTMLElement("table")}} yields {{HTMLElement("table")}}.
-
{{TemplateLink("cssxref")}}
-
Inserts a CSS property, at-rule, or selector's documentation in the CSS reference. For example: \{{cssxref("background-color")}} results in {{cssxref("background-color")}}.
-
{{TemplateLink("domxref")}}
-
Inserts a link into the Web API Reference for a given API term. For example: \{{domxref("window")}} yields {{domxref("window")}} and \{{domxref("window.scrollBy()")}} inserts {{domxref("window.scrollBy()")}}. You can also supply an additional parameter to override the text: \{{domxref("window.scrollBy", "scrollBy()")}} results in {{domxref("window.scrollBy", "scrollBy()")}}.
-
{{TemplateLink("SVGElement")}}
-
Inserts an SVG element's name, properly styled and linked. For example: \{{SVGElement("circle")}} yields {{SVGElement("circle")}}.
-
- -

동일 문서내 섹션에 링크걸기

- -

To link to a section within the same article, you can use the {{TemplateLink("anch")}} macro. The syntax is straightforward: \{{anch("Name of destination section")}}. By default, the displayed link text is the title of that section, but you can add a second, optional, parameter indicating alternate text to use instead. Some examples:

- - - -

버그에 링크걸기

- -

You can link to a bug in Mozilla's Bugzilla database with the {{TemplateLink("bug")}} macro. This macro accepts a single parameter: the bug number to link to. For example, \{{bug(765642)}} looks like this: {{bug(765642)}}.

- -

Similarly, you can create links to bugs in other browsers and Web engines:

- -
-
WebKit (Safari, etc.)
-
{{TemplateLink("WebkitBug")}}: \{{webkitbug(31277)}} yields {{webkitbug(31277)}}.
-
- -

RFCs 에 링크걸기

- -

Much of the way the Internet works at a core level is documented in RFCs. You can easily reference RFCs using the {{TemplateLink("RFC")}} macro. For example, \{{RFC(2616)}} becomes {{RFC(2616)}}. You can, optionally, also provide alternate link text to use instead of a selected piece of text from the article or and/or the section number within the specification to which to link.

- -

XPCOM 인터페이스 정보에 링크걸기 

- -
-

The MDN staff no longer actively maintains the XPCOM documentation, but volunteer contributions are welcomel

-
- -

If you're documenting Mozilla internals, being able to easily create links to XPCOM interface documentation is helpful. There are a few macros used for this.

- -

The syntax for linking to the documentation for an XPCOM interface as a whole is just: \{{interface("interfacename")}}. For example, you might write:

- -
-

When you need to parse or create URIs, the \{{interface("nsIIOService")}} interface can help.

-
- -

The result looks like this:

- -
-

When you need to parse or create URIs, the {{interface("nsIIOService")}} interface can help.

-
- -

If you need to link to information about a specific method or attribute on an XPCOM interface, the {{TemplateLink("ifmethod")}} and {{TemplateLink("ifattribute")}} macros are for you. These accept as parameters the name of the interface and the name of the method or attribute to which you wish to reference. The {{TemplateLink("ifmethod")}} macro is particularly interesting, since it does some special formatting by adding the style guide-mandated parentheses after the method's name. For example, \{{ifmethod("nsIIOService", "newURI")}} results in {{ifmethod("nsIIOService", "newURI")}}. That's a case where you're being protected against possible changes in the style guide in the future!

- -

Mozilla 설정 문서에 링크걸기

- -

To insert the name of a Mozilla preference and make it link to the corresponding page in the Preference reference, use the {{TemplateLink("pref")}} macro. This accepts one parameter: the full name of the preference you wish to link to. For example, you can use \{{pref("javascript.options.showInConsole")}} to create this: {{pref("javascript.options.showInConsole")}}.

- -

Mozilla 소스 파일에 링크걸기

- -

You can link to files in Mozilla's source tree (although you probably won't do this often) using the {{TemplateLink("source")}} macro. Instead of specifying the full URL of the file, you can simply specify the path relative to the /source/ directory. For example: \{{source("browser/Makefile.in")}} creates this link: {{source("browser/Makefile.in")}}.

- -

You may also, optionally, specify alternative text to use for the link. For example, you can use \{{source("browser/Makefile.in", "the browser's makefile")}} to get the result: {{source("browser/Makefile.in", "the browser's makefile")}}.

- -
-

Please look at the {{anch("Using macros")}} documentation if you're interested in learning more about using macros, and check out our KumaScript documentation to learn more about the macro system itself.

-
- -

추천 콘텐츠에 링크걸기

- -

If you wish to create a list of related pages, or other recommended reading material, you should do so by creating a quicklinks box in the sidebar; this mechanism is replacing our old "See also" headings at the end of articles. For details on how to create quicklinks boxes, see Quicklinks.

- -

URL 정책

- -

For security reasons, you should only create links that use the following schemes:

- - - -

Others may or may not work, but are not supported and will probably be removed by editorial staff.

- -
-

Special URL schemes such as about: and chrome: are used by Firefox, Google Chrome, and some other browsers to provide access to special content such as preferences, debugging information, and so forth. These links do not work from article content, so please do not try to create links using these schemes within MDN articles. The same applies to the javascript: and jar: schemes, which are blocked by most modern browsers as a security precaution.

-
- -

{{EditorGuideQuicklinks}}

diff --git a/files/ko/mdn/guidelines/best_practices/index.html b/files/ko/mdn/guidelines/best_practices/index.html deleted file mode 100644 index d8c5f2b247..0000000000 --- a/files/ko/mdn/guidelines/best_practices/index.html +++ /dev/null @@ -1,34 +0,0 @@ ---- -title: 모범 사례 -slug: MDN/Guidelines/Best_practices -tags: - - Guide - - Guidelines - - MDN Meta -translation_of: MDN/Guidelines/Conventions_definitions ---- -
{{MDNSidebar}}

이 글은 MDN에서 추천하는 콘텐츠 작업 법을 설명합니다. 이 가이드라인은 더 나은 결과로 이끌 선호하는 일하는 법을 설명하거나 비슷한 일을 하는 여러 방법 중에서 결정에 조언을 제공합니다.

- -

콘텐츠 복사하기

- -

때때로, 여러 페이지에 같은 텍스트를 재사용해야 합니다 (또는 한 페이지의 콘텐츠를 다른 페이지를 위한 템플릿으로 사용하고 싶습니다). 세 가지 선택 사항이 있습니다:

- - diff --git a/files/ko/mdn/guidelines/code_guidelines/code_guidelines/index.html b/files/ko/mdn/guidelines/code_guidelines/code_guidelines/index.html deleted file mode 100644 index 093f50ae47..0000000000 --- a/files/ko/mdn/guidelines/code_guidelines/code_guidelines/index.html +++ /dev/null @@ -1,159 +0,0 @@ ---- -title: 모든 코드에 대한 일반 가이드라인 -slug: MDN/Guidelines/Code_guidelines/Code_guidelines -tags: - - Code - - General - - Guide - - MDN Meta - - 가이드 - - 가이드라인 - - 코드 블럭 - - 코드 블록 - - 코드 스타일 -translation_of: MDN/Guidelines/Code_guidelines/General ---- -
{{MDNSidebar}}{{IncludeSubnav("/ko/docs/MDN")}}
- -

아래 코드 예제 가이드라인에서 HTML, CSS, JavaScript 나 다른 어느 코드로 예로 들건 , 모든 코드 타입에 적용됩니다.

- -

 이 문서 내용은

- - - -

들여쓰기, 여백주기, 사이즈

- -

들여쓰기

- -

모든 코드는 2 스페이스로 들여쓰기 해야합니다. 예를 들면:

- -
<div>
-  <p>This is my paragraph.</p>
-</div>
- -
function myFunc() {
-  if(thingy) {
-    console.log('Yup, that worked.');
-  }
-}
- -

코드 한 줄 길이

- -

한 행의 코드는 최대 80자 (대화형 예제는 64자) 이내로 제한 되어야 합니다.  가독성을 위해 합리적으로 행을 분리 하는 것 좋지만 모범 사례를 벗어나지는 마십시오.

- -

예를 들면, 아래는 안 좋은 예입니다.

- -
let tommyCat = 'Said Tommy the Cat as he reeled back to clear whatever foreign matter may have nestled its way into his mighty throat. Many a fat alley rat had met its demise while staring point blank down the cavernous barrel of this awesome prowling machine.';
- -

이것은 좀 낫지만, 그래도 여전히 좋지 않습니다:

- -
let tommyCat = 'Said Tommy the Cat as he reeled back to clear whatever foreign '
-+ 'matter may have nestled its way into his mighty throat. Many a fat alley rat '
-+ 'had met its demise while staring point blank down the cavernous barrel of '
-+ 'this awesome prowling machine.';
- -

템플릿 리터럴을 사용하는 것이 더 좋습니다:

- -
let tommyCat = `Said Tommy the Cat as he reeled back to clear whatever foreign
-  matter may have nestled its way into his mighty throat. Many a fat alley rat
-  had met its demise while staring point blank down the cavernous barrel of
-  this awesome prowling machine.`;
- -

코드 블럭 높이

- -

코드 블럭은 필요한 만큼 길어야 하지만 너무 길면 안됩니다. 15에서 25 라인 정도의 길이가 이상적입니다. 코드 블럭이 너무 길어진다면, 가장 유용한 스니펫만 보여주고, 나머지 부분은 깃허브 저장소나 코드펜 같은 링크로 연결하세요.

- -

예제 디스플레이 가이드라인

- -

렌더링 된 예제 크기

- -

MDN 메인 콘텐츠 창은 데스크탑에서 약  700px 크기 이므로, 삽입된 MDN 예제는 ( 삽입된 예제를 100% 너비로 설정했을 때 ) 해당 너비에서 잘 보여야 합니다.

- -

높이의 경우, 최대한의 화면 가독성을 위해 가능하면 렌더링 된 예제 높이를 700px 아래로 유지하는 것을 추천합니다.

- -

모바일 디바이스에서도 예제가 잘 보이도록 어느 정도는 반응형으로 동작되도록 예제를 작성하는데 신경써야 합니다.

- -

이미지나 다른 미디어의 사용

- -

가끔 이미지나 다른 미디어를 예제에 삽입하고 싶을 때가 있습니다. 그럴 때에는:

- - - -

컬러의 사용

- -

소문자 16진수 대신, 음영이나 주요 컬러(즉, 검은색, 흰색, 빨간색)는 키워드를 사용할 수있습니다. 필요한 경우에만 좀 더 복잡한 컬러스킴을 사용하세요.( 예를 들면, 투명색이 필요할 때)

- -

주요 "기본" 컬러는 키워드로 설정하는것이 좋습니다. 예를 들면:

- -
color: black;
-color: white;
-color: red;
- -

좀 더 복잡한 컬러는 rgb() 를 사용합니다. (반 투명 색 포함):

- -
color: rgb(0, 0, 0, 0.5);
-color: rgb(248, 242, 230);
- -

16진수 컬러를 사용해야 한다면, 소문자를 이용하세요:

- -
color: #058ed9;
-color: #a39a92;
- -

그리고 가능한 곳에는 단축형태를 사용하세요:

- -
color: #ff0;
-color: #fff;
- -

MDN's Fiori 가이드라인(프론트엔드 코드베이스용)은 전체 MDN 디자인에 사용된 유용한 컬러셋을 포함하고 있습니다. ( 역자주: 영어 원문 링크가 깨져 MDN Fiori 깃허브 리포 에서 비슷한 링크를 찾아 연결했습니다.)

- -

좋은 예시와 나쁜 예시 강조

- -

이 가이드라인에서 알 수 있는 것처럼, 좋은 실습예시는 연두색에 웃는얼굴로 강조되며, 나쁜 실습 예시는 슬픈표정에 빨간 바탕으로 강조됩니다.

- -

이 처럼 하려면, MDN 에디터 콘트롤로 코드 블럭을 <pre> 블럭이 되도록 하고, 적절한 문법 강조를 설정해야 합니다. 소스 코드는 아래와 비슷하게 보일겁니다:

- -
<pre class="brush: js">
-function myFunc() {
-  console.log('Hello!');
-};</pre>
- -

이 상태에서 좋은 예시로 만들려면, class 속성의 오른쪽 따옴표 바로 앞에 example-good을 넣으면 됩니다:

- -
<pre class="brush: js example-good">
-  ...
- -

나쁜 예시로 만들려면, class 속성의 오른쪽 따옴표 바로 앞에 example-bad를 넣으면 됩니다:

- -
<pre class="brush: js example-bad">
-  ...
- -

우리는 당신이 이 기능을 사용하길 권장합니다. 모든 곳에 사용할 필요는 없습니다. 당신의 코드에서 좋은 예와 나쁜 예를 구분할 필요가 있을때 사용하세요.

- -

레퍼런스 페이지에서 문법 섹션 작성

- -

MDN 레퍼런스 페이지에는  JavaScript 메서드, CSS 속성, HTML 요소 등과 같이 기능의 구문이 무엇을 할 수 있고, 어때야 하는지 명확하게 보여주는 문법 섹션(Syntax section)이 포함되어 있습니다. 이 내용을 작성하는 가이드라인은 Syntax sections 문서를 참고하세요.

diff --git a/files/ko/mdn/guidelines/code_guidelines/general/index.html b/files/ko/mdn/guidelines/code_guidelines/general/index.html new file mode 100644 index 0000000000..093f50ae47 --- /dev/null +++ b/files/ko/mdn/guidelines/code_guidelines/general/index.html @@ -0,0 +1,159 @@ +--- +title: 모든 코드에 대한 일반 가이드라인 +slug: MDN/Guidelines/Code_guidelines/Code_guidelines +tags: + - Code + - General + - Guide + - MDN Meta + - 가이드 + - 가이드라인 + - 코드 블럭 + - 코드 블록 + - 코드 스타일 +translation_of: MDN/Guidelines/Code_guidelines/General +--- +
{{MDNSidebar}}{{IncludeSubnav("/ko/docs/MDN")}}
+ +

아래 코드 예제 가이드라인에서 HTML, CSS, JavaScript 나 다른 어느 코드로 예로 들건 , 모든 코드 타입에 적용됩니다.

+ +

 이 문서 내용은

+ + + +

들여쓰기, 여백주기, 사이즈

+ +

들여쓰기

+ +

모든 코드는 2 스페이스로 들여쓰기 해야합니다. 예를 들면:

+ +
<div>
+  <p>This is my paragraph.</p>
+</div>
+ +
function myFunc() {
+  if(thingy) {
+    console.log('Yup, that worked.');
+  }
+}
+ +

코드 한 줄 길이

+ +

한 행의 코드는 최대 80자 (대화형 예제는 64자) 이내로 제한 되어야 합니다.  가독성을 위해 합리적으로 행을 분리 하는 것 좋지만 모범 사례를 벗어나지는 마십시오.

+ +

예를 들면, 아래는 안 좋은 예입니다.

+ +
let tommyCat = 'Said Tommy the Cat as he reeled back to clear whatever foreign matter may have nestled its way into his mighty throat. Many a fat alley rat had met its demise while staring point blank down the cavernous barrel of this awesome prowling machine.';
+ +

이것은 좀 낫지만, 그래도 여전히 좋지 않습니다:

+ +
let tommyCat = 'Said Tommy the Cat as he reeled back to clear whatever foreign '
++ 'matter may have nestled its way into his mighty throat. Many a fat alley rat '
++ 'had met its demise while staring point blank down the cavernous barrel of '
++ 'this awesome prowling machine.';
+ +

템플릿 리터럴을 사용하는 것이 더 좋습니다:

+ +
let tommyCat = `Said Tommy the Cat as he reeled back to clear whatever foreign
+  matter may have nestled its way into his mighty throat. Many a fat alley rat
+  had met its demise while staring point blank down the cavernous barrel of
+  this awesome prowling machine.`;
+ +

코드 블럭 높이

+ +

코드 블럭은 필요한 만큼 길어야 하지만 너무 길면 안됩니다. 15에서 25 라인 정도의 길이가 이상적입니다. 코드 블럭이 너무 길어진다면, 가장 유용한 스니펫만 보여주고, 나머지 부분은 깃허브 저장소나 코드펜 같은 링크로 연결하세요.

+ +

예제 디스플레이 가이드라인

+ +

렌더링 된 예제 크기

+ +

MDN 메인 콘텐츠 창은 데스크탑에서 약  700px 크기 이므로, 삽입된 MDN 예제는 ( 삽입된 예제를 100% 너비로 설정했을 때 ) 해당 너비에서 잘 보여야 합니다.

+ +

높이의 경우, 최대한의 화면 가독성을 위해 가능하면 렌더링 된 예제 높이를 700px 아래로 유지하는 것을 추천합니다.

+ +

모바일 디바이스에서도 예제가 잘 보이도록 어느 정도는 반응형으로 동작되도록 예제를 작성하는데 신경써야 합니다.

+ +

이미지나 다른 미디어의 사용

+ +

가끔 이미지나 다른 미디어를 예제에 삽입하고 싶을 때가 있습니다. 그럴 때에는:

+ + + +

컬러의 사용

+ +

소문자 16진수 대신, 음영이나 주요 컬러(즉, 검은색, 흰색, 빨간색)는 키워드를 사용할 수있습니다. 필요한 경우에만 좀 더 복잡한 컬러스킴을 사용하세요.( 예를 들면, 투명색이 필요할 때)

+ +

주요 "기본" 컬러는 키워드로 설정하는것이 좋습니다. 예를 들면:

+ +
color: black;
+color: white;
+color: red;
+ +

좀 더 복잡한 컬러는 rgb() 를 사용합니다. (반 투명 색 포함):

+ +
color: rgb(0, 0, 0, 0.5);
+color: rgb(248, 242, 230);
+ +

16진수 컬러를 사용해야 한다면, 소문자를 이용하세요:

+ +
color: #058ed9;
+color: #a39a92;
+ +

그리고 가능한 곳에는 단축형태를 사용하세요:

+ +
color: #ff0;
+color: #fff;
+ +

MDN's Fiori 가이드라인(프론트엔드 코드베이스용)은 전체 MDN 디자인에 사용된 유용한 컬러셋을 포함하고 있습니다. ( 역자주: 영어 원문 링크가 깨져 MDN Fiori 깃허브 리포 에서 비슷한 링크를 찾아 연결했습니다.)

+ +

좋은 예시와 나쁜 예시 강조

+ +

이 가이드라인에서 알 수 있는 것처럼, 좋은 실습예시는 연두색에 웃는얼굴로 강조되며, 나쁜 실습 예시는 슬픈표정에 빨간 바탕으로 강조됩니다.

+ +

이 처럼 하려면, MDN 에디터 콘트롤로 코드 블럭을 <pre> 블럭이 되도록 하고, 적절한 문법 강조를 설정해야 합니다. 소스 코드는 아래와 비슷하게 보일겁니다:

+ +
<pre class="brush: js">
+function myFunc() {
+  console.log('Hello!');
+};</pre>
+ +

이 상태에서 좋은 예시로 만들려면, class 속성의 오른쪽 따옴표 바로 앞에 example-good을 넣으면 됩니다:

+ +
<pre class="brush: js example-good">
+  ...
+ +

나쁜 예시로 만들려면, class 속성의 오른쪽 따옴표 바로 앞에 example-bad를 넣으면 됩니다:

+ +
<pre class="brush: js example-bad">
+  ...
+ +

우리는 당신이 이 기능을 사용하길 권장합니다. 모든 곳에 사용할 필요는 없습니다. 당신의 코드에서 좋은 예와 나쁜 예를 구분할 필요가 있을때 사용하세요.

+ +

레퍼런스 페이지에서 문법 섹션 작성

+ +

MDN 레퍼런스 페이지에는  JavaScript 메서드, CSS 속성, HTML 요소 등과 같이 기능의 구문이 무엇을 할 수 있고, 어때야 하는지 명확하게 보여주는 문법 섹션(Syntax section)이 포함되어 있습니다. 이 내용을 작성하는 가이드라인은 Syntax sections 문서를 참고하세요.

diff --git a/files/ko/mdn/guidelines/conventions_definitions/index.html b/files/ko/mdn/guidelines/conventions_definitions/index.html new file mode 100644 index 0000000000..d8c5f2b247 --- /dev/null +++ b/files/ko/mdn/guidelines/conventions_definitions/index.html @@ -0,0 +1,34 @@ +--- +title: 모범 사례 +slug: MDN/Guidelines/Best_practices +tags: + - Guide + - Guidelines + - MDN Meta +translation_of: MDN/Guidelines/Conventions_definitions +--- +
{{MDNSidebar}}

이 글은 MDN에서 추천하는 콘텐츠 작업 법을 설명합니다. 이 가이드라인은 더 나은 결과로 이끌 선호하는 일하는 법을 설명하거나 비슷한 일을 하는 여러 방법 중에서 결정에 조언을 제공합니다.

+ +

콘텐츠 복사하기

+ +

때때로, 여러 페이지에 같은 텍스트를 재사용해야 합니다 (또는 한 페이지의 콘텐츠를 다른 페이지를 위한 템플릿으로 사용하고 싶습니다). 세 가지 선택 사항이 있습니다:

+ + diff --git a/files/ko/mdn/guidelines/does_this_belong_on_mdn/index.html b/files/ko/mdn/guidelines/does_this_belong_on_mdn/index.html new file mode 100644 index 0000000000..46f6395a52 --- /dev/null +++ b/files/ko/mdn/guidelines/does_this_belong_on_mdn/index.html @@ -0,0 +1,139 @@ +--- +title: 이건 MDN에 있나요? +slug: MDN/Contribute/Does_this_belong +translation_of: MDN/Guidelines/Does_this_belong_on_MDN +--- +
{{MDNSidebar}}
{{IncludeSubnav("/ko/docs/MDN")}}
+ +

무엇인가를 문서로 남겨두겠다는 생각을 하기 시작했다면,  그 문서를 어디에 둘지도 고민해보았을 겁니다. 문서가 위치할 수 있는 몇 가지 장소가 있고, MDN이 웹에서 가장 큰 문서 저장소 중 하나이지만 유일한 옵션은 아닙니다. 또한 소스 코드에 문서를 보관해둘 수도 있고, Mozilla 위키나 git 저장소의 README 파일에 저장해 두어도 좋습니다. 이 글에서는 어느 방법이 여러분들의 문서와 어울릴지를 판단하는데 도움이 되기 위해서 쓰였습니다.

+ +

MDN에는 뭐가 있죠?

+ +

우리는 MDN에 정말 다양한 주제를 다룹니다. 하지만 완전히 MDN에 있어서는 안될 몇 가지도 있습니다. 이 섹션은 여러분의 문서가 MDN에 있어도 괜찮은지 판단할 수 있도록 도와주겠습니다.

+ +

MDN에서 다루는 것

+ +

우리는 MDN에서 정말 많은 내용을 다루고 있습니다. 일반적으로 완전히 제작되었거나 배포 중인 Mozilla 제품이나, 웹에 공개된 열린 기술이라면, MDN에 문서로 남겨둡니다.

+ +

우리들이 다루고 있는 내용 몇가지를 맛보기로 보여드리겠습니다. 전체 리스트는 아니지만 몇가지 아이디어는 줄 수 있을 겁니다.

+ + + +
+

참고하세요: 우리는 Mozilla 기술이 아니더라도 Web에 공개되어 있는 한 다룰 수 있다는 점이 중요합니다. 가령, 우리는 Webkit 전용 CSS 프로퍼티를 설명해놓은 문서도 있습니다.

+
+ +

우리가 다루지 않는 것

+ +

MDN에 문서로 남겨져서는 안되는 명백한 것인지 아닌지에 대해 스스로 질문해볼 수 있습니다.

+ + + +

저 질문 중 하나라도 "예"라고 답변할 수 있다면, MDN에 있어서는 안될 문서입니다. 저 질문 모두에 "아니요"라고 대답할 수 있다면, MDN에 문서로 보관할지 진지하게 고민할 때가 되었다는 겁니다!

+ +

MDN에 문서로 남겨두면 좋은 점

+ +

MDN에 문서로 남겨두면 좋은 점이 굉장히 많답니다.

+ +

글을 쓰는 사람들이 굉장히 많습니다

+ +

MDN 공동체는 굉장히 큽니다. 정말 큽니다. 큰 것들을 작게 보이게 만들 정도로 큽니다. 농담이 아니라, 우리는 굉장히 많은 사람들과 MDN에 있는 자료를 만들어내며 관리하고 있습니다. 전세계 모든 땅(인정할게요. 남극까지는 잘 모르겠어요.)의 작가, 편집자들과 함께하고 있기 때문에, 글을 쓰려는 사람들은 무조건 득 보는 거에요.

+ + + +

Do you want your development team to be entirely responsible for the production of documentation? That's likely if your documentation is maintained elsewhere.

+ +

유지보수

+ +

Because of the sheer number of contributors, there's usually someone on hand to watch for problems with your content: from spam control to copy-editing, things can happen around the clock. Here's just a taste of what our team can do:

+ +
+
스팸 제거
+
스팸이 발생하면 우리들이 처리합니다.
+
편집
+
여러분 생각보다 필력이 달려도 걱정하실 것 없습니다. 여러분이 쓴 글을 다른 사람들이 읽을 수 있도록 해주겠습니다.
+
스타일의 일관성
+
여러분이 작성한 문서 하나에서만 지켜지는 일관성이 아니라, 다른 문서와 함께 있을 때에도 일관적인 스타일을 가지고 있을지 봐주겠습니다.
+
컨텐츠 관리
+
Our team will help ensure that the documentation is cross-linked with other relevant materials, that articles are put in the right places, and that menus and other infrastructure is built to make it easy to follow and understand.
+
+ +

다른 곳에 문서로 남겨두는 경우

+ +

MDN 말고 다른 곳에다가 여러분이 만든 작업물을 문서로 남겨둘 이유도 없는 건 아닙니다. 그런 이유에 대해서 몇가지 살펴보도록 하고, 각각 장단점을 찾아보도록 할게요.

+ +

계획이나 진행 상황

+ +

간단합니다. 계획, 진행 상황, 요청에 대한 문서는 MDN에 남기면 안됩니다.

+ +

Github에 올라온 프로젝트

+ +

Mozilla의 몇몇 프로젝트는 Github에 올라와 있습니다. 또, Github에는 문서를 보관하기 위해 자기네들만의 위키 비스무리한 시스템을 가지고 있어요. 몇몇 팀은 거기에다가 문서를 남겨두기를 더 좋아합니다. 여러분만의 문서를 만들어갈 생각이라면 아무래도 그쪽이 더 편하고 좋겠죠. 하지만 몇가지 사실을 기억하세요.

+ + + +

물론 이런 점들이 여러분들에게 별로 문제가 되지 않거나 문제가 되더라도 딱히 불편한 점이 없을 수도 있습니다. 몇몇 팀은 문서로 남기겠다는 필요성이 별로 없어서 코드 안에서만 작업하고 문서를 남겨두기도 합니다.

+ +

소스 안에 문서를 남겨두고 싶은 경우

+ +

몇몇 팀은 소스 저장소에다가 자신들의 문서를 저장하는 걸 더 선호하기도 합니다. 내부 프로젝트나 라이브러리 프로젝트에서는 꽤나 흔한 일이긴 한데요. 코드를 쓰듯이 자신들의 기술을 문서로 남길 수 있다는 점에서 이점이 있기는 합니다. 하지만 그만큼 단점도 있지요.

+ + + +

여전히 몇몇 프로젝트에서 이런 방법을 사용할 수 없는 건 아닙니다. (오히려 좋은 방법일 수도 있습니다.) 작은 프로젝트나 별로 관심을 얻을 생각을 하지 않는 프로젝트에는 특히 그렇죠.

+ +

나중에는

+ +

It's worth mentioning that someday we intend to make it possible to present off-site content as if it were part of MDN, and that we hope to one day have tools to actually import content from other sites onto MDN. However, there's no timeline in place for making this happen, and even once it does, it will not be as effective as building the documentation directly on MDN.

diff --git a/files/ko/mdn/guidelines/style_guide/index.html b/files/ko/mdn/guidelines/style_guide/index.html deleted file mode 100644 index 507f30e228..0000000000 --- a/files/ko/mdn/guidelines/style_guide/index.html +++ /dev/null @@ -1,833 +0,0 @@ ---- -title: MDN 스타일 가이드 -slug: MDN/Guidelines/Style_guide -tags: - - Documentation - - Guide - - MDN - - MDN Meta - - MDN 스타일 가이드 - - 스타일 가이드 - - 스타일 가이드 작성 -translation_of: MDN/Guidelines/Writing_style_guide ---- -
{{MDNSidebar}}
- -
{{IncludeSubnav("/ko/docs/MDN")}}
- -

정돈되고 일관적이며 읽기 쉬운 문서를 제공하고자, MDN 웹 문서 스타일 안내서는 글의 정렬, 철자, 서식 방법 등을 정리합니다. 이 가이드는 엄격한 규칙이라기보다 가이드라인입니다. 우리는 형식보다는 내용에 더 관심이 있습니다. 그러니 기여하기 전에 스타일 가이드를 배워야 한다는 부담을 느끼시지 않아도 됩니다. 하지만 나중에 다른 부지런한 지원자가 이 가이드를 따라 당신의 작업물을 편집할 수 있습니다. 만약 그런 일이 벌어지더라도 화내거나 놀라지 마세요.

- -

이 가이드의 언어적 측면의 내용은 영문을 위주로 작성되었습니다. 기타 다른 언어는 언어만의 고유한 스타일 가이드를 가질 수 있으며, 새롭게 만드는 것도 좋습니다. 이 페이지들은 지역화 팀 페이지의 하위 페이지로 생성되어야 합니다.

- -

MDN이 아닌 다른 사이트를 위해 쓰여진 콘텐츠를 적용하는 스타일 표준에 대한 내용은 One Mozilla 스타일 가이드를 참고하세요.

- -

기본

- -

아무리 방대한 문서화 스타일 가이드라도 가장 기본적인 텍스트 표준에서 시작하는 것이 좋습니다. 텍스트 표준은 일관된 문서화를 유지하는데 도움을 줍니다. 이어지는 섹션에서 도움이 될 만한 이런 기본들을 설명합니다.

- -

페이지 제목

- -

페이지 제목은 검색 결과에 사용되며, 페이지 상단의 페이지 이동 경로(breadcrumb) 목록에 페이지 계층 구조를 구성하는 데 사용됩니다. (페이지 상단과 검색 결과 상단에 표시되는) 페이지 제목은 페이지 "슬러그"와 다를 수 있습니다. "슬러그"는 페이지 URL의 일부로   "<locale>/docs/" 다음에 따라오는 부분입니다.

- -

 제목과  섹션제목 대문자넣기(Capitalization)

- -

페이지 타이틀과 섹션 제목은 헤드라인 스타일 대문자넣기보다는 (첫번째 단어와 필요한 명사만 대문자를 넣는 방식의)일반 문장 스타일 대문자넣기를 해야 합니다:

- - - -

이런 스타일 규칙이 적용되기 전에 작성된 수많은 예전 문서들이 현재도 존재합니다. 자유롭게 해당 문서들을 수정해도 좋습니다. 우리는 점차적으로 스타일 규칙을 맞춰 나갈겁니다.

- -

제목 및 슬러그(slug) 선택하기

- -

페이지 슬러그는 짧게 만들어야 합니다. 새로운 레벨의 계층을 만들때, 그 레벨의 요소는 슬러그에서 한,두 단어로 표현되어야 합니다.

- -

반면에, 페이지 제목은 ,합리적인 범위내에서, 당신이 원하는 만큼 길어도 됩니다. 그리고 구체적이어야 합니다.

- -

신규 서브트리 생성하기

- -

어떤 토픽이나 주제 영역에 대한 문서를 추가할 필요가 있다면, 당신이 선택할 일반적인 방법은 랜딩 페이지를 생성한 이후, 각각의 개별적인 문서의 서브페이지를 추가하는 것입니다. 랜딩 페이지는 토픽이나 기술을 설명하는 한두 개의 문단으로 시작한 이후, 각 페이지의 설명이 달린 서브페이지의 목록을 전달해야합니다. 우리가 개발한 몇가지 매크로로 페이지를 목록에 자동으로 삽입할 수 있습니다.

- -

예를 들면 , 아래와 같이 구성된 자바스크립트 가이드를 생각해봅시다.

- - - -

문서를 문서구조 최상층에 두는 것은 최대한 피해야 합니다. 이렇게 하면 사이트가 느려지며, 사이트 탐색과 네비게이션을 비효율적으로 만듭니다.

- -
-

주목할 점: 문서 추가는 페이지 생성 권한이 필요합니다.

-
- -

General article content guidelines

- -

When writing any document, it's important to know how much to say. If you ramble on too long, or provide excessive detail, the article becomes tedious to read and nobody will use it. Getting the amount of coverage right is important for several reasons. Among those reasons: to ensure that the reader finds the information they truly need, and to provide enough quality material for search engines to adequately analyze and rank the article.

- -

We'll discuss the former (providing the information the reader may need) here. To learn a little about ensuring that pages are properly classified and ranked by search engines, see the article How to write for SEO on MDN.

- -

The goal is to write pages that include all the information that readers may need without going on too long about it all. We have a few recommendations in this area.

- -

Consider your audience

- -

Keep in mind that these are guidelines. Some of these tips may not apply in every case. Certainly keep your article's audience in mind. An article on advanced network techniques likely doesn't need to go into as much detail about basic networking concepts as the typical article on networking code, for instance.

- -

Provide a useful summary

- -

Make sure the article's summary—that is, the opening paragraph or paragraphs before the first heading—provides enough information for the reader to understand if the article is likely to be covering what they're interested in reading about.

- -

In guide or tutorial content, the summary should let the reader know what topics will be covered and what they're already expected to know, if anything. It should mention the technology, technologies, and/or APIs that are being documented or discussed, with links to those, and it should offer hints as to the situations in which the article's contents might be useful.

- -
Example: Too short!
- -

This example of a summary is far too short. It leaves out too much information, such as what it means exactly to "stroke" text, where the text is drawn, and so forth.

- -
CanvasRenderingContext2D.strokeText() draws a string.
- -
Example: Too long!
- -

Here, we've updated the summary, but now it's far too long. Too much detail is included, and the text gets far too much into other methods and properties.

- -

Instead, the summary should focus on the strokeText() method, and should refer to the appropriate guide where the other details are offered.

- -
-

When called, the Canvas 2D API method CanvasRenderingContext2D.strokeText() strokes the characters in the specified string beginning at the coordinates specified, using the current pen color.In the terminology of computer graphics, "stroking" text means to draw the outlines of the glyphs in the string without filling in the contents of each character with color.

- -

The text is drawn using the context's current font as specified in the context's {{domxref("CanvasRenderingContext2D.font", "font")}} property.

- -

The placement of the text relative to the specified coordinates are determined by the context's textAlign, textBaseline, and direction properties. textAlign controls the placement of the string relative to the X coordinate specified; if the value is "center", then the string is drawn starting at x - (stringWidth / 2), placing the specified X-coordinate in the middle of the string. If the value is "left", the string is drawn starting at the specified value of x. And if textAlign is "right", the text is drawn such that it ends at the specified X-coordinate.

- -

(etc etc etc...)

- -

You can, optionally, provide a fourth parameter that lets you specify a maximum width for the string, in pixels. If you provide this parameter, the text is compressed horizontally or scaled (or otherwise adjusted) to fit inside a space that wide when being drawn.

- -

You can call the fillText() method to draw a string's characters as filled with color instead of only drawing the outlines of the characters.

-
- -
Example: Much better!
- -

Here we see a much better overview for the strokeText() method.

- -
-

The {{domxref("CanvasRenderingContext2D")}} method strokeText(), part of the Canvas 2D API, strokes—that is, draws the outlines of—the characters of a specified string, anchored at the position indicated by the given X and Y coordinates. The text is drawn using the context's current {{domxref("CanvasRenderingContext2D.font", "font")}}, and is justified and aligned according to the {{domxref("CanvasRenderingContext2D.textAlign", "textAlign")}}, {{domxref("CanvasRenderingContext2D.textBaseline", "textBaseline")}}, and {{domxref("CanvasRenderingContext2D.direction", "direction")}} properties.

- -

For more details and further examples, see {{SectionOnPage("/en-US/docs/Learn/JavaScript/Client-side_web_APIs/Drawing_graphics", "Text")}} in the Learning Area as well as our main article on the subject, Drawing text.

-
- -

Include all relevant examples

- -

More pages should have examples than not. The majority of pages probably deserve multiple examples, in fact.

- -

It's important to ensure that you use examples to clarify what every parameter is used for, and to clarify any edge cases that may exist. You should also use examples to demonstrate solutions for common tasks, and you should use examples to demonstrate solutions to problems that may arise.

- -

Each example should be preceded by text explaining what the example does and anything the reader should know before beginning to read or try out the example.

- -
Code Examples
- -

Each piece of code should include an explanation of how it works. Keep in mind that it may make sense to break up a large piece of code into smaller portions so they can be described individually.

- -

The text following each piece of code should explain anything relevant, using an appropriate level of detail.

- - - -

When using the live sample system, it's helpful to be aware that all of the {{HTMLElement("pre")}} blocks in the area that contains the sample are concatenated together before running the example, which lets you break any or all of the HTML, CSS, and JavaScript into multiple segments, each optionally with its own descriptions, headings, and so forth. This makes documenting code incredibly powerful and flexible.

- -

Overly-short articles are hard to find

- -

If an article is "thin"—that is, too short—it may not be indexed properly (or at all) by search engines. As a rule of thumb, the article's body text should be at least 250–300 words. Don't artificially inflate a page, but treat this guideline as a minimum target length when possible.

- -

Sections, paragraphs, and newlines

- -

Use heading levels in decreasing order: {{HTMLElement("h2")}} then {{HTMLElement("h3")}} then {{HTMLElement("h4")}}, without skipping levels.

- -

H2 is the highest level allowed because H1 is reserved for the page title. If you need more than three or four levels of headers, consider breaking up the article into several smaller articles with a landing page, and linking them together using the following macros: {{TemplateLink("Next")}}, {{TemplateLink("Previous")}}, and {{TemplateLink("PreviousNext")}}.

- -

Heading dos and donts

- - - -

The Enter (or Return) key on your keyboard starts a new paragraph. To insert a newline, rather than a new paragraph (that is, to create a {{HTMLElement("br")}} instead of a {{HTMLElement("p")}}), hold down the Shift key while pressing Enter.

- -

Lists

- -

Lists should be formatted and structured uniformly across all contributions. Individual list items should be written with suitable punctuation, regardless of the list format. However, depending on the type of list you are creating, you will want to adjust your writing as described in the sections below.

- -

Bulleted lists

- -

Bulleted lists should be used to group related pieces of concise information. Each item in the list should follow a similar sentence structure. Phrases and sentences in bulleted lists should include standard punctuation. Periods must appear at the end of each sentence in a bulleted list, including the item's final sentence, just as would be expected in a paragraph.

- -

An example of a correctly structured bulleted list:

- -
-

In this example we should include:

- - -
- -

Note how the same sentence structure repeats from bullet to bullet. In this example, each bullet point states a condition followed by a comma and a brief explanation, and each item in the list ends with a period.

- -

Numbered lists

- -

Numbered lists are used primarily to enumerate steps in a set of instructions. Because instructions can be complex, clarity is a priority, especially if the text in each list item is lengthy. As with bulleted lists, follow standard punctuation usage.

- -

An example of a correctly structured numbered list:

- -
-

In order to correctly structure a numbered list, you should:

- -
    -
  1. Open with a heading or brief paragraph to introduce the instructions. It's important to provide the user with context before beginning the instructions.
    2. -
  2. Start creating your instructions, and keep each step in its own numbered item. Your instructions may be quite extensive, so it is important to write clearly and use correct punctuation.
    3. -
  3. After you have finished your instructions, close off the numbered list with a brief summary or explanation of the expected outcome upon completion.
    4. -
- -

This is an example of writing a closing explanation. We have created a short numbered list that provides instructive steps to produce a numbered list with the correct formatting.

-
- -

Note how the items in numbered lists read like short paragraphs. Because numbered lists are routinely used for instructional purposes, or to walk someone through an orderly procedure, be sure to keep each item focused: one item per number or step.

- -

Text formatting and styles

- -

Use the "Formatting Styles" drop-down list to apply predefined styles to selected content.

- -
-

The "Note Box" style is used to call out important notes, like this one.

-
- -
-

Similarly, the "Warning Box" style creates warning boxes like this.

-
- -

Unless specifically instructed to do so, do not use the HTML style attribute to manually style content. If you can't do it using a predefined class, ask for help in the MDN discussion forum.

- -

Code sample style and formatting

- -
-

Note: This section deals with the styling/formatting of code as it appears on an MDN article. If you want guidelines on actually writing code examples, see our Code sample guidelines.

-
- -

Tabs and line breaks

- -

Use two spaces per tab in all code examples. Indent the code cleanly, with open-brace ("{") characters on the same line as the statement that opens the block. For example:

- -
if (condition) {
-  /* handle the condition */
-} else {
-  /* handle the "else" case */
-}
-
- -

Long lines shouldn't be allowed to stretch off horizontally to the extent that they require horizontal scrolling to read. Instead, break at natural breaking points. Some examples follow:

- -
if (class.CONDITION || class.OTHER_CONDITION || class.SOME_OTHER_CONDITION
-       || class.YET_ANOTHER_CONDITION ) {
-  /* something */
-}
-
-var toolkitProfileService = Components.classes["@mozilla.org/toolkit/profile-service;1"]
-                           .createInstance(Components.interfaces.nsIToolkitProfileService);
-
- -

Inline code formatting

- -

Use the "Code" button (labeled with two angle brackets "<>") to apply inline code-style formatting to function names, variable names, and method names. (This uses the {{HTMLElement("code")}} element). For example: "the frenchText() function".

- -

Method names should be followed by a pair of parentheses: doSomethingUseful(). The parentheses help differentiate methods from other code terms.

- -

Syntax highlighting

- -

Screenshot of the 'Syntax Highlighter' menu.Entire lines (or multiple lines) of code should be formatted using syntax highlighting rather than the {{HTMLElement("code")}} element. Select the appropriate language from the language list button (the one with the two code blocks), as seen in the screenshot to the right. This will insert a preformatted code box with line numbers and syntax highlighting for the chosen language.

- -
-

Note: Do not use the {{HTMLElement("code")}} element inside the {{HTMLElement("pre")}} block!

- -

While this structure is used on some sites, we do not do so on MDN; nesting these elements will break certain aspects of our styling.

-
- -

The following example shows text with JavaScript formatting:

- -
for (let i = 0, j = 9; i <= 9; i++, j--)
-  document.writeln("a[" + i + "][" + j + "]= " + a[i][j]);
- -

If no appropriate language is available, use ("No Highlight" in the language menu). This will result in code without syntax highlighting:

- -
x = 42;
- -

Syntax definitions

- -

When writing the syntax description section of a reference page, use the "Syntax Box" option in the "Styles" drop-down menu in the editor toolbar. This creates a specially-formatted box used specifically for syntax definitions, distinguishing them from other code blocks.

- -

Blocks not referring to code

- -

There are a few use cases where a <pre> block does not refer to code and doesn't have syntax highlighting nor line numbers. In such cases you should add a <pre> without a class attribute. Those cases include things like tree structures:

- -
root/
-
-  folder1/
-    file1
-
-  folder2/
-    file2
-    file3
-
- -

To create preformatted content without syntax highlighting and line numbers click the "pre" button in the toolbar. Then start to type the text.

- -

Styling mentions of HTML elements

- -

There are specific rules to follow when writing about HTML elements. These rules produce consistent descriptions of elements and their components. They also ensure correct linking to detailed documentation.

- -
-
Element names
-
Use the {{TemplateLink("HTMLElement")}} macro, which creates a link to the page for that element. For example, writing \{{HTMLElement("title")}} produces "{{HTMLElement("title")}}". If you don't want to create a link, enclose the name in angle brackets and use the "Inline Code" style (e.g., <title>).
-
Attribute names
-
Use "Inline Code" style to put attribute names in code font. Additionally, put them in bold face when the attribute is mentioned in association with an explanation of what it does, or the first time it's used in the article.
-
Attribute definitions
-
Use the {{TemplateLink("htmlattrdef")}} macro (e.g., \{{htmlattrdef("type")}}) for the definition term, so that it can be linked to from other pages easily by simply using the {{TemplateLink("htmlattrxref")}} macro (e.g., \{{htmlattrxref("attr","element")}}) to reference attribute definitions.
-
Attribute values
-
Use the "Inline Code" style to apply <code> to attribute values, and don't use quotation marks around string values, unless needed by the syntax of a code sample.
-
For example: "When the type attribute of an <input> element is set to email or tel ..."
-
- -

Latin abbreviations

- -

In notes and parentheses

- - - -

In running text

- - - -

Meanings and English equivalents of Latin abbreviations

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
AbbrevLatinEnglish
cf.confercompare
e.g.exempli gratiafor example
et al.et aliiand others
etc.et ceteraand so forth, and so on
i.e.id estthat is, in other words
N.B.nota benenote well
P.S.post scriptumpostscript
- -
-

Always consider whether it's truly beneficial to use a Latin abbreviation. Some of these are used so rarely that many readers won't understand the meaning, and others are often confused with one another.

- -

Also, be sure that you use them correctly, if you choose to do so. For example, be careful not to confuse "e.g." with "i.e.", which is a common error.

-
- -

Acronyms and abbreviations

- -

Capitalization and periods

- -

Use full capitals and delete periods in all acronyms and abbreviations, including organizations such as "US" and "UN".

- - - -

Expansion

- -

On the first mention of a term on a page, expand acronyms likely to be unfamiliar to users. When in doubt, expand it, or, better, link it to the article or glossary entry describing the technology.

- - - -

Plurals of acronyms and abbreviations

- -

For plurals of acronyms or abbreviations, add s. Don't use an apostrophe. Ever. Please.

- - - -

"Versus", "vs.", and "v."

- -

The contraction "vs." is preferred.

- - - -

Capitalization

- -

Use standard English capitalization rules in body text, and capitalize "World Wide Web." It is acceptable to use lower case for "web" (used alone or as a modifier) and "internet".

- -
-

This guideline is a change from a previous version of this guide, so you may find many instances of "Web" and "Internet" on MDN.

- -

Feel free to change these as you are making other changes, but editing an article just to change capitalization is not necessary.

-
- -

Keyboard keys should use sentence-style capitalization, not all-caps capitalization. For example, "Enter" not "ENTER." The only exception is that if you wish to abbreviate the name of the "Escape" key, you may use "ESC".

- -

Certain words should always be capitalized (such as trademarks which include capital letters), or words derived from the name of a person (unless it's being used within code, and the rules of the language in which the code is written mandate lower-casing). Some examples:

- - - -

Contractions

- -

Our writing style tends to be casual, so you should feel free to use contractions (e.g., "don't", "can't", "shouldn't"), if you prefer.

- -

Pluralization

- -

Use English-style plurals, not the Latin- or Greek-influenced forms.

- - - -

Hyphenation

- -

Hyphenate compounds when the last letter of the prefix is a vowel and is the same as the first letter of the root.

- - - -

Gender-neutral language

- -

It is a good idea to use gender-neutral language in any writing where gender is irrelevant to the subject matter, to make the text as inclusive as possible. So, for example, if you are talking about the actions of a specific man, usage of "he"/"his" is fine; but if the subject is a person of either gender, "he"/"his" isn't appropriate.
-
- Let's take the following example:

- -
-

A confirmation dialog appears, asking the user if he allows the Web page to make use of his Web cam.

-
- -
-

A confirmation dialog appears, asking the user if she allows the Web page to make use of her Web cam.

-
- -

Both versions are gender-specific. To fix this, use gender-neutral pronouns:

- -
-

A confirmation dialog appears, asking the user if they allow the Web page to make use of their Web cam.

-
- -
-

MDN allows the use of this very common syntax (which is controversial among usage authorities) to make up for the lack of a neutral gender in English.

- -

The use of the third-person plural as a gender neutral pronoun (that is, using "they," "them", "their," and "theirs") is an accepted practice, commonly known as "singular 'they.'"

-
- -

You can use both genders:

- -
-

A confirmation dialog appears, asking the user if he or she allows the web page to make use of his/her web cam.

-
- -

Making the users plural:

- -
-

A confirmation dialog appears, asking the users if they allow the web page to make use of their web cams.

-
- -

The best solution, of course, is to rewrite and eliminate the pronouns:

- -
-

A confirmation dialog appears, requesting the user's permission for web cam access.

-
- -
-

A confirmation dialog box appears, which asks the user for permission to use the web cam.

-
- -

The last way of dealing with the problem is arguably better. It is not only grammatically more correct, but removes some of the complexity associated with dealing with genders across different languages that may have wildly different gender rules. This solution can make translation easier for both readers and localizers.

- -

Numbers and numerals

- -

Dates

- -

For dates (not including dates in code samples) use the format "January 1, 1990".

- - - -

Alternately, you can use the YYYY/MM/DD format.

- - - -

Decades

- -

For decades, use the format "1990s". Don't use an apostrophe.

- - - -

Plurals of numerals

- -

For plurals of numerals add "s". Don't use an apostrophe.

- - - -

Commas

- -

In running text, use commas only in five-digit and larger numbers.

- - - -

Punctuation

- -

Serial comma

- -

Use the serial comma. The serial (also known as "Oxford") comma is the comma that appears before the conjunction in a series of three or more items.

- - - -
-

This is in contrast to the One Mozilla style guide, which specifies that the serial comma is not to be used. MDN is an exception to this rule.

-
- -

Apostrophes and quotation marks

- -

Do not use "curly" quotes and quotation marks. On MDN, we only use straight quotes and apostrophes.

- -

There are a couple of reasons for this.

- -
    -
  1. We need to choose one or the other for consistency.
    2. -
  2. If curly quotes or apostrophes make their way into code snippets—even inline ones—readers may copy and paste them, expecting them to function (which they will not).
    3. -
- - - -

Spelling

- -

For words with variant spellings, always use their American English spelling.

- -

In general, use the first entry at Dictionary.com, unless that entry is listed as a variant spelling or as being primarily used in a non-American form of English. For example, if you look up "behaviour", you find the phrase "Chiefly British" followed by a link to the American standard form, "behavior". Do not use variant spellings.

- - - -

Terminology

- -

HTML elements

- -

Use "elements" to refer to HTML and XML elements, rather than "tags". In addition, they should almost always be wrapped in "<>", and should be in the {{HTMLElement("code")}} style.

- -

When you reference a given element for the first time in a section, you should use the {{TemplateLink("HTMLElement")}} macro to create a link to the documentation for the element (unless you're writing within that element's reference document page).

- - - -

Parameters vs. arguments

- -

The preferred term on MDN is parameters. Please avoid the term "arguments" for consistency whenever possible.

- -

User interface actions

- -

In task sequences, describe user interface actions using the imperative mood. Identify the user interface element by its label and type.

- - - -

Voice

- -

While the active voice is preferred, the passive voice is also acceptable, given the informal feel of our content. Try to be consistent, though.

- -

위키 마크업과 사용법

- -

링크

- -

링크는 위키를 강력한 배움과 가르침의 도구로 만드는 데 큰 역할을 합니다. 아래에서 관련한 기본적 정보를 찾을 수 있지만, 에디터 가이드에 있는 MDN에서 링크를 생성하고 편집하기 에서는 완전한 가이드를  볼 수 있습니다.

- -

우리는 당신이 문서간에 적절한 링크를 생성하도록 권장합니다; 링크는 콘덴츠 검색 용이성및 네비게이션을 개선하는데 도움을 주고, 구글과 같은 검색 엔진이 더 나은 검색결과를 제공하도록  중요한 콘텍스트를 제공 합니다. 모든 페이지는 단어나 구문에서 관련된 주제의 다른 페이지로 연결되는 좋은 링크집합을 가져야 합니다. 링크는 용어를 정의하거나 어떤 주제에 대한 상세하고 심화된 문서를 제공하는데에 모두 사용될 뿐만 아니라,  관련된 예제나 보다 관심이 갈만한 정보도 제공할 수도 있습니다.

- -

MDN내부의 문서(내부 링크)뿐만아니라 MDN 외부의 페이지(외부 링크)도 쉽게 링크를 걸 수 있습니다 .

- -

링크를 만드는 두 가지 방법이 있습니다:

- - - -

어떤 텍스트에 링크를 연결할 것인지에 대해, 몇가지 가이드라인을 소개합니다:

- - - -

URL 정책

- -

보안 때문에, 아래 스킴(schemes)을 사용한 링크만 생성할 수 있다:

- - - -

이 외의 것은 동작할 수도 아닐수도 있지만, 편집 스태프에 의해 지원되거나 삭제되지 않을 것이다.

- -
-

특별히,  about: 이나 chrome:// 스킴은 동작하지 않으므로 피해야 한다.

- -

유사하게 , javascript: 스킴도 jar:와 마찬가지로 대부분의 모던 브라우저에서 막혀있다

-
- -

페이지 태그

- -

Tags provide meta information about a page and/or indicate that a page has specific improvements needed to its content. Every page in the wiki should have tags.

- -

You can find details on tagging in our How to properly tag pages guide.

- -

The tagging interface lives at the bottom of a page while you're in edit mode, and looks something like this:

- -

Screenshot of the UX for adding and removing tags on MDN

- -

To add a tag, click in the edit box at the end of the tag list and type the tag name you wish to add. Tags will autocomplete as you type. Press Enter (or Return) to submit the new tag. Each article may have as many tags as needed. For example, an article about using JavaScript in AJAX programming might have both "JavaScript" and "AJAX" as tags.

- -

To remove a tag, just click the little "×" icon in the tag.

- -

Tagging pages that need work

- -

In addition to using tags to track information about the documentation's quality and content, we also use them to mark articles as needing specific types of work.

- -

Tagging obsolete pages

- -

Use the following tags for pages that are not current:

- -
-
Junk
-
Use for spam, pages created by mistake, or content that is so bad that it should be deleted. Pages with this tag are deleted from time to time.
-
Obsolete
-
-

Use for content that is technically superseded, but still valid in context. For example, this might be an HTML element that is obsolete in HTML5, but still valid in HTML 4.01.

- -

You can also use the {{TemplateLink("obsolete_header")}} macro to put a prominent banner on the topic.

-
-
Archive
-
-

Use for content that is technically superseded and no longer useful. If possible, add a note to the topic referring readers to a more current topic.

- -

For example, a page that describes how to use the Mozilla CVS repository should refer readers to a current topic on using Mercurial repos. (If no corresponding current topic exists, use the NeedsUpdate tag, and add an explanation on the Talk page.)

- -

Pages with the Archive tag are eventually moved from the main content of MDN to the Archive section.

-
-
- -

SEO summary

- -

The SEO summary provides a short description of a page. It will be reported as a summary of the article to robots crawling the site, and will then appear in search results for the page. It is also used by macros that automate the construction of landing pages inside MDN itself. (In other words, it's not just for SEO.)

- -

By default, the first paragraph of the page is used as the SEO summary. However, you can override this behavior by marking a section with the "SEO summary" style in the WYSIWYG editor.

- -

Landing pages

- -

Landing pages are pages at the root of a topic area of the site, such as the main CSS or HTML pages. They have a standard format that consists of three areas:

- -
    -
  1. A brief (typically one paragraph) overview of what the technology is and how it's used. See {{anch("Writing a landing page overview")}} for tips.
    2. -
  2. A two-column list of links with appropriate headings. See {{anch("Creating a page link list")}} for guidelines.
    3. -
  3. An optional "Browser compatibility" section at the bottom of the page.
    4. -
- -

Creating a page link list

- -

The link list section of an MDN landing page consists of two columns. These are created using the following HTML:

- -
<div class="row topicpage-table">
-  <div class="section">
-    ... left column contents ...
-  </div>
-  <div class="section">
-    ... right column contents ...
-  </div>
-</div>
- -

The left column should be a list of articles, with an <h2> header at the top of the left column explaining that it's a list of articles about the topic (e.g., "Documentation and tutorials about foo"); this header should use the CSS class "Documentation". Below that is a <dl> list of articles with each article's link in a <dt> block and a brief one-or-two sentence summary of the article in the corresponding <dd> block.

- -

The right column should contain one or more of the following sections, in order:

- -
-
Getting help from the community
-
This should provide information on Matrix chat rooms and mailing lists available on the topic. The heading should use the class "Community".
-
Tools
-
A list of tools the user can look at to help with the use of the technology described in this section of MDN. The heading should use the class "Tools".
-
Related topics
-
A list of links to landing pages for other, related, technologies of relevance. The heading should use the class "Related_Topics".
-
- -

{{TODO("Finish this once we finalize the landing page standards")}}

- -

Using and inserting images

- -

It's sometimes helpful to provide an image in an article you create or modify, especially if the article is very technical.

- -

To include an image:

- -
    -
  1. Before uploading your image, please ensure that it's as small as possible by using an image optiization tool. -
      -
    • For bitmap images (JPG or PNG), consider a tool such as ImageOptim (macOS), TinyPNG (web service), or Trimage (Linux).
      • -
    • For SVG images, use the svgo tool to optimize the SVG file before sending it. The default configuration is fine.
      • -
    -
    2. -
  2. Attach the desired image file to the article (at the bottom of every article in edit mode). If your artwork is a diagram in SVG format (which is ideal if there is text that may need to be localized), you can't upload it directly, but you can ask an MDN admin to do it for you.
    3. -
  3. Click the "insert image" button in the MDN documentation WYSIWYG editor.
    4. -
  4. In the WYSIWYG editor's drop-down list of attachments, select the newly created attachment that is your image.
    5. -
  5. Press the OK button.
    6. -
- -
-

Important: Remember to save any changes you've made before uploading an attachment to your article! The editor is closed during the upload process, and currently does not verify whether or not you wish to save your work when it does so.

-
- -

Other references

- -

Preferred style guides

- -

If you have questions about usage and style not covered here, we recommend referring to the Microsoft Writing Style Guide—or, failing that, the Chicago Manual of Style. An unofficial crib sheet for the Chicago Manual of Style is available online.

- -

Preferred dictionary

- -

For questions of spelling, please refer to Dictionary.com. The spelling checker for this site uses American English. Please do not use variant spellings (e.g., use color rather than colour).

- -

We will be expanding the guide over time, so if you have specific questions that aren't covered in this document, please post them on the MDN discussion forum, so we know what should be added.

- -

MDN-specific

- - - -

Language, grammar, spelling

- -

If you're interested in improving your writing and editing skills, you may find the following resources to be helpful.

- - diff --git a/files/ko/mdn/guidelines/writing_style_guide/index.html b/files/ko/mdn/guidelines/writing_style_guide/index.html new file mode 100644 index 0000000000..507f30e228 --- /dev/null +++ b/files/ko/mdn/guidelines/writing_style_guide/index.html @@ -0,0 +1,833 @@ +--- +title: MDN 스타일 가이드 +slug: MDN/Guidelines/Style_guide +tags: + - Documentation + - Guide + - MDN + - MDN Meta + - MDN 스타일 가이드 + - 스타일 가이드 + - 스타일 가이드 작성 +translation_of: MDN/Guidelines/Writing_style_guide +--- +
{{MDNSidebar}}
+ +
{{IncludeSubnav("/ko/docs/MDN")}}
+ +

정돈되고 일관적이며 읽기 쉬운 문서를 제공하고자, MDN 웹 문서 스타일 안내서는 글의 정렬, 철자, 서식 방법 등을 정리합니다. 이 가이드는 엄격한 규칙이라기보다 가이드라인입니다. 우리는 형식보다는 내용에 더 관심이 있습니다. 그러니 기여하기 전에 스타일 가이드를 배워야 한다는 부담을 느끼시지 않아도 됩니다. 하지만 나중에 다른 부지런한 지원자가 이 가이드를 따라 당신의 작업물을 편집할 수 있습니다. 만약 그런 일이 벌어지더라도 화내거나 놀라지 마세요.

+ +

이 가이드의 언어적 측면의 내용은 영문을 위주로 작성되었습니다. 기타 다른 언어는 언어만의 고유한 스타일 가이드를 가질 수 있으며, 새롭게 만드는 것도 좋습니다. 이 페이지들은 지역화 팀 페이지의 하위 페이지로 생성되어야 합니다.

+ +

MDN이 아닌 다른 사이트를 위해 쓰여진 콘텐츠를 적용하는 스타일 표준에 대한 내용은 One Mozilla 스타일 가이드를 참고하세요.

+ +

기본

+ +

아무리 방대한 문서화 스타일 가이드라도 가장 기본적인 텍스트 표준에서 시작하는 것이 좋습니다. 텍스트 표준은 일관된 문서화를 유지하는데 도움을 줍니다. 이어지는 섹션에서 도움이 될 만한 이런 기본들을 설명합니다.

+ +

페이지 제목

+ +

페이지 제목은 검색 결과에 사용되며, 페이지 상단의 페이지 이동 경로(breadcrumb) 목록에 페이지 계층 구조를 구성하는 데 사용됩니다. (페이지 상단과 검색 결과 상단에 표시되는) 페이지 제목은 페이지 "슬러그"와 다를 수 있습니다. "슬러그"는 페이지 URL의 일부로   "<locale>/docs/" 다음에 따라오는 부분입니다.

+ +

 제목과  섹션제목 대문자넣기(Capitalization)

+ +

페이지 타이틀과 섹션 제목은 헤드라인 스타일 대문자넣기보다는 (첫번째 단어와 필요한 명사만 대문자를 넣는 방식의)일반 문장 스타일 대문자넣기를 해야 합니다:

+ + + +

이런 스타일 규칙이 적용되기 전에 작성된 수많은 예전 문서들이 현재도 존재합니다. 자유롭게 해당 문서들을 수정해도 좋습니다. 우리는 점차적으로 스타일 규칙을 맞춰 나갈겁니다.

+ +

제목 및 슬러그(slug) 선택하기

+ +

페이지 슬러그는 짧게 만들어야 합니다. 새로운 레벨의 계층을 만들때, 그 레벨의 요소는 슬러그에서 한,두 단어로 표현되어야 합니다.

+ +

반면에, 페이지 제목은 ,합리적인 범위내에서, 당신이 원하는 만큼 길어도 됩니다. 그리고 구체적이어야 합니다.

+ +

신규 서브트리 생성하기

+ +

어떤 토픽이나 주제 영역에 대한 문서를 추가할 필요가 있다면, 당신이 선택할 일반적인 방법은 랜딩 페이지를 생성한 이후, 각각의 개별적인 문서의 서브페이지를 추가하는 것입니다. 랜딩 페이지는 토픽이나 기술을 설명하는 한두 개의 문단으로 시작한 이후, 각 페이지의 설명이 달린 서브페이지의 목록을 전달해야합니다. 우리가 개발한 몇가지 매크로로 페이지를 목록에 자동으로 삽입할 수 있습니다.

+ +

예를 들면 , 아래와 같이 구성된 자바스크립트 가이드를 생각해봅시다.

+ + + +

문서를 문서구조 최상층에 두는 것은 최대한 피해야 합니다. 이렇게 하면 사이트가 느려지며, 사이트 탐색과 네비게이션을 비효율적으로 만듭니다.

+ +
+

주목할 점: 문서 추가는 페이지 생성 권한이 필요합니다.

+
+ +

General article content guidelines

+ +

When writing any document, it's important to know how much to say. If you ramble on too long, or provide excessive detail, the article becomes tedious to read and nobody will use it. Getting the amount of coverage right is important for several reasons. Among those reasons: to ensure that the reader finds the information they truly need, and to provide enough quality material for search engines to adequately analyze and rank the article.

+ +

We'll discuss the former (providing the information the reader may need) here. To learn a little about ensuring that pages are properly classified and ranked by search engines, see the article How to write for SEO on MDN.

+ +

The goal is to write pages that include all the information that readers may need without going on too long about it all. We have a few recommendations in this area.

+ +

Consider your audience

+ +

Keep in mind that these are guidelines. Some of these tips may not apply in every case. Certainly keep your article's audience in mind. An article on advanced network techniques likely doesn't need to go into as much detail about basic networking concepts as the typical article on networking code, for instance.

+ +

Provide a useful summary

+ +

Make sure the article's summary—that is, the opening paragraph or paragraphs before the first heading—provides enough information for the reader to understand if the article is likely to be covering what they're interested in reading about.

+ +

In guide or tutorial content, the summary should let the reader know what topics will be covered and what they're already expected to know, if anything. It should mention the technology, technologies, and/or APIs that are being documented or discussed, with links to those, and it should offer hints as to the situations in which the article's contents might be useful.

+ +
Example: Too short!
+ +

This example of a summary is far too short. It leaves out too much information, such as what it means exactly to "stroke" text, where the text is drawn, and so forth.

+ +
CanvasRenderingContext2D.strokeText() draws a string.
+ +
Example: Too long!
+ +

Here, we've updated the summary, but now it's far too long. Too much detail is included, and the text gets far too much into other methods and properties.

+ +

Instead, the summary should focus on the strokeText() method, and should refer to the appropriate guide where the other details are offered.

+ +
+

When called, the Canvas 2D API method CanvasRenderingContext2D.strokeText() strokes the characters in the specified string beginning at the coordinates specified, using the current pen color.In the terminology of computer graphics, "stroking" text means to draw the outlines of the glyphs in the string without filling in the contents of each character with color.

+ +

The text is drawn using the context's current font as specified in the context's {{domxref("CanvasRenderingContext2D.font", "font")}} property.

+ +

The placement of the text relative to the specified coordinates are determined by the context's textAlign, textBaseline, and direction properties. textAlign controls the placement of the string relative to the X coordinate specified; if the value is "center", then the string is drawn starting at x - (stringWidth / 2), placing the specified X-coordinate in the middle of the string. If the value is "left", the string is drawn starting at the specified value of x. And if textAlign is "right", the text is drawn such that it ends at the specified X-coordinate.

+ +

(etc etc etc...)

+ +

You can, optionally, provide a fourth parameter that lets you specify a maximum width for the string, in pixels. If you provide this parameter, the text is compressed horizontally or scaled (or otherwise adjusted) to fit inside a space that wide when being drawn.

+ +

You can call the fillText() method to draw a string's characters as filled with color instead of only drawing the outlines of the characters.

+
+ +
Example: Much better!
+ +

Here we see a much better overview for the strokeText() method.

+ +
+

The {{domxref("CanvasRenderingContext2D")}} method strokeText(), part of the Canvas 2D API, strokes—that is, draws the outlines of—the characters of a specified string, anchored at the position indicated by the given X and Y coordinates. The text is drawn using the context's current {{domxref("CanvasRenderingContext2D.font", "font")}}, and is justified and aligned according to the {{domxref("CanvasRenderingContext2D.textAlign", "textAlign")}}, {{domxref("CanvasRenderingContext2D.textBaseline", "textBaseline")}}, and {{domxref("CanvasRenderingContext2D.direction", "direction")}} properties.

+ +

For more details and further examples, see {{SectionOnPage("/en-US/docs/Learn/JavaScript/Client-side_web_APIs/Drawing_graphics", "Text")}} in the Learning Area as well as our main article on the subject, Drawing text.

+
+ +

Include all relevant examples

+ +

More pages should have examples than not. The majority of pages probably deserve multiple examples, in fact.

+ +

It's important to ensure that you use examples to clarify what every parameter is used for, and to clarify any edge cases that may exist. You should also use examples to demonstrate solutions for common tasks, and you should use examples to demonstrate solutions to problems that may arise.

+ +

Each example should be preceded by text explaining what the example does and anything the reader should know before beginning to read or try out the example.

+ +
Code Examples
+ +

Each piece of code should include an explanation of how it works. Keep in mind that it may make sense to break up a large piece of code into smaller portions so they can be described individually.

+ +

The text following each piece of code should explain anything relevant, using an appropriate level of detail.

+ + + +

When using the live sample system, it's helpful to be aware that all of the {{HTMLElement("pre")}} blocks in the area that contains the sample are concatenated together before running the example, which lets you break any or all of the HTML, CSS, and JavaScript into multiple segments, each optionally with its own descriptions, headings, and so forth. This makes documenting code incredibly powerful and flexible.

+ +

Overly-short articles are hard to find

+ +

If an article is "thin"—that is, too short—it may not be indexed properly (or at all) by search engines. As a rule of thumb, the article's body text should be at least 250–300 words. Don't artificially inflate a page, but treat this guideline as a minimum target length when possible.

+ +

Sections, paragraphs, and newlines

+ +

Use heading levels in decreasing order: {{HTMLElement("h2")}} then {{HTMLElement("h3")}} then {{HTMLElement("h4")}}, without skipping levels.

+ +

H2 is the highest level allowed because H1 is reserved for the page title. If you need more than three or four levels of headers, consider breaking up the article into several smaller articles with a landing page, and linking them together using the following macros: {{TemplateLink("Next")}}, {{TemplateLink("Previous")}}, and {{TemplateLink("PreviousNext")}}.

+ +

Heading dos and donts

+ + + +

The Enter (or Return) key on your keyboard starts a new paragraph. To insert a newline, rather than a new paragraph (that is, to create a {{HTMLElement("br")}} instead of a {{HTMLElement("p")}}), hold down the Shift key while pressing Enter.

+ +

Lists

+ +

Lists should be formatted and structured uniformly across all contributions. Individual list items should be written with suitable punctuation, regardless of the list format. However, depending on the type of list you are creating, you will want to adjust your writing as described in the sections below.

+ +

Bulleted lists

+ +

Bulleted lists should be used to group related pieces of concise information. Each item in the list should follow a similar sentence structure. Phrases and sentences in bulleted lists should include standard punctuation. Periods must appear at the end of each sentence in a bulleted list, including the item's final sentence, just as would be expected in a paragraph.

+ +

An example of a correctly structured bulleted list:

+ +
+

In this example we should include:

+ + +
+ +

Note how the same sentence structure repeats from bullet to bullet. In this example, each bullet point states a condition followed by a comma and a brief explanation, and each item in the list ends with a period.

+ +

Numbered lists

+ +

Numbered lists are used primarily to enumerate steps in a set of instructions. Because instructions can be complex, clarity is a priority, especially if the text in each list item is lengthy. As with bulleted lists, follow standard punctuation usage.

+ +

An example of a correctly structured numbered list:

+ +
+

In order to correctly structure a numbered list, you should:

+ +
    +
  1. Open with a heading or brief paragraph to introduce the instructions. It's important to provide the user with context before beginning the instructions.
    2. +
  2. Start creating your instructions, and keep each step in its own numbered item. Your instructions may be quite extensive, so it is important to write clearly and use correct punctuation.
    3. +
  3. After you have finished your instructions, close off the numbered list with a brief summary or explanation of the expected outcome upon completion.
    4. +
+ +

This is an example of writing a closing explanation. We have created a short numbered list that provides instructive steps to produce a numbered list with the correct formatting.

+
+ +

Note how the items in numbered lists read like short paragraphs. Because numbered lists are routinely used for instructional purposes, or to walk someone through an orderly procedure, be sure to keep each item focused: one item per number or step.

+ +

Text formatting and styles

+ +

Use the "Formatting Styles" drop-down list to apply predefined styles to selected content.

+ +
+

The "Note Box" style is used to call out important notes, like this one.

+
+ +
+

Similarly, the "Warning Box" style creates warning boxes like this.

+
+ +

Unless specifically instructed to do so, do not use the HTML style attribute to manually style content. If you can't do it using a predefined class, ask for help in the MDN discussion forum.

+ +

Code sample style and formatting

+ +
+

Note: This section deals with the styling/formatting of code as it appears on an MDN article. If you want guidelines on actually writing code examples, see our Code sample guidelines.

+
+ +

Tabs and line breaks

+ +

Use two spaces per tab in all code examples. Indent the code cleanly, with open-brace ("{") characters on the same line as the statement that opens the block. For example:

+ +
if (condition) {
+  /* handle the condition */
+} else {
+  /* handle the "else" case */
+}
+
+ +

Long lines shouldn't be allowed to stretch off horizontally to the extent that they require horizontal scrolling to read. Instead, break at natural breaking points. Some examples follow:

+ +
if (class.CONDITION || class.OTHER_CONDITION || class.SOME_OTHER_CONDITION
+       || class.YET_ANOTHER_CONDITION ) {
+  /* something */
+}
+
+var toolkitProfileService = Components.classes["@mozilla.org/toolkit/profile-service;1"]
+                           .createInstance(Components.interfaces.nsIToolkitProfileService);
+
+ +

Inline code formatting

+ +

Use the "Code" button (labeled with two angle brackets "<>") to apply inline code-style formatting to function names, variable names, and method names. (This uses the {{HTMLElement("code")}} element). For example: "the frenchText() function".

+ +

Method names should be followed by a pair of parentheses: doSomethingUseful(). The parentheses help differentiate methods from other code terms.

+ +

Syntax highlighting

+ +

Screenshot of the 'Syntax Highlighter' menu.Entire lines (or multiple lines) of code should be formatted using syntax highlighting rather than the {{HTMLElement("code")}} element. Select the appropriate language from the language list button (the one with the two code blocks), as seen in the screenshot to the right. This will insert a preformatted code box with line numbers and syntax highlighting for the chosen language.

+ +
+

Note: Do not use the {{HTMLElement("code")}} element inside the {{HTMLElement("pre")}} block!

+ +

While this structure is used on some sites, we do not do so on MDN; nesting these elements will break certain aspects of our styling.

+
+ +

The following example shows text with JavaScript formatting:

+ +
for (let i = 0, j = 9; i <= 9; i++, j--)
+  document.writeln("a[" + i + "][" + j + "]= " + a[i][j]);
+ +

If no appropriate language is available, use ("No Highlight" in the language menu). This will result in code without syntax highlighting:

+ +
x = 42;
+ +

Syntax definitions

+ +

When writing the syntax description section of a reference page, use the "Syntax Box" option in the "Styles" drop-down menu in the editor toolbar. This creates a specially-formatted box used specifically for syntax definitions, distinguishing them from other code blocks.

+ +

Blocks not referring to code

+ +

There are a few use cases where a <pre> block does not refer to code and doesn't have syntax highlighting nor line numbers. In such cases you should add a <pre> without a class attribute. Those cases include things like tree structures:

+ +
root/
+
+  folder1/
+    file1
+
+  folder2/
+    file2
+    file3
+
+ +

To create preformatted content without syntax highlighting and line numbers click the "pre" button in the toolbar. Then start to type the text.

+ +

Styling mentions of HTML elements

+ +

There are specific rules to follow when writing about HTML elements. These rules produce consistent descriptions of elements and their components. They also ensure correct linking to detailed documentation.

+ +
+
Element names
+
Use the {{TemplateLink("HTMLElement")}} macro, which creates a link to the page for that element. For example, writing \{{HTMLElement("title")}} produces "{{HTMLElement("title")}}". If you don't want to create a link, enclose the name in angle brackets and use the "Inline Code" style (e.g., <title>).
+
Attribute names
+
Use "Inline Code" style to put attribute names in code font. Additionally, put them in bold face when the attribute is mentioned in association with an explanation of what it does, or the first time it's used in the article.
+
Attribute definitions
+
Use the {{TemplateLink("htmlattrdef")}} macro (e.g., \{{htmlattrdef("type")}}) for the definition term, so that it can be linked to from other pages easily by simply using the {{TemplateLink("htmlattrxref")}} macro (e.g., \{{htmlattrxref("attr","element")}}) to reference attribute definitions.
+
Attribute values
+
Use the "Inline Code" style to apply <code> to attribute values, and don't use quotation marks around string values, unless needed by the syntax of a code sample.
+
For example: "When the type attribute of an <input> element is set to email or tel ..."
+
+ +

Latin abbreviations

+ +

In notes and parentheses

+ + + +

In running text

+ + + +

Meanings and English equivalents of Latin abbreviations

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
AbbrevLatinEnglish
cf.confercompare
e.g.exempli gratiafor example
et al.et aliiand others
etc.et ceteraand so forth, and so on
i.e.id estthat is, in other words
N.B.nota benenote well
P.S.post scriptumpostscript
+ +
+

Always consider whether it's truly beneficial to use a Latin abbreviation. Some of these are used so rarely that many readers won't understand the meaning, and others are often confused with one another.

+ +

Also, be sure that you use them correctly, if you choose to do so. For example, be careful not to confuse "e.g." with "i.e.", which is a common error.

+
+ +

Acronyms and abbreviations

+ +

Capitalization and periods

+ +

Use full capitals and delete periods in all acronyms and abbreviations, including organizations such as "US" and "UN".

+ + + +

Expansion

+ +

On the first mention of a term on a page, expand acronyms likely to be unfamiliar to users. When in doubt, expand it, or, better, link it to the article or glossary entry describing the technology.

+ + + +

Plurals of acronyms and abbreviations

+ +

For plurals of acronyms or abbreviations, add s. Don't use an apostrophe. Ever. Please.

+ + + +

"Versus", "vs.", and "v."

+ +

The contraction "vs." is preferred.

+ + + +

Capitalization

+ +

Use standard English capitalization rules in body text, and capitalize "World Wide Web." It is acceptable to use lower case for "web" (used alone or as a modifier) and "internet".

+ +
+

This guideline is a change from a previous version of this guide, so you may find many instances of "Web" and "Internet" on MDN.

+ +

Feel free to change these as you are making other changes, but editing an article just to change capitalization is not necessary.

+
+ +

Keyboard keys should use sentence-style capitalization, not all-caps capitalization. For example, "Enter" not "ENTER." The only exception is that if you wish to abbreviate the name of the "Escape" key, you may use "ESC".

+ +

Certain words should always be capitalized (such as trademarks which include capital letters), or words derived from the name of a person (unless it's being used within code, and the rules of the language in which the code is written mandate lower-casing). Some examples:

+ + + +

Contractions

+ +

Our writing style tends to be casual, so you should feel free to use contractions (e.g., "don't", "can't", "shouldn't"), if you prefer.

+ +

Pluralization

+ +

Use English-style plurals, not the Latin- or Greek-influenced forms.

+ + + +

Hyphenation

+ +

Hyphenate compounds when the last letter of the prefix is a vowel and is the same as the first letter of the root.

+ + + +

Gender-neutral language

+ +

It is a good idea to use gender-neutral language in any writing where gender is irrelevant to the subject matter, to make the text as inclusive as possible. So, for example, if you are talking about the actions of a specific man, usage of "he"/"his" is fine; but if the subject is a person of either gender, "he"/"his" isn't appropriate.
+
+ Let's take the following example:

+ +
+

A confirmation dialog appears, asking the user if he allows the Web page to make use of his Web cam.

+
+ +
+

A confirmation dialog appears, asking the user if she allows the Web page to make use of her Web cam.

+
+ +

Both versions are gender-specific. To fix this, use gender-neutral pronouns:

+ +
+

A confirmation dialog appears, asking the user if they allow the Web page to make use of their Web cam.

+
+ +
+

MDN allows the use of this very common syntax (which is controversial among usage authorities) to make up for the lack of a neutral gender in English.

+ +

The use of the third-person plural as a gender neutral pronoun (that is, using "they," "them", "their," and "theirs") is an accepted practice, commonly known as "singular 'they.'"

+
+ +

You can use both genders:

+ +
+

A confirmation dialog appears, asking the user if he or she allows the web page to make use of his/her web cam.

+
+ +

Making the users plural:

+ +
+

A confirmation dialog appears, asking the users if they allow the web page to make use of their web cams.

+
+ +

The best solution, of course, is to rewrite and eliminate the pronouns:

+ +
+

A confirmation dialog appears, requesting the user's permission for web cam access.

+
+ +
+

A confirmation dialog box appears, which asks the user for permission to use the web cam.

+
+ +

The last way of dealing with the problem is arguably better. It is not only grammatically more correct, but removes some of the complexity associated with dealing with genders across different languages that may have wildly different gender rules. This solution can make translation easier for both readers and localizers.

+ +

Numbers and numerals

+ +

Dates

+ +

For dates (not including dates in code samples) use the format "January 1, 1990".

+ + + +

Alternately, you can use the YYYY/MM/DD format.

+ + + +

Decades

+ +

For decades, use the format "1990s". Don't use an apostrophe.

+ + + +

Plurals of numerals

+ +

For plurals of numerals add "s". Don't use an apostrophe.

+ + + +

Commas

+ +

In running text, use commas only in five-digit and larger numbers.

+ + + +

Punctuation

+ +

Serial comma

+ +

Use the serial comma. The serial (also known as "Oxford") comma is the comma that appears before the conjunction in a series of three or more items.

+ + + +
+

This is in contrast to the One Mozilla style guide, which specifies that the serial comma is not to be used. MDN is an exception to this rule.

+
+ +

Apostrophes and quotation marks

+ +

Do not use "curly" quotes and quotation marks. On MDN, we only use straight quotes and apostrophes.

+ +

There are a couple of reasons for this.

+ +
    +
  1. We need to choose one or the other for consistency.
    2. +
  2. If curly quotes or apostrophes make their way into code snippets—even inline ones—readers may copy and paste them, expecting them to function (which they will not).
    3. +
+ + + +

Spelling

+ +

For words with variant spellings, always use their American English spelling.

+ +

In general, use the first entry at Dictionary.com, unless that entry is listed as a variant spelling or as being primarily used in a non-American form of English. For example, if you look up "behaviour", you find the phrase "Chiefly British" followed by a link to the American standard form, "behavior". Do not use variant spellings.

+ + + +

Terminology

+ +

HTML elements

+ +

Use "elements" to refer to HTML and XML elements, rather than "tags". In addition, they should almost always be wrapped in "<>", and should be in the {{HTMLElement("code")}} style.

+ +

When you reference a given element for the first time in a section, you should use the {{TemplateLink("HTMLElement")}} macro to create a link to the documentation for the element (unless you're writing within that element's reference document page).

+ + + +

Parameters vs. arguments

+ +

The preferred term on MDN is parameters. Please avoid the term "arguments" for consistency whenever possible.

+ +

User interface actions

+ +

In task sequences, describe user interface actions using the imperative mood. Identify the user interface element by its label and type.

+ + + +

Voice

+ +

While the active voice is preferred, the passive voice is also acceptable, given the informal feel of our content. Try to be consistent, though.

+ +

위키 마크업과 사용법

+ +

링크

+ +

링크는 위키를 강력한 배움과 가르침의 도구로 만드는 데 큰 역할을 합니다. 아래에서 관련한 기본적 정보를 찾을 수 있지만, 에디터 가이드에 있는 MDN에서 링크를 생성하고 편집하기 에서는 완전한 가이드를  볼 수 있습니다.

+ +

우리는 당신이 문서간에 적절한 링크를 생성하도록 권장합니다; 링크는 콘덴츠 검색 용이성및 네비게이션을 개선하는데 도움을 주고, 구글과 같은 검색 엔진이 더 나은 검색결과를 제공하도록  중요한 콘텍스트를 제공 합니다. 모든 페이지는 단어나 구문에서 관련된 주제의 다른 페이지로 연결되는 좋은 링크집합을 가져야 합니다. 링크는 용어를 정의하거나 어떤 주제에 대한 상세하고 심화된 문서를 제공하는데에 모두 사용될 뿐만 아니라,  관련된 예제나 보다 관심이 갈만한 정보도 제공할 수도 있습니다.

+ +

MDN내부의 문서(내부 링크)뿐만아니라 MDN 외부의 페이지(외부 링크)도 쉽게 링크를 걸 수 있습니다 .

+ +

링크를 만드는 두 가지 방법이 있습니다:

+ + + +

어떤 텍스트에 링크를 연결할 것인지에 대해, 몇가지 가이드라인을 소개합니다:

+ + + +

URL 정책

+ +

보안 때문에, 아래 스킴(schemes)을 사용한 링크만 생성할 수 있다:

+ + + +

이 외의 것은 동작할 수도 아닐수도 있지만, 편집 스태프에 의해 지원되거나 삭제되지 않을 것이다.

+ +
+

특별히,  about: 이나 chrome:// 스킴은 동작하지 않으므로 피해야 한다.

+ +

유사하게 , javascript: 스킴도 jar:와 마찬가지로 대부분의 모던 브라우저에서 막혀있다

+
+ +

페이지 태그

+ +

Tags provide meta information about a page and/or indicate that a page has specific improvements needed to its content. Every page in the wiki should have tags.

+ +

You can find details on tagging in our How to properly tag pages guide.

+ +

The tagging interface lives at the bottom of a page while you're in edit mode, and looks something like this:

+ +

Screenshot of the UX for adding and removing tags on MDN

+ +

To add a tag, click in the edit box at the end of the tag list and type the tag name you wish to add. Tags will autocomplete as you type. Press Enter (or Return) to submit the new tag. Each article may have as many tags as needed. For example, an article about using JavaScript in AJAX programming might have both "JavaScript" and "AJAX" as tags.

+ +

To remove a tag, just click the little "×" icon in the tag.

+ +

Tagging pages that need work

+ +

In addition to using tags to track information about the documentation's quality and content, we also use them to mark articles as needing specific types of work.

+ +

Tagging obsolete pages

+ +

Use the following tags for pages that are not current:

+ +
+
Junk
+
Use for spam, pages created by mistake, or content that is so bad that it should be deleted. Pages with this tag are deleted from time to time.
+
Obsolete
+
+

Use for content that is technically superseded, but still valid in context. For example, this might be an HTML element that is obsolete in HTML5, but still valid in HTML 4.01.

+ +

You can also use the {{TemplateLink("obsolete_header")}} macro to put a prominent banner on the topic.

+
+
Archive
+
+

Use for content that is technically superseded and no longer useful. If possible, add a note to the topic referring readers to a more current topic.

+ +

For example, a page that describes how to use the Mozilla CVS repository should refer readers to a current topic on using Mercurial repos. (If no corresponding current topic exists, use the NeedsUpdate tag, and add an explanation on the Talk page.)

+ +

Pages with the Archive tag are eventually moved from the main content of MDN to the Archive section.

+
+
+ +

SEO summary

+ +

The SEO summary provides a short description of a page. It will be reported as a summary of the article to robots crawling the site, and will then appear in search results for the page. It is also used by macros that automate the construction of landing pages inside MDN itself. (In other words, it's not just for SEO.)

+ +

By default, the first paragraph of the page is used as the SEO summary. However, you can override this behavior by marking a section with the "SEO summary" style in the WYSIWYG editor.

+ +

Landing pages

+ +

Landing pages are pages at the root of a topic area of the site, such as the main CSS or HTML pages. They have a standard format that consists of three areas:

+ +
    +
  1. A brief (typically one paragraph) overview of what the technology is and how it's used. See {{anch("Writing a landing page overview")}} for tips.
    2. +
  2. A two-column list of links with appropriate headings. See {{anch("Creating a page link list")}} for guidelines.
    3. +
  3. An optional "Browser compatibility" section at the bottom of the page.
    4. +
+ +

Creating a page link list

+ +

The link list section of an MDN landing page consists of two columns. These are created using the following HTML:

+ +
<div class="row topicpage-table">
+  <div class="section">
+    ... left column contents ...
+  </div>
+  <div class="section">
+    ... right column contents ...
+  </div>
+</div>
+ +

The left column should be a list of articles, with an <h2> header at the top of the left column explaining that it's a list of articles about the topic (e.g., "Documentation and tutorials about foo"); this header should use the CSS class "Documentation". Below that is a <dl> list of articles with each article's link in a <dt> block and a brief one-or-two sentence summary of the article in the corresponding <dd> block.

+ +

The right column should contain one or more of the following sections, in order:

+ +
+
Getting help from the community
+
This should provide information on Matrix chat rooms and mailing lists available on the topic. The heading should use the class "Community".
+
Tools
+
A list of tools the user can look at to help with the use of the technology described in this section of MDN. The heading should use the class "Tools".
+
Related topics
+
A list of links to landing pages for other, related, technologies of relevance. The heading should use the class "Related_Topics".
+
+ +

{{TODO("Finish this once we finalize the landing page standards")}}

+ +

Using and inserting images

+ +

It's sometimes helpful to provide an image in an article you create or modify, especially if the article is very technical.

+ +

To include an image:

+ +
    +
  1. Before uploading your image, please ensure that it's as small as possible by using an image optiization tool. +
      +
    • For bitmap images (JPG or PNG), consider a tool such as ImageOptim (macOS), TinyPNG (web service), or Trimage (Linux).
      • +
    • For SVG images, use the svgo tool to optimize the SVG file before sending it. The default configuration is fine.
      • +
    +
    2. +
  2. Attach the desired image file to the article (at the bottom of every article in edit mode). If your artwork is a diagram in SVG format (which is ideal if there is text that may need to be localized), you can't upload it directly, but you can ask an MDN admin to do it for you.
    3. +
  3. Click the "insert image" button in the MDN documentation WYSIWYG editor.
    4. +
  4. In the WYSIWYG editor's drop-down list of attachments, select the newly created attachment that is your image.
    5. +
  5. Press the OK button.
    6. +
+ +
+

Important: Remember to save any changes you've made before uploading an attachment to your article! The editor is closed during the upload process, and currently does not verify whether or not you wish to save your work when it does so.

+
+ +

Other references

+ +

Preferred style guides

+ +

If you have questions about usage and style not covered here, we recommend referring to the Microsoft Writing Style Guide—or, failing that, the Chicago Manual of Style. An unofficial crib sheet for the Chicago Manual of Style is available online.

+ +

Preferred dictionary

+ +

For questions of spelling, please refer to Dictionary.com. The spelling checker for this site uses American English. Please do not use variant spellings (e.g., use color rather than colour).

+ +

We will be expanding the guide over time, so if you have specific questions that aren't covered in this document, please post them on the MDN discussion forum, so we know what should be added.

+ +

MDN-specific

+ + + +

Language, grammar, spelling

+ +

If you're interested in improving your writing and editing skills, you may find the following resources to be helpful.

+ + diff --git a/files/ko/mdn/kuma/index.html b/files/ko/mdn/kuma/index.html deleted file mode 100644 index becf84221a..0000000000 --- a/files/ko/mdn/kuma/index.html +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: '쿠마(Kuma): MDN 위키 플랫폼' -slug: MDN/Kuma -tags: - - MDN 메타 - - 시작하기 - - 쿠마 -translation_of: MDN/Kuma ---- -
{{MDNSidebar}}
- -
{{IncludeSubnav("/ko/docs/MDN")}}
- -
쿠마(Kuma)는 MDN Web Docs를 작동시키는 Django 코드 입니다. 
- -

{{SubpagesWithSummaries}}

- -

Kuma와 함께해주세요. 

- -

함께 하고 싶다면 

- - diff --git a/files/ko/mdn/structures/api_references/api_reference_sidebars/index.html b/files/ko/mdn/structures/api_references/api_reference_sidebars/index.html deleted file mode 100644 index fd8be5585d..0000000000 --- a/files/ko/mdn/structures/api_references/api_reference_sidebars/index.html +++ /dev/null @@ -1,114 +0,0 @@ ---- -title: API 레퍼런스의 사이드바 -slug: MDN/Structures/API_references/API_reference_sidebars -translation_of: MDN/Structures/API_references/API_reference_sidebars ---- -
{{MDNSidebar}}
- -

API 레퍼런스 문서에는 수정 가능한 사이드바 를 추가할 수 있습니다. 이 사이드바에 인터페이스, 튜토리얼, 혹은 API와 관련된 자료 링크를 노출합니다. 그 사용법을 설명합니다. 

- -

뭘 해야 하나요?

- -

사이드바 생성은 다음 세 단계로 나뉩니다. 

- -
    -
  1. API 레퍼런스 페이지를 만듭니다. 
    2. -
  2. KumaScript 레파지토리의 GroupData.json 데이터 파일에 그 API를 위한 엔트리를 추가합니다. 
    3. -
  3. 사이드바가 필요한 페이지에 \{{APIRef}} 메크로를 추가합니다.
    4. -
- -

Fetch API를 샘플로 삼아서 단계별로 살펴 보겠습니다. 

- -

신규 API 레퍼런스 페이지 만들기

- -

페이지에 사이드바를 추가하기 전에 여러분은 페이지를 만들어야 합니다. (자세한건 API 레퍼런스 문서에 필요한건 무엇일까요? 마이드 문서를 보세요)

- -

GroupData.json에 API의 엔트리를 추가하기

- -

GroupData.json 파일은 API 레퍼런스 문서의 사이드바 안에 담아야 하는 모든 데이타를 담고 있습니다. API를 파라미터로 주고 \{{APIRef}}메크로를 실행하면, GroupData.json에서 탐색해서 사이드바를 생성하고 페이지에 추가합니다. 

- -

GroupData.json에 엔트리를 추가하려면 다음을 따르세요.

- -
    -
  1. GitHub 계정이 필요합니다. 
    2. -
  2. KumaScript 레파지토리를 포크뜨고, 작업할 브랜치를 생성하고 로컬에 클론을 뜹니다. 
    3. -
  3. 생성한 브랜치로 체크아웃을 하고 작업후 오리진으로 푸시합니다. 
    4. -
  4. MDN 팀이 리뷰할 수 있도록 풀 리퀘스트를 날려주시고, 필요하다 생각이 들면 변경 요청을 주세요.
    5. -
- -

GitHub 사용법을 잘 모르겠으면 호환성 테이블 가이드 문서를 참고하세요. 자세한 내용이 있습니다. 

- -

GroupData.json은 KumaScript 레파지토리의 macros 폴더 안에 있습니다. 파일을 열어보면 API별로 자기 내용을 가진 거대한 JSON 구조체를 볼 수 있습니다. 키는 API명이고, 값은 사이드바 링크를 생성하기 위해 정의된 하위 멤버를 담은 객체입니다. 

- -

Fetch API 를 예로 들면 일치하는 GroupData.json의 엔트리가 다음과 같습니다. 

- -
"Fetch API": {
-    "overview":   [ "Fetch API"],
-    "interfaces": [ "Body",
-                    "Headers",
-                    "Request",
-                    "Response",
-                    "FetchController",
-                    "FetchObserver",
-                    "FetchSignal",
-                    "ObserverCallback" ],
-    "methods":    [ "WindowOrWorkerGlobalScope.fetch()" ],
-    "properties": [],
-    "events":     []
-},
-
- -

보다시피 키 명을 "Fetch API"으로 명명 하고 있고, 하위 멤버들을 담은 객체를 가지고 있습니다. 

- -

GroupData 엔트리에 담긴 하위 멤버들

- -

GroupData 엔트리에 추가할 수 있는 하위 멤버 목록입니다. 

- -

리스트업된 하위 멤버값 대부분은 링크걸 텍스트와 링크 생성을 위해 메인 API 색인 페이지(https://developer.mozilla.org/<language-code>/docs/Web/API) 끝에 추가될 슬러그입니다. 예를 들어 en-US 로케일에서 "Body"는 아래 링크를 만듭니다. 

- -
<li><a href="https://developer.mozilla.org/en-US/docs/Web/API">Body</a></li>
-
- -

몇가지 예외가 있습니다.. 예를 들어 "guides" 하위 멤버는 가이드/튜토리얼 관련 링크를 정의할 하나이상의 링크 정보(타이틀과 슬러그)를 갖고 있는데, 이경우 슬러그는 MDN 어디든 추가될 수 있도록 MDN 문서 루트(https://developer.mozilla.org/<language-code>/docs)의 끝에 추가됩니다. 

- -

사용가능한 멤버들입니다. 로케일은 en-US로 가정합니다. 

- -
    -
  1. -

    "overview" — 값은 배열이고, API 오버뷰 문서의 슬러그입니다. 하나인 경우 "Fetch API"이면 다음 같은 링크를 만듭니다. https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API.

    -
    2. -
  2. -

    "interfaces" — 해당 API의 인터페이스 전체 목록을 담은 배열 입니다. 값이 "Body"이면 다음 과 같은 링크를 만듭니다. https://developer.mozilla.org/en-US/docs/Web/API/Body.

    -
    3. -
  3. -

    "methods" — the value is an array that should contain any methods the spec adds to interfaces associated with other APIs, such as instantiation methods created on {{domxref("Navigator")}} or {{domxref("Window")}}. If there are a huge number of methods, you might want to consider only listing the most popular ones, or putting them first in the list. "WindowOrWorkerGlobalScope.fetch()" results in a link being made to https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/fetch.

    -
    4. -
  4. -

    "properties" — the value is an array that should contain all of the properties associated with the API. This can include properties that are members of interfaces defined in the API spec, and properties the API defines on other interfaces. If there are a huge number of properties, you might want to consider only listing the most popular ones, or putting them first in the list. "Headers.append" results in a link being made to https://developer.mozilla.org/en-US/docs/Web/API/Headers/append.

    -
    5. -
  5. -

    "events" — the value is an array that should contain all of the events associated with the API, defined in the API spec, or elsewhere. If there are a huge number of events, you might want to consider only listing the most popular ones, or putting them first in the list. "animationstart" results in a link being made to https://developer.mozilla.org/en-US/docs/Web/Events/animationstart.

    -
    6. -
  6. -

    "guides" — the value is an array containing one or more objects that define links to guides explain how to use the API. Each object contains two submembers — "url", which contains the partial URL pointing to the guide article, and "title", which defines the link test for the link. As an example, the following object:

    - - 
    { "url":   "/docs/Web/API/Detecting_device_orientation",
-"title": "Detecting device orientation" }
    - -

    Creates a link with the title "Detecting device orientation", which points to https://developer.mozilla.org/en-US/docs/Web/API/Detecting_device_orientation.

    -
    7. -
- -

API Submembers and Tags

- -

Some submembers are automatically discovered from child pages, based on page tags.  Pages under the top-level API are crawled each time the sidebar is rendered, and entries are automatically created for methods ("Method" tag), properties ("Property" tag), and constructors ("Constructor" tag).

- -

Submembers are automatically decorated with warning icons based on tags as well.  Decorations are added for experimental ("Experimental" tag), non-standard ("Non Standard" or "Non-standard" tag), deprecated ("Deprecated" tag), or obsolete ("Obsolete" tag) submembers.

- -

Further information about tag-based processing is available in the APIRef source.

- -

Inserting the sidebar in your pages

- -

Once you've added an entry for your API into GroupData.json, submitted it as a pull request and had the change accepted into the main repo, you can include it in your API reference pages using the \{{APIRef}} macro, which takes the name you used for your API in GroupData as a parameter. As an example, the WebVR API's sidebar is included in its pages with the following:

- -

\{{APIRef("WebVR API")}}

diff --git a/files/ko/mdn/structures/api_references/index.html b/files/ko/mdn/structures/api_references/index.html deleted file mode 100644 index c521b5f4ec..0000000000 --- a/files/ko/mdn/structures/api_references/index.html +++ /dev/null @@ -1,58 +0,0 @@ ---- -title: API 레퍼런스 -slug: MDN/Structures/API_references -tags: - - API - - 가이드 - - 레퍼런스 - - 봉사 -translation_of: MDN/Structures/API_references ---- -
{{MDNSidebar}}
- -
{{IncludeSubnav("/en-US/docs/MDN")}}
- -

웹에서 사용 가능한 기술 중 클라이언트 측 자바스크립트 API가 차지하는 비중은 상당히 높습니다. 그렇기 때문에, MDN은 API의 기능과 사용법을 설명하는 광범위한 참조 자료를 보유하고 있습니다. 이 안내 문서는 이런 API 참고 자료를 MDN에 생성하는 방법을 설명합니다. 

- -

사전 준비

- -

API를 문서화 하려면 다음이 가능해야 합니다. 

- -
    -
  1. 최종 버전의 스팩: 그 API를 다루는 스팩의 단계가 W3C 최종 권고안인지, 초안인지는 관계없지만, 최종 버전의 스팩을 참조해야 합니다.  보통은 웹에서 쉽게 검색할 수 있으며, 그 스팩의 모든 버전의 문서에는 보통 최종 버전으로의 링크가 "lastest draft"등의 제목으로 걸려있습니다. 
    2. -
  2. 최신 모던 브라우저: 여러분이 문서화할 기능들은 정식 버전이 아닌 파이어폭스 나이틀리/크롬 카나리와 같은 실험 버전에서 지원할 가능성이 높습니다. 앞서가는 실험적인 API를 문서화 한다면 더욱 이런 버전의 브라우저를 사용해야 합니다. 
    3. -
  3. 데모/블로그 글/다른 정보: 가능하면 최대한 정보를 찾아보세요. 그 API가 어떻게 동작하는지 스스로 익숙히는 좋은 출발점이 됩니다. 주 인터페이스, 프로퍼티, 메서드가 무엇인지, 주요한 유즈 케이스가 어떻게 되는지 배우고, 어떻게 그 기능을 간단시 서술할지 고민하세요. 
    4. -
  4. 기술문의 활용: API 표준화에 참여했거나 브라우저에서 그 스팩을 구현한 누군가에게 기술문의를 할 수 있는 나만의 연락처를 찾을 수 있다면 정말 좋습니다. 다음을 참고하세요. -
      -
    • 관련 업무를 보는 회사에서 근무한다면 사내 주소록
      • -
    • 그 API에 대한 토론 채널에 참여한 공개 메일링 리스트. 모질라의 dev-platform, dev-webapi 목록, public-webapps 같은 W3C 목록 참고
      • -
    • 스팩 문서. 예를 들면 Web Audio API 문서 상단에는 저자들의 연락처가 있음.
      • -
    -
    5. -
- -

문서 구조

- -
-
API 레퍼런스 문서에 필요한 것은 무엇일까요? 
-
이 문서는 완벽한 API 레퍼런스 문서에 필요한 것들을 설명합니다. 
-
페이지 타입
-
MDN에서 반복적으로 사용되는 페이지 타입들이 있습니다. 이 문서는 그 타입들의 목적을 설명하고 신규 문서를 만들때 사용할 수 있는 템플릿 예제를 제공합니다. 
-
- -

페이지의 기능

- -

API 레퍼런스 문서를 위한 페이지 기능을 생성하는 방법을 설명합니다. 

- -
-
API 레퍼런스 사이드바
-
작성한 MDN API 레퍼런스 문서에 사이드바를 추가할 때, 여러분은 API와 관련된 인터페이스 튜토리얼, 다른 자료 링크를 맘대로 출력할 수 있습니다. 이 문서는 그 방법을 설명합니다. 
-
API 문법 섹션
-
MDN 참조 문서에서 문법 섹션은 그 기능이 가지고 있는 정확한 문법을 기술한 박스형태를 띄고 있다. (어떤 매개변수가 사용가능한지, 어떤 것이 옵션인지 등) 그 문서는 레퍼런스 문서를 위한 문법 섹션 작성법에 대해 설명합니다. 
-
예제 코드
-
웹 플랫폼 기능 사용법을 설명하는 페이지에는 어김없이 많은 예제 코드가 있습니다. 이 문서는 페이지에 예제 코드를 추가하기 위한 각각의 가능한 메카니즘을 기술합니다. 무엇을 언제 사용해야 하는지도 함께요.
-
스펙 테이블
-
MDN의 모든 레퍼런스 페이지는 API나 기술이 정의된 스팩, 또는 그 스팩에 대한 정보를 제공해야 합니다. 이 문서는 테이블의 형태와 제작 방법을 설명합니다. 
-
호환성 테이블
-
MDN은 오픈 웹 문서, 즉 모든 브라우저에서 공유되는 DOM, HTML, CSS, JavaScript, SVG 등과 같은 기술 문서를 위한 호환성 테이블 표준을 가지고 있습니다. 이 문서는 호환성 데이터를 MDN 페이지에 추가하는 기능 사용법을 다룹니다. 
-
diff --git "a/files/ko/mdn/tools/\355\216\230\354\235\264\354\247\200_\354\236\254\354\203\235\354\204\261/index.html" "b/files/ko/mdn/tools/\355\216\230\354\235\264\354\247\200_\354\236\254\354\203\235\354\204\261/index.html" deleted file mode 100644 index 2b75d2508f..0000000000 --- "a/files/ko/mdn/tools/\355\216\230\354\235\264\354\247\200_\354\236\254\354\203\235\354\204\261/index.html" +++ /dev/null @@ -1,34 +0,0 @@ ---- -title: 페이지 재생성 -slug: MDN/Tools/페이지_재생성 -tags: - - Guide - - MDN Meta - - Page-level - - Tools -translation_of: MDN/Tools/Page_regeneration ---- -
{{MDNSidebar}}

MDN 사이트는 성능상의 이유로 페이지를 캐시합니다. 그 결과, 당신이 페이지에 저장한 변경 사항이 다음 번 페이지 새로 고침할 때 나타나지 않을 수 있습니다. 자주, 항상은 아니지만, 배너가 페이지 업데이트가 진행 중임을 알리는 페이지에 나타납니다. 당신은 서버에서 페이지를 새로 고침하기 위해 브라우저에 "강제 새로 고침"을 할 수 있지만, 이는 서버의 업데이트가 끝나지 않았다면 효과가 없을 지도 모릅니다.

- -

일부 페이지(특히 첫방문landing 페이지)는 자동으로 생성하고 콘텐츠를 업데이트하기 위해 매크로를 사용합니다. 첫방문 페이지의 경우, 매크로는 글쓴이가 손수 추가할 필요 없이 새 글이 자동으로 페이지에 나열되게 합니다. 이는 오랜 공헌자에게는 편리하고, 새로 온 이들은 사이트 계층구조에 자신의 글을 링크하는 법을 모르기에 그들의 작업을 셔플에서 잃는 것을 막는 데 도움이 됩니다.

- -

이는 (예를 들어, {{TemplateLink("Page")}} 매크로를 써서) 한 페이지의 콘텐츠를 다른 페이지로 삽입(transcluding)할 때도 사용할 수 있습니다.

- -

MDN은 성능상의 이유로 렌더링된 콘텐츠를 캐시하기 때문에, (매크로 출력이나 삽입transcluded 페이지 같은) 원 저작물(source material)에 더해진 변경 사항은 자동으로 페이지에 반영되지 않습니다. 그러한 원 저작물에 자주 변경이 예상되는 경우, 자동 페이지 재생성 활성화를 고려할 수 있습니다.

- -

자동 재생성을 활성화하기 위해서:

- -
    -
  1. 편집 모드 진입을 위해 페이지 상의 편집 버튼 클릭.
    2. -
  2. 페이지 제목 아래, 페이지 제목 근처에 위치한 페이지 제목과 속성 편집 클릭. 페이지 메타데이터 필드가 나타남.
    3. -
  3. 렌더링 최대 수명값을 설정. 이 값은 캐시된 페이지의 매크로 재실행을 포함하여, 재빌드되는 일정을 결정합니다. 보통, 우리는 여기에 4내지 8시간을 사용합니다. 기술의 문서화가 빠르게 바뀌는 경우, 더 작은 수를 선택할 수 있습니다.
    4. -
  4. 페이지에 변경 사항을 저장. 리비전 코멘트에 "렌더링 최대 수명을 4시간으로 설정"과 같이, 당신이 작업한 내용을 설명하는 것은 좋은 습관입니다. 
    5. -
- -

페이지는 당신이 지정한 일정대로 자동으로 재성성됩니다.

- -
-

주의: "페이지 제목과 속성 편집" 옵션은 새 페이지를 만들 때는 이용할 수 없습니다. 첫 번째 저장 이후로 편집기를 다시 열어야 합니다.

-
- -

 

diff --git a/files/ko/mdn/user_guide/index.html b/files/ko/mdn/user_guide/index.html deleted file mode 100644 index eec139e803..0000000000 --- a/files/ko/mdn/user_guide/index.html +++ /dev/null @@ -1,12 +0,0 @@ ---- -title: MDN 사용자 가이드 -slug: MDN/User_guide -tags: - - 모질라 개발자 네트워크 - - 사용자 가이드 -translation_of: MDN/Tools -translation_of_original: MDN/User_guide ---- -
{{MDNSidebar}}

모질라 개발자 네트워크 (이하 MDN) 사이트는, (파이어폭스 및 파이어폭스 운영체제 개발자 뿐 아니라) 웹 개발자를 위한 문서 및 샘플 코드를 찾고, 읽고, 기여하는 고급 시스템입니다. MDN 사용자 가이드는 필요한 문서를 찾도록 MDN을 이용하는 방법을, 원한다면 좀 더 좋은, 더 광범위하고, 더 완전한 자료를 만들도록 돕는 방법을 열거하는 항목을 제공합니다.

- -

{{LandingPageListSubpages}}

diff --git a/files/ko/mdn/yari/index.html b/files/ko/mdn/yari/index.html new file mode 100644 index 0000000000..becf84221a --- /dev/null +++ b/files/ko/mdn/yari/index.html @@ -0,0 +1,26 @@ +--- +title: '쿠마(Kuma): MDN 위키 플랫폼' +slug: MDN/Kuma +tags: + - MDN 메타 + - 시작하기 + - 쿠마 +translation_of: MDN/Kuma +--- +
{{MDNSidebar}}
+ +
{{IncludeSubnav("/ko/docs/MDN")}}
+ +
쿠마(Kuma)는 MDN Web Docs를 작동시키는 Django 코드 입니다. 
+ +

{{SubpagesWithSummaries}}

+ +

Kuma와 함께해주세요. 

+ +

함께 하고 싶다면 

+ + -- cgit v1.2.3-54-g00ecf