unslug pt-pt: move

1 files changed, 201 insertions, 0 deletions

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