From 2c2df5ea01eb5cd8b9ea226b2869337e59c5fe3e Mon Sep 17 00:00:00 2001 From: Florian Merz Date: Thu, 11 Feb 2021 14:50:24 +0100 Subject: unslug pt-pt: move --- files/pt-pt/mdn/about/index.html | 127 ++++ files/pt-pt/mdn/at_ten/history_of_mdn/index.html | 225 +++++++ files/pt-pt/mdn/at_ten/index.html | 39 ++ .../conversa\303\247\303\265es/index.html" | 58 -- files/pt-pt/mdn/comunidade/doc_sprints/index.html | 125 ---- files/pt-pt/mdn/comunidade/index.html | 56 -- .../o_que_est\303\241_a_acontecer/index.html" | 42 -- .../comunidade/trabalhar_em_comunidade/index.html | 102 ---- .../index.html | 36 -- .../index.html | 47 -- .../howto/como_efetuar_revisao_tecnica/index.html | 65 -- .../index.html | 114 ---- .../index.html | 114 ---- .../howto/comunicar_um_problema/index.html | 24 - .../convert_code_samples_to_be_live/index.html | 36 ++ .../howto/create_and_edit_pages/index.html | 181 ++++++ .../howto/criar_e_editar_paginas/index.html | 181 ------ .../howto/criar_uma_conta_mdn/index.html | 41 -- .../pt-pt/mdn/contribute/howto/etiqueta/index.html | 375 ------------ .../fazer_revis\303\243o_editorial/index.html" | 56 -- .../howto/marcar_paginas_javascript/index.html | 75 --- .../howto/participar_testes_beta/index.html | 52 -- .../contribute/howto/report_a_problem/index.html | 24 + files/pt-pt/mdn/contribute/howto/tag/index.html | 375 ++++++++++++ .../write_a_new_entry_in_the_glossary/index.html | 114 ++++ .../write_an_api_reference/sidebars/index.html | 109 ++++ files/pt-pt/mdn/editor/basicos/index.html | 72 --- files/pt-pt/mdn/editor/index.html | 20 - .../guidelines/convencoes_definicoes/index.html | 201 ------- .../guidelines/conventions_definitions/index.html | 201 +++++++ .../guidelines/does_this_belong_on_mdn/index.html | 200 ++++++ .../guia_de_estilo_de_escrita/index.html | 667 --------------------- .../mdn/guidelines/isto_pertence_a_mdn/index.html | 200 ------ .../mdn/guidelines/writing_style_guide/index.html | 667 +++++++++++++++++++++ files/pt-pt/mdn/kuma/index.html | 24 - files/pt-pt/mdn/sobre/index.html | 127 ---- .../index.html | 109 ---- .../pt-pt/mdn/structures/api_references/index.html | 58 -- .../index.html | 162 ----- .../pt-pt/mdn/structures/exemplos_live/index.html | 248 -------- files/pt-pt/mdn/structures/live_samples/index.html | 248 ++++++++ .../edi\303\247\303\243o_de_modelo/index.html" | 12 - files/pt-pt/mdn/tools/vigiar_pagina/index.html | 49 -- files/pt-pt/mdn/troubleshooting/index.html | 71 --- files/pt-pt/mdn/yari/index.html | 24 + 45 files changed, 2570 insertions(+), 3583 deletions(-) create mode 100644 files/pt-pt/mdn/about/index.html create mode 100644 files/pt-pt/mdn/at_ten/history_of_mdn/index.html create mode 100644 files/pt-pt/mdn/at_ten/index.html delete mode 100644 "files/pt-pt/mdn/comunidade/conversa\303\247\303\265es/index.html" delete mode 100644 files/pt-pt/mdn/comunidade/doc_sprints/index.html delete mode 100644 files/pt-pt/mdn/comunidade/index.html delete mode 100644 "files/pt-pt/mdn/comunidade/o_que_est\303\241_a_acontecer/index.html" delete mode 100644 files/pt-pt/mdn/comunidade/trabalhar_em_comunidade/index.html delete mode 100644 files/pt-pt/mdn/contribute/howto/como_converter_exemplos_de_codigo_para_ficarem_live/index.html delete mode 100644 files/pt-pt/mdn/contribute/howto/como_definir_o_resumo_para_uma_pagina/index.html delete mode 100644 files/pt-pt/mdn/contribute/howto/como_efetuar_revisao_tecnica/index.html delete mode 100644 files/pt-pt/mdn/contribute/howto/como_escrever_um_artigo_para_ajudar_as_pessoas_a_aprenderem_sobre_a_web/index.html delete mode 100644 files/pt-pt/mdn/contribute/howto/como_escrever_uma_nova_entrada_no_glossario/index.html delete mode 100644 files/pt-pt/mdn/contribute/howto/comunicar_um_problema/index.html create mode 100644 files/pt-pt/mdn/contribute/howto/convert_code_samples_to_be_live/index.html create mode 100644 files/pt-pt/mdn/contribute/howto/create_and_edit_pages/index.html delete mode 100644 files/pt-pt/mdn/contribute/howto/criar_e_editar_paginas/index.html delete mode 100644 files/pt-pt/mdn/contribute/howto/criar_uma_conta_mdn/index.html delete mode 100644 files/pt-pt/mdn/contribute/howto/etiqueta/index.html delete mode 100644 "files/pt-pt/mdn/contribute/howto/fazer_revis\303\243o_editorial/index.html" delete mode 100644 files/pt-pt/mdn/contribute/howto/marcar_paginas_javascript/index.html delete mode 100644 files/pt-pt/mdn/contribute/howto/participar_testes_beta/index.html create mode 100644 files/pt-pt/mdn/contribute/howto/report_a_problem/index.html create mode 100644 files/pt-pt/mdn/contribute/howto/tag/index.html create mode 100644 files/pt-pt/mdn/contribute/howto/write_a_new_entry_in_the_glossary/index.html create mode 100644 files/pt-pt/mdn/contribute/howto/write_an_api_reference/sidebars/index.html delete mode 100644 files/pt-pt/mdn/editor/basicos/index.html delete mode 100644 files/pt-pt/mdn/editor/index.html delete mode 100644 files/pt-pt/mdn/guidelines/convencoes_definicoes/index.html create mode 100644 files/pt-pt/mdn/guidelines/conventions_definitions/index.html create mode 100644 files/pt-pt/mdn/guidelines/does_this_belong_on_mdn/index.html delete mode 100644 files/pt-pt/mdn/guidelines/guia_de_estilo_de_escrita/index.html delete mode 100644 files/pt-pt/mdn/guidelines/isto_pertence_a_mdn/index.html create mode 100644 files/pt-pt/mdn/guidelines/writing_style_guide/index.html delete mode 100644 files/pt-pt/mdn/kuma/index.html delete mode 100644 files/pt-pt/mdn/sobre/index.html delete mode 100644 files/pt-pt/mdn/structures/api_references/barras_laterais_de_referencia_da_api/index.html delete mode 100644 files/pt-pt/mdn/structures/api_references/index.html delete mode 100644 files/pt-pt/mdn/structures/api_references/o_que_e_que_uma_referencia_de_api_precisa/index.html delete mode 100644 files/pt-pt/mdn/structures/exemplos_live/index.html create mode 100644 files/pt-pt/mdn/structures/live_samples/index.html delete mode 100644 "files/pt-pt/mdn/tools/edi\303\247\303\243o_de_modelo/index.html" delete mode 100644 files/pt-pt/mdn/tools/vigiar_pagina/index.html delete mode 100644 files/pt-pt/mdn/troubleshooting/index.html create mode 100644 files/pt-pt/mdn/yari/index.html (limited to 'files/pt-pt/mdn') diff --git a/files/pt-pt/mdn/about/index.html b/files/pt-pt/mdn/about/index.html new file mode 100644 index 0000000000..1da67e04e5 --- /dev/null +++ b/files/pt-pt/mdn/about/index.html @@ -0,0 +1,127 @@ +--- +title: Sobre a MDN +slug: MDN/Sobre +tags: + - Colaboração + - Comunidade + - Direitos de Autor + - Documentação + - Guía + - Licenças + - Metadados da MDN +translation_of: MDN/About +--- +
{{MDNSidebar}}
+ +
{{IncludeSubnav("/pt-PT/docs/MDN")}}
+ +

MDN Web Docs é uma plataforma de aprendizagem em evolução para as tecnologias da Web e software que energiza a Web, incluindo:

+ + + +

A nossa missão

+ + + +

A missão da MDN é simples: proporcionar aos programadores a informação que eles precisam para criarem facilmente projetos na Web aberta. Se é uma tecnologia aberta exposta à Web, nós queremos documentá-la.

+ +

Além disso, nós proporcionamos documentação sobre os produtos Mozilla e como criar e contribuir para os projetos da Mozilla.

+ +

Se não tiver a certeza se um tópico em particular deve ser abrangido na MDN, leia: Isso pertence ao MDN?

+ + + +

Como é que pode ajudar

+ + + +

Não precisa de ser capaz de programar - ou escrever bem - para poder ajudar a MDN! Nós temos muitas maneiras em que pode ajudar, desde rever artigos para ter a certeza de que fazem sentido, para contribuir com texto, para adicionar código de exemplo. De facto, existem muitas maneiras de ajudar que nós temos uma página de Primeiros Passos que o ajuda a escolher as tarefas para fazer, com base nos seus interesses e quanto tempo é que tem para contribuir!

+ +

Também pode ajudar a promover a MDN no seu próprio blogue ou site da Web.

+ + + +

A comunidade da MDN

+ +

Nossa comunidade é global! Temos colaboradores incríveis em todo o mundo, em vários idiomas. Se você quiser saber mais sobre nós, ou se precisar de ajuda de qualquer tipo com o MDN, fique à vontade para visitar nosso fórum de discussão ou canal de IRC! Você também pode acompanhar o que estamos fazendo seguindo nossa conta no Twitter, @MozDevNet. Você também pode enviar tweets para nós, se você vir algo errado ou se você gostaria de oferecer feedback (ou quiser nos agradecer) aos nossos escritores e colaboradores!

+ +

Utilizar conteúdo da MDN Web Docs

+ +

O conteúdo da MDN está disponível gratuitamente, e sob as licenças de código aberto.

+ +

Direitos de Autor e Licenças

+ +

O conteúdo da MDN está totalmente disponível sob várias licenças de código aberto. Esta secção cobre os tipos de conteúdo que nós proporcionamos e quais as licenças em vigor para cada.

+ +

Documentação e artigos

+ +

MDN wiki documents have been prepared with the contributions of many authors, both within and outside the Mozilla Foundation. Unless otherwise indicated, the content is available under the terms of the Creative Commons Attribution-ShareAlike license (CC-BY-SA), v2.5 or any later version. Please attribute "Mozilla Contributors" and include a hyperlink (online) or URL (in print) to the specific wiki page for the content being sourced. For example, to provide attribution for this article, you can write:

+ +
Sobre a MDN, pelos Colaboradores da Mozilla (inglês) está licenciado sob CC-BY-SA 2.5.
+ +

Note that in the example, "Mozilla Contributors" links to the history of the cited page. See Best practices for attribution (EN) for further explanation.

+ +
+

Nota: consulte o conteúdo da MDN em WebPlatform.org para informação sobre como reutilizar e atribuir conteúdo MDN nesse site.

+
+ +

Code samples and snippets

+ +

Code samples added to this wiki before August 20, 2010 are available under the MIT license; you should insert the following attribution information into the MIT template: "© <date of last wiki page revision> <name of person who put it in the wiki>".

+ +

Code samples added on or after August 20, 2010 are in the public domain. No licensing notice is necessary, but if you need one, you can use: "Any copyright is dedicated to the Public Domain. http://creativecommons.org/publicdomain/zero/1.0/".

+ +

Contribuições

+ +

If you wish to contribute to this wiki, you must make your documentation available under the Attribution-ShareAlike license (or occasionally an alternative license already specified by the page you are editing), and your code samples available under Creative Commons CC-0 (a Public Domain dedication). Adding to this wiki means you agree that your contributions will be made available under those licenses.

+ +

Some older content was made available under a license other than the licenses noted above; these are indicated at the bottom of each page by way of an Alternate License Block.

+ +
+

Não podem ser criadas novas páginas utilizando licenças alternativas.

+
+ +

Os direitos de autor para os materiais contribuídos permanecem com o autor, a menos que o mesmo o atribua a outra pessoa.

+ +

Se tiver quaisquer questões relacionadas ou problemas sobre qualquer coisa aqui discutida, por favor, contacte Eric Shepherd.

+ +

Logótipo, marcas registadas, marcas de serviço e wordmarks

+ +
+

The rights in the trademarks, logos, service marks of the Mozilla Foundation, as well as the look and feel of this web site, are not licensed under the Creative Commons license, and to the extent they are works of authorship (like logos and graphic design), they are not included in the work that is licensed under those terms. If you use the text of documents, and wish to also use any of these rights, or if you have any other questions about complying with our licensing terms for this collection, you should contact the Mozilla Foundation here: licensing@mozilla.org.

+ +

Interligação com a MDN

+ +

See this article for guidance on linking to MDN for best practices when linking.

+ +

Transferência de conteúdo

+ +

Pode transferir um tarball mirror completo da MDN. (2.1GB, em fevereiro de 2017)

+ +

Páginas únicas

+ +

You can retrieve the content of a single page on MDN by adding document parameters to the URL to specify what format you want.

+ +

Ferramentas de terceiros

+ +

You can view MDN content via third-party tools like Dash (for Mac OS) and Zeal (for Linux and Windows).

+ +

Kapeli also publishes offline MDN docs covering HTML, CSS, JavaScript, SVG, and XSLT.

+ +

Comunicação de problemas com MDN Web Docs

+ +

Consultar "Como comunicar um problema na MDN".

+ +

Histórico da MDN Web Docs

+ +

MDN Web Docs (anteriormente Mozilla Developer Network (MDN), anteriormente projeto da Mozilla Developer Center (MDC), a.k.a. Devmo) começou no início de 2005, quando a Fundação Mozilla (inglês) obteve a licença da AOL para utilizar o conteúdo DevEdge original do Netscape. O conteúdo DevEdge foi minado para o material ainda útil, que foi migrado por voluntários para esta wiki, e assim esta seria mais fácil para atualizar e manter.

+ +

Pode encontrar mais história da MDN na nossa página de celebração do 10º. aniversário, incluindo uma história verbal por algumas das pessoas que estiverem envolvidas.

+ +

Sobre a Mozilla

+ +

Se quer saber mais sobre quem somos, como fazer parte da Mozilla ou apenas onde nos encontrar, veio ao lugar certo. Para descobrir o que nos impulsiona e nos torna diferentes, visite a nossa página da missão.

diff --git a/files/pt-pt/mdn/at_ten/history_of_mdn/index.html b/files/pt-pt/mdn/at_ten/history_of_mdn/index.html new file mode 100644 index 0000000000..ceaed18d08 --- /dev/null +++ b/files/pt-pt/mdn/at_ten/history_of_mdn/index.html @@ -0,0 +1,225 @@ +--- +title: A História da MDN +slug: MDN_at_ten/Historia_da_MDN +tags: + - História + - Metadados MDN +translation_of: MDN_at_ten/History_of_MDN +--- +
+

In this talk, several contributors of the MDN project look at the past ten years of developer.mozilla.org, and at the decade to come. You will hear the story of different wiki software migrations, how a documentation community was built, and many more highlights of the history of the site. The group then also talks about current challenges and projects the MDN community is working on this year.

+ +
+ + +

{{ EmbedLiveSample('audio', '100%', '60px') }}

+ +

Below, learn more about the people who are sharing their memories and thoughts, and get a deeper look at specific details they mention.

+
+
+ +
+
Justin Crawford + +

Justin Crawford Product Manager, MDN

+ +

Justin moderates this talk and makes things with code, words, bike parts, and lumber. He is @hoosteeno on Twitter.

+
+ +
+

O que é MDN, e para quem é? Um lugar para a comunidade Open Web  Um lugar para a comunidade da 'Web Aberta'

+ +

MDN provides useful information for Web technologies, and encourages learning, sharing, and teaching in the open Web community. On MDN, you come together and make things for yourself and for others.

+A place for Mozilla developers + +

MDN is also a place for Mozilla engineers, such as Gecko or Firefox hackers, add-on developers, and Firefox OS contributors.

+
+ +
Eric Shepherd + +

Eric "Sheppy" Shepherd Technical Writer, MDN

+ +

Sheppy has been here documenting for Mozilla since 2006, and has a lot of history (and crazy ideas) when it comes to MDC and MDN over the years. He is @sheppy on Twitter.

+
+ +
+

The history of MDN Pre-wiki era – Netscape DevEdge

+ +

In the early days there was DevEdge, the developer documentation from Netscape which formed the basis of some of MDN's documentation. Have a look at the past on archive.org:

+ +

Netscape DevEdge

+ +

On October 12, 2004, this popular developer website was shut down by AOL, Netscape's parent company. Only a few months later, in February 2005, Mitchell Baker was able to rescue DevEdge and reached an agreement with AOL that allowed Mozilla to post, modify, and create new documents based on the former Netscape DevEdge materials. In other words, what happened to the Mozilla source in 1998 finally happened for Netscape's developer documentation as well: It became open source.

+ +

Deb Richardson joined the Mozilla Foundation as a Technical Editor and lead the new DevMo project for community driven developer documentation.

+
+ +
+

MediaWiki The first wiki engine

+ +

With MediaWiki as the new underlying project platform, the Mozilla developer documentation has been made editable for anyone starting in July 2005. A new collaborative element in Mozilla was established and since then anyone is welcome to help making it better and to share knowledge. A new international community began to grow and to translate developer contents into other languages.

+ +

MDC MediaWiki

+
+ +
Florian Scholz + +

Florian Scholz Technical Writer, MDN

+ +

Florian is a Technical Writer at Mozilla focused on open web technologies. He is a wiki gnome, gardening the documentation as if it were flowers, and he likes to work with the community toward the goal of documenting the Web and making it accessible to everyone. Florian is passionate about open source, he is based in Bremen, Germany, and tweets as @floscholz on Twitter.

+
+ +
+

DekiWiki The second wiki engine

+ +

In August 2008, the Mozilla Developer Center switched to MindTouch DekiWiki, a powerful and new content management system and wiki system for technical documentation. This platform change was quite controversial in the community that was used to MediaWiki from 2005 on and built tools around it.

+ +

MDC DekiWiki

+
+ +
Ali Spivak + +

Ali Spivak Herder of awesome MDN cats

+ +

Ali Spivak manages content & community on the Mozilla Developer Network and spends her time thinking of ways to help make the Web even more awesome. She is passionate about maintaining a free and open Web, and, after jumping into open source when she joined Mozilla in 2012, has focused on building and participating in the developer communities at Mozilla. She is @alispivak on Twitter.

+
+ +
+

Kuma The third and current wiki engine

+ +

Kuma, forked from Kitsune in early 2011 and launched on August 3, 2012, is a Mozilla-built wiki platform based on Django with its own KumaScript macro system which uses Node.js.

+ +

With the code living on GitHub, the community started to contribute to MDN's CMS as well. From now on, hacking on MDN includes both writing documentation and Kuma coding.

+ +

MDN KUMA

+
+ +
David Walsh + +

David Walsh Web developer, MDN

+ +

Mozilla Sr. Web Developer, Front-End Engineer, MooTools Core Developer, Javascript Fanatic, CSS Tinkerer, PHP Hacker, web and open source lover. David is @davidwalshblog on Twitter.

+
+ +
+

Redesigning MDN Kuma with the refreshed design

+ +

