From 33058f2b292b3a581333bdfb21b8f671898c5060 Mon Sep 17 00:00:00 2001 From: Peter Bengtsson Date: Tue, 8 Dec 2020 14:40:17 -0500 Subject: initial commit --- files/zh-cn/mdn/about/index.html | 111 +++ files/zh-cn/mdn/community/conversations/index.html | 59 ++ files/zh-cn/mdn/community/doc_sprints/index.html | 123 +++ files/zh-cn/mdn/community/index.html | 53 ++ .../zh-cn/mdn/community/whats_happening/index.html | 42 + .../index.html" | 101 +++ .../community/\350\247\222\350\211\262/index.html" | 12 + files/zh-cn/mdn/contribute/feedback/index.html | 46 ++ .../mdn/contribute/getting_started/index.html | 129 ++++ .../convert_code_samples_to_be_live/index.html | 30 + .../howto/create_an_mdn_account/index.html | 44 ++ .../howto/create_and_edit_pages/index.html | 186 +++++ .../howto/do_a_technical_review/index.html | 57 ++ .../howto/do_an_editorial_review/index.html | 55 ++ files/zh-cn/mdn/contribute/howto/index.html | 16 + .../howto/link_a_github_account/index.html | 89 +++ .../howto/set_the_summary_for_a_page/index.html | 59 ++ files/zh-cn/mdn/contribute/howto/tag/index.html | 536 +++++++++++++ .../howto/tag_javascript_pages/index.html | 69 ++ .../write_a_new_entry_in_the_glossary/index.html | 107 +++ .../howto/write_an_api_reference/index.html | 446 +++++++++++ .../index.html | 505 +++++++++++++ .../index.html | 117 +++ .../mdn/contribute/howto/write_for_seo/index.html | 77 ++ .../index.html" | 30 + .../index.html" | 185 +++++ .../index.html" | 53 ++ files/zh-cn/mdn/contribute/index.html | 20 + files/zh-cn/mdn/contribute/localize/index.html | 68 ++ .../localize/localization_projects/index.html | 49 ++ .../mdn/contribute/localize/rss_feeds/index.html | 217 ++++++ .../localize/starting_a_localization/index.html | 65 ++ .../localize/translating_pages/index.html | 54 ++ .../mdn/contribute/persona_sign-in/index.html | 26 + files/zh-cn/mdn/editor/basics/index.html | 61 ++ .../mdn/editor/basics/page_controls/index.html | 37 + files/zh-cn/mdn/editor/basics/page_info/index.html | 47 ++ files/zh-cn/mdn/editor/edit_box/index.html | 145 ++++ files/zh-cn/mdn/editor/index.html | 20 + files/zh-cn/mdn/editor/source_mode/index.html | 121 +++ .../zh-cn/mdn/guidelines/content_blocks/index.html | 44 ++ .../mdn/guidelines/css_style_guide/index.html | 841 +++++++++++++++++++++ files/zh-cn/mdn/guidelines/index.html | 16 + files/zh-cn/mdn/guidelines/layout/index.html | 7 + .../guidelines/rules_of_mdn_documenting/index.html | 193 +++++ files/zh-cn/mdn/guidelines/style_guide/index.html | 784 +++++++++++++++++++ files/zh-cn/mdn/index.html | 30 + files/zh-cn/mdn/kuma/index.html | 24 + .../mdn/mdn_product_advisory_board/index.html | 22 + .../mdn_product_advisory_board/members/index.html | 57 ++ .../membership/index.html | 127 ++++ .../mdn/structures/compatibility_tables/index.html | 500 ++++++++++++ files/zh-cn/mdn/structures/index.html | 18 + files/zh-cn/mdn/structures/live_samples/index.html | 213 ++++++ .../simple_live_sample_demo/index.html | 31 + .../mdn/structures/macros/custom_macros/index.html | 222 ++++++ files/zh-cn/mdn/structures/macros/index.html | 48 ++ files/zh-cn/mdn/user_guide/writing/index.html | 64 ++ 58 files changed, 7508 insertions(+) create mode 100644 files/zh-cn/mdn/about/index.html create mode 100644 files/zh-cn/mdn/community/conversations/index.html create mode 100644 files/zh-cn/mdn/community/doc_sprints/index.html create mode 100644 files/zh-cn/mdn/community/index.html create mode 100644 files/zh-cn/mdn/community/whats_happening/index.html create mode 100644 "files/zh-cn/mdn/community/\345\234\250\347\244\276\345\214\272\345\267\245\344\275\234/index.html" create mode 100644 "files/zh-cn/mdn/community/\350\247\222\350\211\262/index.html" create mode 100644 files/zh-cn/mdn/contribute/feedback/index.html create mode 100644 files/zh-cn/mdn/contribute/getting_started/index.html create mode 100644 files/zh-cn/mdn/contribute/howto/convert_code_samples_to_be_live/index.html create mode 100644 files/zh-cn/mdn/contribute/howto/create_an_mdn_account/index.html create mode 100644 files/zh-cn/mdn/contribute/howto/create_and_edit_pages/index.html create mode 100644 files/zh-cn/mdn/contribute/howto/do_a_technical_review/index.html create mode 100644 files/zh-cn/mdn/contribute/howto/do_an_editorial_review/index.html create mode 100644 files/zh-cn/mdn/contribute/howto/index.html create mode 100644 files/zh-cn/mdn/contribute/howto/link_a_github_account/index.html create mode 100644 files/zh-cn/mdn/contribute/howto/set_the_summary_for_a_page/index.html create mode 100644 files/zh-cn/mdn/contribute/howto/tag/index.html create mode 100644 files/zh-cn/mdn/contribute/howto/tag_javascript_pages/index.html create mode 100644 files/zh-cn/mdn/contribute/howto/write_a_new_entry_in_the_glossary/index.html create mode 100644 files/zh-cn/mdn/contribute/howto/write_an_api_reference/index.html create mode 100644 files/zh-cn/mdn/contribute/howto/write_an_api_reference/information_contained_in_a_webidl_file/index.html create mode 100644 files/zh-cn/mdn/contribute/howto/write_an_article_to_help_learn_about_the_web/index.html create mode 100644 files/zh-cn/mdn/contribute/howto/write_for_seo/index.html create mode 100644 "files/zh-cn/mdn/contribute/howto/\345\246\202\344\275\225\346\267\273\345\212\240\346\210\226\346\233\264\346\226\260\346\265\217\350\247\210\345\231\250\345\205\274\345\256\271\346\200\247\346\225\260\346\215\256/index.html" create mode 100644 "files/zh-cn/mdn/contribute/howto/\345\255\246\344\271\240_\344\272\244\344\272\222_\345\234\250\347\272\277_\350\265\267\346\255\245_\345\274\200\345\247\213/index.html" create mode 100644 "files/zh-cn/mdn/contribute/howto/\346\210\220\344\270\272\344\270\200\345\220\215\346\265\213\350\257\225\347\211\210\350\257\225\351\252\214\345\221\230/index.html" create mode 100644 files/zh-cn/mdn/contribute/index.html create mode 100644 files/zh-cn/mdn/contribute/localize/index.html create mode 100644 files/zh-cn/mdn/contribute/localize/localization_projects/index.html create mode 100644 files/zh-cn/mdn/contribute/localize/rss_feeds/index.html create mode 100644 files/zh-cn/mdn/contribute/localize/starting_a_localization/index.html create mode 100644 files/zh-cn/mdn/contribute/localize/translating_pages/index.html create mode 100644 files/zh-cn/mdn/contribute/persona_sign-in/index.html create mode 100644 files/zh-cn/mdn/editor/basics/index.html create mode 100644 files/zh-cn/mdn/editor/basics/page_controls/index.html create mode 100644 files/zh-cn/mdn/editor/basics/page_info/index.html create mode 100644 files/zh-cn/mdn/editor/edit_box/index.html create mode 100644 files/zh-cn/mdn/editor/index.html create mode 100644 files/zh-cn/mdn/editor/source_mode/index.html create mode 100644 files/zh-cn/mdn/guidelines/content_blocks/index.html create mode 100644 files/zh-cn/mdn/guidelines/css_style_guide/index.html create mode 100644 files/zh-cn/mdn/guidelines/index.html create mode 100644 files/zh-cn/mdn/guidelines/layout/index.html create mode 100644 files/zh-cn/mdn/guidelines/rules_of_mdn_documenting/index.html create mode 100644 files/zh-cn/mdn/guidelines/style_guide/index.html create mode 100644 files/zh-cn/mdn/index.html create mode 100644 files/zh-cn/mdn/kuma/index.html create mode 100644 files/zh-cn/mdn/mdn_product_advisory_board/index.html create mode 100644 files/zh-cn/mdn/mdn_product_advisory_board/members/index.html create mode 100644 files/zh-cn/mdn/mdn_product_advisory_board/membership/index.html create mode 100644 files/zh-cn/mdn/structures/compatibility_tables/index.html create mode 100644 files/zh-cn/mdn/structures/index.html create mode 100644 files/zh-cn/mdn/structures/live_samples/index.html create mode 100644 files/zh-cn/mdn/structures/live_samples/simple_live_sample_demo/index.html create mode 100644 files/zh-cn/mdn/structures/macros/custom_macros/index.html create mode 100644 files/zh-cn/mdn/structures/macros/index.html create mode 100644 files/zh-cn/mdn/user_guide/writing/index.html (limited to 'files/zh-cn/mdn') diff --git a/files/zh-cn/mdn/about/index.html b/files/zh-cn/mdn/about/index.html new file mode 100644 index 0000000000..912b4e8e75 --- /dev/null +++ b/files/zh-cn/mdn/about/index.html @@ -0,0 +1,111 @@ +--- +title: 关于 MDN +slug: MDN/About +tags: + - MDN + - 合作伙伴 + - 指南 + - 文档 + - 版权 + - 社区 + - 许可 +translation_of: MDN/About +--- +
{{MDNSidebar}}
+ +

MDN Web Docs 是一个提供 Web 技术和促进 Web 技术软件的不断发展的学习平台，包括：

+ + + +

我们的使命

+ +

MDN 的使命很简单：为开发人员提供在开放的 Web 网络上轻松构建项目所必需的信息。如果它是一种暴露于 Web 网络上的开放技术，我们希望将其记录下来。

+ +

此外，我们还提供有关 Mozilla 产品 以及如何构建和贡献 Mozilla 项目的文档。

+ +

如果你不确定 MDN 是否应涵盖特定主题，请阅读：这是否属于 MDN ？

+ +

如何帮助我们

+ +

想要帮助 MDN ，你并不需要编写代码的能力！你可以通过很多其他的途径帮助我们，包括复查文章来保证文章的可读性，添加示例代码等。实际上，帮助我们的方法有很多，我们还专门建立了一个入门指南来帮你上手，它可以根据你的兴趣和你的空闲时间推荐合适的任务！

+ +

你也可以在个人博客或网站中添加 MDN 链接来帮助我们推广。

+ +

MDN 社区

+ +

我们的社区遍及全球！我们拥有来自世界各地、使用不同语言的了不起的贡献者。如果您想了解更多我们的信息，或者想以任何方式帮助 MDN ，请查看我们的邮件列表或 IRC 聊天频道！

+ +

版权和许可

+ +

MDN 文档来自于包括 Mozilla 基金会内部与外部编辑者的贡献。除非另有说明，文档基于署名 - 相同方式共享许可（CC-BY-SA）V2.5及以上版本发布。请在包括链接至特定文档页面的内容来源在内，以“Mozilla 贡献者”名义署名。例如，在为本文署名时，你需要这样写：

+ +
“ Mozilla贡献者基于CC-BY-SA 2.5协议发布的关于MDN. ”
+ +

注意，在示例中，“Mozzilla 贡献者”链接了引用页面的历史版本。请浏览Best practices for attribution以获得进一步的解释。

+ +
+

注意: 请浏览 MDN content on WebPlatform.org 获取在上述网站使用和署名 MDN 内容的信息。

+
+ +

在2010年8月20日之前添加到 wiki 中的示例代码通过MIT license发布，你应该向MIT模板中添加相应的属性信息："© <最后修订时间> <发布者姓名>"。

+ +

在2010年8月20日之后添加到wiki中的示例代码属于 public domain. 版权声明是不必要的，如果你需要，可以使用以下内容："Any copyright is dedicated to the Public Domain. http://creativecommons.org/publicdomain/zero/1.0/".

+ +

如果你需要对该 wiki 作出贡献，你必须在Attribution-ShareAlike license (或者在你编辑的页面已经制定的其他版权许可)下发布你的文档，在 Creative Commons CC-0 (a Public Domain dedication)下发布你的示例代码。将内容添加到这个 wiki 表明你同意在相应的许可之下发布你贡献的内容。

+ +

一些历史内容是在不同于以上的版权许可之下发布的，这些已在页面底部通过其他版权许可的方式进行了标注。

+ +
+

重要说明: 任何新建的页面都不可以使用其他版权许可。

+
+ +

贡献的内容的版权在作者未授予他人之前归原作者所有。

+ +

对于此处讨论的话题有任何问题，请联系 Eric Shepherd。

+ +
+

Mozilla 基金会的商标、标识、服务标志以及网站的设计、外观不包含在基于知识共享许可的范围内。从某种意义上说，它们是内容的创造者（如图标和图形设计），而这些内容并不在上述许可范畴内发布。 如果你也希望这样发布文档，或者你对这些许可条款还有任何的疑问，你可以联系 Mozilla 基金会以获得更多的帮助： licensing@mozilla.org.

+ +

下载整站内容

+ +

你可以下载 MDN 的镜像文件(2017年2月，总共2.1GB)

+ +

单独页面

+ +

你可以通过在页面URL后添加文档参数来制定需要的格式，获取MDN上每个单页的内容。

+ +

第三方工具

+ +

你可以使用第三方工具访问 MDN 的内容，例如 Dash (适用于 Mac OS) 和 Zeal (适用于 Linux 和 Windows)。

+ +

向 MDN 报告错误

+ +

在使用MDN的过程中，你将不时遇到问题。不论是网站基础设施的问题或者你查看的文档的错误，你都可以自己修改或报告错误。前者是更推荐的，但有时候后者可能更适合于你，那当然也是可行的。

+ +

文档错误

+ +

显然，由于 MDN 是一个 wiki ，因而最佳的解决你遇到的问题的方法是自己动手解决。然而有时候，你也许不知道如何解决或者因为其他重要的事无法脱身，那么此时你需要将问题记录下来，以便于之后方便其他人查看。

+ +

你只需要在 documentation request bug 登陆后提交一个错误表单来报告错误，之后的工作将由Mozilla处理。我们的文档请求表单便捷易用,它会收集解决问题所需的必要信息。

+ +

当然，我们的编辑社区是十分繁忙的，因而有时候最快的确认文档问题是否解决的方案是自己动手修正。参见创建与编辑页面以了解更多信息。

+ +

站点错误反馈或新特性请求

+ +

Kuma 是 Mozilla 开发的用于驱动 MDN 的平台，目前仍处在持续开发的进程中。我们的开发者，以及大量的志愿者，正在不断的对这个平台作出改进。如果你在使用网站时发现了错误，或者遇到的问题，或者有新的可以让这个软件更加完美的想法建议，可以使用 Kuma bug form 进行反馈。

+ +

MDN历史

+ +

Mozilla 开发者网络（亦称作 Mozilla 开发者中心（MDC）或 Devmo）在2005年年初启动。那时 Mozilla 基金会 从 AOL 获得了许可协议，得以使用原创的 DevEdge 内容。DevEdge 内容的引入具有抛砖引玉之效，因此在那不久在社区志愿者的努力下它被迁移到了这个更易于更新与维护的 wiki 。

+ +

此后，这个项目不断发展，现在已经成为所有与关于 Mozilla 项目和开放网络技术的文档的核心一环。在2010年，该项目更名为Mozilla开发者网络（Mozilla Developer Network）。2011年，又添加了供web开发者分享与展示代码的 Demo Studio 与提供教程的 Learning 页面。（MDC 现在表示了"MDN文档中心（MDN Doc Center）"）现在，Mozilla开发者网络正向着成为供Web设计师、应用开发者、以及拓展、主题制作者们时常参考的资源的方向发展。

+ +

更多关于 Mozilla 的后世前身可在我们的十周年纪念庆页面查看,其中还有参与者发表的 Ta 对 Mozilla 的评价。

+ +

关于 Mozilla

+ +

想要了解是什么在驱动着我们，是什么使我们与众不同，请访问使命页面。在那里你能了解更多关于我们的信息，不论你想知道如何成为 Mozilla 的一员，或者仅仅想知道如何找到我们。

diff --git a/files/zh-cn/mdn/community/conversations/index.html b/files/zh-cn/mdn/community/conversations/index.html new file mode 100644 index 0000000000..e37d40486e --- /dev/null +++ b/files/zh-cn/mdn/community/conversations/index.html @@ -0,0 +1,59 @@ +--- +title: MDN 社区对话 +slug: MDN/Community/Conversations +tags: + - 不完善的 + - 后期还需要改善 + - 社区相关 + - 经过一次润色的 +translation_of: MDN/Community/Conversations +--- +
{{MDNSidebar}}
+ +

MDN的“工作”在MDN网站开展，但“社区”也通过（异步）讨论以及（同步）在线聊天和会议开展。

+ +

异步讨论

+ +

为了分享信息并进行持续的讨论，MDN在Mozilla话语论坛中有自己的类别（“MDN”）。 将此类别用于与MDN相关的所有主题，包括文档内容的创建，翻译和维护; MDN平台开发; 并进行规划，目标设定和进度跟踪。

+ + + +

历史档案

+ +

在2017年6月之前，MDN相关的讨论发生在与Google群组关联并归档的邮件列表中。 如果您想搜索这些过去的讨论，您可以查看与旧邮件列表相对应的Google网上论坛。 （是的，我们知道这些名字是重叠和混淆。历史的偶然性。对此我们感到很抱歉。）

+ +
+
mozilla.dev.mdc
+
此列表用于讨论MDN上的文档内容。
+
mozilla.dev.mdn
+
此列表涉及MDN底层Kuma平台的开发工作。
+
mozilla.mdn
+
这个论坛是针对高层次的规划和优先级讨论，MDN网站和其他相关举措。
+
+ + + +

同步聊天

+ +

Mozilla实时的讨论平台是Matrix，Mozilla自己拥有使用这个通讯协议的服务器。网页中即可加入讨论。

+ +

MDN Web文档聊天室是为讨论MDN内容的主要频道。我们探讨编写、内容编排等内容。我们也会进行“茶水间”讨论（摸鱼），这是我们的社群保持联系，或者仅仅用来消遣的方式。通常在北美和欧洲的工作日，这间聊天室最为活跃。

+ +

你或许会想了解一下怎么使用Mozilla的Matrix，然后呢，如果你真的很喜欢它的话，那么可以安个独立的Matrix应用，例如Riot.im。

+ +

那么IRC呢？

+ +

多年来，Mozilla用互联网中继聊天（IRC）来进行实时讨论。到了2020年初，Matrix已经把IRC淘汰了。你可能会在很多地方看到有人提到IRC的频道，包括MDN上。你可以帮忙更新MDN上你看到的IRC频道的链接，为指向对应Matrix聊天室的链接。如果你不确定这个话题对应的Matrix聊天室是哪间，那么可以来General聊天室询问。不再活跃的项目和话题可能也不会有Matrix聊天室，如果是这样的话，把链接删掉即可。

+ +

参加我们的会议（和其他活动）

+ +


+ MDN团队会举行一些面向MDN社区的定期会议。查看 Mozilla维基上的MDN Meetings 页面获取关于日程、议程和笔记的细节，以及如何参加的信息。

+ +

查看MDN Events calendar上的这些和其他会议、当地聚会和其他项目。在 MDN Meetings wiki page上有定期会议

+ +

如果你看到一个在Vidyo videoconferencing系统的“mdn”频道举行的会议，你可以在网上加入谈话。

diff --git a/files/zh-cn/mdn/community/doc_sprints/index.html b/files/zh-cn/mdn/community/doc_sprints/index.html new file mode 100644 index 0000000000..ca1da4be91 --- /dev/null +++ b/files/zh-cn/mdn/community/doc_sprints/index.html @@ -0,0 +1,123 @@ +--- +title: Doc sprints +slug: MDN/Community/Doc_sprints +tags: + - NeedsUpdate +translation_of: MDN/Community/Doc_sprints +--- +
{{MDNSidebar}}
+ +

{{ draft() }}

+ +
+

Note: MDN社区在2010 - 2013年期间经常举办文档迭代。 从2014年开始，这些事件的范围扩大到“Hack on MDN”事件，其中包括代码窃取以及文档项目。 下面的大部分建议同样适用于 "Hack" sprints和documentation sprints。

+
+ +

这是组织documentation sprint的指南。 它包含来自组织doc sprints的人的建议和提示，以帮助您更好的组织文档。 本指南还借鉴了FLOSS手册书籍的书籍。

+ +

什么是 doc sprint?

+ +

doc sprint 是一段时间，一群人像你一样可爱的人，合作撰写关于给定主题或相关主题的文档。

+ +

sprints 的分类

+ +

sprints可以是线上的，也可以是线下的，也可以线上线下一起进行。对于线上sprints而言，每个人都可以在不同的地区参与，只需要通过中间渠道进行沟通。对于线下sprints，参加者在sprints期间聚集在同一地区，以便他们可以面对面进行交流。线下sprints需要更多的后勤规划，确保会议地点，可以容纳所有参与者，并且在sprints期间需要提供食物与安置参与者。

+ +

另一种分类sprints的方式是通过专题聚焦。例如sprint可能关注特定的主题，比如：Web开发，或翻译特定语言。

+ +

计划一次 sprint

+ +

设定目标

+ +

明确这次 sprint的目标, 包括内容和社区效应。 这能够帮助你更好地计划低层次的细节。

+ + + +

决定类型和范围

+ +

基于你的目标, 确定 sprint的类型 (线上的，也可以是线下的，或者是线上线下一起进行) 和范围 (这是参与者会关注的)。

+ +

比如说，你想要吸引新的社区成员，你可以选择本地的线下sprint, 因为不需要长途旅行, 而且参加者还可以见面. 如果您想要专注于特定的主题领域，其中内容贡献者是地理上分离的，而且早就彼此认识，那么一个线上sprint就很合适。

+ +

选择日期和时间

+ +

对于需要长途交通的线下sprint， 我们已经发现了三天 (比如说两天周末和一天工作日) 就足够做到很多重要的工作。也不会占用大家日常生活的很多时间。对于公开，本地，线下的sprint，大部分人只能够付出一天的时间. 对于线上的sprint, 我们通常进行两天: 一个工作日外加周末的一天。 As an alternative example, in the past there has been mini-sprint for writing and translating docs, every Wednesday evening in the Mozilla Paris office; it was primarily in-person for locals, but also got remote participation from Montreal (where it was at lunch time).

+ +

Attaching a sprint to the end of a conference that everyone attended worked well; trying to run a sprint during a conference that everyone attended did not work so well. Make sure that participants know about the sprint when they make their conference plans, so that they allow extra days for the sprint.

+ +

Consider the time zones that virtual participants are in; be sure that you allow enough working time in each time zone, and have some overlap when multiple zones (such as Europe and Americas, or Americas and Asia) are awake. However, it's just reality that no one time is good for everyone everywhere.

+ +

For virtual sprints, the dates can be set as little as 2-3 weeks in advance. For in-person sprints, you need to decide further in advance, in order to allow time for people to decide and make travel arrangements.

+ +

Promote the sprint

+ +

You can make the sprint open, and invite the world, but you should have a few key people that you know for sure will participate. Work with them when selecting dates, to ensure that they are available during the chosen dates. If the sprint is not open, then you need only extend invitations; make sure that each invitation is personal, explaining why that person has been specificallly invited.

+ +

For public sprints, identify existing groups that have an interest in the topic, for example: local Web developer meetup groups for a local in-person sprint. Send an announcement through whatever channel is appropriate for that group. Be sure to provide a link to a web page with more details, and include a call-to-action for people to sign up for the sprint. Eventbrite and Lanyrd are two services that support sign-ups. For Mozilla developer events, we have found that about half the people who sign up actually show up.

+ +

Use the social media channels that are appropriate to reach your target attendees. We have found that for Web developers, this means Twitter, followed by Google Plus, more than Facebook or LinkedIn. However, popular channels can vary geographically (such as Orkut in Brazil). Reach out to a few well-connected people who have a large following among your target audience, and ask them to re-share your posts.

+ +

Logistics for in-person sprints

+ +

Logistics for in-person sprints are greater for longer sprints and those where sprinters travel to attend. A short or locals-only sprint need relatively little logistical support.

+ +

Budget and funding

+ +

You need to figure out how much the event is going to cost, and where the money is going to come from.

+ +

Costs to consider in your budget include:

+ + + +

Some of these costs can be self-funded by participants, meaning that they pay for their own costs. There are a variety of ways to save money, which are mentioned in the following sections.

+ +

It may be possible to get sponsorship from Mozilla to fund some of the costs of your event. It helps to have a clear focus for your event, and a specific plan and budget. If there is a Mozilla Rep in your area, work with them to request budget and swag through the Reps program. Otherwise, you can submit a developer events request in Bugzilla.

+ +
+
Venue
+
There are lots of options for meeting space. If you are in a city with a Mozilla office, you can use the community space in that office. Elsewhere, options include meeting rooms in libraries, churches, coffee shops, or businesses where you have contacts. Many cities now have coworking spaces that rent their conference rooms for a reasonable fee.
+
Resources
+
Be sure that your venue has good chairs and tables, and reliable power and Internet access. Sitting all day on a bad chair is not just uncomfortable; it can lead to injury. Make sure that the number of sprinters and their computers and devices does not overwhelm the power supply and available Internet bandwidth. Be generous (but not dangerous) with extension cords, and if necessary, international plug adapters. A projector for shared viewing can be very helpful. Whiteboards and sticky notes are great for brainstorming and planning.
+
Travel
+
Travel is relevant only if the sprinters do not all live close to the sprint venue. The usual strategies for saving on travel apply, and are not specific to doc sprints.
+
Accommodations
+
Where sprinters stay should not be inconveniently far from the meeting venue. It can be cheaper (and possibly more fun) to split the cost of a vacation house or flat, rather than paying for individual hotel rooms. If you have a mix of visitors and (willing) locals, the visitors can stay in the homes of local community members.
+
Food
+
Sprinters need to eat! Make arrangements for food during the sprint, and inform sprinters if certain meals will not be arranged. If the group is staying in a home, you can save money by buying and cooking food rather than going out to eat. Even if food is self-funded, it can reduce hassle to pitch into a common fund for food, rather than splitting every restaurant bill. If your venue allows, have snacks (some healthy and some not) available between meals.
+
Fun
+
Make time for non-writing social activities. These can be informal, like going for a hike together, or more formal, like a tourist excursion. Going out for beer (at the end of the day, of course) is usually a winner. On the other hand, don't plan every hour of every day. Everybody needs some down time, especially introverts.
+
+ +

During the sprint

+ +

Planning the work

+ +

 

+ +

Tracking tasks

+ +

Have a way to track what tasks need to be worked on, who is doing what, and what has been completed. For MDN doc sprints, we use a wiki page for advance planning, and an etherpad for tracking work during the sprint.

+ +

Often, people want to help but don't know where to start, and deciding among many options takes too much mental effort. For any given participant, give them a couple of possible tasks ("you could do A, or B"); this simplifies their choice, without making them feel like they're being bossed around.

+ +

Collaborating

+ +

One of the benefits of in-person sprints is that people can work together in ways that they might not be able to when they're not in the same place, for example, by working out ideas together on a whiteboard or by brainstorming with sticky notes. Still, there are opportunities for collaboration and camaraderie in any type of sprint. Chatting via IRC is essential for virtual sprints, and still very helpful for in-person sprints (for example, for sharing links). For a greater sense of "virtual presence", consider using a video conferencing service, such as Google Hangout.

+ +

As an organizer, look for common interests among the participants and for ways that they can work together.

+ +

Celebrating accomplishments

+ +

Be sure to take time to celebrate accomplishments at the end of the sprint. This gives participants a better feeling than when the sprint just ends without any summary. If possible, have people "demo" what they have done, even if it is just showing a new article page.

+ +

Also, share the sprint accomplishments via a blog post, to celebrate publicly as well. This is important for any kind of sprint, but especially for virtual sprints, where the participants might not all be online at the official end of the sprint for a wrap-up session.

diff --git a/files/zh-cn/mdn/community/index.html b/files/zh-cn/mdn/community/index.html new file mode 100644 index 0000000000..19e3e729ce --- /dev/null +++ b/files/zh-cn/mdn/community/index.html @@ -0,0 +1,53 @@ +--- +title: 加入 MDN 社区 +slug: MDN/Community +tags: + - MDN Meta + - 引导 + - 社区 +translation_of: MDN/Community +--- +
{{MDNSidebar}}
+ +
{{IncludeSubnav("/zh-CN/docs/MDN")}}
+ +
+

MDN（Mozilla Developer Network）不仅仅是一个维基，而且是一个为使用开放 Web 技术的开发者而打造的社区。在这儿，开发者为了使 MDN 更加出色而共同努力。

+
+ +

我们非常乐意您能给 MDN 贡献一份力量。当然我们更加希望您能加入 MDN 社区。只需简单的三步，即可加入我们：

+ +
    +
  1. 创建 MDN 账户
    2. +
  2. 参与交流
    3. +
  3. 关注正发生的一切
    4. +
+ +

社区是怎么运作的

+ +

下列文章详细地介绍了 MDN 社区。

+ +
+
+
+
社区参与者
+
MDN 社区有许多负责任的参与者。
+
文档迭代
+
这是一个有关组织文档迭代的指导。它包含组织过文档迭代的开发者的建议和技巧，这个指导的目的是为了帮助您更好地组织文档。
+
关注正发生的一切
+
MDN 是由 Mozilla 开发者网络社区 发起的。这里有一些有关我们正在做的事物信息。
+
+ +
+
+
+ +
+
+
MDN 社区对话
+
MDN 上的工作在 MDN 社区网站上进行。但社区也提供讨论，在线交流和线下会议等多种对话方式。
+
社区工作
+
了解如何作为 MDN 社区的一部分来为 MDN 文档作贡献是本文的主题。本文给出了一些技巧来帮助您和其他开发者、开发团队来进行更有效的交流。
+
+
+
diff --git a/files/zh-cn/mdn/community/whats_happening/index.html b/files/zh-cn/mdn/community/whats_happening/index.html new file mode 100644 index 0000000000..abdb8b5215 --- /dev/null +++ b/files/zh-cn/mdn/community/whats_happening/index.html @@ -0,0 +1,42 @@ +--- +title: 跟随正在发生的事情 +slug: MDN/Community/Whats_happening +tags: + - MDN Meta + - 初学者 + - 指南 + - 社区 +translation_of: MDN/Community/Whats_happening +--- +
{{MDNSidebar}}
+ +

MDN是由 Mozilla开发者网络社区带给你的。这里是关于我们正在做之事的共享信息的一些途径。

+ +

博客

+ +
+
Mozilla Hacks
+
Web和Mozilla技术和功能的新闻深度报道。
+
Engaging Developers
+
促进社区参与Mozilla MDN活动和讨论。
+
+ +

信息流

+ + + +

状态栏和仪表盘

+ +

查看 文档状态 页面，以了解整个MDN内容的动态。您将能够看到哪些文章需要书写或更新，哪些主题需要最大的帮助以及更多。

+ +

MDN会议

+ +

有一些跟踪和各种MDN相关的项目和进程共享进步定期会议，这些都描述了MDN会议的维基页面。

+ +

想要了解最新动态，MDN社区会议是最佳渠道。MDN社区会议一般在美国太平洋时间周三上午10点举办（UTC-0800 十月——三月, UTC-0700 三月——十月）。会议每两周举办一次，会议采用 #mdn IRC 的方式举行。想要了解会议日程及往期会议记录，请查阅 MDN 社区会议 维基页面。

+ +

公共 MDN活动  日历包括MDN社区会议，文件分享，其他MDN相关活动。如果您在我们的Vidyo视频会议系统中遇到正在“mdn”频道中举办的会议，那么您可以 从从网站上加入会议对话。

diff --git "a/files/zh-cn/mdn/community/\345\234\250\347\244\276\345\214\272\345\267\245\344\275\234/index.html" "b/files/zh-cn/mdn/community/\345\234\250\347\244\276\345\214\272\345\267\245\344\275\234/index.html" new file mode 100644 index 0000000000..e8cce689d8 --- /dev/null +++ "b/files/zh-cn/mdn/community/\345\234\250\347\244\276\345\214\272\345\267\245\344\275\234/index.html" @@ -0,0 +1,101 @@ +--- +title: 社区工作 +slug: MDN/Community/在社区工作 +tags: + - 指南 + - 社区 +translation_of: MDN/Community/Working_in_community +--- +
{{MDNSidebar}}
+ +

在任何重大规模上为MDN文档作出贡献的主要部分是知道如何作为MDN社区的一部分工作。本文提供的技巧可帮助您充分利用与其他作者和开发团队的互动。

+ +

一般礼仪准则

+ +

以下是在Mozilla社区工作时的一些通用指导原则。

+ + + +

委婉

+ +

与他人沟通时要时刻保持委婉和恭敬。

+ +

礼貌地指出错误

+ +

如果您在联系某人的目的是要求他们采取不同的做法，或者指出他们所犯的错误（特别是他们反复犯错的话），请以正面评论开始您的信息。这可以减轻打击，这可以说，它表明你试图帮助，而不是让你成为坏人。 例如，如果一个新的贡献者创建了大量没有标签的页面，并且您想要指出这个问题，那么您给他们的消息可能看起来像这样（您需要为每个个案更改的内容加下划线):

+ +
+

嗨，MrBigglesworth，我一直注意到你对Wormhole API文档的贡献，并且能够得到你的帮助真是太棒了！我特别喜欢你通过可读性平衡细节水平的方式。尽管如此，如果您在页面中添加正确的标签，您可以使这些文章更好，更有用。

+ +

