initial commit

4 files changed, 1078 insertions, 0 deletions

diff --git a/files/pt-pt/mdn/guidelines/convencoes_definicoes/index.html b/files/pt-pt/mdn/guidelines/convencoes_definicoes/index.html
new file mode 100644
index 0000000000..f3a57c70c3
--- /dev/null
+++ b/files/pt-pt/mdn/guidelines/convencoes_definicoes/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
+---
+<div>{{MDNSidebar}}</div>
+
+<div>{{IncludeSubnav("/pt-PT/docs/MDN")}}</div>
+
+<p class="summary">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.</p>
+
+<h2 id="Definições">Definições</h2>
+
+<h3 id="Desaprovada_e_obsoleta">Desaprovada e obsoleta</h3>
+
+<p><strong>Desaprovada</strong> e <strong>obsoleta</strong> são termos comuns associados com as tecnologias e especificações, mas o que eles significam?</p>
+
+<dl>
+ <dt>Desaprovada</dt>
+ <dd>Na MDN, o termo '<strong>desaprovada</strong>' 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 <a href="https://github.com/mdn/browser-compat-data/blob/master/schemas/compat-data-schema.md#status-information">projeto de dados compatíveis do navegador</a>, 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".</dd>
+ <dt>Obsoleta</dt>
+ <dd>No MDN, o termo '<strong>obsoleta</strong>'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'.</dd>
+</dl>
+
+<h3 id="Experimental">Experimental</h3>
+
+<p><strong>Experimental</strong> 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).</p>
+
+<p>One or both of these will be true:</p>
+
+<ul>
+ <li>It is implemented and enabled by default in less than two modern major browsers.</li>
+ <li>Its defining spec is not stable and likely to change significantly. Its syntax and behavior is therefore subject to change in future versions of browsers as the specification changes.</li>
+</ul>
+
+<p>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 <a href="https://github.com/mdn/browser-compat-data/blob/master/compat-data-schema.md#status-information">browser-compat-data project</a>.</p>
+
+
+
+<p>Conversely, an item is no longer experimental when:</p>
+
+<ul>
+ <li>It is implemented in two or more major browsers; or</li>
+ <li>Its defining spec is stable and unlikely to change.</li>
+</ul>
+
+
+
+<h3 id="Páginas_arquivadas">Páginas arquivadas</h3>
+
+<p>Archived pages are pages that are stored in the MDN <a href="/en-US/docs/Archive">Archive of obsolete content</a>. These pages contain information out-of-date enough that it is not directly useful to anyone anymore.</p>
+
+<p>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 <a href="/en-US/docs/Archive/B2G_OS">B2G (Firefox OS) project</a>.</p>
+
+<h4 id="Quando_é_que_uma_página_deverá_ser_arquivada">Quando é que uma página deverá ser arquivada?</h4>
+
+<p>A page should be archived if it fits the above description. To archive a page, you should use the "Move page feature" (<em>Advanced &gt; Move this article</em>) 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 <a href="https://discourse.mozilla.org/c/mdn">Discourse forum</a>.</p>
+
+<h3 id="Páginas_eliminadas">Páginas eliminadas</h3>
+
+<p>Deleted pages are pages that have been explicitly deleted from MDN — see for example the <code><a href="/en-US/docs/Web/API/SharedKeyframeList">SharedKeyframeList</a></code> interface and <code><a href="/en-US/docs/Web/API/SharedKeyframeList/SharedKeyframeList">SharedKeyframeList()</a></code> 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.</p>
+
+<p>These might be:</p>
+
+<ul>
+ <li>Reference pages for API features that were removed from the specification before they were implemented in any browsers.</li>
+ <li>Articles covering techniques that were later shown to be bad practice and superceded by better techniques.</li>
+ <li>Articles containing information that were later replaced by other, better quality articles.</li>
+ <li>Articles containing content that is inappropriate for MDN.</li>
+ <li>Translations that are old, out-of-date, and difficult to fix, meaning that the English version is preferrable and starting a new translation would be an easier option.</li>
+</ul>
+
+<h4 id="Quando_é_que_uma_página_deverá_ser_eliminada">Quando é que uma página deverá ser eliminada?</h4>
+
+<p>A page should be deleted if it fits the above description. To delete a page, you should use the "Delete this page feature" (<em>Advanced &gt; Delete this page</em>) 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 <a href="https://discourse.mozilla.org/c/mdn">Discourse forum</a>.</p>
+
+
+
+
+
+<h3 id="Quando_documentar_novas_tecnologias">Quando documentar novas tecnologias</h3>
+
+<p>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.</p>
+
+<p>In general, our definition of the earliest we'll consider documenting a new technology is:</p>
+
+<p><em>"When the feature is on a standards track and is implemented somewhere."</em></p>
+
+<p>You should definitely consider documenting a new technology if:</p>
+
+<ul>
+ <li>It is specified in a specification document published under a reliable standards organization (such as W3C, WHATWG, Khronos, IETF, etc.), which has reached a reasonable level of stability (e.g. a W3C working draft or candidate recommendation, or the spec is looking to be fairly stable judging by the flow of issues filed against it).</li>
+ <li>It is implemented consistently in at least one browser, with other browser developers showing signs of interest (such as an active ticket or "intent to implement" process in effect).</li>
+</ul>
+
+<p>You should be more wary of documenting a new technology (but should still consider it if it makes sense) if it:</p>
+
+<ul>
+ <li>Doesn't have a spec, or the spec is a rough note that looks liable to change.</li>
+ <li>One or zero browsers currently implement it, and non-supporting browsers are not showing signs of interest in implementing it (you can gauge this by asking engineers who work on those browsers, looking at browser bug trackers and mailing lists, etc.).</li>
+</ul>
+
+<p>You should not consider documenting a new technology if it:</p>
+
+<ul>
+ <li>Is not a web-exposed technology and/or is completely proprietary.</li>
+ <li>Is already showing signs of being deprecated, or superseded by a similar feature.</li>
+</ul>
+
+
+
+<h2 id="Convenções">Convenções</h2>
+
+<h3 id="Quando_é_removido_algo_da_especificação">Quando é removido algo da especificação</h3>
+
+<p>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.</p>
+
+<div class="note">
+<p>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.</p>
+</div>
+
+<ul>
+ <li>If the item was <em>never</em> implemented in a release version of <em>any</em> browser—even behind a preference or flag—simply delete any references to the item from the documentation.
+
+  <ul>
+   <li>If the item has any documentation pages describing only that one item (such as {{domxref("RTCPeerConnection.close()")}}), delete that page. If the removed item is an interface, this means removing any subpages describing the properties and methods on that interface as well.</li>
+   <li>Remove the item from any lists of properties, attributes, methods, and so forth. For methods of an interface, that means to remove it from the "Methods" section on the interface's overview page, for example.</li>
+   <li>Search the text of the overview page for that interface, element, etc. for any references to the removed item. Remove those references, being sure not to leave weird grammar issues or other problems with the text. This may mean not just deleting words but rewriting a sentence or paragraph to make more sense. It may also mean removing entire sections of content if the description of the item's use is lengthy.</li>
+   <li>Similarly, look for any discussion of the item in the guides and tutorials about the relevant API or technology. Remove those references, being sure not to leave weird grammar issues or other problems with the text. This may mean not just deleting words but rewriting a sentence or paragraph to make more sense. It may also mean removing entire sections of content if the description of the item's use is lengthy.</li>
+   <li>Search MDN for references to the removed item, in case there are discussions elsewhere. It's unlikely that there are, since if it was never implemented, it's unlikely to be widely discussed. Remove those mentions as well.</li>
+   <li>If the <a href="https://github.com/mdn/browser-compat-data">Browser Compatibility Data repository's</a> JSON files contain data for the removed items, delete those objects from the JSON code and submit a PR with that change, explaining why in the commit message and the PR description. Be careful to check that you don't break the JSON syntax while doing this.</li>
+  </ul>
+ </li>
+ <li>If the item was implemented in any release version of any one or more browsers—but <em>only</em> behind a preference or flag—do not delete the item from the documentation immediately. Instead, mark the item as obsolete as follows:
+  <ul>
+   <li>If the item has any documentation pages describing only that one item (such as {{domxref("RTCPeerConnection.close()")}}), add the {{TemplateLink("obsolete_header")}} macro to the top of the page and add the {{tag("Obsolete")}} tag to the page's list of tags.</li>
+   <li>On the overview page for the element, interface, or API, find the list of items which includes the item that's been removed from the specification and add the {{TemplateLink("obsolete_inline")}} macro after the item's name in that list.</li>
+   <li>Search the informative text of the overview page for that interface, element, etc. for any references to the removed item. Add warning boxes in appropriate places with text along the lines of "[whatever] has been removed from the specification and will be removed from browsers soon. See [link to page] for a new way to do this."</li>
+   <li>Similarly, look for any discussion of the item in the guides and tutorials about the relevant API or technology. Add similar warnings.</li>
+   <li>Search MDN for references to the removed item, in case there are discussions elsewhere. Add similar warning boxes there as well.</li>
+   <li>At some point in the future, a decision may be made to actually remove the item from the documentation; we don't normally do this but if the item was especially unutilized or uninteresting, we may decide to do so.</li>
+   <li>Update any relevant entries in the <a href="https://github.com/mdn/browser-compat-data">Browser Compatibility Data repo</a> to reflect the obsolescence of the item(s) affected.</li>
+  </ul>
+ </li>
+ <li>If the item was implemented in one or more release builds of browsers—without requiring a preference or flag to be changed—mark the item as deprecated, as follows:
+  <ul>
+   <li>If the item has any documentation pages describing only that one item (such as {{domxref("RTCPeerConnection.close()")}}), add the {{TemplateLink("deprecated_header")}} macro to the top of the page and add the {{tag("Deprecated")}} tag to the page's list of tags.</li>
+   <li>On the overview page for the element, interface, or API, find the list of items which includes the item that's been removed from the specification and add the {{TemplateLink("deprecated_inline")}} macro after the item's name in that list.</li>
+   <li>Search the informative text of the overview page for that interface, element, etc. for any references to the removed item. Add warning boxes in appropriate places with text along the lines of "[whatever] has been removed from the specification and is deprecated. It may be removed from browsers in the future, so you should not use it. See [link to page] for a new way to do this."</li>
+   <li>Similarly, look for any discussion of the item in the guides and tutorials about the relevant API or technology. Add similar warnings.</li>
+   <li>Search MDN for references to the removed item, in case there are discussions elsewhere. Add similar warning boxes there as well.</li>
+   <li>It's unlikely that these items will be removed from the documentation anytime soon, if ever. It's possible, however, that some or all of the material may be moved to the <a href="/en-US/docs/Archive">Archive</a> section of the site.</li>
+   <li>Update any relevant entries in the <a href="https://github.com/mdn/browser-compat-data">Browser Compatibility Data repo</a> to reflect the deprecation of the item(s) affected.</li>
+  </ul>
+ </li>
+</ul>
+
+<p>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 <a href="https://chat.mozilla.org/#/room/#mdn:mozilla.org">MDN Web Docs chat room</a> on <a href="https://wiki.mozilla.org/Matrix">Matrix</a>, or on the <a href="https://discourse.mozilla.org/c/mdn">MDN Web Docs discussion forum</a>.</p>
+
+<h3 id="Copiar_conteúdo_dentro_da_MDN">Copiar conteúdo dentro da MDN</h3>
+
+<p>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:</p>
+
+<ul>
+ <li>If you want to copy an entire page:
+  <ol>
+   <li>While viewing the page you want to copy, on the <strong>Advanced</strong> (gear) menu, choose  <strong><a href="/en-US/docs/MDN/Contribute/Creating_and_editing_pages#Clone_of_an_existing_page">Clone this page</a></strong>. This opens the editor UI for a new page, with the contents of the cloned page already populated.</li>
+   <li>Enter a new <strong>Title</strong> and <strong>Slug</strong> for the cloned page.</li>
+   <li>Edit the contents of the page as needed, and save as usual.</li>
+  </ol>
+ </li>
+ <li>If you want to copy just part of a page, <strong>don't just visit the page and copy from it</strong>. This introduce unwanted additional bits of HTML into the destination page, and somebody will have to clean that up, you or another editor. Nobody wants that. To copy part of an MDN page to another page:
+  <ol>
+   <li>On the source page, click the <strong>Edit</strong> button on the source page.</li>
+   <li><strong>Copy the content you want to reuse from within the editor UI.</strong></li>
+   <li>Click <strong>Discard</strong> to exit the editor UI for that page.</li>
+   <li>Open the editor UI for page where you want to paste.</li>
+   <li>Paste the content from the clipboard.</li>
+  </ol>
+ </li>
+ <li>Sometimes you literally want to use the same content on many pages. In this case, you might be best off placing the content in one page, then using the {{TemplateLink("Page")}} macro to transclude the material from one page into another. This way, whenever the text on the source page is updated, the destination page will update as well (that is, this will happen on a forced-refresh or when the target page goes through a scheduled rebuild).</li>
+</ul>
+
+<h4 id="Copiar_conteúdo_de_outro_lado">Copiar conteúdo de outro lado</h4>
+
+<p>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.</p>
+
+<p>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.</p>
+
+<p>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 <a href="/en-US/docs/MDN/About#Copyrights_and_licenses">MDN's license</a>.</p>
+
+<ul>
+ <li><strong>If you created the existing content</strong> (for your own purposes and not as work-for-hire), and you are willing to contribute it to MDN under MDN's license, this is the easiest case, and you are free to contribute the content.</li>
+ <li><strong>If the copyright for the content belongs to someone else</strong>, it must be licensed and attributed compatibly with MDN's license. It is often not easy for someone who is not a lawyer to determine what licenses are compatible. To be on the safe side, contact a member of the <a href="https://wiki.mozilla.org/MDN#Staff_Team">MDN staff team</a>, who may consult Mozilla's Legal team for guidance if necessary.</li>
+</ul>
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
new file mode 100644
index 0000000000..fe96ad554e
--- /dev/null
+++ b/files/pt-pt/mdn/guidelines/guia_de_estilo_de_escrita/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
+---
+<div>{{MDNSidebar}}</div>
+
+<p><span class="seoSummary">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.</span> 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.</p>
+
+<p>If you're looking for specifics of how a given type of page should be structured, see the <a href="/en-US/docs/MDN/Contribute/Content/Layout">MDN page layout guide</a>.</p>
+
+<p>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.</p>
+
+<p>For style standards that apply to content written for sites other than MDN, refer to the <a href="https://www.mozilla.org/en-US/styleguide/" title="https://www.mozilla.org/en-US/styleguide/">One Mozilla style guide</a>.</p>
+
+<h2 id="Básico">Básico</h2>
+
+<p>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.</p>
+
+<h3 id="Page_titles">Page titles</h3>
+
+<p>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 "<em>&lt;locale&gt;/docs/</em>".</p>
+
+<h4 id="Title_and_heading_capitalization">Title and heading capitalization</h4>
+
+<p>Page titles and section headings should use sentence-style capitalization (only capitalize the first word and proper nouns) rather than headline-style capitalization:</p>
+
+<ul>
+ <li><span class="correct"><strong>Correct</strong></span>: "A new method for creating JavaScript rollovers"</li>
+ <li><span class="incorrect"><strong>Incorrect</strong></span>: "A New Method for Creating JavaScript Rollovers"</li>
+</ul>
+
+<p>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.</p>
+
+<h4 id="Choosing_titles_and_slugs">Choosing titles and slugs</h4>
+
+<p>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.</p>
+
+<p>Page titles, on the other hand, may be as long as you like, within reason, and they should be descriptive.</p>
+
+<h4 id="Creating_new_subtrees">Creating new subtrees</h4>
+
+<p>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.</p>
+
+<p>For example, consider the <a href="/en-US/docs/Web/JavaScript">JavaScript</a> guide, which is structured as follows:</p>
+
+<ul>
+ <li><a href="/en-US/docs/Web/JavaScript/Guide" title="JavaScript/Guide">JavaScript/Guide</a> - Main table-of-contents page</li>
+ <li><a href="/en-US/docs/Web/JavaScript/Guide/JavaScript_Overview" title="JavaScript/Guide/JavaScript_Overview">JavaScript/Guide/JavaScript Overview</a></li>
+ <li><a href="/en-US/docs/JavaScript/Guide/Functions" title="JavaScript/Guide/Functions">JavaScript/Guide/Functions</a></li>
+ <li><a href="/en-US/docs/JavaScript/Guide/Details_of_the_Object_Model" title="JavaScript/Guide/Details_of_the_Object_Model">JavaScript/Guide/Details of the Object Model</a></li>
+</ul>
+
+<p>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.</p>
+
+<h3 id="Sections_paragraphs_and_newlines">Sections, paragraphs, and newlines</h3>
+
+<p>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.</p>
+
+<p>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.</p>
+
+<p>Don't create single subsections -- you don't subdivide a topic into one. It's either two subheadings or more or none at all. </p>
+
+<p>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.</p>
+
+<h3 id="Listas">Listas</h3>
+
+<p>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.</p>
+
+<h4 id="Bulleted_Lists">Bulleted Lists</h4>
+
+<p>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.</p>
+
+<p>An example of a correctly structured bulleted list:</p>
+
+<blockquote>
+<p><em>In this example we should include:</em></p>
+
+<ul>
+ <li><em>A condition, with a brief explanation.</em></li>
+ <li><em>A similar condition, with a brief explanation.</em></li>
+ <li>
+  <p><em>Yet another condition, some further explanation.</em></p>
+ </li>
+</ul>
+</blockquote>
+
+<p>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.</p>
+
+<h4 id="Listas_Numeradas">Listas Numeradas</h4>
+
+<p>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.</p>
+
+<p>An example of a correctly structured numbered list:</p>
+
+<blockquote>
+<p><em>In order for you to structure a correct numbered list you must:</em></p>
+
+<p><em>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.</em></p>
+
+<p><em>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.</em></p>
+
+<p><em>3. After you have finished your instructions, close off the numbered list with a brief explanation of the outcome upon completion.</em></p>
+
+<p><em>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. </em></p>
+</blockquote>
+
+<p>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.  </p>
+
+<h3 id="Formatação_e_estilo_do_texto">Formatação e estilo do texto</h3>
+
+<p>Use the "Formatting Styles" drop-down list to apply predefined styles to selected content.</p>
+
+<div class="note">The "Note" style is used to call out important notes, like this one.</div>
+
+<div class="warning">Similarly, the "Warning" style creates warning boxes like this.</div>
+
+<p>Unless specifically instructed to do so, <strong>do not</strong> use the HTML <code>style</code> attribute to manually style content. If you can't do it using a predefined class, drop into {{IRCLink("mdn")}} and ask for help.</p>
+
+<h3 id="Code_sample_style_and_formatting">Code sample style and formatting</h3>
+
+<h4 id="Tabs_and_line_breaks">Tabs and line breaks</h4>
+
+<p>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:</p>
+
+<pre class="brush: js notranslate">if (condition) {
+  /* handle the condition */
+} else {
+  /* handle the "else" case */
+}
+</pre>
+
+<p>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:</p>
+
+<pre class="brush: js notranslate">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);
+</pre>
+
+<h4 id="Inline_code_formatting">Inline code formatting</h4>
+
+<p>Use the "Code" button (labeled with two angle brackets "&lt;&gt;") to apply inline code-style formatting to function names, variable names, and method names (this uses the {{HTMLElement("code")}} element). For example, "the <code class="js plain">frenchText()</code> function".</p>
+
+<p>Method names should be followed by a pair of parentheses: <code>doSomethingUseful()</code>. The parentheses help differentiate methods from other code terms.</p>
+
+<h4 id="Syntax_highlighting">Syntax highlighting</h4>
+
+<p><img alt="Screenshot of the 'Syntax Highlighter' menu." src="https://mdn.mozillademos.org/files/12682/Language%20list.png" style="border-style: solid; border-width: 1px; float: right; margin: 2px 4px;">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.</p>
+
+<p>The following example shows text with JavaScript formatting:</p>
+
+<div class="line number2 index1 alt1">
+<pre class="brush: js notranslate">for (var i = 0, j = 9; i &lt;= 9; i++, j--)
+  document.writeln("a[" + i + "][" + j + "]= " + a[i][j]);</pre>
+</div>
+
+<p>If no appropriate language is available, use ("No Highlight" in the language menu). This will result in code without syntax highlighting:</p>
+
+<pre class="brush: plain notranslate">x = 42;</pre>
+
+<h4 id="Syntax_definitions">Syntax definitions</h4>
+
+<p>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.</p>
+
+<h4 id="Blocks_not_referring_to_code">Blocks not referring to code</h4>
+
+<p>There are a few use cases where a &lt;pre&gt; block does not refer to code and doesn't have syntax highlighting nor line numbers. In such cases you should add a &lt;pre&gt; without class. Those cases include things like tree structures:</p>
+
+<pre class="notranslate">root/
+
+    folder1/
+        file1
+
+    folder2/
+        file2
+        file3
+</pre>
+
+<p>To create preformatted content without syntax highlighting and line numbers click the "pre" button in the toolbar. Then start to type the text.</p>
+
+<h4 id="Styling_HTML_element_references">Styling HTML element references</h4>
+
+<p>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.</p>
+
+<dl>
+ <dt>Element names</dt>
+ <dd>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, <strong>enclose the name in angle brackets</strong> and use "Code (inline)" style (e.g., <code>&lt;title&gt;</code>).</dd>
+ <dt>Attribute names</dt>
+ <dd>Use <strong>bold face</strong>.</dd>
+ <dt>Attribute definitions</dt>
+ <dd>Use the {{TemplateLink("htmlattrdef")}} macro (e.g., <span class="nowiki">\{{htmlattrdef("type")}}</span>) for the definition term, so that it can be linked to from other pages, then use the {{TemplateLink("htmlattrxref")}} macro (e.g., <span class="nowiki">\{{htmlattrxref("attr","element")}}</span>) to reference attribute definitions.</dd>
+ <dt>Attribute values</dt>
+ <dd>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 <strong>type</strong> attribute of an <code>&lt;input&gt;</code> element is set to <code>email</code> or <code>tel</code> ...</dd>
+ <dt>Labeling attributes</dt>
+ <dd>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.</dd>
+</dl>
+
+<h3 id="Latin_abbreviations">Latin abbreviations</h3>
+
+<h4 id="In_notes_and_parentheses">In notes and parentheses</h4>
+
+<ul>
+ <li>Common Latin abbreviations (etc., i.e., e.g.) may be used in parenthetical expressions and notes. Use periods in these abbreviations, followed by a comma or other appropriate punctuation.
+  <ul>
+   <li><span class="correct"><strong>Correct</strong></span>: Web browsers (e.g., Firefox) can be used ...</li>
+   <li><span class="incorrect"><strong>Incorrect</strong></span>: Web browsers e.g. Firefox can be used ...</li>
+   <li><span class="incorrect"><strong>Incorrect</strong></span>: Web browsers, e.g. Firefox, can be used ...</li>
+   <li><span class="incorrect"><strong>Incorrect</strong></span>: Web browsers, (eg: Firefox) can be used ...</li>
+  </ul>
+ </li>
+</ul>
+
+<h4 id="In_running_text">In running text</h4>
+
+<ul>
+ <li>In regular text (i.e., text outside of notes or parentheses), use the English equivalent of the abbreviation.
+  <ul>
+   <li><span class="correct"><strong>Correct</strong></span>: ... web browsers, and so on.</li>
+   <li><span class="incorrect"><strong>Incorrect</strong></span>: ... web browsers, etc.</li>
+   <li><span class="correct"><strong>Correct</strong></span>: Web browsers such as Firefox can be used ...</li>
+   <li><span class="incorrect"><strong>Incorrect</strong></span>: Web browsers e.g. Firefox can be used ...</li>
+  </ul>
+ </li>
+</ul>
+
+<h4 id="Meanings_and_English_equivalents_of_Latin_abbreviations">Meanings and English equivalents of Latin abbreviations</h4>
+
+<table class="fullwidth-table">
+ <tbody>
+  <tr>
+   <th>Abbrev</th>
+   <th>Latin</th>
+   <th>English</th>
+  </tr>
+  <tr>
+   <td>cf.</td>
+   <td><em>confer</em></td>
+   <td>compare</td>
+  </tr>
+  <tr>
+   <td>e.g.</td>
+   <td><em>exempli gratia</em></td>
+   <td>for example</td>
+  </tr>
+  <tr>
+   <td>et al.</td>
+   <td><em>et alii</em></td>
+   <td>and others</td>
+  </tr>
+  <tr>
+   <td>etc.</td>
+   <td><em>et cetera</em></td>
+   <td>and so forth, and so on</td>
+  </tr>
+  <tr>
+   <td>i.e.</td>
+   <td><em>id est</em></td>
+   <td>that is, in other words</td>
+  </tr>
+  <tr>
+   <td>N.B.</td>
+   <td><em>nota bene</em></td>
+   <td>note well</td>
+  </tr>
+  <tr>
+   <td>P.S.</td>
+   <td><em>post scriptum</em></td>
+   <td>postscript</td>
+  </tr>
+ </tbody>
+</table>
+
+<div class="note">
+<p>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 <strong>you</strong> 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.</p>
+</div>
+
+<h3 id="Acronyms_and_abbreviations">Acronyms and abbreviations</h3>
+
+<h4 id="Capitalization_and_periods">Capitalization and periods</h4>
+
+<p>Use full capitals and delete periods in all acronyms and abbreviations, including organizations such as "US" and "UN".</p>
+
+<ul>
+ <li><span class="correct"><strong>Correct</strong></span>: XUL</li>
+ <li><span class="incorrect"><strong>Incorrect</strong></span>: X.U.L.; Xul</li>
+</ul>
+
+<h4 id="Expansion">Expansion</h4>
+
+<p>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 <a href="/en-US/docs/Glossary">glossary</a> entry describing the technology.</p>
+
+<ul>
+ <li><span class="correct"><strong>Correct</strong></span>: "XUL (XML User Interface Language) is Mozilla's XML-based language..."</li>
+ <li><span class="incorrect"><strong>Incorrect</strong></span>: "XUL is Mozilla's XML-based language..."</li>
+</ul>
+
+<h4 id="Plurals_of_acronyms_and_abbreviations">Plurals of acronyms and abbreviations</h4>
+
+<p>For plurals of acronyms or abbreviations, add <em>s</em>. Don't use an apostrophe. Ever. Please.</p>
+
+<ul>
+ <li><span class="correct"><strong>Correct</strong></span>: CD-ROMs</li>
+ <li><span class="incorrect"><strong>Incorrect</strong></span>: CD-ROM's</li>
+</ul>
+
+<h4 id="Versus_vs._and_v.">"Versus", "vs.", and "v."</h4>
+
+<p>The contraction "vs." is preferred.</p>
+
+<ul>
+ <li><span class="correct"><strong>Correct</strong></span>: this vs. that</li>
+ <li><span class="incorrect"><strong>Incorrect</strong></span>: this v. that</li>
+ <li><span class="incorrect"><strong>Incorrect</strong></span>: this versus that</li>
+</ul>
+
+<h3 id="Capitalização">Capitalização</h3>
+
+<p>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.</p>
+
+<p>Keyboard keys should use sentence-style capitalization, not all-caps capitalization. For example, "Enter" not "ENTER."</p>
+
+<h3 id="Contrações">Contrações</h3>
+
+<p>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.</p>
+
+<h3 id="Pluralização">Pluralização</h3>
+
+<p>Use English-style plurals, not the Latin- or Greek-influenced forms.</p>
+
+<ul>
+ <li><span class="correct"><strong>Correct</strong></span>: syllabuses, octopuses</li>
+ <li><span class="incorrect"><strong>Incorrect</strong></span>: syllabi, octopi</li>
+</ul>
+
+<h3 id="Hifenização">Hifenização</h3>
+
+<p>Hyphenate compounds when the last letter of the prefix is a vowel and is the same as the first letter of the root.</p>
+
+<ul>
+ <li><font color="green"><strong>Correct</strong></font>: email, re-elect, co-op</li>
+ <li><font color="red"><strong>Incorrect</strong></font>: e-mail, reelect, coop</li>
+</ul>
+
+<h3 id="Idioma_de_género_neutral">Idioma de género neutral</h3>
+
+<p>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.<br>
+ <br>
+ Let's take the following example:</p>
+
+<blockquote>
+<p>A confirmation dialog appears, asking the user if he allows the Web page to make use of his Web cam.</p>
+</blockquote>
+
+<blockquote>
+<p>A confirmation dialog appears, asking the user if she allows the Web page to make use of her Web cam.</p>
+</blockquote>
+
+<p>Both versions are gender-specific. To fix this, use gender-neutral pronouns:</p>
+
+<blockquote>
+<p>A confirmation dialog appears, asking the user if they allow the Web page to make use of their Web cam.</p>
+</blockquote>
+
+<div class="note">
+<p>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 "<a href="https://en.wikipedia.org/wiki/Singular_they">singular 'they.'</a>"</p>
+</div>
+
+<p>You can use both genders:</p>
+
+<blockquote>
+<p>A confirmation dialog appears, asking the user if he or she allows the web page to make use of his/her web cam.</p>
+</blockquote>
+
+<p>making the users plural:</p>
+
+<blockquote>
+<p>A confirmation dialog appears, asking the users if they allow the web page to make use of their web cams.</p>
+</blockquote>
+
+<p>The best solution, of course, is to rewrite and eliminate the pronouns:</p>
+
+<blockquote>
+<p>A confirmation dialog appears, requesting the user's permission for web cam access.</p>
+</blockquote>
+
+<blockquote>
+<p>A confirmation dialog box appears, which asks the user for permission to use the web cam.</p>
+</blockquote>
+
+<p>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.</p>
+
+<h3 id="Numbers_and_numerals">Numbers and numerals</h3>
+
+<h4 id="Dates">Dates</h4>
+
+<p>For dates (not including dates in code samples) use the format "January 1, 1990".</p>
+
+<ul>
+ <li><span class="correct"><strong>Correct</strong></span>: February 24, 2006</li>
+ <li><span class="incorrect"><strong>Incorrect</strong></span>: February 24th, 2006; 24 February, 2006; 24/02/2006</li>
+</ul>
+
+<p>Alternately, you can use the YYYY/MM/DD format.</p>
+
+<ul>
+ <li><span class="correct"><strong>Correct</strong></span>: 2006/02/24</li>
+ <li><span class="incorrect"><strong>Incorrect</strong></span>: 02/24/2006; 24/02/2006; 02/24/06</li>
+</ul>
+
+<h4 id="Decades">Decades</h4>
+
+<p>For decades, use the format "1990s". Don't use an apostrophe.</p>
+
+<ul>
+ <li><span class="correct"><strong>Correct</strong></span>: 1990s</li>
+ <li><span class="incorrect"><strong>Incorrect</strong></span>: 1990's</li>
+</ul>
+
+<h4 id="Plurals_of_numerals">Plurals of numerals</h4>
+
+<p>For plurals of numerals add "s". Don't use an apostrophe.</p>
+
+<ul>
+ <li><span class="correct"><strong>Correct</strong></span>: 486s</li>
+ <li><span class="incorrect"><strong>Incorrect</strong></span>: 486's</li>
+</ul>
+
+<h4 id="Commas">Commas</h4>
+
+<p>In running text, use commas only in five-digit and larger numbers.</p>
+
+<ul>
+ <li><span class="correct"><strong>Correct</strong></span>: 4000; 54,000</li>
+ <li><span class="incorrect"><strong>Incorrect</strong></span>: 4,000; 54000</li>
+</ul>
+
+<h3 id="Punctuation">Punctuation</h3>
+
+<h4 id="Serial_comma">Serial comma</h4>
+
+<p><strong>Use the serial comma</strong>. The serial (also known as "Oxford") comma is the comma that appears before the conjunction in a series of three or more items.</p>
+
+<ul>
+ <li><span class="correct"><strong>Correct</strong></span>: I will travel on trains, planes, and automobiles.</li>
+ <li><span class="incorrect"><strong>Incorrect</strong></span>: I will travel on trains, planes and automobiles.</li>
+</ul>
+
+<div class="note">
+<p>This is in contrast to the <a href="https://www.mozilla.org/en-US/styleguide/" title="https://www.mozilla.org/en-US/styleguide/">One Mozilla style guide</a>, which specifies that the serial comma is not to be used. MDN is an exception to this rule.</p>
+</div>
+
+<h3 id="Ortografia">Ortografia</h3>
+
+<p>For words with variant spellings, always use their American English spelling. In general, use the first entry at <a href="http://www.dictionary.com/">Dictionary.com</a>, 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 <a href="http://dictionary.reference.com/browse/honour">look up "honour"</a>, you find the phrase "Chiefly British" followed by a link to the American standard form, "<a href="http://dictionary.reference.com/browse/honor">honor</a>". Do not use variant spellings.</p>
+
+<ul>
+ <li><span class="correct"><strong>Correct</strong></span>: localize, honor</li>
+ <li><span class="incorrect"><strong>Incorrect</strong></span>: localise, honour</li>
+</ul>
+
+<h3 id="Terminologia">Terminologia</h3>
+
+<h4 id="Obsolete_vs._deprecated">Obsolete vs. deprecated</h4>
+
+<p>It's important to be clear about the difference between the terms <strong>obsolete</strong> and <strong>deprecated</strong>.</p>
+
+<dl>
+ <dt>Obsolete</dt>
+ <dd>On MDN, the term <strong>obsolete</strong> 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.</dd>
+ <dt>Deprecated</dt>
+ <dd>On MDN, the term <strong>deprecated</strong> 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 <em>obsolete</em> 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.</dd>
+</dl>
+
+<h4 id="Elementos_de_HTML">Elementos de HTML</h4>
+
+<p>Use "elements" to refer to HTML and XML elements, rather than "tags". In addition, they should almost always be wrapped in "&lt;&gt;", 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).</p>
+
+<ul>
+ <li><span class="correct"><strong>Correct</strong></span>: the {{HTMLElement("span")}} element</li>
+ <li><span class="incorrect"><strong>Incorrect</strong></span>: the span tag</li>
+</ul>
+
+<h4 id="Parameters_vs._arguments">Parameters vs. arguments</h4>
+
+<p>The preferred term on MDN is <strong>parameters</strong>. Please avoid the term "arguments" for consistency if at all possible.</p>
+
+<h4 id="User_interface_actions">User interface actions</h4>
+
+<p>In task sequences, describe user interface actions using the imperative mood. Identify the user interface element by its label and type.</p>
+
+<ul>
+ <li><span class="correct"><strong>Correct</strong></span>: Click the Edit button.</li>
+ <li><span class="incorrect"><strong>Incorrect</strong></span>: Click Edit.</li>
+</ul>
+
+<h3 id="Voice">Voice</h3>
+
+<p>While the active voice is preferred, the passive voice is also acceptable, given the informal feel of our content. Try to be consistent, though.</p>
+
+<h2 id="Wiki_markup_and_usage">Wiki markup and usage</h2>
+
+<h3 id="Hiperligações">Hiperligações</h3>
+
+<p>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 <a href="/en-US/docs/MDN/Contribute/Editor/Links">creating and editing links on MDN</a> in our editor guide.</p>
+
+<p>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).</p>
+
+<p>There are two ways to create links: you explicitly create a link using the Link button in the editor's toolbar—or by pressing <kbd>Ctrl</kbd>+<kbd>K</kbd> (<kbd>Cmd</kbd>-<kbd>K</kbd> on the Mac)—or you can use MDN's powerful macro system to generate links automatically or based on an input value.</p>
+
+<p>When deciding what text to use as a link, there are a few guidelines you can follow:</p>
+
+<ul>
+ <li>Whenever a macro exists which will create the link you need, and you are able to do so, please do. <a href="/en-US/docs/MDN/Contribute/Editor/Links#Using_link_macros">Using macros to create links</a> will not only help you get it right, but will allow future improvements to MDN to automatically be applied to your link.</li>
+ <li>For an API name, use the entire string of the API term as written in your content. The easiest way to do this is to <a href="/en-US/docs/MDN/Contribute/Editor/Links#Linking_to_documentation_for_APIs">use the appropriate macro</a> to construct a properly-formatted link for you.</li>
+ <li>For a term for which you're linking to a page defining or discussing that term, use the name of the term and no additional text as the link's text. For example:
+  <ul>
+   <li><span class="correct"><strong>Correct</strong></span>: You can use <a href="/en-US/docs/Web/JavaScript">JavaScript</a> code to create dynamic applications on the Web.</li>
+   <li><span class="incorrect"><strong>Incorrect</strong></span>: You can use <a href="/en-US/docs/Web/JavaScript">JavaScript code</a> to create dynamic applications on the Web.</li>
+  </ul>
+ </li>
+ <li>Otherwise, when adding a useful link to prose, try to choose an action and object phrase, such as:
+  <ul>
+   <li><span class="correct"><strong>Correct</strong></span>: If you'd like to <a href="/en-US/docs/Mozilla/Developer_guide">contribute to the Firefox project</a>, your first step is to <a href="/en-US/docs/Mozilla/Developer_guide/Build_Instructions">download and build Firefox</a>.</li>
+   <li><span class="incorrect"><strong>Incorrect</strong></span>: <a href="/en-US/docs/Mozilla/Developer_guide">If you'd like to contribute to the Firefox project</a>, your first step is to <a href="/en-US/docs/Mozilla/Developer_guide/Build_Instructions">download and build</a> Firefox.</li>
+  </ul>
+ </li>
+</ul>
+
+<h4 id="Esquemas_de_URL">Esquemas de URL</h4>
+
+<p>For security reasons, you should only create links that use the following schemes:</p>
+
+<ul>
+ <li><code>http://</code></li>
+ <li><code>https://</code></li>
+ <li><code>ftp://</code></li>
+ <li><code>mailto:</code></li>
+</ul>
+
+<p>Others may or may not work, but are not supported and will probably be removed by editorial staff.</p>
+
+<div class="note">
+<p>In particular, be sure not to use the <code>about:</code> or <code>chrome://</code> schemes, as they will not work. Similarly, the <code>javascript:</code> scheme is blocked by most modern browsers, as is <code>jar:</code>.</p>
+</div>
+
+<h3 id="Etiquetas_de_página">Etiquetas de página</h3>
+
+<p>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 <a href="/en-US/docs/MDN/Contribute/Howto/Tag">How to properly tag pages</a> guide.</p>
+
+<p>The tagging interface lives at the bottom of a page while you're in edit mode, and looks something like this:</p>
+
+<p><img alt="Screenshot of the UX for adding and removing tags on MDN" src="https://mdn.mozillademos.org/files/7859/tag-interface.png" style="border-style: solid; border-width: 1px; height: 167px; width: 863px;"></p>
+
+<p>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.</p>
+
+<p>To remove a tag, just click the little "X" icon in the tag.</p>
+
+<h4 id="Tagging_pages_that_need_work">Tagging pages that need work</h4>
+
+<p>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.</p>
+
+<h4 id="Tagging_obsolete_pages">Tagging obsolete pages</h4>
+
+<p>Use the following tags for pages that are not current:</p>
+
+<ul>
+ <li><em>Junk</em>: Use for spam, pages created by mistake, or content that is so bad that it should be deleted. Pages with this tag are deleted from time to time.</li>
+ <li><em>Obsolete</em>: Use for content that is technically superseded, but still valid in context. For example an HTML element that is obsolete in HTML5 is still valid in HTML 4.01. You can also use the <span class="nowiki">{{TemplateLink("obsolete_header")}}</span> macro to put a prominent banner on the topic.</li>
+ <li><em>Archive</em>: Use for content that is technically superseded and no longer useful. If possible, add a note to the topic referring readers to a more current topic. For example, a page that describes how to use the Mozilla CVS repository should refer readers to a current topic on using Mercurial repos. (If no corresponding current topic exists, use the <em>NeedsUpdate</em> tag, and add an explanation on the Talk page.) Pages with the Archive tag are eventually moved from the main content of MDN to the <a href="/en-US/docs/Archive">Archive</a> section.</li>
+</ul>
+
+<h3 id="Resumo_SEO">Resumo SEO</h3>
+
+<p>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.</p>
+
+<p>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 <a href="/en-US/docs/Project:MDN/Contributing/Editor_guide/Editing#Formatting_styles">"SEO summary" style in the WYSIWYG editor</a>.</p>
+
+<h3 id="Landing_pages">Landing pages</h3>
+
+<p><strong>Landing pages</strong> are pages at the root of a topic area of the site, such as the main <a href="/en-US/docs/CSS" title="CSS">CSS</a> or <a href="/en-US/docs/HTML" title="HTML">HTML</a> pages. They have a standard format that consists of three areas:</p>
+
+<ol>
+ <li>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.</li>
+ <li>A two-column list of links with appropriate headings. See {{anch("Creating a page link list")}} for guidelines.</li>
+ <li>An <strong>optional</strong> "Browser compatibility" section at the bottom of the page.</li>
+</ol>
+
+<h4 id="Creating_a_page_link_list">Creating a page link list</h4>
+
+<p>The link list section of an MDN landing page consists of two columns. These are created using the following HTML:</p>
+
+<pre class="brush: html notranslate">&lt;div class="row topicpage-table"&gt;
+  &lt;div class="section"&gt;
+    ... left column contents ...
+  &lt;/div&gt;
+  &lt;div class="section"&gt;
+    ... right column contents ...
+  &lt;/div&gt;
+&lt;/div&gt;</pre>
+
+<p>The left column should be a list of articles, with an <code>&lt;h2&gt;</code> 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 <code>&lt;dl&gt;</code> list of articles with each article's link in a <code>&lt;dt&gt;</code> block and a brief one-or-two sentence summary of the article in the corresponding <code>&lt;dd&gt;</code> block.</p>
+
+<p>The right column should contain one or more of the following sections, in order:</p>
+
+<dl>
+ <dt>Getting help from the community</dt>
+ <dd>This should provide information on Matrix chat rooms and mailing lists available on the topic. The heading should use the class "Community".</dd>
+ <dt>Tools</dt>
+ <dd>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".</dd>
+ <dt>Related topics</dt>
+ <dd>A list of links to landing pages for other, related, technologies of relevance. The heading should use the class "Related_Topics".</dd>
+</dl>
+
+<p><strong>&lt;&lt;&lt;finish this once we finalize the landing page standards&gt;&gt;&gt;</strong></p>
+
+<h2 id="Utilização_inserção_de_imagens">Utilização, inserção de imagens</h2>
+
+<p>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:</p>
+
+<ol>
+ <li>Attach the desired image file to the article (at the bottom of every article in edit mode)</li>
+ <li>Create an image in the WYSIWYG editor</li>
+ <li>In the WYSIWYG editor, in the drop-down list of attachments, select the newly created attachment that is your image</li>
+ <li>Press OK.</li>
+</ol>
+
+<h2 id="Outras_referências">Outras referências</h2>
+
+<h3 id="Preferred_style_guides">Preferred style guides</h3>
+
+<p>If you have questions about usage and style not covered here, we recommend referring to the <a href="http://www.economist.com/styleguide/introduction">Economist style guide</a> or, failing that, the <a href="https://www.amazon.com/Chicago-Manual-Style-16th/dp/0226104206">Chicago Manual of Style</a>.</p>
+
+<h3 id="Preferred_dictionary">Preferred dictionary</h3>
+
+<p>For questions of spelling, please refer to <a href="http://www.dictionary.com/">Dictionary.com</a>. The spelling checker for this site uses American English. Please do not use variant spellings (e.g., use <em>color</em> rather than <em>colour</em>).</p>
+
+<p>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 <a href="/en-US/docs/Project:Community" title="Project:en/Community">MDC mailing list</a> or <a href="/User:Sheppy" title="User:Sheppy">project lead</a> so we know what should be added.</p>
+
+<h3 id="Específico_da_MDN">Específico da MDN</h3>
+
+<ul>
+ <li><a href="/en-US/docs/MDN/Contribute/Structures/Macros/Commonly-used_macros" title="Project:en/Custom_Templates">Commonly-used macros</a> on MDN, with explanations.</li>
+</ul>
+
+<h3 id="Idioma_gramática_ortografia">Idioma, gramática, ortografia</h3>
+
+<p>If you're interested in improving your writing and editing skills, you may find the following resources to be helpful.</p>
+
+<ul>
+ <li><a href="http://www.amazon.com/Writing-Well-30th-Anniversary-Nonfiction/dp/0060891548">On Writing Well</a>, by William Zinsser (Amazon link)</li>
+ <li><a href="http://www.amazon.com/Style-Basics-Clarity-Grace-4th/dp/0205830765/" title="http://www.amazon.com/Style-Lessons-Clarity-Grace-Edition/dp/0321898680">Style: The Basics of Clarity and Grace</a>, by Joseph Williams and Gregory Colomb (Amazon link)</li>
+ <li><a href="https://brians.wsu.edu/common-errors-in-english-usage/">Common Errors in English</a></li>
+ <li><a href="http://www-personal.umich.edu/~jlawler/aue.html">English Grammar FAQ</a> (alt.usage.english)</li>
+ <li><a href="http://www.angryflower.com/bobsqu.gif">Bob's quick guide to the apostrophe, you idiots</a> (funny)</li>
+ <li><a href="http://www.amazon.com/Merriam-Websters-Concise-Dictionary-English-Usage/dp/B004L2KNI2" title="http://www.amazon.com/Merriam-Websters-Concise-Dictionary-English-Usage/dp/B004L2KNI2">Merriam-Webster's Concise Dictionary of English Usage</a> (Amazon link): Scholarly but user-friendly, evidence-based advice; very good for non-native speakers, especially for preposition usage.</li>
+ <li><a href="http://english.stackexchange.com/">English Language and Usage StackExchange</a>: Question and answer site for English language usage.</li>
+</ul>
diff --git a/files/pt-pt/mdn/guidelines/index.html b/files/pt-pt/mdn/guidelines/index.html
new file mode 100644
index 0000000000..e4e220f1f4
--- /dev/null
+++ b/files/pt-pt/mdn/guidelines/index.html
@@ -0,0 +1,10 @@
+---
+title: Linhas Diretrizes
+slug: MDN/Guidelines
+translation_of: MDN/Guidelines
+---
+<div>{{MDNSidebar}}</div><div>{{IncludeSubnav("/pt-PT/docs/MDN")}}</div>
+
+<p><span class="seoSummary">Estas </span>linhas diretrizes <span class="seoSummary">proporcionam detalhes em como é que a documentação da MDN deverá ser escrita e formatada, bem como, é que deverá ser apresentado as nossas amostras de código e outro conteúdo.</span> Ao seguir esta orientação, pode certificar-se de que o material que produz é simples e fácil de utilziar.</p>
+
+<p>{{LandingPageListSubpages}}</p>
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
new file mode 100644
index 0000000000..429ffa389f
--- /dev/null
+++ b/files/pt-pt/mdn/guidelines/isto_pertence_a_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
+---
+<div>{{MDNSidebar}}</div>
+
+<div>{{IncludeSubnav("/pt-PT/docs/MDN")}}</div>
+
+<p><span class="seoSummary">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</span>.</p>
+
+<h2 id="A_questão">A questão</h2>
+
+<p>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 <a href="https://wiki.mozilla.org/">Mozilla wiki</a>, 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.</p>
+
+<p>The two main considerations for whether a document belongs on MDN are:</p>
+
+<ul>
+ <li>The topic of the document (what is it about?)</li>
+ <li>The nature of the document (what kind of document is it?)</li>
+</ul>
+
+<p>Be aware that all contributions to MDN fall under specific open source licenses; these are <a href="https://developer.mozilla.org/en-US/docs/MDN/About#Copyrights_and_licenses">described in detail</a> on our <a href="/en-US/docs/MDN/About">About MDN</a> page.</p>
+
+<div class="note">
+<p><strong>Nota</strong>: Keep in mind that Mozilla's <a href="https://www.mozilla.org/en-US/about/legal/terms/mozilla/">Websites &amp; Communications Terms of Use</a> 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.</p>
+</div>
+
+<h2 id="Que_tópicos_pertencem_aos_MDN_Web_Docs">Que tópicos pertencem aos MDN Web Docs?</h2>
+
+<p>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.</p>
+
+<p>The primary focus is on front-end web technologies:</p>
+
+<ul>
+ <li><a href="/en-US/docs/Web/HTML" title="HTML">HTML</a></li>
+ <li><a href="/en-US/docs/Web/CSS" title="CSS">CSS</a></li>
+ <li><a href="/en-US/docs/Web/JavaScript" title="en/JavaScript">JavaScript</a></li>
+ <li><a href="/en-US/docs/Web/SVG" title="SVG">SVG</a></li>
+ <li><a href="/en-US/docs/Web/API">Web APIs</a></li>
+ <li><a href="/en-US/docs/Web/API/WebGL_API" title="WebGL">WebGL</a></li>
+ <li>etc.</li>
+</ul>
+
+<div class="note">
+<p><strong>Nota</strong>: Back-end technologies usually have their own documentation elsewhere that MDN does not attempt to supercede, although we <a href="https://developer.mozilla.org/en-US/docs/Learn/Server-side">do have some exceptions</a>.</p>
+</div>
+
+<p>Also welcome are topics that cut across technologies but are relevant to Web development, such as:</p>
+
+<ul>
+ <li><a href="/en-US/docs/Web/Accessibility" title="Accessibility">Accessibility</a></li>
+ <li><a href="/en-US/docs/AJAX">AJAX</a></li>
+ <li><a href="/en-US/docs/Web/Guide/Graphics">Web graphics</a></li>
+ <li><a href="/en-US/docs/Apps">Open web apps</a></li>
+ <li><a href="/en-US/Apps/Tutorials/Games">Web-based games</a></li>
+</ul>
+
+<div class="note">
+<p><strong>Nota:</strong> 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.</p>
+</div>
+
+<h2 id="Que_tópicos_não_pertencem_aos_MDN_Web_Docs">Que tópicos não pertencem aos MDN Web Docs?</h2>
+
+<p>In general, anything that isn't an open web standard does not belong on MDN. The below sections provide more specifics.</p>
+
+<h3 id="Produtos_da_Mozilla">Produtos da Mozilla</h3>
+
+<p>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.</p>
+
+<p>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 <a href="https://wiki.mozilla.org/Engagement/MDN_Durable_Team">MDN staff team</a> to discuss possible avenues for documenting your product. Also, see the section on <a href="#Cases_for_documenting_elsewhere">Cases for documenting elsewhere</a>, below.</p>
+
+<ul>
+ <li><a href="en-US/docs/Firefox">Firefox browser</a>
+
+  <ul>
+   <li><a href="/en-US/docs/Tools">Firefox Developer Tools</a></li>
+   <li><a href="/en-US/docs/Mozilla/Add-ons">Add-ons</a></li>
+   <li><a href="en-US/docs/Mozilla/Developer_guide/Build_Instructions">Building and configuring Firefox</a></li>
+   <li>etc.</li>
+  </ul>
+ </li>
+ <li><a href="/en-US/docs/Mozilla">The Mozilla platform</a>
+  <ul>
+   <li><a href="/en-US/docs/Mozilla/Gecko">Gecko</a></li>
+   <li><a href="/en-US/docs/Mozilla/Projects/SpiderMonkey">SpiderMonkey</a></li>
+   <li>etc.</li>
+  </ul>
+ </li>
+</ul>
+
+<h3 id="E_que_mais">E que mais?</h3>
+
+<p>Other examples of inappropriate topics for MDN Web Docs:</p>
+
+<ul>
+ <li>Technology that is not exposed to the Web and is specific to a non-Mozilla browser.</li>
+ <li>Technology that is not related to the Web or Mozilla products.</li>
+ <li>Documentation for end-users; for Mozilla products, such documentation belongs on the <a href="https://support.mozilla.org">Mozilla support site</a>.</li>
+</ul>
+
+<h2 id="Que_tipos_de_documentos_pertencem_à_MDN">Que tipos de documentos pertencem à MDN?</h2>
+
+<p>In general, MDN is for <em>product</em> documentation, not for <em>project</em> or <em>process</em> documentation (except <a href="/en-US/docs/MDN">about MDN itself</a>). 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 <a href="https://wiki.mozilla.org/Main_Page">Mozilla project wiki</a> may be a good place for it.</p>
+
+<p>Here are some examples of types of documents that should <em>not</em> be placed on MDN<strong>:</strong></p>
+
+<ul>
+ <li>Planning documents</li>
+ <li>Design documents</li>
+ <li>Project proposals</li>
+ <li>Specifications or standards</li>
+ <li>Promotional material, advertising, or personal information{{ref("*")}}</li>
+</ul>
+
+<h2 id="Vantagens_para_documentar_na_MDN">Vantagens para documentar na MDN</h2>
+
+<p>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.</p>
+
+<h3 id="Muitos_escritores_e_tradutores">Muitos escritores e tradutores</h3>
+
+<p>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:</p>
+
+<ul>
+ <li>We have a paid staff of writers whose <strong>mission</strong> is to make sure that our content is as good as possible.</li>
+ <li>We have a core community of volunteers who contribute substantial amounts of content and can help you.</li>
+ <li>The MDN team can work with you to ensure that your documentation project is adequately staffed.</li>
+ <li>The broader MDN community also contributes enormously, from typo fixes to editorial reviews of your content.</li>
+ <li>The <a href="https://chat.mozilla.org/#/room/#mdn:mozilla.org">MDN Web Docs chat room</a> offers a resource where you can talk to our writing community and get their advice, or recruit help with the production of or maintenance of your content.</li>
+ <li>Because we have contributors all over the world, there's always someone around, watching for problems and fixing them.</li>
+ <li>Our community of volunteers includes translators for many languages, who can help localize your documentation.</li>
+</ul>
+
+<p>Do you want your development team to be entirely responsible for the production of documentation? That's likely if your documentation is maintained elsewhere.</p>
+
+<h3 id="Manutenção">Manutenção</h3>
+
+<p>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:</p>
+
+<dl>
+ <dt>Delete spam</dt>
+ <dd>Spam happens. We deal with it.</dd>
+ <dt>Copy editing</dt>
+ <dd>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.</dd>
+ <dt>Consistency of style</dt>
+ <dd>We'll ensure that your content is stylistically consistent not just within itself, but with the other documentation around it.</dd>
+ <dt>Content management</dt>
+ <dd>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.</dd>
+ <dt>Site and platform maintenance</dt>
+ <dd>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.</dd>
+</dl>
+
+<h2 id="Casos_para_documentação_em_qualquer_outra_parte">Casos para documentação em qualquer outra parte</h2>
+
+<p>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.</p>
+
+<h3 id="Planos_e_processos">Planos e processos</h3>
+
+<p>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 <a href="https://wiki.mozilla.org/Main_Page">Mozilla project wiki</a>.</p>
+
+<h3 id="O_projeto_está_no_GitHub">O projeto está no GitHub</h3>
+
+<p>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:</p>
+
+<ul>
+ <li>The MDN Web Docs team will probably not be able to help you. We don't generally participate in documentation work off MDN Web Docs; there are exceptions but they are exceptionally rare.</li>
+ <li>Cross-linking your documentation with other relevant materials may be difficult or impossible.</li>
+ <li>The content will not have consistent style with other documentation.</li>
+ <li>Your documentation loses discoverability by not being among other (Web or Mozilla) documentation.</li>
+</ul>
+
+<p>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.</p>
+
+<h3 id="Quer_manter_os_documentos_na_fonte">Quer manter os documentos na fonte</h3>
+
+<p>Some teams like to have their documentation in the source tree. This is particularly common with project internals and library projects.</p>
+
+<p>This approach has a couple of advantages:</p>
+
+<ul>
+ <li>It lets the developers document their technology as they code it, helping to ensure that the docs stay up to date with the code.</li>
+ <li>Docs can be subject to the same development and release processes as the code, including versioning.</li>
+</ul>
+
+<p>There are some drawbacks:</p>
+
+<ul>
+ <li>The MDN Web Docs team can't help you; even if the code is within Mozilla's source repository, the system of reviews and check-ins make it impractical for the docs team to participate.</li>
+ <li>You don't have easy tools for cross-linking with other relevant documentation. Cross-linking provides both context and additional important information to your readers.</li>
+ <li>Your documentation loses discoverability by not being among other documentation.</li>
+ <li>Even if you use conversion tools (like JavaDoc) to create Web-readable documentation, it won't be as attractive as what we can do on MDN Web Docs.</li>
+</ul>
+
+<p>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.</p>
+
+<p>{{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 <em>do not </em>use your profile to upload personal photos or other irrelevant files.</p>