The redesign of MDN was a big project. Sean Martell designed the new MDN visual identity. It was then an iterative process with a beta user group of 3000 MDNers during several months. The new look was behind a "Waffle flag" (MDN's feature flag system). Major shout-outs also to David Walsh who was really championing the entire redesign and gave MDN the front-end that it deserves.

+Waffle flag
+ +
Janet Swisher + +

Janet Swisher Community Manager, MDN

+ +

Janet is a Mozilla Community Manager for Mozilla Developer Network. She joined Mozilla in 2010, and has been involved in open source software since 2004 and in technical communication since the 20th century. She is @jmswisher on Twitter.

+
+ +
+

Community around Open Web docs Community-driven, browser-agnostic Open Web documentation

+ +

At some point in 2010, especially when community members and Technical Writers met in Paris, it became more obvious that MDN's focus is clearly shifting from "Let's document all things Firefox!" to "Let's document the Web!". Documentation has been cleaned up and restructured over the last few years, so that MDN's open Web documentation is browser-agnostic. This material, useful for anyone developing for the Web, is our most popular and most widely used content.

+ +

Different browser vendors have joined every once in a while to help shape this part of MDN. This cross-browser collaboration has been very successful and is appreciated by MDN's readers.

+
+ +
Luke Crouch + +

Luke Crouch Web developer, MDN

+ +

Luke Crouch is a home-brewer, soccer fan and web developer for Mozilla. He's been developing on the web since 1996, using Firefox since 2004, writing open source software since 2006, and joined Mozilla as the first staff MDN web dev in 2010. Luke is @groovecoder on Twitter.

+
+ +
+

Localization communities MDN serves a global audience in many languages

+ +

Localization is a big part of the Mozilla community; it is a component of almost every project and product. Using Kuma, MDN is also very localizable and suited for the needs of our l10n community. The W3C specifications and other resources describing the Web's functionality have no direct goals, and have communities that provide specs in multiple languages. Especially for beginners, MDN is the first step to explore web technologies, so it's our aim to be there for everyone. MDN has a broad audience and aims to include not only native English speakers. It is appreciated all around the globe.

+
+ +
Julien + +

Julien (a.k.a. Sphinx) French localization, MDN

+ +

Julien spent many nights and weekends over several month, translating JavaScript articles into French. He is not a developer, but has a background in IT and wants to learn more about new technologies. He contributes to MDN instead of watching TV.

+
+ +
Jean-Yves Perrier + +

Jean-Yves Perrier Technical Writer, MDN

+ +

Jean-Yves has been a Technical Writer on MDN since 2010 and joined Mozilla full-time at the end of 2011. He is passionate about the open Web, with 15 years of C++ experience. He is Swiss but lives in London, UK. His Erdös number is 5 and he is @Teoli2003 on Twitter.

+
+ +
+

Learning Area

+ +

The MDN Learning Area is a new effort to teach basic web skills. Over the last 10 years, MDN added a lot of advanced material, serving experts with valuable information. This project is focused on materials for beginners, and tries to fill in a lot of knowledge gaps.

+
+ +
Jérémie Patonnier + +

Jérémie Patonnier Technical Writer, MDN

+ +

Jérémie is a long time contributor to the Mozilla Developer Network, and a professional web developer since 2000. He's advocating web standards and write documentation about web technologies with the will to make them accessible to everybody. He is @JeremiePat on Twitter.

+
+ +
+

The future of MDN What will be different when we celebrate 20 years of MDN?

+ +

Everyone involved with MDN really cares about the web being open and accessible, and that's why we have the localization teams and all of the people contributing. MDN hopes to continue to be a key player in keeping the Web the way we feel it should be.

+ +

One big part of this future is going to be learning resources. There will be a lot more Web developers over the next ten years.

+ +

Another big part of our job is maintaining and updating the information we already have, so we can always serve relevant content to Web developers.

+ +

What is changing and will likely change more in the future, is how information is consumed. Today people searching for information and looking up documentation. In the future, MDN documentation might be delivered directly in code editors, Firefox Developer Tools, and many other developer tools and services.

+
+ +
+

Awesome contributors Many more people have done amazing work on MDN

+ +
+
    +
  • Les Orchard
    • +
  • John Karahalis
    • +
  • David Walsh
    • +
  • Jannis Leidel
    • +
  • Stephanie Hobson
    • +
  • James Bennett
    • +
  • Isac Lagerblad
    • +
  • Piotrek Koszuliński
    • +
  • Craig Cook
    • +
  • Rob Hudson
    • +
  • John Whitlock
    • +
  • ...
    + And many more Kuma contributors.
    • +
+ + +
    +
  • Chris Mills
    • +
  • Will Bamberg
    • +
  • David Bruant
    • +
  • Thierry Régagnon
    • +
  • etherthank
    • +
  • Saurabh Nair
    • +
  • Deb Richardson
    • +
  • Sebastian Zartner
    • +
  • Tooru Fujisawa
    • +
  • Karen Scarfone
    • +
  • Niklas Barning
    • +
  • ...
    + And hundreds more wiki collaborators.
    • +
+
+The Berlin Office
+
diff --git a/files/pt-pt/mdn/at_ten/index.html b/files/pt-pt/mdn/at_ten/index.html new file mode 100644 index 0000000000..fcd5f5875f --- /dev/null +++ b/files/pt-pt/mdn/at_ten/index.html @@ -0,0 +1,39 @@ +--- +title: 10.º Aniversário da MDN +slug: MDN_at_ten +tags: + - MDN +translation_of: MDN_at_ten +--- +
Celebrar 10 anos de documentação da sua Web.
+ +
+
+

A história da MDN

+ +

No início de 2005, uma pequena equipa de idealistas juntaram-se para criar uma comunidade nova e livre, de recursos on-line para todos os programadores da Web. Com a ideia brilhante mas estranha, cresceu até hoje para se tornar no que é hoje, a Rede de Desenvolvimento da Mozilla - o primeiro recurso para todas as tecnologias abertas da Web. Dez anos mais tarde, a nossa comunidade global é maior do que nunca, e juntos iremos continuar a criar documentação, exemplos de código e recursos de aprendizagem para todas as tecnologias abertas da Web, incluindo CSS, HTML, JavaScript e tudo o mais que torna a Web aberta tão poderosa como é.

+ +

Saber maisabout the history

+ + +

Contribuir para a MDN

+ +

Durante dez anos, a nossa comunidade MDN tem vindo a documentar a Web aberta. Desde corrigir pequenos erros até escrever conjuntos completos de uma API completamente nova, toda a gente tem qualquer coisa para oferecer, e nenhuma contribuição é menos ou mais importante do que qualquer outra. Nós temos mais de 90 000 páginas de conteúdo que têm vindo a ser escritas ou traduzidas por membros da nossa comunidade fantástica de Mozillians. Pode tornar-se num deles.

+ +

Saber maisabout contributing

+ +

 

+ +

 

+
+ +
{{TenthCampaignQuote}}
+ + + +
    +
  1. 10.º Aniversário da MDN
    2. +
  2. A história da MDN
    3. +
  3. Contribuir para a MDN
    4. +
+
diff --git "a/files/pt-pt/mdn/comunidade/conversa\303\247\303\265es/index.html" "b/files/pt-pt/mdn/comunidade/conversa\303\247\303\265es/index.html" deleted file mode 100644 index 2112b63562..0000000000 --- "a/files/pt-pt/mdn/comunidade/conversa\303\247\303\265es/index.html" +++ /dev/null @@ -1,58 +0,0 @@ ---- -title: Conversações da comunidade MDN -slug: MDN/Comunidade/Conversações -tags: - - Comunidade - - Guia(2) - - MDN Meta -translation_of: MDN/Community/Conversations ---- -
{{MDNSidebar}}

O "trabalho" da MDN ocorre no site da MDN, mas a "comunidade" também produz através da discussão (assíncrona), conversação on-line (síncrona) e encontros.

- -

Discussões assíncronas

- -

Para partilhar a informação e ter discussões em curso, a MDN tem a sua própria categoria ("MDN") , no fórum da Mozilla Discourse. Utilize esta categoria para todos os tópicos relacionados com a MDN, incluindo a criação de conteúdo da documentação, tradução, e manutenção; desenvolvimento da plataforma MDN; planeamento, definição de metas, e acompanhamento do progresso.

- - - -

Arquivos históricos

- -

Antes de junho de 2017, as discussões relacionadas com a MDN ocorriam nas listas de endereços que eram acedidas e arquivadas com os grupos Google. Se desejar pesquisar essas discussões anteriores, pode consultar os grupos Google correspondentes às listas de endereços antigas. (Sim, nós sabemos que esses nomes são sobrepostos e confusos. Acidente histórico. Desculpe por isso.)

- -
-
mozilla.dev.mdc a.k.a. dev-mdc
-
Esta lista era para discussões sobre conteúdo de documentação na MDN.
-
mozilla.dev.mdn a.k.a. dev-mdn
-
Esta lista era sobre o trabalho de desenvolvimento na plataforma subjacente Kuma da MDN.
-
mozilla.mdn a.k.a. mdn@
-
Este fórum era para discussões de alto nível de planeamento e priorização, para o site da Web da MDN e outras iniciativas relacionadas.
-
- -

 

- -

Conversação no IRC

- -

Internet Relay Chat (IRC) is our preferred method for day-to-day chat and real-time discussions among community members. We use a few channels on the server irc.mozilla.org for discussions related to MDN.

- -
-
#mdn
-
This channel is our primary channel for discussing the content of MDN. We talk about writing, organization of content, and so on. We also have "water cooler" conversations here—it's a way our community can keep in touch and just hang out. This is also the place to talk about other aspects of MDN (other than development of the platform), such as Demo Studio, profiles, and so on.
-
#mdndev
-
This channel is where our development team—the people that write the code that makes MDN work—hangs out and discusses their day-to-day work. You're welcome to join in and either participate in the development or simply ask questions about issues you see with the software.
-
- -

Estes canais são mais prováveis ​​de estarem ativos durante a semana na América do Norte.

- -

You may want to learn more about IRC (EN) and use an installable IRC client such as ChatZilla (PT). It is implemented as a Firefox add-on, which makes it quick and easy to install and use. If you're not familiar with IRC, an easy way to join is using a web-based IRC client such as Scrollback, which is pre-configured with the mdn and mdndev channels.

- -

Junte-se aos nossos encontros (e outros eventos)

- -

A equipa da MDN realiza vários encontros regulares abertos para a comunidade MDN. Consulte a página de Encontros da MDN na wiki da Mozilla para obter detalhes dos agendamentos, agendas e notas, e informação sobre como participar.

- -

Consulte o calendário de Eventos da MDN (EN) para estes e outros encontros, local de encontros, e outros eventos.

- -

Se vir um encontro que ocorre no canal "mdn", no nosso sistema de videoconferência Vidyo, pode juntar-se à conversação na Web.

diff --git a/files/pt-pt/mdn/comunidade/doc_sprints/index.html b/files/pt-pt/mdn/comunidade/doc_sprints/index.html deleted file mode 100644 index fcfaac9236..0000000000 --- a/files/pt-pt/mdn/comunidade/doc_sprints/index.html +++ /dev/null @@ -1,125 +0,0 @@ ---- -title: Doc sprints -slug: MDN/Comunidade/Doc_sprints -tags: - - Comunidade - - Guía - - Metadados MDN -translation_of: MDN/Community/Doc_sprints ---- -
{{MDNSidebar}}
- -

{{ draft() }}

- -
-

Nota: a comunidade da MDN realizou frequentemente sprints de documentação durante o período de 2010 a 2013. A partir de 2014, estes eventos foram ampliados para os eventos "Hack na MDN" que incluem hacking de código, bem como projetos de documentação. A maioria dos conselhos abaixo aplicam-se igualmente aos sprints de "Hack" e sprints de documentação.

-
- -

Este é um guia para organizar um sprint de documentação. Este contém conselhos e dicas de pessoas que organizaram os sprints de documentos, para ajudá-lo a organizar um também. Este guia também se baseia nas idéias do livroFLOSS Manuals Book Sprints.

- -

O que é um sprint de documento?

- -

A doc sprint is a short period when a group of people come together, virtually or actually, to collaborate on writing documentation on a given topic or related topics.

- -

Tipos de sprints

- -

Sprints can be virtual or in-person, or some combination. For a virtual sprint, everyone participates from wherever they happen to be located, communicating solely through mediated channels. For an in-person sprint, participants gather in the same location for the duration of the sprint, so that they can communicate face-to-face. Hybrid sprints can be mostly-in-person with some remote participants, or mostly-virtual with some local gatherings. In-person sprints require more logistical planning, to secure a meeting location, to get everybody there, and to house and feed them during the sprint.

- -

Another way to categorize sprints is by topical focus. For example, a sprint might focus on a particular subject area, such as Web development, or translation into a particular language.

- -

Planear um sprint

- -

Determinar os objetivos

- -

Have a clear idea of what the goals are for the sprint, for both content and community. This helps drive your planning of lower-level details.

- - - -

Decidir o tipo e âmbito

- -

Based on your goals, decide on the type of sprint (virtual, in-person, or combination) and the scope (what participants will focus on).

- -

For example, if you want to attract new community members, a local in-person sprint would be a good choice, because no travel is involved, but participants get to meet each other. If you want to focus on a specific subject area, where the content contributors are geographically distributed, and already know each other, then a virtual sprint may make sense.

- -

Escolher datas e horas

- -

For in-person sprints that require travel, we've found that three days (such as two weekend days and a weekday) is enough time to get some significant work done, without taking too much time away from everyone's normal lives. For public, local, in-person sprints, one day is the most you can expect most people to commit. For virtual sprints, we typically run for two days: a weekday and a weekend day. 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.

- -

Promoter o 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.

- -

Logística para sprints em pessoa

- -

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.

- -

Orçamento e financiamento

- -

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.

- -
-
Ponto de encontro
-
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.
-
Recursos
-
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.
-
Viagens
-
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.
-
Acomodação
-
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.
-
Alimentação
-
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.
-
Diversão
-
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.
-
- -

Durante o sprint

- -

Planear o trabalho

- -

 

- -

Monitorizar tarefas

- -

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.

- -

Colaboração

- -

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.

- -

Celebrar realizações

- -

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/pt-pt/mdn/comunidade/index.html b/files/pt-pt/mdn/comunidade/index.html deleted file mode 100644 index 1969fd94e1..0000000000 --- a/files/pt-pt/mdn/comunidade/index.html +++ /dev/null @@ -1,56 +0,0 @@ ---- -title: Aderir à Comunidade da MDN -slug: MDN/Comunidade -tags: - - Comunidade - - Guía - - Landing - - Metadados MDN -translation_of: MDN/Community ---- -
{{MDNSidebar}}
- -
{{IncludeSubnav("/pt-PT/docs/MDN")}}
- -
-

Os Documentos da Web da MDN é mais do que uma wiki:

- -

É uma comunidade de programadores a trabalhar em conjunto para tornar a MDN num recurso marcante para os programadores que utilizam as tecnologias abertas da Web.

-
- -

Nós adoraríamos se contribuísse para a MDN, mas nós ainda iríamos adorar mais se participasse na comunidade da MDN. Aqui tem como ligar-se, em três passos fáceis:

- -
    -
  1. Criar uma conta na MDN.
    2. -
  2. Juntar-se às conversações.
    3. -
  3. Seguir o que está a acontecer.
    4. -
- -

Como é que a comunidade funciona

- -

O seguinte são mais artigos que descrevem a comunidade da MDN.

- -
-
-
-
Regras da comunidade
-
Há várias funções dentro da comunidade da MDN que possuem responsabilidades específicas.
-
Doc sprints
-
Este é um guia para organizar um sprint de documentação. Este contém conselhos e dicas de pessoas que organizaram sprints de documentos, para ajudá-lo a organizar um também.
-
Seguir o que está a acontecer
-
A MDN é trazida para si pela comunidade da Rede de Desenvolviemtno da Mozilla. Aqui tem algumas maneiras, e assim nós partilhamos a informação sobre o que estamos a fazer.
-
- -
-
-
- -
-
-
Conversações da comunidade da MDN
-
O "trabalho" da MDN acontece no site da MDN, mas a "comunidade" também acontece através de discussões (assíncronas) e conversação e reuniões on-line (síncrono).
-
Trabalhar em comunidade
-
Uma parte importante da contribuição para a documentação da MDN em qualquer escala significativa é saber como trabalhar como parte da comunidade da MDN. Este artigo oferece dicas para ajudá-lo a aproveitar ao máximo as interações com os outros escritores e com as equipas de desenvolvimento.
-
-
-
diff --git "a/files/pt-pt/mdn/comunidade/o_que_est\303\241_a_acontecer/index.html" "b/files/pt-pt/mdn/comunidade/o_que_est\303\241_a_acontecer/index.html" deleted file mode 100644 index 6f53451020..0000000000 --- "a/files/pt-pt/mdn/comunidade/o_que_est\303\241_a_acontecer/index.html" +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: Seguir o que está a acontecer -slug: MDN/Comunidade/O_que_está_a_acontecer -tags: - - Comunidade - - Guia(2) - - Metadados MDN - - Principiante -translation_of: MDN/Community/Whats_happening ---- -
{{MDNSidebar}}

MDN is brought to you by the Mozilla Developer Network community. Here are some ways to that we share information about what we're doing.

- -

Blogues

- -
-
Mozilla Hacks
-
News about and in-depth coverage of Web and Mozilla technologies and features.
-
Engaging Developers
-
Promoting activity and discussion amongst the community involved in MDN at Mozilla.
-
- -

Emissões de ephemera

- - - -

Estado das informações e painéis

- -

The MDN documentation team maintains a Trello board on which our projects are tracked. This board is read-only but will let you see what's being worked on and what we hope to do soon, and may help you figure out where you can help. This article explains how this board is used.

- -

In addtion, take a look at the Documentation status pages to see what's going on across the full breadth of MDN content. You'll be able to see what articles need to be written or updated, what topics need the most help, and much, much more.

- -

Encontros da MDN

- -

There are a number of regular meetings for tracking and sharing progress on various MDN-related projects and processes. These are described on the MDN meetings wiki page.

- -

To get a general sense of what's happening, the best meeting to attend is the MDN Community meeting, which occurs every two weeks on Wednesdays, 10:00 US Pacific time (UTC-0800 October-March, UTC-0700 in March-October), in the #mdn IRC channel. See the MDN community meetings wiki page for agendas and notes from past meetings.

- -

The Public MDN Events calendar contains MDN community meetings, doc sprints, and other MDN-related events.

diff --git a/files/pt-pt/mdn/comunidade/trabalhar_em_comunidade/index.html b/files/pt-pt/mdn/comunidade/trabalhar_em_comunidade/index.html deleted file mode 100644 index f2c9116d03..0000000000 --- a/files/pt-pt/mdn/comunidade/trabalhar_em_comunidade/index.html +++ /dev/null @@ -1,102 +0,0 @@ ---- -title: Trabalhar em comunidade -slug: MDN/Comunidade/Trabalhar_em_comunidade -translation_of: MDN/Community/Working_in_community ---- -
{{MDNSidebar}}
- -

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

- -

Guias gerais de etiqueta

- -

Here are some general guidelines for conduct when working in the Mozilla community.

- - - -

Seja delicado

- -

Always be tactful and respectful when communicating with others.

- -

Politely pointing out mistakes

- -

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

- -

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

- -
-

Hi, MrBigglesworth, I've been noticing your contributions to the Wormhole API documentation, and it's fantastic to have your help! I particularly like the way you balanced your level of detail with readability. That said, though, you could make these articles even better and more helpful if you added the correct tags to the pages as you go.

- -

See the MDN tagging guide (https://developer.mozilla.org/en-US/docs/MDN/Contribute/Howto/Tag) for details.

- -

Thanks again, and I look forward to your future contributions!

-
- -

Partilhar conhecimento

- -

As you participate in the MDN project, it's useful to know what's going on, and to interact with other members of our community. By talking with others in our community, you can get—and share—ideas, status updates, and more. We also have tools and informational resources that can help you know what's being done, by whom.

- -

Communication channels

- -

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

- -

Bugzilla

- -

When writing documentation to cover changes implemented as a result of a bug in Bugzilla, you'll often interact with people involved in those bugs. Be sure to keep the Bugzilla Etiquette guide in mind at all times!

- -

Correio eletrónico

- -

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

- -
-

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

-
- -

Ferramentas de estado de conteúdo

- -

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.
-
- -

A comunidade de desenvolvimento

- -

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.

- -

A comunidade de escrita

- -

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.

- -

Consultar também

- - diff --git a/files/pt-pt/mdn/contribute/howto/como_converter_exemplos_de_codigo_para_ficarem_live/index.html b/files/pt-pt/mdn/contribute/howto/como_converter_exemplos_de_codigo_para_ficarem_live/index.html deleted file mode 100644 index e0f16cc514..0000000000 --- a/files/pt-pt/mdn/contribute/howto/como_converter_exemplos_de_codigo_para_ficarem_live/index.html +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: Como converter exemplos de código para ficarem "live" -slug: MDN/Contribute/Howto/Como_converter_exemplos_de_codigo_para_ficarem_live -tags: - - Como - - Metadados MDN - - Principiante -translation_of: MDN/Contribute/Howto/Convert_code_samples_to_be_live ---- -
{{MDNSidebar}}
- -

MDN tem um sistema de "exemplos live", onde o exemplo de código é mostrado numa página utilizada diretamente para exibir o resultado desse mesmo exemplo. Contudo, muitos artigos existentes tem exemplos de código que ainda não utilizam este sistema, e precisam de ser convertidos.

- -

Exemplos live, permitem-lhe ver como é que é o exemplo de destino. Este guia fala sobre como utilizar os exemplos existentes e adicionar a funcionalidade "live" às mesmas.

- -
-
Onde é que isso precisa de ser feito?
-
Artigos com a etiqueta NeedsLiveSample
-
O que precisa de saber para realizar a tarefa?
-
-
    -
  • Conhecimentos em HTML, CSS e/ou JavaScript, dependendo da amostra de código.
    • -
  • Capacidade de usar macros KumaScript dentro dos artigos MDN.
    • -
-
-
Quais são os passos para realizar a tarefa?
-
-
    -
  1. Escolher um artigo da lista de artigos que estão marcados NeedsLiveSample, onde a amostra de código é para uma funcionalidade com que se sente familiarizado.
    2. -
  2. Converter a amostra de código para ser "live".
    3. -
  3. Eliminar qualquer código ou imagem que fosse previamente utilizada para demonstrar o output da amostra.
    4. -
-
-
- -

Para mais informação sobre a criação  e edição de Amostras Live, consulte Utilizar o sistema de amostra live

diff --git a/files/pt-pt/mdn/contribute/howto/como_definir_o_resumo_para_uma_pagina/index.html b/files/pt-pt/mdn/contribute/howto/como_definir_o_resumo_para_uma_pagina/index.html deleted file mode 100644 index 172aed7d5d..0000000000 --- a/files/pt-pt/mdn/contribute/howto/como_definir_o_resumo_para_uma_pagina/index.html +++ /dev/null @@ -1,47 +0,0 @@ ---- -title: Como definir o resumo para uma página -slug: MDN/Contribute/Howto/Como_definir_o_resumo_para_uma_pagina -tags: - - Como - - Guia(2) - - Metadados MDN -translation_of: MDN/Contribute/Howto/Set_the_summary_for_a_page ---- -
{{MDNSidebar}}

Pode definir-se o resumo de uma página no MDN para ser usada de várias maneiras, incluindo em resultados de motores de busca, noutras páginas MDN tais como páginas de destino de tópicos, e dicas ou sugestões de ajuda. Deverá ser um texto que faça sentido quer no contexto da página, quer quando aparece noutros contextos, sem que esteja disponível a totalidade do conteúdo.

- -

Um resumo pode definido explicitamente em apenas uma página. Se não estiver explicitamente definido, então normalmente usam-se as primeiras linhas, o que nem sempre é o melhor para o objectivo pretendido.

- -
-
O que é uma tarefa?
-
Identificar o texto de uma página que melhor poderia ser usado para ser o seu resumo, mesmo que apareça noutros contextos; esta tarefa poderá incluir editar o texto existente e/ou introduzir texto apropriado se necessário.
-
Onde é que esta precisa de ser feita?
-
Em páginas que não têm resumos ou têm um resumo menos bom.
-
O que precisa de saber para efectuar a tarefa?
-
Habilitação para usar o editor MDN; competência em português escrito; familiaridade suficiente com o tópico para escrever um bom resumo.
-
Quais os passos a seguir?
-
-
    -
  1. Escolher uma página para colocar um resumo: -
      -
    1. Na página Estado do documento por tópico, clique num tópico de que tenha algum conhecimento (por exemplo, HTML) da coluna Secções: 
      -
      2. -
    2. Na página de Estado do documento do tópico escolhido, clicar no cabeçalho Pages da tabela Summary.  Irá para um índice de todas as páginas da secção correspondente ao tópico escolhido; mostra os links das páginas na coluna esquerda, e as palavras-chave e resumos na coluna da direita:
      -
      3. -
    3. Escolher uma página que não tenha ou tenha um fraco resumo:
      -
      4. -
    4. Clicar no link para ir para essa página.
      5. -
    -
    2. -
  2. Clicar em  Edit para abrir a página no editor MDN.
    3. -
  3. Tentar encontrar uma frase ou duas que possam servir de resumo, mesmo fora de contexto. Se necessário, editar o conteúdo existente para criar ou modificar frases de modo a que estas se tornem um bom resumo.
    4. -
  4. Seleccionar o texto que irá ser usado como resumo.
    5. -
  5. Na ferramenta Estilos, da barra de ferramentas do editor, seleccionar SEO Summary. (Na página de código fonte, isto cria um elemento {{HTMLElement("span")}}  com  class="seoSummary" em volta do texto seleccionado.)
    -
    6. -
  6. Guardar as alterações com um comentário de revisão. O comentário é opcional, mas é encorajado pois torna mais fácil para os outros utilizadores o rastreio de alterações.
    7. -
- -

 

-
-
- -

 

diff --git a/files/pt-pt/mdn/contribute/howto/como_efetuar_revisao_tecnica/index.html b/files/pt-pt/mdn/contribute/howto/como_efetuar_revisao_tecnica/index.html deleted file mode 100644 index def53aa207..0000000000 --- a/files/pt-pt/mdn/contribute/howto/como_efetuar_revisao_tecnica/index.html +++ /dev/null @@ -1,65 +0,0 @@ ---- -title: Como efetuar uma revisão técnica -slug: MDN/Contribute/Howto/Como_efetuar_revisao_tecnica -tags: - - Como - - Documentação - - Guía - - Metadados MDN - - Revisão -translation_of: MDN/Contribute/Howto/Do_a_technical_review ---- -
{{MDNSidebar}}
- -
{{IncludeSubnav("/en-US/docs/MDN")}}
- -

'Uma revisão Técnica' consiste em rever a exatidão técnica e a integridade de um artigo e corrigi-lo, se necessário. Se um escritor de um artigo quiser que outra pessoa verifique o conteúdo técnico de um artigo, o escritor marca a caixa de seleção "Revisão técnica" durante a edição. Muitas vezes, o escritor entra em contacto com um técnico específico para realizar a revisão técnica, mas qualquer pessoa com conhecimento técnico no assunto pode efetuar uma.

- -

Este artigo descreve como realizar uma revisão técnica, ajudando a garantir que o conteúdo da MDN seja preciso.

- -
-
O que é uma tarefa?
-
Rever e corrigir os artigos para uma perfeição e exatidão técnica.
-
-

 

- Onde é que esta precisa de ser efetuada?
-
Nos artigos específicos que são marcados como 'necessária uma revisão técnica' (em inglês).
-
O que precisa de saber para realizar a tarefa?
-
-
    -
  • -

    Conhecimento especializado do tópico do artigo que está a rever. Se ao ler o artigo não lhe ensina algo significativamente novo, considere-se um especialista.

    -
    • -
  • Como editar um artigo da wiki na MDN.
    • -
-
-
Quais são os passos a seguir?
-
-
    -
  1. Escolha um artigo para rever: -
      -
    1. Vá para lista das páginas que precisam de revisões técnicas. I -

       

      - sto lista todas as páginas para as quais uma revisão técnica foi solicitada.
      2. -
    2. Escolha uma página cujo tópico esteja familizarizado.
      3. -
    3. Clique na hiperligação do artigo para carregar a página.
      4. -
    -
    2. -
  2. Leia o artigo, tendo em atenção os detalhes técnicos: O artigo está correto? Tem alguma coisa em falta? Não hesite em mudar para uma página diferente se a primeira que escolheu não lhe é conveniente.
    3. -
  3. Se não existirem erros, não precisa de editar o artigo para o marcar como revisto. Veja na caixa "revisão rápida" na barra lateral esquerda da página. Esta caixa amarela lista quaisquer revisões pendentes e deixa-o limpar a bandeira do pedido da sua revisão. Parece-se com isto se foi solicitada uma revisão técnica:
    - Screenshot of the sidebar's box listing reviews that have been requested and allowing the flags to be changed.
    4. -
  4. Desselecione a caixa Técnico, e clique em Guardar.
    5. -
  5. Se encontrar erros que precisam de ser corrigidos, irá ficar feliz em saber que também pode alterar o estado da solicitação de revisão no editor. Aqui tem o fluxo de trabalho: -
      -
    1. Para editar a página, clique em Editar perto do topo da página; isto coloca-o no editor da MDN.
      2. -
    2. Corrigir qualquer informação técnica que não esteja correta, e/ou adicioanr qualquer informação importante que esteja em falta.
      3. -
    3. Inserir um 'Comentário da Revisão' no fim do artigo. Esta é uma breve mensagem que descreve o que fez, tal como 'Revisão técnica concluída'. Se corrigiu a informação, inclua isso no seu comentário, por exemplo, 'Revisão técnica e descrições dos parâmetros corrigidos'. Isto ajuda os outros colaboradores e editores de sites a saberem o que alterou e o porquê. Também pode mencionar se existiam partes específicas que não se sentia qualificado para rever.
      4. -
    4. Desselecionar a caixa Técnico sob Revisão necessária?.
      5. -
    5. Clique em PUBLICAR.
      6. -
    -
    6. -
- -

Parabéns! Concluiu a sua primeira revisão técnica! Obrigado pela sua ajuda!

-
-
diff --git a/files/pt-pt/mdn/contribute/howto/como_escrever_um_artigo_para_ajudar_as_pessoas_a_aprenderem_sobre_a_web/index.html b/files/pt-pt/mdn/contribute/howto/como_escrever_um_artigo_para_ajudar_as_pessoas_a_aprenderem_sobre_a_web/index.html deleted file mode 100644 index 5751a2e391..0000000000 --- a/files/pt-pt/mdn/contribute/howto/como_escrever_um_artigo_para_ajudar_as_pessoas_a_aprenderem_sobre_a_web/index.html +++ /dev/null @@ -1,114 +0,0 @@ ---- -title: Como escrever um artigo para ajudar as pessoas a aprenderem sobre a Web -slug: >- - MDN/Contribute/Howto/Como_escrever_um_artigo_para_ajudar_as_pessoas_a_aprenderem_sobre_a_Web -tags: - - Aprender - - Como - - Guia(2) - - Metadados MDN -translation_of: MDN/Contribute/Howto/Write_an_article_to_help_learn_about_the_Web ---- -
{{MDNSidebar}}
- -

A Área de Aprendizagem da MDN é o nosso local para os artigos que introduzem os conceitos da Web para os novos programadores. Porque o seu conteúdo, principalmente, tem como alvo os principiantes, é um local excelente para partilhar os seus conhecimentos e ajudar estes a conhecer a Web. É importante certificar-se que os novos programadores podem seguir este conteúdo, por isso nós damos especial atenção a este.

- -

Este artigo explica sobre como escrever as páginas para a Área de Aprendizagem.

- -

Como escrever um artigo da Área de Aprendizagem

- -

To start contributing your knowledge, simply click the big green button, then follow the five steps below. If you're looking for ideas, please take a look at the our team Trello board!

- -

Escrever um novo artigo de aprendizagem

- -

This article might not end up in exactly the right place, but at least it's on MDN. If you need to talk to someone about getting it moved to the right place, please  Contact us.

- -

Passo 1: Write a two-liner

- -

Your article's first sentence needs to summarize what subject you're going to cover, and the second one should go into a few more specifics of the items that you'd put in the article. For example:

- -
-

Whereas {{glossary("HTML")}} files contain structured content, {{Glossary("CSS")}}, another major Web technology, makes the content look the way you want. In this article we are going to cover how this technology works, and how to write your own basic example.

-
- -

Note how the example briefly explains that CSS is a core Web technology used to style pages. That's enough for the reader to get a pretty good idea what the article covers.

- -

Because Learning Area articles primarily target beginners, each article should cover one straightforward topic so as not to overwhelm the reader with too much new information. If you can't summarize the article in one sentence, you might be trying to do too much in one article!

- -

Passo 2: Add a top box

- -

Then add a top box to help readers get their bearings as to where they are in the learning process.  Here's an example of a top box from "Understanding URLs and their structure". You can use this article as an model when writing your own.

- - - - - - - - - - - - -
Pré-requisitos:You need to first know how the Internet works, what a Web server is, and the concepts behind links on the web.
Objetivo:You will learn what a URL is and how it works on the Web.
- -
-
Pré-requisitos
-
What must the reader already know to follow the article? When possible, make each prerequisite a link to another Learning Area article covering the concept (unless it's a really basic article that doesn't require prior knowledge).
-
Objetivos
-
This section briefly states what the reader will learn over the course of the article. This is a bit different than the one-liner; the one-liner summarizes the topic of the article, while the objectives section specifically lays out what the reader can expect to accomplish over the course of the article.
-
- -
-

Nota: To create this table, you can either copy and paste the example table above, or use MDN's editor's table tool. If you choose to use the table tool, you need to specifically add the learn-box CSS class in addition to the default standard-table class. To do this, when you create or edit the table's properties,, go to the "Advanced" panel and set the Stylesheet Classes field to "standard-table learn-box".

-
- -

Passo 3: Write a full description

- -

Next, write a longer description that provides a more thorough overview of the article highlighting the most important concepts. Don't forget to explain why the reader should take the time to learn this topic and read your article!

- -

Passo 4: Dig deeper

- -

When you're done with all that, you can finally dive deeply into the topic. You can structure this part of your article however you like (although feel free to consult our style guide). This is your chance to shine! Go into detail explaining the topic you're writing about. Provide links to the full reference documentation, explain how the technology works in detail, provide syntax and usage details, and so forth. It's up to you!

- -

As a guide, here are some writing tips for beginners:

- - - -

Have a look at the first few sections of our Functions — reusable blocks of code article for some good descriptive sections.

- -

Passo 5: Provide "active learning" material

- -

To illustrate the article and help the reader better understand what they're learning, be sure to provide exercises, tutorials, and tasks to accomplish. By having them actively and practically using and experimenting with the concepts your article explains, you can help "lock" the information into their brains.

- -

You can choose to include the examples directly in the page as live samples, or link to them if they don't really work as a live sample. If you're interested in helping create these valuable materials, please read the article Create an interactive exercise to help learning the Web.

- -

If you can't provide links to existing active learning materials (you don't know of any or don't have time to create them), you should add the tag {{Tag("NeedsActiveLearning")}} to the article. That way other contributors can find articles that need active learning materials and perhaps help you come up with them.

- -

Have a look at Active learning: selecting different elements for a live interactive learning exercise, or Active learning: Playing with scope for a different style of exercise that calls upon them to download a template locally and modify it following the provided steps.

- -

Passo 6: Get the article reviewed, and put into the Learning Area navigation menu

- -

After you've written your article, let us know so we can have a look at it, do a review, and suggest improvements. Again, see our Contact us section for the best ways to get in touch.

- -

Another part finalizing your article is to put it in the Learning Area main navigation menu. This menu is generated by the LearnSidebar macro, which you need special privileges to edit, so again, talk ot one of our team about getting it added.

- -

You should at least add it to your page — this is done by adding the macro call \{{LearnSidebar}} into a paragraph at the top of your page.

- - - -

Artigos sugeridos

- -

So you want to contribute but you're not sure what to write about?

- -

The Learning Area team maintains a Trello board with ideas of articles to write. Feel free to pick one and get to work!

- -

 

- -

 

diff --git a/files/pt-pt/mdn/contribute/howto/como_escrever_uma_nova_entrada_no_glossario/index.html b/files/pt-pt/mdn/contribute/howto/como_escrever_uma_nova_entrada_no_glossario/index.html deleted file mode 100644 index 105853672c..0000000000 --- a/files/pt-pt/mdn/contribute/howto/como_escrever_uma_nova_entrada_no_glossario/index.html +++ /dev/null @@ -1,114 +0,0 @@ ---- -title: Como escrever e referenciar uma entrada no glossário -slug: MDN/Contribute/Howto/Como_escrever_uma_nova_entrada_no_Glossario -tags: - - Como... - - Glossário - - Guia(2) - - Metadados da MDN -translation_of: MDN/Contribute/Howto/Write_a_new_entry_in_the_Glossary ---- -
{{MDNSidebar}}
- -

O glossário da MDN é o local onde nós definimos toda a terminologia, gíria, e abreviações utilizadas na documentação e programação. Contribuir para o glossário é uma maneira simples de tornar a Web mais fácil para todos entenderem. Você não precisa de um alto nível de habilidade técnica para escrever entradas de glossário porque elas devem permanecer simples e diretas.

- -

Como escrever uma entrada

- -

Se você está procurando por tópicos que precisam de uma entrada de glossário, verifique a lista de termos não documentados no final da página de destino do Glossário; clique em qualquer um desses links para iniciar uma nova página do Glossário para o item que você clicou; então siga os passos abaixo.

- -

Se você tem uma ideia para um nova entrada de glossário, basta abrir o botão em uma nova aba, e então siga os passos abaixo do botão.

- -

Adicionar Nova Entrada ao Glossário

- -

 

- -

Passo 1: Escreva um resumo

- -

The first paragraph of any glossary page is a simple and short description of the term (preferably no more than two sentences). Make sure anyone reading the description can understand the defined term immediately.

- -
-

Nota: Please don't copy-and-paste definitions from elsewhere (especially not Wikipedia, since its range of license versions is smaller, and thus incompatible with that of MDN). It's really important to make sure this content is simple and easy to understand. It's worth spending some time on it rather than stealing content blindly. This glossary should be useful new content, not repeating things from elsewhere.

-
- -

Links to the glossary entry will use these summaries inside their tooltips, so that readers can see the definitions without navigating away from the page they're on. (See below how to insert links to glossary entries with the \{{Glossary}} macro.)

- -

If you must, you can add a few extra paragraphs, but it's very easy to find yourself writing a whole article. Writing a whole article is fine, but please don't put it in the glossary. If you aren't sure where to put your article, feel free to reach out to discuss it.

- -

Passo 2: Expanda com hiperligações

- -

Finally, a glossary entry should always end with a "Learn more" section. This section should contain links to help the reader move forward: discovering more details, learning to use the relevant technology, and so on.

- -

We recommend that you sort the links into at least these three groups:

- -
-
Conhecimento geral
-
Links that provide more general information; for example, a link to Wikipedia is a good starting point.
-
Referência técnica
-
Links to more in-depth technical information, on MDN or elsewhere.
-
Saber sobre a mesma
-
Hiperligações para tutoriais, exercícios, quaisquer outros materiais que ajudem o leitor a saber como utilizar a tecnologia por de trás do termo definido.
-
- -

Termos sugeridos

- -

So you want to contribute but you don't know which terms need to be defined? Here's a list of suggestions. Click one and get started!

- -

Lidar com a desambiguação

- -

Sometimes, a term has several meanings depending on the context. To resolve the ambiguities, you must follow those guidelines:

- - - -

Let's illustrate that with an example. The term signature can have different meanings in at least three different contexts: security, function and email.

- -
    -
  1. A página de Glossário/Assinatura é a página de desambiguação como a  {{TemplateLink("GlossaryDisambiguation")}} macro.
    2. -
  2. The page Glossary/Signature/Security is the page defining a signature in a security context.
    3. -
  3. The page Glossary/Signature/Function is the page defining a function signature.
    4. -
  4. The page Glossary/Signature/Email is the page defining email signature.
    5. -
- -

Como utilizar a macro \{{Glossary}}

- -

The glossary is much more useful when people can access the definitions from another document without navigating away from what they're reading. Therefore we urge you to link to the glossary whenever you can, using the {{TemplateLink("Glossary")}} macro:

- - - - - - - - - - - - - - - - - - - - - - - - - - -
MacroResultadoNota
\{{Glossary("browser")}}{{Glossary("browser")}}When a text matches the term to be defined, just use the macro as is (it's case insensitive)
\{{Glossary("browser", "Web browser")}}{{Glossary("browser","Web browser")}}To display an alternative text, use the second argument to specify that text
\{{Glossary("browser", "Web browser", 1)}}{{Glossary("browser","Web browser",1)}}Specify 1 as an optional third argument to display the link as a regular link rather than a subtle hint
- -

Links created with the \{{Glossary}} macro always display a tooltip containing the glossary entry's summary paragraph.

- -

Utilização das linhas diretrizes

- -

In many cases, it's perfectly safe to use that macro everywhere on MDN. However, there are a few cases you should handle with care:

- - diff --git a/files/pt-pt/mdn/contribute/howto/comunicar_um_problema/index.html b/files/pt-pt/mdn/contribute/howto/comunicar_um_problema/index.html deleted file mode 100644 index 764d3fca0c..0000000000 --- a/files/pt-pt/mdn/contribute/howto/comunicar_um_problema/index.html +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: Como comunicar um problema na MDN -slug: MDN/Contribute/Howto/Comunicar_um_problema -tags: - - Como... - - Guía - - Metadados MDN -translation_of: MDN/Contribute/Howto/Report_a_problem ---- -
{{MDNSidebar}}
- -

De vez em quando, pode encontrar problemas ao utilizar a MDN. Se é um problema com a infra-estrutura do site ou um erro no conteúdo da documentação, pode tentar corrigi-lo ou comunicar o problema. Enquanto o primeiro é o preferido, o último é às vezes o melhor que pode gerir, e isso também está bem.

- -

Erros de documentação ou pedidos

- -

Obviously, since MDN is a wiki, the best thing you can possibly do is fix problems you spot yourself. But maybe you don't know the answer or are in the middle of a deadline on your own project or something, and need to jot down the problem so someone can look at it later.

- -

As is the case with all things Mozilla, you report a documentation problem by filing a bug. That's when filing a documentation request bug comes in. The documentation request form gathers the information needed to get us started on fixing the issue.

- -

Of course, our writing community is busy, so sometimes the quickest way to see a documentation problem resolved is to fix it yourself. See How to create and edit pages for details.

- -

Erros (bugs) do site ou pedidos de funcionalidades

- -

Kuma, the Mozilla-developed platform used for the MDN web site, is in a state of continuous development. Our developers—as well as a number of volunteer contributors—are constantly making improvements. If you see a bug, or have a problem with the site, or even have a suggestion for something that could make the software more awesome, you can use the Kuma bug form to file a report. You can also use this form to report performance problems with the site, though odds are that performance-monitoring tools have already notified the appropriate people.

diff --git a/files/pt-pt/mdn/contribute/howto/convert_code_samples_to_be_live/index.html b/files/pt-pt/mdn/contribute/howto/convert_code_samples_to_be_live/index.html new file mode 100644 index 0000000000..e0f16cc514 --- /dev/null +++ b/files/pt-pt/mdn/contribute/howto/convert_code_samples_to_be_live/index.html @@ -0,0 +1,36 @@ +--- +title: Como converter exemplos de código para ficarem "live" +slug: MDN/Contribute/Howto/Como_converter_exemplos_de_codigo_para_ficarem_live +tags: + - Como + - Metadados MDN + - Principiante +translation_of: MDN/Contribute/Howto/Convert_code_samples_to_be_live +--- +
{{MDNSidebar}}
+ +

MDN tem um sistema de "exemplos live", onde o exemplo de código é mostrado numa página utilizada diretamente para exibir o resultado desse mesmo exemplo. Contudo, muitos artigos existentes tem exemplos de código que ainda não utilizam este sistema, e precisam de ser convertidos.

+ +

Exemplos live, permitem-lhe ver como é que é o exemplo de destino. Este guia fala sobre como utilizar os exemplos existentes e adicionar a funcionalidade "live" às mesmas.

+ +
+
Onde é que isso precisa de ser feito?
+
Artigos com a etiqueta NeedsLiveSample
+
O que precisa de saber para realizar a tarefa?
+
+
    +
  • Conhecimentos em HTML, CSS e/ou JavaScript, dependendo da amostra de código.
    • +
  • Capacidade de usar macros KumaScript dentro dos artigos MDN.
    • +
+
+
Quais são os passos para realizar a tarefa?
+
+
    +
  1. Escolher um artigo da lista de artigos que estão marcados NeedsLiveSample, onde a amostra de código é para uma funcionalidade com que se sente familiarizado.
    2. +
  2. Converter a amostra de código para ser "live".
    3. +
  3. Eliminar qualquer código ou imagem que fosse previamente utilizada para demonstrar o output da amostra.
    4. +
+
+
+ +

Para mais informação sobre a criação  e edição de Amostras Live, consulte Utilizar o sistema de amostra live

diff --git a/files/pt-pt/mdn/contribute/howto/create_and_edit_pages/index.html b/files/pt-pt/mdn/contribute/howto/create_and_edit_pages/index.html new file mode 100644 index 0000000000..e4d8572fe3 --- /dev/null +++ b/files/pt-pt/mdn/contribute/howto/create_and_edit_pages/index.html @@ -0,0 +1,181 @@ +--- +title: Como criar e editar páginas +slug: MDN/Contribute/Howto/Criar_e_editar_paginas +tags: + - Guía + - Introdução + - MDN Meta + - Principiante +translation_of: MDN/Contribute/Howto/Create_and_edit_pages +--- +
{{MDNSidebar}}
+ +

Este artigo introduz novos colaboradores ao processo de editar páginas existentes e criar novas páginas.

+ +

Editar uma página existente

+ +

Para editar uma página:

+ +
    +
  1. Clique no botão Editar perto do canto superior direito da página.
    2. +
  2. A página vai recarregar, com uma interface de edição onde podes acrescentar ou apagar informação diretamente.
    3. +
  3. Acrescente parágrafos, apague texto, insira títulos, e realize outras funções básicas envolvidas em escrever e editar.
    4. +
+ +

Veja o guia do Elementos da IU do editor, no Guia para o editor da IU da MDN, para obter mais informação sobre a utilização do editor incorporado da MDN.

+ +

Pré-visualizar alterações

+ +

Para ver o aspeto das suas alterações:

+ + + +

Tenha cuidado! Pré-visualizar uma página não guarda o seu progresso. Não feche o separador em que está a editar até ter guardado o seu trabalho.

+ +

Comentário de revisão

+ +

Depois de pré-visualizar as alterações, vai querer guardar a sua revisão. Antes de guardar, procure a caixa do comentário de revisão, por baixo da caixa de edição,  e deixe um comentário para informar outros colaboradores de porque é que fez alterações. Diga, por exemplo, se acrescentou uma secção nova, mudou algumas palavras para tornar a terminologia mais consistente, reescreveu um parágrafo para esclarecer a linguagem, ou removeu informação redundante.

+ +

Índice

+ +

A secção "Neste artigo", é uma lista, gerada automaticamente, de ligações para os títulos numa página. Estes podem ser modificados através dos títulos. Também é possível remover um índice ou reduzir o número de ligações ao selecionar "Editar o Título e Propriedades da Página" e mudar o valor na caixa de seleção "TOC" (Table of contents / Índice).

+ +

Etiquetas (Tags)

+ +

Pode adicionar ou remover etiquetas, que descrevem o conteúdo e propósito da página, por baixo da secção de edição. Veja Como etiquetar devidamente as páginas para obter informação sobre as etiquetas que deve utilizar.

+ +

Necessita de revisão?

+ +

Se um colaborador perito ou experiente deve rever as suas edições, por favor peça uma revisão técnica (de código, API, ou tecnologias), e/ou uma revisão editorial (de prosa, gramática, e conteúdo), certificando-se de que a caixa adequada tem um visto antes de guardar.

+ +

Anexar ficheiro

+ +

Se pretende anexar um ficheiro a uma página existente, ou acrescentar uma ilustração para dar melhores esclarecimentos, o mesmo pode ser acrescentado na margem inferiro da página. Quando envia uma imagem, por favor utilize uma ferramente de otimização de imagens para tornar o ficheiro o mais pequeno possível. Desta forma, reduz o tempo de carregamento da página e ajuda o desempenho geral da MDN. Utilize a sua ferramente preferida, se tiver uma; se não, sugerimos TinyPNG, uma ferramenta Web acessível.

+ +

Publicar, Descartar, ou Continuar a editar

+ +

Quando termina de editar e está contente com a pré-visualização, publique o seu trabalho e comentários com o botão verde Publicar, à direita do título da página, ou no fim da página. Se pretende continuar, clique em Publicar e cotinuar a editar, o qual publica as suas alterações e mantém a interface de edição aberta.

+ +

Se mudar de ideias, pode descartar edições com o botão vermelho Descartar. Atenção que este botão descarta permanentemente.

+ +

Premir a tecla Enter na caixa de Comentário de Revisão é equivalente a clicar em Publicar e cotinuar a editar.

+ +
+

Nota: Se tentar guardar, mas as alterações são rejeitas como inválidas, e acha que o conteúdo é apropriado para a MDN, envie um e-mail à equipa de administração da MDN para obter assistência.

+
+ +

Getting page-creation permissions

+ +

For security reasons, newly-created accounts don't have the ability to create new pages. If you try to do so, you'll see a page instructing you how to get the page created. There are two options:

+ + + +

Creating a new page

+ +

Once you have page-creation permission, you can begin creating pages.

+ +

If you do not know where to place a new article, do not worry. Put it anywhere, we will find it, move to where it belongs, or merge it into existing content. Whatever makes the most sense. Do not worry about making it perfect. We have happy helper gnomes who help to make your content clean and rather luscious.

+ +

There are a few ways to create a new page:

+ + + + + +

As with most wikis, it is possible to create a link to a page that is yet to exist. For example, an author might create a list of all the members of an API, before creating the pages for those members. On MDN, links to non-existent pages are typically displayed in red.

+ +

To create a page from a 'missing page' link:

+ +
    +
  1. Log into MDN, and have page-creation permission. If not logged in, clicking a 'missing page' link results in a 404 (page not found) error.
    2. +
  2. Click the 'missing page' link. If you have page creation permission, the MDN Editor UI opens, ready for you to create the missing page.
    3. +
  3. Write the content of the page, and save it.
    4. +
+ +

New page without link

+ +

To create a new page without linking from another page, enter a unique page name in the URL field of your browser. For example, if you enter:

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

MDN Creates a new page, with the title "FooBar", opening the editor for you to add new content. Refer to the Editing an existing page section of this article, for information on how to use the editor mode.

+ +

To create a new page without linking from another page:

+ +
    +
  1. Log in, and have page-creation permission.
    2. +
  2. Enter the following in the URL field of your browser:
    3. +
+ +
https://developer.mozilla.org/en-US/docs/new
+ +

MDN Creates a new page, with a place for a title, opening the editor to add new content to this page. Refer to Editing an existing page, for information on using editor mode.

+ +

Subpage of an existing page

+ +

To create a page you want to be below an existing page, in the page hierarchy:

+ +
    +
  1. On the 'parent' page, click the Advanced menu (the gear icon in the toolbar), then click New sub-page.
    2. +
  2. An editor view opens for creating a new document.
    3. +
  3. Add a title for this document, in the Title field.
    4. +
  4. Change the Slug field, if needed. For example, if the title is long, and a shorter URL seems appropriate. This field is automatically filled by the editor, substituting underscores for spaces found in the title, changing only the last part of the URL.
    5. +
  5. In the TOC field, select heading levels you want to be displayed in the table of contents for the page. Or select 'No table of contents', if one is not needed.
    6. +
  6. Write content of the page in the editor pane, saving your changes. Refer to Editing an existing page, for further information on using editor mode.
    7. +
+ +

Clone of an existing page

+ +

If there is an existing page, whose format you wish to use as a base for your new page, you can 'clone' that page, and then change its content.

+ +
    +
  1. On the original page, click the Advanced menu (the gear icon in the toolbar), and click Clone this page. An editor view opens, for creating a new document.
    2. +
  2. Change the Title of the page, as appropriate for the new content. The Slug field is updated automatically as you change the Title field.
    3. +
  3. Change the path portion of the Slug field, as needed, to put the new document in a different location in the document hierarchy. In most cases, this is not needed. A cloned page often has similar content to its original, and need to be in a similar location.
    4. +
  4. In the TOC field, select the heading levels you want to be automatically displayed in the table of contents for this page. Or select 'No table of contents', if one is not needed.
    5. +
  5. Write your content in the editor pane, saving your changes. Refer to Editing an existing page, for more information on using editor mode.
    6. +
+ +

Link from an existing page

+ +

This is a bit of a hybrid. You can create a link on another page, then click the link you just inserted, to create the new page:

+ +
    +
  1. Enter the name of your new page, anywhere that makes sense in the text of an existing page.
    2. +
  2. Highlight this new name, and click the Link icon () in the editor's toolbar. The 'Update Link' dialog opens, with the highlighted text in the 'Link To' field.
    3. +
  3. "/en-US/docs/" is inserted by default, to the beginning of the URL field. Enter the name of the page after "/en-US/docs/". The page name does not have to be the same as the link text.
    4. +
  4. Click OK, to create and insert the link.
    5. +
+ +

If the page does not yet exist, the link is displayed in red. If the page does exist, the link is displayed blue. If you want to create a new page, but the page title you desire is already taken, check if it makes sense helping edit and improve the page already there. Otherwise, think of a unique title for your new page, and create a link for it. Refer to page naming guide for guidelines.

+ +

To add content to your new page, click on the red link you just created, after saving and closing the editor. The new page opens in editor mode, enabling you to start writing. Refer to Editing an existing page, for further information on using editor mode.

+ +

Refreshing page content

+ +

MDN support of KumaScript macros, and integration of content from other pages can sometimes be hampered by the need for caching of pages, for performance reasons. Pages are built from their source, and this output is cached for future requests. From that moment on, any macros (templates), or integrations (using the macroPage), will not reflect later changes made to the macro, its output, or the contents of the integrated material.

+ + + +

See also

+ + diff --git a/files/pt-pt/mdn/contribute/howto/criar_e_editar_paginas/index.html b/files/pt-pt/mdn/contribute/howto/criar_e_editar_paginas/index.html deleted file mode 100644 index e4d8572fe3..0000000000 --- a/files/pt-pt/mdn/contribute/howto/criar_e_editar_paginas/index.html +++ /dev/null @@ -1,181 +0,0 @@ ---- -title: Como criar e editar páginas -slug: MDN/Contribute/Howto/Criar_e_editar_paginas -tags: - - Guía - - Introdução - - MDN Meta - - Principiante -translation_of: MDN/Contribute/Howto/Create_and_edit_pages ---- -
{{MDNSidebar}}
- -

Este artigo introduz novos colaboradores ao processo de editar páginas existentes e criar novas páginas.

- -

Editar uma página existente

- -

Para editar uma página:

- -
    -
  1. Clique no botão Editar perto do canto superior direito da página.
    2. -
  2. A página vai recarregar, com uma interface de edição onde podes acrescentar ou apagar informação diretamente.
    3. -
  3. Acrescente parágrafos, apague texto, insira títulos, e realize outras funções básicas envolvidas em escrever e editar.
    4. -
- -

Veja o guia do Elementos da IU do editor, no Guia para o editor da IU da MDN, para obter mais informação sobre a utilização do editor incorporado da MDN.

- -

Pré-visualizar alterações

- -

Para ver o aspeto das suas alterações:

- - - -

Tenha cuidado! Pré-visualizar uma página não guarda o seu progresso. Não feche o separador em que está a editar até ter guardado o seu trabalho.

- -

Comentário de revisão

- -

Depois de pré-visualizar as alterações, vai querer guardar a sua revisão. Antes de guardar, procure a caixa do comentário de revisão, por baixo da caixa de edição,  e deixe um comentário para informar outros colaboradores de porque é que fez alterações. Diga, por exemplo, se acrescentou uma secção nova, mudou algumas palavras para tornar a terminologia mais consistente, reescreveu um parágrafo para esclarecer a linguagem, ou removeu informação redundante.

- -

Índice

- -

A secção "Neste artigo", é uma lista, gerada automaticamente, de ligações para os títulos numa página. Estes podem ser modificados através dos títulos. Também é possível remover um índice ou reduzir o número de ligações ao selecionar "Editar o Título e Propriedades da Página" e mudar o valor na caixa de seleção "TOC" (Table of contents / Índice).

- -

Etiquetas (Tags)

- -

Pode adicionar ou remover etiquetas, que descrevem o conteúdo e propósito da página, por baixo da secção de edição. Veja Como etiquetar devidamente as páginas para obter informação sobre as etiquetas que deve utilizar.

- -

Necessita de revisão?

- -

Se um colaborador perito ou experiente deve rever as suas edições, por favor peça uma revisão técnica (de código, API, ou tecnologias), e/ou uma revisão editorial (de prosa, gramática, e conteúdo), certificando-se de que a caixa adequada tem um visto antes de guardar.

- -

Anexar ficheiro

- -

Se pretende anexar um ficheiro a uma página existente, ou acrescentar uma ilustração para dar melhores esclarecimentos, o mesmo pode ser acrescentado na margem inferiro da página. Quando envia uma imagem, por favor utilize uma ferramente de otimização de imagens para tornar o ficheiro o mais pequeno possível. Desta forma, reduz o tempo de carregamento da página e ajuda o desempenho geral da MDN. Utilize a sua ferramente preferida, se tiver uma; se não, sugerimos TinyPNG, uma ferramenta Web acessível.

- -

Publicar, Descartar, ou Continuar a editar

- -

Quando termina de editar e está contente com a pré-visualização, publique o seu trabalho e comentários com o botão verde Publicar, à direita do título da página, ou no fim da página. Se pretende continuar, clique em Publicar e cotinuar a editar, o qual publica as suas alterações e mantém a interface de edição aberta.

- -

Se mudar de ideias, pode descartar edições com o botão vermelho Descartar. Atenção que este botão descarta permanentemente.

- -

Premir a tecla Enter na caixa de Comentário de Revisão é equivalente a clicar em Publicar e cotinuar a editar.

- -
-

Nota: Se tentar guardar, mas as alterações são rejeitas como inválidas, e acha que o conteúdo é apropriado para a MDN, envie um e-mail à equipa de administração da MDN para obter assistência.

-
- -

Getting page-creation permissions

- -

For security reasons, newly-created accounts don't have the ability to create new pages. If you try to do so, you'll see a page instructing you how to get the page created. There are two options:

- - - -

Creating a new page

- -

Once you have page-creation permission, you can begin creating pages.

- -

If you do not know where to place a new article, do not worry. Put it anywhere, we will find it, move to where it belongs, or merge it into existing content. Whatever makes the most sense. Do not worry about making it perfect. We have happy helper gnomes who help to make your content clean and rather luscious.

- -

There are a few ways to create a new page:

- - - - - -

As with most wikis, it is possible to create a link to a page that is yet to exist. For example, an author might create a list of all the members of an API, before creating the pages for those members. On MDN, links to non-existent pages are typically displayed in red.

- -

To create a page from a 'missing page' link:

- -
    -
  1. Log into MDN, and have page-creation permission. If not logged in, clicking a 'missing page' link results in a 404 (page not found) error.
    2. -
  2. Click the 'missing page' link. If you have page creation permission, the MDN Editor UI opens, ready for you to create the missing page.
    3. -
  3. Write the content of the page, and save it.
    4. -
- -

New page without link

- -

To create a new page without linking from another page, enter a unique page name in the URL field of your browser. For example, if you enter:

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

MDN Creates a new page, with the title "FooBar", opening the editor for you to add new content. Refer to the Editing an existing page section of this article, for information on how to use the editor mode.

- -

To create a new page without linking from another page:

- -
    -
  1. Log in, and have page-creation permission.
    2. -
  2. Enter the following in the URL field of your browser:
    3. -
- -
https://developer.mozilla.org/en-US/docs/new
- -

MDN Creates a new page, with a place for a title, opening the editor to add new content to this page. Refer to Editing an existing page, for information on using editor mode.

- -

Subpage of an existing page

- -

To create a page you want to be below an existing page, in the page hierarchy:

- -
    -
  1. On the 'parent' page, click the Advanced menu (the gear icon in the toolbar), then click New sub-page.
    2. -
  2. An editor view opens for creating a new document.
    3. -
  3. Add a title for this document, in the Title field.
    4. -
  4. Change the Slug field, if needed. For example, if the title is long, and a shorter URL seems appropriate. This field is automatically filled by the editor, substituting underscores for spaces found in the title, changing only the last part of the URL.
    5. -
  5. In the TOC field, select heading levels you want to be displayed in the table of contents for the page. Or select 'No table of contents', if one is not needed.
    6. -
  6. Write content of the page in the editor pane, saving your changes. Refer to Editing an existing page, for further information on using editor mode.
    7. -
- -

Clone of an existing page

- -

If there is an existing page, whose format you wish to use as a base for your new page, you can 'clone' that page, and then change its content.

- -
    -
  1. On the original page, click the Advanced menu (the gear icon in the toolbar), and click Clone this page. An editor view opens, for creating a new document.
    2. -
  2. Change the Title of the page, as appropriate for the new content. The Slug field is updated automatically as you change the Title field.
    3. -
  3. Change the path portion of the Slug field, as needed, to put the new document in a different location in the document hierarchy. In most cases, this is not needed. A cloned page often has similar content to its original, and need to be in a similar location.
    4. -
  4. In the TOC field, select the heading levels you want to be automatically displayed in the table of contents for this page. Or select 'No table of contents', if one is not needed.
    5. -
  5. Write your content in the editor pane, saving your changes. Refer to Editing an existing page, for more information on using editor mode.
    6. -
- -

Link from an existing page

- -

This is a bit of a hybrid. You can create a link on another page, then click the link you just inserted, to create the new page:

- -
    -
  1. Enter the name of your new page, anywhere that makes sense in the text of an existing page.
    2. -
  2. Highlight this new name, and click the Link icon () in the editor's toolbar. The 'Update Link' dialog opens, with the highlighted text in the 'Link To' field.
    3. -
  3. "/en-US/docs/" is inserted by default, to the beginning of the URL field. Enter the name of the page after "/en-US/docs/". The page name does not have to be the same as the link text.
    4. -
  4. Click OK, to create and insert the link.
    5. -
- -

If the page does not yet exist, the link is displayed in red. If the page does exist, the link is displayed blue. If you want to create a new page, but the page title you desire is already taken, check if it makes sense helping edit and improve the page already there. Otherwise, think of a unique title for your new page, and create a link for it. Refer to page naming guide for guidelines.

- -

To add content to your new page, click on the red link you just created, after saving and closing the editor. The new page opens in editor mode, enabling you to start writing. Refer to Editing an existing page, for further information on using editor mode.

- -

Refreshing page content

- -

MDN support of KumaScript macros, and integration of content from other pages can sometimes be hampered by the need for caching of pages, for performance reasons. Pages are built from their source, and this output is cached for future requests. From that moment on, any macros (templates), or integrations (using the macroPage), will not reflect later changes made to the macro, its output, or the contents of the integrated material.

- - - -

See also

- - diff --git a/files/pt-pt/mdn/contribute/howto/criar_uma_conta_mdn/index.html b/files/pt-pt/mdn/contribute/howto/criar_uma_conta_mdn/index.html deleted file mode 100644 index 058456953e..0000000000 --- a/files/pt-pt/mdn/contribute/howto/criar_uma_conta_mdn/index.html +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: Como criar uma conta MDN -slug: MDN/Contribute/Howto/Criar_uma_conta_MDN -tags: - - Como - - Documentação - - Guía - - Metadados MDN - - Principiante -translation_of: MDN/Contribute/Howto/Create_an_MDN_account ---- -
{{MDNSidebar}}
- -

Para editar conteúdo na MDN precisa de um perfil MDN. Não precisa de um perfil se só pretende ler e pesquisar documentos na MDN. Este guia irá ajudá-lo a configurar o seu perfil na MDN.

- -
Porque é que a MDN precisa do meu endereço de e-mail?
-
-O seu endereço de e-mail é utilizado para a recuperação da conta e, se necessário, pelos administradores da MDN para o contactar sobre a sua conta ou atividade no site.
-
-Adicionalmente, pode registar-se para receber notificações (tais como, quando são alteradas páginas especificas) e mensagens (por exemplo, se optar por aderir à nossa equipa de testes beta, poderá receber mensagens sobre as novas funcionalidades que precisam de ser testadas).
-
-O seu endereço de e-mail nunca é exibido na MDN e será utilizado apenas de acordo com a nossa politica de privacidade (EN).
- -
Se iniciou a sessão na MDN via GitHub, e utiliza um endereço de e-mail  "não responder" no GitHub, não irá receber mensagens (incluindo as notificações quando subecrever páginas) na MDN.
- -
    -
  1. No topo de cada página na MDN irá encontrar um botão nomeado "Iniciar sessão". Clique com o seu rato (ou toque no mesmo, se estiver a utilizar um dispositivo móvel) para exibir uma lista de serviços de autenticação que nós suportamos para iniciar a sessão na MDN.
    2. -
  2. Selecione um serviço para iniciar a sessão. Atualmente, apenas está disponível o GitHub. Note que se selecionar o GitHub, será incluída uma hiperligação para o seu perfil do GitHub na página pública do seu perfil da MDN.
    3. -
  3. Siga os avisos do GitHub para entrar na sua conta MDN.
    4. -
  4. Assim que o serviço de autenticação volta para o seu MDN, ser-lhe-á pedido para inserir um nome de utilizador e um endereço de e-mail. O seu nome de utilizador será exibido publicamente para creditar o seu trabalho realizado. Não utilize o seu endereço de e-mail como o seu nome de utilizador.
    5. -
  5. Clique em Criar o meu perfil MDN.
    6. -
  6. Se o endereço de e-mail especificado no passo 4 não for o mesmo que utilizou no serviço de autenticação, por favor, verifique o seu e-mail e clique na hiperligação na mensagem de confirmação que nós lhe enviamos.
    7. -
- -

E é tudo! Agora tem uma conta MDN, e pode editar as páginas imediatamente!

- -

Pode clicar no seu nome no topo de qualquer página da MDN para ver o seu perfil público. Lá, pode clicar em Editar para efetuar alterações ou adições ao seu perfil.

- -
-

Os novos nomes de utilizador não podem conter espaços ou o caráter "@". Lembre-se que o seu nome de utilizador será exibido publicamente para identificar o seu trabalho realizado!

-
diff --git a/files/pt-pt/mdn/contribute/howto/etiqueta/index.html b/files/pt-pt/mdn/contribute/howto/etiqueta/index.html deleted file mode 100644 index 2d0ca3d1d6..0000000000 --- a/files/pt-pt/mdn/contribute/howto/etiqueta/index.html +++ /dev/null @@ -1,375 +0,0 @@ ---- -title: Como etiquetar devidamente as páginas -slug: MDN/Contribute/Howto/Etiqueta -tags: - - Como - - Glossário - - Guía - - Introdução - - Metadados da MDN - - Principiante - - Tutorial - - contribuir -translation_of: MDN/Contribute/Howto/Tag ---- -
{{MDNSidebar}}
- -

As tags de artigo são uma maneira importante de colocar os visitantes em contacto com conteúdo útil. Cada página normalmente deverá ter várias tags para ajudar a manter o conteúdo organizado. Esta página explica a melhor maneira para etiquetar as páginas, e assim os nossos leitores podem encontrar a informação e nós podemos manter-nos organizados.

- -

Para obter ajuda com a interface do utilizador para editar tags, consulte a secção de etiquetagem no nosso guia do editor.

- -

Por favor, utilize as tags devidamente como explicado em baixo. Se não o fizer, as nossas ferramentas automatizadas não irão gerar corretamente as listas de conteúdo, as páginas de destino, e ligação dos artigos.

- -

Como é que a MDN utiliza as tags (etiquetas) 

- -

As tags são utilizadas de vários modos na MDN:

- -
-
Categorização do  documento
-
What type of document is it? Is it a reference? A tutorial? A landing page? Our visitors can use these tags to filter searches, so they're really important!
-
Identificação do tópico
-
What is the article about? Is it about an API? The DOM? Graphics? Again, these tags are important because they can filter searches.
-
Estado da tecnologia
-
What's the status of the technology? Is it non-standard? Obsolete or deprecated? Experimental?
-
Nível de proficiência
-
For tutorials and guides, how advanced is the material covered by the article?
-
Metadados do documento
-
The writing community uses tags to keep track of which pages need what kind of work.
-
- -

Guia do tipo de tag

- -

Here's a quick guide to the types of tags and possible values for them.

- -

Categoria do documento

- -

When you tag an article with one of these categories, you help the automated tools more accurately generate landing pages, tables of contents, and so on. Our new search system will also use these terms so that our visitors can locate reference or guide information at will.

- -

We use the following category names as standard tagging terms:

- -
-
{{Tag("Intro")}}
-
The article provides introductory material about a topic. Ideally each technology area should have only one "Intro".
-
{{Tag("Featured")}}
-
The article is critical and will display prominently on landing pages. Use this tag sparingly (never more than three documents in each documentation area).
-
{{Tag("Reference")}}
-
The article contains reference material about an API, element, attribute, property, or the like.
-
{{Tag("Landing")}}
-
The page is a landing page.
-
{{Tag("Guide")}}
-
The article is a how-to or guide page.
-
{{Tag("Example")}}
-
The article is a code sample page, or has code samples (that is, actual snippets of useful code, not one-line "syntax examples").
-
- -

Tópico

- -

By identifying the article's topic area, you are helping generate better search results (and landing pages and navigation as well).

- -

While there's some room for flexibility here as we identify new topic areas, we try to limit ourselves to the names of APIs or technologies. Some useful examples:

- - - -

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

- -

Conteúdo específico da Mozilla

- -

Estas tags são utilizadas apenas no conteúdo especifico da Mozilla:

- - - -

Identificação de API

- -

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

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

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

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

Estado da tecnologia

- -

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

- -

Here are possible values for these tags:

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

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

- -

Nível de competência técnica

- -

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

- -
-
{{Tag("Beginner")}}
-
Articles designed to introduce the reader to a technology they've never used or have only a passing familiarity with.
-
{{Tag("Intermediate")}}
-
Articles for users who have gotten started with the technology but aren't experts.
-
{{Tag("Advanced")}}
-
Articles about stretching the capabilities of a technology and of the reader.
-
- -

Metadados de documento

- -

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

- -
-
{{Tag("Draft")}}
-
The article is not complete, and is at least in theory still actively being updated (although it's also possible it's been forgotten about). Try to check with the most recent contributors before making changes, in order to avoid potential content collisions.
-
{{Tag("NeedsCompatTable")}}
-
The article needs a table to specify compatibility of a feature across browsers. See here for a guide on contributing to browser compatibility.
-
{{Tag("NeedsContent")}}
-
The article is a stub, or is otherwise lacking information. This tag means that someone should review the content and add more details and/or finish writing the article.
-
{{Tag("NeedsExample")}}
-
The article needs one or more examples created to help illustrate the article's point. These examples should use the live sample system.
-
{{Tag("NeedsLiveSamples")}}
-
The article has one or more examples that need to be updated to use the live sample system.
-
{{Tag("NeedsSpecTable")}}
-
The article needs a table to indicate on which specification document(s) the feature was defined.
-
{{Tag("NeedsUpdate")}}
-
The content is out of date and needs to be updated.
-
{{Tag("l10n:exclude")}}
-
The content is not really worth localizing and will not appear on localization status pages.
-
{{Tag("l10n:priority")}}
-
The content is important and should be marked as a priority for MDN translators. Shows up in an extra priority table on localization status pages.
-
- -

Unindo tudo

- -

Portanto, para cada página que atribui tags de vários tipos de tag, por exemplo:

- -
-
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
-
- -

Filtros de tag e pesquisa

- -

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

- -
-

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

-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Grupo de filtroNome do filtro de pesquisaNome da tag
TópicoAPIs and DOM{{Tag("API")}} || {{Tag("DOM")}} {{Deprecated_Inline}}
Add-ons & Extensions {{Deprecated_Inline}}{{Tag("Add-ons")}} || {{Tag("Extensions")}} || {{Tag("Plugins")}} || {{Tag("Themes")}} || {{Tag("WebExtensions")}}
CSS{{Tag("CSS")}}
Canvas{{Tag("Canvas")}}
Firefox{{Tag("Firefox")}}
Firefox OS{{Tag("Firefox OS")}}
Games{{Tag("Games")}}
HTML{{Tag("HTML")}}
HTTP{{Tag("HTTP")}}
JavaScript{{Tag("JavaScript")}}
Marketplace {{Non-standard_Inline}}{{Tag("Marketplace")}}
MathML{{Tag("MathML")}}
Mobile{{Tag("Mobile")}}
Open Web Apps {{Non-standard_Inline}}{{Tag("Apps")}}
SVG{{Tag("SVG")}}
Web Development{{Tag("Web Development")}}
Web Standards{{Tag("Web")}}
WebExtensions{{Tag("WebExtensions")}}
WebGL{{Tag("WebGL")}}
Writing Documentation{{Tag("MDN Meta")}}
XPCOM {{Non-standard_Inline}}{{Tag("XPCOM")}}
XUL {{Non-standard_Inline}}{{Tag("XUL")}}
{{anch("Skill level")}}I'm an Expert{{Tag("Advanced")}}
Intermediate{{Tag("Intermediate")}}
I'm Learning{{Tag("Beginner")}}
Tipo de documentoDocsThis 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...
- -

Problemas de etiquetagem que pode corrigir

- -

There are several kinds of tag problems you can help fix:

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

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

diff --git "a/files/pt-pt/mdn/contribute/howto/fazer_revis\303\243o_editorial/index.html" "b/files/pt-pt/mdn/contribute/howto/fazer_revis\303\243o_editorial/index.html" deleted file mode 100644 index d2902a8bb6..0000000000 --- "a/files/pt-pt/mdn/contribute/howto/fazer_revis\303\243o_editorial/index.html" +++ /dev/null @@ -1,56 +0,0 @@ ---- -title: Como efetuar uma revisão editorial -slug: MDN/Contribute/Howto/fazer_revisão_editorial -tags: - - Como - - Documentação - - Guía - - Metadados MDN - - Revisão Editorial -translation_of: MDN/Contribute/Howto/Do_an_editorial_review ---- -
{{MDNSidebar}}
- -
{{IncludeSubnav("/pt-PT/docs/MDN")}}
- -

As revisões editoriais consistem em corrigir erros de digitação, ortografia, gramática, utilização ou erros textuais num artigo. Não é preciso ser um especialistas em linguagem para efetuar contribuições úteis para a documentação técnica da MDN, mas os artigos continuam a precisar de edição de cópia e revisão de provas. Isto é efetuado numa revisão editorial.

- -

Este artigo descreve como efetuar uma revisão editorial, que ajuda a assegurar que o conteúdo na MDN é preciso e bem escrito.

- -
-
O que é a tarefa?
-
Copy-editing and proof-reading of articles that are marked as requiring an editorial review.
-
Onde é que esta tem de ser efetuada?
-
Within specific articles that are marked as requiring an editorial review.
-
O que precisa de saber para efetuar a tarefa?
-
You need to have good English grammar and spelling skills. An editorial review is about ensuring that the grammar, spelling, and wording are correct and make sense, and that the MDN writing style guide is followed.
-
Quais os passos a seguir?
-
-
    -
  1. Escolha um artigo para rever: -
      -
    1. Go to the list of articles needing editorial review. This lists all the pages for which an editorial review has been requested.
      2. -
    2. Click on the article link to load the page.
      - Nota: This listing is generated automatically but infrequently, so some articles appear on the list that no longer need editorial review. If the article you picked does not display a banner that says "This article needs an editorial review", skip that article and pick a different one.
      3. -
    -
    2. -
  2. Read the article, paying close attention for typos, spelling, grammar, or usage errors. Don't hesitate to switch to a different page if the first one you choose doesn't suit you.
    3. -
  3. If there are no errors, you don't need to edit the article to mark it as reviewed. Look for the "quick review" box in the left sidebar of the page:
    - Screenshot of the editorial review request sidebar box
    4. -
  4. Deselect the Editorial box and click Save.
    5. -
  5. If you find errors that need to be corrected: -
      -
    1. Click the Edit button near the top of the page; this brings you into the MDN editor.
      2. -
    2. Correct any typos and spelling, grammar, or usage errors you find. You don't have to fix everything to be useful, but be sure to leave the editorial review request in place if you don't feel reasonably sure that you've done a complete review of the entire article.
      3. -
    3. Enter a Revision Comment at the bottom of the article; something like 'Editorial review: fixed typos, grammar & spelling.' This lets other contributors and site editors know what you changed and why.
      4. -
    4. Deselect the Editorial box under Review Needed?. This is located just below the Revision Comment section of the page.
      5. -
    5. Click the Publish button.
      6. -
    -
    6. -
- -
-

Depois de guardar, as suas alterações poderão não ser visíveis de imediato; existe um pequeno atraso enquanto a página é processada e guardada.

-
-
-
diff --git a/files/pt-pt/mdn/contribute/howto/marcar_paginas_javascript/index.html b/files/pt-pt/mdn/contribute/howto/marcar_paginas_javascript/index.html deleted file mode 100644 index e7c610347c..0000000000 --- a/files/pt-pt/mdn/contribute/howto/marcar_paginas_javascript/index.html +++ /dev/null @@ -1,75 +0,0 @@ ---- -title: Como marcar páginas de JavaScript -slug: MDN/Contribute/Howto/Marcar_paginas_JavaScript -tags: - - Como - - Guia(2) - - JavaScript - - Metadados MDN -translation_of: MDN/Contribute/Howto/Tag_JavaScript_pages ---- -
{{MDNSidebar}}

A marcação consiste na adição de informação-metadados às páginas, e assim o conteúdo relacionado pode ser agrupado, por exemplo, na ferramenta de pesquisa.

- -
-
Onde é que isso precisa ser feito?
-
Nas páginas relacionadas com JavaScript especificas sem marcações (tags)
-
O que precisa de saber para efetuar a tarefa?
-
Conhecimento de codificação JavaScript básico, tal como saber o que é um 'método' ou uma 'propriedade'.
-
Quais são os passos a efetuar?
-
-
    -
  1. Escolha uma das páginas na lista acima.
    2. -
  2. Clique na hiperligação do artigo para carregar a página.
    3. -
  3. Assim que a página esteja carregada, clique em "EDITAR" perto do seu topo; isto leva-o para o editor da MDN.
    4. -
  4. Deverá ser adicionada pelo menos uma etiqueta de JavaScript. Aqui tem algumas das etiquetas possíveis para adicionar:
    5. -
  5. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    EtiquetaQue páginas para a utilizar
    Methodmethods
    Propertyproperties
    prototypeprototypes
    Object type namemethods of an object; for example String.fromCharCode should have the tag String
    ECMAScript6 and Experimentalfeatures added in a new ECMAScript version
    Deprecateddeprecated features (whose use is discouraged but still supported)
    Obsoleteobsolete features (which are no longer supported in modern browsers)
    othersSee MDN tagging standards for other possible tags to apply
    -
    6. -
  6. Guarde com um comentário.
    7. -
  7. E concluiu!
    8. -
-
-
- -

 

diff --git a/files/pt-pt/mdn/contribute/howto/participar_testes_beta/index.html b/files/pt-pt/mdn/contribute/howto/participar_testes_beta/index.html deleted file mode 100644 index ec68693a32..0000000000 --- a/files/pt-pt/mdn/contribute/howto/participar_testes_beta/index.html +++ /dev/null @@ -1,52 +0,0 @@ ---- -title: Como participar nos testes "beta" -slug: MDN/Contribute/Howto/Participar_testes_beta -tags: - - MDN Meta - - Metadados MDN -translation_of: MDN/Contribute/Howto/Be_a_beta_tester ---- -
{{MDNSidebar}}

De vez em quando, à medida que os programadores da plataforma Kuma da MDN fazem alterações no site, nós oferecemos acesso antecipado a essas novas funcionalidades aos membros que optaram por participar nos testes "beta". Como é típico com qualquer teste "beta", as funcionalidades podem não funcionar corretamente em algumas situações.

- -

Participar nos testes "beta"

- -
    -
  1. Depois de iniciar a sessão na MDN, clique no seu nome de utilizador na barra de navegação no topo.
    - Shows location of the user's profile link in the top navigation
    - This takes you to your profile page.
    2. -
  2. Clique no botão "Edit".
    - Shows location of the button to edit a user's profile (which may vary depending on window dimensions
    - This opens the profile page in edit mode.
    3. -
  3. Selecione a caixa para Beta tester.
    - Shows the location of the Beta Tester checkbox
    4. -
  4. Clique no botão "Publicar" no fim da página de perfil.
    - Shows the location of the Publish button on a user's profile page
    5. -
- -

Cancelar participação nos testes "beta"

- -
    -
  1. While logged in to MDN, click your user name in the top navigation bar. This takes you to your profile page.
    2. -
  2. Click the Edit button. This opens the profile page in edit mode.
    3. -
  3. Clear the checkbox for Beta tester.
    4. -
  4. Click the Publish button.
    5. -
- -

Dê a sua opinião/comentário sobre os testes "beta"

- -

There are two ways you can give feedback about a beta test:

- - - -
    -
  1. Create an account on Bugzilla if you don't already have one.
    2. -
  2. Open a bug report in Bugzilla for MDN.
    3. -
  3. Include the word "beta" in the Summary field to help MDN developers filter and triage incoming bugs.
    4. -
  4. Fill out the bug report form to the best of your ability. Be as detailed as possible.
    5. -
  5. Click the Submit button.
    6. -
- -

 

diff --git a/files/pt-pt/mdn/contribute/howto/report_a_problem/index.html b/files/pt-pt/mdn/contribute/howto/report_a_problem/index.html new file mode 100644 index 0000000000..764d3fca0c --- /dev/null +++ b/files/pt-pt/mdn/contribute/howto/report_a_problem/index.html @@ -0,0 +1,24 @@ +--- +title: Como comunicar um problema na MDN +slug: MDN/Contribute/Howto/Comunicar_um_problema +tags: + - Como... + - Guía + - Metadados MDN +translation_of: MDN/Contribute/Howto/Report_a_problem +--- +
{{MDNSidebar}}
+ +

De vez em quando, pode encontrar problemas ao utilizar a MDN. Se é um problema com a infra-estrutura do site ou um erro no conteúdo da documentação, pode tentar corrigi-lo ou comunicar o problema. Enquanto o primeiro é o preferido, o último é às vezes o melhor que pode gerir, e isso também está bem.

+ +

Erros de documentação ou pedidos

+ +

Obviously, since MDN is a wiki, the best thing you can possibly do is fix problems you spot yourself. But maybe you don't know the answer or are in the middle of a deadline on your own project or something, and need to jot down the problem so someone can look at it later.

+ +

As is the case with all things Mozilla, you report a documentation problem by filing a bug. That's when filing a documentation request bug comes in. The documentation request form gathers the information needed to get us started on fixing the issue.

+ +

Of course, our writing community is busy, so sometimes the quickest way to see a documentation problem resolved is to fix it yourself. See How to create and edit pages for details.

+ +

Erros (bugs) do site ou pedidos de funcionalidades

+ +

Kuma, the Mozilla-developed platform used for the MDN web site, is in a state of continuous development. Our developers—as well as a number of volunteer contributors—are constantly making improvements. If you see a bug, or have a problem with the site, or even have a suggestion for something that could make the software more awesome, you can use the Kuma bug form to file a report. You can also use this form to report performance problems with the site, though odds are that performance-monitoring tools have already notified the appropriate people.

diff --git a/files/pt-pt/mdn/contribute/howto/tag/index.html b/files/pt-pt/mdn/contribute/howto/tag/index.html new file mode 100644 index 0000000000..2d0ca3d1d6 --- /dev/null +++ b/files/pt-pt/mdn/contribute/howto/tag/index.html @@ -0,0 +1,375 @@ +--- +title: Como etiquetar devidamente as páginas +slug: MDN/Contribute/Howto/Etiqueta +tags: + - Como + - Glossário + - Guía + - Introdução + - Metadados da MDN + - Principiante + - Tutorial + - contribuir +translation_of: MDN/Contribute/Howto/Tag +--- +
{{MDNSidebar}}
+ +

As tags de artigo são uma maneira importante de colocar os visitantes em contacto com conteúdo útil. Cada página normalmente deverá ter várias tags para ajudar a manter o conteúdo organizado. Esta página explica a melhor maneira para etiquetar as páginas, e assim os nossos leitores podem encontrar a informação e nós podemos manter-nos organizados.

+ +

Para obter ajuda com a interface do utilizador para editar tags, consulte a secção de etiquetagem no nosso guia do editor.

+ +

Por favor, utilize as tags devidamente como explicado em baixo. Se não o fizer, as nossas ferramentas automatizadas não irão gerar corretamente as listas de conteúdo, as páginas de destino, e ligação dos artigos.

+ +

Como é que a MDN utiliza as tags (etiquetas) 

+ +

As tags são utilizadas de vários modos na MDN:

+ +
+
Categorização do  documento
+
What type of document is it? Is it a reference? A tutorial? A landing page? Our visitors can use these tags to filter searches, so they're really important!
+
Identificação do tópico
+
What is the article about? Is it about an API? The DOM? Graphics? Again, these tags are important because they can filter searches.
+
Estado da tecnologia
+
What's the status of the technology? Is it non-standard? Obsolete or deprecated? Experimental?
+
Nível de proficiência
+
For tutorials and guides, how advanced is the material covered by the article?
+
Metadados do documento
+
The writing community uses tags to keep track of which pages need what kind of work.
+
+ +

Guia do tipo de tag

+ +

Here's a quick guide to the types of tags and possible values for them.

+ +

Categoria do documento

+ +

When you tag an article with one of these categories, you help the automated tools more accurately generate landing pages, tables of contents, and so on. Our new search system will also use these terms so that our visitors can locate reference or guide information at will.

+ +

We use the following category names as standard tagging terms:

+ +
+
{{Tag("Intro")}}
+
The article provides introductory material about a topic. Ideally each technology area should have only one "Intro".
+
{{Tag("Featured")}}
+
The article is critical and will display prominently on landing pages. Use this tag sparingly (never more than three documents in each documentation area).
+
{{Tag("Reference")}}
+
The article contains reference material about an API, element, attribute, property, or the like.
+
{{Tag("Landing")}}
+
The page is a landing page.
+
{{Tag("Guide")}}
+
The article is a how-to or guide page.
+
{{Tag("Example")}}
+
The article is a code sample page, or has code samples (that is, actual snippets of useful code, not one-line "syntax examples").
+
+ +

Tópico

+ +

By identifying the article's topic area, you are helping generate better search results (and landing pages and navigation as well).

+ +

While there's some room for flexibility here as we identify new topic areas, we try to limit ourselves to the names of APIs or technologies. Some useful examples:

+ + + +

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

+ +

Conteúdo específico da Mozilla

+ +

Estas tags são utilizadas apenas no conteúdo especifico da Mozilla:

+ + + +

Identificação de API

+ +

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

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

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

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

Estado da tecnologia

+ +

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

+ +

Here are possible values for these tags:

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

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

+ +

Nível de competência técnica

+ +

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

+ +
+
{{Tag("Beginner")}}
+
Articles designed to introduce the reader to a technology they've never used or have only a passing familiarity with.
+
{{Tag("Intermediate")}}
+
Articles for users who have gotten started with the technology but aren't experts.
+
{{Tag("Advanced")}}
+
Articles about stretching the capabilities of a technology and of the reader.
+
+ +

Metadados de documento

+ +

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

+ +
+
{{Tag("Draft")}}
+
The article is not complete, and is at least in theory still actively being updated (although it's also possible it's been forgotten about). Try to check with the most recent contributors before making changes, in order to avoid potential content collisions.
+
{{Tag("NeedsCompatTable")}}
+
The article needs a table to specify compatibility of a feature across browsers. See here for a guide on contributing to browser compatibility.
+
{{Tag("NeedsContent")}}
+
The article is a stub, or is otherwise lacking information. This tag means that someone should review the content and add more details and/or finish writing the article.
+
{{Tag("NeedsExample")}}
+
The article needs one or more examples created to help illustrate the article's point. These examples should use the live sample system.
+
{{Tag("NeedsLiveSamples")}}
+
The article has one or more examples that need to be updated to use the live sample system.
+
{{Tag("NeedsSpecTable")}}
+
The article needs a table to indicate on which specification document(s) the feature was defined.
+
{{Tag("NeedsUpdate")}}
+
The content is out of date and needs to be updated.
+
{{Tag("l10n:exclude")}}
+
The content is not really worth localizing and will not appear on localization status pages.
+
{{Tag("l10n:priority")}}
+
The content is important and should be marked as a priority for MDN translators. Shows up in an extra priority table on localization status pages.
+
+ +

Unindo tudo

+ +

Portanto, para cada página que atribui tags de vários tipos de tag, por exemplo:

+ +
+
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
+
+ +

Filtros de tag e pesquisa

+ +

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

+ +
+

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

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Grupo de filtroNome do filtro de pesquisaNome da tag
TópicoAPIs and DOM{{Tag("API")}} || {{Tag("DOM")}} {{Deprecated_Inline}}
Add-ons & Extensions {{Deprecated_Inline}}{{Tag("Add-ons")}} || {{Tag("Extensions")}} || {{Tag("Plugins")}} || {{Tag("Themes")}} || {{Tag("WebExtensions")}}
CSS{{Tag("CSS")}}
Canvas{{Tag("Canvas")}}
Firefox{{Tag("Firefox")}}
Firefox OS{{Tag("Firefox OS")}}
Games{{Tag("Games")}}
HTML{{Tag("HTML")}}
HTTP{{Tag("HTTP")}}
JavaScript{{Tag("JavaScript")}}
Marketplace {{Non-standard_Inline}}{{Tag("Marketplace")}}
MathML{{Tag("MathML")}}
Mobile{{Tag("Mobile")}}
Open Web Apps {{Non-standard_Inline}}{{Tag("Apps")}}
SVG{{Tag("SVG")}}
Web Development{{Tag("Web Development")}}
Web Standards{{Tag("Web")}}
WebExtensions{{Tag("WebExtensions")}}
WebGL{{Tag("WebGL")}}
Writing Documentation{{Tag("MDN Meta")}}
XPCOM {{Non-standard_Inline}}{{Tag("XPCOM")}}
XUL {{Non-standard_Inline}}{{Tag("XUL")}}
{{anch("Skill level")}}I'm an Expert{{Tag("Advanced")}}
Intermediate{{Tag("Intermediate")}}
I'm Learning{{Tag("Beginner")}}
Tipo de documentoDocsThis 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...
+ +

Problemas de etiquetagem que pode corrigir

+ +

There are several kinds of tag problems you can help fix:

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

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

diff --git a/files/pt-pt/mdn/contribute/howto/write_a_new_entry_in_the_glossary/index.html b/files/pt-pt/mdn/contribute/howto/write_a_new_entry_in_the_glossary/index.html new file mode 100644 index 0000000000..105853672c --- /dev/null +++ b/files/pt-pt/mdn/contribute/howto/write_a_new_entry_in_the_glossary/index.html @@ -0,0 +1,114 @@ +--- +title: Como escrever e referenciar uma entrada no glossário +slug: MDN/Contribute/Howto/Como_escrever_uma_nova_entrada_no_Glossario +tags: + - Como... + - Glossário + - Guia(2) + - Metadados da MDN +translation_of: MDN/Contribute/Howto/Write_a_new_entry_in_the_Glossary +--- +
{{MDNSidebar}}
+ +

O glossário da MDN é o local onde nós definimos toda a terminologia, gíria, e abreviações utilizadas na documentação e programação. Contribuir para o glossário é uma maneira simples de tornar a Web mais fácil para todos entenderem. Você não precisa de um alto nível de habilidade técnica para escrever entradas de glossário porque elas devem permanecer simples e diretas.

+ +

Como escrever uma entrada

+ +

Se você está procurando por tópicos que precisam de uma entrada de glossário, verifique a lista de termos não documentados no final da página de destino do Glossário; clique em qualquer um desses links para iniciar uma nova página do Glossário para o item que você clicou; então siga os passos abaixo.

+ +

Se você tem uma ideia para um nova entrada de glossário, basta abrir o botão em uma nova aba, e então siga os passos abaixo do botão.

+ +

Adicionar Nova Entrada ao Glossário

+ +

 

+ +

Passo 1: Escreva um resumo

+ +

The first paragraph of any glossary page is a simple and short description of the term (preferably no more than two sentences). Make sure anyone reading the description can understand the defined term immediately.

+ +
+

Nota: Please don't copy-and-paste definitions from elsewhere (especially not Wikipedia, since its range of license versions is smaller, and thus incompatible with that of MDN). It's really important to make sure this content is simple and easy to understand. It's worth spending some time on it rather than stealing content blindly. This glossary should be useful new content, not repeating things from elsewhere.

+
+ +

Links to the glossary entry will use these summaries inside their tooltips, so that readers can see the definitions without navigating away from the page they're on. (See below how to insert links to glossary entries with the \{{Glossary}} macro.)

+ +

If you must, you can add a few extra paragraphs, but it's very easy to find yourself writing a whole article. Writing a whole article is fine, but please don't put it in the glossary. If you aren't sure where to put your article, feel free to reach out to discuss it.

+ +

Passo 2: Expanda com hiperligações

+ +

Finally, a glossary entry should always end with a "Learn more" section. This section should contain links to help the reader move forward: discovering more details, learning to use the relevant technology, and so on.

+ +

We recommend that you sort the links into at least these three groups:

+ +
+
Conhecimento geral
+
Links that provide more general information; for example, a link to Wikipedia is a good starting point.
+
Referência técnica
+
Links to more in-depth technical information, on MDN or elsewhere.
+
Saber sobre a mesma
+
Hiperligações para tutoriais, exercícios, quaisquer outros materiais que ajudem o leitor a saber como utilizar a tecnologia por de trás do termo definido.
+
+ +

Termos sugeridos

+ +

So you want to contribute but you don't know which terms need to be defined? Here's a list of suggestions. Click one and get started!

+ +

Lidar com a desambiguação

+ +

Sometimes, a term has several meanings depending on the context. To resolve the ambiguities, you must follow those guidelines:

+ + + +

Let's illustrate that with an example. The term signature can have different meanings in at least three different contexts: security, function and email.

+ +
    +
  1. A página de Glossário/Assinatura é a página de desambiguação como a  {{TemplateLink("GlossaryDisambiguation")}} macro.
    2. +
  2. The page Glossary/Signature/Security is the page defining a signature in a security context.
    3. +
  3. The page Glossary/Signature/Function is the page defining a function signature.
    4. +
  4. The page Glossary/Signature/Email is the page defining email signature.
    5. +
+ +

Como utilizar a macro \{{Glossary}}

+ +

The glossary is much more useful when people can access the definitions from another document without navigating away from what they're reading. Therefore we urge you to link to the glossary whenever you can, using the {{TemplateLink("Glossary")}} macro:

+ + + + + + + + + + + + + + + + + + + + + + + + + + +
MacroResultadoNota
\{{Glossary("browser")}}{{Glossary("browser")}}When a text matches the term to be defined, just use the macro as is (it's case insensitive)
\{{Glossary("browser", "Web browser")}}{{Glossary("browser","Web browser")}}To display an alternative text, use the second argument to specify that text
\{{Glossary("browser", "Web browser", 1)}}{{Glossary("browser","Web browser",1)}}Specify 1 as an optional third argument to display the link as a regular link rather than a subtle hint
+ +

Links created with the \{{Glossary}} macro always display a tooltip containing the glossary entry's summary paragraph.

+ +

Utilização das linhas diretrizes

+ +

In many cases, it's perfectly safe to use that macro everywhere on MDN. However, there are a few cases you should handle with care:

+ + diff --git a/files/pt-pt/mdn/contribute/howto/write_an_api_reference/sidebars/index.html b/files/pt-pt/mdn/contribute/howto/write_an_api_reference/sidebars/index.html new file mode 100644 index 0000000000..8e28e33556 --- /dev/null +++ b/files/pt-pt/mdn/contribute/howto/write_an_api_reference/sidebars/index.html @@ -0,0 +1,109 @@ +--- +title: Barras laterais de referência da API +slug: MDN/Structures/API_references/Barras_laterais_de_referencia_da_API +tags: + - API + - Guía + - Referencia + - barras laterais + - groupdata + - onboarding +translation_of: MDN/Structures/API_references/API_reference_sidebars +--- +
{{MDNSidebar}}

Pode incluir uma barra lateral personalizada nas páginas de referência da API para exibir as hiperligações para as 'Interfaces' relacionadas, tutoriais, e outros recursos relevantes, apenas para essa API. Este artigo explica como.

+ +

O que precisa de fazer?

+ +

You need to take the following three steps to create your API sidebar:

+ +
    +
  1. Create your API reference pages.
    2. +
  2. Add an entry for your particular API into the KumaScript repo's GroupData.json data file.
    3. +
  3. Use the \{{APIRef}} macro to insert the sidebar into each page you want to display it on.
    4. +
+ +

Let's run through each of these steps in turn. The example we'll refer to in this article is the Fetch API.

+ +

Criar páginas de referência da sua API

+ +

Before you can add sidebars to your pages, you'll need to create the pages themselves (see our What does an API reference need? guide for more guidance).

+ +

Adicionar uma entrada para GroupData.json

+ +

The GroupData.json file holds all the data relating to what links should appear in API reference sidebars. When invoked, the \{{APIRef}} macro takes an API name given to it as a parameter, looks up that name in GroupData.json, builds a sidebar as appropriate, and inserts it in the page.

+ +

To add an entry to GroupData.json, you need to:

+ +
    +
  1. Make sure you have a GitHub account.
    2. +
  2. Fork the KumaScript repo, create a new branch to contain your changes, and clone the repo locally.
    3. +
  3. Checkout your new branch before starting work, and make sure you push changes to it after finishing.
    4. +
  4. Create a pull request so that the MDN team can review your work, and ask for changes if necessary.
    5. +
+ +

If you need help with using GitHub, a more detailed guide can be found at our compatibility tables guide.

+ +

The GroupData.json file can be found inside the macros directory of the KumaScript repo. Looking at it, you'll see a giant JSON structure, with each API having its own member. The name is the API name, and the value is an object containing several submembers defining the sidebar links to be created.

+ +

For example, look at the Fetch API page on MDN. The corresponding entry in GroupData.json looks like this:

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

As you can see, we've used "Fetch API" for the name, and inside the object value we include a number of submembers.

+ +

Submembers to include inside a GroupData entry

+ +

This section lists all the submembers you could include in a GroupData entry.

+ +

Note that Most of the values included inside the listed submembers equate to both the link text, and slugs appended to the end of the main API index page —  https://developer.mozilla.org/<language-code>/docs/Web/API — to create the final URL for the displayed link. So for example, "Body" will result in a link being created like so in the en-US locale:

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

There are a few exceptions. For example the "guides" submember contains one or more sets of link information (title and slug) that defines links to associated guides/tutorials. In this case the slugs are appended to the end of the MDN docs root — https://developer.mozilla.org/<language-code>/docs — allowing an article anywhere on MDN to be included.

+ +

Here are the available members. In each case, an example is included that assumes that the local is en-US.

+ +
    +
  1. +

    "overview" — the value is an array, inside of which you include the slug of the API overview page, if there is one. "Fetch API" results in a link being made to https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API.

    +
    2. +
  2. +

    "interfaces" — the value is an array in which you should list all of the interfaces that form part of that API. "Body" results in a link being made to https://developer.mozilla.org/en-US/docs/Web/API/Body.

    +
    3. +
  3. +

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

    +
    4. +
  4. +

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

    +
    5. +
  5. +

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

    +
    6. +
  6. +

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

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

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

    +
    7. +
+ +

Inserir a barra lateral nas suas páginas

+ +

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

+ +

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

diff --git a/files/pt-pt/mdn/editor/basicos/index.html b/files/pt-pt/mdn/editor/basicos/index.html deleted file mode 100644 index 78a0023b70..0000000000 --- a/files/pt-pt/mdn/editor/basicos/index.html +++ /dev/null @@ -1,72 +0,0 @@ ---- -title: Elementos da IU do Editor -slug: MDN/Editor/Basicos -tags: - - Documentação - - Guía - - MDN - - Metadados da MDN - - Principiante - - editor -translation_of: MDN/Editor/Basics ---- -
{{MDNSidebar}}
- -

O editor WYSIWYG na MDN foi projetado para facilitar ao máximo a criação, edição e melhoramento de artigos e outras páginas em praticamente qualquer lugar do site. A janela do editor, mostrada abaixo, consiste em oito áreas principais. Este guia fornece informação sobre cada secção para que saiba como utilizar todo o nosso ambiente de edição.

- -
-

We're constantly working on improvements to MDN, so there will be times when this documentation or the screen shots below may be slightly out-of-date. We'll periodically update this documentation, though, to avoid it being unusably behind.

-
- -

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

- -

The editor UI contains the following sections, as shown above. Click a link below to read about that section of the editor.

- - - -

Caixa de edição

- -

The edit box is, of course, where you actually do your writing.

- -

Right-clicking in the editor box offers appropriate additional options depending on the context of your click: right-clicking in a table offers table-related options and right-clicking in a list offers list-related options, for example. By default, the editor uses its own contextual menu when you right-click on the editor. To access your browser's default contextual menu (such as to access the Firefox spell checker's list of suggested corrections), hold down the Shift or Control key (the Command key on Mac OS X) while clicking.

- -

When working in the edit box, you can use its keyboard shortcuts.

- -

Comentário da revisão

- -

After you've made your changes, it's strongly recommended you add a comment to your revision. This is displayed in the revision history for the page, as well as on the Revision Dashboard. It helps to explain or justify your changes to others that may review your work later. To add a revision comment, simply type the note into the revision comment box before clicking either of the Publish buttons at the top or bottom of the page.

- -

There are a few reasons this is helpful:

- - - -

Pedidos de revisão

- -

The MDN community uses reviews to try to monitor and improve the quality of MDN's content. This works by setting a flag on an article indicating that a review is needed. You can learn more about technical reviews and editorial review in the How to guides.

- -

To request a review on the article you've worked on, toggle on the checkbox next to the type of review that's needed. Technical reviews should be requested any time you make changes to the explanation of how something technical works, while editorial reviews are a good idea when you've made changes and would like someone to review your writing and style choices.

- -

While selecting a review checkbox adds the article to the lists of those needing technical review or needing editorial review, it does not guarantee that anyone will immediately review the article. For technical reviews, it's a good idea to directly contact a subject-matter expert in the relevant technical area. For editorial reviews, you can post in the MDN discussion forum to request that someone review your changes.

- -

Be sure to click one of the Publish buttons after making your selections, to commit your review request.

- -

Consulte também

- - - - diff --git a/files/pt-pt/mdn/editor/index.html b/files/pt-pt/mdn/editor/index.html deleted file mode 100644 index a13dda6b6a..0000000000 --- a/files/pt-pt/mdn/editor/index.html +++ /dev/null @@ -1,20 +0,0 @@ ---- -title: Guia para o editor da IU da MDN -slug: MDN/Editor -tags: - - Documentação - - Guía - - Landing - - MDN - - Metadados MDN -translation_of: MDN/Editor ---- -
{{MDNSidebar}}
- -

O editor WYSIWYG (o que vê é o que obtém) para a wiki dos Documentos da Web da MDN torna fácil a contribuição para novo conteúdo. Este guia mostra-lhe como utilizar o editor e melhorar a sua produtividade. Por favor, leia e concorde com os Termos da Mozilla antes de editar ou criar novas páginas.

- -

O guia de estilo de escrita da MDN oferece informação sobre como formatar e estilizar o próprio conteúdo, incluindo as nossas regras de gramática e ortografia preferidas.

- -

{{LandingPageListSubpages}}

- -

{{EditorGuideQuicklinks}}

diff --git a/files/pt-pt/mdn/guidelines/convencoes_definicoes/index.html b/files/pt-pt/mdn/guidelines/convencoes_definicoes/index.html deleted file mode 100644 index f3a57c70c3..0000000000 --- a/files/pt-pt/mdn/guidelines/convencoes_definicoes/index.html +++ /dev/null @@ -1,201 +0,0 @@ ---- -title: MDN - Convenções e Definições -slug: MDN/Guidelines/Convencoes_definicoes -tags: - - Documentação - - Guía - - Linhas Diretrizes - - MDN - - Metadados MDN -translation_of: MDN/Guidelines/Conventions_definitions ---- -
{{MDNSidebar}}
- -
{{IncludeSubnav("/pt-PT/docs/MDN")}}
- -

Este artigo define algumas convenções e definições que são normalmente utilizadas na MDN, que talvez não sejam óbvias para algumas pessoas quando elas as encontrarem na documentação.

- -

Definições

- -

Desaprovada e obsoleta

- -

Desaprovada e obsoleta são termos comuns associados com as tecnologias e especificações, mas o que eles significam?

- -
-
Desaprovada
-
Na MDN, o termo 'desaprovada' utilizado para marcar uma API ou tecnologia que já não é recomendada, mas que ainda está implementada e poderá funcionar. Mais recentemente, nós atualizamos-la para a definição utilizada no projeto de dados compatíveis do navegador, que é que "a funcionalidade já não é mais recomendada. Esta poderá ser removida no futuro ou pode ser mantida apenas para fins de compatibilidade. Evite utilizar esta funcionalidade".
-
Obsoleta
-
No MDN, o termo 'obsoleta'utilizado para marcar uma API ou tecnologia que já não é mais recomendada, mas também não é mais implementada nos navegadores. Isto foi no entanto confuso - é semelhante a obsoleta, e a distinção não é muito útil (ainda não o deveria utilizar num site de produção). Portanto, nós não estamos mais a utilizá-lo, e quaisquer instâncias encontradas deveriam ser removidas/substituídas por 'obsoleta'.
-
- -

Experimental

- -

Experimental can mean different things depending on the context you hear or read it in. When a technology is described as experimental on MDN, it means that the technology is nascent and immature, and currently in the process of being added to the Web platform (or considered for addition).

- -

One or both of these will be true:

- - - -

If one or both of these definitions is true, then you should think carefully before you start using that technology in any kind of production project (i.e. not just a demo or experiment). See also the definition of experimental in our browser-compat-data project.

- - - -

Conversely, an item is no longer experimental when:

- - - - - -

Páginas arquivadas

- -

Archived pages are pages that are stored in the MDN Archive of obsolete content. These pages contain information out-of-date enough that it is not directly useful to anyone anymore.

- -

Most commonly, these concern Mozilla projects that have been discontinued and shouldn't be relied on anymore. But we don't simply delete them because they form a useful historical record, and some of the patterns or ideas contained within might be useful for future work. A good example is the B2G (Firefox OS) project.

- -

Quando é que uma página deverá ser arquivada?

- -

A page should be archived if it fits the above description. To archive a page, you should use the "Move page feature" (Advanced > Move this article) to move the page into the Archive page tree (/en-US/docs/Archive). You might not have the permissions to use this feature, and before you start archiving pages you should discuss it with the MDN community first — talk to us on our Discourse forum.

- -

Páginas eliminadas

- -

Deleted pages are pages that have been explicitly deleted from MDN — see for example the SharedKeyframeList interface and SharedKeyframeList() constructor. These pages contain information that is not useful in any way anymore, and/or might be incorrect to the point where keeping it available might be confusing or bad for people to know.

- -

These might be:

- - - -

Quando é que uma página deverá ser eliminada?

- -

A page should be deleted if it fits the above description. To delete a page, you should use the "Delete this page feature" (Advanced > Delete this page) to delete the page. You will probably not have the permissions to use this feature, and when thinking about deleting pages you should discuss it with the MDN community first — talk to us on our Discourse forum.

- - - - - -

Quando documentar novas tecnologias

- -

On MDN, we are constantly looking to document new web standards technologies as appropriate. We try to strike a balance between publishing the documentation early enough so developers can learn about new features as soon as they need to, and publishing it late enough so that the technology is mature and stable so the docs won't need constant updates or rapid removal.

- -

In general, our definition of the earliest we'll consider documenting a new technology is:

- -

"When the feature is on a standards track and is implemented somewhere."

- -

You should definitely consider documenting a new technology if:

- - - -

You should be more wary of documenting a new technology (but should still consider it if it makes sense) if it:

- - - -

You should not consider documenting a new technology if it:

- - - - - -

Convenções

- -

Quando é removido algo da especificação

- -

Sometimes during the development of a new specification, or over the course of the evolution of living standards such as HTML, new elements, methods, properties, and so forth are added to the specification, stay there for a while, then get removed again. Sometimes this happens very quickly, and sometimes these new items remain in the specification for months or even years before being removed. This can make it tricky to decide how to handle the removal of the item from the spec. Here are some guidelines to help you decide what to do.

- -
-

For the purposes of this discussion, the word "item" is used to mean anything which can be part of a specification: an element or an attribute of an element, an interface or any individual method, property, or other member of an interface, and so forth.

-
- - - -

Please use common sense with wording of warning messages and other changes to text suggested by the guidelines above. Different items will require different wording and handling of the situation. When in doubt, feel free to ask for advice on the MDN Web Docs chat room on Matrix, or on the MDN Web Docs discussion forum.

- -

Copiar conteúdo dentro da MDN

- -

Sometimes, you need to reuse the same text on multiple pages (or you want to use one page's content as a template for another page). You have three options:

- - - -

Copiar conteúdo de outro lado

- -

Often, there is useful content about a topic somewhere on the web besides on MDN. However, copying such content can be fraught with difficulties, both legal and technical.

- -

On the technical level, search engines typically penalize a site in their rankings for reproducing content available elsewhere. Therefore, it is preferable to have original content on MDN, to enhance the search engine ranking of MDN's content. You can link to the existing content from MDN.

- -

On the legal level, you must be authorized to contribute the content, and it must be licensed and attributed in a way that is compatible with MDN's license.

- - diff --git a/files/pt-pt/mdn/guidelines/conventions_definitions/index.html b/files/pt-pt/mdn/guidelines/conventions_definitions/index.html new file mode 100644 index 0000000000..f3a57c70c3 --- /dev/null +++ b/files/pt-pt/mdn/guidelines/conventions_definitions/index.html @@ -0,0 +1,201 @@ +--- +title: MDN - Convenções e Definições +slug: MDN/Guidelines/Convencoes_definicoes +tags: + - Documentação + - Guía + - Linhas Diretrizes + - MDN + - Metadados MDN +translation_of: MDN/Guidelines/Conventions_definitions +--- +
{{MDNSidebar}}
+ +
{{IncludeSubnav("/pt-PT/docs/MDN")}}
+ +

Este artigo define algumas convenções e definições que são normalmente utilizadas na MDN, que talvez não sejam óbvias para algumas pessoas quando elas as encontrarem na documentação.

+ +

Definições

+ +

Desaprovada e obsoleta

+ +

Desaprovada e obsoleta são termos comuns associados com as tecnologias e especificações, mas o que eles significam?

+ +
+
Desaprovada
+
Na MDN, o termo 'desaprovada' utilizado para marcar uma API ou tecnologia que já não é recomendada, mas que ainda está implementada e poderá funcionar. Mais recentemente, nós atualizamos-la para a definição utilizada no projeto de dados compatíveis do navegador, que é que "a funcionalidade já não é mais recomendada. Esta poderá ser removida no futuro ou pode ser mantida apenas para fins de compatibilidade. Evite utilizar esta funcionalidade".
+
Obsoleta
+
No MDN, o termo 'obsoleta'utilizado para marcar uma API ou tecnologia que já não é mais recomendada, mas também não é mais implementada nos navegadores. Isto foi no entanto confuso - é semelhante a obsoleta, e a distinção não é muito útil (ainda não o deveria utilizar num site de produção). Portanto, nós não estamos mais a utilizá-lo, e quaisquer instâncias encontradas deveriam ser removidas/substituídas por 'obsoleta'.
+
+ +

Experimental

+ +

Experimental can mean different things depending on the context you hear or read it in. When a technology is described as experimental on MDN, it means that the technology is nascent and immature, and currently in the process of being added to the Web platform (or considered for addition).

+ +

One or both of these will be true:

+ + + +

If one or both of these definitions is true, then you should think carefully before you start using that technology in any kind of production project (i.e. not just a demo or experiment). See also the definition of experimental in our browser-compat-data project.

+ + + +

Conversely, an item is no longer experimental when:

+ + + + + +

Páginas arquivadas

+ +

Archived pages are pages that are stored in the MDN Archive of obsolete content. These pages contain information out-of-date enough that it is not directly useful to anyone anymore.

+ +

Most commonly, these concern Mozilla projects that have been discontinued and shouldn't be relied on anymore. But we don't simply delete them because they form a useful historical record, and some of the patterns or ideas contained within might be useful for future work. A good example is the B2G (Firefox OS) project.

+ +

Quando é que uma página deverá ser arquivada?

+ +

A page should be archived if it fits the above description. To archive a page, you should use the "Move page feature" (Advanced > Move this article) to move the page into the Archive page tree (/en-US/docs/Archive). You might not have the permissions to use this feature, and before you start archiving pages you should discuss it with the MDN community first — talk to us on our Discourse forum.

+ +

Páginas eliminadas

+ +

Deleted pages are pages that have been explicitly deleted from MDN — see for example the SharedKeyframeList interface and SharedKeyframeList() constructor. These pages contain information that is not useful in any way anymore, and/or might be incorrect to the point where keeping it available might be confusing or bad for people to know.

+ +

These might be:

+ + + +

Quando é que uma página deverá ser eliminada?

+ +

A page should be deleted if it fits the above description. To delete a page, you should use the "Delete this page feature" (Advanced > Delete this page) to delete the page. You will probably not have the permissions to use this feature, and when thinking about deleting pages you should discuss it with the MDN community first — talk to us on our Discourse forum.

+ + + + + +

Quando documentar novas tecnologias

+ +

On MDN, we are constantly looking to document new web standards technologies as appropriate. We try to strike a balance between publishing the documentation early enough so developers can learn about new features as soon as they need to, and publishing it late enough so that the technology is mature and stable so the docs won't need constant updates or rapid removal.

+ +

In general, our definition of the earliest we'll consider documenting a new technology is:

+ +

"When the feature is on a standards track and is implemented somewhere."

+ +

You should definitely consider documenting a new technology if:

+ + + +

You should be more wary of documenting a new technology (but should still consider it if it makes sense) if it:

+ + + +

You should not consider documenting a new technology if it:

+ + + + + +

Convenções

+ +

Quando é removido algo da especificação

+ +

Sometimes during the development of a new specification, or over the course of the evolution of living standards such as HTML, new elements, methods, properties, and so forth are added to the specification, stay there for a while, then get removed again. Sometimes this happens very quickly, and sometimes these new items remain in the specification for months or even years before being removed. This can make it tricky to decide how to handle the removal of the item from the spec. Here are some guidelines to help you decide what to do.

+ +
+

For the purposes of this discussion, the word "item" is used to mean anything which can be part of a specification: an element or an attribute of an element, an interface or any individual method, property, or other member of an interface, and so forth.

+
+ + + +

Please use common sense with wording of warning messages and other changes to text suggested by the guidelines above. Different items will require different wording and handling of the situation. When in doubt, feel free to ask for advice on the MDN Web Docs chat room on Matrix, or on the MDN Web Docs discussion forum.

+ +

Copiar conteúdo dentro da MDN

+ +

Sometimes, you need to reuse the same text on multiple pages (or you want to use one page's content as a template for another page). You have three options:

+ + + +

Copiar conteúdo de outro lado

+ +

Often, there is useful content about a topic somewhere on the web besides on MDN. However, copying such content can be fraught with difficulties, both legal and technical.

+ +

On the technical level, search engines typically penalize a site in their rankings for reproducing content available elsewhere. Therefore, it is preferable to have original content on MDN, to enhance the search engine ranking of MDN's content. You can link to the existing content from MDN.

+ +

On the legal level, you must be authorized to contribute the content, and it must be licensed and attributed in a way that is compatible with MDN's license.

+ + diff --git a/files/pt-pt/mdn/guidelines/does_this_belong_on_mdn/index.html b/files/pt-pt/mdn/guidelines/does_this_belong_on_mdn/index.html new file mode 100644 index 0000000000..429ffa389f --- /dev/null +++ b/files/pt-pt/mdn/guidelines/does_this_belong_on_mdn/index.html @@ -0,0 +1,200 @@ +--- +title: Isto pertence aos MDN Web Docs? +slug: MDN/Guidelines/Isto_pertence_a_MDN +tags: + - Guía + - Linhas Diretrizes + - Metadados MDN +translation_of: MDN/Guidelines/Does_this_belong_on_MDN +--- +
{{MDNSidebar}}
+ +
{{IncludeSubnav("/pt-PT/docs/MDN")}}
+ +

Neste artigo, irá encontrar informação a descrever como decidir se determinado tópico e/ ou tipo de conteúdo deverá ou não ser incluído na MDN Web Docs. Nós também iremos considerar outros lugares em que pode colocar o conteúdo, embora não em profundidade.

+ +

A questão

+ +

If you're preparing to document something, you may be trying to decide whether to put the information on MDN Web Docs. In addition, you may be considering maintaining documentation in your source code, putting the document on the Mozilla wiki, or in readme files in a Git repository. This article's purpose is to help you decide which of these options is right for your content.

+ +

The two main considerations for whether a document belongs on MDN are:

+ + + +

Be aware that all contributions to MDN fall under specific open source licenses; these are described in detail on our About MDN page.

+ +
+

Nota: Keep in mind that Mozilla's Websites & Communications Terms of Use are in effect when you use or contribute to MDN Web Docs. Review this document to ensure that you're aware of what can and cannot be posted on Mozilla sites.

+
+ +

Que tópicos pertencem aos MDN Web Docs?

+ +

In general, if it's an open web-facing technology, we document it on MDN. This means any feature that can used by Web developers creating sites and applications now and in the near future. If it is implemented by multiple browsers and either accepted as standard or is progressing towards standardization, then yes, definitely. If it is still very experimental and not implemented in multiple browsers and/or liable to change, then it is still suitable for inclusion, but may not be seen as a priority for the writer's team to work on.

+ +

The primary focus is on front-end web technologies:

+ + + +
+

Nota: Back-end technologies usually have their own documentation elsewhere that MDN does not attempt to supercede, although we do have some exceptions.

+
+ +

Also welcome are topics that cut across technologies but are relevant to Web development, such as:

+ + + +
+

Nota: MDN covers some non-standard features if they're exposed to the Web, especially if they find common usage; for example, we have documentation for WebKit-specific CSS properties.

+
+ +

Que tópicos não pertencem aos MDN Web Docs?

+ +

In general, anything that isn't an open web standard does not belong on MDN. The below sections provide more specifics.

+ +

Produtos da Mozilla

+ +

Documentation in this category includes information on both how to work with Mozilla products, as a developer, and how to contribute to these open-source projects.

+ +

While MDN Web Docs contains a large quantity of Mozilla product documentation, the focus of new content development is on open web standards. We are in the process of determining what to do about this content, so it may not make sense to create new Mozilla product documentation on MDN Web Docs. If you are working on a Mozilla product (or project that may become a product), talk to a member of the MDN staff team to discuss possible avenues for documenting your product. Also, see the section on Cases for documenting elsewhere, below.

+ + + +

E que mais?

+ +

Other examples of inappropriate topics for MDN Web Docs:

+ + + +

Que tipos de documentos pertencem à 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:

+ + + +

Vantagens para documentar na 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.

+ +

Muitos escritores e tradutores

+ +

The MDN community is big. We have a lot of people that participate in creating and maintaining content on MDN. With writers and editors on every continent (okay, maybe not 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.

+ +

Manutenção

+ +

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 which keeps the site up, running, and secure, and a platform development team to maintain and enhance the platform on which the content is presented. You won't need to devote your own or additional resources to documentation infrastructure.
+
+ +

Casos para documentação em qualquer outra parte

+ +

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.

+ +

Planos e processos

+ +

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.

+ +

O projeto está no 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 writing and maintaining their own docs, or are working on code that has minimal documentation needs.

+ +

Quer manter os documentos na fonte

+ +

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/pt-pt/mdn/guidelines/guia_de_estilo_de_escrita/index.html b/files/pt-pt/mdn/guidelines/guia_de_estilo_de_escrita/index.html deleted file mode 100644 index fe96ad554e..0000000000 --- a/files/pt-pt/mdn/guidelines/guia_de_estilo_de_escrita/index.html +++ /dev/null @@ -1,667 +0,0 @@ ---- -title: Guia de estilo de escrita -slug: MDN/Guidelines/Guia_de_estilo_de_escrita -tags: - - Documentação - - Guia(2) - - Linhas Diretrizes - - MDN - - Metadados MDN -translation_of: MDN/Guidelines/Writing_style_guide ---- -
{{MDNSidebar}}
- -

To present documentation in an organized, standardized, and easy-to-read manner, the MDN Web Docs style guide describes how text should be organized, spelled, formatted, and so on. These are guidelines rather than strict rules. We are more interested in content than formatting, so don't feel obligated to learn the style guide before contributing. Do not be upset or surprised, however, if an industrious volunteer later edits your work to conform to this guide.

- -

If you're looking for specifics of how a given type of page should be structured, see the MDN page layout guide.

- -

The language aspects of this guide apply primarily to English-language documentation. Other languages may have (and are welcome to create) style guides. These should be published as subpages of the localization team's page.

- -

For style standards that apply to content written for sites other than MDN, refer to the One Mozilla style guide.

- -

Básico

- -

The best place to start in any extensive publishing style guide is with some very basic text standards to help keep documentation consistent. The following sections outline some of these basics to help you.

- -

Page titles

- -

Page titles are used in search results and also used to structure the page hierarchy in the breadcrumb list at the top of the page. The page title (which is displayed at the top of the page and in the search results) can be different from the page "slug", which is the portion of the page's URL following "<locale>/docs/".

- -

Title and heading capitalization

- -

Page titles and section headings should use sentence-style capitalization (only capitalize the first word and proper nouns) rather than headline-style capitalization:

- - - -

We have many older pages that were written before this style rule was established. Feel free to update them as needed if you like. We're gradually getting to them.

- -

Choosing titles and slugs

- -

Page slugs should be kept short; when creating a new level of hierarchy, the new level's component in the slug should just be a word or two.

- -

Page titles, on the other hand, may be as long as you like, within reason, and they should be descriptive.

- -

Creating new subtrees

- -

When you need to add some articles about a topic or subject area, you will typically do so by creating a landing page, then adding subpages for each of the individual articles. The landing page should open with a paragraph or two describing the topic or technology, then provide a list of the subpages with descriptions of each page. You can automate the insertion of pages into the list using some macros we've created.

- -

For example, consider the JavaScript guide, which is structured as follows:

- - - -

Try to avoid putting your article at the top of the hierarchy, which slows the site down and makes search and site navigation less effective.

- -

Sections, paragraphs, and newlines

- -

Use heading levels in decreasing order: {{HTMLElement("h2")}} then {{HTMLElement("h3")}} then {{HTMLElement("h4")}}, without skipping levels. H2 is the highest level allowed because H1 is reserved for the page title. If you need more than three or four levels of headers you should consider breaking up the article into several smaller articles with a landing page, linking them together using the {{TemplateLink("Next")}}, {{TemplateLink("Previous")}}, and {{TemplateLink("PreviousNext")}} macros.

- -

The Enter (or Return) key on your keyboard starts a new paragraph. To insert a newline without a space, hold down the Shift key while pressing Enter.

- -

Don't create single subsections -- you don't subdivide a topic into one. It's either two subheadings or more or none at all. 

- -

Don't have bumping heads, which are headings followed immediately by headings. Aside from looking horrible, it's helpful to readers if every heading has at least a brief intro after it to introduce the subsections beneath.

- -

Listas

- -

Lists should be written in a similar format across all contributions. Correct procedures should include suitable punctuation and sentence structure regardless of the list format. However dependent on the type of list you are writing, you must adjust your format accordingly. Refer to the documentation below to understand the differences of each.

- -

Bulleted Lists

- -

Bulleted lists should be used for grouping purposes to create concise but effective pieces of information. Each new piece of information must start with a '•' to signify a new piece. Bulleted lists must follow standard punctuation usage, pay attention to the use of full stops; they must be included at the end of each sentence just like standard writing practice.

- -

An example of a correctly structured bulleted list:

- -
-

In this example we should include:

- - -
- -

Note how the format remains the same from bullet to bullet. Create a bullet point, state a condition that has relevence to your indented topic and add some pausing punctuation in order to follow up the condition with a concise explanation.

- -

Listas Numeradas

- -

Instruction lists must follow suitable numbering and format. It is important to include these attributes as with instructions, being clear is a key priority. Create the list in a similar style to a bulleted list, however numbered or instruction lists can be extensive where necessary, meaning correct punctuation is vital as you will be forming complex sentences.

- -

An example of a correctly structured numbered list:

- -
-

In order for you to structure a correct numbered list you must:

- -

1. Begin with creating an introductory heading to lead into the instructions. This way we can provide the user with context before beginning the instructions.

- -

2. Start creating your instructions, listing your instructions with numbers. This is a standard format of a numbered list that is easily recognizable by the user. Your instructions may be quite extensive, so it is important to write effectively and use correct punctuation where necessary.

- -

3. After you have finished your instructions, close off the numbered list with a brief explanation of the outcome upon completion.

- -

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

-
- -

Numbered lists are almost exclusive for instructive purposes, so before writing consider your approach based on the context of the information you are trying to relay.  

- -

Formatação e estilo do texto

- -

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

- -
The "Note" style is used to call out important notes, like this one.
- -
Similarly, the "Warning" style creates warning boxes like this.
- -

Unless specifically instructed to do so, do not use the HTML style attribute to manually style content. If you can't do it using a predefined class, drop into {{IRCLink("mdn")}} and ask for help.

- -

Code sample style and formatting

- -

Tabs and line breaks

- -

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

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

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

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

Inline code formatting

- -

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

- -

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

- -

Syntax highlighting

- -

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

- -

The following example shows text with JavaScript formatting:

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

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

- -
x = 42;
- -

Syntax definitions

- -

If you want to insert a syntax definition, you can choose the "Syntax Box" option from the "Styles" drop-down menu in the editor toolbar. This will give the syntax definition a special formatting distinguishing it from normal code.

- -

Blocks not referring to code

- -

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

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

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

- -

Styling HTML element references

- -

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

- -
-
Element names
-
Use the {{TemplateLink("HTMLElement")}} macro, which creates a link to the page for that element. For example, writing \{{HTMLElement("title")}} produces "{{HTMLElement("title")}}". If you don't want to create a link, enclose the name in angle brackets and use "Code (inline)" style (e.g., <title>).
-
Attribute names
-
Use bold face.
-
Attribute definitions
-
Use the {{TemplateLink("htmlattrdef")}} macro (e.g., \{{htmlattrdef("type")}}) for the definition term, so that it can be linked to from other pages, then use the {{TemplateLink("htmlattrxref")}} macro (e.g., \{{htmlattrxref("attr","element")}}) to reference attribute definitions.
-
Attribute values
-
Use "Code (inline)" style, and do not use quotation marks around strings, unless needed by the syntax of a code sample. For example: When the type attribute of an <input> element is set to email or tel ...
-
Labeling attributes
-
Use labels like {{HTMLVersionInline(5)}} thoughtfully. For example, use them next to the bold attribute name but not for every occurrence in your body text.
-
- -

Latin abbreviations

- -

In notes and parentheses

- - - -

In running text

- - - -

Meanings and English equivalents of Latin abbreviations

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

Always consider whether it's truly beneficial to use a Latin abbreviation. Some of these are used so rarely that many readers won't understand the meaning, and others are often confused with one another. And be sure that you use them correctly, if you choose to do so. For example, be careful not to confuse "e.g." with "i.e.", which is a common error.

-
- -

Acronyms and abbreviations

- -

Capitalization and periods

- -

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

- - - -

Expansion

- -

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

- - - -

Plurals of acronyms and abbreviations

- -

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

- - - -

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

- -

The contraction "vs." is preferred.

- - - -

Capitalização

- -

Use standard English capitalization rules in body text, and capitalize "World Wide Web." It is acceptable to use lower case for "web" (used alone or as a modifier) and "internet;" this guideline is a change from a previous version of this guide, so you may find many instances of "Web" and "Internet" on MDN.  Feel free to change these as you are making other changes, but editing an article just to change capitalization is not necessary.

- -

Keyboard keys should use sentence-style capitalization, not all-caps capitalization. For example, "Enter" not "ENTER."

- -

Contrações

- -

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

- -

Pluralização

- -

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

- - - -

Hifenização

- -

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

- - - -

Idioma de género neutral

- -

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

- -
-

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

-
- -
-

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

-
- -

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

- -
-

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

-
- -
-

MDN allows the use of this very common syntax (which is controversial among usage authorities), to make up for the lack of a neutral gender in English. The use of the third-person plural as a gender neutral pronoun (that is, using "they," them", "their," and "theirs") is an accepted practice, commonly known as "singular 'they.'"

-
- -

You can use both genders:

- -
-

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

-
- -

making the users plural:

- -
-

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

-
- -

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

- -
-

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

-
- -
-

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

-
- -

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

- -

Numbers and numerals

- -

Dates

- -

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

- - - -

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

- - - -

Decades

- -

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

- - - -

Plurals of numerals

- -

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

- - - -

Commas

- -

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

- - - -

Punctuation

- -

Serial comma

- -

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

- - - -
-

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

-
- -

Ortografia

- -

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

- - - -

Terminologia

- -

Obsolete vs. deprecated

- -

It's important to be clear about the difference between the terms obsolete and deprecated.

- -
-
Obsolete
-
On MDN, the term obsolete marks an API or technology that is not only no longer recommended, but also no longer implemented in the browser. For Mozilla-specific technologies, the API is no longer implemented in Mozilla code; for Web standard technology, the API or feature is no longer supported by current, commonly-used browsers.
-
Deprecated
-
On MDN, the term deprecated marks an API or technology that is no longer recommended, but is still implemented and may still work. These technologies will in theory eventually become obsolete and be removed, so you should stop using them. For Mozilla-specific technologies, the API is still supported in Mozilla code; for Web standard technology, the API or feature has been removed or replaced in a recent version of the defining standard.
-
- -

Elementos de HTML

- -

Use "elements" to refer to HTML and XML elements, rather than "tags". In addition, they should almost always be wrapped in "<>", and should be in the {{HTMLElement("code")}} style. When you reference a given element for the first time in a section, you should use the {{TemplateLink("HTMLElement")}} macro to create a link to the documentation for the element (unless you're writing within that element's reference document page).

- - - -

Parameters vs. arguments

- -

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

- -

User interface actions

- -

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

- - - -

Voice

- -

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

- -

Wiki markup and usage

- -

Hiperligações

- -

Links are a large part of what makes a wiki a powerful learning and teaching tool. Below you'll find some basic information, but you can find a complete guide to creating and editing links on MDN in our editor guide.

- -

We encourage you to create appropriate links among articles; they help improve navigation and discoverability of content. You can easily create links not only among pages on MDN (internal links) but also to pages outside MDN (external links).

- -

There are two ways to create links: you explicitly create a link using the Link button in the editor's toolbar—or by pressing Ctrl+K (Cmd-K on the Mac)—or you can use MDN's powerful macro system to generate links automatically or based on an input value.

- -

When deciding what text to use as a link, there are a few guidelines you can follow:

- - - -

Esquemas de URL

- -

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

- - - -

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

- -
-

In particular, be sure not to use the about: or chrome:// schemes, as they will not work. Similarly, the javascript: scheme is blocked by most modern browsers, as is jar:.

-
- -

Etiquetas de página

- -

Tags provide meta information about a page and/or indicate that a page has specific improvements needed to its content. Every page in the wiki should have tags. You can find details on tagging in our How to properly tag pages guide.

- -

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

- -

Screenshot of the UX for adding and removing tags on MDN

- -

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

- -

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

- -

Tagging pages that need work

- -

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

- -

Tagging obsolete pages

- -

Use the following tags for pages that are not current:

- - - -

Resumo SEO

- -

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

- -

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

- -

Landing pages

- -

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

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

Creating a page link list

- -

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

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

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

- -

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

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

<<<finish this once we finalize the landing page standards>>>

- -

Utilização, inserção de imagens

- -

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

- -
    -
  1. Attach the desired image file to the article (at the bottom of every article in edit mode)
    2. -
  2. Create an image in the WYSIWYG editor
    3. -
  3. In the WYSIWYG editor, in the drop-down list of attachments, select the newly created attachment that is your image
    4. -
  4. Press OK.
    5. -
- -

Outras referências

- -

Preferred style guides

- -

If you have questions about usage and style not covered here, we recommend referring to the Economist style guide or, failing that, the Chicago Manual of Style.

- -

Preferred dictionary

- -

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

- -

We will be expanding the guide over time, so if you have specific questions that aren't covered in this document, please send them to the MDC mailing list or project lead so we know what should be added.

- -

Específico da MDN

- - - -

Idioma, gramática, ortografia

- -

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

- - diff --git a/files/pt-pt/mdn/guidelines/isto_pertence_a_mdn/index.html b/files/pt-pt/mdn/guidelines/isto_pertence_a_mdn/index.html deleted file mode 100644 index 429ffa389f..0000000000 --- a/files/pt-pt/mdn/guidelines/isto_pertence_a_mdn/index.html +++ /dev/null @@ -1,200 +0,0 @@ ---- -title: Isto pertence aos MDN Web Docs? -slug: MDN/Guidelines/Isto_pertence_a_MDN -tags: - - Guía - - Linhas Diretrizes - - Metadados MDN -translation_of: MDN/Guidelines/Does_this_belong_on_MDN ---- -
{{MDNSidebar}}
- -
{{IncludeSubnav("/pt-PT/docs/MDN")}}
- -

Neste artigo, irá encontrar informação a descrever como decidir se determinado tópico e/ ou tipo de conteúdo deverá ou não ser incluído na MDN Web Docs. Nós também iremos considerar outros lugares em que pode colocar o conteúdo, embora não em profundidade.

- -

A questão

- -

If you're preparing to document something, you may be trying to decide whether to put the information on MDN Web Docs. In addition, you may be considering maintaining documentation in your source code, putting the document on the Mozilla wiki, or in readme files in a Git repository. This article's purpose is to help you decide which of these options is right for your content.

- -

The two main considerations for whether a document belongs on MDN are:

- - - -

Be aware that all contributions to MDN fall under specific open source licenses; these are described in detail on our About MDN page.

- -
-

Nota: Keep in mind that Mozilla's Websites & Communications Terms of Use are in effect when you use or contribute to MDN Web Docs. Review this document to ensure that you're aware of what can and cannot be posted on Mozilla sites.

-
- -

Que tópicos pertencem aos MDN Web Docs?

- -

In general, if it's an open web-facing technology, we document it on MDN. This means any feature that can used by Web developers creating sites and applications now and in the near future. If it is implemented by multiple browsers and either accepted as standard or is progressing towards standardization, then yes, definitely. If it is still very experimental and not implemented in multiple browsers and/or liable to change, then it is still suitable for inclusion, but may not be seen as a priority for the writer's team to work on.

- -

The primary focus is on front-end web technologies:

- - - -
-

Nota: Back-end technologies usually have their own documentation elsewhere that MDN does not attempt to supercede, although we do have some exceptions.

-
- -

Also welcome are topics that cut across technologies but are relevant to Web development, such as:

- - - -
-

Nota: MDN covers some non-standard features if they're exposed to the Web, especially if they find common usage; for example, we have documentation for WebKit-specific CSS properties.

-
- -

Que tópicos não pertencem aos MDN Web Docs?

- -

In general, anything that isn't an open web standard does not belong on MDN. The below sections provide more specifics.

- -

Produtos da Mozilla

- -

Documentation in this category includes information on both how to work with Mozilla products, as a developer, and how to contribute to these open-source projects.

- -

While MDN Web Docs contains a large quantity of Mozilla product documentation, the focus of new content development is on open web standards. We are in the process of determining what to do about this content, so it may not make sense to create new Mozilla product documentation on MDN Web Docs. If you are working on a Mozilla product (or project that may become a product), talk to a member of the MDN staff team to discuss possible avenues for documenting your product. Also, see the section on Cases for documenting elsewhere, below.

- - - -

E que mais?

- -

Other examples of inappropriate topics for MDN Web Docs:

- - - -

Que tipos de documentos pertencem à 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:

- - - -

Vantagens para documentar na 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.

- -

Muitos escritores e tradutores

- -

The MDN community is big. We have a lot of people that participate in creating and maintaining content on MDN. With writers and editors on every continent (okay, maybe not 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.

- -

Manutenção

- -

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 which keeps the site up, running, and secure, and a platform development team to maintain and enhance the platform on which the content is presented. You won't need to devote your own or additional resources to documentation infrastructure.
-
- -

Casos para documentação em qualquer outra parte

- -

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.

- -

Planos e processos

- -

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.

- -

O projeto está no 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 writing and maintaining their own docs, or are working on code that has minimal documentation needs.

- -

Quer manter os documentos na fonte

- -

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/pt-pt/mdn/guidelines/writing_style_guide/index.html b/files/pt-pt/mdn/guidelines/writing_style_guide/index.html new file mode 100644 index 0000000000..fe96ad554e --- /dev/null +++ b/files/pt-pt/mdn/guidelines/writing_style_guide/index.html @@ -0,0 +1,667 @@ +--- +title: Guia de estilo de escrita +slug: MDN/Guidelines/Guia_de_estilo_de_escrita +tags: + - Documentação + - Guia(2) + - Linhas Diretrizes + - MDN + - Metadados MDN +translation_of: MDN/Guidelines/Writing_style_guide +--- +
{{MDNSidebar}}
+ +

To present documentation in an organized, standardized, and easy-to-read manner, the MDN Web Docs style guide describes how text should be organized, spelled, formatted, and so on. These are guidelines rather than strict rules. We are more interested in content than formatting, so don't feel obligated to learn the style guide before contributing. Do not be upset or surprised, however, if an industrious volunteer later edits your work to conform to this guide.

+ +

If you're looking for specifics of how a given type of page should be structured, see the MDN page layout guide.

+ +

The language aspects of this guide apply primarily to English-language documentation. Other languages may have (and are welcome to create) style guides. These should be published as subpages of the localization team's page.

+ +

For style standards that apply to content written for sites other than MDN, refer to the One Mozilla style guide.

+ +

Básico

+ +

The best place to start in any extensive publishing style guide is with some very basic text standards to help keep documentation consistent. The following sections outline some of these basics to help you.

+ +

Page titles

+ +

Page titles are used in search results and also used to structure the page hierarchy in the breadcrumb list at the top of the page. The page title (which is displayed at the top of the page and in the search results) can be different from the page "slug", which is the portion of the page's URL following "<locale>/docs/".

+ +

Title and heading capitalization

+ +

Page titles and section headings should use sentence-style capitalization (only capitalize the first word and proper nouns) rather than headline-style capitalization:

+ + + +

We have many older pages that were written before this style rule was established. Feel free to update them as needed if you like. We're gradually getting to them.

+ +

Choosing titles and slugs

+ +

Page slugs should be kept short; when creating a new level of hierarchy, the new level's component in the slug should just be a word or two.

+ +

Page titles, on the other hand, may be as long as you like, within reason, and they should be descriptive.

+ +

Creating new subtrees

+ +

When you need to add some articles about a topic or subject area, you will typically do so by creating a landing page, then adding subpages for each of the individual articles. The landing page should open with a paragraph or two describing the topic or technology, then provide a list of the subpages with descriptions of each page. You can automate the insertion of pages into the list using some macros we've created.

+ +

For example, consider the JavaScript guide, which is structured as follows:

+ + + +

Try to avoid putting your article at the top of the hierarchy, which slows the site down and makes search and site navigation less effective.

+ +

Sections, paragraphs, and newlines

+ +

Use heading levels in decreasing order: {{HTMLElement("h2")}} then {{HTMLElement("h3")}} then {{HTMLElement("h4")}}, without skipping levels. H2 is the highest level allowed because H1 is reserved for the page title. If you need more than three or four levels of headers you should consider breaking up the article into several smaller articles with a landing page, linking them together using the {{TemplateLink("Next")}}, {{TemplateLink("Previous")}}, and {{TemplateLink("PreviousNext")}} macros.

+ +

The Enter (or Return) key on your keyboard starts a new paragraph. To insert a newline without a space, hold down the Shift key while pressing Enter.

+ +

Don't create single subsections -- you don't subdivide a topic into one. It's either two subheadings or more or none at all. 

+ +

Don't have bumping heads, which are headings followed immediately by headings. Aside from looking horrible, it's helpful to readers if every heading has at least a brief intro after it to introduce the subsections beneath.

+ +

Listas

+ +

Lists should be written in a similar format across all contributions. Correct procedures should include suitable punctuation and sentence structure regardless of the list format. However dependent on the type of list you are writing, you must adjust your format accordingly. Refer to the documentation below to understand the differences of each.

+ +

Bulleted Lists

+ +

Bulleted lists should be used for grouping purposes to create concise but effective pieces of information. Each new piece of information must start with a '•' to signify a new piece. Bulleted lists must follow standard punctuation usage, pay attention to the use of full stops; they must be included at the end of each sentence just like standard writing practice.

+ +

An example of a correctly structured bulleted list:

+ +
+

In this example we should include:

+ + +
+ +

Note how the format remains the same from bullet to bullet. Create a bullet point, state a condition that has relevence to your indented topic and add some pausing punctuation in order to follow up the condition with a concise explanation.

+ +

Listas Numeradas

+ +

Instruction lists must follow suitable numbering and format. It is important to include these attributes as with instructions, being clear is a key priority. Create the list in a similar style to a bulleted list, however numbered or instruction lists can be extensive where necessary, meaning correct punctuation is vital as you will be forming complex sentences.

+ +

An example of a correctly structured numbered list:

+ +
+

In order for you to structure a correct numbered list you must:

+ +

1. Begin with creating an introductory heading to lead into the instructions. This way we can provide the user with context before beginning the instructions.

+ +

2. Start creating your instructions, listing your instructions with numbers. This is a standard format of a numbered list that is easily recognizable by the user. Your instructions may be quite extensive, so it is important to write effectively and use correct punctuation where necessary.

+ +

3. After you have finished your instructions, close off the numbered list with a brief explanation of the outcome upon completion.

+ +

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

+
+ +

Numbered lists are almost exclusive for instructive purposes, so before writing consider your approach based on the context of the information you are trying to relay.  

+ +

Formatação e estilo do texto

+ +

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

+ +
The "Note" style is used to call out important notes, like this one.
+ +
Similarly, the "Warning" style creates warning boxes like this.
+ +

Unless specifically instructed to do so, do not use the HTML style attribute to manually style content. If you can't do it using a predefined class, drop into {{IRCLink("mdn")}} and ask for help.

+ +

Code sample style and formatting

+ +

Tabs and line breaks

+ +

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

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

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

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

Inline code formatting

+ +

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

+ +

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

+ +

Syntax highlighting

+ +

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

+ +

The following example shows text with JavaScript formatting:

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

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

+ +
x = 42;
+ +

Syntax definitions

+ +

If you want to insert a syntax definition, you can choose the "Syntax Box" option from the "Styles" drop-down menu in the editor toolbar. This will give the syntax definition a special formatting distinguishing it from normal code.

+ +

Blocks not referring to code

+ +

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

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

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

+ +

Styling HTML element references

+ +

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

+ +
+
Element names
+
Use the {{TemplateLink("HTMLElement")}} macro, which creates a link to the page for that element. For example, writing \{{HTMLElement("title")}} produces "{{HTMLElement("title")}}". If you don't want to create a link, enclose the name in angle brackets and use "Code (inline)" style (e.g., <title>).
+
Attribute names
+
Use bold face.
+
Attribute definitions
+
Use the {{TemplateLink("htmlattrdef")}} macro (e.g., \{{htmlattrdef("type")}}) for the definition term, so that it can be linked to from other pages, then use the {{TemplateLink("htmlattrxref")}} macro (e.g., \{{htmlattrxref("attr","element")}}) to reference attribute definitions.
+
Attribute values
+
Use "Code (inline)" style, and do not use quotation marks around strings, unless needed by the syntax of a code sample. For example: When the type attribute of an <input> element is set to email or tel ...
+
Labeling attributes
+
Use labels like {{HTMLVersionInline(5)}} thoughtfully. For example, use them next to the bold attribute name but not for every occurrence in your body text.
+
+ +

Latin abbreviations

+ +

In notes and parentheses

+ + + +

In running text

+ + + +

Meanings and English equivalents of Latin abbreviations

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

Always consider whether it's truly beneficial to use a Latin abbreviation. Some of these are used so rarely that many readers won't understand the meaning, and others are often confused with one another. And be sure that you use them correctly, if you choose to do so. For example, be careful not to confuse "e.g." with "i.e.", which is a common error.

+
+ +

Acronyms and abbreviations

+ +

Capitalization and periods

+ +

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

+ + + +

Expansion

+ +

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

+ + + +

Plurals of acronyms and abbreviations

+ +

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

+ + + +

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

+ +

The contraction "vs." is preferred.

+ + + +

Capitalização

+ +

Use standard English capitalization rules in body text, and capitalize "World Wide Web." It is acceptable to use lower case for "web" (used alone or as a modifier) and "internet;" this guideline is a change from a previous version of this guide, so you may find many instances of "Web" and "Internet" on MDN.  Feel free to change these as you are making other changes, but editing an article just to change capitalization is not necessary.

+ +

Keyboard keys should use sentence-style capitalization, not all-caps capitalization. For example, "Enter" not "ENTER."

+ +

Contrações

+ +

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

+ +

Pluralização

+ +

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

+ + + +

Hifenização

+ +

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

+ + + +

Idioma de género neutral

+ +

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

+ +
+

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

+
+ +
+

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

+
+ +

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

+ +
+

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

+
+ +
+

MDN allows the use of this very common syntax (which is controversial among usage authorities), to make up for the lack of a neutral gender in English. The use of the third-person plural as a gender neutral pronoun (that is, using "they," them", "their," and "theirs") is an accepted practice, commonly known as "singular 'they.'"

+
+ +

You can use both genders:

+ +
+

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

+
+ +

making the users plural:

+ +
+

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

+
+ +

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

+ +
+

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

+
+ +
+

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

+
+ +

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

+ +

Numbers and numerals

+ +

Dates

+ +

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

+ + + +

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

+ + + +

Decades

+ +

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

+ + + +

Plurals of numerals

+ +

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

+ + + +

Commas

+ +

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

+ + + +

Punctuation

+ +

Serial comma

+ +

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

+ + + +
+

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

+
+ +

Ortografia

+ +

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

+ + + +

Terminologia

+ +

Obsolete vs. deprecated

+ +

It's important to be clear about the difference between the terms obsolete and deprecated.

+ +
+
Obsolete
+
On MDN, the term obsolete marks an API or technology that is not only no longer recommended, but also no longer implemented in the browser. For Mozilla-specific technologies, the API is no longer implemented in Mozilla code; for Web standard technology, the API or feature is no longer supported by current, commonly-used browsers.
+
Deprecated
+
On MDN, the term deprecated marks an API or technology that is no longer recommended, but is still implemented and may still work. These technologies will in theory eventually become obsolete and be removed, so you should stop using them. For Mozilla-specific technologies, the API is still supported in Mozilla code; for Web standard technology, the API or feature has been removed or replaced in a recent version of the defining standard.
+
+ +

Elementos de HTML

+ +

Use "elements" to refer to HTML and XML elements, rather than "tags". In addition, they should almost always be wrapped in "<>", and should be in the {{HTMLElement("code")}} style. When you reference a given element for the first time in a section, you should use the {{TemplateLink("HTMLElement")}} macro to create a link to the documentation for the element (unless you're writing within that element's reference document page).

+ + + +

Parameters vs. arguments

+ +

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

+ +

User interface actions

+ +

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

+ + + +

Voice

+ +

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

+ +

Wiki markup and usage

+ +

Hiperligações

+ +

Links are a large part of what makes a wiki a powerful learning and teaching tool. Below you'll find some basic information, but you can find a complete guide to creating and editing links on MDN in our editor guide.

+ +

We encourage you to create appropriate links among articles; they help improve navigation and discoverability of content. You can easily create links not only among pages on MDN (internal links) but also to pages outside MDN (external links).

+ +

There are two ways to create links: you explicitly create a link using the Link button in the editor's toolbar—or by pressing Ctrl+K (Cmd-K on the Mac)—or you can use MDN's powerful macro system to generate links automatically or based on an input value.

+ +

When deciding what text to use as a link, there are a few guidelines you can follow:

+ + + +

Esquemas de URL

+ +

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

+ + + +

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

+ +
+

In particular, be sure not to use the about: or chrome:// schemes, as they will not work. Similarly, the javascript: scheme is blocked by most modern browsers, as is jar:.

+
+ +

Etiquetas de página

+ +

Tags provide meta information about a page and/or indicate that a page has specific improvements needed to its content. Every page in the wiki should have tags. You can find details on tagging in our How to properly tag pages guide.

+ +

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

+ +

Screenshot of the UX for adding and removing tags on MDN

+ +

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

+ +

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

+ +

Tagging pages that need work

+ +

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

+ +

Tagging obsolete pages

+ +

Use the following tags for pages that are not current:

+ + + +

Resumo SEO

+ +

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

+ +

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

+ +

Landing pages

+ +

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

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

Creating a page link list

+ +

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

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

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

+ +

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

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

<<<finish this once we finalize the landing page standards>>>

+ +

Utilização, inserção de imagens

+ +

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

+ +
    +
  1. Attach the desired image file to the article (at the bottom of every article in edit mode)
    2. +
  2. Create an image in the WYSIWYG editor
    3. +
  3. In the WYSIWYG editor, in the drop-down list of attachments, select the newly created attachment that is your image
    4. +
  4. Press OK.
    5. +
+ +

Outras referências

+ +

Preferred style guides

+ +

If you have questions about usage and style not covered here, we recommend referring to the Economist style guide or, failing that, the Chicago Manual of Style.

+ +

Preferred dictionary

+ +

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

+ +

We will be expanding the guide over time, so if you have specific questions that aren't covered in this document, please send them to the MDC mailing list or project lead so we know what should be added.

+ +

Específico da MDN

+ + + +

Idioma, gramática, ortografia

+ +

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

+ + diff --git a/files/pt-pt/mdn/kuma/index.html b/files/pt-pt/mdn/kuma/index.html deleted file mode 100644 index 3ffc29d8b6..0000000000 --- a/files/pt-pt/mdn/kuma/index.html +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: 'Kuma: Plataforma wiki da MDN' -slug: MDN/Kuma -tags: - - Kuma - - MDN Meta - - Metadados MDN -translation_of: MDN/Kuma ---- -
{{MDNSidebar}}{{IncludeSubnav("/pt-PT/docs/MDN")}}
- -

Kuma é o código Django que é utilizado para os 'Documentos da Web na MDN'.

- -

{{SubpagesWithSummaries}}

- -

Participe na plataforma Kuma

- -

Para participar na plataforma Kuma:

- - diff --git a/files/pt-pt/mdn/sobre/index.html b/files/pt-pt/mdn/sobre/index.html deleted file mode 100644 index 1da67e04e5..0000000000 --- a/files/pt-pt/mdn/sobre/index.html +++ /dev/null @@ -1,127 +0,0 @@ ---- -title: Sobre a MDN -slug: MDN/Sobre -tags: - - Colaboração - - Comunidade - - Direitos de Autor - - Documentação - - Guía - - Licenças - - Metadados da MDN -translation_of: MDN/About ---- -
{{MDNSidebar}}
- -
{{IncludeSubnav("/pt-PT/docs/MDN")}}
- -

MDN Web Docs é uma plataforma de aprendizagem em evolução para as tecnologias da Web e software que energiza a Web, incluindo:

- - - -

A nossa missão

- - - -

A missão da MDN é simples: proporcionar aos programadores a informação que eles precisam para criarem facilmente projetos na Web aberta. Se é uma tecnologia aberta exposta à Web, nós queremos documentá-la.

- -

Além disso, nós proporcionamos documentação sobre os produtos Mozilla e como criar e contribuir para os projetos da Mozilla.

- -

Se não tiver a certeza se um tópico em particular deve ser abrangido na MDN, leia: Isso pertence ao MDN?

- - - -

Como é que pode ajudar

- - - -

Não precisa de ser capaz de programar - ou escrever bem - para poder ajudar a MDN! Nós temos muitas maneiras em que pode ajudar, desde rever artigos para ter a certeza de que fazem sentido, para contribuir com texto, para adicionar código de exemplo. De facto, existem muitas maneiras de ajudar que nós temos uma página de Primeiros Passos que o ajuda a escolher as tarefas para fazer, com base nos seus interesses e quanto tempo é que tem para contribuir!

- -

Também pode ajudar a promover a MDN no seu próprio blogue ou site da Web.

- - - -

A comunidade da MDN

- -

Nossa comunidade é global! Temos colaboradores incríveis em todo o mundo, em vários idiomas. Se você quiser saber mais sobre nós, ou se precisar de ajuda de qualquer tipo com o MDN, fique à vontade para visitar nosso fórum de discussão ou canal de IRC! Você também pode acompanhar o que estamos fazendo seguindo nossa conta no Twitter, @MozDevNet. Você também pode enviar tweets para nós, se você vir algo errado ou se você gostaria de oferecer feedback (ou quiser nos agradecer) aos nossos escritores e colaboradores!

- -

Utilizar conteúdo da MDN Web Docs

- -

O conteúdo da MDN está disponível gratuitamente, e sob as licenças de código aberto.

- -

Direitos de Autor e Licenças

- -

O conteúdo da MDN está totalmente disponível sob várias licenças de código aberto. Esta secção cobre os tipos de conteúdo que nós proporcionamos e quais as licenças em vigor para cada.

- -

Documentação e artigos

- -

MDN wiki documents have been prepared with the contributions of many authors, both within and outside the Mozilla Foundation. Unless otherwise indicated, the content is available under the terms of the Creative Commons Attribution-ShareAlike license (CC-BY-SA), v2.5 or any later version. Please attribute "Mozilla Contributors" and include a hyperlink (online) or URL (in print) to the specific wiki page for the content being sourced. For example, to provide attribution for this article, you can write:

- -
Sobre a MDN, pelos Colaboradores da Mozilla (inglês) está licenciado sob CC-BY-SA 2.5.
- -

Note that in the example, "Mozilla Contributors" links to the history of the cited page. See Best practices for attribution (EN) for further explanation.

- -
-

Nota: consulte o conteúdo da MDN em WebPlatform.org para informação sobre como reutilizar e atribuir conteúdo MDN nesse site.

-
- -

Code samples and snippets

- -

Code samples added to this wiki before August 20, 2010 are available under the MIT license; you should insert the following attribution information into the MIT template: "© <date of last wiki page revision> <name of person who put it in the wiki>".

- -

Code samples added on or after August 20, 2010 are in the public domain. No licensing notice is necessary, but if you need one, you can use: "Any copyright is dedicated to the Public Domain. http://creativecommons.org/publicdomain/zero/1.0/".

- -

Contribuições

- -

If you wish to contribute to this wiki, you must make your documentation available under the Attribution-ShareAlike license (or occasionally an alternative license already specified by the page you are editing), and your code samples available under Creative Commons CC-0 (a Public Domain dedication). Adding to this wiki means you agree that your contributions will be made available under those licenses.

- -

Some older content was made available under a license other than the licenses noted above; these are indicated at the bottom of each page by way of an Alternate License Block.

- -
-

Não podem ser criadas novas páginas utilizando licenças alternativas.

-
- -

Os direitos de autor para os materiais contribuídos permanecem com o autor, a menos que o mesmo o atribua a outra pessoa.

- -

Se tiver quaisquer questões relacionadas ou problemas sobre qualquer coisa aqui discutida, por favor, contacte Eric Shepherd.

- -

Logótipo, marcas registadas, marcas de serviço e wordmarks

- -
-

The rights in the trademarks, logos, service marks of the Mozilla Foundation, as well as the look and feel of this web site, are not licensed under the Creative Commons license, and to the extent they are works of authorship (like logos and graphic design), they are not included in the work that is licensed under those terms. If you use the text of documents, and wish to also use any of these rights, or if you have any other questions about complying with our licensing terms for this collection, you should contact the Mozilla Foundation here: licensing@mozilla.org.

- -

Interligação com a MDN

- -

See this article for guidance on linking to MDN for best practices when linking.

- -

Transferência de conteúdo

- -

Pode transferir um tarball mirror completo da MDN. (2.1GB, em fevereiro de 2017)

- -

Páginas únicas

- -

You can retrieve the content of a single page on MDN by adding document parameters to the URL to specify what format you want.

- -

Ferramentas de terceiros

- -

You can view MDN content via third-party tools like Dash (for Mac OS) and Zeal (for Linux and Windows).

- -

Kapeli also publishes offline MDN docs covering HTML, CSS, JavaScript, SVG, and XSLT.

- -

Comunicação de problemas com MDN Web Docs

- -

Consultar "Como comunicar um problema na MDN".

- -

Histórico da MDN Web Docs

- -

MDN Web Docs (anteriormente Mozilla Developer Network (MDN), anteriormente projeto da Mozilla Developer Center (MDC), a.k.a. Devmo) começou no início de 2005, quando a Fundação Mozilla (inglês) obteve a licença da AOL para utilizar o conteúdo DevEdge original do Netscape. O conteúdo DevEdge foi minado para o material ainda útil, que foi migrado por voluntários para esta wiki, e assim esta seria mais fácil para atualizar e manter.

- -

Pode encontrar mais história da MDN na nossa página de celebração do 10º. aniversário, incluindo uma história verbal por algumas das pessoas que estiverem envolvidas.

- -

Sobre a Mozilla

- -

Se quer saber mais sobre quem somos, como fazer parte da Mozilla ou apenas onde nos encontrar, veio ao lugar certo. Para descobrir o que nos impulsiona e nos torna diferentes, visite a nossa página da missão.

diff --git a/files/pt-pt/mdn/structures/api_references/barras_laterais_de_referencia_da_api/index.html b/files/pt-pt/mdn/structures/api_references/barras_laterais_de_referencia_da_api/index.html deleted file mode 100644 index 8e28e33556..0000000000 --- a/files/pt-pt/mdn/structures/api_references/barras_laterais_de_referencia_da_api/index.html +++ /dev/null @@ -1,109 +0,0 @@ ---- -title: Barras laterais de referência da API -slug: MDN/Structures/API_references/Barras_laterais_de_referencia_da_API -tags: - - API - - Guía - - Referencia - - barras laterais - - groupdata - - onboarding -translation_of: MDN/Structures/API_references/API_reference_sidebars ---- -
{{MDNSidebar}}

Pode incluir uma barra lateral personalizada nas páginas de referência da API para exibir as hiperligações para as 'Interfaces' relacionadas, tutoriais, e outros recursos relevantes, apenas para essa API. Este artigo explica como.

- -

O que precisa de fazer?

- -

You need to take the following three steps to create your API sidebar:

- -
    -
  1. Create your API reference pages.
    2. -
  2. Add an entry for your particular API into the KumaScript repo's GroupData.json data file.
    3. -
  3. Use the \{{APIRef}} macro to insert the sidebar into each page you want to display it on.
    4. -
- -

Let's run through each of these steps in turn. The example we'll refer to in this article is the Fetch API.

- -

Criar páginas de referência da sua API

- -

Before you can add sidebars to your pages, you'll need to create the pages themselves (see our What does an API reference need? guide for more guidance).

- -

Adicionar uma entrada para GroupData.json

- -

The GroupData.json file holds all the data relating to what links should appear in API reference sidebars. When invoked, the \{{APIRef}} macro takes an API name given to it as a parameter, looks up that name in GroupData.json, builds a sidebar as appropriate, and inserts it in the page.

- -

To add an entry to GroupData.json, you need to:

- -
    -
  1. Make sure you have a GitHub account.
    2. -
  2. Fork the KumaScript repo, create a new branch to contain your changes, and clone the repo locally.
    3. -
  3. Checkout your new branch before starting work, and make sure you push changes to it after finishing.
    4. -
  4. Create a pull request so that the MDN team can review your work, and ask for changes if necessary.
    5. -
- -

If you need help with using GitHub, a more detailed guide can be found at our compatibility tables guide.

- -

The GroupData.json file can be found inside the macros directory of the KumaScript repo. Looking at it, you'll see a giant JSON structure, with each API having its own member. The name is the API name, and the value is an object containing several submembers defining the sidebar links to be created.

- -

For example, look at the Fetch API page on MDN. The corresponding entry in GroupData.json looks like this:

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

As you can see, we've used "Fetch API" for the name, and inside the object value we include a number of submembers.

- -

Submembers to include inside a GroupData entry

- -

This section lists all the submembers you could include in a GroupData entry.

- -

Note that Most of the values included inside the listed submembers equate to both the link text, and slugs appended to the end of the main API index page —  https://developer.mozilla.org/<language-code>/docs/Web/API — to create the final URL for the displayed link. So for example, "Body" will result in a link being created like so in the en-US locale:

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

There are a few exceptions. For example the "guides" submember contains one or more sets of link information (title and slug) that defines links to associated guides/tutorials. In this case the slugs are appended to the end of the MDN docs root — https://developer.mozilla.org/<language-code>/docs — allowing an article anywhere on MDN to be included.

- -

Here are the available members. In each case, an example is included that assumes that the local is en-US.

- -
    -
  1. -

    "overview" — the value is an array, inside of which you include the slug of the API overview page, if there is one. "Fetch API" results in a link being made to https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API.

    -
    2. -
  2. -

    "interfaces" — the value is an array in which you should list all of the interfaces that form part of that API. "Body" results in a link being made to https://developer.mozilla.org/en-US/docs/Web/API/Body.

    -
    3. -
  3. -

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

    -
    4. -
  4. -

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

    -
    5. -
  5. -

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

    -
    6. -
  6. -

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

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

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

    -
    7. -
- -

Inserir a barra lateral nas suas páginas

- -

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

- -

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

diff --git a/files/pt-pt/mdn/structures/api_references/index.html b/files/pt-pt/mdn/structures/api_references/index.html deleted file mode 100644 index a7a7b21004..0000000000 --- a/files/pt-pt/mdn/structures/api_references/index.html +++ /dev/null @@ -1,58 +0,0 @@ ---- -title: API references -slug: MDN/Structures/API_references -tags: - - API - - Contribute - - Guide - - NeedsTranslation - - Reference - - TopicStub -translation_of: MDN/Structures/API_references ---- -
{{MDNSidebar}}
{{IncludeSubnav("/en-US/docs/MDN")}}
- -

Client-side JavaScript APIs form a large part of the technology available on the web, and MDN includes extensive reference material to explain what functionality is available in these APIs, and how to use it. In this set of guides we explain how to create API reference material on MDN.

- -

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. 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.
    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. -
- -

High level structure

- -
-
What does an API reference need?
-
This article explains what pages are required for a complete API reference.
-
Page types
-
There are a number of types of pages that are used repeatedly on MDN. This article describes these page types, their purpose, and gives examples of each and templates to use when creating a new page.
-
- -

Individual page features

- -

These articles explain how to create the individual page features required for API reference pages.

- -
-
API reference sidebars
-
When including a sidebar on your MDN API reference articles, you are able to customize it so that it displays links to related Interfaces, tutorials, and other resources relevant just to that API. This article explains how.
-
Syntax sections
-
The syntax section of an MDN reference page contains a syntax box defining the exact syntax that a feature has (e.g. what parameters can it accept, which ones are optional?) This article explains how to write syntax boxes for refererence articles.
-
Code examples
-
On MDN, you'll see numerous code examples inserted throughout the pages to demonstrate usage of web platform features. This article discusses the different mechanisms available for adding code examples to pages, along with which ones you should use and when.
-
Specification tables
-
Every reference page on MDN should provide information about the specification or specifications in which that API or technology was defined. This article demonstrates what these tables look like and explains how to construct them.
-
Compatibility tables
-
MDN has a standard format for compatibility tables for our open web documentation; that is, documentation of technologies such as the DOM, HTML, CSS, JavaScript, SVG, and so forth, that are shared across all browsers. This article covers how to use our features to add compatibility data to MDN pages.
-
diff --git a/files/pt-pt/mdn/structures/api_references/o_que_e_que_uma_referencia_de_api_precisa/index.html b/files/pt-pt/mdn/structures/api_references/o_que_e_que_uma_referencia_de_api_precisa/index.html deleted file mode 100644 index 986791e813..0000000000 --- a/files/pt-pt/mdn/structures/api_references/o_que_e_que_uma_referencia_de_api_precisa/index.html +++ /dev/null @@ -1,162 +0,0 @@ ---- -title: O que é que uma referência de API precisa? -slug: MDN/Structures/API_references/O_que_e_que_uma_referencia_de_API_precisa -translation_of: MDN/Structures/API_references/What_does_an_API_reference_need ---- -
{{MDNSidebar}}

Este artigo explica quais as páginas que são necessárias para uma referência completa da API .

- -
-

Nota: It is a good idea to create the list of documents you need to write or update when you are working on an API reference, then check them off as you complete them.

-
- -

API pages at a glance

- -

An API reference will generally contain the following pages. You can find more details of what each page contains, examples, and templates, in our Page types article.

- -
    -
  1. Overview page
    2. -
  2. Interface pages
    3. -
  3. Constructor pages
    4. -
  4. Method pages
    5. -
  5. Property pages (including event handlers properties)
    6. -
  6. Event pages
    7. -
  7. Concept/guide pages
    8. -
  8. Examples
    9. -
- -
-

Nota: We'll be referring to the Web Audio API for examples in this article.

-
- -
-

Nota: To create a page as specified below, the easiest way is to go to the parent page you want it to hang off, and choose Cog icon > New sub-article. If you haven't got this option available on your MDN interface, you'll need to request this privilege (ask at mdn-admins@mozilla.org), or ask another MDN contributor to create them for you.

-
- -

Página de sinopse

- -

A single API overview page is used to describe the role of the API, its top-level interfaces, related features contained in other interfaces, and other high level details. Its name and slug should be the name of the API plus "API" on the end. It is placed at the top level of the API reference, as a child of https://developer.mozilla.org/en-US/docs/Web/API.

- -

Example:

- - - -

Páginas da interface

- -

Each interface will have its own page too, describing the purpose of the interface, listing any members (constructors, methods, properties, etc. it contains), and showing what browsers it is compatible with. A page's name and slug should be the name of the interface, exactly as written in the spec. Each page is placed at the top level of the API reference, as a child of https://developer.mozilla.org/en-US/docs/Web/API.

- -

Exemplos:

- - - - - -
-

Nota: We document every member appearing in the interface. You should bear the following rules in mind:

- - -
- -

Páginas de constructor

- -

Each interface has 0 or 1 constructors, documented on a subpage of the interface's page. It describes the purpose of the constructor and shows what its syntax looks like, usage examples, browser compatibility information, etc. Its slug is the name of the constructor, which is exactly the same as the interface name, and the title is interface name, dot, constructor name, then parentheses on the end.

- -

Example:

- - - -

Páginas de propriedade

- -

Each interface has zero or more properties, documented on subpages of the interface's page. each page describes the purpose of the property and shows what its syntax looks like, usage examples, browser compatibility information, etc. Its slug is the name of the property, and the title is interface name, dot, then property name.

- -

Examples:

- - - - - -
-

Nota: Event handler properties are treated in the same way as regular properties; they are generally listed in a separate section on the interface page though.

-
- - - -

Páginas de método

- -

Each interface has zero or more methods, documented on subpages of the interface's page. each page describes the purpose of the method and shows what its syntax looks like, usage examples, browser compatibility information, etc. Its slug is the name of the method, and the title is interface name, dot, method name, then parentheses.

- -

Examples:

- - - - - -

Páginas de evento

- -

Each event handler property you create will have a corresponding event page, describing the event that causes the handler to fire, documented on a subpage of https://developer.mozilla.org/en-US/docs/Web/Events. Each page describes the purpose of the event and shows what its syntax looks like, usage examples, browser compatibility information, etc. Its slug and title is the name of the event.

- -

Example:

- - - -

Páginas de conceito/guia

- -

Most API references have at least one guide and sometimes also a concept page to accompany it. At minimum, an API reference should contain a guide called "Using the name-of-api", which will provide a basic guide to how to use the API. More complex APIs may require multiple usage guides to explain how to use different aspects of the API.

- -

If required, you can also including a concepts article called "name-of-api concepts", which will provide explanation of the theory behind any concepts related to the API that developers should understand to effectively use it.

- -

These articles should all be created as subpages of the API overview page. For example, the Web Audio has four guides and a concept article:

- - - -

Exemplos

- -

You should create some examples that demonstrate at least the most common use cases of the API. You can put these anywhere that is appropriate, although the recommended place is the MDN GitHub repo.

diff --git a/files/pt-pt/mdn/structures/exemplos_live/index.html b/files/pt-pt/mdn/structures/exemplos_live/index.html deleted file mode 100644 index 91295fc37c..0000000000 --- a/files/pt-pt/mdn/structures/exemplos_live/index.html +++ /dev/null @@ -1,248 +0,0 @@ ---- -title: Exemplos live -slug: MDN/Structures/Exemplos_live -tags: - - Estruturas - - Guia(2) - - Intermediário - - Metadados MDN -translation_of: MDN/Structures/Live_samples ---- -
{{MDNSidebar}}

Exemplos MDN supports turning sample code displayed in articles into running samples the reader can look at in action. These live samples can include HTML, CSS, and JavaScript in any combination. Note that "live" samples are not interactive; however, they do ensure that the output displayed for a sample matches the code of the sample exactly, because it is actually generated by the code sample.

- -

Como é que os exemplos live funcionam

- -

The live sample system gathers up all the code in a group, merges it into one HTML file, and then renders that HTML in an {{HTMLElement("iframe")}}. A live sample therefore consists of two pieces:

- - - -

A "group" of code blocks, in this context, is identified by the ID of a heading or a block element (such as a {{HTMLElement("div")}}).

- - - -

The macro uses a special URL to fetch the sample code for a given group: http://url-of-page$samples/group-id, where group-id is the ID of the heading or block where the code is located. The resulting frame (or page) is sandboxed, secure, and technically may do anything that works on the Web. Of course, as a practical matter, the code must contribute to the point of the page that contains it; random stuff running on MDN will be removed by the editor community.

- -
-

Nota: You must use the macro for presenting the live sample's output. MDN's editor will strip out any direct use of the <iframe> element in order to ensure security.

-
- -

Each {{HTMLElement("pre")}} block containing code for the sample has a class on it that indicates whether it's HTML, CSS, or JavaScript code; these are "brush: html", "brush: css", and "brush: js". These classes must be on the corresponding blocks of code so that the wiki can use them correctly; fortunately, these are added for you automatically when you use the syntax highlighter features in the editor's toolbar.

- -

The live sample system has lots of options available, and we'll try to break things down to look at them a bit at a time.

- -

Macros de exmplo live

- -

There are two macros that you can use to display live samples:

- - - -

In many cases, you may be able to add the EmbedLiveSample or LiveSampleLink macro to pages with little or no additional work! As long as the sample can be identified by a heading's ID or is in a block with an ID you can use, simply adding the macro should do the job.

- -

EmbedLiveSample macro

- -
 \{{EmbedLiveSample(block_ID, width, height, screenshot_URL, page_slug)}}
- -
-
block_ID
-
Required: The ID of the heading or enclosing block to draw the code from. The best way to be sure you have the ID right is to look at the URL of the section in the page's table of contents.
-
width
-
The width of the {{HTMLElement("iframe")}} to create, specified in px. This is optional; a reasonable default width will be used if you omit this. Note that if you want to use a specific width, you must also specify the height parameter.
-
height
-
The height of the {{HTMLElement("iframe")}} to create, specified in px. This is optional; a reasonable default height will be used if you omit this. Note that if you want to use a specific height, you must also specify the width parameter. If you use only one of them, the default frame size is used.
-
screenshot_URL
-
The URL of a screenshot that shows what the live sample should look like. This is optional, but can be useful for new technologies that may not work in the user's browser, so they can see what the sample would look like if it were supported by their browser. If you include this parameter, the screenshot is shown next to the live sample, with appropriate headings.
-
page_slug
-
The slug of the page containing the sample; this is optional, and if it's not provided, the sample is pulled from the same page on which the macro is used.
-
- -
    -
- - - -
 \{{LiveSampleLink(block_ID, link_text)}}
- -
-
block_ID
-
The ID of the heading or enclosing block to draw the code from. The best way to be sure you have the ID right is to look at the URL of the section in the page's table of contents.
-
link_text
-
A string to use as the link text.
-
- -

Utilizar o sistema de exemplo live

- -

The sections below describe a few common use cases for the live sample system.

- -

In all of these cases, to see the results of the live sample, you must click Save Changes in the editor (which takes you out of edit mode). Because of the reflexive, Inception-like nature of live samples, the Preview Changes functionality is not able to display live samples.

- -

Turning snippets into live samples

- -

One common use case is to take existing code snippets already shown on MDN and turn them into live samples.

- -

Preparar os exemplos de código

- -

The first step is to either add code snippets or ensure that existing ones are ready to be used as live samples, in terms of the content and in terms of their mark-up. The code snippets, taken together, must comprise a complete, runnable example. For example, if the existing snippet shows only CSS, you might need to add a snippet of HTML for the CSS to operate on.

- -

Each piece of code must be in a {{HTMLElement("pre")}} block, with a separate block for each language, properly marked as to which language it is. Most of the time, this has already been done, but it's always worth double-checking to be sure each piece of code is configured with the correct syntax. Next to the PRE icon in the toolbar is a drop-down menu icon (tooltip: Syntax Highlighter) with the various languages that MDN does syntax highlighting for. Setting the language for the block for syntax highlighting also correlates it with a language for the purposes of the live sample system.

- -
-

Nota: You may have more than one block for each language; they are all concatenated together. This lets you have a chunk of code, followed by an explanation of how it works, then another chunk, and so forth. This makes it even easier to produce tutorials and the like that utilize live samples interspersed with explanatory text.

-
- -

So make sure the {{HTMLElement("pre")}} blocks for your HTML, CSS, and/or JavaScript code are each configured correctly for that language's syntax highlighting, and you're good to go.

- -
-

Nota: When pasting content into MDN, please be aware that if pasting styled content (including, for example, syntax highlighting in code being copied from another site) that you may be bringing along unwanted and unneeded additional styles or classes. Please be careful not to do this; if necessary, review your edit in source mode to remove these unnecessary styles and classes (or check it before pasting, or use the "Paste as plain text" option instead).

-
- -

Inserir a macro de exemplo live

- -

Once the code is in place and properly configured to identify each block's language, you need to insert the macro that creates the iframe.

- -
    -
  1. Click the Insert Live Code Sample iFrame button in the toolbar; it looks like this: . This opens a dialog box for configuring your live sample frame:
    2. -
  2. Under Document, enter the title of the article that contains the sample you wish to embed. By default, it's the article you're currently editing, but you can choose an article elsewhere on MDN, too. This makes it possible to reuse samples on multiple pages if needed. (If you type new text in this field, a menu of partially matching pages appears; select the title of the page you want.)
    3. -
  3. In the Sections in Document menu, select the section in the article that contains the code blocks of the sample you want to embed.
    4. -
  4. Click the OK button to generate and insert the macro call that creates the sample frame for you. The macro call looks something like this:
    - \{{ EmbedLiveSample('Live_sample_demo') }}
    5. -
- -

Adicionar um novo exemplo live

- -

If you're writing a new page, and want to insert code that you want to present as a live sample, even more of the work can be done for you by the editor! 

- -
    -
  1. Click the Insert Code Sample Template button in the toolbar, which looks like this: . This presents a simple dialog asking you to name your live sample:
    -
    2. -
  2. Enter the title of the sample; this is used as the heading for the sample. Make sure that your title makes sense within the context of the page you're on.
    3. -
  3. Click OK. A new heading with the title you entered is created, with sub-headings and empty code blocks for HTML, CSS, and JavaScript.
    4. -
  4. Delete any headings and code blocks you don't need.
    5. -
  5. Enter the code that makes up your sample in the appropriate code blocks
    6. -
  6. Check conventions
    7. -
- -

Utilizar o 'Localizador de Exemplo'

- -

As mentioned above, the Sample Finder is activated by clicking the Insert Live Code Sample iFrame icon. Unfortunately the the Sample Finder may produce a macro that is NOT usable without editing. There are two problem areas that should be carefully checked and edited if necessary.

- -
    -
  1. Document field. This field will search as you type and present a list of documents that match your string. But the list presented will NOT include the sub-page. For example, say you are working on the subpage for Negative under the main page @counter-style. The Sample Finder search will not find Negative but will find the main page @counter-style. When @counter-style is selected the field background turns green. See below for the issue this creates.
    2. -
  2. Sections in Document. The pull-down menu Sections in Document may not show the section that you need. Just pick one, say Examples, and it can be fixed with a simple edit.
    3. -
- -

Here is what the Sample Finder produced:

- -
\{{ EmbedLiveSample('Examples', '', '', '', 'Web/CSS/@counter-style') }}
- -

This macro will not work. The block_ID is Examples and it should be Example in this case (check the source ID for this section to verify which block_ID you need to use. Similarly the page_slug is @counter-style and it should be @counter-style/negative. These corrections can be done directly in the page with Edit active.

- -

After editing the macro now looks like this:

- -
\{{ EmbedLiveSample('Example', '', '', '', 'Web/CSS/@counter-style/negative') }}
- -

This edited macro will work correctly. If the macro is working correctly you will see the Open in CodePen button. A thumbnail of the example should appear above the Open in CodePen button. If the button is there but there isn't a thumbnail, just wait a few minutes. It may take some time for the server to generate it.

- -

Encontrar exemplos que precisam de ser atualizados

- -

When looking for existing samples to update, there are three main kinds of updating you may wish to do:

- - - -
-

Note: If you find an article that has samples in need of being updated to use the live sample system, please add the tag "NeedsLiveSample" to the page.

-
- -

Encontrar exemplos para os transformnar em exemplos live

- -

MDN has lots of older examples that don't yet use the live sample system. Our goal is to update most or all of these to be live samples. This will improve consistency and usability. You will almost certainly find many of these as you use MDN on a daily basis; however, how can you find them if you're specifically looking for them to update? Unfortunately, there's not an easy way to do that. But there are some guidelines you can follow to help track them down:

- - - -

Demonstração de exemplo live

- -

This section is the result of using the live sample template button to create not only the main heading ("Live sample demo"), but also subheadings for our HTML, CSS, and JavaScript content. You're not limited to one block of each; in addition, they don't even need to be in any particular order. Mix and match!

- -

You may choose to delete any of these you wish; if you don't need any script, just delete that heading and its {{HTMLElement("pre")}} block. You can also delete the heading for a code block ("HTML", "CSS", or "JavaScript"), since these are not used by the live sample macro.

- -

Now that the template has been inserted, we can put in some code, and even some explanatory text.

- -

HTML

- -

This HTML creates a paragraph and some blocks to help us position and style a message.

- -
<p>A simple example of the live sample system in action.</p>
-<div class="box">
-  <div id="item">Hello world!</div>
-</div>
-
- -

CSS

- -

The CSS code styles the box as well as the text inside it.

- -
.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

- -

This code is very simple. All it does is attach an event handler to the "Hello world!" text that makes an alert appear when it is clicked.

- -
var el = document.getElementById('item');
-el.onclick = function() {
-  alert('Owww, stop poking me!');
-}
-
- -

Resultado

- -

Here is the result of running the code blocks above via \{{EmbedLiveSample('Live_sample_demo')}}:

- -

{{EmbedLiveSample('Live_sample_demo')}}

- -

Here is a link that results from calling these code blocks via \{{LiveSampleLink('Live_sample_demo', 'Live sample demo link')}}:

- -

{{LiveSampleLink('Live_sample_demo', 'Live sample demo link')}}

- -

Convenções sobre exemplos live

- -
-

Nota: This is currently (Feb. 2016) under discussion on the dev-mdc mailing list (see this thread). Any input is welcome. If this note persists after some month (Apr. 2016), please reach the author of the first email in this thread for updating this page.

-
- -
-
Ordem dos blocos de código
-
When adding a live sample, the code blocks should be sorted so that the first one corresponds to the main language for this sample (if there is one). For example, when adding a live sample for the HTML Reference, the first block should be HTML, when adding a live sample for the CSS Reference, it should be CSS and so on.
-
Nomeação de cabeçalhos
-
When there is no ambiguity (e.g. the sample is under a "Examples" section), headings should be straightforward with the sole name of the corresponding language: HTML, CSS, JavaScript, SVG, etc. (see above). Headings like "HTML Content" or "JavaScript Content" should not be used. However if such a short heading makes content unclear, one can use a more thoughtful title.
-
Utilizar um bloco de "Resultado"
-
After the different code blocks, please use a last "Result" block before using the EmbedLiveSample macro (see above). This way, the semantic of the example is made clearer for both the reader and any tools that would parse the page (e.g. screen reader, web crawler).
-
diff --git a/files/pt-pt/mdn/structures/live_samples/index.html b/files/pt-pt/mdn/structures/live_samples/index.html new file mode 100644 index 0000000000..91295fc37c --- /dev/null +++ b/files/pt-pt/mdn/structures/live_samples/index.html @@ -0,0 +1,248 @@ +--- +title: Exemplos live +slug: MDN/Structures/Exemplos_live +tags: + - Estruturas + - Guia(2) + - Intermediário + - Metadados MDN +translation_of: MDN/Structures/Live_samples +--- +
{{MDNSidebar}}

Exemplos MDN supports turning sample code displayed in articles into running samples the reader can look at in action. These live samples can include HTML, CSS, and JavaScript in any combination. Note that "live" samples are not interactive; however, they do ensure that the output displayed for a sample matches the code of the sample exactly, because it is actually generated by the code sample.

+ +

Como é que os exemplos live funcionam

+ +

The live sample system gathers up all the code in a group, merges it into one HTML file, and then renders that HTML in an {{HTMLElement("iframe")}}. A live sample therefore consists of two pieces:

+ + + +

A "group" of code blocks, in this context, is identified by the ID of a heading or a block element (such as a {{HTMLElement("div")}}).

+ + + +

The macro uses a special URL to fetch the sample code for a given group: http://url-of-page$samples/group-id, where group-id is the ID of the heading or block where the code is located. The resulting frame (or page) is sandboxed, secure, and technically may do anything that works on the Web. Of course, as a practical matter, the code must contribute to the point of the page that contains it; random stuff running on MDN will be removed by the editor community.

+ +
+

Nota: You must use the macro for presenting the live sample's output. MDN's editor will strip out any direct use of the <iframe> element in order to ensure security.

+
+ +

Each {{HTMLElement("pre")}} block containing code for the sample has a class on it that indicates whether it's HTML, CSS, or JavaScript code; these are "brush: html", "brush: css", and "brush: js". These classes must be on the corresponding blocks of code so that the wiki can use them correctly; fortunately, these are added for you automatically when you use the syntax highlighter features in the editor's toolbar.

+ +

The live sample system has lots of options available, and we'll try to break things down to look at them a bit at a time.

+ +

Macros de exmplo live

+ +

There are two macros that you can use to display live samples:

+ + + +

In many cases, you may be able to add the EmbedLiveSample or LiveSampleLink macro to pages with little or no additional work! As long as the sample can be identified by a heading's ID or is in a block with an ID you can use, simply adding the macro should do the job.

+ +

EmbedLiveSample macro

+ +
 \{{EmbedLiveSample(block_ID, width, height, screenshot_URL, page_slug)}}
+ +
+
block_ID
+
Required: The ID of the heading or enclosing block to draw the code from. The best way to be sure you have the ID right is to look at the URL of the section in the page's table of contents.
+
width
+
The width of the {{HTMLElement("iframe")}} to create, specified in px. This is optional; a reasonable default width will be used if you omit this. Note that if you want to use a specific width, you must also specify the height parameter.
+
height
+
The height of the {{HTMLElement("iframe")}} to create, specified in px. This is optional; a reasonable default height will be used if you omit this. Note that if you want to use a specific height, you must also specify the width parameter. If you use only one of them, the default frame size is used.
+
screenshot_URL
+
The URL of a screenshot that shows what the live sample should look like. This is optional, but can be useful for new technologies that may not work in the user's browser, so they can see what the sample would look like if it were supported by their browser. If you include this parameter, the screenshot is shown next to the live sample, with appropriate headings.
+
page_slug
+
The slug of the page containing the sample; this is optional, and if it's not provided, the sample is pulled from the same page on which the macro is used.
+
+ +
    +
+ + + +
 \{{LiveSampleLink(block_ID, link_text)}}
+ +
+
block_ID
+
The ID of the heading or enclosing block to draw the code from. The best way to be sure you have the ID right is to look at the URL of the section in the page's table of contents.
+
link_text
+
A string to use as the link text.
+
+ +

Utilizar o sistema de exemplo live

+ +

The sections below describe a few common use cases for the live sample system.

+ +

In all of these cases, to see the results of the live sample, you must click Save Changes in the editor (which takes you out of edit mode). Because of the reflexive, Inception-like nature of live samples, the Preview Changes functionality is not able to display live samples.

+ +

Turning snippets into live samples

+ +

One common use case is to take existing code snippets already shown on MDN and turn them into live samples.

+ +

Preparar os exemplos de código

+ +

The first step is to either add code snippets or ensure that existing ones are ready to be used as live samples, in terms of the content and in terms of their mark-up. The code snippets, taken together, must comprise a complete, runnable example. For example, if the existing snippet shows only CSS, you might need to add a snippet of HTML for the CSS to operate on.

+ +

Each piece of code must be in a {{HTMLElement("pre")}} block, with a separate block for each language, properly marked as to which language it is. Most of the time, this has already been done, but it's always worth double-checking to be sure each piece of code is configured with the correct syntax. Next to the PRE icon in the toolbar is a drop-down menu icon (tooltip: Syntax Highlighter) with the various languages that MDN does syntax highlighting for. Setting the language for the block for syntax highlighting also correlates it with a language for the purposes of the live sample system.

+ +
+

Nota: You may have more than one block for each language; they are all concatenated together. This lets you have a chunk of code, followed by an explanation of how it works, then another chunk, and so forth. This makes it even easier to produce tutorials and the like that utilize live samples interspersed with explanatory text.

+
+ +

So make sure the {{HTMLElement("pre")}} blocks for your HTML, CSS, and/or JavaScript code are each configured correctly for that language's syntax highlighting, and you're good to go.

+ +
+

Nota: When pasting content into MDN, please be aware that if pasting styled content (including, for example, syntax highlighting in code being copied from another site) that you may be bringing along unwanted and unneeded additional styles or classes. Please be careful not to do this; if necessary, review your edit in source mode to remove these unnecessary styles and classes (or check it before pasting, or use the "Paste as plain text" option instead).

+
+ +

Inserir a macro de exemplo live

+ +

Once the code is in place and properly configured to identify each block's language, you need to insert the macro that creates the iframe.

+ +
    +
  1. Click the Insert Live Code Sample iFrame button in the toolbar; it looks like this: . This opens a dialog box for configuring your live sample frame:
    2. +
  2. Under Document, enter the title of the article that contains the sample you wish to embed. By default, it's the article you're currently editing, but you can choose an article elsewhere on MDN, too. This makes it possible to reuse samples on multiple pages if needed. (If you type new text in this field, a menu of partially matching pages appears; select the title of the page you want.)
    3. +
  3. In the Sections in Document menu, select the section in the article that contains the code blocks of the sample you want to embed.
    4. +
  4. Click the OK button to generate and insert the macro call that creates the sample frame for you. The macro call looks something like this:
    + \{{ EmbedLiveSample('Live_sample_demo') }}
    5. +
+ +

Adicionar um novo exemplo live

+ +

If you're writing a new page, and want to insert code that you want to present as a live sample, even more of the work can be done for you by the editor! 

+ +
    +
  1. Click the Insert Code Sample Template button in the toolbar, which looks like this: . This presents a simple dialog asking you to name your live sample:
    +
    2. +
  2. Enter the title of the sample; this is used as the heading for the sample. Make sure that your title makes sense within the context of the page you're on.
    3. +
  3. Click OK. A new heading with the title you entered is created, with sub-headings and empty code blocks for HTML, CSS, and JavaScript.
    4. +
  4. Delete any headings and code blocks you don't need.
    5. +
  5. Enter the code that makes up your sample in the appropriate code blocks
    6. +
  6. Check conventions
    7. +
+ +

Utilizar o 'Localizador de Exemplo'

+ +

As mentioned above, the Sample Finder is activated by clicking the Insert Live Code Sample iFrame icon. Unfortunately the the Sample Finder may produce a macro that is NOT usable without editing. There are two problem areas that should be carefully checked and edited if necessary.

+ +
    +
  1. Document field. This field will search as you type and present a list of documents that match your string. But the list presented will NOT include the sub-page. For example, say you are working on the subpage for Negative under the main page @counter-style. The Sample Finder search will not find Negative but will find the main page @counter-style. When @counter-style is selected the field background turns green. See below for the issue this creates.
    2. +
  2. Sections in Document. The pull-down menu Sections in Document may not show the section that you need. Just pick one, say Examples, and it can be fixed with a simple edit.
    3. +
+ +

Here is what the Sample Finder produced:

+ +
\{{ EmbedLiveSample('Examples', '', '', '', 'Web/CSS/@counter-style') }}
+ +

This macro will not work. The block_ID is Examples and it should be Example in this case (check the source ID for this section to verify which block_ID you need to use. Similarly the page_slug is @counter-style and it should be @counter-style/negative. These corrections can be done directly in the page with Edit active.

+ +

After editing the macro now looks like this:

+ +
\{{ EmbedLiveSample('Example', '', '', '', 'Web/CSS/@counter-style/negative') }}
+ +

This edited macro will work correctly. If the macro is working correctly you will see the Open in CodePen button. A thumbnail of the example should appear above the Open in CodePen button. If the button is there but there isn't a thumbnail, just wait a few minutes. It may take some time for the server to generate it.

+ +

Encontrar exemplos que precisam de ser atualizados

+ +

When looking for existing samples to update, there are three main kinds of updating you may wish to do:

+ + + +
+

Note: If you find an article that has samples in need of being updated to use the live sample system, please add the tag "NeedsLiveSample" to the page.

+
+ +

Encontrar exemplos para os transformnar em exemplos live

+ +

MDN has lots of older examples that don't yet use the live sample system. Our goal is to update most or all of these to be live samples. This will improve consistency and usability. You will almost certainly find many of these as you use MDN on a daily basis; however, how can you find them if you're specifically looking for them to update? Unfortunately, there's not an easy way to do that. But there are some guidelines you can follow to help track them down:

+ + + +

Demonstração de exemplo live

+ +

This section is the result of using the live sample template button to create not only the main heading ("Live sample demo"), but also subheadings for our HTML, CSS, and JavaScript content. You're not limited to one block of each; in addition, they don't even need to be in any particular order. Mix and match!

+ +

You may choose to delete any of these you wish; if you don't need any script, just delete that heading and its {{HTMLElement("pre")}} block. You can also delete the heading for a code block ("HTML", "CSS", or "JavaScript"), since these are not used by the live sample macro.

+ +

Now that the template has been inserted, we can put in some code, and even some explanatory text.

+ +

HTML

+ +

This HTML creates a paragraph and some blocks to help us position and style a message.

+ +
<p>A simple example of the live sample system in action.</p>
+<div class="box">
+  <div id="item">Hello world!</div>
+</div>
+
+ +

CSS

+ +

The CSS code styles the box as well as the text inside it.

+ +
.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

+ +

This code is very simple. All it does is attach an event handler to the "Hello world!" text that makes an alert appear when it is clicked.

+ +
var el = document.getElementById('item');
+el.onclick = function() {
+  alert('Owww, stop poking me!');
+}
+
+ +

Resultado

+ +

Here is the result of running the code blocks above via \{{EmbedLiveSample('Live_sample_demo')}}:

+ +

{{EmbedLiveSample('Live_sample_demo')}}

+ +

Here is a link that results from calling these code blocks via \{{LiveSampleLink('Live_sample_demo', 'Live sample demo link')}}:

+ +

{{LiveSampleLink('Live_sample_demo', 'Live sample demo link')}}

+ +

Convenções sobre exemplos live

+ +
+

Nota: This is currently (Feb. 2016) under discussion on the dev-mdc mailing list (see this thread). Any input is welcome. If this note persists after some month (Apr. 2016), please reach the author of the first email in this thread for updating this page.

+
+ +
+
Ordem dos blocos de código
+
When adding a live sample, the code blocks should be sorted so that the first one corresponds to the main language for this sample (if there is one). For example, when adding a live sample for the HTML Reference, the first block should be HTML, when adding a live sample for the CSS Reference, it should be CSS and so on.
+
Nomeação de cabeçalhos
+
When there is no ambiguity (e.g. the sample is under a "Examples" section), headings should be straightforward with the sole name of the corresponding language: HTML, CSS, JavaScript, SVG, etc. (see above). Headings like "HTML Content" or "JavaScript Content" should not be used. However if such a short heading makes content unclear, one can use a more thoughtful title.
+
Utilizar um bloco de "Resultado"
+
After the different code blocks, please use a last "Result" block before using the EmbedLiveSample macro (see above). This way, the semantic of the example is made clearer for both the reader and any tools that would parse the page (e.g. screen reader, web crawler).
+
diff --git "a/files/pt-pt/mdn/tools/edi\303\247\303\243o_de_modelo/index.html" "b/files/pt-pt/mdn/tools/edi\303\247\303\243o_de_modelo/index.html" deleted file mode 100644 index aa1f90ba40..0000000000 --- "a/files/pt-pt/mdn/tools/edi\303\247\303\243o_de_modelo/index.html" +++ /dev/null @@ -1,12 +0,0 @@ ---- -title: Edição de modelo -slug: MDN/Tools/Edição_de_modelo -tags: - - Ferramentas - - Guía - - Metadados MDN -translation_of: MDN/Tools/Template_editing ---- -
{{MDNSidebar}}

Na MDN, os modelos esccritos em KumaScript são utilziados por uma geração de conteúdo automatizado e personalização dentro das páginas. Cada modelo é um ficheiro separado sob a diretoria de macros do repositório de KumaScript no GitHub.

- -

Qualquer pessoa que edite páginas da wiki da MDN podem invocar modelos via macros nos artigos da MDN.Qualquer pessoa pode criar e editar modelos via repositório de KumaScript no GitHub, utilizando práticas de código aberto padrão (fork repositório, criar um ramo, efetuar alterações, e submeter um pedido de submissão para revisão). Note que enviar um pedido de submissão é atualmente a única maneira para atualizar as strings traduzidas nos modelos que as contêm .

diff --git a/files/pt-pt/mdn/tools/vigiar_pagina/index.html b/files/pt-pt/mdn/tools/vigiar_pagina/index.html deleted file mode 100644 index b7f9de52b0..0000000000 --- a/files/pt-pt/mdn/tools/vigiar_pagina/index.html +++ /dev/null @@ -1,49 +0,0 @@ ---- -title: Subscrição de página -slug: MDN/Tools/Vigiar_pagina -tags: - - Ferramentas - - Guia(2) - - Metadados MDN - - Nível de Página -translation_of: MDN/Tools/Page_watching ---- -
{{MDNSidebar}}
- -

A great way to stay involved with content on MDN that you care about is to subscribe to pages, so that you're notified via email when the pages get changed. Every page on MDN offers a button offering options to monitor the page (and optionally its subpages) for changes. To access these options, hover over the Watch button to disclose the Watch menu, which looks like this:

- -

Screenshot of MDN's Watch menu

- -

Then choose the option specifying whether to watch only that one page or that page and its sub-pages, as described in the following sections.

- -

Subscrever uma página

- -

To subscribe to a single page, simply hover the mouse cursor over the Watch menu to display the Watch menu as described above, then select the first option, "Subscribe to Page Title". Once you've done this, each time a user makes a change to that one page, you'll get email describing the change.

- -

Vigiar várias páginas

- -

Choosing the second option in the Watch menu, "Subscribe to Page Title and all its sub-articles", will register you to receive email for each change made to that page as well as all of its sub-pages. This includes sub-pages added after you requested the subscription, so if more sub-pages are created in the future, you'll get notifications for those as well.

- -

Cancelar a subscriçção de uma página

- -

If you eventually need to unsubscribe from, or stop watching, a page, open the Watch menu again, and see that the "Subscribe" link has changed to "Unsubscribe." Click that, and you're unsubscribed!

- -

Mensagens de alteração de página

- -

Each time a change is saved to the page, you'll get an email. These emails come from notifications@developer.mozilla.org and are sent to the email address you used when registering your MDN account. Each message has a title of the form:

- -
[MDN] Page "Page title" changed by username
- -

The message starts with a repeat of the information in the title, then presents a standard diff of the content, showing exactly what changed. The changes are shown as HTML source code, which can be a little weird to read if you're not used to it in the context of MDN.

- -

After the diff itself comes a list of useful links that you can use to act on the change in some way, including:

- - - -

At the end of the email you see text telling you what subscription generated the email, such as "You are subscribed to edits on: HTML element reference and all its sub-articles", as well as a link you can click to unsubscribe from the messages for this watch request.

diff --git a/files/pt-pt/mdn/troubleshooting/index.html b/files/pt-pt/mdn/troubleshooting/index.html deleted file mode 100644 index 4282a39570..0000000000 --- a/files/pt-pt/mdn/troubleshooting/index.html +++ /dev/null @@ -1,71 +0,0 @@ ---- -title: Resolução de Problemas -slug: MDN/Troubleshooting -tags: - - resolução de problemas -translation_of: MDN/Troubleshooting ---- -
{{MDNSidebar}}

Este artigo descreve problemas comuns que podem ocorrer durante a utilização da MDN, e como os resolver.

- -

Não consegue guardar uma página

- -
-
Sintoma
-
You try to save some change that you have made, and you get an error message indicating that your change couldn't be saved.
-
Causa
-
Your change has been caught in MDN's spam trap.
-
Solução
-
Save a copy of your revision, and send an email to the MDN site administrators, as instructed in the error message. One of the admins will verify that it is, in fact, a legitimate change, then train the spam filter not to block edits like yours, and add you to a whitelist so that you don't encounter this problem in the future.
-
- -

As suas alterações não aparecem na página

- -
-
Sintoma
-
You make some changes to an article and click Publish; the changes that you just made are not reflected in the normal view of the page.
-
Causa
-
The page content is cached on the server, and has not been refreshed since the page was changed.
-
Solução
-
Force a refresh of the page in your browser (for example, Shift+Reload). You might see the updated content, or you might see a message indicating that an update to the page is being processed. In the second case, wait a few minutes and refresh the page again.
-
- -

Macro-generated content is out of date

- -
-
Sintoma
-
You see a page that contains content generated by a macro. You know that this macro has been updated and put into production, but the page is showing outdated values.
-
Causa
-
The macro output is cached, and has not been refreshed since the macro was updated.
-
Solução
-
Force a refresh of the page in your browser (for example, Shift+Reload). You might see the updated output, or you might see a message indicating that an update to the page is being processed. In the second case, wait a few minutes and refresh the page again.
-
- -

Erro de scripting numa página

- -
-
Sintoma
-
You see a scary red box like this on a page:
- There was a scripting error on this page. While it is being addressed by site editors, you can view partial content below. More information about this error
-
Causa
-
This is caused by a Kumascript error in a macro on the page. This issue is less common in production now that macros are stored on Github and go through a review and testing process before being put into production. You might see it if you modify a macro call or its arguments in a way that breaks the macros. You might also see it  if you are editing macros on a local build of the MDN platform.
-
Solução
-
If you modified a macro call, you can check the name and parameters of the macro against the Kumascript Github repo. If you are in the midst of modifying the macro in question, Troubleshooting Kumascript errors may be helpful.
-
- -

Scripting error while previewing a page

- -
-
Sintoma
-
You are editing a page, and click the Preview button. The preview of the page contains a scripting error message (as shown in the previous section).
-
Causa
-
Either there was an existing scripting error in the page you were editing, or you have introduced an error, possibly by changing arguments to a macro.
-
Solução
-
-

Be assured that as long as you have not modified or added any macros or templates in the page, you can safely ignore this error; you can expect it to go away when the edited page is finally saved and viewed normally again (unless the error was already there in the normal view).

- -

If you are still unsure whether you introduced the error, then you can open a copy of the normal page in a new window, enter Edit mode, and immediately click Preview. If any errors occur now, you can be confident that you did not cause them, and that they will likely disappear as previously described. As for your changes, if these new errors are the same as the old errors from the old window, then  close the new window and continue working in the old one.  However, if they are different errors, then you indeed might have damaged something in the old window, so just start carefully copying your changes to the new window, and click Preview after each copy.  If the old errors suddenly appear here too, then your last changes have likely caused them, and you should carefully examine that work.  Finally, as a side benefit, if you click Preview frequently and always leave that Preview window open, you will have a quick but unsaved copy of most of your changes in case the editor fails or somehow loses your work (as may happen when trying to use Discard.)

- -

 

-
-
 
-
diff --git a/files/pt-pt/mdn/yari/index.html b/files/pt-pt/mdn/yari/index.html new file mode 100644 index 0000000000..3ffc29d8b6 --- /dev/null +++ b/files/pt-pt/mdn/yari/index.html @@ -0,0 +1,24 @@ +--- +title: 'Kuma: Plataforma wiki da MDN' +slug: MDN/Kuma +tags: + - Kuma + - MDN Meta + - Metadados MDN +translation_of: MDN/Kuma +--- +
{{MDNSidebar}}{{IncludeSubnav("/pt-PT/docs/MDN")}}
+ +

Kuma é o código Django que é utilizado para os 'Documentos da Web na MDN'.

+ +

{{SubpagesWithSummaries}}

+ +

Participe na plataforma Kuma

+ +

Para participar na plataforma Kuma:

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