详细信息，请参阅MDN标记指南 (https://developer.mozilla.org/en-US/docs/MDN/Contribute/Howto/Tag) 。

+
+ +

分享知识

+ +

在您参与MDN项目时，了解发生了什么以及与我们社区的其他成员进行互动很有用。通过与我们社区中的其他人交谈，您可以获得并分享想法，状态更新等。我们还拥有工具和信息资源，可以帮助您了解由谁来完成的工作。

+ +

沟通渠道

+ +

您可以通过多种方式与社区成员（开发人员或作者）进行交流，每种方式都有自己特定的礼仪规则。

+ +

Bugzilla

+ +

在编写文档以涵盖由于Bugzilla中的错误而实施的更改时，您经常会与涉及这些错误的人员进行交互。请务必始终牢记Bugzilla礼仪指南！

+ +

电子邮件

+ +

有时候，如果你有他们的电子邮件地址，你和一个或多个其他人之间的私人电子邮件交换就是要走的路。

+ +
+

注意：一般来说，如果有人在您要记录的技术文档上发布了他们的电子邮件地址，已经亲自给您发送了他们的电子邮件地址，或者通常有一个众所周知的电子邮件地址，则电子邮件是可接受的“第一次联系人”做法。如果你需要挖掘它，你可能应该首先尝试获得IRC或邮件列表的许可，除非你已经用尽了所有其他尝试取得联系的努力。

+
+ +

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 {{IRCLink("mdn")}} channel on IRC. This channel is specifically reserved for discussing documentation. For IRC-specific etiquette tips, see the Mozilla Support article "Getting Started with IRC." You'll also have discussions with us on the MDN discussion forum. In general, IRC tends to be used for quick, more in-person-like discussions, while the discussion forum is typically used for longer-duration conversation.

+ +

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

+ +

See also

+ + diff --git "a/files/zh-cn/mdn/community/\350\247\222\350\211\262/index.html" "b/files/zh-cn/mdn/community/\350\247\222\350\211\262/index.html" new file mode 100644 index 0000000000..e9ceeacc0b --- /dev/null +++ "b/files/zh-cn/mdn/community/\350\247\222\350\211\262/index.html" @@ -0,0 +1,12 @@ +--- +title: 社区的角色 +slug: MDN/Community/角色 +tags: + - Community + - Landing + - MDN Meta +translation_of: MDN/Community/Roles +--- +
{{MDNSidebar}}

在MDN社区中有多种类型的角色，每个角色都有明确的职责。

+ +

{{LandingPageListSubPages()}}

diff --git a/files/zh-cn/mdn/contribute/feedback/index.html b/files/zh-cn/mdn/contribute/feedback/index.html new file mode 100644 index 0000000000..1eb0e71883 --- /dev/null +++ b/files/zh-cn/mdn/contribute/feedback/index.html @@ -0,0 +1,46 @@ +--- +title: 发送有关MDN Web Docs的反馈 +slug: MDN/Contribute/Feedback +tags: + - 公用 +--- +
{{MDNSidebar}}
+ +

欢迎来到 Mozilla 开发者网络！如果你现在遇到了一些问题，或者想要给我们提一些建议，那么你来对地方了。在事实上，向我们提供反馈会使你更接近 Mozilla 社区中的一员，我们提前祝贺你。

+ +

你可以使用本文下方提到的方式来发表你自己的看法。

+ +

更新文档

+ +

首先，如果你发现某篇文档存在问题，首先应该尝试自己能否修正它。你只需登录，然后点击蓝色的"编辑"按钮打开编辑器，就可以编辑那份文档了。这里的所有文档都是以 wiki 为形式，它们是由一些 Mozilla 员工和志愿者共同维护的，你不用担心犯错，你在编辑文档时的用语也并非必须完全正确。如果你弄错什么，我们会发现和修复它，完全ok！

+ +

想要了解更多有关如何贡献 MDN 文档的知识，请查看：

+ + + +

加入讨论组

+ +

我们使用互联网中继聊天（IRC）系统来讨论关于 MDN 的所有事情。你可以加入我们！根据你感兴趣的领域不同，我们有几个频道可供你选择：

+ +
+
开发者文档内容(#devmo)
+
#devmo 频道用来讨论与实际的文档内容有关的话题。如果你有和某篇文档相关的问题，想察看某些方面的文档，或者想自己写一些新的文档，都可以来这里与我们交流。
+
MDN网站(#mdn)
+
这个频道讨论关于 MDN 的任何事情。如果你不确定应该去哪个频道寻求帮助，或者不知道你具体遇到了哪个方面的问题，可以在这里提问。
+
文档站点开发(#mdndev)
+
#mdndev 频道是我们讨论 MDN 网站所使用的这个 wiki 系统（名为 kuma）的地方。如果网站本身的功能遇到了问题，或者你有一些好点子能让这个系统变得更好，那么就加入我们的讨论吧。
+
+ +

报告一个问题

+ +

文档问题

+ +

如果你在某个文档中发现了任何的错误，但又无法自己修复，那么你就可以把这个问题报告给我们！谢谢

+ +

网站问题

+ +

如果你遇到了一些 MDN 网站本身的问题，或者有一些能改进MDN系统的好点子，可以到 Mozilla 的 Bugzilla 系统上提交一个请求。 

diff --git a/files/zh-cn/mdn/contribute/getting_started/index.html b/files/zh-cn/mdn/contribute/getting_started/index.html new file mode 100644 index 0000000000..76ae0b45db --- /dev/null +++ b/files/zh-cn/mdn/contribute/getting_started/index.html @@ -0,0 +1,129 @@ +--- +title: 初识 MDN +slug: MDN/Contribute/Getting_started +tags: + - MDN元数据 + - MDN入门 + - 入门 + - 初学者 +translation_of: MDN/Contribute/Getting_started +--- +
{{MDNSidebar}}{{IncludeSubnav("/zh-CN/docs/MDN")}}
+ +

我们是一个由开发者和作者组成的开源社区，目的是为了建设一个更美好的网络，不论品牌、浏览器或平台。任何人都可以参与，每个人的贡献都会让我们更强大。我们可以一起继续推动 Web 创新服务于更广泛的利益。我们和你一起在这里开始。

+ +

MDN 的每一个部分（文档，演示，和网站本身）都是由一个开放的开发者社区创建的。任何人都可以贡献自己的力量，请加入我们吧！

+ +

简单三步参与 MDN

+ +

MDN（Mozilla Developer Network）是一个 wiki，这意味着任何人都可以向其添加和编辑内容。你不一定非得是一个程序员，或了解许多涉及技术方面的知识，才能参与进来。这里有很多任务，从简单的（如校对和纠正拼写）到复杂的（如撰写 API 文档），都等待着我们去完成。

+ +

做贡献很容易，也没有什么风险。即使你犯了一个错误，别人也能很容易更正它。即使你不知道该做什么，或者你的语法不是很好，别担心！我们有一个团队，这个团队的工作就是使 MDN 的内容尽善尽美。总会有人来再看一眼，确保你的文档是整洁且符合标准的。所以，请在此分享你的知识，发挥你的所长，在大家的共同努力下，MDN 只会越来越好。

+ +

步骤 1：创建一个 MDN 账号

+ +

在开始给 MDN 贡献自己的知识前，你需要有一个 MDN 帐号。详细信息请参阅如何创建一个帐户。

+ +

步骤 2：选择一个任务

+ +

现在你已经登录，在{{anch("可选的任务类型", "下面的列表")}}里阅读有关不同任务的描述，并决定哪一个任务是最吸引你的。你可以选择任何你喜欢的任务并开始贡献你的知识。

+ +

步骤 3：做任务

+ +

一旦你决定了想做什么任务，找一个具体的页面、示例代码等等就开动吧，尽管去做！

+ +

别担心做得是否完美，其他的 MDN 贡献者会来帮助修复那些错漏。如果你想尝试一下在 MDN 上编辑内容的感觉，或想在“真的做”一些事情之前实验一下，你可以在沙盒页面上练练手。如果你有疑问，请到交流社区页面获取邮件列表和在线聊天频道，在那里你可以找到答案。

+ +

完成任务之后，若恰巧时间空闲，你可以选择另一个项任务，或者看看下面其它你可以在 MDN 上做的事情。

+ +

可选的任务类型

+ +

基于你的技能和兴趣，你有很多方法可以帮助到 MDN。尽管一些任务可能是艰巨的，但同时我们也有很多相对简单的任务。很多只需要五分钟（或更少！）。通过做任务和阅读它的简短描述，你会发现每一种类型的任务通常都是需要近似的时间的。

+ +

选项 1：我喜欢文字

+ +

你可以帮我们审核或编辑现有的文档，并对它们应用正确的标签。

+ + + +
+

注意：在你审查已有的文章或者编写新的文章之前，最好先看一下我们的风格指南，这有助于保证大家写出的文章的风格是一致的。

+
+ +

选项 2：我喜欢代码

+ +

我们需要更多的代码示例！你也可以帮助构建我们的网站平台 —— Kuma！

+ + + +

选项 3：我喜欢文字和代码

+ +

我们有需要的技术和语言技能的任务，像写新文章，审查技术的准确性，或改编文档等。

+ + + +

选项 4：我想翻译 MDN

+ +

所有的本地化与翻译工作是由我们优秀的MDN社区志愿者做的。

+ + + +

选项 5: 我发现了一些错误的信息，但我不知道该怎样修复它

+ +

你可以在 Bugzilla 上提交 bug。（5分钟）

+ + + + + + + + + + + + + + + + + + + + + + + + +
Bugzilla字段内容
产品开发者文档
组件选择一个适合其主题的范围。当你不确定或者没有找到合适的主题时，可以选择“General”
URL你发现问题的页面
描述请尽你所能的去描述这个问题，并且谈谈在何处能找到正确的解决方案。这一内容既可以是其他人（交谈中涉及到的），也可以是网页链接
+ +

其它可以在 MDN 上做的事情

+ + diff --git a/files/zh-cn/mdn/contribute/howto/convert_code_samples_to_be_live/index.html b/files/zh-cn/mdn/contribute/howto/convert_code_samples_to_be_live/index.html new file mode 100644 index 0000000000..243f6b29a7 --- /dev/null +++ b/files/zh-cn/mdn/contribute/howto/convert_code_samples_to_be_live/index.html @@ -0,0 +1,30 @@ +--- +title: 如何将代码示例转换成“实时的” +slug: MDN/Contribute/Howto/Convert_code_samples_to_be_live +translation_of: MDN/Contribute/Howto/Convert_code_samples_to_be_live +--- +
{{MDNSidebar}}

MDN 拥有一套 "live sample" 系统，在那里页面上展示的代码示例将被直接使用，以显示该示例的输出结果。然而，许多现有文章的代码示例还没有使用这套系统，它们需要被转换。

+ +

实样让你可以看到示例输出的样子，让文档生动有益。这篇指南涵盖如何获取现有示例并添加上“实时的”功能性。

+ +
+
哪里需要完成它？
+
标记有 NeedsLiveSample 的文章。
+
做这项任务你需要知道哪些？
+
+
    +
  • 基于代码示例，对 HTML, CSS 和/或 JavaScript 的理解。
    • +
  • 能够在 MDN 文章中使用 KumaScript 宏。
    • +
+
+
做这项任务的步骤是什么？
+
+
    +
  1. 从标记 NeedsLiveSample 的文章列表中选取一篇文章，这篇文章里的代码示例是你熟悉的。
    2. +
  2. 转换代码示例为“实例的”。
    3. +
  3. 删除之前用于显示示例输出结果的任何代码或图像。
    4. +
+
+
+ +

关于创建和编辑实样的更多信息，见 Using the live sample system

diff --git a/files/zh-cn/mdn/contribute/howto/create_an_mdn_account/index.html b/files/zh-cn/mdn/contribute/howto/create_an_mdn_account/index.html new file mode 100644 index 0000000000..256d61b897 --- /dev/null +++ b/files/zh-cn/mdn/contribute/howto/create_an_mdn_account/index.html @@ -0,0 +1,44 @@ +--- +title: 如何创建 MDN 账号 +slug: MDN/Contribute/Howto/Create_an_MDN_account +tags: + - MDN + - 创建账户 + - 初学者指南 + - 新手上路 +translation_of: MDN/Contribute/Howto/Create_an_MDN_account +--- +
{{MDNSidebar}}
+ +

 要对MDN的内容进行任何更改，你需要一个MDN账户。别担心，如果你只是打算阅读或搜索MDN，就不需要一个账户！这个指南  将帮助你建立MDN账户。

+ +
+
+

为什么MDN需要我的电子邮件地址？

+ +

你的电子邮件地址用于帐户恢复；必要时，MDN管理员会通过它来联系您，讨论你的账户或在网站上的活动。

+ +

此外，你可以选择订阅通知（例如，当特定的页面被更改）和消息（例如，如果你选择加入我们的beta测试团队，你可能会收到关于待测试新功能的邮件）。

+ +

你的电子邮件地址永远不会显示在MDN，并只会按照我们的隐私政策使用。

+ +
如果你通过Github登录到MDN，并且你的Github账号使用了“noreply”的电子邮件地址，你将不会收到任何来自MDN的信息（包括你从页面订阅的通知）。
+
+
+ +
    +
  1. 在每个MDN页面的顶部都有一个登录按钮。将鼠标指向它（如果你在移动设备上使用，轻触即可），以显示支持的登录到MDN的认证服务列表。
    2. +
  2. 选择一项服务以登录。目前，我们只支持使用Github登录。值得注意的是如果你选择GitHub，你的MDN公开资料页上将显示一个链接，其指向你的GitHub个人资料页。
    3. +
  3. 按照Github的提示，将你的GitHub帐户绑定到MDN。
    4. +
  4. 从认证服务页面返回到MDN之后，MDN会提示你输入用户名和电子邮件地址。你的用户名会公开显示，以便展示你做过的工作。请不要将你的电子邮件地址作为用户名。
    5. +
  5. 点击创建我的MDN个人资料。
    6. +
  6. 如果你在步骤4中指定的电子邮件地址与认证服务所使用的不同，请检查这个邮箱，并点击我们发送的确认邮件中的链接。
    7. +
+ +

一切就绪！你已经拥有一个MDN帐户，并可以立即编辑页面！

+ +

你可以在任何MDN页面的顶部点击你的名字以查看账号的公开资料。从那里，你可以点击编辑按钮修改或更新你的个人资料。

+ +
+

注：新用户名不能包含空格或“@”字符。请记住，你的用户名将会公开显示，以标识你做过的工作！

+
diff --git a/files/zh-cn/mdn/contribute/howto/create_and_edit_pages/index.html b/files/zh-cn/mdn/contribute/howto/create_and_edit_pages/index.html new file mode 100644 index 0000000000..57f573339d --- /dev/null +++ b/files/zh-cn/mdn/contribute/howto/create_and_edit_pages/index.html @@ -0,0 +1,186 @@ +--- +title: 如何创建及编辑页面 +slug: MDN/Contribute/Howto/Create_and_edit_pages +tags: + - 指南 + - 新手 + - 简介 +translation_of: MDN/Contribute/Howto/Create_and_edit_pages +--- +

测试页面

+ +

需要帮助？ • 编者指南 • 风格指南

+ +

如何编辑一个页面: 

+ +
    +
  1. 登陆 MDN Web Docs 账号，若未注册请注册。
    2. +
  2. 如果你在只读版本的 MDN Web Docs（https://developer.mozilla.org），点击点击页面右上角的 Edit in wiki（在 wiki 编辑）按钮。这将带你进入可编辑的，wiki 版本的网页（https://wiki.developer.mozilla.org），但是这并没有真正地打开可编辑的界面。
    3. +
  3. 请点击 wiki 页面文章标题旁的 编辑 按钮。
    4. +
  4. 页面会重新加载具有规定格式的编辑页面，你可以直接在页面上新增或者删除内容。
    5. +
  5. 你可以新增段落，删除文本，插入标题，并且执行更多涉及编写和编辑的功能。
    6. +
+ +

通过查看MDN Editor guide里的Editor UI elements获得更多关于MDN内置编辑器的信息。

+ +

预览修改

+ +

查看你修改的内容：

+ + + +

注意！预览页面并不会保存你的修改内容，所以你在关闭编辑的页面前必须保存你的修改。

+ +

版本注释

+ +

当预览修改之后，你需要保存你的修改版本。在保存之前，查看页面文章下方的版本注释栏，留下一些注释信息来告诉其它贡献者你为什么要去修改它。例如，你可能新增加了一个章节，或修改了一些文字来使得术语表述的更加一致，亦或重构了一个段落使其语言更加易于理解，或者就是删除了一些冗余信息。

+ +

目录

+ +

一篇文章的“在本文中”部分是自动生成的页面上标题的链接列表。这些链接的措词可以通过编辑标题进行编辑。也可以通过选择“编辑页面标题和属性”和改变“TOC”下拉列表的值，从而删除目录，或减少链接数量。

+ +

标签

+ +

你可以新增或删除编辑区域下面的一些描述页面内容或者功能的标签。查看 如何正确标记页面 来了解如何为页面添加合适的标签。

+ +

需要复核？

+ +

保存之前，为了确保信息的准确性，你可以勾选技术复核（针对代码，API，或技术），编辑复核（针对文章，语法，和内容），或模板复核（针对KumaScript code）的选择框，来让专家或有经验的贡献者复核你的编辑信息。

+ +

附件

+ +

如果你想附加某个文件到一个现有的页面中来添加插图或作进一步说明的话，你可以在页面底部输入。当你上传图片时，请确保使用图片优化工具进行优化，以便我们的图片足够小，方便下载。这样便提高了页面加载速度，提升MDN的整体性能。有可能有你钟爱的工具，如果没有的话，我们推荐一款容易上手的Web工具：TinyPNG。

+ +

保存，放弃更改，继续编辑

+ +

当你完成编辑，并确认过预览界面，你可以点击标题右边或者文章底部的的绿色按钮“发布修改”来发布你的文章和注释。如果你想要继续编辑，可以选择点击按钮“发布并继续编辑”来保证在保存编辑的同时不离开编辑模式。

+ +

如果你改变主意，你也可以点击页面右侧的红色按钮“放弃”来放弃你的编辑，注意放弃更改是不可撤销返回的。

+ +

在版本注释区域点击 Enter 键和点击按钮“发布并继续编辑”具有相同的效果。

+ +
+

注意：当你尝试保存你编辑好的页面时发现你的编辑被视为无效操作而被拒绝了，若你编辑好的内容又确实是适合MDN的，此时你可以向MDN管理团队发送邮件来获得帮助。

+
+ +

获取新建页面的许可

+ +

出于对安全的考虑，最近创建的MDN账号是没有权限新建页面的。如果你尝试这样做，你将看到一个页面引导你如何创建新页面。有以下两种可选的方式：

+ + + +

新建一个页面

+ +

当你拥有创建新页面的权限之后，你就可以开始创建页面了。

+ +

找不到在哪里新建一个页面？别担心！你可以在任何地方新建一个页面，我们会找到它并把它归档或者合并到最合适的类别下。你也不用过多担心它不够完美，我们有热心的志愿者来帮你打理，让你的文章保持干净美观。 

+ +

下面是一些新建页面的方法：

+ + + +

“缺失页面”链接

+ +

和许多维基站点一样，在 MDN 也有可能创建一个链接，它指向一个尚不存在的页面。例如：一个作者可能创建了一个清单页面，该页面涵盖了某个API的所有成员，而这些成员对应的页面还没创建好。在 MDN，指向到缺失页面的链接通常显示为红色。

+ +

从“缺失页面”链接创建对应的页面需要：

+ +
    +
  1. 确认已登录进 MDN，并且拥有新建页面的权限。（若未登录就点击“缺失页面”链接，会得到一个404（找不到页面）的错误。）
    2. +
  2. 点击“缺失页面”链接。如果你拥有页面创建权限，MDN编辑器界面会自动打开，准备好让你创建缺失的页面。
    3. +
  3. 编写页面内容，然后保存。
    4. +
+ +

不需要链接的新页面

+ +

想要创建一个没有链接到其他页面的新页面时，你需要在你的浏览器中键入一个包含新页面名字段的URL。例如，如果你键入以下URL并回车：

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

MDN将创建一个标题为“FooBar”的新页面并且打开编辑器让你能够为新添加的页面添加内容。请参考本文中编辑一个已存在的页面的小节来学习如何使用编辑器模式。

+ +

要创建一个没有链接到其他页面的新页面需要：

+ +
    +
  1. 确保您已经登陆MDN，并且拥有创建新页面的权限。
    2. +
  2. 在您的浏览器中输入以下URL并回车。
    3. +
+ +
https://developer.mozilla.org/en-US/docs/new
+ +

此时，MDN 创建新页面时有一个地方专门用来填写标题，打开编辑器后您就可以添加内容到这个新页面。请参考本文中编辑一个已存在的页面的小节来学习如何使用编辑器模式。

+ +

已存在页面的子页面

+ +

在页面层次结构中的现有页面以下创建页面，需要：

+ +
    +
  1. 在“父”页面，点击高级菜单（工具栏中的齿轮按钮），然后点击“新建子页面”。
    2. +
  2. 打开编辑器视图以创建新文档。
    3. +
  3. 在标题栏键入文档标题。
    4. +
  4. 需要的话，更改 Slug 字段（例如，若标题太长而你又想用较短的URL）。该字段由编辑器自动填充，替换掉标题处的空白下划线并且只更改文档对应的URL的最后一部分。
    5. +
  5. 在 TOC 字段，选择你想自动显示在页面目录中的标题级别，或者如果一个都不需要的话可以选择”无目录“。
    6. +
  6. 在编辑框中编写页面内容，然后保存您的修改。请参考本文中编辑一个已存在页面的小节来学习如何使用编辑器模式。
    7. +
+ +

克隆一个已存在的页面

+ +

如果你想应用一个已经存在的页面的版式，你可以“克隆”这个页面并且修改其内容。

+ +
    +
  1. 在原页面中，点击高级菜单（工具栏中的齿轮按钮），然后点击“克隆此文章”，一个编辑器视图就会被打开来创建新文档。
    2. +
  2. 更换一个合适的标题，当你在更改标题时，Slug 字段会自动更新。
    3. +
  3. +

    如果需要，更改 Slug 字段部分的路径，然后把新的文档放入文件夹的另一处（在大多数情况下这是没有必要的，因为克隆的页面与原始页面拥有相似的内容，因此克隆的页面应该与原始页面安排在相近的位置）。

    +
    4. +
  4. +

    在TOC字段中，选择你想让其显示在目录中的标题等级，或者选择“没有目录（No table of contents）”如果页面不需要的话。

    +
    5. +
  5. +

    在编辑面板输入页面的内容并保存您的修改。请参考本文中编辑一个已存在页面的小节来学习如何使用编辑器模式。

    +
    6. +
+ +

从现有页面链接到新页面

+ +

你可以在一个现有页面创建一个链接，然后点击这个链接来创建一个新页面：

+ +
    +
  1. 在现有页面上任意但合理的位置输入新页面的名字
    2. +
  2. 将名字设置为高亮显示并在编辑工具栏点击链接图标（也可能是简洁的锁链状）。“更新链接”对话框打开，高亮的文字会被显示在“链接文本”框中。 
    3. +
  3. "/en-US/docs/" 会被默认添加到URL的开头。在 "/en-US/docs/" 后输入此页面的名字。当然，链接文字和新页面的标题也可以不一样。
    4. +
  4. 点击“确认”来创建和插入这个链接。
    5. +
+ +

如果这个页面不存在，这个链接将会用红色显示。如果这个页面存在，这个链接将会用蓝色显示。如果你想创建一个新的页面，但是你想创建页面的标题被占用了，请考虑是否更应该去编辑和改进这个已经存在的页面。如果您认为创建一个新页面更有必要，可以选择一个不同的标题并创建它。请参考页面命名指南获得指导。

+ +

为了给您新建的页面添加内容，点击您刚刚创建的红色的链接（在保存并且关闭编辑器之后）。新的页面将进入编辑模式使您能够开始编写内容，请参考本文中编辑一个已存在的页面的小节来学习如何使用编辑器模式。

+ +

刷新页面内容

+ +

由于性能上原因，MDN对KumaScript 宏指令和将一个页面嵌入另一个页面中的支持有时候会稍微被页面缓存所妨碍。页面由它们的数据源编译，并且输出会被缓存起来用来将来的页面请求。从那时起，在该页面的任何宏指令（模板）或者嵌入（使用宏Page ）将不会展现由于宏，宏的输出，或者嵌入的原本内容所引起的变化。

+ + + +

更多参考

+ + diff --git a/files/zh-cn/mdn/contribute/howto/do_a_technical_review/index.html b/files/zh-cn/mdn/contribute/howto/do_a_technical_review/index.html new file mode 100644 index 0000000000..83945186c5 --- /dev/null +++ b/files/zh-cn/mdn/contribute/howto/do_a_technical_review/index.html @@ -0,0 +1,57 @@ +--- +title: 如何进行技术审查 +slug: MDN/Contribute/Howto/Do_a_technical_review +tags: + - MDN Meta + - 复核 + - 如何做 + - 指南 + - 文档 +translation_of: MDN/Contribute/Howto/Do_a_technical_review +--- +
{{MDNSidebar}}
+ +

技术复核包括审查一篇文章的技术准确性和完整性，并在必要的时候予以纠正。 如果一篇文章的作者需要其他人来对文章进行技术复核的话，就需要在编辑时勾选”技术复核“选项。通常情况下，作者会联系特定的工程师来执行技术审查，但是任何具有此领域专业技能的人都可以完成技术复核。

+ +

本文介绍如何进行技术复核，从而帮助确保MDN的内容的正确性。

+ +

任务是什么？

+ +

  审查和纠正文章的技术准确性和完整性。

+ +

什么地方需要技术审核？

+ +

  在被标记为需要技术审核的特定文章中。

+ +

开始做任务前你需要了解什么？

+ + + +

完成任务的步骤是什么？

+ +
    +
  1. 选取一篇需要复查的文章： +
      +
    1. 前往 technical reviews 页面。这里列出了所有需要技术复核的文章。
      2. +
    2. 选择一个你非常熟悉的领域的页面。
      3. +
    3. 点击该页面。
      4. +
    +
    2. +
  2. 在阅读这篇文章的时候注意文章里的所有技术细节：这篇文章的内容正确吗？是否缺少了一些细节？如果你觉得这篇文章不适合你，那么请毫不犹豫地换一篇文章。
    3. +
  3. 如果没有错误，你不需要重新编辑来把这篇文章标识为”已复核“，你只需要找到左边导航栏最下方的”快速复核“框。黄色背景的框里列出了所有等待复核的请求，像这样：
    4. +
  4. 去掉需要技术复核前面的勾，然后点保存。
    5. +
  5. 如果你发现了需要被修正的错误，你可以在编辑器里修改这篇文章的审核请求状态。以下是操作步骤： +
      +
    1. 点击页面顶部的编辑按钮，进入 MDN editor 页面，来编辑该页面。
      2. +
    2. 更正不正确的技术信息，还可以添加文章遗漏的任何重要信息。
      3. +
    3. 在文章的底部输入修改注释。这个注释简要地描述你的修改工作，比如“完成技术审查。”如果你更正了某些信息，将它们写进你的注释，比如“技术审查以及修复参数的相关描述。”这将帮助其他贡献者和网站编辑人员知道你修改的部分以及原因。如果你认为文章中有些不必要被审查的部分，也可以在注释中提出来。
      4. +
    4. 取消勾选“需要审查”下面的“技术”选项框了吗？它就在页面的审查注释区域。
      5. +
    5. 点击发布按钮。
      6. +
    +
    6. +
+ +

祝贺你，你已经完成了你的第一篇技术复核，感谢您的帮助！

diff --git a/files/zh-cn/mdn/contribute/howto/do_an_editorial_review/index.html b/files/zh-cn/mdn/contribute/howto/do_an_editorial_review/index.html new file mode 100644 index 0000000000..48396dcd33 --- /dev/null +++ b/files/zh-cn/mdn/contribute/howto/do_an_editorial_review/index.html @@ -0,0 +1,55 @@ +--- +title: 如何进行编辑审核 +slug: MDN/Contribute/Howto/Do_an_editorial_review +tags: + - 指导 + - 文档 + - 编辑审核 +translation_of: MDN/Contribute/Howto/Do_an_editorial_review +--- +
{{MDNSidebar}}
+ +
{{IncludeSubnav("/zh-CN/docs/MDN")}}
+ +

编辑审核的工作由修改文中排版错误，拼写、语法、用法等文本错误构成。并不是所有贡献者都是语言专家，但有了他们的共同努力，他们把那些需要编辑以及校对的文章转化为了极其有用的文章；这些都是在编辑审核的工作中完成的。

+ +

这篇文章描述了如何进行编辑审核，从而帮助实现 MDN 的内容精确。

+ +
+
任务是什么？
+
编辑并审核那些被标记为需要编辑审核的文章。
+
应该在何处处理它？
+
在特定的文章中会有标记有需要编辑审核的地方。
+
开始做任务前你需要了解什么？
+
你需要有好的中文语法和词汇技能。文章复核是要确保语法、用词都是正确的并且有意义，同时遵循 MDN 样式指南。
+
完成任务的步骤是什么？
+
+
    +
  1. 选择一篇文章来审核： +
      +
    1. 访问需要复核的文章列表。它陈列了所有请求编辑审核的页面。
      2. +
    2. 点击文章链接进入页面。
      + 注意：这个列表是自动生成的，但更新并不频繁，所以列表中的一些文章是不再需要编辑审核的。如果你选择的文章没有显示“这篇文章需要复核”，跳过这一篇文章，再选择其他的文章。
      3. +
    +
    2. +
  2. 仔细阅读文章，特别注意其中可能出现的排版、错字、语法或者词语使用错误。如果你觉得这篇文章不适合你，随时可以换一篇其它文章。
    3. +
  3. 如果文章中没有任何错误，你不需要进入编辑页面再把它标记为“已审核”。在页面的左侧边栏处可以找到“快速复核”对话框：
    + 文法复核边栏屏幕截图
    4. +
  4. 取消 文法 的勾选之后点击 保存 。
    5. +
  5. 如果你发现了需要改正的错误： +
      +
    1. 点击右上角蓝色的 编辑 按钮；它将带你进入 MDN 编辑器。
      2. +
    2. 更正所有你看到的的排版、错字、语法或者词语使用错误。你并不需要将所有问题都一次性改好，不过当完成整篇文章的时候你还觉得不确定是否完美，一定要保留文法复核的请求。
      3. +
    3. 在文本底部输入一段修订注释；比如 “文法符合：更改了排版，语法和用词错误。” 这有助于其他编辑者和网站管理员知道你更改了什么以及为什么做出更改。
      4. +
    4. 在 需要复核吗？ 下面取消 文法 的选择。这一项位于页面的 版本备注 当中。
      + 文法复核编辑模式屏幕截图
      5. +
    5. 点击 发布 按钮。
      6. +
    +
    6. +
+ +
+

你所做出的更改在保存后不一定立即可见，页面保存和处理过程可能出现一些延迟。

+
+
+
diff --git a/files/zh-cn/mdn/contribute/howto/index.html b/files/zh-cn/mdn/contribute/howto/index.html new file mode 100644 index 0000000000..c63b358e37 --- /dev/null +++ b/files/zh-cn/mdn/contribute/howto/index.html @@ -0,0 +1,16 @@ +--- +title: MDN 使用指南 +slug: MDN/Contribute/Howto +tags: + - Documentation + - Landing + - MDN + - TopicStub +translation_of: MDN/Contribute/Howto +--- +

<% //插入当前页面的子页面的定义列表，每个 //页面的标题为

+ +
+
术语，其 SEO 摘要为
+
术语。的 //如果可能，列表以两列视图显示。 // //参数： //没有 var html = 等待模板 （[子页与摘要] ); //现在，我们有了HTML中的整个列表。让我们通过它，并尝试用力把它分成两列。 %> <%-等待模板（"MakeColumnsForDL"，[html]）%>
+
diff --git a/files/zh-cn/mdn/contribute/howto/link_a_github_account/index.html b/files/zh-cn/mdn/contribute/howto/link_a_github_account/index.html new file mode 100644 index 0000000000..5be8c9fe23 --- /dev/null +++ b/files/zh-cn/mdn/contribute/howto/link_a_github_account/index.html @@ -0,0 +1,89 @@ +--- +title: 如何在您的MDN账户中关联一个GitHub账户 +slug: MDN/Contribute/Howto/Link_a_GitHub_account +tags: + - MDN + - 文档 +translation_of: Archive/MDN/Howto_Link_a_Github_account +--- +
{{MDNSidebar}}
+ +
{{IncludeSubnav("/zh-CN/docs/MDN")}}
+ +
+

Note: Support for Persona logins on MDN was disabled on November 1, 2016. The method for adding a Github account to your profile therefore no longer works. If you didn't add a GitHub login to your MDN account before we disabled Persona logins, please file an "Account Help" bug on Bugzilla. For further reading about the end of life of Persona, see: Persona shutdown guidelines.

+
+ + +

由于Mozilla的 Persona 身份认证系统将会于2016年11月30日起关闭，所有希望为MDN做贡献的用户都需要用其他手段来登录到 MDN。当前，我们支持的唯一选择就是 GitHub，所以您需要在截止日期过后使用 GitHub 账户登入并编辑 MDN。这篇文章讲述了如何将 GitHub 身份认证添加到您的MDN账户中。

+ +
+

您必须在2016年11月30日前完成此操作，否则您将再也无法登录 MDN！

+
+ +

概述

+ +

将GitHub身份认证添加到您的账户中并不难。下面我们将进一步讨论细节，但首先，先看一下步骤概述：

+ +
    +
  1. 登录您的 MDN 账户
    2. +
  2. 转到 账户关联 页面
    3. +
  3. 添加 GitHub 身份认证。
    4. +
+ +

详细指南

+ +

下面是一个手把手的教程，教您如何完成您需要知道的事情。

+ +

登入您的 MDN 账户

+ +
    +
  1. 在任意MDN页面的顶端，将鼠标悬浮于或点击登录框。它会显示可用的身份认证方式：Persona 或 GitHub 。
    + Sign in box on MDN, showing Persona and Github.
    2. +
  2. 选择 Persona ，然后用您常用的登录凭据登入。
    3. +
+ +

转到账户关联页面

+ +

有两种方法转到账户关联页面。

+ +

一种方法就是点击下面的链接。

+ + +

还有一种方法就是完成下列步骤：

+ +
    +
  1. 在任意 MDN 的页面顶端单击您的用户名（就是您未登录时登入框的位置）。这将带您到您的资料页面。
    2. +
  2. 点击“齿轮”菜单，然后单击 Account connections （账户关联）。
    + Gear menu in profile, showing the "Account connections" option
    3. +
+ +

添加 GitHub 身份认证

+ +

您现在位于"Account connections"（账户关联）页面，它罗列了您已连接到您的 MDN 个人资料的外部账户。如果 GitHub 账户已经列出，那么恭喜你！您已经完成了！但为了测试一下您是否牢记您的密码，可以登出 MDN，再使用您的 GitHub 身份凭证登入。

+ +

如果 Github 没有列出，请看看页面底部的已连接账户列表。您可以看到连接一个新的账号小节，这里列出了您可以与您的 MDN 个人资料建立连接的账户。如下图：

+ +

+ +

要想添加 GitHub：

+ +
    +
  1. 点击 连接 Github。MDN 将会向 Github 请求权限连接这两个账户。如果您还未登录 Github，登录页面将会显示出来：
    + Screenshot of GitHub sign in window.
    2. +
  2. 如果您为您的 Github 账户开通了两步验证，您须要输入您的验证码：
    + Screenshot of GitHub's Two-factor authentication window.
    3. +
  3. 现在您登录您的 Github 账户了。您可以进行授权，以连接 Github 与 MDN 账户（除非您曾经因某些原因授权过）。此页面如下图：
    + Screenshot of GitHub "Authorize application" window.
    + 点击绿色的 Authorize application（授权应用） 按钮授予您的 MDN 账户访问您的 Github 账户的权限。当您的 Github 账户成功与 MDN 账户建立连接时，您将看到这一信息：
    + Account successfully created.
    4. +
+ +

现在您不仅可用 GitHub 登录 MDN，还已经使用 GitHub 身份认证登入了！您已经准备好应对 Persona 关闭了。如有必要，您应该确定已经更新了安装的所有密码管理器。

+ +

相关链接

+ + diff --git a/files/zh-cn/mdn/contribute/howto/set_the_summary_for_a_page/index.html b/files/zh-cn/mdn/contribute/howto/set_the_summary_for_a_page/index.html new file mode 100644 index 0000000000..bf90ff0262 --- /dev/null +++ b/files/zh-cn/mdn/contribute/howto/set_the_summary_for_a_page/index.html @@ -0,0 +1,59 @@ +--- +title: 如何为页面编写概要 +slug: MDN/Contribute/Howto/Set_the_summary_for_a_page +tags: + - 指南 +translation_of: MDN/Contribute/Howto/Set_the_summary_for_a_page +--- +
{{MDNSidebar}}
+ +

您可以在MDN的每一个页面上定义概要，它可以在很多方面起到作用，如包含在搜索引擎的搜索结果中，或者在其他MDN页面如热门话题页或者工具提示页。它应该概括的描述该页面的所有内容，并且当在其他页面显示时，不包含页面内容的无关部分。

+ +
+

一个概要可以被明确的定在在一个页面中。如果概要没有被明确的定义，通常会使用该页面内容的第一句话作为概要，而它往往不是该页面最精确的描述。

+
+ + + + + + + + + + + + + + + + + + + + +
任务是什么？标记应被用作其在其他情况下摘要页面中的文本;这项任务可能包括在需要写相应的文本。
哪些地方需要它？在缺乏一个总结或总结不太好的页面。
完成任务需要什么？能够使用MDN编辑器的能力;良好的英语写作能力;对网页的主题足够熟悉，以便于能写一个很好的总结。
怎样完成任务？ +
    +
  1. 选择一个页面来设置总结: +
      +
    1. 在MDN documentation status 页面上的section中, 点击你所了解的话题。
      2. +
    2. 在主题的文档状态页面，单击汇总表中的页头。这需要你在该主题区段的所有网页的索引;它示出了在左侧列中的页面的链接，以及在右栏中的标签和摘要。
      3. +
    3. 挑选缺少一个总结页面，或者说有一个较差的总结的页面。
      4. +
    +
    2. +
+ +
+

点击链接进入该页面。

+
+ +
    +
  1. 单击编辑在MDN编辑器中打开该页面。
    2. +
  2. 找一两句话，作为一个总结。如果需要，可以编辑现有的内容来创建或修改的句子来做一个很好的总结。
    3. +
  3. 选择要使用的摘要文本。
    4. +
  4. 在样式插件的编辑器工具栏，选择搜索引擎优化摘要。 (In the page source, this creates a {{HTMLElement("span")}} element with class="seoSummary" around the selected text.)
    5. +
  5. 保存你的更改，并附上类似“设置页面总结”的修改意见。修改意见是可选的，但我们鼓励你添加一个。这样便于其他人了解变更的情况。
    6. +
+
+ +

完成这样的一份任务后，你就是MDN的一员。

diff --git a/files/zh-cn/mdn/contribute/howto/tag/index.html b/files/zh-cn/mdn/contribute/howto/tag/index.html new file mode 100644 index 0000000000..67415b88f1 --- /dev/null +++ b/files/zh-cn/mdn/contribute/howto/tag/index.html @@ -0,0 +1,536 @@ +--- +title: 如何合理的标记页面 +slug: MDN/Contribute/Howto/Tag +tags: + - MDN 元 + - 初学者 + - 如何 + - 指南 + - 教程 +translation_of: MDN/Contribute/Howto/Tag +--- +
{{MDNSidebar}}
+ +

文章标签是一个让游客接触到有用内容的重要方式。每一个页面通常都应该有几个标签来保持其内容的组织性。  这一页解释了标记页面的最好方法，以使我们的读者可以找到信息和让我们的页面保持组织有序。

+ +

对于编辑标签的用户界面的帮助, 请看我们的编辑者指南里的标记部分。

+ +

请根据下面所解释的来合理的使用标签。 如果你没有这么做, 我们的自动化工具将不能正确的生成内容列表，着陆页面和文章的交叉链接。

+ +

MDN如何使用标签

+ +

MDN有这么几种方法来使用标签：

+ +
+
文档分类：
+
这个文档是什么类型的？是一篇参考？一篇教程？还是一篇着陆页？我们的游客可以使用这些标签来过滤搜索，所以它们真的很重要！
+
主题识别
+
这篇文章是关于什么的？关于API？DOM？图形？重申一遍，这些标签很重要，因为它们可以用来过滤搜索。
+
技术现状
+
这门技术的现状是什么？它是非标准的？过时的还是已经被弃用了的？还是处于实验性的？
+
技术水平
+
教程和指南，这篇文章中涵盖的内容有多先进？
+
文档元数据
+
写作社区使用标签来跟踪哪些页面需要什么样的工作。
+
+ +

标签类型指南

+ +

这里是关于标签类型的快速指南和它们可能用到的值。

+ +

文档类别

+ +

当你使用这些类别中的一个来标记文章的时候, 你帮助了自动化工具更准确的生成着陆页面，内容表，和更多。我们新的搜索系统也可以使用这些来让我们的游客更好的根据他们的意愿来定位参考和指南。

+ +
+
+

我们使用以下类别名称作为标准标记术语：

+
+
+ +
+
{{Tag("Intro")}}
+
+
+
+

这篇文章提供了一个有关主题的介绍材料。最理想的是每一个技术领域应该只能有一个“Intro”标签。

+
+
+
+
{{Tag("Featured")}}
+
+
+
+

这篇文章是至关重要的，将在登陆页面上显示在突出的位置上。有节制地使用这个标签（每个文件区不要超过三个）。

+
+
+
+
{{Tag("Reference")}}
+
这篇文章包含API、元素、属性、等的参考资料。
+
{{Tag("Landing")}}
+
这是一个着陆页面。
+
{{Tag("Guide")}}
+
这篇文章是一个告诉如何做或者指南的页面。
+
{{Tag("Example")}}
+
这是代码示例页面，或者有代码示例（那是有用的代码实例，而不是一行“语法例子”）。
+
+ +

主题

+ +
+
+

通过确定文章的主题区域，您可以帮助产生更好的搜索结果（以及着陆页和导航）。

+
+
+ +
+
+

虽然在这里有一些灵活的空间可以识别新的主题领域，但我们试着将自己限制在API和技术的名字上，一些有用的例子：

+
+
+ + + +
+
+

一般而言，您的主题标识标签应该是一个接口的名称，和相关的页面（如Node，它的各种属性和方法有很多页），或一个整体的技术类型的名称。你可以对图形、WebGL和WebGL设置页面标签，而不仅是一个关于{{HTMLElement("canvas")}} 与HTML、元素，Canvas，和图形。

+ +

Mozilla 特定内容

+ +

这些标签只用于Mozilla特定内容:

+ +
    +
  • {{Tag("Mozilla")}}
    • +
  • {{Tag("Firefox")}}
    • +
  • {{Tag("Firefox OS")}}
    • +
  • {{Tag("Gecko")}}
    • +
  • {{Tag("XUL")}}
    • +
  • {{Tag("XPCOM")}}
    • +
+ + + +

API 标识

+ +

在API引用中, 每篇文章都应该标明它覆盖了哪部分API:

+ +
+
{{tag("Interface")}}
+
一个接口的主要文章应该有这样的标签. 例如, {{DOMxRef("RTCPeerConnection")}}.
+
{{tag("Constructor")}}
+
每个接口最多可以有一个页面标记为“构造函数”（接口的构造函数）。页面应该有和接口一样的名字，如{{DOMxRef("RTCPeerConnection.RTCPeerConnection()","RTCPeerConnection()")}}.
+
{{tag("Property")}}
+
每一篇描述接口内特定属性的文章都需要这样的标记。以{{DOMxRef("RTCPeerConnection.connectionState")}}, 为例。
+
{{tag("Method")}}
+
每一篇记录接口方法的文章都需要这样的标记。以 {{DOMxRef("RTCPeerConnection.createOffer()")}}为例。
+
+ +

此外，引用页面需要在其标记中包含接口、属性和方法名称。一些例子如下：

+ +
+
接口 {{DOMxRef("RTCPeerConnection")}}
+
包含标签 "RTCPeerConnection" 以及其他相关标记 （"Interface"，"WebRTC"，"WebRTC API"，"API"，"Reference"等）。
+
方法{{DOMxRef("RTCPeerConnection.createOffer()")}}
+
包括标记 "RTCPeerConnection"和 "createOffer" (注意标记名中没有括号！) 以及其他相关标记，包括 "WebRTC"，"WebRTC API"，"API"，"Reference"等。考虑包含像 "Offer"和 "SDP"这些内容，它们在这里也是相关的。
+
属性{{DOMxRef("RTCPeerConnection.iceConnectionState")}}
+
包括标记"RTCPeerConnection"和"iceConnectionState"以及其他相关标记，包括 "WebRTC"，"WebRTC API"，"API"和"Reference"。也需要考虑包括 "ICE"。
+
+ + + +
    +
+
+
+ +

技术状况

+ +

为了帮助读者了解可行的技术是怎样的，我们使用标签来标记页面的技术规范的状态。这并不像实际解释规格是什么，以及技术在规范过程中出现了多少（这正是规格表的用途），但它有助于读者判断，乍一看之下，使用在文章中描述的技术是否是一个好主意。

+ +

这些标记是一些可能的值：

+ +
+
{{Tag("Non-standard")}}
+
+
+
+

表示页面中描述的技术或应用接口不是标准的一部分，但是在任何实现浏览器中都是稳定的。如果你不使用这个标签，你的读者会认为这是标准的技术。页面上的兼容性表应该说明该技术或API的支持。

+
+
+
+
{{Tag("Deprecated")}}
+
+
+
+

网页上的技术或API被标记为过时的规范，并有可能最终被删除，但一般仍可用在当前版本的浏览器。

+
+
+
+
{{Tag("Obsolete")}}
+
+
+
+

该技术或API已被认为已经过时，并已经在所有或大多数当前浏览器中被删除（或正在积极被删除）。

+
+
+
+
{{Tag("Experimental")}}
+
+
+
+

技术不是规范，而是一个实验性的技术或API，可能会或可能不会成为标准的一部分。它可能在浏览器的实现上被改变。

+
+
+
+
{{Tag("Needs Privileges")}}
+
+
+
+

该接口要求访问该设备在该设备上运行的权限。

+
+
+
+
{{Tag("Certified Only")}}
+
该API仅适用于认证码。
+
+ +

这些标签没有理由离开你文章中的 兼容性表 ！

+ +

技术水平

+ +
+
+

指南或教程的技术水平标签类型（那是，被标记的指南）帮助用户来基于他们的熟悉程度来选择教程，这里有三个值：

+
+
+ +
+
{{Tag("Beginner")}}
+
介绍读者到一个从未使用过的技术或仅仅是一种熟悉的技术。
+
{{Tag("Intermediate")}}
+
+
+
+

已经开始使用该技术的用户的文章，但不是专家。

+
+
+
+
{{Tag("Advanced")}}
+
关于拓展技术和读者能力的文章。
+
+ +

文档元数据

+ +
+
+

写作社区要求根据特定类型的工作来使用标签标记文章。以下是我们最常用的一个列表：

+
+
+ +
+
{{Tag("Draft")}}
+
文章不完整，至少在理论上仍在积极更新（尽管它也有可能被遗忘）。在进行更改之前，请尝试与最新的贡献者进行检查，以避免潜在的内容冲突。
+
{{Tag("NeedsCompatTable")}}
+
文章需要一个表来指定跨浏览器特性的兼容性，有关促进浏览器兼容性的指南参见此处。
+
+ +
+
{{Tag("NeedsContent")}}
+
+
+
+

文章是一个存根，或者是缺乏其他信息。这个标签意味着有人应该审查的内容，并添加更多的细节和/或完成写作的文章。

+
+
+
+
{{Tag("NeedsExample")}}
+
+
+
+

文章需要一个或多个例子来帮助说明文章的要点。这些例子应该使用实时示例系统.

+
+
+
+
{{Tag("NeedsLiveSamples")}}
+
+
+
+

本文有一个或多个实例，需要使用 在线样本系统更新。

+
+
+
+
{{Tag("NeedsUpdate")}}
+
内容过时，需要更新。
+
{{Tag("l10n:exclude")}}
+
+
+
+

内容是不真正值得本地化，不会出现在本地化状态页。

+
+
+
+
{{Tag("l10n:priority")}}
+
+
+
+

内容重要，应该被MDN标记为优先翻译。在本地化状态页上显示了一个额外的优先级表。

+
+
+
+
+ +

Web Literacy Map

+ +

The WebMaker project, through the Web Literacy Map, has defined skills needed to optimally read, write, and participate on the Web. We use Web literacy skills as tags on MDN to help our users find the resources that best suit their needs:

+ +
+
{{Tag("Navigation")}}
+
文章包含关于在web上如何搜索的信息。
+
{{Tag("WebMechanics")}}
+
内容有关于web如何组织和如何工作的信息。
+
{{Tag("Search")}}
+
文章解释了如何在web上寻找信息、人和资源。
+
{{Tag("Credibility")}}
+
文章中的信息帮助读者理解怎样批判性的评估他们在web上找到的信息。
+
{{Tag("Security")}}
+
文章提供有关如何保持系统、身份和内容安全的信息。
+
{{Tag("Composing")}}
+
文档解释如何创建和curate web上的内容。
+
{{Tag("Remixing")}}
+
文章讲授如何修改existing的网络资源来创建新的东西。
+
{{Tag("Design")}}
+
文档解释如何提高视觉和其他用户体验。
+
{{Tag("Accessibility")}}
+
文档描述如何用universally-recognizable的方式交流。
+
{{Tag("CodingScripting")}}
+
如何在网络上写代码和（或）创造交互式的用户体验。
+
{{Tag("Infrastructure")}}
+
文档解释Internet's technical stack是如何工作的。
+
{{Tag("Sharing")}}
+
文章内容包含与他人一起创造资源的方式。
+
{{Tag("Collaborating")}}
+
文档提供关于如何与他人一同工作的信息。
+
{{Tag("Community")}}
+
文章详细说明如何参与网络社区并理解他们如何工作。
+
{{Tag("Privacy")}}
+
材料帮助检查在网络上分享数据的后果。
+
{{Tag("OpenPractices")}}
+
文章provid=deshow帮助保持人人可以连接网络。
+
+ +

把它们放到一起

+ +

就可以从几种标签种类中搜索你标记的网页，例如

+ +
+
A tutorial about WebGL for beginners
+
WebGL, Graphics, Guide, Beginner
+
Reference page for {{HTMLElement("canvas")}}
+
Canvas, HTML, Element, Graphics, Reference
+
A landing page for Firefox OS developer tools
+
Tools, Firefox OS, Landing
+
+ +

标签和搜索过滤

+ +

只有我们正确地标记网页，搜索过滤才能正确工作。这是一个搜索过滤和它们寻找的标签的表格。

+ +
+

注意：Note: 如果多个标签被列在“tag name”下，那说明，为了搜索，任何一个或更多的标签必须在文章中。

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Filter groupSearch filter nameTag name
TopicOpen Web Apps{{Tag("Apps")}}
HTML{{Tag("HTML")}}
CSS{{Tag("CSS")}}
JavaScript{{Tag("JavaScript")}}
APIs and DOM{{Tag("API")}}
Canvas{{Tag("Canvas")}}
SVG{{Tag("SVG")}}
MathML{{Tag("MathML")}}
WebGL{{Tag("WebGL")}}
XUL{{Tag("XUL")}}
Marketplace{{Tag("Marketplace")}}
Firefox{{Tag("Firefox")}}
Firefox for Android{{Tag("Firefox Mobile")}}
Firefox for Desktop{{Tag("Firefox Desktop")}}
Firefox OS{{Tag("Firefox OS")}}
Mobile{{Tag("Mobile")}}
Web Development{{Tag("Web Development")}}
Add-ons & Extensions{{Tag("Add-ons ")}}|| {{Tag("Extensions")}} || {{Tag("Plugins")}} || {{Tag("Themes")}}
Games{{Tag("Games")}}
Skill levelI'm an Expert{{Tag("Advanced")}}
Intermediate{{Tag("Intermediate")}}
I'm Learning{{Tag("Beginner")}}
Document typeDocsThis restricts the search to docs content, leaving out Hacks and other MDN content.
DemosThis includes Demo Studio content in the search results.
Tools{{Tag("Tools")}}
Code Samples{{Tag("Example")}}
How-To & Tutorial{{Tag("Guide")}}
Developer ProfilesThis includes developer profiles from the MDN site in the search results.
External ResourcesThe dev team is still figuring this out...
+ +

你可以修改的标签的错误

+ +

这些种类的标签错误你可以帮助修改：

+ +
+
没有标签
+
一般来说文章应该至少有一个 "category" 标签和一个 "topic"标签. 虽然有其他标签也好, 但是如果你能帮我们提供最基本的标签（前文所说的category和topic标签）, 你将会是一名（维护）文档的英雄!
+
不符合我们标签标准的标签
+
请修正一切含有不合标准标签的文档.请注意由于Kuma的一个bug, 一些本地化的标签(比如 Référence) 可能会出现在一些英语页面上. 这些标签还有可能反复出现,即使你已经吧它们删除; 请耐心处理这些问题直到kuma的那个bug被修复.
+
不正确的标签
+
如果你正在看一篇关于HTML的文章并且发现它被标上了"JavaScript"的标签, 那很有可能这是一个错误标签! 同理, 如果一篇文章在讨论Mozilla internals 但是有一个"Web"标签, 那也有可能是错误的. 删除这些错误的标签并且如果还没有合适标签的话，加上正确的标签. 同样请更正拼写错误的标签(e.g., 因为标签是大小写敏感的, 所以"Javascript" 仍然匹配, 但是我们还是不要马虎对待!).
+
缺失的标签
+
如果一篇文章有标签但是不全面, 请补全. 比如, 一页JavaScript 的参考文档被(正确) 标签为 "JavaScript" 但是除此之外什么也没有了, 请你就为它标上"参考"的标签!
+
垃圾标签
+
这只潜伏的怪兽是所有标签问题中最让人讨厌的: some Web vermin has deposited its droppings in the page tags (like "Free warez!" or "Hey I was browsing your site and wanted to ask you if you could help me solve this problem I'm having with Flash crashing all the time"). We've got to delete these right away! They're ugly, they're hard to manage if they're allowed to linger too long, and they're terrible for {{Glossary("SEO")}}.
+
+ +

如果你发现了以上问题, 请登录MDN点击MDN窗口右上方的 EDIT按钮. 等编辑器载入完成后, 到页面底部, 你就会看到标签. 想了解标签操作界面的更多信息, 请参看 "The tags box" in the MDN editor guide.

diff --git a/files/zh-cn/mdn/contribute/howto/tag_javascript_pages/index.html b/files/zh-cn/mdn/contribute/howto/tag_javascript_pages/index.html new file mode 100644 index 0000000000..4420d3f04e --- /dev/null +++ b/files/zh-cn/mdn/contribute/howto/tag_javascript_pages/index.html @@ -0,0 +1,69 @@ +--- +title: 如何给JavaScript相关页面添加标签 +slug: MDN/Contribute/Howto/Tag_JavaScript_pages +translation_of: MDN/Contribute/Howto/Tag_JavaScript_pages +--- +
{{MDNSidebar}}

标记工作包括给页面添加元信息，使得这些页面的相关内容能被搜索工具等正确的分拣。

+ +
+
哪里需要做这件事?
+
那些特定的没有标签的JavaScript相关的页面
+
开始标记任务前你需要知道些什么？
+
一些基本的JavaScript编程知识，比如javascript中的方法和属性都是些什么。
+
你的工作有以下几个步骤
+
+
    +
  1. 选择下面列举的某篇文章。
    2. +
  2. 点击该文章所对应的链接，载入页面。
    3. +
  3. 当页面载入完毕时，点击顶部附近的EDIT按钮，就会进入MDN编辑模式。
    4. +
  4. 最后就是添加Javascript相关的标签了，我们提供了如下可选的标签。 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    标签名适用于含有哪些内容的页面
    Method方法
    Property属性
    Prototype原型
    Object type name所述对象的名字，例如String.fromCharCode就应该有String标签
    ECMAScript6 and Experimental在新版ECMAScript标准中增加的特性
    Deprecated不赞成使用的特性（那些不鼓励使用但仍然被浏览器支持的特性）
    Obsolete被废弃的特性（那些不再被浏览器支持的特性）
    others查看 MDN 标签规则 中其他可选标签
    +
    5. +
  5. 添加备注信息并保存你的修改。
    6. +
  6. 你做到了！
    7. +
+
+
+ +

 

diff --git a/files/zh-cn/mdn/contribute/howto/write_a_new_entry_in_the_glossary/index.html b/files/zh-cn/mdn/contribute/howto/write_a_new_entry_in_the_glossary/index.html new file mode 100644 index 0000000000..29ad28e098 --- /dev/null +++ b/files/zh-cn/mdn/contribute/howto/write_a_new_entry_in_the_glossary/index.html @@ -0,0 +1,107 @@ +--- +title: 如何撰写和引用一个词汇表中的条目 +slug: MDN/Contribute/Howto/Write_a_new_entry_in_the_Glossary +translation_of: MDN/Contribute/Howto/Write_a_new_entry_in_the_Glossary +--- +
{{MDNSidebar}}
+ +

MDN 术语表 是一个定义所有被用于文档和编码的术语、行话和缩写的地方。对词汇表做出贡献是使Web更易于理解的简单方法。您不需要高水平的技术技能来编写词汇表条目，因为它们应该保持简单直接。

+ +

如何写一个条目

+ +

如果您正在寻找需要词汇表条目的主题，请查看词汇表首页末尾的未撰写文档的条目清单。请单击您希望创建的词汇条目的链接，进入”新的词汇表页面“准备新条目的创建。然后按照后面的步骤操作。

+ +

如果您有添加新的词汇表条目的想法，只需在新选项卡中打开以下按钮，然后按照按钮下方的步骤操作：

+ +

向术语表中添加一个新条目

+ +

第一步: 写概要

+ +

任何词汇表页面的第一段是对该术语的简单和简短描述（最好不超过两个句子）。 确保阅读说明的人能够立即了解定义的术语。

+ +
+

注意: 请不要直接从其他地方复制和粘贴定义（尤其是维基百科，因为许可证版本范围较小，因此与MDN不兼容）。确保条目内容简单易懂是很重要的。值得花一些时间来撰写定义，而不是简单盲目地窃取其他地方的内容。 这个词汇表应该是有用的新内容，而不是和别处重复的。

+
+ +

使用“链接到词汇表条目”工具可以方便读者直接看到词汇条目中的定义，不需要读者跳转到词汇条目的页面。（更多内容请浏览如何使用 \{{Glossary}} 宏插入词汇表条目的链接。）

+ +

如果需要的话，你可以添加少量额外的段落，但是这很容易导致你写了一整篇文章的情况发生。写一个完整的文章很棒，但是请不要把它们整个放在词汇表中。如果你不确定这里是否适合放你的文章，你就要随时在这里讨论。

+ +

第二步: 扩展链接

+ +

最后，一个词汇表的条目应该总是有“了解更多”这个部分。这个部分应该包含帮助读者看得更深入的链接：探索发现更多细节、学习使用相关技术等。

+ +

我们建议您将链接分为以下三组：

+ +
+
基础知识
+
提供更多一般信息的链接。如：到维基百科的链接是一个很棒的点。 
+
技术参考
+
链接到更深入的技术信息，在MDN或其他地方。
+
学习它
+
链接到教程、练习或任何其他材料，帮助读者学习使用定义术语背后的技术。
+
+ +

小建议

+ +

所以你想贡献，但你不知道需要定义哪些术语？ 这里是是建议列表。点击一下，开始吧！

+ +

消除歧义

+ +

有时，根据上下文，术语有几个含义。 要解决歧义，您必须遵循以下准则：

+ + + +

我们以一个例子来说明。signature 条目在至少三种不同的语境中具有不同的含义： 安全、函数 和 电子邮件。

+ +
    +
  1. Glossary/Signature 页面是使用了 {{TemplateLink("GlossaryDisambiguation")}} 宏的消歧页面；
    2. +
  2. Glossary/Signature/Security 页面是定义安全上下文中签名的条目页面；
    3. +
  3. Glossary/Signature/Function 页面是定义函数签名的条目页面；
    4. +
  4. Glossary/Signature/Email 页面是定义电子邮件签名的条目页面。
    5. +
+ +

如何使用 \{{Glossary}} 宏

+ +

当人们可以在另一个文档访问到词汇的定义，而无需他们从正在阅读的内容进行跳转阅读词汇定义时，词汇表是最好用的。因此，我们敦促您随时使用 {{TemplateLink("Glossary")}} 宏将词汇链接到词汇表：

+ + + + + + + + + + + + + + + + + + + + + + + + + + +
宏结果备注
\{{Glossary("browser")}}{{Glossary("browser")}}当文本与要定义的术语匹配时，只需直接使用宏（不区分大小写）
\{{Glossary("browser", "Web浏览器")}}{{Glossary("browser","Web浏览器")}}要显示替代文本，请使用第二个参数来指定该文本
\{{Glossary("browser", "Web浏览器", 1)}}{{Glossary("browser","Web浏览器",1)}}指定 1 作为可选的第三个参数，将链接显示为常规链接，而不是单纯的提示文本的样式
+ +

使用 \{{Glossary}} 宏创建的链接将总是展示一个包含了词汇表条目的概要段落的提示文本（tooltip）。

+ +

使用方针

+ +

在许多情况下，在MDN上的任何地方使用该宏是非常安全的。 但是，您应该谨慎处理的几种情况：

+ + diff --git a/files/zh-cn/mdn/contribute/howto/write_an_api_reference/index.html b/files/zh-cn/mdn/contribute/howto/write_an_api_reference/index.html new file mode 100644 index 0000000000..4ef7b2bcec --- /dev/null +++ b/files/zh-cn/mdn/contribute/howto/write_an_api_reference/index.html @@ -0,0 +1,446 @@ +--- +title: How to write an API reference +slug: MDN/Contribute/Howto/Write_an_API_reference +tags: + - API + - Documentation + - Guide + - Howto + - MDN Meta + - NeedsTranslation + - TopicStub +translation_of: MDN/Contribute/Howto/Write_an_API_reference +--- +
{{MDNSidebar}}
+ +
+

This guide takes you through all you need to know to write an API reference on MDN.

+
+ +

Getting prepared

+ +

Before starting to document an API, there are some things you should prepare and plan in advance of starting to actually write.

+ +

Prerequisite knowledge

+ +

It is assumed that before reading this guide you have a reasonable knowledge of:

+ + + +

Everything else can be learned along the way.

+ +

Prerequisite resources

+ +

Before starting to document an API, you should have available:

+ +
    +
  1. The latest spec: Whether it is a W3C Recommendation or an early  editor's draft, you should refer to the latest available draft of the  spec that covers (or specs that cover) that API. To find it, you can usually do a Web search. The latest  version will often be linked to from all versions of the spec, listed under "latest draft" or similar.
    2. +
  2. The latest modern web browsers: These should be experimental/alpha builds such as Firefox Nightly/Chrome Canary that are more likely to support the features you are documenting. This is especially pertinent if you are documenting a nascent/experimental API.
    3. +
  3. Demos/blog posts/other info: Find as much info as you can.
    4. +
  4. Useful engineering contacts: It is really useful to find yourself a friendly engineering contact to ask questions about the spec, someone who is involved in the standardization of the API, or its implementation in a browser. Good places to find them are: +
      +
    • Your internal company address book, if you work for a relevant company.
      • +
    • A public mailing list that is involved in the discussion of that API,  such as Mozilla's dev-platform or dev-webapi lists, or a W3C list like public-webapps.
      • +
    • The spec itself. For example, the Web Audio API spec lists the authors and their contact details at the top.
      • +
    +
    5. +
+ +

Take some time to play with the API

+ +

You will return to building demos many times through the course of documenting an API, but it is useful to start by spending time familiarizing yourself with how the API works — learn what the main interfaces/properties/methods are, what the primary use cases are, and how to write simple functionality with it.

+ +

When an API has changed, you need to be careful that existing demos you refer to or learn from are not out of date. Check the main constructs that are used in the demo to see if they match up to the latest spec. They may also not work in up-to-date browsers, but this is not a very reliable test, as often the old features continue to be supported for backwards compatibility.

+ +
+

Note: If the spec has been recently updated so that, say, a method is now defined differently, but the old method still works in browsers, you will often have to document both in the same place, so that the old and new methods are covered. If you need help, refer to demos you have found, or ask an engineering contact.

+
+ +

Create the list of documents you need to write or update

+ +

Reference documents for an API are quite numerous. There is an overview page for the API, a page for each interface, one for each method (including constructors) and property (including event handlers properties). There is also one page per event.

+ +

Overview page

+ +

The API overview page described the role of the API and the top-level interfaces. Its name is NAME OF API and its slug (that is the end part of the URL) must contains at least one space. It is placed at the top level of the API reference (https://developer.mozilla.org/en-US/docs/Web/API)

+ + + +

Note that most API have a special sidebar with quicklinks. This sidebar lists all interfaces, and possibly tutorials and related API.

+ +

Interfaces

+ +

Each interface will have its own page too. It will describe the purpose of the interface and lists all constructors, methods, and properties. The title of the page will be the name of the interface (always starting with an uppercase letter), its slug, the interface name, will be at the top level of the API reference (https://developer.mozilla.org/en-US/docs/Web/API)

+ + + + + +
+

Note: We document every property and interface appearing in the prototype of an object implementing this interface. This has the following consequences:

+ + +
+ +

Properties

+ +

The set of properties of a given interface can be found on its WebIDL. We document each one in a single page. It will describe the purpose of the property, its syntax, and provide examples of use, in isolation. Its slug is the property name, as a subpage of the interface:

+ + + +
+

Note: Event handlers properties (onXYZ properties) are also listed: they'll have their individual subpage, like any other property.

+
+ +

Methods

+ +

Like for properties, methods are listed on the interface's WebIDL and we document each method in a single page. It will describe the purpose of the method, its syntax, and provide examples of use, in isolation. Its slug, without the parenthesis, is the method name, as a subpage of the interface:

+ + + +

Constructors

+ +

Similar in structure to methods, they also have their own pages. Note that only one unnamed constructor may exist per interface. The title convention is slightly different than the one of methods: it isn't prefixed.

+ + + +

Events

+ +

Events are the last type of objects needing documentation. Unless the previous documents, event subpages lies under the Web/Events hierarchy. Each event has its own subpage:

+ + + +

Listing them all

+ +

Creating a list of all these subpages is a good way to track them. For example:

+ + + +

Each interface in the list has a separate page created for it as a subpage of https://developer.mozilla.org/en-US/docs/Web/API; for example, the document for {{domxref("AudioContext")}} would be located at https://developer.mozilla.org/en-US/docs/Web/API/AudioContext. Each {{anch("Interface pages", "interface page")}} explains what that interface does and provides a list of the methods and properties that comprise the interface. Then each method and property is documented on its own page, which is created as a subpage of the interface it's a member of. For instance, {{domxref("AudioContext.currentTime")}} is documented at https://developer.mozilla.org/en-US/docs/Web/API/AudioContext/currentTime.

+ +

For example, given the list above, the {{domxref("AudioContext")}} interface is documented at https://developer.mozilla.org/en-US/docs/Web/API/AudioContext

+ +

Create the overview page

+ +

Now create the overview (API landing) page:

+ +
    +
  1. Go to https://developer.mozilla.org/en-US/docs/Web/API and, making sure you are logged in, select the Cog icon > New sub-page. You should now be in an editor for a new page.
    2. +
  2. Enter the title as the API name as defined by the spec, plus "API". So for example "Web Audio API", "IndexedDB API", or "MediaRecorder API".
    3. +
  3. The Slug should be auto-filled, with underscores in the place of spaces. If it isn't, correct it.
    4. +
  4. Enter some dummy content into the large content area, such as "TBD" or "Content", then click Save Changes. Or just soar right on into the section {{anch("Overview page")}} and start filling out the real content right away.
    5. +
+ +

Your landing page now exists! Now all you have to do is fill it in, which is discussed in the next section.

+ +

Structure of an overview page

+ +
+

Important: This section is still a proposal, without consensus yet reached. Don't use it yet.

+
+ +

API landing pages will differ greatly in length, depending on how big the API is, but they will all have basically the same features. See https://developer.mozilla.org/en-US/docs/Web/API/Web_Audio_API for an example of a big landing page.

+ +

The features of a landing page are outlined below:

+ +
    +
  1. Description: the first paragraph of the landing page should provide a short, concise description of the API's overarching purpose.
    2. +
  2. Concepts and usage section: The next section should be titled "[name  of  API] concepts and usage", and provide an overview of all the main functionality that the API provides, what problems it solves, and how it  works — all at a high level. This section should be fairly short,  and not go into code or specific implementation details.
    3. +
  3. List of interfaces: This section should be titled "[name of API]  interfaces", and provide links to the reference page for each interface that makes up the API, along with a short description of what each one does. See the "Referencing other API features with the \{{domxref}} macro" section for a quicker way to create new pages. Only current interfaces should be in this list; obsolete ones should be placed in (or moved into, if obsoleted after initially being documented) the following section.
    4. +
  4. Obsolete interfaces: This section lists obsolete interfaces. Ed. note: should this be a subsection of the main "Interfaces" section above?
    5. +
  5. List of mixins: If any mixins are defined on the API spec, list them under a separate section, as they aren't interfaces as such.
    6. +
  6. Example: This section should show a simple use case for the API.
    7. +
  7. Specifications table: At this point you need to include a  specifications table — see the "Creating a spec reference table"  section for more details.
    8. +
  8. Browser compatibility: Now you need to include a browser compatibility table. See Compatibility tables for details.
    9. +
  9. See also: The "See also" section is a good place to include further links that may be useful when learning about this technology, including MDN (and external) tutorials, examples, libraries, etc.
    10. +
  10. Tags: There is a set of standard tags you should include for each reference page — see the "Tags" section for more.
    11. +
+ +

Structure of an interface page

+ +

Now you should be ready to start writing your interface pages. Each interface reference page should observe the following structure:

+ +
    +
  1. \{{APIRef}}: Include the \{{APIRef}} macro in the first line of each interface page, including the name of the API as an argument, so for example \{{APIRef("Web Audio API")}}. This macro serves to construct a reference menu on the left hand side of the interface page, including properties and methods, and other quicklinks as defined in the GroupData macro (ask someone to add your API to an existing GroupData entry, or to create a new one, if it isn't already listed there). The menu will look something like the below screenshot.
    + This screenshot shows a vertical navigation menu for the OscillatorNode interface, with multiple sublists for methods and properties, as generated by the APIRef macro
    2. +
  2. Standardization status: The banner indicating the standardization status should be added next (these can be placed on the same line as the \{{APIRef}} macro.): +
      +
    • \{{SeeCompatTable}} for an experimental feature (i.e. the spec is not at the CR level.)
      • +
    • \{{Deprecated_header}}
      • +
    • \{{Obsolete_header}}
      • +
    • \{{Non-standard_header}}
      • +
    +
    3. +
  3. Description: the first paragraph of the interface page should provide  a  short concise description of the interface's overarching purpose.  You may also want to include a couple more paragraphs if any additional description is required. Note that if the interface defines a mixin, you shouldn't use the term "Interface" to describe it, but mixin instead — it isn't really a standalone interface as such, but a mixin that adds functionality to multiple other interfaces. Similarly, if the interface is actually a dictionary, you should use that term instead of "interface".
    4. +
  4. Inheritance diagram: Use the {{TemplateLink("InheritanceDiagram")}} macro to embed an SVG inheritance diagram for the interface. For most interfaces, you won't need any parameters, but if the inheritance chain is long, you may need to use \{{InheritanceDiagram(600, 120)}} to make room vertically for two rows of boxes.
    5. +
  5. +

    List of properties, List of methods: These sections should be titled  "Properties" and "Methods", and provide links (using the \{{domxref}} macro) to a reference  page for each property/method of that interface, along with a description of what  each one does. These should be marked up using description/definition  lists, which can be created using the  "Definition List", "Definition  Term", and "Definition Description" buttons on the MDN editor toolbar. Each description should be short and concise — one sentence if possible. See the "Referencing other API features with the \{{domxref}} macro" section for a quicker way to create links to other pages.
    +
    + At the beginning of both sections, before the beginning of the list of properties/methods, indicate inheritance using the appropriate sentence, in italics:
    + This interface doesn't implement any specific properties, but inherits properties from \{{domxref("XYZ")}}, and \{{domxref("XYZ2")}}.
    + This interface also inherits properties from \{{domxref("XYZ")}}, and \{{domxref("XYZ2")}}.
    + This interface doesn't implement any specific methods, but inherits methods from \{{domxref("XYZ")}}, and \{{domxref("XYZ2")}}.
    + This interface also inherits methods from \{{domxref("XYZ")}}, and \{{domxref("XYZ2")}}.

    + +
    +

    Note: If the interface features event handlers, put these inside the "Properties" section (they are a type of property) under a subheading of "Event handlers".

    +
    + +
    +

    Note:  Properties that are read-only should have the \{{readonlyInline}} macro, which creates a nifty little "Read only" badge, included on the same line as their \{{domxref}} links (after the use of the \{{experimentalInline}}, \{{obsoleteInline}}, \{{non-standard_Inline}} and \{{deprecatedInline}} macros, if some of these are needed.

    +
    +
    6. +
  6. Example: Include a code listing to show typical usage of a major feature of the API. Rather than listing ALL the code, you should list an interesting subset of it. For a complete code listing, you could reference a Github repo containing the full example, and you could  also link to a live example created using the Github gh-pages feature (so long as it uses only client-side code of course.) If the example is visual, you could also use the MDN Live Sample feature to make it live and playable in the page. +
    +

    Note: More details about writing code examples can be found in the "Examples" section.

    +
    +
    7. +
  7. Specifications table: At this point you need to include a specifications table — see the "Creating a spec reference table" section  for more details.
    8. +
  8. Browser compatibility: Now you need to include a browser compatibility table. See Compatibility tables for details.
    9. +
  9. Polyfill: If appropriate, include this section, providing code for a polyfill that enables the API to be used even on browsers that don't implement it. If no polyfill exists or is needed, leave this section out entirely.
    10. +
  10. See also: The "See also" section is a good place to include further links that may be useful when learning about this technology, including MDN (and external) tutorials, examples, libraries, etc. We have a liberal policy for linking to external sources, but pay attention: +
      +
    • Do not include pages with the same information as another page in the MDN; link to that page instead.
      • +
    • Do not put author names — we are a writer-neutral documentation site. Link to the document; the author name will be displayed there.
      • +
    • Pay special attention to blog posts: they tend to become outdated (old syntax, wrong compat information). Link to them only if they have a clear added value that can't be found in a maintained document.
      • +
    • Do not use action verb like "See … for more information" or "Click to…", you don't know if your reader is able to see, or to click on the link (like on a paper version of the document).
      • +
    +
    11. +
  11. Tags: There is a set of standard tags you should include for each reference page — see the "Tags" section for more.
    12. +
+ +

Interface page examples

+ +

The following are exemplary examples of Interface pages:

+ + + +

Structure of a property page

+ +

You can now fill in your interface property pages. Since the structures of all of them are the same, it usually works best to open all the property  pages for each interface in separate tabs. From here you can fill one in fully, then copy its contents to all the other property pages and just update the bits that need changing,  rather than having to fill each one in from scratch.

+ +

Edit the property page name to follow the Interface.property_name convention.

+ +

Property pages must have the following sections:

+ +
    +
  1. Title: the title of the page must be InterfaceName.propertyName. The interface name must start with a capital letter. Although an interface is implemented in JavaScript on the prototype of objects, we don't include .prototype. in the title, like we do in the JavaScript reference.
    2. +
  2. \{{APIRef}}: Include the \{{APIRef}} macro in the first line of each property page, including the name of the API as an argument, so for example \{{APIRef("Web Audio API")}}. This macro serves to construct a reference menu on the left hand side of the interface page, including properties and methods, and other quicklinks as defined in the GroupData macro (ask someone to add your API to an existing GroupData entry, or to create a new one, if it isn't already listed there). The menu will look something like the below screenshot.
    + This screenshot shows a vertical navigation menu for the OscillatorNode interface, with multiple sublists for methods and properties, as generated by the APIRef macro
    3. +
  3. Standardization status: The banner indicating the standardization status should be added next to the interface name (these can be placed on the same line as the \{{APIRef}} macro): +
      +
    • \{{SeeCompatTable}} for an experimental feature (i.e. the spec is not at the CR level.)
      • +
    • \{{Deprecated_header}}
      • +
    • \{{Obsolete_header}}
      • +
    • \{{Non-standard_header}}
      • +
    +
    4. +
  4. Description: the first paragraph of the property page should provide a short, concise description of the property's overarching purpose. You may also want to include a couple more paragraphs if any additional description is required. Obvious extra information to include is its default/initial value, and whether it's read only or not. The structure of the first sentence must be: +
    +
    For read-only properties
    +
    The InterfaceName.property read-only property returns a \{{domxref("type")}} that...
    +
    For other properties
    +
    The InterfaceName.property property is a \{{domxref("type")}} that…
    +
    + +
    Note: InterfaceName.property should be in <code>, and should additionally be in bold (<strong>) the first time it's used.
    +
    5. +
  5. Syntax: The syntax section should show how to get the property, and how to set it, if it's not read only. Use the syntaxbox class for it and italics for part to be replaced by the actual variable name. For example: + 
    var myType = oscillator.type;
+oscillator.type = aType;
+
    + The syntax section should also have a subsection — "Value", which will contain a description of the property's value. This should contain the data type of the property, and what it represents. For an example, see {{domxref("SpeechRecognition.grammars")}}
    6. +
  6. +

    Example: Include a code listing to show typical usage of the property in question. You should start with a simple example that shows how an object of the type is created and how to access the property. More complex examples can be added after such an example. In these additional examples, rather than listing ALL the code, you should list an interesting subset of it. For a complete code listing, you can reference a Github repo containing the full example, and you could also link to a live example created using the github gh-pages feature (so long as it uses only client-side code of course.) You can also make use of the MDN Sample Server, which is particularly helpful for more complex samples. If the example is visual, you could also use the MDN Live Sample feature to make it live and playable in the page.

    + +
    Note: If you make use of Github, the example must live under github.com/mdn. See the "Examples" section for more details.
    +
    7. +
  7. Specifications table: At this point you need to include a specifications table — see the "Creating a spec reference table"  section for more details.
    8. +
  8. Browser compatibility: Now you need to include a browser compatibility table. See Compatibility tables for details.
    9. +
  9. See also: The "See also" section is a good place to include further links that may be useful when using this technology: like methods and properties affected by a change of this property or events thrown in relation to it. More links useful when learning about this technology, including MDN (and external) tutorials, examples, libraries,… can be added, though it may be useful to consider adding them on the interface reference page instead.
    10. +
  10. Tags: There is a set of standard tags you should include for each property page — see the "Tags" section for more.
    11. +
+ +

Property page examples

+ +

The following are exemplary examples of property pages:

+ + + +

Structure of a method page

+ +

You can now fill in your interface method pages. Since the structure of  all of them are the same, one possible way of doing it is to open all the method pages for each interface in separate tabs. From here you can fill one in fully, then copy its contents to all the other method pages and just update the bits that need changing, rather than having to fill each one in from scratch.

+ +

Method pages need the following sections:

+ +
    +
  1. Title: the title of the page must be InterfaceName.method() (with the two terminal parentheses), but the slug (the end of the page URL) must not include the brackets. Also the  interface name must start with a capital. Although an interface is implemented in JavaScript on the prototype of objects, we don't put .prototype. in the title, like we do in the JavaScript reference.
    2. +
  2. \{{APIRef}}: Include the \{{APIRef}} macro in the first line of each method page, including the name of the API as an argument, so for example \{{APIRef("Web Audio API")}}. This macro serves to construct a reference menu on the left hand side of the interface page, including properties and methods, and other quicklinks as defined in the GroupData macro (ask someone to add your API to an existing GroupData entry, or to create a new one, if it isn't already listed there). The menu will look something like the below screenshot.
    + This screenshot shows a vertical navigation menu for the OscillatorNode interface, with multiple sublists for methods and properties, as generated by the APIRef macro
    3. +
  3. Standardization status: Next, the banner indicating the standardization status should be added (these can be placed on the same line as the \{{APIRef}} macro): +
      +
    • \{{SeeCompatTable}} for an experimental feature (i.e. the spec is not at the CR level.)
      • +
    • \{{Deprecated_header}}
      • +
    • \{{Obsolete_header}}
      • +
    • \{{Non-standard_header}}
      • +
    +
    4. +
  4. Description: The first paragraph of the method page should provide a short concise description of the method's overarching purpose. You may also want to include a couple more paragraphs if any additional description is required. Obvious extra information to include is its default parameter values, any theory that the method relies on, and what the parameter values do. +
    +
    The beginning of the first sentence must follow the following structure:
    +
    The InterfaceName.method() method interface ...
    +
    + +
    Note: InterfaceName.method() should be in <code>, and should also be in bold (<strong>) the first time it's used.
    +
    5. +
  5. Syntax: The syntax section should include a 2–3 line example — usually just construction of the  interface, then calling of the interface method. +
    +
    The syntax should be of the form:
    +
    var  <em>returnValue</em> =  <em>ifName</em>.method(<em>param1</em>,  <em>param2</em>, ...)
    +
    If the method has no return value (void as return value in the webidl), use:
    +
    <em>ifName</em>.method(<em>param1</em>,  <em>param2</em>, ...)
    +
    + The syntax section should include three subsections (see {{domxref("SubtleCrypto.sign()")}} for an example): + +
      +
    • "Parameters": This should contain a definition list (or unordered list) that names and describes the different parameters the method takes. You should include the {{optional_inline}} macro next to the parameter name, in the case of optional parameters. If there are no parameters, this section should be omitted.
      • +
    • "Return value": This should say what return value the method has, be it a simple value like a double or boolean, or a more complex value like another interface object, in which case you can use \{{domxref}} macro to link to the MDN API page covering that interface (if it exists.) A method might return nothing, in which case the return value should be written as "\{{jsxref('undefined')}}" (which will look like this in the rendered page: {{jsxref("undefined")}}).
      • +
    • "Exceptions": This should list the different exceptions that can be raised when invoking the method, and what circumstances cause them. If there are no exceptions, this section should be omitted.
      • +
    +
    6. +
  6. Example: Include a code listing to show typical usage of the method in question. Rather than listing ALL the code, you should list an interesting subset of it. For a complete code listing, you should reference a Github repo containing the full example, and you could also link to a live example created using the Github gh-pages feature (so long as it uses only client-side code of course.) You can also make use of the MDN Sample Server, which is particularly helpful for more complex samples. See the "Examples" section for more details. If the example is visual, you could also use the MDN Live Sample feature to make it live and playable in the page.
    7. +
  7. Specifications table: At this point you need to include a specifications table — see the "Creating a spec reference table" section for more details.
    8. +
  8. Browser compatibility: Now you need to include a browser compatibility table. See Compatibility tables for details.
    9. +
  9. Polyfill: If appropriate (especially if common browsers are still shipping without support for the method), you can include a section which includes the code for a polyfill to allow the API to be used in browsers that don't implement it.
    10. +
+ +

Method page examples

+ +

The following are exemplary examples of Interface pages:

+ + + +

Tagging

+ +

For API reference pages, there are standard tags that all pages should have:

+ + + +

For Interface pages, also add:

+ + + +

For method pages, also add:

+ + + +

For property pages, also add:

+ + + +

In all cases, also add a keyword indicating the standardization status:

+ + + +

These tags will be used to generate correct quicklinks, with nice icons. See How to properly tag pages for additional information on tagging, as well as about other tags you may find useful.

diff --git a/files/zh-cn/mdn/contribute/howto/write_an_api_reference/information_contained_in_a_webidl_file/index.html b/files/zh-cn/mdn/contribute/howto/write_an_api_reference/information_contained_in_a_webidl_file/index.html new file mode 100644 index 0000000000..239c6a83f4 --- /dev/null +++ b/files/zh-cn/mdn/contribute/howto/write_an_api_reference/information_contained_in_a_webidl_file/index.html @@ -0,0 +1,505 @@ +--- +title: Information contained in a WebIDL file +slug: >- + MDN/Contribute/Howto/Write_an_API_reference/Information_contained_in_a_WebIDL_file +translation_of: >- + MDN/Contribute/Howto/Write_an_API_reference/Information_contained_in_a_WebIDL_file +--- +
+

{{MDNSidebar}}

+ +

在编写有关API的文档时，信息来源很多：规范描述了应该实现的内容以及模型，实现描述了实际放在浏览器中的内容。WebIDL文件是一种非常简洁的方式，可以提供很多（但不是全部）有关API的信息。本文档提供了有助于理解WebIDL语法的参考。

+ +

IDL代表接口定义语言，它用于描述API。在更广泛的计算领域，有几种IDL。在浏览器领域，我们使用的IDL称为WebIDL。有两种WebIDL可用：WebIDL规范中给出的一种，以及在浏览器中实现的一种。规范是规范引用，浏览器WebIDL描述了在特定浏览器中实际实现的内容，并包含其他内容，例如注释和有关非标准元素的信息。

+
+ +

 

+ +

在哪里可以找到WebIDL文件

+ +

WebIDL可以在多个位置找到：

+ + + +

Different dialects of WebIDL

+ +

WebIDL is defined in its specification. But it has been designed to be extended to convey more information, and browser vendors have done so:

+ + + +
+

We describe here only the subset of WebIDL which is most useful when writing documentation. There are many more annotations useful for implementers; refer to the four documents linked above to have a complete overview.

+
+ +

Interfaces

+ +

This section explains the WebIDL syntax that describes overall API features.

+ +

Name of the interface

+ +

The interface name is the string that appears after the keyword interface and before the next opening bracket ('{') or colon (':').

+ +
interface URL {};
+ +

Each WebIDL interface, being a true interface or a mixin, has its own page in the documentation, listing every constructor, property and method defined for it.

+ +

Inheritance chain

+ +

The parent, if any, of a given interface is defined after the interface name, following a colon (':'). There can be only one parent per interface.

+ +
interface HTMLMediaElement : HTMLElement {…}
+ +

The inheritance chain is listed automatically in the sidebar (using the \{{APIRef}} macro). It can also be added as an SVG image via the macro \{{InheritanceDiagram}}.

+ +

Mixins

+ +

Some properties or methods are available to several interfaces. To prevent redefinition they are defined in special WebIDL interfaces called mixins. In the WebIDL, they are prefixed using the [NoInterfaceObject] annotation. The name of a mixin, Body in the following example, doesn't appear in JavaScript.

+ +
[NoInterfaceObject]
+   interface Body {…}
+ +

For documentation purposes, we create a mixin page, with the same structure as an interface page. As they are not true interfaces, the word interface is not used — mixin is used instead.

+ +

Mixin methods and properties are listed in the same way as regular methods and properties:

+ + + +

Mixins implemented on an interface are defined using the implements keyword.

+ +
Request implements Body;
+Response implements Body;
+ +
+

Note: Mixin names do not appear in a Web developer console. We shouldn't show them, but we currently do this as it saves us from duplicating content, which would lead to a maintenance issue. We do this if the mixin is only used in one interface (such cases are bugs in the relevant specs — they shouldn't be defined as mixins, but as partial interfaces.)

+
+ +

Availability in workers

+ +

Availability in Web workers (of any type) and on the Window scope is defined using an annotation: [Exposed=(Window,Worker)]. The annotation applies to the partial interface it is listed with. If no annotation is available, the default value is Window.

+ +
[Exposed=(Window,Worker)]
+interface Performance {
+   [DependsOn=DeviceState, Affects=Nothing]
+   DOMHighResTimeStamp now();
+};
+
+[Exposed=Window]
+partial interface Performance {
+   [Constant]
+   readonly attribute PerformanceTiming timing;
+   [Constant]
+   readonly attribute PerformanceNavigation navigation;
+
+   jsonifier;
+};
+ +

In this case Performance.now() is available on the Window scope and to any worker, while Performance.timing, Performance.navigation and Performance.toJSON() are not available to Web workers.

+ +

The most common values for the [Exposed] are:

+ +
+
Window
+
The partial interface is available to the {{domxref('Window')}} global scope.
+
Worker
+
The partial interface is available to any kind of worker, that is if the global scope is a descendant of {{domxref('WorkerGlobalScope')}} — {{domxref('DedicatedWorkerGlobalScope')}}, {{domxref('SharedWorkerGlobalScope')}}, or {{domxref('ServiceWorkerGlobalScope')}} (It also is available to ChromeWorker, but we don't document this as they are not visible on the Web and are internal to Firefox.)
+
DedicatedWorker
+
The partial interface is available to the {{domxref('DedicatedWorkerGlobalScope')}} only.
+
SharedWorker
+
The partial interface is available to the {{domxref('SharedWorkerGlobalScope')}} only.
+
ServiceWorker
+
The partial interface is available to the {{domxref('ServiceWorkerGlobalScope')}} only.
+
+ +

Another value is possible, like System, but this has a special meaning and doesn't need to be documented.

+ +

Note that these possible values are themselves defined in WebIDL files. Interfaces may have a [Global=xyz] annotation. It means that when an object of this type is used as a global scope, any interface, property or method, with xyz as a value of [Exposed] is available.

+ +
[Global=(Worker,DedicatedWorker), Exposed=DedicatedWorker]
+interface DedicatedWorkerGlobalScope : WorkerGlobalScope {…}
+ +

Here, it is defined that when the global scope is of type DedicatedWorkerGlobalScope, that is if we are in a dedicated worker, any interface, property or method exposed – using the [Exposed] annotation – to Worker or DedicatedWorker is available.

+ +

Even the primary global is defined in WebIDL. The primary global is the value of an [Exposed] annotation when not present. This is defined using the [PrimaryGlobal] annotation and is present on {{domxref('Window')}}:

+ +
[PrimaryGlobal, NeedResolve]
+/*sealed*/ interface Window : EventTarget {…}
+ +

Preferences

+ +
+

Note: this information is specific to Gecko and should only be used in the Browser compatibility section.

+
+ +

In Gecko, the availability of a partial interface, including its constructor, properties and methods may be controlled by a preference (usually called a "pref"). This is marked in the WebIDL too.

+ +
[Pref="media.webspeech.synth.enabled"]
+interface SpeechSynthesis {
+   readonly attribute boolean pending;
+   readonly attribute boolean speaking;
+   readonly attribute boolean paused;
+};
+ +

Here media.webspeech.synth.enabled controls the SpeechSynthesis interface and its properties (the full listing has more than 3.)

+ +
+

Note: the default value of the preference is not available directly in the WebIDL (it can be different from one product using Gecko to another.)

+
+ +

Properties

+ +

You can recognize the definition of a property by the presence of the attribute keyword.

+ +

Name of the property

+ +
readonly attribute MediaError? error;
+ +

In the above example the name of the property is error; in the docs we will refer to it as HTMLMediaElement.error as it belongs to the HTMLMediaElement interface. Linking to the page is either done with the interface prefix using \{{domxref('HTMLMediaElement.error')}} or without the prefix using \{{domxref('HTMLMediaElement.error', 'error')}} when the context is obvious and unambiguous.

+ +

Type of the property

+ +
readonly attribute MediaError? error;
+ +

The property value is an object of type MediaError. The question mark ('?') indicates that it can take a value of null, and the documentation must explain when this may occur. If no question mark is present, the error property can't be null.

+ +

Writing permissions on the property

+ +
readonly attribute MediaError? error;
+ +

If the keyword readonly is present, the property can't be modified. It must be marked as read-only:

+ + + +
+

Note: Only read-only properties can be described as 'returning' a value. Non read-only properties can also be used to set a value.

+
+ + + +

Throwing exceptions

+ +
[SetterThrows]
+            attribute DOMString src;
+ +

In some cases, like when some values are illegal, setting a new value can lead to an exception being raised. This is marked using the [SetterThrows] annotation. When this happens, the Syntax section of the property page must have an Exceptions subsection. The list of exceptions and the conditions to have them thrown are listed, as textual information, in the specification of that API.

+ +

Note that some exceptions are not explicitly marked but are defined by the JavaScript bindings. Trying to set an illegal enumerated value (mapped to a JavaScript {{jsxref('String')}}) raises a {{exception('TypeError')}} exception. This must be documented, but is only implicitly marked in the WebIDL document.

+ +

It is uncommon to have getters throwing exceptions, though it happens in a few cases. In this case the [GetterThrows] annotation is used. Here also, the Syntax section of the property page must have an Exceptions subsection.

+ +
partial interface Blob {
+  [GetterThrows]
+  readonly attribute unsigned long long size;
+};
+
+ +

Not throwing exceptions

+ +

When the semantics of Webidl is not followed, an exception is often thrown, even without [SetterThrows] or [GetterThrows] set. For example, in strict mode, if we try to set a read-only property to a new value, that is to call its implicit setter, a read-only property will throw in strict mode.

+ +

Mostly for compatibility purpose, this behavior is sometimes annoying. To prevent this by creating a no-op setter (that is by silently ignoring any attempt to set the property to a new value), the [LenientSetter] annotation can be used.

+ +
partial interface Document {
+  [LenientSetter]
+  readonly attribute boolean fullscreen;
+  [LenientSetter]
+  readonly attribute boolean fullscreenEnabled;
+};
+
+ +

In these cases, an extra sentence is added to the description of the property. E.g

+ +

Although this property is read-only, it will not throw if it is modified (even in strict mode); the setter is a no-operation and it will be ignored.

+ +

New objects or references

+ +

The return value of a property can be either a copy of an internal object, a newly created synthetic object, or a reference to an internal object.

+ +

Basic objects with types like {{jsxref("String")}} (being an IDL DOMString, or other), {{jsxref("Number")}} (being an IDL byte, octet, unsigned int, or other), and {{jsxref("Boolean")}} are always copied and nothing special has to be noted about them (it is natural behavior expected by a JavaScript developer.)

+ +

For interface objects, the default is to return a reference to the internal object. This has to be mentioned both in the short description in the interface page, and in the description in the specific sub-pages.

+ +
+

Note: The keyword readonly used with a property returning an object applies to the reference (the internal object cannot be changed.) The properties of the returned object can be changed, even if they are marked as read-only in the relevant interface.

+
+ +

Sometimes an API must return a new object, or a copy of an internal one. This case is indicated in the WebIDL using the [NewObject] annotation.

+ +
[NewObject]
+   readonly attribute TimeRanges buffered;
+ +

In this case, each call to buffered returns a different object: changing it will not change the internal value, and a change in the internal value will not affect each object instance. In the documentation, we will mark it by using the adjective new next to object:

+ +

The HTMLMediaElement.buffered read-only property returns a new \{{domxref("TimeRanges")}} object that…

+ +

and

+ +
+
\{{domxref("HTMLMediaElement.buffered")}}\{{readonlyinline}}
+
Returns a new \{{domxref("TimeRanges")}} object that …
+
+ +

In the case of a reference to a collection object (like HTMLCollection, HTMLFormElementsCollection, or HTMLOptionsCollection, always without [NewObject]), we make it explicit that changes to the underlying object will be available via the returned reference. To mark this, we qualify the collection as a live HTMLCollection (or HTMLFormElementsCollections, or HTMLOptionsCollection), both in the interface description and in the subpage.

+ +

E.g.

+ +
+
\{{domxref("HTMLFormElement.elements")}}\{{readonlyinline}}
+
Returns a live \{{domxref("HTMLFormControlsCollection")}} containing…
+
+ +

Availability in workers

+ +

Individual property availability in workers is also found in the WebIDL. For a property, the default is the same availability as the interface (that is available to {{domxref('Window')}} context only if nothing special is marked) or as the partial interface it is defined in.

+ +

For documentation, the subpage must contain a sentence indicating if it is available or not in Web workers, right before the "Syntax" section.

+ +

Preferences

+ +
+

This information is specific to Gecko and should only be used in the Browser compatibility section.

+
+ +

In Gecko, the availability of some properties may be controlled by a preference. This is marked in the WebIDL too.

+ +
[Pref="media.webvtt.enabled"]
+    readonly attribute TextTrackList? textTracks;
+ +

Here media.webvtt.enabled controls the textTracks property.

+ +
+

The default value of the preference is not available directly in the WebIDL (it can be different from one product using Gecko to another).

+
+ +

Methods

+ +

You can recognize the definition of a method by the presence of parentheses after the name.

+ +

Name of the method

+ +
DOMString canPlayType(DOMString type);
+ +

The name of the method is canPlayType, and we will refer to it as HTMLMediaElement.canPlayType() (with the parentheses that indicate that it is a method) in the docs, as it belongs to the HTMLMediaElement interface. Linking to the page is either done with the interface prefix using \{{domxref('HTMLMediaElement.canPlayType()')}}, or without the prefix using \{{domxref('HTMLMediaElement.canPlayType', 'canPlayType()')}} when the context is obvious and unambiguous. The parentheses should always be included.

+ +

Parameters

+ +
TextTrack addTextTrack(TextTrackKind kind,
+                       optional DOMString label = "",
+                       optional DOMString language = "");
+ +

The parameters of a method are listed in the Syntax section of the method sub-page. They are listed in the WebIDL in order, between the parenthesis, as a comma-separated list. Each parameter has a name (indicated above) and a type (e.g. a '?' means that the null value is valid.) If marked optional, the parameter is optional to include in a method call and must have the \{{OptionalInline}} flag included when it is listed in the Syntax section. The parameter's default value is listed after the equality sign ('=').

+ +

Type of the return value

+ +
DOMString canPlayType(DOMString type);
+ +

The return value type is indicated first inside the parentheses — in the above case the value is an object of type DOMString. if followed by a question mark ('?'), a value of null can be returned too, and the documentation must explain when this may happen. If no question mark is present, like here,  the return value can't be null.

+ +

The keyword void means that there is no return value. It is not a return value type. If the WebIDL entry reads void, the Return value section in the docs should contain only a simple None.

+ +

Throwing exceptions

+ +
[Throws]
+   void fastSeek(double time);
+ +

Some methods can throw exceptions. This is marked using the [Throws] annotation. When this happens, the Syntax section of the method page must have an Exceptions subsection. The list of exceptions and the conditions to have them thrown are listed, as textual information, in the specification of that API.

+ +

Note that some exceptions are not explicitly marked but are defined by the JavaScript bindings. Trying to set an illegal enumerated value (mapped to a JavaScript {{jsxref('String')}}) as a parameter will raise a {{exception('TypeError')}} exception. This must be documented, but it is only implicitly marked in the WebIDL document.

+ +

Have a look at one of these Exceptions sections.

+ +

Availability in workers

+ +

Individual method availability in workers is also found in the WebIDL. For a method, the default is the same availability as the interface (that is available to {{domxref('Window')}} context only if nothing special is marked) or as the partial interface it is defined it.

+ +

For the documentation, the sub-page must contain a sentence indicating if it is available in Web workers, right before the Syntax section.

+ +

Preferences

+ +
+

Note: this information is specific to Gecko and should only be used in the Browser compatibility section.

+
+ +

In Gecko, the availability of some properties may be controlled by a preference. This is marked in the WebIDL too.

+ +
[Pref="media.webvtt.enabled"]
+   TextTrack addTextTrack(TextTrackKind kind,
+                          optional DOMString label = "",
+                          optional DOMString language = "");
+ +

Here media.webvtt.enabled controls the addTextTrack() method.

+ +
+

Note: The default value of the preference is not available directly in the WebIDL (it can be different from one product using Gecko to another.)

+
+ +

 

+ +

Special methods

+ +

Some methods are not listed as regular methods in WebIDL but instead as special keywords, which translate to specific standard JavaScript methods.

+ +

toString() and toJSON()

+ +

A stringifier is mapped to toString() and defined as:

+ +
stringifier;
+ +

The toString() method is listed just like any other method of the interface and has its own sub-page (E.g. {{domxref("Range.toString()")}})

+ +

A jsonifier is mapped to toJSON() and defined as:

+ +
jsonifier; // Gecko version
+serializer; // Standard version
+
+ +

The toJSON() method is listed just like any other method of the interface and has its own sub-page (E.g. {{domxref("Performance.toJSON()")}})

+ +
+

Note: the WebIDL specification uses serializer instead of jsonifier. This is not used in Gecko — only the non-standard likely early proposal jsonifier is found in mozilla-central.

+
+ +

 

+ +

Iterator-like methods

+ +

An interface may be defined as iterable, meaning that it will have the following methods: entries(), keys(), values() and forEach(). They also supports the use of {{jsxref("Statements/for...of", "for...of")}} on an object implementing this interface.

+ +

There are two kinds of iteration possible: the value iterator and the pair iterator.

+ +

Value iterator

+ +
iterable<valueType>
+ +

The iterator will iterate over values of type valueType. The generated methods will be:

+ + + +

Such an iterator allows to use the syntax for (var p in object) as a shorthand of for (var p in object.entries()). We add a sentence about it in the interface description.

+ +
+

Note: the value pairs to iterate over can be defined in two different ways:

+ +
    +
  1. Outside the webidl file, in the prose accompanying it. Such a prose is in the spec and usually starts with: "The values to iterate over…".
    2. +
  2. In the webidl file, implicitly, if the interface supports indexed properties, that is when the interface has a getter methods with a parameter of type unsigned long.
    3. +
+
+ +

Pair iterator

+ +
iterable<keyType, valueType>
+ +

The iterator will iterate over values of type valueType, with keys of type keyType. The generated methods will be:

+ + + +

Such an iterator allows to use the syntax for (var p in object) as a shorthand of for (var p in object.entries()). We add a sentence about it in the interface description. E.g. {{domxref('FormData')}}.

+ +
+

Note: the value pairs to iterate over are not defined in the webidl file, but in the prose accompanying it. Such a prose is in the spec and usually starts with: "The value pairs to iterate over…"
+ E.g, for {{domxref('FormData')}} you find in the spec: "The value pairs to iterate over are the entries with the key being the name and the value the value. "

+
+ +

Set-like methods

+ +

An interface may be defined as set-like, meaning that it represents an ordered set of values will have the following methods: entries(), keys(),  values(), forEach(), and has() (it also has the size property). They also supports the use of {{jsxref("Statements/for...of", "for...of")}} on an object implementing this interface. The set-like can be prefixed readonly or not. If not read-only, the methods to modify the set are also implemented: add(), clear(), and delete().

+ +
setlike<valueType>
+ +

The generated properties will be:

+ + + +

In the case, the set-like declaration is not prefixed by read-only, the following methods are also generated:

+ + + +

Such an set interface also allows to use the syntax for (var p in object) as a shorthand of for (var p in object.entries()). We add a sentence about it in the interface description. E.g. {{domxref('FontFaceSet')}}.

+ +

 

+ +

Constructors

+ +

Constructors are a little bit hidden in WebIDL: they are listed as annotations of the main interface.

+ +

Unnamed constructors

+ +

This is the most common case for constructors. The constructor of a given interface A, can be used as a = new A(parameters);

+ +
 [Constructor, Func="MessageChannel::Enabled",
+  Exposed=(Window,Worker)]
+    interface MessageChannel {…};
+ +

A constructor with the same interface is defined using the Constructor annotation on the interface. There can be parenthesis and a list of parameters or not (like in the above example.) We document all the unnamed constructors on a sub-page — for example the above is given the slug Web/API/MessageChannel/MessageChannel and the title MessageChannel().

+ +

Another example of an unnamed constructor, with parameters:

+ +
[Constructor(DOMString type, optional MessageEventInit eventInitDict),
+ Exposed=(Window,Worker,System)]
+   interface MessageEvent : Event {…};
+ +

There can also be several unnamed constructors, differing by their parameter lists. All syntax is documented in one single sub-page.

+ +
[Constructor(DOMString url, URL base),
+ Constructor(DOMString url, optional DOMString base),
+ Exposed=(Window,Worker)]
+    interface URL {};
+ +

Named constructors

+ +
[NamedConstructor=Image(optional unsigned long width, optional unsigned long height)]
+    interface HTMLImageElement : HTMLElement {…
+ +

A named constructor is a constructor that has a different name than that of its interface. For example new Image(…) creates a new HTMLImageElement object. They are defined in the WebIDL using the NamedConstructor annotation on the interface, followed by the name of the constructor after the equality sign ('=') and the parameter inside the parenthesis, in the same format as you'll see for methods.

+ +

There can be several named constructors for a specific interface, but this is extremely rare; in such a case we include one sub-page per name.

+ +

Availability in workers

+ +

Constructors have the same availability as the interface, or partial interface, they are defined on. The sub-page provides this information in the same way as for a method.

+ +

Preferences

+ +

Constructors are controlled by the same preference as the interface, or partial interface, they are defined on. The sub-page provides this information in the same way as for a method.

diff --git a/files/zh-cn/mdn/contribute/howto/write_an_article_to_help_learn_about_the_web/index.html b/files/zh-cn/mdn/contribute/howto/write_an_article_to_help_learn_about_the_web/index.html new file mode 100644 index 0000000000..15c6f0b2ee --- /dev/null +++ b/files/zh-cn/mdn/contribute/howto/write_an_article_to_help_learn_about_the_web/index.html @@ -0,0 +1,117 @@ +--- +title: 如何写文章帮助人们了解 Web +slug: MDN/Contribute/Howto/Write_an_article_to_help_learn_about_the_Web +tags: + - MDN元数据 + - 学习社区 + - 指导 + - 贡献指南 +translation_of: MDN/Contribute/Howto/Write_an_article_to_help_learn_about_the_Web +--- +
{{MDNSidebar}}
+ +

MDN 的学习区是我们给新手开发者介绍 Web 概念的大本营。因为它的内容主要面对初学者，这是你分享知识，帮助新手逐渐了解 Web 的绝佳地点。确保新手开发者能够跟上这里的内容是很重要的，所以我们格外重视学习区。

+ +

这篇文章解释了如何给学习区写文章。

+ +

如何写学习社区的文章

+ +

要开始贡献你的知识，只需点击绿色大按钮，然后按照下面的五个步骤。如果你想找点子，请看一下我们的团队 Trello ！

+ +
写一篇新的学习文章 + +
+
+ +

这篇文章可能不会在正确的地方出现，但至少是在MDN上。如果你需要找人谈谈把它搬到正确的地方，请联系我们。

+ +

第一步：写两行

+ +

你文章的第一句话需要总结一下你将要涉及的主题，第二句话应该更详细地介绍你要放在文章中的内容（项目）。例如：

+ +
+

 {{glossary("HTML")}} 文件包含的结构和内容, {{Glossary("CSS")}}以及其他主要的Web技术，使内容看起来像你想要的那样。在本文中，我们将介绍这项技术是如何工作的，以及如何编写你自己的基本示例。

+
+ +

注意示例如何简要说明CSS是用于样式化页面的核心Web技术。 这足以使读者很好地了解本文所涵盖的内容。

+ +

因为学习区域的文章主要是针对初学者的，所以每篇文章都应该涵盖一个简单的主题，以免给读者带来太多的新信息。如果你不能在一句话中总结这篇文章，那么你可能在一篇文章中做得太多了!

+ +

第二步：添加一个顶部框

+ +

然后添加一个顶框，以帮助读者了解他们在学习过程中的位置。 这是“了解URL及其结构 ”顶部框的示例。 您可以在编写自己的文章时将其用作模型。

+ + + + + + + + + + + + +
必要条件:您首先必须清楚Internet的工作方式，Web服务器是什么，与Web链接背后的所有概念。
目标:您将了解什么是URL以及它如何在Web上工作
+ +
+
必要条件
+
读者首先必须知道什么东西才能读懂你的一篇文章?在有可能的状况下，让每一个前提条件链接到另一篇涵盖概念的学习领域的一篇文章(除了您写的是是一篇完全不需要首先先验知识的无比基础的文章)。
+
目标
+
这一章节粗略说明了您的读者在阅读学习这篇文章的过程中会学到（并学会）什么。这与一行程序有点不同;一行代码总结了文章的主题，而目标部分专门列出了读者在阅读文章过程中所希望完成的全部内容。
+
+ +
+

注意:要创建此表，您可以复制并粘贴上面的示例表，或者使用MDN的编辑器 台式工具。如果选择使用table工具，则需要在默认的standard-table类之外特别添加learn-box CSS类。为此，当您创建或编辑表的属性时，请转到“Advanced”面板并将样式表类字段设置为“standard-table learn-box”。

+
+ +

第三步:写一个完整的描述

+ +

接下来，写一个更长的描述，提供更全面的文章概述，突出最重要的概念。不要忘记解释为什么读者要花时间来学习这个主题并阅读你的文章！

+ +

第四步：更深一步

+ +
当你完成了所有这些，你终于可以深入到主题。你可以根据自己的喜好来组织文章的这一部分(尽管您能够随时咨询我们的 设计指南)。这是你闪耀的机会!详细解释你要写的主题。提供指向完整参考文档的链接，详细解释该技术的工作原理，提供语法和用法细节，等等。由你决定 + +
+
+ + + +

看一看我们的函数的前几节可重用代码块文章 ，有一些很好的描述部分。

+ +

第五步:提供“主动学习”材料

+ +

为了阐明本文并帮助读者更好地理解他们正在学习的内容，请确保提供练习、教程和需要完成的任务。通过让他们积极地、实际地使用和试验你文章中解释的概念，你可以帮助他们将信息“锁定”在大脑中。

+ +

您可以选择在页面中直接包含这些示例作为 实时实例,或者直接链接到它们。 （如果它们不能作为实时实例。） 如果你有兴趣帮助创造这些有价值的东西 ，请参阅《创建一个交互式的练习来帮助学习网络》

+ +

如果您不能提供到现有活动学习材料的链接(您不知道或者没有时间创建它们)，那么您应该在文章中添加标记{{tag ("NeedsActiveLearning")}}。这样，其他贡献者就可以找到需要积极学习材料的文章，并可能帮助你找到它们。

+ +

看看《主动学习:选择不同的元素》进行现场互动学习练习或者《主动学习: 玩转范围》或者另一种不同风格的练习，要求它们在本地下载模板并按照提供的步骤更改

+ +

+ +

                                                                                         

+ +

第六步：查看文章，并放入学习区域导航菜单

+ +

在你写完你的文章后，让我们知道，这样我们可以看一看，做一个回顾，并提出改进建议 。再次看看我们的 联系方式 板块以寻找最好的联系方式。

+ +

完成文章的另一部分是把它放在学习区主导航菜单中。这个菜单是 LearnSidebar 宏生成的。 你需要特殊的权限来编辑，所以，再一次，让我们团队中的一个人把它添加进去。

+ +

您至少应该将其添加到您的页面中，这是通过在页面顶部的段落中添加宏调用\{{LearnSidebar}}来完成的。

+ + + +

推荐文章

+ +

您想做出贡献，但是您不知道该写什么?

+ +

学习社区维护了一个要写文章的Trello看板。随意挑选一个，然后开始去写吧！

diff --git a/files/zh-cn/mdn/contribute/howto/write_for_seo/index.html b/files/zh-cn/mdn/contribute/howto/write_for_seo/index.html new file mode 100644 index 0000000000..c8bab8d102 --- /dev/null +++ b/files/zh-cn/mdn/contribute/howto/write_for_seo/index.html @@ -0,0 +1,77 @@ +--- +title: 如何带着SEO的思维将MDN的Web文档写的更符合搜索引擎展现 +slug: MDN/Contribute/Howto/Write_for_SEO +tags: + - MDN内容贡献 + - MDN搜索优化 + - MDN搜索引擎优化 + - MDN文档 + - MDN的SEO优化 + - SEO + - 搜索引擎优化 +translation_of: MDN/Contribute/Howto/Write_for_SEO +--- +
{{MDNSidebar}}
{{IncludeSubnav("/zh-CN/docs/MDN")}}{{draft("为了更好的将MDN的文档符合SEO要求，我们在此提供了一些提升MDN搜索引擎优化的技术建议。本文是由MDN的志愿者们整理翻译完成的。 ")}}
+ +

本指南涵盖了我们对内容的基础要求、推荐和实践参考，以确保搜索引擎可以更好的对我们的内容进行分类和索引，同时确保用户可以轻松地获取到所需的内容。

+ +

简介

+ +

MDN写作的首要目标是向开发者们阐明和指导开放的Web技术，以便他们能够快速找到他们想要的东西，或者为了优化自己的代码而寻找需要的细节，因此我们在MDN提供的内容可以被更容易的搜索到就非常重要了。

+ +

由于绝大部分读者是通过搜索引擎搜索找到MDN的内容的，那么作为作者，我们就要始终记得内容对搜索引擎的友好程度这件事。为了对搜索引擎友好，我们撰写了SEO指引的内容以帮助MDN的作者和编辑们能够确保MDN上的每篇内容的设计、撰写和标记方式都符合SEO规范，以获得搜索引擎更好的收录索引和展现。

+ +

本文档的状态

+ +

目前我们刚开始了改进MDN文档在搜索引擎优化({{Glossary("SEO")}}) 的长期项目的初期阶段。 我们最近完成了一系列小规模实验来测试能提升SEO的方法，并确定哪些内容能够作为SEO指南提供给我们的贡献者们。

+ +

我们仍在编辑并更新本文，同时将其他贡献者提供的参考纳入到我们的发现中。

+ +

SEO 要点

+ +

The following is a list of things you should check while writing and reviewing content to help ensure that the page and its neighbors will be indexed properly by search engines.

+ + + +

避免过于相似的内容页面

+ +

Each article should be as unique as possible. Articles that look similar to one another textually will wind up being considered to be about roughly the same thing, even if they aren't. For example, if an interface has the properties width and height, it's easy for the text to be surprisingly similar, with just a few words swapped out, and using the same example. This makes it hard for search engines to know which is which, and they wind up sharing page rank, resulting in both being harder to find than they ought to be.

+ +

Understandably, writers confronted with two related properties like width and height (or any other set of functionally related features) are tempted to write the article on width, then copy that article and paste it into the one on height, replacing a few words. Done!

+ +

Unfortunately, the result is two pages that, as far as search engines are concerned, may as well be the same thing.

+ +

It's important, then, to ensure that every page has its own content. Here are some suggestions to help you accomplish that:

+ + + +

The easiest way to avoid being overly similar is of course to write each article from scratch if time allows.

+ +

避免页面内容过短

+ +

如果文章过短，那么搜索引擎可能会难以甚至无法对其建立关键字索引。一般来说，文章的主体内容应该至少包含 250-300 个单词。但是也不要对内容确实很少的文章进行刻意的扩充，在可能的情况下尽量遵守该指导原则即可。

+ + + +

See also

+ + diff --git "a/files/zh-cn/mdn/contribute/howto/\345\246\202\344\275\225\346\267\273\345\212\240\346\210\226\346\233\264\346\226\260\346\265\217\350\247\210\345\231\250\345\205\274\345\256\271\346\200\247\346\225\260\346\215\256/index.html" "b/files/zh-cn/mdn/contribute/howto/\345\246\202\344\275\225\346\267\273\345\212\240\346\210\226\346\233\264\346\226\260\346\265\217\350\247\210\345\231\250\345\205\274\345\256\271\346\200\247\346\225\260\346\215\256/index.html" new file mode 100644 index 0000000000..8c0513d654 --- /dev/null +++ "b/files/zh-cn/mdn/contribute/howto/\345\246\202\344\275\225\346\267\273\345\212\240\346\210\226\346\233\264\346\226\260\346\265\217\350\247\210\345\231\250\345\205\274\345\256\271\346\200\247\346\225\260\346\215\256/index.html" @@ -0,0 +1,30 @@ +--- +title: 如何添加或更新浏览器兼容性数据 +slug: MDN/Contribute/Howto/如何添加或更新浏览器兼容性数据 +translation_of: MDN/Contribute/Howto/Add_or_update_browser_compatibility_data +--- +
{{MDNSidebar}}

如果你有浏览器在兼容Web特性方面的信息 —— 或者有意愿并有能力做一些这方面的研究和/或实验 —— 你可以帮助更新MDN的浏览器兼容性数据库（BCD）。

+ + + +
+
哪些地方需要做？
+
+

在MDN上你有这几种方法可以帮助改进浏览器兼容性方面的信息：

+ +
    +
  • 添加尚未收录在BCD仓库内的网页特性数据
    • +
  • 依据浏览器新版本的变更内容、现有数据中的更正错误，或者某项技术的特性之最新变更等信息来更新现有数据
    • +
  • 提交 pull requests 到 BCD issues filed on Github.
    • +
+
+
做这个任务你需要知道哪些知识？
+
做这个任务需要哪些步骤？
+
欲了解如何更新在GitHub上的组成BCD仓库的 JSON 文件的详细信息，请参见兼容性表格页面。如要了解我们特别寻求帮助的问题列表，请到 Github issues with the "Help Wanted" tag.
+
 
+
 
+
diff --git "a/files/zh-cn/mdn/contribute/howto/\345\255\246\344\271\240_\344\272\244\344\272\222_\345\234\250\347\272\277_\350\265\267\346\255\245_\345\274\200\345\247\213/index.html" "b/files/zh-cn/mdn/contribute/howto/\345\255\246\344\271\240_\344\272\244\344\272\222_\345\234\250\347\272\277_\350\265\267\346\255\245_\345\274\200\345\247\213/index.html" new file mode 100644 index 0000000000..91b8a8640d --- /dev/null +++ "b/files/zh-cn/mdn/contribute/howto/\345\255\246\344\271\240_\344\272\244\344\272\222_\345\234\250\347\272\277_\350\265\267\346\255\245_\345\274\200\345\247\213/index.html" @@ -0,0 +1,185 @@ +--- +title: 如何创建一个交互学习环境 +slug: MDN/Contribute/Howto/学习_交互_在线_起步_开始 +tags: + - MDN Meta + - 交互 + - 如何使用 + - 学习 + - 教程 +translation_of: MDN/Contribute/Howto/Create_an_interactive_exercise_to_help_learning_the_web +--- +
{{MDNSidebar}}

动态的内容对于学习 Web 来说是重要的。 她能让学习的人更加积极主动。 这可以是练习，实例，任务，评价等等。总之，任何有助于学习理解的东西都行。

+ +

这儿还没有能够直接创建动态的实例内容。但是一些第三方工具可以帮助你创建（如： JSFiddle，CodePen，Dabblet，等），你可以将其链接放在 MDN 文章中。另外，你可以使用 WebMaker 项目的 Thimble 来创造更加高级的内容。

+ +

目前，MDN 虽然没有能够轻易创建动态实例内容的工具。不过，如果你是工程师，可以使用当前 MDN 提供的功能创建自定义的主动学习内容，下面内容将告诉你如何操作。

+ +

MDN live samples

+ +

MDN 有一个非常炫酷的功能：live samples。她是一种可以将 MDN 页面内任何 HTML, CSS, Javascript 代码等效执行的机制。在使用她以前，你最好通读一下 Using the live sample system，这是我们关于她的完整文档。虽然她很容易使用，不过通过阅读文档，你会学到一些奇淫巧技。

+ +

有意思的是，将任何类型的工具或实例嵌入到 MDN 页面中都可以通过调教她轻松做到。

+ +

隐藏代码

+ +

通过实例创建主动学习内容的第一种方法是编辑要添加内容的页面。使用 Live Sample 功能创建内容，只构建你需要的功能，不要在乎代码的复杂度。当内容准备好之后，只需切换到编辑器视图，并用 class 为 hidden 的 {{HTMLElement('div')}} 来包围你的代码。这样代码就会隐藏，不过实例依然可以访问和显示。

+ +

看看这个简单的代码：

+ +
+

点击这个方块提供随机色，或者直接输入色值

+ + +{{EmbedLiveSample('hidden_code_example', 120, 120)}}
+ +

如果你使用 MDN 编辑器查看该页面代码，你会看到如下 HTML 代码：

+ +
<div class="moreinfo">
+<p>Click on the following square to randomly change its color or just type an hexadecimal code color</p>
+
+<div class="hidden">
+<h4 id="hidden_code_example">hidden code example</h4>
+
+<h5 id="HTML">HTML</h5>
+
+<pre class="brush: html">
+&lt;div class="square"&gt;
+  #&lt;input class="color"&gt;
+&lt;/div&gt;</pre>
+
+<h5 id="CSS">CSS</h5>
+
+<pre class="brush: css">
+body {
+  padding: 10px;
+  margin : 0;
+}
+
+.square {
+  width  : 80px;
+  height : 80px;
+  padding: 10px;
+  background-color: black;
+  color: white;
+  text-align: center;
+}
+
+.color {
+  width: 60px;
+  text-transform: uppercase;
+}
+</pre>
+
+<h5 id="JS">JS</h5>
+
+<pre class="brush: js">
+function setColor(color) {
+  document.querySelector('.square').style.backgroundColor = '#' + color;
+  document.querySelector('.color').value = color;
+}
+
+function getRandomColor() {
+  var color = Math.floor(Math.random() * 16777215);
+  return color.toString(16);
+}
+
+function getInputColor() {
+  var value = document.querySelector('.color').value;
+  var color = Number('0x' + color);
+  if (color === +color) {
+    return color.toString(16);
+  }
+  return value;
+}
+
+document.addEventListener('click', function () {
+  setColor(getRandomColor());
+});
+
+document.addEventListener('keyup', function () {
+  setColor(getInputColor());
+});
+</pre>
+</div>
+
+\{{EmbedLiveSample('hidden_code_example', 120, 120)}}
+</div>
+ +

你可以在 the Canvas API page 查看更多高级例子。

+ +

外部代码

+ +

前面的例子在你想嵌入主动学习内容时是可行的。不过，如果你想要处理更加复杂的代码，这个 hidden 的 {{HTMLElement('div')}} 就比较麻烦。

+ +

另外种方案是将内容写入 MDN 页面，然后嵌入另一个页面中。为此，我们可以使用 {{TemplateLink("EmbedDistLiveSample")}} 替代{{TemplateLink("EmbedLiveSample")}} 。

+ +

我们学习配置这个模拟远程代码嵌入的实例：

+ +
+

点击这个方块提供随机色，或者直接输入色值

+{{EmbedLiveSample('The_example', 120, 120, '', 'MDN/Contribute/Howto/Create_an_interactive_exercise_to_help_learning_the_web/distant_example')}}
+ +

这下如果你继续使用 MDN 编辑器查看页面源码，将看不到隐藏元素。如果你需要看，则需要前往这个页面地址。

+ +

你可以在 HTML 表单教程中查看更多高级例子，那里可以使用表单尝试。

diff --git "a/files/zh-cn/mdn/contribute/howto/\346\210\220\344\270\272\344\270\200\345\220\215\346\265\213\350\257\225\347\211\210\350\257\225\351\252\214\345\221\230/index.html" "b/files/zh-cn/mdn/contribute/howto/\346\210\220\344\270\272\344\270\200\345\220\215\346\265\213\350\257\225\347\211\210\350\257\225\351\252\214\345\221\230/index.html" new file mode 100644 index 0000000000..08693b3ff1 --- /dev/null +++ "b/files/zh-cn/mdn/contribute/howto/\346\210\220\344\270\272\344\270\200\345\220\215\346\265\213\350\257\225\347\211\210\350\257\225\351\252\214\345\221\230/index.html" @@ -0,0 +1,53 @@ +--- +title: 如何成为一名测试版试验员 +slug: MDN/Contribute/Howto/成为一名测试版试验员 +tags: + - MDN Meta +translation_of: MDN/Contribute/Howto/Be_a_beta_tester +--- +
{{MDNSidebar}}
+ +

随着MDN Kuma平台的开发人员不断地对站点进行更改，我们为那些选择成为测试版测试人员提供对这些新特性的早期访问。与任何“beta”测试一样，在某些情况下，一些功能可能无法正常工作。

+ +

参与beta测试

+ +
    +
  1. 登录MDN，在顶部导航栏点击你的用户名。
    + Shows location of the user's profile link in the top navigation
    + 随后跳转到你的资料页。
    2. +
  2. 点击编辑按钮。
    + Shows location of the button to edit a user's profile (which may vary depending on window dimensions
    + 随后在编辑模式下打开资料页。
    3. +
  3. 勾选复选框成为 Beta 测试者。
    + Shows the location of the Beta Tester checkbox
    4. +
  4. 点击资料页底部的发布按钮
    + Shows the location of the Publish button on a user's profile page
    5. +
+ +

退出Beta测试

+ +
    +
  1. 登录MDN，在顶部导航栏点击你的用户名。随后会跳转到你的资料页。
    2. +
  2. 点击编辑按钮。随后在编辑模式下打开资料页。
    3. +
  3. 取消 Beta 测试者的复选框
    4. +
  4. 点击发布按钮.
    5. +
+ +

对beta测试给予反馈

+ +

你有两种方式可以对 beta 测试进行反馈:

+ + + +
    +
  1. 如果你还没有账号，创建一个 Bugzilla 账号.
    2. +
  2. 打开 bug report in Bugzilla for MDN.
    3. +
  3. 在“摘要”字段中包含 “beta” 一词，帮助 MDN开发人员过滤和区分传入的 bug。.
    4. +
  4. 尽你所能填写 bug 报告. 越详细越好.
    5. +
  5. 点击提交按钮.
    6. +
+ +

 

diff --git a/files/zh-cn/mdn/contribute/index.html b/files/zh-cn/mdn/contribute/index.html new file mode 100644 index 0000000000..c28b259fc6 --- /dev/null +++ b/files/zh-cn/mdn/contribute/index.html @@ -0,0 +1,20 @@ +--- +title: 为 MDN 做贡献 +slug: MDN/Contribute +tags: + - Guide + - Landing + - MDN Meta +translation_of: MDN/Contribute +--- +
{{MDNSidebar}}
{{IncludeSubnav("/zh-CN/docs/MDN")}}
+ +

欢迎！你来到了这里，说明你已经迈出了成为 MDN 贡献者的第一步！

+ +

本页面包含如何为 MDN 做贡献的各个方面的内容，包括风格指南、编辑器和工具使用指南，等等。在编辑或创建任何页面前，请先阅读并确认你已了解了 Mozilla 条款。

+ +

如果你以前没有为 MDN 做贡献的经验，这个入门指南可以帮你找到一个你所熟悉的或者力所能及的任务。

+ +

{{LandingPageListSubPages()}}

+ +

 

diff --git a/files/zh-cn/mdn/contribute/localize/index.html b/files/zh-cn/mdn/contribute/localize/index.html new file mode 100644 index 0000000000..d67b35280a --- /dev/null +++ b/files/zh-cn/mdn/contribute/localize/index.html @@ -0,0 +1,68 @@ +--- +title: MDN 本地化 +slug: MDN/Contribute/Localize +tags: + - I10n + - Landing + - Localization + - MDN +translation_of: MDN/Contribute/Localize +--- +
{{MDNSidebar}}
+ +
{{IncludeSubnav("/zh-CN/docs/MDN")}}
+ +

MDN 被全世界的人们和 Firefox 项目组内部用作 Web 技术的参考和指南。众多的本地化社区是 Mozilla 项目的一个关键部分，他们对文档的翻译和本地化工作可以帮助世界各地的人们开发开放 Web。如果你想更多地了解本地化相关的内容，或者准备开始一个新的本地化工作，你可以从这里开始。

+ +

MDN 上的本地化类型

+ +

MDN 上的本地化包含三个方面，它们位于不同的系统并要求不同访问权限。

+ +

MDN 站点的用户界面

+ +

指的是每个或大多数 MDN 页面中都有的框架、导航和用户控制组件等部分。这些地方使用 Mozilla Pontoon 系统自动翻译，这里是该项目的主页。如果你所在地区的语言没有包含在 MDN 中，你可以联系 Pontoon 管理员来启用。见创建新的 MDN 本地化。

+ +

MDN 上的内容

+ +

指 MDN 页面中的主体内容，包含参考、指南和教程等文章。可以使用 MDN 内建的翻译接口来翻译这些文章。如果你所在地区的语言没有包含在该接口所支持的语言列表中，可参考创建新的 MDN 本地化来了解如何操作。

+ +

宏字符串

+ +

这些字符串由宏模板产生，以创建导航、消息或某些预定义的结构。因为修改模板可能会对已经使用该模板的所有页面产生影响，所以每次修改模板都需要通过提交一个 pull request 并经过评审。

+ +

以下页面提供了 MDN 上本地化的更多信息：

+ +

{{LandingPageListSubpages}}

+ +

MDN 上的本地化社区

+ +

MDN 上的本地化活动由两个主体共同完成：独立的个人和一起工作的本地化小组，后者可能是一个更大的 Mozilla 本地化社区的一部分。MDN 上的本地化项目则由本地化带头人所领导。

+ + + +

中文翻译术语表和翻译规范

+ +

这篇文章列出了翻译中会遇到的一些术语以及翻译时推荐遵守的规范，推荐阅读：

+ +

翻译术语表和翻译规范

+ +

本地化相关的工具

+ +

这里介绍几个对你的本地化工作非常有用的工具：

+ +
+
Pontoon
+
用于多个 Mozilla 项目中的字符串的翻译，包括 MDN 用户界面和 Firefox 用户界面。
+
Transvision
+
由 Mozilla 法国社区提供的一个工具。它可以搜索某个英文在 Mozilla 代码中所有出现的地方，并列出针对目标语言的所有翻译。当需要确定某个单词或短语如何翻译更好时很有用。
+
+ +

参阅

+ + diff --git a/files/zh-cn/mdn/contribute/localize/localization_projects/index.html b/files/zh-cn/mdn/contribute/localize/localization_projects/index.html new file mode 100644 index 0000000000..96cf43b145 --- /dev/null +++ b/files/zh-cn/mdn/contribute/localize/localization_projects/index.html @@ -0,0 +1,49 @@ +--- +title: 本地化项目 +slug: MDN/Contribute/Localize/Localization_projects +tags: + - MDN元信息 + - 参考 + - 国际化 + - 本地化 + - 社区 +translation_of: MDN/Contribute/Localize/Localization_projects +--- +
{{MDNSidebar}}
+ +

所有在 MDN 上的本地化及翻译工作都是由我们了不起的社区志愿者们完成的。这篇文章列出了 MDN 上“中文(简体)”本地化项目的带头人以及其他贡献者们。

+ +

比起普通的贡献者，每个本地化项目的带头人都拥有下面这些特点：他们对 MDN 这个平台比较了解；他们投入 MDN 本地化的时间和精力也比其他贡献者多；他们会有一些其他贡献者没有的编辑权限，比如移动页面，比如修改某些特殊页面的内容；他们会和 MDN 的管理员进行邮件往来。

+ +
+

每个参与“中文(简体)”本地化的贡献者都应该自觉的把自己的名字添加到下面的表格中（会自动同步到本文档的英文页面中去），并在个人详情页完善好自己的个人信息，以便其他人联系。

+
+ + + + + + + + + + + + + + + + +
本地化语言本地化带头人其他贡献者们备注
+

中文 (简体)

+ 		+
{{userlink("ziyunfei")}}
+ 		+
{{userlink("Terry.Qiao")}}, {{userlink("iwo")}}, {{userlink("du.wei")}}, {{userlink("xcffl")}}, {{userlink("c_king")}}, {{userlink("yan")}}, {{userlink("shengyouxiao")}}, {{userlink("sunnylost")}}, {{userlink("Joyce")}}, {{userlink("Chajn")}}, {{userlink("sagitattoo")}}, {{userlink("ma3r")}}, {{userlink("hyspace")}}, {{userlink("TimZhao")}}, {{userlink("drygin")}}, {{userlink("zhangyaochun1987")}}, {{userlink("donghao526")}}, {{userlink("jtyjty99999")}}, {{userlink("Nightingale")}}, {{userlink("bingguo")}}, {{userlink("fishenal")}}, {{userlink("wanglingzhi")}}, {{userlink("Meteormatt")}}, {{userlink("Darrel.Hsu")}}, {{userlink("aztack")}}, {{userlink("smith_zhong")}}, {{userlink("fatbigbright")}}, {{userlink("manjun.han")}}, {{userlink("stoprunning3")}}, {{userlink("Kennyluck")}}, {{userlink("Technommy")}}, {{userlink("Will_Chen")}}, {{userlink("Jimmie_Felidae")}}, {{userlink("alimon")}}, {{userlink("cagen53070830")}}, {{userlink("crazybullet")}}, {{userlink("princetoad@gmail.com")}}, {{userlink("xiaoxiong")}}, {{userlink("zbinlin")}}, {{userlink("liminjun")}}, {{userlink("Jack_No1")}}, {{userlink("endlesswind")}}, {{userlink("evantre")}}, {{userlink("wanglong")}}, {{userlink("wangming")}}, {{userlink("Elvis_7")}}, {{userlink("anjianshi")}}, {{userlink("xuxun")}}, {{userlink("RobberPhex")}}, {{userlink("YangHanlin")}}, {{userlink("chyingp")}}, {{userlink("companycy")}}, {{userlink("robsean")}}, {{userlink("Fiag")}}, {{userlink("hutuxu")}}, {{userlink("jessiecaisme")}}, {{userlink("sleepholic")}}, {{userlink("xuexiaocai")}}, {{userlink("ArthasTree")}}, {{userlink("Wenbin")}}, {{userlink("xupingmao")}}, {{userlink("Dx.Yang")}}, {{userlink("HeyMemo")}}, {{userlink("LieGroup")}}, {{userlink("amibug")}}, {{userlink("gqqnbig")}}, {{userlink("lilyh")}}, {{userlink("sunorry")}}, {{userlink("Kasuganosora")}}, {{userlink("LinusYu")}}, {{userlink("Maple-Jan")}}, {{userlink("ZhangJianxiang")}}, {{userlink("bowen-shi")}}, {{userlink("figure7")}}, {{userlink("qiumaoyuan")}}, {{userlink("sonicview")}}, {{userlink("zekai.zheng")}}, {{userlink("VinceZhao")}}, {{userlink("coolfire")}}, {{userlink("ericchan1336")}}, {{userlink("jingyu9575")}}, {{userlink("jiraiya")}}, {{userlink("fskuok")}}, {{userlink("jpuncle")}}, {{userlink("reygreen1")}}, {{userlink("yanhaijing1234")}}, {{userlink("yfdyh000")}}, {{userlink("DaoG")}}, {{userlink("Josephok")}}, {{userlink("Othella")}}, {{userlink("aihua")}}, {{userlink("guoyunhebrave")}}, {{userlink("hxl")}}, {{userlink("james.li")}}, {{userlink("jedmeng")}}, {{userlink("ndon")}}, {{userlink("yisi")}}, {{userlink("ReyCG")}}, {{userlink("smartkid")}}, {{userlink("OlingCat")}}, {{userlink("Breezewish")}}, {{userlink("iakuf")}}, {{userlink("ccForward")}}, {{userlink("Jone_Casper")}}, {{userlink("jasonworg")}}, {{userlink("NIGHTEAGLE")}}, {{userlink("saintwinkle")}}, {{userlink("psychebb")}}, {{userlink("zorceta")}}, {{userlink("Light1980")}}, {{userlink("Gaohaoyang")}}, {{userlink("Dolphin_Wood")}}, {{userlink("nyx2014")}}, {{userlink("licop")}}, {{userlink(" qianjiahao")}}, {{userlink("charlie")}}, {{userlink("kun.yan")}}, {{userlink("Jacksunwei")}}, {{userlink("FredWe")}}, {{userlink("lukywong")}}, {{userlink("lttxzmj")}}, {{userlink("pantao")}}, {{userlink("Serifx")}}, {{userlink("kangmingxuan")}}, {{userlink("Ende93")}}, {{userlink("MarxJiao")}}, {{userlink("distums")}}, {{userlink("binggg")}}, {{userlink("Jiang-Xuan")}}, {{userlink("ArcherGrey")}}, {{userlink("johncido")}}, {{userlink("runyul")}}, {{userlink("xjr7670")}}, {{userlink("pluwen")}}, {{userlink("Lyra007")}}, {{userlink("zsxeee")}}, {{userlink("codeofjackie")}}, {{userlink("Louis-7")}}, {{userlink("Chor")}}, {{userlink("celdr")}}, {{userlink("Roronoa_Zoro")}}, {{userlink("mynull")}}, {{userlink("Lsnsh")}},  {{userlink("CharCat")}},{{userlink("guow10")}},{{userlink("Tindoc")}},{{userlink("SirnoChan")}},{{userlink("kagurakana")}},{{userlink("plusmultiply0")}},{{userlink("Adrian-Yan")}},{{userlink("Mookiepiece")}},{{userlink("cheiron")}},
+ +
{{userlink("greatofdream")}},{{userlink("lastVigo")}},{{userlink("sdutwsl")}},
+ 		+
+

如有问题讨论，请加 QQ 群 26079139 咨询带头人。

+
+
diff --git a/files/zh-cn/mdn/contribute/localize/rss_feeds/index.html b/files/zh-cn/mdn/contribute/localize/rss_feeds/index.html new file mode 100644 index 0000000000..9b7fb55d18 --- /dev/null +++ b/files/zh-cn/mdn/contribute/localize/rss_feeds/index.html @@ -0,0 +1,217 @@ +--- +title: MDN RSS 订阅源 +slug: MDN/Contribute/Localize/RSS_feeds +translation_of: MDN/Tools/Feeds +--- +
{{MDNSidebar}}

订阅你所感兴趣的本地化项目，第一时间得知文档变化。

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
本地化语言简称本地化名称订阅源地址
Arabianarعربيhttps://developer.mozilla.org/ar/docs/feeds/atom/all
Bengali (Bangladesh)bn-BDবাঙ্গালীhttps://developer.mozilla.org/bn-BD/docs/feeds/atom/all
Catalancacatalàhttps://developer.mozilla.org/ca/docs/feeds/atom/all
CzechcsČeštinahttps://developer.mozilla.org/cs/docs/feeds/atom/all
GermandeDeutschhttps://developer.mozilla.org/de/docs/feeds/atom/all
GreekelΕλληνικάhttps://developer.mozilla.org/el/docs/feeds/atom/all
Englishen-USEnglishhttps://developer.mozilla.org/en-US/docs/feeds/atom/all
SpanishesEspañolhttps://developer.mozilla.org/es/docs/feeds/atom/all
Persianfaفارسیhttps://developer.mozilla.org/fa/docs/feeds/atom/all
Finnishfisuomihttps://developer.mozilla.org/fi/docs/feeds/atom/all
FrenchfrFrançaishttps://developer.mozilla.org/fr/docs/feeds/atom/all
Frisianfy-NLFryskhttps://developer.mozilla.org/fy-NL/docs/feeds/atom/all
Georgian (Ireland)ga-IEGaeilge (Éire)https://developer.mozilla.org/ga-IE/docs/feeds/atom/all
Hebrewheעבריתhttps://developer.mozilla.org/he/docs/feeds/atom/all
CroatianhrHrvatskihttps://developer.mozilla.org/hr/docs/feeds/atom/all
HungarianhuMagyarhttps://developer.mozilla.org/hu/docs/feeds/atom/all
IndonesianidBahasa Indonesiahttps://developer.mozilla.org/id/docs/feeds/atom/all
ItalianitItalianohttps://developer.mozilla.org/it/docs/feeds/atom/all
Japaneseja日本語https://developer.mozilla.org/ja/docs/feeds/atom/all
Georgiankaქართულიhttps://developer.mozilla.org/ka/docs/feeds/atom/all
Koreanko한국어https://developer.mozilla.org/ko/docs/feeds/atom/all
DutchnlNederlandshttps://developer.mozilla.org/nl/docs/feeds/atom/all
PolishplPolskihttps://developer.mozilla.org/pl/docs/feeds/atom/all
Portuguese (Brazil)pt-BRPortuguês (do Brasil)https://developer.mozilla.org/pt-BR/docs/feeds/atom/all
Portuguese (Europe)pt-PTPortuguês (Europeu)https://developer.mozilla.org/pt-PT/docs/feeds/atom/all
Romanianroromânăhttps://developer.mozilla.org/ro/docs/feeds/atom/all
RussianruРусскийhttps://developer.mozilla.org/ru/docs/feeds/atom/all
AlbaniansqShqiphttps://developer.mozilla.org/sq/docs/feeds/atom/all
Thaithไทยhttps://developer.mozilla.org/th/docs/feeds/atom/all
TurkishtrTürkçehttps://developer.mozilla.org/tr/docs/feeds/atom/all
VietnameseviTiếng Việthttps://developer.mozilla.org/vi/docs/feeds/atom/all
Chinese (Simplified)zh-CN中文 (简体)https://developer.mozilla.org/zh-CN/docs/feeds/atom/all
Chinese (Traditional)zh-TW中文 (繁體)https://developer.mozilla.org/zh-TW/docs/feeds/atom/all
+

如果你想要更灵活的自定义所订阅的消息，请查看订阅源一文。

diff --git a/files/zh-cn/mdn/contribute/localize/starting_a_localization/index.html b/files/zh-cn/mdn/contribute/localize/starting_a_localization/index.html new file mode 100644 index 0000000000..56f977a6b2 --- /dev/null +++ b/files/zh-cn/mdn/contribute/localize/starting_a_localization/index.html @@ -0,0 +1,65 @@ +--- +title: Starting a new MDN localization +slug: MDN/Contribute/Localize/Starting_a_localization +tags: + - 未翻译 +translation_of: MDN/Contribute/Localize/Starting_a_localization +--- +
{{MDNSidebar}}
+ +

If your language doesn't already have a localization project on MDN, and you have the time and the enthusiasm to do so, you should consider starting a new one. This article is a guide to how to go about starting a localization project.

+ +

Getting started

+ +

If you'd like to start a localization project to translate MDN into your language, here are the steps you need to follow to get up and running.

+ +
    +
  1. First, check to see if there's already a localization for that language.
    2. +
  2. Contact your locale's Mozilla l10n team and let them know that you want to start it.
    3. +
  3. Sign up to our Mailing Lists and head to the #mdn IRC channel on irc.mozilla.org.
    4. +
  4. Contact the MDN administration team to let them know you're starting a new localization. You don't need their permission or anything, but we likes to know who you are. Let us know a little bit about you and which locale you're planning to start work on.
    5. +
  5. Add a row for your language to the list of localization projects, and include anyone else who is planning to work on it.
    6. +
  6. Create a bug in Bugzilla requesting that your language be added to the list of languages supported by MDN. This bug should be in the "Mozilla Developer Network" > "Localization" category. It will be automatically assigned to the correct person. This is needed so that your language shows up in the list of languages to choose from on the site; until this is done, you won't be able to continue.
    7. +
  7. Wait while the MDN team handles your request. If your bug isn't responded to within three or four days, please add a comment to the bug asking for an "ETA" for completion.
    8. +
  8. Once the locale has been added to MDN, you can use the Verbatim tool to translate the user interface strings for the site, and you can begin translating articles on the wiki. While translating the site's strings in Verbatim isn't required, it does add a nice touch to have the user interface presented in your language.
    9. +
+ +

Organizing a localization project

+ +

There are lots of great tips from various existing translation teams; you should feel free to adopt any of these ideas you choose. In addition, please feel free to add your own suggestions as well. See this template in the Spanish wiki for an example.

+ + + +

To find help with your project, be sure to ask around on the dev-mdc mailing list, the #devmo IRC channel, and other MDN-related discussion areas. See "Join the MDN community" for pointers to community discussion channels that will help you find others interested in joining your localization team.

+ +

You may also be able to find others interested in helping you by attending local Web development events, at your local hacker space, and the like. Be creative!

+ +

Localization look and feel

+ +

The basic structure of each of the localizations of MDN should be essentially the same. In general, you should try to maintain the same hierarchy of pages, so that each page on each language corresponds to a similar page in each locale.

+ +

You are welcome to link to external local pages, write your own articles, and translate everything from the English wiki. If you do decide to write your own articles, it would be helpful if you could provide an English translation for the English wiki so it can then get translated into all of the other localized wikis.

+ +

Adding local resources you should keep a neutral point of view; that is, you shouldn't promote a particular perspective, and should instead simply provide the facts as best as possible (see information about the NPOV rule on Wikipedia). You should not link to commercial sites (like paid courses, web design companies, etc.). You should promote open standards and cross-browser compatibility over closed or proprietary methods wherever possible.

+ +
+

Note: Team leads are encouraged to monitor their locale's content for spam and other inappropriate materials and take steps to get them removed or corrected.

+
+ +

Policy

+ +

All materials created and translated for the MDN should follow our Copyright and Licensing Policies.

+ +

If you encounter problems of any sort—technical, policy, or other—please contact the MDN admin team.

+ +

See also

+ + diff --git a/files/zh-cn/mdn/contribute/localize/translating_pages/index.html b/files/zh-cn/mdn/contribute/localize/translating_pages/index.html new file mode 100644 index 0000000000..4d6a915298 --- /dev/null +++ b/files/zh-cn/mdn/contribute/localize/translating_pages/index.html @@ -0,0 +1,54 @@ +--- +title: 翻译 MDN 上的页面 +slug: MDN/Contribute/Localize/Translating_pages +tags: + - MDN + - 向导 + - 国际化 + - 本地化 + - 页面翻译 +translation_of: MDN/Contribute/Localize/Translating_pages +--- +
{{MDNSidebar}}
+ +

本文是翻译 MDN 的基本指南，包括翻译的机制以及处理不同内容的技巧。

+ +

创建页面翻译

+ +

当您浏览到一个 MDN 的页面，并想要翻译成您的语言，请参照以下步骤：

+ +
    +
  1. 点击页面上的语言图标 ( {{FontAwesomeIcon("icon- language")}}) 打开语言菜单，并点击添加翻译副本，就会看到选择语言的页面。
    2. +
  2. 点击您想要翻译成的语言。翻译文章的页面会打开，页面左边是文章的原语言。
    3. +
  3. 在翻译描述下，您可以翻译标题，或者，也可以将slug翻译成目标语言。slug 是网页 URL 的最后那一部分（例如，这篇文章的“Translating_pages”）。一些语言的社区不翻译 slug，保留使用英语版本的 slug。请您对比其他 MDN 上您的语言的文章来决定一个普遍的做法。当您完成描述的翻译时，您可以点击翻译描述后的减号来隐藏它，这样下面翻译内容的部分就有更大的空间。
    4. +
  4. 在翻译内容下，翻译页面的主体内容。
    5. +
  5. 为您翻译的页面添加至少一个标签。
    6. +
  6. 当您完成时点击保存更改。
    7. +
+ +
注意： 翻译中的文章用户初始界面为英文版。如果 MDN 的本地化中您的目标语言存在的话，那么在接下来的访问翻译特定文章时，用户界面将以目标语言显示。MDN 用户界面能使用 Pontoon 来本地化。如何使用这个工具的细节参阅  使用 Pontoon 进行本地化。
+ +

编辑已有翻译

+ + + +

如果英语版本已经被更改而翻译副本还是上次更新状态，翻译中的文章视图在英语版面中显示一个源级别的不同更改。帮助您看到翻译副本中什么需要更新。

+ +

标签翻译

+ +

确保页面至少有一个标签，即使是翻译的页面。一般而言，和原始文章使用相同的标签是一个好主意。

+ +

一些标签用于搜索筛选，或者作为贡献者之间的约定。这些标签无需翻译。如果需要了解这些标签，请参看标签标准。 如果标签标准里面没有您想用的标签，您可以新建翻译了的标签来分类内容。

+ +

给本地化新手的小技巧

+ +

如果您不熟悉 MDN 的本地化，请参考以下建议：

+ + diff --git a/files/zh-cn/mdn/contribute/persona_sign-in/index.html b/files/zh-cn/mdn/contribute/persona_sign-in/index.html new file mode 100644 index 0000000000..d10ee0432f --- /dev/null +++ b/files/zh-cn/mdn/contribute/persona_sign-in/index.html @@ -0,0 +1,26 @@ +--- +title: MDN 和 Persona登录 +slug: MDN/Contribute/Persona_sign-in +translation_of: Archive/MDN/Persona_sign-ins +--- +
{{MDNSidebar}}
+

警告：我们不再提供使用 Persona 登录到 MDN 的服务。所以请您马上将 GitHub 账户关联到您的 MDN 资料以继续登录 MDN。

+
+ +

当前MDN给志愿者提供有两种身份认证方式：Mozilla Persona 和 GitHub。从 2016 年 11 月 1 日开始，我们将会把 Persona 从可选登录方式中移除。因此您必须在您的个人资料中启用 Github 身份认证以避免无法登陆到 MDN 的情况出现，您若有任何问题都可以联系 Account Help。

+ +

我们认识到这很不方便，我们也为此深感抱歉。但不幸的是， 我们不得不这样做。了解更多内容可以参见{{anch("Why is Persona being removed", "Why was Persona removed?")}}

+ +

为什么 Persona 会被移除?

+ +

Mozilla 已经关闭了 Persona 项目，而 Persona 将会于2016年11月1日起停止服务。您可以参看在 Mozilla wiki 上的文章以了解更多Mozilla关停Persona决定的信息。我们现在目前把 GitHub 作为唯一的认证方式。

+ +

Persona 何时会被移除?

+ +

我们将会在2016年11月1日禁用Persona这个身份认证方式，换句话来说，您最后能用Persona登录MDN的日子将会是2016年10月31日。我们将从现在开始，越发频繁、紧急地发布通告，以催促您在您的MDN资料中关联一个GitHub账户。请您尽快完成，以避免丢失您MDN账户上的任何数据。

+ +

MDN 会提供其他身份认证方式吗?

+ +

我们很乐意这样做，但现在还没有其他认证方式能够符合我们的要求；另外我们当前并没有将开发人员资源与其他供应商进行整合。所以目前您作为志愿者访问 MDN 的唯一方式就是在您的 MDN 资料中关联的一个 GitHub 账户。

+ +

当然请记住，您并不需要为了阅读我们的内容而登录到 MDN。但如果您有一个账户，并希望能在将来任何时候给MDN做贡献，请您一定要在2016年10月31日前添加一个Github 账户到您的个人资料里，时间越快越好。

diff --git a/files/zh-cn/mdn/editor/basics/index.html b/files/zh-cn/mdn/editor/basics/index.html new file mode 100644 index 0000000000..d6435b8282 --- /dev/null +++ b/files/zh-cn/mdn/editor/basics/index.html @@ -0,0 +1,61 @@ +--- +title: 编辑器 UI 元素 +slug: MDN/Editor/Basics +tags: + - 指南 + - 新手 + - 编辑器 +translation_of: MDN/Editor/Basics +--- +

MDN内置 WYSIWYG（所见即所得）编辑器，目的就是让编辑工作变得更加轻松。你可以轻松地在网站各处创建、编辑、修改文章或其他页面。 编辑器界面如下所示，包含八个关键区域。本指南将提供每个区域的介绍，以便您了解如何使用整个编辑环境。

+ +
+

我们不断努力改进MDN，所以有时候本指南或下面的屏幕截图可能会稍微过时。不过，我们会定期更新此文档，以避免其无法使用。

+
+ +

Screenshot of the editor UI (August 2017) with each section labeled

+ +

上图所示的编辑器各个UI区域已罗列在下表中，点击下面的链接来了解每个部分。

+ + + +

修订注释

+ +

我们强烈建议你每次编辑完成后要附上对修改的注释（修订注释）。这些注释将被保存到页面的修订历史中，就像这个修订看板。这将有助于向复核你修改的人提供解释说明。想要添加修订意见也很简单，只要在发布之前，在修订意见框中填入注释即可。

+ +

这么做的好处：

+ + + +

复核请求

+ +

MDN社区使用复核来追踪和提高MDN内容的质量。通过在文章页面上设置特定标志来表示这篇文章需要审查复核。你可以在 MDN 使用指南中了解更多关于技术复核和文法复核的知识。

+ +

想要申请对你所做的文章进行复核，只需勾选对应复核类型前面的复选框即可。任何对技术方面的修改，都应申请技术复核，当然，如果你申请文法复核，想找个人来检查你的写作和样式，那也是极好的。

+ +

当申请复核后，文章将会被添加到需要技术复核或需要文法复核列表，但这并不能保证会立马有人来复核你的文章。对于技术复核，最好直接联系相关技术领域的学科专家。对于编辑评论，您可以在 MDN 论坛中发帖以请求其他人来复核你的更改。

+ +

 

+ +

在勾选申请复核之后，请务必点击一下发布按钮，这样才能提交复核请求。

+ +

参阅

+ + + + diff --git a/files/zh-cn/mdn/editor/basics/page_controls/index.html b/files/zh-cn/mdn/editor/basics/page_controls/index.html new file mode 100644 index 0000000000..48175fd7c8 --- /dev/null +++ b/files/zh-cn/mdn/editor/basics/page_controls/index.html @@ -0,0 +1,37 @@ +--- +title: MDN 编辑器页面控件 +slug: MDN/Editor/Basics/Page_controls +tags: + - 指南 + - 编辑器 +translation_of: MDN/Editor/Basics/Page_controls +--- +
{{MDNSidebar}}
+ +

页面控件由对整个页面起作用的按钮组成，为了减少多余的滚动，页面控件在编辑器的顶部和底部都可见。一共有四个页面控制按钮：

+ +
+

如果你编写的页面符合 MDN 的要求，而编辑器却不能保存成功，你可以电子邮件联系开发团队寻求帮助。

+
+ +
+
发布并继续编辑
+
点击这个按钮，会在不关闭编辑器的前提下保存并发布页面。这样你就可以定期保存编辑工作，在页面修订历史中创建存档，这些存档说不定以后会用到。在创建新页面时这个按钮是不可用。查看修订注释框以了解如何在保存文章时添加修订注释。
+
发布
+
点击该按钮，将保存并发布你的文章，同时关闭编辑器，浏览器跳转到标准模式下的页面。查看修订注释框以了解如何在保存文章时添加修订注释。
+
预览
+
点击这个按钮将打开新的页面或窗口，以发布的样式展示编辑器中的内容，其中的宏指令和模板都如实展示。值得注意的是，此时你的文章并没有被保存。这个按钮的作用，就是在文章发布前检查实际页面效果的，如果出现脚本错误，请参阅预览页面时排除脚本错误。
+
+
+

警告: Currently some macros and templates don't execute properly in Preview-mode, leaving the Preview page missing some of its content (such as sidebars), and thus with somewhat distorted page layout; i.e. not totally WYSIWYG. Further, if SCAYT is enabled (and possibly if the page contains certain valid macros or templates), Preview mode may still give a scripting error.

+
+
+

+ 放弃
+
这个按钮的功能就是取消编辑，放弃所有未曾保存的更改。页面将会跳转回上个页面。
+
+
+

警告: Occasionally Discard can malfunction and start acting more like a partial "discard," undoing many of your changes without exiting the editor. If this happens to you, you should save, exit, and re-enter the editor.

+
+
+
diff --git a/files/zh-cn/mdn/editor/basics/page_info/index.html b/files/zh-cn/mdn/editor/basics/page_info/index.html new file mode 100644 index 0000000000..54be30c0cf --- /dev/null +++ b/files/zh-cn/mdn/editor/basics/page_info/index.html @@ -0,0 +1,47 @@ +--- +title: 编辑器 UI 的页面信息区域 +slug: MDN/Editor/Basics/Page_info +tags: + - 指南 + - 新手 + - 编辑器 +translation_of: MDN/Editor/Basics/Page_info +--- +
{{MDNSidebar}}
+ +

页面信息区域包含了本页面的信息，但也可以扩展开来以提供额外的页面控件。

+ +

现有页面

+ +

默认情况下，编辑现有页面时，页面信息区域会显示页面标题。

+ +

你可以点击编辑标题和属性按钮来打开更多页面控件。如下图：

+ +

Page info fields for an existing article

+ +

这里可以对下列内容进行设置：

+ +
+
标题
+
标题会显示在浏览器的标题栏（或标签栏）、面包屑导航栏中，以及文章的顶部。但它不会出现在页面的URL中。
+
目录
+
指定文章中次级标题的级别深度，次级标题会自动生成目录展示在页面上。默认情况下，这里填的是从 <h2> 到 <h4> ，也就是有三级深度。当然，你也可以根据需要自由选择，比如，“没有目录”（不显示目录，如登陆页），或者“所有级别”。
+
最大渲染时长
+
确定页面自动刷新的频率。在绝大多数情况下，设置为零。
+
查找
+
对于已本地化的页面，这个字段可以帮助重新关联变成“孤儿”的页面（脱离英文原版的页面）。对于英语页面来讲，这个字段用处不大，因为，英语是 MDN 的官方语言。
+
+ +

新页面

+ +

如果你拥有创建页面权限，你就可以创建新的页面了。查看如何创建和编辑页面你可以了解到更多这方面的知识。对于创建新页面，页面信息区域看起来如下图：

+ +

Page info fields for a new page

+ +

你同样可以设置标题和目录，还可以设置页面的别名，别名用于页面URL地址的最后一个部分。以只读状态显示的父地址是页面URL中网站根节点之后的部分。当你在标题输入框中输入文字的时候，别名输入框会自动生成对应的内容，其中会用下划线替代标题中的空格。

+ +
+

值得注意的是，我们推荐使用更短的别名和描述更清晰的标题。举例来说，一个关于编辑器页面控件的页面，应该取一个例如：“MDN 编辑器页面控件”的标题，而它的 URL 应该写成“MDN/Contribute/Editor/Basics/Page_controls”，其中“Page_controls”正是这个页面的别名。

+
+ +

 

diff --git a/files/zh-cn/mdn/editor/edit_box/index.html b/files/zh-cn/mdn/editor/edit_box/index.html new file mode 100644 index 0000000000..de23593df5 --- /dev/null +++ b/files/zh-cn/mdn/editor/edit_box/index.html @@ -0,0 +1,145 @@ +--- +title: MDN 编辑器的编辑框 +slug: MDN/Editor/Edit_box +tags: + - MDN + - 快捷键 + - 编辑器 + - 编辑框 +translation_of: MDN/Editor/Keyboard_shortcuts +--- +

编辑框正是你写文章的地方，在编辑框中点击右键会根据你点击的位置打开对应的快捷菜单，比如：在表格中点击右键会弹出与编辑表格相关的菜单，在列表中右击就会弹出与列表相关的菜单。

+ +

默认情况下，编辑器会用自己的右键菜单替代浏览器默认的菜单，如果你一定要打开浏览器的默认菜单（比如，使用火狐的拼写检查功能），你可以按住 Shift 或 Control 键（ Mac 的 Command 键），再点击右键。

+ +

快捷键

+ +

丰富而便捷的键盘快捷键能让你在编辑时，手不离开键盘。此处所列的是 Windows 或 Linux 系统下的快捷键，如果是 Mac，只需将 Control 替换为 Command 即可。

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
快捷键描述
Ctrl + A全选
Ctrl + C复制
Ctrl + V粘贴
Ctrl + Shift + V粘贴为纯文本
Ctrl + X剪切
Ctrl + Z撤销
Ctrl + Y重做
Ctrl + K打开链接编辑器/添加新链接
Ctrl + Shift + K移除光标所在位置的链接
Ctrl + B加粗
Ctrl + I斜体
Ctrl + O切换 <code> 样式
Ctrl + Shift + O +

切换源码编辑模式

+ +
使用源码编辑模式时请格外小心，你必须按照既定的格式来编辑。请仔细阅读编辑器源码模式指南，该指南详细介绍了如何使用源码模式，以及各项注意事项。
+
Ctrl + P切换当前区域的 <pre> 样式
Ctrl + U下划线
Ctrl + S保存但不关闭编辑器
Ctrl + Shift + S保存并关闭编辑器
Ctrl + 0移除选中区域的样式（此处是数字“0”，不是字母“O”）
Ctrl + 2  至  Ctrl + 6切换标题的级别（从 2 到 6 ），一级标题仅可供文章头部的页面标题使用。
Ctrl + Shift + L在无序列表、有序列表和普通段落格式之间切换。
Tab在缩进模式下增加缩进级别，否则插入两个空格作为制表符。在表格内部，将光标移动到下一个单元格，或者在没有下一个单元格的情况下插入新行。如果光标当前位于页面标题或某个标题中，则光标跳转到下一段。
Shift + Tab在缩进模式下降低缩进水平。在表格内部，跳到前一个单元格，如果前面没有单元格，则插入新行。如果光标当前位于页面标题或某个标题中，则光标跳转到下一段。
Shift + Space插入空格(&nbsp;)
Shift + Enter +

跳出当前区域。例如，如果你当前正在某个 <pre> 区域，按下 Shift + Enter ，你将跳出这个区域，回到文章正文。

+ +
+

当前不可用，详见：{{bug('780055')}}。

+
+
+ +

参阅

+ + + +
{{MDNSidebar}}
diff --git a/files/zh-cn/mdn/editor/index.html b/files/zh-cn/mdn/editor/index.html new file mode 100644 index 0000000000..02f71ade9f --- /dev/null +++ b/files/zh-cn/mdn/editor/index.html @@ -0,0 +1,20 @@ +--- +title: MDN 编辑指南 +slug: MDN/Editor +tags: + - MDN + - 指南 + - 文档 +translation_of: MDN/Editor +--- +
{{MDNSidebar}}
+ +
{{IncludeSubnav("/zh-CN/docs/MDN")}}
+ +

MDN Web Docs wiki 文档系统的 WYSIWYG (所见即所得)编辑器让贡献新的内容变得简单。这篇指南将告诉你如何使用它，借此来提高你的生产力。在编辑或新建新的页面之前，请阅读并遵守 Mozilla 条款。

+ +

MDN 样式指南 除了告诉你如何进行格式化和样式化内容本身外，还包括我们推荐的语法和拼写规则。

+ +

{{LandingPageListSubpages}}

+ +

{{EditorGuideQuicklinks}}

diff --git a/files/zh-cn/mdn/editor/source_mode/index.html b/files/zh-cn/mdn/editor/source_mode/index.html new file mode 100644 index 0000000000..660f88267e --- /dev/null +++ b/files/zh-cn/mdn/editor/source_mode/index.html @@ -0,0 +1,121 @@ +--- +title: 源码模式 +slug: MDN/Editor/Source_mode +translation_of: MDN/Editor/Source_mode +--- +
{{MDNSidebar}}
+ +

MDN 编辑器有个重要的按键，用来切换到源码编辑模式。此模式下，你可以看到正在编辑的文章的 HTML。这个指引使你了解 MDN wiki 源码编辑模式能做什么，什么应该做，但更为重要的是，什么是不应该做的。

+ +
+

在你考虑使用源码模式之前，请注意我们强烈建议你不要使用源码模式。如果您只是为了强行符合我们的样式规范，你不应该去使用源码模式。我们确实有一些需求不启用源码模式无法做到。记得查看{{anch("Warnings and caveats")}}。

+
+ +

启用源码模式

+ +

启用源码模式很简单。在编辑器工具栏的左上角，点击“Source”或“原始碼”按钮。

+ +

Partial screenshot of the editor toolbar, with the Source mode button highlighted

+ +

对于格式化、图片之类的功能，很可能源码模式没有 WYSIWYG (所见即所得)好用，因为你可能需要滚动很远才能找到编辑器中相关源码的位置。

+ +

警告

+ +

综上所述，你应该极少会需要用到源码模式。只有一些极个别的事情才必须由修改源码实现。最终，我们会更新编辑器界面，为你展示你的修改。

+ +

MDN贡献者指南中未明确描述的所有内容均不应添加到源代码中。这意味着：

+ + + +

源码模式下编辑

+ +

一旦启用源码模式，你将可以编辑 wiki 页面的原始 HTML。虽不受编辑器约束，您应竭尽所能保持您的工作与样式指南一致，并且可以安全可靠的工作。

+ +
+

通常，您应该是在源码模式中做一些短暂的调整，而不是长时间的撰写页面。

+
+ +

不幸的是，Tab 键在源码模式中无法使用，请输入两个空格来代替。

+ +

若您使用 MDN 不允许的 HTML 元素和属性，它们会在你保存时直接被移除。此外，文档还将重新被格式化，以使之符合预期。

+ +

合理使用源码模式

+ +

在一些个别的情况下，使用源码是唯一能遵循MDN格式规范的方式。这一节涵盖了这些情况，并说明了如何在不破坏其他东西的前提下，正确使用这些功能。

+ +

在示例代码中高亮代码行

+ +

在用工具栏的块组中的PRE或Syntax Highlighter建立的示例代码片段块中，你会希望让某几行代码更引人注目一些。唯一实现这种事项的方式是开启源码模式，找到包含此部分代码的{{HTMLElement("pre")}}块，然后编辑<pre>标签的{{htmlattrxref("class")}}属性，加上一个highlight组件，像下面这种格式：

+ + + +

例如，如果现在的标签为<pre class="brush: js">，然后你想往第4行和第7行加个高亮，你可把它改为<pre class="brush:js; highlight:[4,7]">。

+ +

我们看个更复杂的示例：

+ + + + + + + + + + + + + + +
高亮前高亮后
+ 
+var canvas = document.getElementById("canvas");
+var ctx = canvas.getContext("2d");
+
+var path1 = new Path2D();
+path1.rect(10, 10, 100, 100);
+
+var path2 = new Path2D(path1);
+path2.moveTo(220, 60);
+path2.arc(170, 60, 50, 0, 2 * Math.PI);
+
+ctx.stroke(path2);
+
+ +

这里的{{HTMLElement("pre")}}标签为：<pre class="brush: js">

+ 		+ 
+var canvas = document.getElementById("canvas");
+var ctx = canvas.getContext("2d");
+
+var path1 = new Path2D();
+path1.rect(10, 10, 100, 100);
+
+var path2 = new Path2D(path1);
+path2.moveTo(220, 60);
+path2.arc(170, 60, 50, 0, 2 * Math.PI);
+
+ctx.stroke(path2);
+ +

然后这里的<pre>标签已经改为了：<pre class="brush: js; highlight:[4,7]">

+
+ +

没有对应工具栏按钮的样式

+ +

MDN上我们用的一些样式通过通常的用户界面是无法实现的。好消息是，这些不是很常见。示例如：

+ + diff --git a/files/zh-cn/mdn/guidelines/content_blocks/index.html b/files/zh-cn/mdn/guidelines/content_blocks/index.html new file mode 100644 index 0000000000..cd98951641 --- /dev/null +++ b/files/zh-cn/mdn/guidelines/content_blocks/index.html @@ -0,0 +1,44 @@ +--- +title: 内容块 +slug: MDN/Guidelines/Content_blocks +translation_of: MDN/Guidelines/CSS_style_guide +--- +
{{MDNSidebar}}
+

This pages lists reusable content blocks.

+
+

Card-grid

+

Allows to have a couple of cards next to each other to call out specific contents or can be used for a call to action. CSS class: .card-grid (L 751 - 824 in CustomCSS).

+ +

Two columns

+

Two columns seperated with a thick grey border. Often used on landing pages. CSS class: .topicpage-table (L 830 - 837 & 82-93 in CustomCSS).

+
+
+ Column 1
+
+ Column 2
+
+

 

+

Equal column heights

+

Used on the Firefox OS landing page to wrap columns that should all be the same height. CSS class .equalColumnHeights (L 25 - 38 in CustomCSS).

+
+
+ Some text
+ And a new line
+  
+
+ Some more text
+
+
+ here
+
+

 

diff --git a/files/zh-cn/mdn/guidelines/css_style_guide/index.html b/files/zh-cn/mdn/guidelines/css_style_guide/index.html new file mode 100644 index 0000000000..ee85c19b97 --- /dev/null +++ b/files/zh-cn/mdn/guidelines/css_style_guide/index.html @@ -0,0 +1,841 @@ +--- +title: MDN样式指南 +slug: MDN/Guidelines/CSS_style_guide +translation_of: MDN/Guidelines/CSS_style_guide +--- +

MDN有许多内置的全局样式，可以在设置文章样式和布局文章时使用，本文是可用类以及何时使用它们的指南。其中一些样式可以通过MDN编辑器的工具栏访问。在这种情况下，我们将在样式标题下包含短语“编辑工具栏”，以及相关工具栏按钮的图像。

+ +

请注意，这些样式的开发是为了涵盖在设置文章内容样式时出现的最常见情况，并且只要可能，您就应该尝试使用可用的类；与标准内容的外观相差太大不利于一致性和可读性。如果你觉得你的页面绝对需要某种特殊的定制样式，你应该首先在MDN讨论论坛中提出这个主题。

+ +
+

注意：如果要搜索MDN上使用给定类的位置，可以使用表单的URL执行此操作

+ +

https://developer.mozilla.org/en-US/search?locale=en-US&css_classnames=desired-css-class.   例如，要查找使用卡片网格布局的页面，请尝试URLhttps://wiki.developer.mozilla.org/en-US/search?locale=*&css_classnames=card-grid.

+
+ +
+

重要提示: 本指南不完整。有关如何帮助我们完成此指南的信息，请参阅“更新此指南”。

+
+ +

内联样式

+ +

本节列出MDN上样式内容块可用的内联样式。

+ +

.button

+ +

MDN提供任何button样式。通常用于设置链接样式（出于安全原因，HTMLElement（“button”）元素从文章源代码中剥离。）

+ +

下载源代码

+ +
+

Example syntax

+ +
<a href="https://github.com/mdn/simple-web-worker/archive/gh-pages.zip" class="button">Download source code</a>
+
+ +

.external-icon and .ignore-external

+ +

指向MDN外部内容的链接会自动设置格式，以便将类外部图标添加到这些链接中，从而创建一个图标，指示它们离开站点。但是，在某些情况下，此图标是不需要的，并且会干扰其他样式。可以通过将忽略外部类添加到链接中来删除它。

+ +
+

注意: 大多数时候，我们不想用这些。外部图标将自动添加，以帮助防止用户在不知不觉中离开MDN。唯一通常可以接受的用例是指向特定于MDN的域或子域的链接，例如我们用于示例代码或其他服务的那些域或子域。

+
+ +

Link to MDN
+ Link away from MDN
+ Link away from MDN with ignore-external

+ +
+

Example syntax

+ +
<a href="/">Link to MDN</a>
+<a href="http://wikipedia.org">Link away from MDN</a>
+<a href="http://wikipedia.org" class="ignore-external">Link away from MDN with <code>ignore-external</code></a>
+
+ + + +

这是一个类，用于设置词汇表链接的样式，以使它们在页面上不那么显眼。这个类是使用KumaScript宏添加的，如常用宏中所述，因此不会手动插入。

+ +
+

Example macro syntax

+ +

\{{Glossary("HTML")}}

+
+ +

.hidden

+ +

允许您隐藏wiki文章中的内容，但可以在编辑器中查看。通常，这用于向创建实时代码示例的脚本提供HTML、CSS和JavaScript，而只向读者显示相关语言。

+ +
+

Example syntax

+ +
<h4 id="Hidden_Code_Sample" name="Hidden_Code_Sample">Hidden code Sample</h4>
+
+<div class="hidden">
+<h5 id="HTML">HTML</h5>
+
+<pre class="brush: html;">
+&lt;button id="test"&gt; Click me &lt;/button&gt;
+
+<h5 id="CSS">CSS</h5>
+
+<pre class="brush: css;">
+button {
+    background-color: #a00;
+    color:#fff;
+    font-size: 20px;
+}
+</pre>
+</div>
+
+<h5 id="JavaScript_Content">JavaScript Content</h5>
+
+<pre class="brush: js;">
+document.getElementById("test").addEventListener("click", works);
+function works() {
+    window.alert("you clicked it!");
+}
+</pre>
+
+<p>\{{EmbedLiveSample("Hidden_Code_Sample")}}</p>
+
+ +

Hidden code Sample

+ + + +
JavaScript
+ +
document.getElementById("test").addEventListener("click", works);
+function works(){
+    window.alert("you clicked it!");
+}
+
+ +

{{EmbedLiveSample("Hidden_Code_Sample", "100%", 150)}}

+
+ +

.seoSummary

+ +

这是一个对页面内容没有可见影响的类，但是，如果该类应用于元素（通常是span），KumaScript将使用元素的内容创建描述meta标记。它们提供了一个简短的描述，可用于搜索引擎和分享网站，如Facebook和Twitter。这个类可以通过MDN编辑器WYSIWYG样式下拉列表中的“SEO摘要”选项获得。

+ +

+ +
+
+

Note: If .seoSummary is not explicitly specified on a page, the first paragraph is automatically set as the SEO summary: there is no need to use this on most pages.

+
+ +

The final page display won't show any styling change, but in the editor the text that is set as the SEO summary will be marked with a dotted outline and a "SEO Summary" label", as shown below:

+ +

+ +

The below examples are taken from the Mozilla Add-ons page.

+ +

Example syntax

+ +
<p>
+  <span class="seoSummary">Add-ons add new functionality to <a href="/en-US/docs/Mozilla/Gecko">Gecko</a>-based applications such as Firefox, SeaMonkey, and Thunderbird.</span>
+  There are two main types of add-on: <a href="#Extensions">Extensions</a> add new features to the application, while <a href="#Themes">Themes</a> modify the application's user interface.
+</p>
+ +

Example of the generated {{HTMLElement("meta")}} elements

+ +
<meta property="og:description" content="Add-ons add new functionality to Gecko -based applications such as Firefox, SeaMonkey, and Thunderbird.">
+<meta name="description" content="Add-ons add new functionality to Gecko -based applications such as Firefox, SeaMonkey, and Thunderbird.">
+<meta name="twitter:description" content="Add-ons add new functionality to Gecko -based applications such as Firefox, SeaMonkey, and Thunderbird.">
+ +

Example of how Facebook uses it

+ +

SEOSummary as it is used by Facebook

+
+ +
+

注意: 这与“.summary”类不同，后者创建了一个特殊的“关于此页”样式的模糊框。该类不设置搜索引擎使用的SEO摘要或MDN用于生成工具提示和自动生成列出子页面的菜单的宏。

+
+ +

块级样式

+ +

本节列出MDN上样式内容块可用的块级样式。

+ +

.callout-box

+ +

允许您创建一个右浮动框，用于包含要突出显示的标注或相关信息。这是一个示例内容

+ +

Mixtape distillery biodiesel pop-up Austin chambray. Fingerstache YOLO tousled, meditation four loko squid brunch single-origin coffee stumptown ethical asymmetrical polaroid Neutra hashtag beard. Mustache Godard Bushwick, Tumblr salvia +1 fixie cornhole beard wayfarers stumptown aesthetic keffiyeh lomo. Meggings lumbersexual keytar Shoreditch.

+ +
+

Example syntax

+ +
<div class="callout-box">
+  <p>This is an exciting callout</p>
+</div>
+<p>Example content to float around</p>
+<p>Mixtape distillery biodiesel pop-up Austin chambray. Fingerstache YOLO tousled, meditation four loko squid brunch single-origin coffee stumptown ethical asymmetrical polaroid Neutra hashtag beard. Mustache Godard Bushwick, Tumblr salvia +1 fixie cornhole beard wayfarers stumptown aesthetic keffiyeh lomo. Meggings lumbersexual keytar Shoreditch.</p>
+
+
+ +

.card-grid

+ +

允许您将多张卡片相邻放置，以调出特定内容或映射出多步行动要求。卡片在可用的水平空间中均匀分布；大约2-3张效果最好。

+ + + +
+

Example syntax

+ +
<ul class="card-grid">
+  <li>My card content</li>
+  <li>My second card content</li>
+  <li>My third card content</li>
+</ul>
+
+ +

.column-container

+ +

 表示特定宽度列的容器。通常与其他类一起使用，如下所示。

+ +

My first equal width column.

+ +
+
+

My second equal width column.

+
+ +
+

My third equal width column.

+
+
+ +
+

Example syntax

+ +
<div class="column-container">
+  <div class="column-4">
+    <p>My first equal width column.</p>
+  </div>
+  <div class="column-4">
+    <p>My second equal width column.</p>
+  </div>
+  <div class="column-4">
+    <p>My third equal width column.</p>
+  </div>
+</div>
+
+ +

.column-1, .column-2, .column-3 ... all the way up to .column-11

+ +

指定要由.column container包含的特定宽度的列，即列容器宽度（基于12列网格布局）的一定数量的二分之一。每对列之间都留有一个檐沟。

+ +
+
1/12
+ +
11/12
+
+ +
+
5/12
+ +
7/12
+
+ +
+
6/12
+ +
4/12
+ +
2/12
+
+ +
+

Example syntax

+ +
<div class="column-container">
+  <div class="column-1" style="background-color: yellow;">1/12</div>
+  <div class="column-11" style="background-color: lime;">11/12</div>
+</div>
+
+<div class="column-container">
+  <div class="column-5" style="background-color: yellow;">5/12</div>
+  <div class="column-7" style="background-color: lime;">7/12</div>
+</div>
+
+<div class="column-container">
+  <div class="column-6" style="background-color: yellow;">6/12</div>
+  <div class="column-4" style="background-color: lime;">4/12</div>
+  <div class="column-2" style="background-color: pink;">2/12</div>
+</div>
+
+
+ +

.column-quarter, .column-third, .column-half

+ +

指定要由.column container包含的特定宽度的列，该列是列容器宽度的特定部分。每对列之间都留有一条边沟。

+ +
+
Half
+ +
Half
+
+ +
+
Third
+ +
Third
+ +
Third
+
+ +
+
Quarter
+ +
Quarter
+ +
Quarter
+ +
Quarter
+
+ +
+

These classes are equivalents of commonly-used numerical width classes, as follows:

+ + + +

Example syntax

+ +
<div class="column-container">
+  <div class="column-half" style="background-color: yellow;">Half</div>
+  <div class="column-half" style="background-color: lime;">Half</div>
+</div>
+
+<div class="column-container">
+  <div class="column-third" style="background-color: yellow;">Third</div>
+  <div class="column-third" style="background-color: lime;">Third</div>
+  <div class="column-third" style="background-color: pink;">Third</div>
+</div>
+<div class="column-container">
+  <div class="column-quarter" style="background-color: yellow;">Quarter</div>
+  <div class="column-quarter" style="background-color: lime;">Quarter</div>
+  <div class="column-quarter" style="background-color: pink;">Quarter</div>
+  <div class="column-quarter" style="background-color: cyan;">Quarter</div>
+</div>
+
+
+ +

<details>

+ +

可以包装在一个内容块周围以隐藏该内容，而不是显示一个“详细信息”链接，单击该链接可展开/折叠其中包含的内容。您可以在本文中看到它的用法。

+ +
+

Example syntax

+ +

This is an example syntax section for {{HTMLElement("details")}} that was hidden with {{HTMLElement("details")}}. Ooooooh, how meta.

+ +
<details>
+<h4>Example syntax</h4>
+<p>This is an example syntax section for <code>.detail</code> that was hidden with <code>.detail</code>. Ooooooh, how meta.</p>
+</details>
+
+ +

.example-bad and .example-good

+ +

可以使用.example Good和.example bad类突出显示好的和坏的示例。它们通常用于表示示例代码段的<pre>块，但也可以用于其他块。

+ +
Good code example
+ +
<label for="test">Form label:</label>
+<input type="text" id="test">
+
+ +
Bad code example
+ +
<input type="text">
+
+ +
+

You should always use headings with these classes, as shown below — CSS is unable to add localized language to the page identifying whether they're good or bad so this is important for people who rely on screen readers, and people with different cultural backgrounds (green and red are not universally good and bad.)

+ +

Example syntax

+ +
<h5 id="Good_code_example">Good code example</h5>
+
+<pre class="brush: html example-good">
+  &lt;label for="test"&gt;Form label:&lt;/label&gt;
+  &lt;input type="text" id="test"&gt;
+</pre>
+
+<h5 id="Bad_code_example">Bad code example</h5>
+
+<pre class="brush: html example-bad">
+  &lt;input type="text"&gt;
+</pre>
+
+ +

.moreinfo

+ +

这个类最初被设计为提供一个链接列表以供进一步阅读，但它可以用于任何远离当前页面的信息。

+ +
+

基于JavaScript知识构建的工具

+ +
+
JavaScript frameworks
+
Developed by Google Angular.js is one of the best known frameworks.
+
Ember.js is open source and community driven.
+
JavaScript Compilers
+
Babel lets you write ES2015 and compiles to more backwards compatible code.
+
+
+ +
+

Example syntax

+ +
<div class="moreinfo">
+  <!-- content goes here -->
+</div>
+
+ +

.blockIndicator.note

+ +

将内容的一部分转换为便签框，这通常是一个有用的便签，与当前主题相切，但不直接适合信息流。

+ +
+

注意: 这就是我们通常在MDN文章中呈现注释的方式。

+
+ +
+

This is available via the "Note box" option in the MDN editor WYSIWYG styles dropdown.

+ +

Example syntax

+ +
<div class="blockIndicator note" role="complementary">
+  <p><strong>Note</strong>: This is how we usually present a note in an MDN article.</p>
+</div>
+
+ +

.pull-aside

+ +

将内容拉到一边。

+ +

有些内容会偏离主题。

+ +

有些内容不太靠边站。

+ +
+

Example Syntax

+ +
<div class="pull-right">Some content that goes off to the side.</div>
+<p>Some content that does not go off to the side.</p>
+ +

Other uses

+ +
+
Combined with the .moreinfo class.
+
+ +

Some content that does not go off to the side.

+ +

Some content that does not go off to the side.

+ +
<div class="pull-aside"><div class="moreinfo">Some content that goes off to the side.</div></div>
+<p>Some content that does not go off to the side.</p>
+<p>Some content that does not go off to the side.</p>
+
+
+ +

.summary {{Obsolete_Inline}}

+ +

为页面创建摘要框，在视觉上显示为带有额外填充的灰色框-应用于文章的开头段落（但不用于参考文章），以使其在页面上具有额外的重要性。

+ +
+

重要提示: 这与anch“.seoSummary”类不同，该类建立文本部分，搜索引擎使用该文本部分在结果列表中汇总页面，MDN使用该文本部分创建页面标题及其摘要的工具提示和菜单。这门课完全是一种视觉效果。如果希望同时使用这两个类，可以为页面建立可见和有效的摘要。

+
+ +

这是本文的开头。下面我们将讨论 puppies, giraffes, 和 dugongs.

+ +
+

This is available via the "Article Summary" option in the MDN editor WYSIWYG styles dropdown.

+ +

+ +

Example syntax

+ +
<p class="summary">This is the start of this article. Below we will talk about puppies, giraffes, and dugongs.</p>
+
+ +

.topicpage-table

+ +

创建用粗灰色边框分隔的两列。常用于登录页。这通常最适合嵌套（“div”）。注意，这两个子元素必须被赋予.section类。

+ +
+
Column 1
+ +
Column 2
+
+ +
+

Example syntax

+ +
<div class="topicpage-table">
+  <div class="section">Column 1</div>
+  <div class="section">Column 2</div>
+</div>
+
+ +

.threecolumns

+ +
+

使内容块显示在三个等宽列中。

+ +

Mixtape distillery biodiesel pop-up Austin chambray. Fingerstache YOLO tousled, meditation four loko squid brunch single-origin coffee stumptown ethical asymmetrical polaroid Neutra hashtag beard. Mustache Godard Bushwick, Tumblr salvia +1 fixie cornhole beard wayfarers stumptown aesthetic keffiyeh lomo. Meggings lumbersexual keytar Shoreditch.

+ +

Street art PBR YOLO pug, before they sold out fixie artisan blog bicycle rights beard direct trade chillwave. Fanny pack cornhole whatever, Austin single-origin coffee ethical church-key distillery fashion axe tofu farm-to-table irony tattooed Tumblr. Craft beer Thundercats Austin gentrify, wolf Echo Park asymmetrical hella sartorial.

+
+ +
+

This is available via the "Three columns" option in the MDN editor WYSIWYG styles dropdown.

+ +

+ +
+

Note: If you want to apply this to a list, then you should apply it to an outer wrapper {{HTMLElement("div")}} — if not, it gets applied to the {{HTMLElement("ul")}} element, which causes the list bullets to not display in Chrome.

+
+ +

Example syntax

+ +
<div class="threecolumns">
+  <p>Mixtape distillery biodiesel pop-up Austin chambray. Fingerstache YOLO tousled, meditation four loko squid brunch single-origin coffee stumptown ethical asymmetrical polaroid Neutra hashtag beard. Mustache Godard Bushwick, Tumblr salvia +1 fixie cornhole beard wayfarers stumptown aesthetic keffiyeh lomo. Meggings lumbersexual keytar Shoreditch.</p>
+
+  <p>Street art PBR YOLO pug, before they sold out fixie artisan blog bicycle rights beard direct trade chillwave. Fanny pack cornhole whatever, Austin single-origin coffee ethical church-key distillery fashion axe tofu farm-to-table irony tattooed Tumblr. Craft beer Thundercats Austin gentrify, wolf Echo Park asymmetrical hella sartorial.</p>
+</div>
+
+ +

.twocolumns

+ +

使内容块显示在两个等宽列中。 

+ +
+

Mixtape distillery biodiesel pop-up Austin chambray. Fingerstache YOLO tousled, meditation four loko squid brunch single-origin coffee stumptown ethical asymmetrical polaroid Neutra hashtag beard. Mustache Godard Bushwick, Tumblr salvia +1 fixie cornhole beard wayfarers stumptown aesthetic keffiyeh lomo. Meggings lumbersexual keytar Shoreditch.

+ +

Street art PBR YOLO pug, before they sold out fixie artisan blog bicycle rights beard direct trade chillwave. Fanny pack cornhole whatever, Austin single-origin coffee ethical church-key distillery fashion axe tofu farm-to-table irony tattooed Tumblr. Craft beer Thundercats Austin gentrify, wolf Echo Park asymmetrical hella sartorial.

+
+ +
+

This is available via the "Two columns" option in the MDN editor WYSIWYG styles dropdown.

+ +

+ +
+

Note: If you want to apply this to a list, then you should apply it to an outer wrapper {{HTMLElement("div")}} — if not, it gets applied to the {{HTMLElement("ul")}} element, which causes the list bullets to not display in Chrome.

+
+ +

Example syntax

+ +
<div class="twocolumns">
+  <p>Mixtape distillery biodiesel pop-up Austin chambray. Fingerstache YOLO tousled, meditation four loko squid brunch single-origin coffee stumptown ethical asymmetrical polaroid Neutra hashtag beard. Mustache Godard Bushwick, Tumblr salvia +1 fixie cornhole beard wayfarers stumptown aesthetic keffiyeh lomo. Meggings lumbersexual keytar Shoreditch.</p>
+
+  <p>Street art PBR YOLO pug, before they sold out fixie artisan blog bicycle rights beard direct trade chillwave. Fanny pack cornhole whatever, Austin single-origin coffee ethical church-key distillery fashion axe tofu farm-to-table irony tattooed Tumblr. Craft beer Thundercats Austin gentrify, wolf Echo Park asymmetrical hella sartorial.</p>
+</div>
+
+ +

.blockIndicator.warning

+ +

将内容的一部分转换为警告框，警告框通常传达读者需要非常小心的一个重要事实（例如，他们需要做一些事情，或避免一些事情来避免严重问题）

+ +
+

Warning: Here be dragons!

+
+ +
+

This is available via the "Warning box" option in the MDN editor WYSIWYG styles dropdown.

+ +

+ +

Example syntax

+ +
<div class="blockIndicator warning">
+  <p><strong>Warning</strong>:Here be dragons!</p>
+</div>
+
+ +

表格样式

+ +

MDN为HTML“table”元素提供了特定的样式。这一节包括这些。

+ +

没有添加类：

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Favorite teas, December 2015
VarietyCaffeineSteeping TimeWater Temperature
BlackHigh2-3 minutes99 °C
GreenLow to Medium1-2 minutes75 to 80 °C
Caffeine free
HerbalNone3-6 minutes99 °C
+ +

.standard-table

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Favorite teas, December 2015
VarietyCaffeineSteeping TimeWater Temperature
BlackHigh2-3 minutes99 °C
GreenLow to Medium1-2 minutes75 to 80 °C
Caffeine free
HerbalNone3-6 minutes99 °C
+ +
+

A standard table can be created using the Table button in the MDN editor WYSIWYG toolbar. Pressing this brings up the Table Properties dialog box, which contains a number of functions. Generally you'll just want to use it to set the number of rows and columns, which cells are table headers ({{HTMLElement("th")}}), and a visible {{HTMLElement("caption")}} and {{HTMLAttrxRef("summary", "table")}} attribute to provide more information for screenreaders, if desired.

+ +

A diagram showing the Table button in the MDN edit interface, which has a picture of a table on it, and the dialog box that it brings up, which has options on it to set row number, column number, which cells are headings, and more.

+ +

Style notes

+ + + +

Example syntax

+ +
<table class="standard-table" summary="This table details what tea we liked to drink back in the heady month of December 2015">
+ <caption>Favorite teas, December 2015</caption>
+ <thead>
+  <tr>
+   <th scope="row">Variety</th>
+   <th scope="col">Caffeine</th>
+   <th scope="col">Steeping Time</th>
+   <th scope="col">Water Temperature</th>
+  </tr>
+ </thead>
+ <tbody>
+  <tr>
+   <th scope="row">Black</th>
+   <td>High</td>
+   <td>2-3 minutes</td>
+   <td>99&nbsp;°C</td>
+  </tr>
+  <tr>
+   <th scope="row">Green</th>
+   <td>Low to Medium</td>
+   <td>1-2 minutes</td>
+   <td>75 to 80&nbsp;°C</td>
+  </tr>
+  <tr>
+   <th scope="row">Herbal</th>
+   <td>None</td>
+   <td>3-6 minutes</td>
+   <td>99&nbsp;°C</td>
+  </tr>
+ </tbody>
+</table>
+
+ +

.standard-table.nostripe

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Favorite teas, December 2015
VarietyCaffeineSteeping TimeWater Temperature
BlackHigh2-3 minutes99 °C
GreenLow to Medium1-2 minutes75 to 80 °C
Caffeine free
HerbalNone3-6 minutes99 °C
+ +

.standard-table.fullwidth

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Favorite teas, December 2015
VarietyCaffeineSteeping TimeWater Temperature
BlackHigh2-3 minutes99 °C
GreenLow to Medium1-2 minutes75 to 80 °C
Caffeine free
HerbalNone3-6 minutes99 °C
+ +

.fullwidth-table

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Favorite teas, December 2015
VarietyCaffeineSteeping TimeWater Temperature
BlackHigh2-3 minutes99 °C
GreenLow to Medium1-2 minutes75 to 80 °C
Caffeine free
HerbalNone3-6 minutes99 °C
+ +

更新本指南

+ +

本指南不完整，正在逐步更新。如果您想帮助更新或添加到本指南中，请随时更新或添加！如果您有问题或想讨论并提出改进本文的想法，或者对我们如何改进MDN Web文档的样式或布局有建议，您可以有以下几种选择：

+ +

如果你想帮助完成它，或者想报告一个丢失或错误的文档样式，请联系Chris Mills（以chrisdavidmills的身份发言，在Mozil Mozilla IRC as chrismills)

+ +
+
开始讨论MDN Web文档讨论论坛 forum
+
如果您有什么想法想与MDN Web Docs社区或工作人员讨论，请随时在Mozilla讨论站点的MDN Web Docs论坛上开始一个主题。
+
在GitHub中提交您的建议
+
如果您想在我们的官方问题跟踪系统中记录您的建议，我们鼓励您这样做。先用上面的一个频道讨论是个好主意，但这不是必需的。
+
在IRC频道提问
+
我们的写作人员和贡献者社区使用 Mozilla's IRC 服务器 进行讨论和分享想法。欢迎您加入我们，提出您的问题或建议！（请注意，IRC的参与度很低，可能会在2020年停办；对话是获得答案的最佳选择。）
+
diff --git a/files/zh-cn/mdn/guidelines/index.html b/files/zh-cn/mdn/guidelines/index.html new file mode 100644 index 0000000000..9edc568068 --- /dev/null +++ b/files/zh-cn/mdn/guidelines/index.html @@ -0,0 +1,16 @@ +--- +title: MDN内容和样式指南 +slug: MDN/Guidelines +tags: + - Documentation + - Landing + - MDN + - NeedsTranslation + - TopicStub +translation_of: MDN/Guidelines +--- +
{{MDNSidebar}}
{{IncludeSubnav("/zh-CN/docs/MDN")}}
+ +

代码示例与其它内容应当被表示为适当的形式，这些指南提供了 MDN 文档应当如何被编写并被格式化的规范，以及我们的代码示例与其它内容应当如何被表示的详情说明。你可以通过遵循这些指南来确保自己编写的内容是清晰易用的。

+ +

{{LandingPageListSubpages}}

diff --git a/files/zh-cn/mdn/guidelines/layout/index.html b/files/zh-cn/mdn/guidelines/layout/index.html new file mode 100644 index 0000000000..919994b78d --- /dev/null +++ b/files/zh-cn/mdn/guidelines/layout/index.html @@ -0,0 +1,7 @@ +--- +title: MDN page layout guide +slug: MDN/Guidelines/Layout +translation_of: Archive/Meta_docs/MDN_page_layout_guide +--- +
{{MDNSidebar}}

这些指南补充了MDN 风格指南 中关于 MDN 上各种页面类型的具体布局。这有助于让贡献者们创建的内容结构与 MDN 上其他页面保持一致。

+

{{LandingPageListSubpages}}

diff --git a/files/zh-cn/mdn/guidelines/rules_of_mdn_documenting/index.html b/files/zh-cn/mdn/guidelines/rules_of_mdn_documenting/index.html new file mode 100644 index 0000000000..1f40cc49b8 --- /dev/null +++ b/files/zh-cn/mdn/guidelines/rules_of_mdn_documenting/index.html @@ -0,0 +1,193 @@ +--- +title: MDN收录规则 +slug: MDN/Guidelines/Rules_Of_MDN_Documenting +translation_of: MDN/Guidelines/Does_this_belong_on_MDN +--- +
{{MDNSidebar}}
{{IncludeSubnav("/zh-CN/docs/MDN")}}
+ +

如果你正准备记录什么信息，你可能想知道是否要将这些信息放入MDN。 更进一步地，你可能想在你的源代码中维护文档，并将文档写入Mozilla wiki，或者写入某Git仓库的readme文件中。 本文的目的是帮助你确认你的内容是否适合MDN。

+ +

文档是否应放入MDN主要取决于两点：

+ + + +
+

注意Mozilla的 Websites & Communications Terms of Use 所声明的条例在你使用MDN或对其做贡献时是生效的。检查这个文档，确保你知道在Mozilla的网站上什么是能发表的，什么是不能发表的。

+
+ +

哪些话题在MDN的范畴内？

+ +

MDN涉及了惊人的各种材料。总的来说，如果它是开放的面向Web的技术，或者是Mozilla的产品，我们就把它收录到MDN。但也有一小部分东西完全不属于MDN。这一节会告诉你如何确认你的文档是否属于MDN。

+ +

这里有一些我们涉及的事物；虽然这不是一个完整的列表，但是可以给你一个大致的印象。

+ +

开放的Web标准与技术

+ +

现在Web标准文档中受关注的是那些可以被Web开发者用于创建网站与App这些大众应用的功能。这指的是那些被众多浏览器所实现，要么是被标准接受，要么是正在向标准化发展的技术。即主要关注前端Web技术。后端的技术常常在别处有它们自己的文档，MDN不会去尝试取代它们。

+ + + +

同时欢迎关注与Web开发有关的交互技术话题，比如：

+ + + +
+

注意： MDN 涉及了非Mozilla但对Web开放的技术；举个例子，我们有关于WebKit格式的CSS属性的文档。

+
+ +

Mozilla 产品

+ +

这个分类的文档包括如何作为开发者使用Mozilla的产品，以及如何向这些开源项目贡献。

+ + + +

哪些话题不属于MDN？

+ +

举一些不适合MDN的话题：

+ + + +

哪些类型在MDN的范畴内？

+ +

In general, MDN is for product documentation, not for project or process documentation (except about MDN itself). So, if the document is about "how to use a thing" or "how a thing works" (where the "thing" is in one of the topic categories mentioned above), then it can go on MDN. But if it about "who's working on developing a thing" or "plans for developing a thing", then it shouldn't go on MDN. In that case, if the thing is being developed under the umbrella of Mozilla, then the Mozilla project wiki may be a good place for it.

+ +

Here are some examples of types of documents that should not be placed on MDN:

+ + + +

Advantages to documenting on MDN

+ +

If you've determined that the documentation you want to write is appropriate in content and type for MDN, but you're still not sure whether MDN is the best place for it, read on.  There are a lot of good reasons to create documentation on MDN.

+ +

Lots of writers and translators

+ +

The MDN community is big. Really big. It's big in the sort of way that makes big things look small. Seriously, we have a lot of people that participate in creating and maintaining content on MDN. With writers and editors on every continent (okay, I'm not sure about Antarctica, but otherwise), there's a lot of value to the sheer volume of writers:

+ + + +

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:

+ +
+
Delete spam
+
Spam happens. We deal with it.
+
Copy editing
+
You don't have to worry if your writing isn't as clear or precise as you'd like. We'll turn your prose into something other people can read.
+
Consistency of style
+
We'll ensure that your content is stylistically consistent not just within itself, but with the other documentation around it.
+
Content management
+
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.
+
Site and platform maintenance
+
MDN has both an IT team who keep the site up, running, and secure, and a platform development team who maintain and enhance the platform. You won't need to devote your own or additional resources to documentation infrastructure.
+
+ +

Cases for documenting elsewhere

+ +

There are also a few reasons you may be thinking about documenting your work somewhere other than MDN. Here are some of those reasons, and the pros and cons for each.

+ +

Plans and processes

+ +

Documentation for plans, processes, and proposals should never be put on MDN. That's pretty simple. If your project is part of Mozilla, you can put them on the Mozilla project wiki.

+ +

The project is on Github

+ +

Some of Mozilla's projects are hosted on Github, and Github offers its own wiki-like system for documentation. Some teams like to produce their documentation there. This is certainly fair and convenient if you're game to write your own docs; however, keep in mind that:

+ + + +

It's possible, of course, that these things don't bother you, or aren't a problem in your situation. Some teams don't mind keeping their own docs, or are working on code that has minimal documentation needs.

+ +

You want to keep docs in-source

+ +

Some teams like to have their documentation in the source tree. This is particularly common with project internals and library projects.

+ +

This approach has a couple of advantages:

+ + + +

There are some drawbacks:

+ + + +

Still, this can be a viable option (possibly even a good option) for some types of projects, especially small ones or those that aren't expected to get much interest.

+ +

{{endnote("*")}} It's OK to put a limited amount of personal information on your MDN profile page. User profiles should reflect a human being, not a business or organization. A moderate degree of self-promotion is OK, but link-spamming is not. Please do not use your profile to upload personal photos or other irrelevant files.

diff --git a/files/zh-cn/mdn/guidelines/style_guide/index.html b/files/zh-cn/mdn/guidelines/style_guide/index.html new file mode 100644 index 0000000000..285b2703cb --- /dev/null +++ b/files/zh-cn/mdn/guidelines/style_guide/index.html @@ -0,0 +1,784 @@ +--- +title: MDN Web 文档写作规范 +slug: MDN/Guidelines/Style_guide +tags: + - MDN + - MDN Meta + - MDN Web 文档 + - MDN 规范 + - 写作规范 + - 准则 + - 教程 + - 文档 + - 规范 +translation_of: MDN/Guidelines/Writing_style_guide +--- +
{{MDNSidebar}}
+ +

{{IncludeSubnav("/zh-CN/docs/MDN")}}

+ +

为了提供更加组织化、标准化且易于阅读的文档，MDN Web 文档写作规范明确了文本的组织方式、拼写规则、固定格式等内容，不过这些内容只是指导性的而不是严格的规定，因为比起格式我们对内容更感兴趣，所以没有必要在参与贡献之前强迫自己学习本规范。但是如果有一位勤劳的志愿者在之后编辑了你的文档使它更加符合本规范，也请不要感到惊讶或难过。

+ +

如果你正在寻找一个特定类型的页面应该如何构建的相关细节，请参阅MDN Web 文档页面布局规范。

+ +

本规范主要适用于英文文档。 其他语言可能也有（也欢迎创建）相应的规范。 这些应该作为子页面发布在各个本地化小组的页面中。

+ +
+

译注：本文的写作规范虽说是针对英文所写，但是其中的不少内容也适用于中文，可花点时间阅读一下。另外，中文翻译时的规范请参见《翻译术语表和翻译规范》。

+
+ +

对于那些为MDN以外的站点内容所编写的规范，请参考 Mozilla 统一规范。

+ +

基础部分

+ +

为了使文档保持更好的一致性，所有主流的写作规范指南都是从一些比较基本的写作规范开始的。以下几个小节所概述的这些基本规范内容应该会对你有很大帮助。

+ +

页面标题

+ +

页面标题不仅会在搜索时用到，在页面顶部的面包屑路径中也会被用来表示文档的层级结构。页面标题（就是显示在页面顶部以及搜索结果中标题的部分）可以与页面URL“<locale>/docs/”之后的“铭牌（slug）”部分不同.

+ +

文章标题和段落标题的大写规则

+ +

页面的标题和章节的标头应当使用语句式大写（只大写第一个单词的首字母以及专有名词的首字母），而不应该使用标题式大写：

+ + + +

我们还有很多旧的页面是在这条规范确立之前就已经发布了的。所以只要你愿意，你随时可以更新它们的标题。我们也正在逐步完善它们。

+ +

标题和铭牌的选择

+ +

页面的铭牌应该尽量简短，当创建一个新的层级时，新层级的铭牌最好只由一到两个单词组成。

+ +

而页面的标题长度并没有什么严格的限制，只要合理并且表意明确即可。

+ +

创建新的子目录

+ +

当你要给某个新的主题或主体添加文章时，你通常需要创建一个引导页，然后再把要添加的文章作为子页面添加进去。引导页开篇应当用一两段话来描述一下当前主题或技术，然后添加一个子页面的目录列表，并简要描述每个页面的内容。你可以使用一些我们已经编写好的宏把相关的子页面自动插入到目录列表中。

+ +

例如，JavaScript手册,其结构如下：

+ + + +

尽量避免把文章内容放置在层次结构的顶层，这会降低网站的访问速度，同时搜索和导航的效率也会下降。

+ +

文章内容的通用原则

+ +

在写任何文档时，知道该写多少是很重要的。如果你写的长篇大论，文章读起来就会冗长无味,更不会有人愿意使用它。保持文章内容适量很重要,原因有很多。这其中的原因就有：为了确保读者能够找到他们真正想要的信息，以及为搜索引擎提供足够的优质素材来对文章进行分析和排名。我们将在这里讨论前者（提供读者可能需要的信息）。如果想了解如何让文章更好地被搜索引擎分类和排名，查阅文章How to write for SEO on MDN。

+ +

我们的目标是在页面中包含读者可能需要的所有信息，但又不至于太过冗长。为了实现这个目标,我们给出了一些建议。

+ +

为读者着想

+ +

请记住，这些只是指导性的。其中某些建议并不适用于所有状况。当然你应该始终为你的读者着想。例如，在一篇介绍高级网络技术的文章中，通常不需要像介绍网络编程的文章那样包含过多的网络基本概念。

+ +

提供一个有用的简介

+ +

在开篇或第一个段落标题之前给出文章的简介，以使读者快速了解文章中是否包含他们感兴趣的内容。在指南或教程类的文章中，简介还应该让读者明白文章覆盖了哪些主题，以及文章期望读者能够从中了解到哪些知识。简介中应该包含文章中介绍和讨论的技术、API，并提供相关的链接，同时还应该提供可能会遇到的情况的提示。

+ +
示例：过于简短的简介
+ +

下面这个例子中的简介太过于简短，很多信息都没有包含进来，比如“stroke text”是什么意思，文本会在哪里等。

+ +
+

CanvasRenderingContext2D.strokeText() draws a string.

+
+ +
示例：过于冗长的简介
+ +

下面是上面那个简介的修改版，但是这次它又太过冗长了。其中包含了过多的细节，并且还包含了很多其他方法和属性，但实际上它应该将重点聚焦在 strokeText() 方法上，然后给出详细介绍它的文章的链接即可。

+ +
+

译注：作为例子，内容并不重要，所以就不逐句翻译了。

+
+ +
+

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.

+
+ +
示例：这次好多了
+ +

下面这个简介比前两个要好很多。

+ +
+

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.

+
+ +

多提供一些示例

+ +

文章应该尽量多提供一些示例。实际上，大多数文章都应该包含不止一个例子。使用例子来说明每个参数的用途或每个可能的边界条件是很有必要的。同时还应该用例子来演示常见问题的解决方法，以及应该如何解决使用过程中可能碰到的坑。

+ +

每个例子都应该先给出解释，说明它做了什么，以及读者在阅读或动手尝试之前需要了解的内容。

+ +

另外，每段示例代码都应该就其工作原理给出说明。最好将一段较长的代码分解成多个较小的部分，并提供每个部分的说明，说明时注意细节的层次。如果代码很简单并且不直接涉及到当前 API，可以只给出一个简单的介绍，说明其用途，以及为何要把它放在这里；而如果代码比较复杂、或用到了当前的 API、或在技术上比较有创造性，那么你应该提供更详细的说明。

+ +

如果使用的是在线演示的方式，则可以将 HTML、CSS、JavaScript 拆分到不同的 {{HTMLElement("pre")}} 中，它们在运行时会自动组合到一起，但使用这种方式每个里面都可以有自己的说明。因此这是一种很好很强大的方式。

+ +

过短的文章难以被搜索到

+ +

如果文章过短，那么搜索引擎可能会难以甚至无法对其建立关键字索引。一般来说，文章的主体内容应该至少包含 250-300 个单词。但是也不要对内容确实很少的文章进行刻意的扩充，在可能的情况下尽量遵守该指导原则即可。

+ +

小节、段落和换行

+ +

对于小节的标题，应使用从大到小的方式来定义级别：{{HTMLElement("h2")}}、{{HTMLElement("h3")}}、{{HTMLElement("h4")}} 这样，并且中间不要跳过某一级。因为 H1 已用于文章的标题，因此小节的标题应该从 H2 开始。如果你的文章中小节的层次超过了 3 到 4 级，那么你可能需要考虑将整篇文章拆分成几篇小的文章，然后用一个引导页给出这些文章的链接，并用 {{TemplateLink("Next")}}、{{TemplateLink("Previous")}}、{{TemplateLink("PreviousNext")}} 宏为它们创建导航。

+ +

按下回车键（Enter 或 Return）可以开始一个新的段落。如果只是想换行而不是另起一段，可以按住 Shift 并敲下回车。

+ +

不要创建只包含一个小节的子级别，如果只有一个小节，那么拆分主题就是没有意义的。至少包含两个小节，要么就不要拆分。

+ +

不要让两个小节标题紧挨在一起，这样看起来很丑。每个小节标题的下面至少要放上一段对后面各子小节的简短说明，这会对阅读的人很有帮助。

+ +

列表

+ +

列表的格式应该在所有文章中保持一致，并且应在列表中恰当使用标点和结构合理的句子。不管是哪种类型的列表，都需要对格式进行适当的调整。下面的内容说明了每种列表之间的不同。

+ +

无序列表

+ +

无序列表可以以简洁且有效的方式对内容进行分组显示。每个条目都会以类似“•”的符号来标识。在无序列表中要注意正确使用标点，尤其是每句的最后不要遗漏掉句号。应该以标准写作方式来对待无序列表。

+ +

下面是一个结构良好的无序列表的例子：

+ +
+

在这个例子中需要包括:

+ + +
+ +

可以看到，每个条目的格式都是一致的：首先显示一个“•”符号，然后列出一种情况，然后写上逗号，并在逗号后面添加一些对当前情况的简单说明。

+ +

有序列表

+ +

有序列表用序号来标识每个条目。同样要注意应该在有序列表中使用适当的格式，保持列表的清晰和简洁，这一点与无序列表是类似的。但是有序列表中的某些条目内容可能会很多，因此正确使用标点就更为重要了，因为难免会遇到必须使用复杂句子的情况。

+ +

下面是一个结构良好的有序列表的例子：

+ +
+

为了创建一个好的有序列表，你需要：

+ +
    +
  1. 以一个介绍性的标题开始，以引出后续的序列。我们可以在开始有序列表的序列之前提供这一内容。
    2. +
  2. 开始创建各个序列，这些序列会用数字依次编号。这是有序列表的标准格式，能够很容易地被读者理解。有序列表中的某些条目内容可能会很多，因此正确使用标点是很重要的。
    3. +
  3. 列表序列完成之后，应在后面再提供一段简短的总结。
    4. +
+ +

这段内容就是一个总结。我们已经创建了一个简短的有序列表，解释了创建良好格式的有序列表应遵循的步骤。

+
+ +

有序列表基本都用来表示具有连续性关系的内容，因此应该先深入思考你要用这些内容达到什么目的，然后再去撰写。

+ +

文本格式和样式

+ +

可以使用“样式”下拉列表中的预定义样式来格式化你选定的内容。

+ +
+

“Note”样式用来强调重要提示，就像这个。

+
+ +
+

类似地，“Warning”样式用来创建一个警告框。

+
+ +

除非有特殊需要，否则请不要用 HTML 的 style 属性来手动给内容添加样式。如果你没有找到你需要的预定义样式，可以放置一个 {{IRCLink("mdn")}} 并寻求帮助。

+ +

示例代码的格式和样式

+ +
+

这一小节只是讨论 MDN 文章中的示例代码的样式和格式问题，如果你想了解如何编写示例代码，请参考示例代码指南。

+
+ +

缩进和换行符

+ +

每级缩进都使用两个空格来缩进，并在所有的示例中保持一致。对于代码块的起始语句，应将开大括号“{”与当前语句写在一行上，比如：

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

如果一行的代码很长，应在适当的地方换行以避免出现水平滚动条。下面是一个例子：

+ +
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”按钮（编辑器中显示为“<>”的按钮）将其设置为内联代码格式（内联代码使用的是 {{HTMLElement("code")}} 元素）。比如：frenchText() 函数。

+ +

方法名后面应该加上小括号：doSomethingUseful()，这样会比较容易将方法与其他代码元素区分开来。

+ +

语法高亮

+ +

Screenshot of the 'Syntax Highlighter' menu.对于整行或多行代码，此时别再使用 {{HTMLElement("code")}}  元素来格式化了，而应该对其进行语法高亮。点击语法高亮器按钮（图标是两个代码块），从语言下拉列表中选择一种合适的语言即可。见右图。

+ +

下面的例子使用了 JavaScript 语法高亮：

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

如果没有在下拉列表中找到你需要的语言，可以选择第一项“没有高亮”，此时代码显示的是不带高亮效果的普通样式：

+ +
x = 42;
+ +

语法定义

+ +

如果你想插入一段语法定义，可以使用样式下拉列表中的“Syntax Box”选项。语法定义的样式与普通代码的样式会有所区别。

+ +

非代码区块

+ +

有些情况下需要用到 <pre> 区块而不是代码区块，此时不会进行语法高亮，也不会显示行号。比如你需要显示树形结构，就可以使用 <pre>：

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

插入方法是要先点击”pre“按钮，然后输入想要的内容即可。

+ +

HTML 元素的样式

+ +

HTML 元素的样式有一套自己的规则。遵守这些规则可以让元素及其组件的描述方式保持统一，并且还可以保证能够正确链接到各元素的详细文档页面。

+ +
+
元素名称
+
使用 {{TemplateLink("HTMLElement")}} 宏会生成一个指向该元素详情页的链接。比如，\{{HTMLElement("title")}} 会生成”{{HTMLElement("title")}}“。如果不想生成链接，就将元素名称用尖括号括起来，然后将其设置为内联代码样式，比如 <title>。
+
属性名称
+
请使用粗体。
+
属性定义
+
对正在定义的术语使用 {{TemplateLink("htmlattrdef")}} 宏（如 \{{htmlattrdef("type")}}），这样其他页面就可以使用 {{TemplateLink("htmlattrxref")}} 宏来链接到该页面了（例如 \{{htmlattrxref("attr","属性")}}）。
+
属性值
+
请使用内联代码样式，并且注意字符串两边不要加引号，除非是代码的语法要求加引号。举例：当将 <input> 元素的 type 属性设置为 email 或 tel 时……
+
为属性添加说明标签
+
请不要滥用 {{HTMLVersionInline(5)}} 这样的标签。比如，可以在某个第一次出现的属性名称旁边添加标签，但是不要在每次出现该属性的时候都添加一次。
+
+ +

拉丁文缩写

+ +

在补充说明的括号中

+ +

一般的拉丁文缩写（如：”etc.“、”i.e.“、”e.g.“）都可以用在起补充说明的括号里面。这时应在缩写中添加句号，后面加上逗号或其他恰当的标点。

+ + + +

在一般句子中

+ +

在普通的句子中（即括号的外面），请使用与缩写等价的英文单词或短语。

+ + + +

缩写、拉丁文原文和英文的对照表

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
缩写拉丁文英文
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
+ +
+

在使用前请仔细思考使用拉丁文缩写是否真的能带来好处。上面列出的某些缩写很少用到，很多读者可能不知道其意思，还有一些读者可能会分不清其中的某些缩写。另外，如果你决定使用缩写，那么请确保你的用法是正确的。比如，一个很多人经常会犯的错误是将“e.g.”和“i.e.”弄混。

+
+ +

首字母缩写和一般缩写

+ +
+
大写与句号
+
在这两种缩写中（包括国家和组织的缩写，如“US”、“UN”），请使用全大写且不要添加句号。
+
+
    +
  • 正确: XUL
    • +
  • 错误: X.U.L.、Xul
    • +
+
+
缩写展开
+
文章中第一次遇到某个缩写术语时，应该同时给出其展开形式，从而让不了解该缩写的读者能够知道它所指代的内容。如果不确定要不要展开那么就选择展开，或者更好的办法是将其链接到术语表中的对应条目。
+
+
    +
  • 正确: XUL (XML User Interface Language) is Mozilla's XML-based language...
    • +
  • 错误: XUL is Mozilla's XML-based language...
    • +
+
+
缩写的复数形式
+
当需要使用复数形式的缩写时，直接在后面加上“s”即可，请务必不要加撇号。
+
+
    +
  • 正确: CD-ROMs
    • +
  • 错误: CD-ROM's
    • +
+
+
”Versus“、”vs.“和”v.“
+
推荐使用”vs.“。
+
+
    +
  • 正确: this vs. that
    • +
  • 错误: this v. that
    • +
  • 错误: this versus that
    • +
+
+
+ +

大写

+ +

在文章内容中请使用标准英文大写规则，比如对于”World Wide Web“需大写每个单词的首字母。如果”web“和”internet“是单独使用或作为修饰词使用，那么将其全小写也可以——这一指导原则是后来修改过的，所以在 MDN 中你也许会看到很多首字母大写的”Web“和”Internet“。当你编辑文章的时候遇到这种情况，可以随它去，也可以随手修改一下。但是仅仅只是为了修改一下大写的话就没必要专门去编辑一下了。

+ +

对于键盘按键，应该使用普通的大写规则，而不是全大写。比如，是”Enter“而不是”ENTER“。

+ +

简写

+ +

我们倾向于宽松的写作风格，所以你可以按你的喜好来决定是否使用简写（如”don't“、”can't“、”shouldn't“）。

+ +

名称复数

+ +

请使用英文风格的复数形式，不要使用拉丁文或希腊文的形式。

+ +
+
+
    +
  • 正确: syllabuses、octopuses
    • +
  • 错误: syllabi、octopi
    • +
+
+
+ +

连字符

+ +

当两个单词连起来组成另一个单词时，如果前一个单词的最后一个字母是元音字母，并且与后一个单词的第一个字母相同时，应使用连字符。

+ +
+
+
    +
  • 正确: email、re-elect、co-op
    • +
  • 错误: e-mail、reelect、coop
    • +
+
+
+ +

使用性别中立的表述

+ +

在任何性别无关的场合使用性别中立的表述方式是一种比较好的做法，这样可以使你的文章具有普适性。举个例子，如果你正在写的是关于某个男人的行为，那么使用”他“来指代是没问题的；但如果内容并没有特指是男还是女，那么再使用”他“就不太恰当了。

+ +

让我们再看几个例子：

+ +

弹出一个对话框，让用户确认他是否允许网页使用他的网络摄像头。

+ +

弹出一个对话框，让用户确认她是否允许网页使用她的网络摄像头。

+ +

这两句话使用的都是特定性别的表述方式，我们可以将其修改为性别中立的代词：

+ +

弹出一个对话框，让用户确认他们是否允许网页使用他们的网络摄像头。

+ +
+

译注：这里原文为”they“和”their“，在英文中是性别中立的代词。而中文中如果上下文没有强调性别，则”他们“也具有性别中立性。

+
+ +
+

MDN 允许使用这种通用性的语法（尽管在正式用法中这一点还存在争议）来弥补英语在表达中立性别时的不足。将第三人称复数的代词用来表示性别中立代词（即使用”they“、”them“、”their“、”theirs“）是可以接受的，也就是通常所说的”单数形式的‘they’“。

+
+ +

你还可以同时写上两个性别：

+ +

弹出一个对话框，让用户确认他或她是否允许网页使用他/她的网络摄像头。

+ +
+

译注：中文里一般不这么用，所以如果在翻译中遇到这种情况，请简单翻译为”他“即可。”中文翻译规范“一文的”误解：100% 翻译 = 准确“一节中也提到了这个问题。

+
+ +

或者使用复数形式的”users“：

+ +

弹出一个对话框，让用户（译注：原文为”users“）确认他们是否允许网页使用他们的网络摄像头。

+ +

当然，最好的方法还是重写句子，去掉其中的代词：

+ +

弹出一个对话框，询问用户是否允许网页对网络摄像头的访问。

+ +

弹出一个询问用户以获取网络摄像头访问权限的对话框。

+ +

最后一种方法（译注：意指去除代词的方法）可能更好一些，因为它不但语法上更加正确，而且还能消除不同语言处理性别问题时所带来的复杂性，因为不同语言对性别的处理可能有不同的规则。因此这种方法无论是对读者（译注：意为阅读英语原文的非英语读者）还是翻译者来说都可以让翻译更简单。

+ +

数字和数词

+ +

日期

+ +

请用”January 1, 1990“这样的形式来表达日期（不包括代码中的日期）。

+ +
+
+
    +
  • 正确: February 24, 2006
    • +
  • 错误: February 24th, 2006、24 February, 2006、24/02/2006
    • +
+
+
+ +

或者你也可以使用”YYYY/MM/DD“的形式：

+ +
+
+
    +
  • 正确: 2006/02/24
    • +
  • 错误: 02/24/2006、24/02/2006、02/24/06
    • +
+
+
+ +

年代

+ +

请使用”1990s“这种形式来表示年代，但不要使用撇号：

+ +
+
+
    +
  • 正确: 1990s
    • +
  • 错误: 1990's
    • +
+
+
+ +

数词的复数

+ +

数词的复数直接在后面加”s“，同样不要使用撇号：

+ +
+
+
    +
  • 正确: 486s
    • +
  • 错误: 486's
    • +
+
+
+ +

逗号

+ +

应该仅在数字的位数大于等于 5 位时才使用逗号分隔符：

+ +
+
+
    +
  • 正确: 4000、54,000
    • +
  • 错误: 4,000、54000
    • +
+
+
+ +

标点符号

+ +

连续逗号

+ +

请使用连续逗号。连续逗号（也叫牛津逗号）是在一个包含三个或以上单词或短语的序列中位于连词前的那个逗号。

+ +
+
+
    +
  • 正确: I will travel on trains, planes, and automobiles.
    • +
  • 错误: I will travel on trains, planes and automobiles.
    • +
+
+
+ +
+

译注：这种情况在翻译时应将逗号翻译为顿号。”中文翻译规范“一文的”标点符号“一节中也提到了这个问题。

+
+ +
+

这一点与 Mozilla 统一规范有冲突，后者要求不要使用连续逗号。MDN 是这一规则的特例。

+
+ +

拼写

+ +

如果一个单词具有多种拼写，请使用美国英语的拼写。一般来说，Dictionary.com 上的第一个拼写是符合此要求的，除非单词本身即为其他变体形式或主要用于美国以外的国家中。例如，如果你去查”honour“，你会看到一个标注”Chiefly British“，并在其后有一个指向美语标准形式的链接。请不要使用其他的拼写变体。

+ +
+
+
    +
  • 正确: localize、honor
    • +
  • 错误: localise、honour
    • +
+
+
+ +

术语

+ +

HTML 元素

+ +

请使用”元素“来表示 HTML 和 XML 元素，不要使用”标记“。另外，请在元素名称两边使用尖括号 ”<>“ 括起来，并使用 {{HTMLElement("code")}} 样式。当文章中第一次出现某个元素的时候，应该用 {{TemplateLink("HTMLElement")}} 宏创建一个指向该元素文档的链接（除非你正在撰写的恰好是该元素的文档页面）。

+ +
+
+
    +
  • 正确: {{HTMLElement("span")}} 元素
    • +
  • 错误: span 标记
    • +
+
+
+ +

函数参数

+ +

在 MDN 上推荐使用 parameters 来表示函数的参数，为了保持一致性，如果可能的话请尽量避免使用”arguments“。

+ +

描述用户的操作

+ +

在说明一系列操作步骤时，应使用祈使语气来描述用户的操作，并用 UI 组件的名称和其元素类型来标识操作对象。

+ +
+
+
    +
  • 正确: 点击编辑按钮
    • +
  • 错误: 点击编辑
    • +
+
+
+ +

语态

+ +

推荐使用主动语态，但被动语态也可以接受，只是可能会让文章看起来不太正式。建议选择一种并在文章中尽量保持统一。

+ +

Wiki 标记及用法

+ +

链接

+ +

链接是 wiki 中最重要的功能元素之一。这里会介绍一些链接的基本内容，在我们的编辑器指南中的在MDN中创建和编辑链接这篇文章中有关于链接的详细介绍。

+ +

我们鼓励适当的添加一些相关文章的链接，这样可以提高页面导航的效率和内容的易发现性。链接不但可以指向其他 MDN 页面（内部链接），也可以指向其他网站的页面（外部链接）。

+ +

有两种创建链接的方式：点击编辑器工具栏中的“插入/编辑超链接”按钮（也可以按 Ctrl+K  键（在 Mac 上是 Cmd-K  键）），或者使用 MDN 强大的宏功能来自动创建或根据输入的内容创建链接。

+ +

下面列出的指导意见可以帮助你确定创建链接时使用什么样的链接文本：

+ + + +

URL 语法

+ +

为了保险起见，应始终使用下面的语法来创建链接：

+ + + +

其他语法可能无法工作或者不受支持，并有可能会被编辑人员删掉。

+ +
+

强调一下，不要使用 about: 和 chrome:// 等语法，因为它们可能无法生效。类似地， javascript: 可能会被最新的浏览器阻止，jar: 同理。

+
+ +

页面标签

+ +

标签用来提供与页面有关的元数据信息，或者用来标记当前页面在某方面仍需要完善。wiki 中的每个页面都应该包含标签。在如何合理地标记页面这篇指南中有更多关于使用标签的信息。

+ +

在编辑文章时，标签位于编辑器的底部，看起来是这样的：

+ +

在 MDN 中为页面添加和删除标签

+ +

要添加标签，点击标签列表最后的”新建标签……“按钮，然后输入要添加的标签名称。标签会随着你的输入显示自动完成提示。最后按下回车键来确认并提交新标签。可以为一篇文章添加任意多个标签。举个例子，一篇关于在 AJAX 编程中使用 JavaScript 的文章可能需要添加”JavaScript“和”AJAX“这两个标签。

+ +

要删除一个标签，点击标签上的”X“图标即可。

+ +

标记页面的后续事项

+ +

标签还可以用于将文章标记为需要某些后续的工作，用来跟踪文章质量和内容方面的信息。

+ +

标记已废弃页面

+ +

可使用下面的标签来标记不再使用的页面：

+ + + +

SEO 概要

+ +

SEO 概要是对一篇文章的简短描述，它会在网页机器爬虫抓取到当前页面时告诉爬虫该文章的概要，当用户搜索到该页面时就会显示此概要信息。另外，在 MDN 内部通过宏来自动生成引导页的时候也会用到它。

+ +

默认情况下，文章的第一段内容会被当成是 SEO 概要。但是你可以在编辑器中使用“SEO Summary“样式来手动指定一段内容作为 SEO 概要。

+ +

引导页

+ +

引导页的层级位于网站层级的顶层，例如 CSS 和 HTML 的主页面就是引导页。引导页具有标准的格式，由以下 3 个部分组成：

+ + + +
+

译注：这里的链接原本是指向原文的”Writing a landing page overview“一节，但该节貌似已被删除了，所以链接已失效。这里我找到了一个与其内容相近的小节。

+
+ + + +

创建相关页面的链接列表

+ +

引导页中的链接列表部分有两列，其 HTML 代码的结构如下：

+ +
<div class="row topicpage-table">
+  <div class="section">
+    ... 左侧列 ...
+  </div>
+  <div class="section">
+    ... 右侧列 ...
+  </div>
+</div>
+ +

左侧列的顶部是一个 <h2> 标题，用来说明此列的内容是当前主题所包含的文章列表（如”某某的文档和教程“），其下方则是具体的文章列表。该列的标题样式应使用 CSS 类 ”Documentation“，而下方的文章列表是一个 <dl> 列表，其中的每个 <dt> 都包含一个文章的链接和位于 <dd> 中的该目标文章的一两句话的说明。

+ +

右侧列则包含一或多个小节，各小节按以下顺序排列：

+ +
+
获取社区的帮助
+
该节用来提供当前主题相关的 Matrix 频道和邮件列表信息。标题需使用 CSS 类”Community“。
+
工具
+
可以帮助用户使用当前主题所介绍的技术的工具列表。标题需使用 CSS 类”Tools“。
+
相关主题
+
一些链接到其他相关技术的引导页链接。标题需使用 CSS 类”Related_Topics“。
+
+ +

<<<当引导页的标准完成时需要继续完善本节内容>>>

+ +

插入图片

+ +

在创建或编辑文章时，有时候使用图片会对文章内容有不少好处，特别是文章的技术性很强的时候。可以使用下面的方法来添加一个图片：

+ +
    +
  1. 先添加一个图片附件到当前文章中（附件在编辑器的底部）
    2. +
  2. 点击”图像“按钮，弹出对话框
    3. +
  3. 在对话框中的附件下拉列表中，选择刚添加的图片
    4. +
  4. 点击确定按钮
    5. +
+ +

其他参考资料

+ +

推荐样式指南

+ +

如果你在撰写过程中或在格式方面遇到了本文尚未提及的问题，我们建议你参考 Economist 网站的风格指南，如果还是不能解决问题，还可参考芝加哥论文格式。

+ +

推荐词典

+ +

如果有拼写方面的问题，请参考 Dictionary.com。本网站的拼写检查采用美国英语规则，因此请不要使用其他拼写规则（例如应该使用“color”而不是“colour”）。

+ +

我们会继续扩充本指南，因此如果你遇到了本文未提及的问题，请通过 MDC 邮件列表或项目带头人联系我们，让我们了解还需要加入哪些内容。

+ +

MDN

+ +

MDN 中常用的宏及其说明。

+ +

语言、语法和拼写

+ +

如果你对提高写作和编辑能力感兴趣，下面的资料会对你有所帮助：

+ + diff --git a/files/zh-cn/mdn/index.html b/files/zh-cn/mdn/index.html new file mode 100644 index 0000000000..f04f67d25f --- /dev/null +++ b/files/zh-cn/mdn/index.html @@ -0,0 +1,30 @@ +--- +title: MDN项目 +slug: MDN +tags: + - MDN + - 文档 +translation_of: MDN +--- +
{{MDNSidebar}}
+ +

Mozilla 开发者网络（MDN）是一个记录所有与开放 Web 技术、Mozilla 私有技术、Firefox OS 等相关的技术性文档的维基。我们欢迎各位志愿者的加入并帮助我们完善文档内容。您不必是程序员，也无需懂很多的技术。这里有许多不同的任务等待您去做，从简单的文章校对到错字修改、复杂的 API 文档编写等等。

+ +
+

MDN 的目标是为所有的开放 Web 技术、Mozilla 私有技术以及 Mozilla 私有项目提供技术文档，我们诚恳地期待您的加入！

+
+ +

我们需要您的帮助！加入我们很简单，您不必担心权限问题，也不必担心犯错误。只要加入MDN 社区，我们就可以帮助您。下面的文章可以帮你快速入门。

+ + diff --git a/files/zh-cn/mdn/kuma/index.html b/files/zh-cn/mdn/kuma/index.html new file mode 100644 index 0000000000..d506a15fbe --- /dev/null +++ b/files/zh-cn/mdn/kuma/index.html @@ -0,0 +1,24 @@ +--- +title: 'Kuma: MDN 的 wiki 平台' +slug: MDN/Kuma +tags: + - Kuma + - wiki + - 平台 +translation_of: MDN/Kuma +--- +
{{MDNSidebar}}{{IncludeSubnav("/en-US/docs/MDN")}}
+ +

Kuma 是驱动 MDN Web Docs 的 Django 程序。

+ +

{{SubpagesWithSummaries}}

+ +

了解Kuma

+ +

想要了解Kuma，你可以：

+ + diff --git a/files/zh-cn/mdn/mdn_product_advisory_board/index.html b/files/zh-cn/mdn/mdn_product_advisory_board/index.html new file mode 100644 index 0000000000..5407210821 --- /dev/null +++ b/files/zh-cn/mdn/mdn_product_advisory_board/index.html @@ -0,0 +1,22 @@ +--- +title: MDN 产品咨询委员会 +slug: MDN/MDN_Product_Advisory_Board +tags: + - MDN + - PAB + - 产品咨询委员会 +translation_of: MDN/MDN_Product_Advisory_Board +--- +
{{MDNSidebar}}

MDN Web Docs是基于wiki技术、也基于开源的Web开发文档平台，是Web开发人员的技术文档的可靠来源，允许几乎任何人编写和编辑内容。

+ +

Mozilla对MDN产品咨询委员会的愿景是建立协作，帮助MDN社区将MDN作为最全面，完整和值得信赖的参考文献，将文档记录在现代浏览器和Web标准的最重要方面。

+ +

产品咨询委员会将会从外部领导者提供建议，帮助MDN致力于提供HTML，CSS，JavaScript和Web API的中立、浏览器无关文档，并成为基于标准的Web开发的首要参考。

+ +

参见

+ + diff --git a/files/zh-cn/mdn/mdn_product_advisory_board/members/index.html b/files/zh-cn/mdn/mdn_product_advisory_board/members/index.html new file mode 100644 index 0000000000..a1131e703f --- /dev/null +++ b/files/zh-cn/mdn/mdn_product_advisory_board/members/index.html @@ -0,0 +1,57 @@ +--- +title: Product Advisory Board Members +slug: MDN/MDN_Product_Advisory_Board/Members +tags: + - MDN + - PAB + - 产品顾问委员会 + - 会员 +translation_of: MDN/MDN_Product_Advisory_Board/Members +--- +
{{MDNSidebar}}

现任MDN产品咨询委员会成员:

+ +

Daniel Appelquist
+ Director of Developer Advocacy at Samsung Internet, Co-Chair of W3C's Technical Architecture Group

+ +

Daniel Appelquist leads the Web Developer Advocacy team at Samsung Internet <https://samsunginter.net>, Samsung's mobile and VR web browser. He has also been co-chair the W3C's Technical Architecture Group since 2013. He has been working on the web for over 2 decades, first helping to create start-ups in the web publishing sphere and then (after moving to London from New York in '99) working on the convergence between web and mobile through many projects and initiatives. He has also led open standards strategy for the UK Government and remains a member of the UK Government Open Standards Board. In between all this he's been an active community builder and event organizer.

+ +

Dominique Hazael-Massieux
+ W3C Web Technology Expert including Telecommunications Vertical champion, Web Real-Time Communications Working Group, Device and Sensors Working Group.

+ +

Dominique Hazael-Massieux is part of the W3C staff, where he leads W3C efforts in developer relationship. Dom has been working for W3C since 2000, and in addition to devrel, is currently involved in the standardization of WebRTC, device APIs and WebVR.

+ +

Meggin Kearney
+ Lead Technical Writer, Web Developer Relations at Google.

+ +

Meggin leads the team that writes docs that help web developers succeed, including Web API documentation in MDN. A proud Chromium committer, she also co-built the Chrome extensions doc server. Meggin earned her undergraduate degree at the University of California, Berkeley. She lives in San Francisco, and is always looking for ways to support diversity and inclusion in the web developer community.

+ +

Patrick Kettner
+ Microsoft

+ +

Patrick is a Program Manager at Microsoft, focusing on interoperability and new web technologies. A web developer by trade, he has committed in all major browsers and works every day to make web developers lives easier and more fun. Outside of work, he contributes to a number of open source projects, including maintaining Modernizr. He lives in Seattle with his wonderful partner Katrina, son Holden, and dog Baxter.

+ +

Chris Mills
+ Content Lead, MDN Web Docs at Mozilla

+ +

Chris works at Mozilla as content lead for MDN, helping to pull together a strategy for what needs documenting in the short and long term. He also contributes a large number of beginner’s tutorials and reference articles covering DOM APIs, HTML and CSS features, web games, WebAssembly, and more.

+ +

Erika Doyle Navara
+ Senior Dev Writer for Windows web documentation at Microsoft

+ +

 Erika Doyle Navara has been tinkering around the Microsoft browser engine room since 2006 when she started working on IE7. As a test engineer and technical writer, she helped organize Microsoft's contributions and browser data for the CSS 2.1, CSS3, SVG and HTML5 test suites at the W3C. She’s excited to continue championing cross-browser interoperability at MDN web docs.

+ +

Robert Nyman
+ Global Lead for Programs & Initiatives, Web Developer Relations, at Google.

+ +

Robert Nyman is the Global Lead for Developer Feedback & Communities, Web Platform at Google. In his role, he works to make the web the best platform for developers. Prior to Google, Robert was a technical evangelist at Mozilla, focused on the Open Web and the company’s various products and initiatives. He lives in Stockholm, and has a passion for traveling and meeting people. He claims the title of “Most Well-Traveled Speaker” on Lanyrd, having presented in 42 countries.

+ +

Ali Spivak

+ +

Mozilla开发商生态系统负责人，产品顾问委员会主席。
+  

+ +

Ali是Mozilla开发商生态系统的负责人，之前在Mozilla负责开发者营销。 她管理MDN超过5年，致力于一个可互操作、跨平台互联网。 在Mozilla之前，她曾经在思科，Edmunds.com和许多创业公司管理Web产品。

+ +

Kadir Topal

+ +

Mozilla的MDN Web文档产品经理。

diff --git a/files/zh-cn/mdn/mdn_product_advisory_board/membership/index.html b/files/zh-cn/mdn/mdn_product_advisory_board/membership/index.html new file mode 100644 index 0000000000..e438d455b9 --- /dev/null +++ b/files/zh-cn/mdn/mdn_product_advisory_board/membership/index.html @@ -0,0 +1,127 @@ +--- +title: Product Advisory Board Charter & Membership +slug: MDN/MDN_Product_Advisory_Board/Membership +tags: + - MDN + - PAB + - 产品咨询委员会 + - 会员 + - 条款和条件 +translation_of: MDN/MDN_Product_Advisory_Board/Membership +--- +
{{MDNSidebar}}

1.目的和目标

+ +

The primary purpose of the PAB is to provide advice, input, and feedback on content strategy, content prioritization, strategic direction, and platform/site features to MDN’s Product Manager and Content Lead. Mozilla will consider input and advice from the PAB; however PAB input and recommendations are non-binding. The primary objectives of the PAB are:

+ + + +

2.会员当选和终止

+ +

a. The PAB shall consist of 10 to 12 Members (as defined in the MDN Product Advisory Board Agreement and including those individuals representing a Member organization), to be selected by Mozilla.

+ +

b. There are two types of membership: organizational and individual. Organizations who meet the membership criteria and are accepted as member organizations may nominate up to 2 individuals to serve as their representatives (“Member Representatives” as defined in the MDN Product Advisory Board Agreement) on the PAB.

+ +

c. Organizations/individuals who wish to become PAB members must submit a MDN Product Advisory Board Interest Form. Membership will be subject to review and approval by Mozilla, and notification will be sent to the applicant within 30 days of application.

+ +

d. Membership start dates will be based upon review meeting schedules; any new Members will begin their term on the PAB at the next scheduled review meeting.

+ +

e. Members of the PAB will serve terms of 1 year, renewed automatically for up to 3 years (unless terminated by either party). At the end of the 1-year term, the PAB Member and Mozilla will review membership and decide whether to continue Member participation.

+ +

f. Members may resign in writing, via email to the PAB mailing list. Member organizations can nominate replacements for resigned members before the start of the next review meeting.

+ +

g. Mozilla may terminate a Member in the case of violation of the MDN Advisory Board Agreement, violation of the MDN PAB Code of Conduct, violation of the Antitrust Policy, or if the Member fails to participate in two consecutive review meetings without notice. At that time, a notice will be sent to the principal contact stating that they have been removed as a Member.

+ +

3.PAB 会员资格

+ +

a. PAB Members have in-depth industry knowledge and expertise. Members will be knowledgeable about web standards, with the ability and experience to align MDN’s overall strategic goals and content plans with evolution of web standards, industry direction, and the needs of developers using MDN’s documentation.

+ +

b. Membership in the PAB is limited to organizations and individuals who make significant contributions to MDN and/or the advancement, development, and implementation of web standards.

+ +

c. Member organizations must play a significant role in the creation, implementation, or adoption of Web standards and guidelines. It is also preferred that PAB Member organizations be members of an established Web standards group, such as W3C. Member organizations may nominate up to 2 individual representatives to serve on the board.

+ +

d. Individual Members of the PAB must have at least one of the following qualifications:

+ + + +

4. 会员责任和承诺。

+ +

a. Members are expected to provide feedback and responses in a timely manner, and attend a minimum number of review meetings. Participation is welcome from all over the world. Members’ expectations include:

+ +

Provide feedback on scheduling annual and quarterly meetings;

+ + + +

b. Members may be required to provide personal information and material (bios, etc.) for analyst, press, and/or trade publications and press releases.

+ +

c. All Members must sign the MDN Product Advisory Board Agreement and agree to the MDN PAB Code of Conduct and Antitrust Policy.

+ +

5. MDN PAB 会员权利。

+ +

It is anticipated that PAB membership will have the following benefits:

+ + + +

6. 常规和指定会议。

+ +

a. Members will be invited to the following meetings:

+ + + +

b. Annual Product Strategy review meetings will review the previous year’s progress and make recommendations for MDN’s strategy and objectives for the following year.

+ +

c. Annual Product Strategy review meetings can take place in Mozilla headquarters or worldwide office, the offices of a Member, or external locations, as determined by vote of the PAB. Virtual attendance will be accommodated for Members who are unable to attend in person.

+ +

d. Quarterly Reviews and Ad-Hoc Meetings will primarily be held via video/conference call, although in-person attendance will be possible at the discretion of Members.

+ +

e. Ad-Hoc Meeting dates will depend upon the work in development. Review points will have a specific emphasis such as coordination around product release dates and major features or new specs and standards reaching broad release that require more in-depth coordination and planning beyond the Quarterly Review.

+ +

7. 时间承诺和成本。

+ +

a. Members are asked to make a commitment to the PAB for at least 12 months.

+ +

b. Members are asked to commit the time to prepare for, attend (sometimes in person), and participate in regularly scheduled and ad-hoc PAB meetings.

+ +

c. Costs for participant travel and living expenses or other involvement are to be paid by the individual board member or the sponsoring organization.

+ +

 

+ +

参见

+ + diff --git a/files/zh-cn/mdn/structures/compatibility_tables/index.html b/files/zh-cn/mdn/structures/compatibility_tables/index.html new file mode 100644 index 0000000000..fdcf1d1408 --- /dev/null +++ b/files/zh-cn/mdn/structures/compatibility_tables/index.html @@ -0,0 +1,500 @@ +--- +title: 兼容性表格 +slug: MDN/Structures/Compatibility_tables +tags: + - MDN Meta + - 兼容性表格 + - 指南 + - 浏览器兼容性 +translation_of: MDN/Structures/Compatibility_tables +--- +
{{MDNSidebar}}
+ +
{{IncludeSubnav("/zh-CN/docs/MDN")}}
+ +

MDN 为我们的开放网页文档提供了兼容性表格的标准格式; 它是对比所有浏览器之间，包含 DOM，HTML，CSS，JavaScript，SVG 等技术的文档。本文将介绍如何使用我们的功能将兼容性数据添加到MDN页面。

+ +
+

重要: 数据的生成方式已经发生了变更。过去，我们的表格直接嵌入在页面中，而且数据是手动填写的。这样效率很低，难以维护，而且使得数据不够灵活，不便更新。所以我们正在把我们的兼容性表格迁移到一个数据 repo 中（https://github.com/mdn/browser-compat-data）并且改为使用程序化的方式生成它。
+
+ 本指南中，我们撰写了关于如何向 MDN 添加新的兼容性数据的文档，但是我们仍然保留了旧的方法来保证旧文档的兼容性表格可用：正如你所见，手动输入的表格依然存在于 MDN 上。如果你有必要使用旧方法的话，可以参考这篇文章：Old compatibility tables。

+
+ +
+

注意：如果您需要本指南任何步骤的帮助，欢迎您在MDN论坛上与我们联系。

+
+ +

如何访问 data repo

+ +

数据存储在一个 GitHub repo 中，到 https://github.com/mdn/browser-compat-data 查看。想要访问它，你必须拥有一个 GitHub 账号，fork浏览器兼容数据仓库到你自己的账户，然后克隆你的fork到你的本地机器。

+ +

选择要贡献的数据类型

+ +

首先，确定一下你想为何种 Web 技术贡献兼容性数据。可以是一个 HTML 元素、CSS 属性、JS 语法或者 JS API 接口。我们鼓励您贡献 API 接口的数据, 因为已经有人在贡献 HTML、JS 和 CSS 的数据了。你可以在表格 Browser Compat Data migration 中查看各个需要添加兼容性数据的 Web 技术的数据状态。

+ +

电子表格的使用步骤如下:

+ +
    +
  1. 直接挑选一个还未开始或者还未完成数据录入的功能点，在“Who”一栏中填入你的名字, 最好能够和你的MDN用户名保持一致，以便我们在需要联系你的时候能够查找到你的邮件地址.
    2. +
  2. 如果该功能点不在表格上，那么你可以参照现有的格式在合适的位置上加一行。注意要使用同等的粒度（例如，HTML以标签元素为单位、CSS以选择器或者属性值为单位、JS以对象为单位、JS API以特定的接口为单位）
    3. +
  3. 当你已经开始录入数据的时候，把对应状态栏的下拉选项置于“In progress”（进行中）状态。
    4. +
  4. 一旦添加完数据，并且向主仓库提交了一个拉取请求（pull request），那么把对应状态栏的下拉选项置于“PR done”状态。
    5. +
  5. 当你的数据已经成功合并到主分支，或者已经添加到npm包里面的时候，请尽量更新对应的状态栏到相应的状态。
    6. +
  6. 当你更新了你的功能文档页面，并且使用新的脚步命令使其可以在每一个页面都可以动态的生成合适的数据表格的时候，你就需要在电子表格中修改对应功能的状态为“Article updated”（文章已更新）。这意味着你已经完成了这一功能的所有数据录入工作。
    7. +
+ +

准备添加数据

+ +

在添加新数据之前，你应该保证您的 fork 是主 repo 的最新版本（它们应包含相同的内容）。在您的 fork 里添加一个包含您的更改的分支，然后把它pull到您本地的仓库，这样你就可以开始贡献了：

+ +

下面是更新您的分支的一个简单方法：

+ +

将浏览器兼容信息的主 repo 添加到远端服务器列表中

+ +

在您的终端或命令行中进入您的fork的本地仓库，用以下命令将（服务器上的）主 repo 添加到远端服务器列表中（您只需执行以下命令一次）：

+ +
git remote add upstream https://github.com/mdn/browser-compat-data.git
+ +

如果您不确定自己是否做到了这一点， 您可以检查您仓库已经在用的远端服务器列表：

+ +
git remote -v
+ +

让您的分支与服务器上的内容同步

+ +

现在，只要您想更新您的分支，您就可以这样做：

+ +
    +
  1. +

    确定您已切换到在主分支：

    + + 
    git checkout master
    +
    2. +
  2. +

    使用以下命令来获取服务器上最新的内容：

    + + 
    git fetch upstream
    +
    3. +
  3. +

    用rebase将主仓库的内容合并到您的master分支中：

    + + 
    git rebase upstream/master
    +
    4. +
  4. +

    将来自主 repo 的更新 push 回您自己的 repo 中：

    + + 
    git push -f
    +
    5. +
+ +

创建您用来工作的分支：

+ +

接下来，打开您在服务器上的fork（它的地址可能是https://github.com/your-username/browser-compat-data）并且创建一个新分支来存储您的改动。步骤如下：

+ +
    +
  1. 点击"Branch: Master"按钮；
    2. +
  2. 在"Find or create a branch..."文本输入框中输入一个新的分支名；
    3. +
  3. 点击下方出现的"Create branch name-of-branch from Master"按钮。
    4. +
+ +

举个例子，如果您想补充WebVR API的信息，您可以创建一个名为“webvr”的分支.

+ +

切换到新分支

+ +

此时，回到您的终端或命令行，用以下命令将您的新分支同步到您本地的fork中：

+ +
git pull
+ +

现在用以下命令切换到您的新分支

+ +
git checkout -b name-of-branch
+ +

现在您可以开始进行您对浏览器兼容信息的补充和修改了。

+ +

添加数据

+ +

为添加新的数据，您需要新建文件以存储您的兼容性数据。对于不同技术的数据，您需要创建的文件也有所不同：

+ + + +
+

注意：您会留意到，该仓库还包含了浏览器拓展和HTTP的数据。These data sets are basically finished as they stand, but more features may need to be added in the future.

+
+ +

你创建的每个文件都需要跟随定义在我们repo的schema中的这些模板的规定。你可以参考详细的模板描述。

+ +

基本的兼容性数据的结构

+ +

让我们来看一下如下例子。一个CSS属性JSON文件需要以下的结构：

+ +
{
+  "css": {
+    "properties": {
+      "border-width": {
+        "__compat": {
+          ...
+        }
+      }
+    }
+  }
+}
+ +

首先有一个css对象，其中包含了一个properties对象。每个您要设定兼容性数据的特性都对应一个properties对象中的成员。而每一个这些成员都有一个__compat成员，__compat成员中则是实际的数据。

+ +

以上的数据能在 browser-width.json 文件中找到——可将这与 MDN上渲染后的浏览器兼容性 相比较。

+ +

对于其他类型特性，写法是类似的，但对象的名称不同：

+ + + +
+

在一个HTML、CSS和JS页面中，通常您只需要有一个特性。API则有些不同——它们总是包含多个子特性 （参见下边的 {{anch("Sub-features")}}）。

+ +

一个特性中的基础结构

+ +

在一个特性的__compat成员中，您需要包含以下成员：

+ + + +

浏览器成员名称在架构里被定义（参见 浏览器标识符）。你应该使用现有定义的标识符的完整列表。如果你希望添加其他浏览器，请先联系我们，因为这可能会产生广泛的影响，不应该在未经认真考虑就这么做。

+ +

在一个基本的浏览器兼容数据文件中，你只需要在浏览器标识符成员仲包含"version_added" （以下我们会说到{{anch("Advanced cases")}}）。其他你可能使用的值还包括： 

+ + + +

在 status 成员中，包含三个子成员：

+ + + +

作为例子，以下是 border-width 特性的数据 (参见 border-width.json) ：

+ +
"__compat": {
+  "mdn_url": "https://developer.mozilla.org/docs/Web/CSS/border-width",
+  "support": {
+    "chrome": {
+      "version_added": "1"
+    },
+    "webview_android": {
+      "version_added": "2"
+    },
+    "edge": {
+      "version_added": true
+    },
+    "edge_mobile": {
+      "version_added": true
+    },
+    "firefox": {
+      "version_added": "1"
+    },
+    "firefox_android": {
+      "version_added": "1"
+    },
+    "ie": {
+      "version_added": "4"
+    },
+    "ie_mobile": {
+      "version_added": "6"
+    },
+    "opera": {
+      "version_added": "3.5"
+    },
+    "opera_android": {
+      "version_added": "11"
+    },
+    "safari": {
+      "version_added": "1"
+    },
+    "safari_ios": {
+      "version_added": "3"
+    }
+  },
+  "status": {
+    "experimental": false,
+    "standard_track": true,
+    "deprecated": false
+  }
+}
+ +

添加描述说明

+ +

There is a fourth, optional, member that can go inside the __compat member — description. This can be used to include a human-readable description of the feature. You should only include this if it is hard to see what the feature is from glancing at the data. For example, it might not be that obvious what a constructor is from looking at the data structure, so you can include a description like so:

+ +
{
+  "api": {
+    "AbortController": {
+      "__compat": {
+        ...
+      },
+      "AbortController": {
+        "__compat": {
+          "mdn_url": "https://developer.mozilla.org/docs/Web/API/AbortController/AbortController",
+          "description": "<code>AbortController()</code> constructor",
+          "support": {
+            ...
+          }
+        }
+      }
+
+      ... etc.
+    }
+  }
+}
+ +

子特性

+ +

In a page where the compat table has more than one row, you'll need multiple subfeatures inside each feature to define the information for each row. This can happen, for example, when you've got the basic support for a feature stored in one row, but then the feature also has a new property or value type that was addded much later in the specification's life and is only supported in a couple of browsers.

+ +

As an example, see the compat data and corresponding MDN page for the background-color property. The basic support exists inside the __compat object as explained above, then you have an additional row for browsers' support for "alpha channel for hex values", which contains its own __compat object.

+ +
{
+  "css": {
+    "properties": {
+      "background-color": {
+        "__compat": {
+          ...
+        },
+        "alpha_ch_for_hex": {
+          "__compat": {
+            ...
+          },
+        }
+      }
+    }
+  }
+}
+ +

For an API, you've got the top two levels defined as api.name-of-the-interface, then a top-level __compat section to define the overall browser compatibility of the interface, then a sub-feature for each of the methods, properties, and constructors contained inside the interface. The basic structure looks like this:

+ +
{
+  "api": {
+    "VRDisplay": {
+      "__compat": {
+        ...
+      },
+      "cancelAnimationFrame": {
+        "__compat": {
+          ...
+        }
+      },
+      "capabilities": {
+        "__compat": {
+          ...
+        }
+      },
+
+      ... etc.
+
+    }
+  }
+}
+ +

See VRDisplay.json for a full example.

+
+ +

添加数据：高级场景

+ +

There are some advanced features that you'll want to include in browser compat data. The aim of this section is to list the most common ones, providing an example of each to show how you can implement them in your own compat data.

+ +

Including a footnote

+ +

Often compat tables will include footnotes related to certain entries that explain useful details or strange behavior that developers will find useful. As an example, the Chrome Android entry for {{domxref("VRDisplay.capabilities")}} (see also VRDisplay.json)  (at the time of writing) had a footnote "Currently supported only by Google Daydream." To include this in the capabilities data, we added a "notes" submember inside the relevant "chrome_android" submember; it would look like this:

+ +
"chrome_android": {
+  "version_added": true,
+  "notes": "Currently supported only by Google Daydream."
+}
+ +

包含浏览器厂商的前缀

+ +

If a feature is supported behind a vendor prefix in one or more browsers, you'll want to make that clear in the browser compat data. 例如您可能有一个特性在Firefox浏览器中要用-moz-前缀才被支持，要在兼容性数据中指明这一点，您需在对应的"firefox"子成员中增加一个"prefix"子成员。它看起来是这样的：

+ +
"firefox": {
+  "version_added": true,
+  "prefix": "-moz-"
+}
+ +

Including browser preferences or flags

+ +

Some features may be supported in a browser, but they are experimental and turned off by default. If a user wants to play with this feature they need to turn it on using a preference/flag.

+ +

To represent this in the compat data, you need to add the "flags" submember inside the relevant browser identifier submember. The value of "flags" is an array of objects each of which contains of three members:

+ + + +

So to add a preference/flag to the Chrome support for a feature, you'd do something like this:

+ +
"chrome": {
+  "version_added": "50",
+  "flags": [
+    {
+      "type": "preference",
+      "name": "Enable Experimental Web Platform Features",
+      "value_to_set": "true"
+    }
+  ]
+},
+ +

If a feature is behind two or more flags, you can add additional objects to the "flags" array, like in this case, for example:

+ +
"firefox": {
+  "version_added": "57",
+  "flags": [
+    {
+      "type": "preference",
+      "name": "dom.streams.enabled",
+      "value_to_set": "true"
+    },
+    {
+      "type": "preference",
+      "name": "javascript.options.streams",
+      "value_to_set": "true"
+    }
+  ]
+},
+ +

包含特性不再被支持的版本

+ +

有时一个特性在浏览器的某个版本被加进去，然后又因为该特性过时而被被移除掉。这可以在"version_removed"子成员中体现。该子成员是一个代表特性被移除的版本的字符串。例如：

+ +
"firefox": {
+  "version_added": "35",
+  "version_removed": "47",
+},
+ +

Including multiple support points for the same browser entry

+ +

Sometimes you'll want to add multiple support data points for the same browser inside the same feature.

+ +

As an example, the {{cssxref("text-align-last")}} property (see also text-align-last.json) was added to Chrome in version 35, supported behind a pref.

+ +

The support mentioned above was then removed in version 47; also in version 47, support was added for text-align-last enabled by default.

+ +

To include both of these data points, you can make the value of the "chrome" submember an array containing two support information objects, rather than just a single support information object:

+ +
"chrome": [
+  {
+    "version_added": "47"
+  },
+  {
+    "version_added": "35",
+    "version_removed": "47",
+    "flags": [
+      {
+        "type": "preference",
+        "name": "Enable Experimental Web Platform Features",
+        "value_to_set": "true"
+      }
+    ]
+  }
+],
+ +
+

Note: You should put the most current or important support point first in the array — this makes the data easier to read for people who just want to scan it for the latest info.

+
+ +

包含一个可选的名字

+ +

Occasionally browsers will support a feature under a different name to the name defined in its specification. This might be for example because a browser added experimental support for a feature early, and then the name changed before the spec stabilized.

+ +

To include such a case in the browser compat data, you can include a support information point that specifies the alternative name inside an "alternative_name" member.

+ +
+

Note: The alternative name might not be an exact alias — it might have differing behaviour to the standard version.

+
+ +

Let's look at an example. The {{cssxref("border-top-right-radius")}} property (see also border-top-right-radius.json) was supported in Firefox:

+ + + +

To represent this in the data, we used the following JSON:

+ +
"firefox": [
+  {
+    "version_added": "4",
+    "notes": "Prior to Firefox 50.0, border styles of rounded corners were always rendered as if <code>border-style</code> was solid. This has been fixed in Firefox 50.0."
+  },
+  {
+    "prefix": "-webkit-",
+    "version_added": "49",
+    "notes": "From Firefox 44 to 48, the <code>-webkit-</code> prefix was available with the <code>layout.css.prefixes.webkit</code> preference. Starting with Firefox 49, the preference defaults to <code>true</code>."
+  },
+  {
+    "alternative_name": "-moz-border-radius-topright",
+    "version_added": "1",
+    "version_removed": "12"
+  }
+],
+ +

将变更推送回主仓库

+ +

在您添加完您的兼容性数据之后，您应该先用以下命令测试一下：

+ + + +

If it is looking OK, you then need to commit it and push it back up to your remote fork on GitHub. You can do this easily with terminal commands like this:

+ +
git add .
+git commit -m 'adding compat data for name-of-feature'
+git push
+ +

Now go to your remote fork (i.e. https://github.com/your-username/browser-compat-data) and you should see information about your push at the top of the files list (under "Your recently pushed branches"). You can create a pull request (starting the process of pushing this to the main repo) by pressing the "Compare & pull request" button, then following the simple prompts on the subsequent screen.

+ +

At this point, you just need to wait. A reviewer will review your pull request, and merge it with the main repo, OR request that you make changes. If changes are needed, make the changes and submit again until the PR is accepted.

+ +

将数据插入MDN页

+ +

Once your new data has been included in the main repo, you can start dynamically generating browser compat tables based on that data on MDN pages using the \{{Compat}} macro. This takes a single parameter, the dot notation required to walk down the JSON data and find the object representing the feature you want to generate the compat table for.

+ +

Above the macro call, to help other contributors finding their way, you should add a hidden text that is only visible in MDN contributors in edit mode:

+ +
<div class="hidden">
+<p>此页面上的兼容性表格由结构化数据生成。如果你想贡献数据，可以看看 <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a>并向我们发送 pull request.</p>
+</div>
+ +

As an example, on the {{httpheader("Accept-Charset")}} HTTP header page, the macro call looks like this: \{{Compat("http.headers.Accept-Charset")}}. If you look at the accept-charset.json file in the repo, you'll see how this is reflected in the JSON data.

+ +

As another example, The compat table for the {{domxref("VRDisplay.capabilities")}} property is generated using \{{Compat("api.VRDisplay.capabilities")}}. The macro call generates the following table (and corresponding set of notes):

+ +
+ + +

{{Compat("api.VRDisplay.capabilities")}}

+ +
+

注意: 文件名通常与给予JSON结构内的接口的标签相匹配，但事实并非总是如此。 当宏调用生成表时，他们遍历所有文件，直到找到相关的JSON使用，所以文件名不是关键。 说到这一点，你应该始终尽可能直观地命名它们。

+
diff --git a/files/zh-cn/mdn/structures/index.html b/files/zh-cn/mdn/structures/index.html new file mode 100644 index 0000000000..aee298c70e --- /dev/null +++ b/files/zh-cn/mdn/structures/index.html @@ -0,0 +1,18 @@ +--- +title: 文档结构 +slug: MDN/Structures +tags: + - Landing + - MDN Meta + - NeedsTranslation + - Structures + - TopicStub +translation_of: MDN/Structures +--- +
{{MDNSidebar}}
+ +
{{IncludeSubnav("/zh-CN/docs/MDN")}}
+ +

在MDN里有各式各样的重复使用的文档结构，来使MDN文章中的内容有一致性的表现。这里的文章描述了这些结构。因此作为一名MDN的作者，你可以确认、应用并修改成适合于你写、编辑或翻译的文档。

+ +

{{LandingPageListSubPages()}}

diff --git a/files/zh-cn/mdn/structures/live_samples/index.html b/files/zh-cn/mdn/structures/live_samples/index.html new file mode 100644 index 0000000000..0b50a1b8f7 --- /dev/null +++ b/files/zh-cn/mdn/structures/live_samples/index.html @@ -0,0 +1,213 @@ +--- +title: 运行实例 +slug: MDN/Structures/Live_samples +tags: + - Guide + - Intermediate + - MDN Meta + - NeedsTranslation + - Structures + - TopicStub +translation_of: MDN/Structures/Live_samples +--- +
{{MDNSidebar}}

MDN 支持将文章中的示例代码转化为运行实例。运行实例可以包括 HTML、CSS、 JavaScript 的任意组合。注意，“运行”的实例是 非交互性 的。它们仅仅由代码示例生成，只是用来展示示例的输出效果。本文在JavaScript语法的基础上说明了该系统的集体使用。

+ +

运行实例系统如何工作

+ +

运行实例系统将所有代码整合为一个集合，再将这个集合融合到一个 HTML 文件中，然后在 内联框架{{HTMLElement("iframe")}} 中渲染这个文件。一个运行实例由两个部分构成：

+ + + +

一个代码块的集合，在此上下文中，以行级或块级元素（类似 {{HTMLElement("div")}} ）的 id作为标识。

+ + + +

宏使用一个特殊的 URL 来取得一个分组中的代码示例：http://url-of-page$samples/group-id。 group-id 指代码所在行级或者块级元素的id。用来展示运行结果的框架(或页面)会运行在沙盒中，在安全条件下实现任何想在网络上实现的功能。当然，在实践中，代码需要针对于包含它的页面，否则会被社区编辑移除。

+ +
+

注意：必须使用宏来展示运行实例的输出。为保安全，MDN 编辑器将会移除直接使用 <iframe> 标签的地方。

+
+ +

每个包含示例代码的 {{HTMLElement("pre")}}  段落都有一个 class 指示它由何种语言写成（HTML、CSS 或 JavaScript）。这些 class 的值是“brush: html”、“brush: css”或“brush: js”。这些 class 必须与代码匹配以被维基正确使用。一般情况下，当你在使用编辑器工具栏的语法高亮时候，这些属性会被自动添加。

+ +

运行实例系统由很多可用选项，我们会分解开来讲解。

+ +

运行实例宏

+ +

你可以用两种宏来展示实例：

+ + + +

在很多情况下，可以很便捷地使用以上两种宏 EmbedLiveSample 或 LiveSampleLink 。只要代码示例可以通过一个行级元素的id 或一个块级元素的id 的区分开，就可以简单的插入宏来实现功能。

+ +

页内运行实例宏

+ +
 \{{EmbedLiveSample(block_ID, width, height, screenshot_URL, page_slug)}}
+ +
+
block_ID
+
必需。包含示例代码的元素的 id 。保证 ID正确的最好的办法是在内容表中查看 URL。
+
width
+
可选。创建的 {{HTMLElement("iframe")}} 元素的宽度，以 px 为单位。若忽略该项，系统会使用一个合理的默认宽度。请注意，如果需要指定该项，那么必须同时指定高度。
+
height
+
可选。创建的 {{HTMLElement("iframe")}} 元素的高度，以 px 为单位。若忽略该项，系统会使用一个合理的默认高度。请注意，如果需要指定该项，那么必须同时指定宽度。如果仅仅指定了高度和宽度中的一个，那么系统会应用默认尺寸。
+
screenshot_URL
+
可选。截屏 URL 显示了运行实例的效果。对于用户浏览器尚未支持的新技术很有用，他们就可以看到结果的快照。如果指定该项，截屏会带着相关标题显示在运行实例之后。
+
page_slug
+
可选。包含示例的页面的代称。若忽略该项，示例将会从宏所在页面拉取。
+
+ +
    +
+ +

链接运行实例宏

+ +
 \{{LiveSampleLink(block_ID, link_text)}}
+ +
+
block_ID
+
必需。根据标题或段落的 ID 识别示例。保证正确使用 ID 最好的办法是在页面的目录中查找 URL。
+
link_text
+
链接地址文本。
+
+ +

使用运行实例系统

+ +

以下部分描述了一些运行实例系统的常见用例。

+ +

在所有这些用例中，必须点击编辑器的“保存更改”（将关闭编辑模式）才能看到运行实例。“预览变更”功能不可展示运行实例。

+ +

将片段转为运行实例

+ +

一个常见的用例是将 MDN 中已有代码片段转为运行实例。

+ +

准备代码示例

+ +

第一步是添加代码片段，或根据内容和标记确认已有片段可以成为运行实例。代码片段必须组成一个完整可运行的示例。比如，如果已有 CSS 片段，那么需要添加一段 HTML。

+ +

每段代码都需要包含在正确标记其语言的 {{HTMLElement("pre")}} 块中，每块中只能包含一种语言。多数情况下，这些步骤都没问题，不过再检查一遍总是好的。工具栏中 PRE 图标旁的按钮是一个提供选择语法的下拉框（语法高亮）。该选项除了设置语法高亮以外，还标记了代码片段在运行实例系统中的语言。

+ +
+

注意：每种语言的代码可以分布在几个 {{HTMLElement("pre")}} 块里，所有代码会被连接起来。这个特性允许一块代码对应一块简介。这样有利于制作教程，比如代码间夹杂着大量的注释。

+
+ +

所以确认代码块被正确标记为其所用语言，然后你可以继续了。

+ +
+

注意：当向MDN中粘贴内容时，请注意在粘贴带样式的内容时，可能会带来不需要的样式（比如复制高亮代码）。请尽量避免粘贴带样式的内容，在必须的情况下，请在源码模式中删除不需要的样式，或者使用“粘贴为纯文本”。

+
+ +

插入运行实例宏

+ +

当代码准备好并被正确标记之后，需要插入宏来创建 iframe。

+ +
    +
  1. 点击“插入运行实例框架”按钮（），将会打开一个对话框可以配置。
    2. +
  2. +

    在 Document 下方，输入包含实例的文章标题。默认是当前正被编辑的文章，但是可以被更改为 MDN 中的其它文章。这项特性允许在不同的页面中重用实例。（如果输入文字，将会出现一个部分匹配输入内容文章列表，可以从中选取需要的文章。）

    +
    3. +
  3. 在 Sections in Document 选项中，选取需要将包含实例的部分。
    4. +
  4. 点击 OK 按钮，生成并将宏插入到文章中，宏调用代码看起来是这样的：
    + \{{ EmbedLiveSample('Live_sample_demo') }}
    5. +
+ +

增加新的运行实例

+ +

在编辑一个新的一页需要插入运行实例时，编辑器做更多工作。

+ +
    +
  1. 点击 Insert Code Sample Template 按钮（），将会出现这样的对话框。
    +
    2. +
  2. 输入运行实例的标题，请确保标题对于当前页面是有意义的。
    3. +
  3. 点击 OK。会创建一个新的标题，还有一个空的代码框，可以输入 HTML、CSS 或 JavaScript。
    4. +
  4. 删除不需要的标题的代码框。
    5. +
  5. 输入代码
    6. +
+ +

查找需要更新的示例

+ +

当查询实例的时候，有三种可能的更新方式。

+ + + +
+

注意：如果发现包含需要更新到运行实例系统的文章，请为文章增加标签“ NeedsLiveSample ”。

+
+ +

查找需要转为运行实例的示例

+ +

MDN 上有很多老版本的并且使用运行实例系统的示例。我们希望可以将多数示例更新到运行实例。这将会提升网站的一致性和可用性。在访问 MDN 时，你一定经常看到这些例子。然而，很难如果你想要找到某个特定的例子来更新，不过有一些方法可以试一试。

+ + + +

运行实例演示

+ +

这部分是使用“插入运行实例模板”按钮插入运行实例标题和代码块的结果。每种语言可以有不止一个代码块。同样也不需要有特定的顺序，所有代码会被混合匹配。

+ +

可以选取删除任何部分。如果不需要脚本，那么删掉脚本的标题和代码块就可以了。同样，也可以删掉其余任何代码块。

+ +

代码模板插入之后，可以增加一些代码，也可以加入一些注释。

+ +

HTML

+ +

这段 HTML 代码创建了一个段落和几个 DIV 可以展示信息。

+ +
<p>A simple example of the live sample system in action.</p>
+<div class="box">
+  <div id="item">Hello world!</div>
+</div>
+
+ +

CSS

+ +

这段 CSS 代码为信息增加样式。

+ +
.box {
+  width: 200px;
+  height: 100 px;
+  border-radius: 6px;
+  background-color: #ffaabb;
+}
+
+#item {
+  width: 100%;
+  font-weight: bold;
+  text-align: center;
+  font-size: 2em;
+}
+
+ +

JavaScript

+ +

这段代码很简单，只是增加了一个点击事件来弹出信息。

+ +
var el = document.getElementById('item');
+el.onclick = function() {
+  alert('Owww, stop poking me!');
+}
+
+ +

这里通过\{{EmbedLiveSample('Live_sample_demo')}}来展示上面实例运行的结果。

+ +

{{EmbedLiveSample('Live_sample_demo')}}

+ +

这是使用外链宏\{{LiveSampleLink('Live_sample_demo', 'Live sample demo link')}}来展示实例运行的结果。

+ +

{{LiveSampleLink('Live_sample_demo', 'Live sample demo link')}}的集合

diff --git a/files/zh-cn/mdn/structures/live_samples/simple_live_sample_demo/index.html b/files/zh-cn/mdn/structures/live_samples/simple_live_sample_demo/index.html new file mode 100644 index 0000000000..d0ca0069fb --- /dev/null +++ b/files/zh-cn/mdn/structures/live_samples/simple_live_sample_demo/index.html @@ -0,0 +1,31 @@ +--- +title: A simple demo of a live code sample +slug: MDN/Structures/Live_samples/Simple_live_sample_demo +translation_of: MDN/Structures/Live_samples/Simple_live_sample_demo +--- +
{{MDNSidebar}}

The_example

+ +

This is a very simple example showing you how to do a live demo in MDN. For more information, see Live samples.

+ +
<form>
+  <label>Try me<input type="text" name="name"></label>
+  <input type="submit" value="go">
+</form>
+ +
form {
+  border-radius: 10px;
+  background: powderblue;
+}
+ +
var f = document.querySelector('form');
+
+f.addEventListener('submit', function(ev) {
+  ev.preventDefault();
+  document.querySelectorAll('input')[1].value = 'sending';
+}, false);
+ +

{{ EmbedLiveSample('The_example', '', '', '') }}

+ +

 

+ +

 

diff --git a/files/zh-cn/mdn/structures/macros/custom_macros/index.html b/files/zh-cn/mdn/structures/macros/custom_macros/index.html new file mode 100644 index 0000000000..3809bb2094 --- /dev/null +++ b/files/zh-cn/mdn/structures/macros/custom_macros/index.html @@ -0,0 +1,222 @@ +--- +title: 常用的宏 +slug: MDN/Structures/Macros/Custom_macros +tags: + - CSS + - 参考 + - 宏 + - 结构 +translation_of: MDN/Structures/Macros/Commonly-used_macros +--- +
{{MDNSidebar}}
+ +

本页列举了许多被创建用于 MDN 的通用宏。对于使用这些宏的基础信息，见使用宏和使用链接宏。对于不常用的，只在特定上下文或不赞成使用的宏的信息，参见其它宏。这里也有一份 MDN 上所有宏的完整列表。

+ +

对于适合你使用的样式，另见 CSS 样式指南。

+ +

链接

+ +

创建一个单独的超链接

+ +

通常来说，你不需要使用宏来创建任意的链接。使用编辑器界面上的链接按钮创建链接。

+ + + +

链接到参考文档页面

+ +

有各种宏用来链接到 MDN 上特定参考区域里的页面。

+ + + +

链接到漏洞和互联网中继聊天（IRC）

+ + + +

用于多页面指南的导航帮助

+ +

{{TemplateLink("Previous")}}，{{TemplateLink("Next")}}，和 {{TemplateLink("PreviousNext")}} 提供导航控制用于序列中的部分文章。对于单向模板，唯一需要的参数是序列中前一篇或后一篇文章的维基（wiki）地址。对于 {{TemplateLink("PreviousNext")}}，需要两个适当的文章地址作为参数。第一个参数用于前一篇文章，而第二个用于后一篇文章。

+ +

代码示例

+ +

实样

+ + + +

附上的示例文件

+ + + +

侧边栏组

+ +

There templates for almost every large collection of pages. 它们通常链接回参考/指南/教程的主页面（这经常被需要，因为我们的面包屑有时做不到这样）并把文章放入适当的类别中。

+ + + +

（译者注：通过在 background-color 页面测试，编辑页面中 "Summary" 上一行的 {{CSSRef}} 用于生成页面左侧的 CSS 参考链接的侧边栏）

+ +

通用格式化

+ +

API 文档的行内指示器

+ +

{{TemplateLink("optional_inline")}} 和 {{TemplateLink("ReadOnlyInline")}} 被用于 API 文档，通常当描述一个对象的属性或一个函数的参数的列表。

+ +

用法: \{{optional_inline()}} 或 \{{ReadOnlyInline()}} 。示例：

+ +
+
isCustomObject {{ReadOnlyInline()}}
+
如果为真，指示该对象是一个自定义对象。
+
parameterX {{ optional_inline() }}
+
Blah blah blah...
+
+ +

状态和兼容性指示器

+ +

没有附加参数的行内指示器

+ +

非标准的

+ +

{{TemplateLink("non-standard_inline")}} 插入一个行内标记指示当前 API 还没有被标准化，并且不在一个标准行径上。

+ +
语法
+ +

\{{non-standard_inline}}

+ +
示例
+ + + +

实验性的

+ +

{{TemplateLink("experimental_inline")}} 插入一个行内标记指示当前 API 没有被广泛地实现，并且在以后可能会改变。

+ +
语法
+ +

\{{experimental_inline}}

+ +
示例
+ + + +

提供明确技术的指示器

+ +

在这些宏当中，其参数（在明确规定下）应该是 "html", "js", "css" 或 "gecko" 当中的一个字符串，其后跟着版本号。

+ +

不赞成的

+ +

{{TemplateLink("deprecated_inline")}} 插入一个不赞成的行内标记来劝阻一个官方不赞成的 API 的使用。注意：“不赞成的”表示该项不该再被使用，但是仍然可用。如果你想表示它不再起作用了，使用术语“已废弃”。

+ +

不要在任何浏览器不可知的区域（ HTML, APIs, JS, CSS, … ）内使用参数。

+ +
语法
+ +

\{{deprecated_inline}} 或 \{{deprecated_inline("gecko5")}}

+ +
示例
+ + + +

已废弃的

+ +

{{TemplateLink("obsolete_inline")}} 插入一个已废弃的行内标记来阻止使用，比如正式废弃的一个函数，方法或属性。

+ +

不要在任何浏览器不可知的区域（ HTML, APIs, JS, CSS, … ）内使用参数。

+ +
语法
+ +

\{{obsolete_inline}} 或 \{{obsolete_inline("js1.8.5")}}

+ +
示例
+ + + +

模板徽标

+ +

这些宏大多数被用于 WebAPI 页面。见 {{anch("Creating new badges")}} 关于创建一个新徽标的信息。

+ +

页面或区域标头指示

+ +

这些模板与上述内联模板具有相同的语义。 模板应直接放置在参考页面的主页标题（或面包屑导航，如果可用）的下面。 它们也可以用于标记页面上的某个部分。

+ + + +

指示一个功能在Web workers中可用

+ +

 {{TemplateLink("AvailableInWorkers")}} 宏插入一个本地化的指示框，指示一个功能在Web worker 上下文中可用。

+ +

版本信息宏

+ +

这些宏被用来指示这个语段只与一个产品的特定版本有关。

+ + + +
    +
+ +
    +
diff --git a/files/zh-cn/mdn/structures/macros/index.html b/files/zh-cn/mdn/structures/macros/index.html new file mode 100644 index 0000000000..4ddb72e576 --- /dev/null +++ b/files/zh-cn/mdn/structures/macros/index.html @@ -0,0 +1,48 @@ +--- +title: Macros +slug: MDN/Structures/Macros +tags: + - Guide + - Kuma + - KumaScript + - MDN Meta + - Structures +translation_of: MDN/Structures/Macros +--- +
{{MDNSidebar}}
+ +

Kuma 平台为 MDN 提供了强大的宏系统——KumaScript，使得 MDN 能够自动地去做各种东西。本文提供一些信息以便大家知道如何使用 MDN 上的文章内的宏。

+ +

鉴于本文只是 KumaScript 的简介，KumaScript 指南提供了更深入的内容。

+ +

宏是如何实现的

+ +

MDN使用的Macros(宏)是基于Node.js执行环境，并在服务端执行运行。这里包括了大量的代码库，另外对此还提供了丰富的wiki说明文档内容。如果你希望能学习到更多的内容，可以查看 KumaScript 指南， KumaScript reference 则提供了更多关于这些代码库和KumaScript的API的实现机理。

+ +

在文章中使用宏

+ +

要实际使用宏，只需将对宏的调用括在一对双括号中，其参数（如果有）括在括号中;如下：

+ +
\{{macroname(parameter-list)}}
+ +

关于宏调用的一些注意事项：

+ + + +

宏被高度缓存;对于任何一组输入值（参数和环境值，例如运行宏的URL），结果都会被存储和重用。这意味着宏仅在输入发生变化时才实际运行。

+ +
+

注意: 您可以通过在浏览器中强制刷新页面（即转移重新加载）来强制重新评估页面上的所有宏。

+
+ +

宏可以像插入更大的文本块或从MDN的另一部分交换内容一样简单，也可以通过搜索站点的各个部分，设置输出样式和添加链接来构建整个内容索引。

+ +

您可以在Commonly-used macros页面上阅读我们最常用的宏;另外，这里有complete list of all macros。大多数宏都有内置的文档，作为顶部的注释。

+ +

{{EditorGuideQuicklinks}}

diff --git a/files/zh-cn/mdn/user_guide/writing/index.html b/files/zh-cn/mdn/user_guide/writing/index.html new file mode 100644 index 0000000000..5b2c6762f3 --- /dev/null +++ b/files/zh-cn/mdn/user_guide/writing/index.html @@ -0,0 +1,64 @@ +--- +title: 写作内容 +slug: MDN/User_guide/Writing +tags: + - 写作内容 +translation_of: Archive/Meta_docs/Writing_content +--- +

在MDN上经常会有一些东西需要加进来和更新。不管是一个全新出彩API的文档或者一个旧API的细微修改，你会找到很多可以出力的机会。关于怎么使用编辑器，和我们为了自动化结构与内容格式使用的宏系统的细节，请参看MDN editor guide。

+

编辑一个已经存在的页面

+

如果你找到一个想去修正的页面，简单点击右上方的“编辑”按钮。这会打开一个 WYSIWYG编辑器来帮助你修改页面内容。

+

有很多原因你会去编辑一个已经存在的页面：

+ +

增加一个新页面

+

这是个大的任务！在MDN上添加一个新的页面会让Web爱上你，拥抱你。这里有一些显而易见的原因，包括给未文档化的API做文档，增加一个新的教程或者?做一个主题的指南。

+

当你登陆后，按以下步骤去创建一个新的页面在MDN上:

+
+
+ 点击一个 "missing page" 链接
+
+ 当你浏览MDN的时候，你会偶然发现有些链接的页面还不存在。很多时候，当我们创建文章，我们会把需要创建的页面链接加进去，即使它们还没做好。这有助于我们跟踪那些最终需要完成的事，虽然有时候会花一些时间回过去完成它们。你可以随意去做！只要点击这些链接，你会直接进入新网页的编辑器。
+
+  
+
+ 创建一个子页面
+
+ 在每篇文章的最右上角是“This Page“下拉菜单。菜单里面有”New sub-page“选项。点击这个选项会打开一个页面编辑器，在这个新的页面在站点层次上的父页面是你选择”New sub-page“那个页面。只需填写标题和标签，就可以开始写正文了。
+
+ 创建一个副本
+
+ 你也可以克隆一个已经存在的页面，使用“This page“下拉菜单的”Clone this page“选项。点击该选项会复制当前页面，其父页面和当前页面完全相同。接着页面上会打开编辑器，你就可以设置页面的标题和标签，然后编辑页面的内容。给一个现有站点参考区域增加一个新的页面，通常是一个好的方式。比如，这会给你内容布局的样式。
+
+ 创建一个链接到还没存在的页面，然后点击它
+
+ 这有点儿混合模式。因为每个页面应该被某处链接到，你可以从给一个新的文章创建一个已有页面的链接开始，然后保存页面。你可以点击你刚刚插入的链接，接着在打开的编辑器中写新的文章。
+
+

 

+

 

+
+

注意：如果你没有登录，当你想要查看未存在的文章时，会跳出404错误提示，而不是跳出新页面的编辑器。

+
+

寻找信息

+

有很多信息没有出现在这里。有时候这些信息你很难搜寻到，但你恰好很需要用到，这里有一些提示来帮助你。

+
+
+ 模块化所有者列表
+
+ Mozilla的项目在一个“模块所有者”基础上进行；每一个重要的组件都有一个或者多个所有者负责它的进展。这些所有者往往是信息的最好来源--至少是个好的方式找到对的人来讨论。
+
+ Mozilla源交叉参考
+
+ MXR（Mozilla cross-reference的缩写）能让你得到所有Mozilla工程的源代码（有些事例除外，比如Firefox OS是托管在Github上）。代码和有关评论常常是信息的重要资源。
+
+ Mozilla wiki
+
+ The Mozilla wiki（常被称作“wikimo“）是过程和设计的一些笔记，草稿，计划和初步的方案等。尽管看起来一团糟，但也是宝贵的知识库。
+
-- cgit v1.2.3-54-g00ecf