unslug pt-pt: move

4 files changed, 0 insertions, 329 deletions

diff --git a/files/pt-pt/mdn/structures/api_references/barras_laterais_de_referencia_da_api/index.html b/files/pt-pt/mdn/structures/api_references/barras_laterais_de_referencia_da_api/index.html
deleted file mode 100644
index 8e28e33556..0000000000
--- a/files/pt-pt/mdn/structures/api_references/barras_laterais_de_referencia_da_api/index.html
+++ /dev/null
@@ -1,109 +0,0 @@
----
-title: Barras laterais de referência da API
-slug: MDN/Structures/API_references/Barras_laterais_de_referencia_da_API
-tags:
-  - API
-  - Guía
-  - Referencia
-  - barras laterais
-  - groupdata
-  - onboarding
-translation_of: MDN/Structures/API_references/API_reference_sidebars
----
-<div>{{MDNSidebar}}</div><p class="summary">Pode incluir uma barra lateral personalizada nas páginas de referência da API para exibir as hiperligações para as 'Interfaces' relacionadas, tutoriais, e outros recursos relevantes, apenas para essa API. Este artigo explica como.</p>
-
-<h2 id="O_que_precisa_de_fazer">O que precisa de fazer?</h2>
-
-<p>You need to take the following three steps to create your API sidebar:</p>
-
-<ol>
- <li>Create your API reference pages.</li>
- <li>Add an entry for your particular API into the <a href="https://github.com/mdn/kumascript">KumaScript repo</a>'s GroupData.json data file.</li>
- <li>Use the \{{APIRef}} macro to insert the sidebar into each page you want to display it on.</li>
-</ol>
-
-<p>Let's run through each of these steps in turn. The example we'll refer to in this article is the <a href="/en-US/docs/Web/API/Fetch_API">Fetch API</a>.</p>
-
-<h3 id="Criar_páginas_de_referência_da_sua_API">Criar páginas de referência da sua API</h3>
-
-<p>Before you can add sidebars to your pages, you'll need to create the pages themselves (see our <a href="/en-US/docs/MDN/Contribute/Structures/API_references/What_does_an_API_reference_need">What does an API reference need?</a> guide for more guidance).</p>
-
-<h3 id="Adicionar_uma_entrada_para_GroupData.json">Adicionar uma entrada para GroupData.json</h3>
-
-<p>The <a href="https://github.com/mdn/kumascript/blob/master/macros/GroupData.json">GroupData.json</a> file holds all the data relating to what links should appear in API reference sidebars. When invoked, the \{{APIRef}} macro takes an API name given to it as a parameter, looks up that name in GroupData.json, builds a sidebar as appropriate, and inserts it in the page.</p>
-
-<p>To add an entry to GroupData.json, you need to:</p>
-
-<ol>
- <li>Make sure you have a <a href="https://github.com/">GitHub</a> account.</li>
- <li>Fork the KumaScript repo, create a new branch to contain your changes, and clone the repo locally.</li>
- <li>Checkout your new branch before starting work, and make sure you push changes to it after finishing.</li>
- <li>Create a pull request so that the MDN team can review your work, and ask for changes if necessary.</li>
-</ol>
-
-<p>If you need help with using GitHub, a more detailed guide can be found at our <a href="/en-US/docs/MDN/Contribute/Structures/Compatibility_tables#The_new_way_The_browser_compat_data_repo_and_dynamic_tables">compatibility tables guide</a>.</p>
-
-<p>The <a href="https://github.com/mdn/kumascript/blob/master/macros/GroupData.json">GroupData.json</a> file can be found inside the macros directory of the KumaScript repo. Looking at it, you'll see a giant JSON structure, with each API having its own member. The name is the API name, and the value is an object containing several submembers defining the sidebar links to be created.</p>
-
-<p>For example, look at the <a href="/en-US/docs/Web/API/Fetch_API">Fetch API</a> page on MDN. The corresponding entry in GroupData.json looks like this:</p>
-
-<pre class="brush: json notranslate">"Fetch API": {
-    "overview":   [ "Fetch API"],
-    "interfaces": [ "Body",
-                    "Headers",
-                    "Request",
-                    "Response",
-                    "FetchController",
-                    "FetchObserver",
-                    "FetchSignal",
-                    "ObserverCallback" ],
-    "methods":    [ "WindowOrWorkerGlobalScope.fetch()" ],
-    "properties": [],
-    "events":     []
-},</pre>
-
-<p>As you can see, we've used "Fetch API" for the name, and inside the object value we include a number of submembers.</p>
-
-<h4 id="Submembers_to_include_inside_a_GroupData_entry">Submembers to include inside a GroupData entry</h4>
-
-<p>This section lists all the submembers you could include in a GroupData entry.</p>
-
-<p>Note that Most of the values included inside the listed submembers equate to both the link text, and slugs appended to the end of the main API index page —  https://developer.mozilla.org/<em>&lt;language-code&gt;</em>/docs/Web/API — to create the final URL for the displayed link. So for example, "Body" will result in a link being created like so in the <em>en-US</em> locale:</p>
-
-<pre class="brush: html notranslate">&lt;li&gt;&lt;a href="https://developer.mozilla.org/en-US/docs/Web/API"&gt;Body&lt;/a&gt;&lt;/li&gt;</pre>
-
-<p>There are a few exceptions. For example the "guides" submember contains one or more sets of link information (title and slug) that defines links to associated guides/tutorials. In this case the slugs are appended to the end of the MDN docs root — https://developer.mozilla.org/<em>&lt;language-code&gt;</em>/docs — allowing an article anywhere on MDN to be included.</p>
-
-<p>Here are the available members. In each case, an example is included that assumes that the local is <em>en-US</em>.</p>
-
-<ol>
- <li>
-  <p>"overview" — the value is an array, inside of which you include the slug of the API overview page, if there is one. "Fetch API" results in a link being made to <a href="/en-US/docs/Web/API/Fetch_API">https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API</a>.</p>
- </li>
- <li>
-  <p>"interfaces" — the value is an array in which you should list all of the interfaces that form part of that API. "Body" results in a link being made to <a href="/en-US/docs/Web/API/Body">https://developer.mozilla.org/en-US/docs/Web/API/Body</a>.</p>
- </li>
- <li>
-  <p>"methods" — the value is an array that should contain all of the methods associated with the API. This can include methods that are members of interfaces defined in the API spec, and methods the API defines on other interfaces. If there are a huge number of methods, you might want to consider only listing the most popular ones, or putting them first in the list. "WindowOrWorkerGlobalScope.fetch()" results in a link being made to <a href="/en-US/docs/Web/API/WindowOrWorkerGlobalScope/fetch">https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/fetch</a>.</p>
- </li>
- <li>
-  <p>"properties" — the value is an array that should contain all of the properties associated with the API. This can include properties that are members of interfaces defined in the API spec, and properties the API defines on other interfaces. If there are a huge number of properties, you might want to consider only listing the most popular ones, or putting them first in the list. "Headers.append" results in a link being made to <a href="/en-US/docs/Web/API/Headers/append">https://developer.mozilla.org/en-US/docs/Web/API/Headers/append</a>.</p>
- </li>
- <li>
-  <p>"events" — the value is an array that should contain all of the events associated with the API, defined in the API spec, or elsewhere. If there are a huge number of events, you might want to consider only listing the most popular ones, or putting them first in the list. "animationstart" results in a link being made to <a href="/en-US/docs/Web/Events/animationstart">https://developer.mozilla.org/en-US/docs/Web/Events/animationstart</a>.</p>
- </li>
- <li>
-  <p>"guides" — the value is an array containing one or more objects that define links to guides explain how to use the API. Each object contains two submembers — "url", which contains the partial URL pointing to the guide article, and "title", which defines the link test for the link. As an example, the following object:</p>
-
-  <pre class="brush: json notranslate">{ "url":   "/docs/Web/API/Detecting_device_orientation",
-"title": "Detecting device orientation" }</pre>
-
-  <p>Creates a link with the title "Detecting device orientation", which points to <a href="/en-US/docs/Web/API/Detecting_device_orientation">https://developer.mozilla.org/en-US/docs/Web/API/Detecting_device_orientation</a>.</p>
- </li>
-</ol>
-
-<h3 id="Inserir_a_barra_lateral_nas_suas_páginas">Inserir a barra lateral nas suas páginas</h3>
-
-<p>Once you've added an entry for your API into GroupData.json, submitted it as a pull request and had the change accepted into the main repo, you can include it in your API reference pages using the \{{APIRef}} macro, which takes the name you used for your API in GroupData as a parameter. As an example, the <a href="/en-US/docs/Web/API/WebVR_API">WebVR API</a>'s sidebar is included in its pages with the following:</p>
-
-<p>\{{APIRef("WebVR API")}}</p>
diff --git a/files/pt-pt/mdn/structures/api_references/index.html b/files/pt-pt/mdn/structures/api_references/index.html
deleted file mode 100644
index a7a7b21004..0000000000
--- a/files/pt-pt/mdn/structures/api_references/index.html
+++ /dev/null
@@ -1,58 +0,0 @@
----
-title: API references
-slug: MDN/Structures/API_references
-tags:
-  - API
-  - Contribute
-  - Guide
-  - NeedsTranslation
-  - Reference
-  - TopicStub
-translation_of: MDN/Structures/API_references
----
-<div>{{MDNSidebar}}</div><div>{{IncludeSubnav("/en-US/docs/MDN")}}</div>
-
-<p class="summary">Client-side JavaScript APIs form a large part of the technology available on the web, and MDN includes extensive reference material to explain what functionality is available in these APIs, and how to use it. In this set of guides we explain how to create API reference material on MDN.</p>
-
-<h2 id="Prerequisite_resources">Prerequisite resources</h2>
-
-<p>Before starting to document an API, you should have available:</p>
-
-<ol>
- <li>The latest spec: Whether it is a W3C Recommendation or an early  editor's draft, you should refer to the latest available draft of the  spec that covers (or specs that cover) that API. To find it, you can usually do a Web search. The latest  version will often be linked to from all versions of the spec, listed under "latest draft" or similar.</li>
- <li>The latest modern web browsers: These should be experimental/alpha builds such as <a href="https://nightly.mozilla.org/">Firefox Nightly</a>/<a href="https://www.google.com/intl/en/chrome/browser/canary.html">Chrome Canary</a> that are more likely to support the features you are documenting. This is especially pertinent if you are documenting a nascent/experimental API.</li>
- <li>Demos/blog posts/other info: Find as much info as you can. It is useful to start by spending time familiarizing yourself with how the API works — learn what the main interfaces/properties/methods are, what the primary use cases are, and how to write simple functionality with it.</li>
- <li>Useful engineering contacts: It is really useful to find yourself a friendly engineering contact to ask questions about the spec, someone who is involved in the standardization of the API, or its implementation in a browser. Good places to find them are:
-  <ul>
-   <li>Your internal company address book, if you work for a relevant company.</li>
-   <li>A public mailing list that is involved in the discussion of that API,  such as Mozilla's <a href="https://lists.mozilla.org/listinfo/dev-platform">dev-platform</a> or <a href="https://lists.mozilla.org/listinfo/dev-webapi">dev-webapi</a> lists, or a W3C list like <a href="https://lists.w3.org/Archives/Public/public-webapps/">public-webapps</a>.</li>
-   <li>The spec itself. For example, the <a href="https://webaudio.github.io/web-audio-api/">Web Audio API spec</a> lists the authors and their contact details at the top.</li>
-  </ul>
- </li>
-</ol>
-
-<h2 id="High_level_structure">High level structure</h2>
-
-<dl>
- <dt><a href="/en-US/docs/MDN/Contribute/Structures/API_references/What_does_an_API_reference_need">What does an API reference need?</a></dt>
- <dd>This article explains what pages are required for a complete API reference.</dd>
- <dt><a href="/en-US/docs/MDN/Contribute/Structures/Page_types">Page types</a></dt>
- <dd>There are a number of types of pages that are used repeatedly on MDN. This article describes these page types, their purpose, and gives examples of each and templates to use when creating a new page.</dd>
-</dl>
-
-<h2 id="Individual_page_features">Individual page features</h2>
-
-<p>These articles explain how to create the individual page features required for API reference pages.</p>
-
-<dl>
- <dt><a href="/en-US/docs/MDN/Contribute/Structures/API_references/API_reference_sidebars">API reference sidebars</a></dt>
- <dd>When including a sidebar on your MDN API reference articles, you are able to customize it so that it displays links to related Interfaces, tutorials, and other resources relevant just to that API. This article explains how.</dd>
- <dt><a href="/en-US/docs/MDN/Contribute/Structures/Syntax_sections">Syntax sections</a></dt>
- <dd>The syntax section of an MDN reference page contains a syntax box defining the exact syntax that a feature has (e.g. what parameters can it accept, which ones are optional?) This article explains how to write syntax boxes for refererence articles.</dd>
- <dt><a href="/en-US/docs/MDN/Contribute/Structures/Code_examples">Code examples</a></dt>
- <dd>On MDN, you'll see numerous code examples inserted throughout the pages to demonstrate usage of web platform features. This article discusses the different mechanisms available for adding code examples to pages, along with which ones you should use and when.</dd>
- <dt><a href="/en-US/docs/MDN/Contribute/Structures/Specification_tables">Specification tables</a></dt>
- <dd>Every reference page on MDN should provide information about the specification or specifications in which that API or technology was defined. This article demonstrates what these tables look like and explains how to construct them.</dd>
- <dt><a href="/en-US/docs/MDN/Contribute/Structures/Compatibility_tables">Compatibility tables</a></dt>
- <dd>MDN has a standard format for compatibility tables for our open web documentation; that is, documentation of technologies such as the DOM, HTML, CSS, JavaScript, SVG, and so forth, that are shared across all browsers. This article covers how to use our features to add compatibility data to MDN pages.</dd>
-</dl>
diff --git a/files/pt-pt/mdn/structures/api_references/o_que_e_que_uma_referencia_de_api_precisa/index.html b/files/pt-pt/mdn/structures/api_references/o_que_e_que_uma_referencia_de_api_precisa/index.html
deleted file mode 100644
index 986791e813..0000000000
--- a/files/pt-pt/mdn/structures/api_references/o_que_e_que_uma_referencia_de_api_precisa/index.html
+++ /dev/null
@@ -1,162 +0,0 @@
----
-title: O que é que uma referência de API precisa?
-slug: MDN/Structures/API_references/O_que_e_que_uma_referencia_de_API_precisa
-translation_of: MDN/Structures/API_references/What_does_an_API_reference_need
----
-<div>{{MDNSidebar}}</div><p class="summary">Este artigo explica quais as páginas que são necessárias para uma referência completa da API .</p>
-
-<div class="note">
-<p><strong>Nota</strong>: It is a good idea to create the list of documents you need to write or update when you are working on an API reference, then check them off as you complete them.</p>
-</div>
-
-<h2 id="API_pages_at_a_glance">API pages at a glance</h2>
-
-<p>An API reference will generally contain the following pages. You can find more details of what each page contains, examples, and templates, in our <a href="/en-US/docs/MDN/Contribute/Structures/Page_types">Page types</a> article.</p>
-
-<ol>
- <li>Overview page</li>
- <li>Interface pages</li>
- <li>Constructor pages</li>
- <li>Method pages</li>
- <li>Property pages (including event handlers properties)</li>
- <li>Event pages</li>
- <li>Concept/guide pages</li>
- <li>Examples</li>
-</ol>
-
-<div class="note">
-<p><strong>Nota</strong>: We'll be referring to the <a href="/en-US/docs/Web/API/Web_Audio_API">Web Audio API</a> for examples in this article.</p>
-</div>
-
-<div class="note">
-<p><strong>Nota</strong>: To create a page as specified below, the easiest way is to go to the parent page you want it to hang off, and choose <em>Cog icon &gt; New sub-article</em>. If you haven't got this option available on your MDN interface, you'll need to request this privilege (ask at <code>mdn-admins@mozilla.org</code>), or ask another MDN contributor to create them for you.</p>
-</div>
-
-<h3 id="Página_de_sinopse">Página de sinopse</h3>
-
-<p>A single API overview page is used to describe the role of the API, its top-level interfaces, related features contained in other interfaces, and other high level details. Its name and slug should be the name of the API plus "API" on the end. It is placed at the top level of the API reference, as a child of <a href="/en-US/docs/Web/API">https://developer.mozilla.org/en-US/docs/Web/API</a>.</p>
-
-<p>Example:</p>
-
-<ul>
- <li>Title: <em>Web Audio API</em></li>
- <li>Slug: <em>Web_Audio_API</em></li>
- <li>URL: <a href="https://developer.mozilla.org/en-US/docs/Web/API/Web_Audio_API">https://developer.mozilla.org/en-US/docs/Web/API/Web_Audio_API</a></li>
-</ul>
-
-<h3 id="Páginas_da_interface">Páginas da interface</h3>
-
-<p>Each interface will have its own page too, describing the purpose of the interface, listing any members (constructors, methods, properties, etc. it contains), and showing what browsers it is compatible with. A page's name and slug should be the name of the interface, exactly as written in the spec. Each page is placed at the top level of the API reference, as a child of <a href="/en-US/docs/Web/API">https://developer.mozilla.org/en-US/docs/Web/API</a>.</p>
-
-<p>Exemplos:</p>
-
-<ul>
- <li>Title: <em>AudioContext</em></li>
- <li>Slug: <em>AudioContext</em></li>
- <li>URL: <a href="https://developer.mozilla.org/en-US/docs/Web/API/AudioContext">https://developer.mozilla.org/en-US/docs/Web/API/AudioContext</a></li>
-</ul>
-
-<ul>
- <li>Title: <em>AudioNode</em></li>
- <li>Slug: <em>AudioNode</em></li>
- <li>URL: <a href="https://developer.mozilla.org/en-US/docs/Web/API/AudioNode">https://developer.mozilla.org/en-US/docs/Web/API/AudioNode</a></li>
-</ul>
-
-<div class="note">
-<p><strong>Nota:</strong> We document every member appearing in the interface. You should bear the following rules in mind:</p>
-
-<ul>
- <li>We document methods defined on the <u>prototype</u> of an object implementing this interface (instance methods), and methods defined on the actual class itself (static methods). On the rare occasions that they both exist on the same interface, you should list them in separate sections on the page (Static methods/Instance methods). Usually only instance methods exist, in which case you can put these under the title "Methods".</li>
- <li>We do not document inherited properties and methods of the interface: they are listed on the respective parent interface. We do hint at their existence though.</li>
- <li>We do document properties and methods defined in mixins, though we use the mixin name as interface name. (This is not optimal as the mixin name will not appear in the console, but it prevents the duplication of documentation. We may revisit this in the future.)</li>
- <li>Special methods like the stringfier (<code>toString()</code>) and the jsonizier (<code>toJSON()</code>) are also listed if they do exist.</li>
- <li>Named constructors (like <code>Image()</code>  for {{domxref("HTMLImageElement")}} ) are also listed, if relevant.</li>
-</ul>
-</div>
-
-<h3 id="Páginas_de_constructor">Páginas de <em>constructor</em></h3>
-
-<p>Each interface has 0 or 1 constructors, documented on a subpage of the interface's page. It describes the purpose of the constructor and shows what its syntax looks like, usage examples, browser compatibility information, etc. Its slug is the name of the constructor, which is exactly the same as the interface name, and the title is interface name, dot, constructor name, then parentheses on the end.</p>
-
-<p>Example:</p>
-
-<ul>
- <li>Title: <em>AudioContext.AudioContext()</em></li>
- <li>Slug: <em>AudioContext</em></li>
- <li>URL: <a href="https://developer.mozilla.org/en-US/docs/Web/API/AudioContext/AudioContext">https://developer.mozilla.org/en-US/docs/Web/API/AudioContext/AudioContext</a></li>
-</ul>
-
-<h3 id="Páginas_de_propriedade">Páginas de propriedade</h3>
-
-<p>Each interface has zero or more properties, documented on subpages of the interface's page. each page describes the purpose of the property and shows what its syntax looks like, usage examples, browser compatibility information, etc. Its slug is the name of the property, and the title is interface name, dot, then property name.</p>
-
-<p>Examples:</p>
-
-<ul>
- <li>Title: <em>AudioContext.state</em></li>
- <li>Slug: <em>state</em></li>
- <li>URL: <a href="/en-US/docs/Web/API/AudioContext/state">https://developer.mozilla.org/en-US/docs/Web/API/AudioContext/state</a></li>
-</ul>
-
-<ul>
- <li>Title: <em>AudioContext.onstatechange</em></li>
- <li>Slug: <em>onstatechange</em></li>
- <li>URL: <a href="/en-US/docs/Web/API/AudioContext/onstatechange">https://developer.mozilla.org/en-US/docs/Web/API/AudioContext/onstatechange</a></li>
-</ul>
-
-<div class="note">
-<p><strong>Nota:</strong> Event handler properties are treated in the same way as regular properties; they are generally listed in a separate section on the interface page though.</p>
-</div>
-
-<ul>
-</ul>
-
-<h3 id="Páginas_de_método">Páginas de método</h3>
-
-<p>Each interface has zero or more methods, documented on subpages of the interface's page. each page describes the purpose of the method and shows what its syntax looks like, usage examples, browser compatibility information, etc. Its slug is the name of the method, and the title is interface name, dot, method name, then parentheses.</p>
-
-<p>Examples:</p>
-
-<ul>
- <li>Title: <em>AudioContext.close()</em></li>
- <li>Slug: <em>close</em></li>
- <li>URL: <a href="/en-US/docs/Web/API/AudioContext/close">https://developer.mozilla.org/en-US/docs/Web/API/AudioContext/close</a></li>
-</ul>
-
-<ul>
- <li>Title: <em>AudioContext.createGain()</em></li>
- <li>Slug: <em>createGain</em></li>
- <li>URL: <a href="/en-US/docs/Web/API/AudioContext/createGain">https://developer.mozilla.org/en-US/docs/Web/API/AudioContext/createGain</a></li>
-</ul>
-
-<h3 id="Páginas_de_evento">Páginas de evento</h3>
-
-<p>Each event handler property you create will have a corresponding event page, describing the event that causes the handler to fire, documented on a subpage of <a href="/en-US/docs/Web/Events">https://developer.mozilla.org/en-US/docs/Web/Events</a>. Each page describes the purpose of the event and shows what its syntax looks like, usage examples, browser compatibility information, etc. Its slug and title is the name of the event.</p>
-
-<p>Example:</p>
-
-<ul>
- <li>Title: <em>statechange</em></li>
- <li>Slug: <em>statechange</em></li>
- <li>URL: <a href="/en-US/docs/Web/Events/statechange">https://developer.mozilla.org/en-US/docs/Web/Events/statechange</a></li>
-</ul>
-
-<h3 id="Páginas_de_conceitoguia">Páginas de conceito/guia</h3>
-
-<p>Most API references have at least one guide and sometimes also a concept page to accompany it. At minimum, an API reference should contain a guide called "Using the <em>name-of-api</em>", which will provide a basic guide to how to use the API. More complex APIs may require multiple usage guides to explain how to use different aspects of the API.</p>
-
-<p>If required, you can also including a concepts article called "<em>name-of-api</em> concepts", which will provide explanation of the theory behind any concepts related to the API that developers should understand to effectively use it.</p>
-
-<p>These articles should all be created as subpages of the API overview page. For example, the Web Audio has four guides and a concept article:</p>
-
-<ul>
- <li><a href="/en-US/docs/Web/API/Web_Audio_API/Using_Web_Audio_API">https://developer.mozilla.org/en-US/docs/Web/API/Web_Audio_API/Using_Web_Audio_API</a></li>
- <li><a href="/en-US/docs/Web/API/Web_Audio_API/Visualizations_with_Web_Audio_API">https://developer.mozilla.org/en-US/docs/Web/API/Web_Audio_API/Visualizations_with_Web_Audio_API</a></li>
- <li><a href="/en-US/docs/Web/API/Web_Audio_API/Web_audio_spatialization_basics">https://developer.mozilla.org/en-US/docs/Web/API/Web_Audio_API/Web_audio_spatialization_basics</a></li>
- <li><a href="/en-US/docs/Web/API/Web_Audio_API/Porting_webkitAudioContext_code_to_standards_based_AudioContext">https://developer.mozilla.org/en-US/docs/Web/API/Web_Audio_API/Porting_webkitAudioContext_code_to_standards_based_AudioContext</a></li>
- <li><a href="/en-US/docs/Web/API/Web_Audio_API/Basic_concepts_behind_Web_Audio_API">https://developer.mozilla.org/en-US/docs/Web/API/Web_Audio_API/Basic_concepts_behind_Web_Audio_API</a></li>
-</ul>
-
-<h3 id="Exemplos">Exemplos</h3>
-
-<p>You should create some examples that demonstrate at least the most common use cases of the API. You can put these anywhere that is appropriate, although the recommended place is the <a href="https://github.com/mdn/">MDN GitHub repo</a>.</p>
diff --git a/files/pt-pt/mdn/structures/exemplos_live/index.html b/files/pt-pt/mdn/structures/live_samples/index.html
index 91295fc37c..91295fc37c 100644
--- a/files/pt-pt/mdn/structures/exemplos_live/index.html
+++ b/files/pt-pt/mdn/structures/live_samples/index.html