docs: Removed how-to-work-on-guide-articles from 4 languages (#37573)

* Changes typos and grammar. Changes typos in Spanish on "how-to-work-on-guide-articles.md" * Removed guide articles in spanish, russian, chinese and portuguese
2019-10-31 05:15:38 -07:00
parent 7d119b67dd
commit f41b5b7371
4 changed files with 0 additions and 1006 deletions
--- a/docs/i18n-languages/chinese/how-to-work-on-guide-articles.md
+++ b/docs/i18n-languages/chinese/how-to-work-on-guide-articles.md
@ -1,264 +0,0 @@
 <!-- do not translate this -->
 | [Read these guidelines in other languages](/docs/i18n-languages) |
 |-|
 <!-- do not translate this -->
 #如何在指南文章工作
 在您的帮助下，我们可以创造将帮助成千上万人学会未来几年编码的一个全面参考工具。 💛
 您能：
 - [帮助我们通过创造和编辑指南文章](#steps为创造和编辑指南文章)。
 - [帮助回顾拉扯要求指南文章(]) ##
 步的我们为创造和编辑指南文章
 1。 🍴 [叉子这repo] (https://github.com/freeCodeCamp/freeCodeCamp#fork-destination-box)
 2。 👀️遵循如下所示的贡献的指导方针。
 3. 🔧做一些令人敬畏的变动!
 4. 📖读了这个 [样式指南为最佳的实践](/docs/style指南为指南文章)。
 5. 👉 [做拉扯请求](https://github.com/freeCodeCamp/freeCodeCamp/compare)
 6。 🎉得到您的拉扯请求被批准-成功!
 或请 [创造一个问题](https://github.com/freeCodeCamp/freeCodeCamp/issues) -任何一点帮助计数! 😊
 ### [遵循这些被推荐的指导方针从我们的样式指南为创造拉扯请求](PR)的
 一強制指南文章(/docs/style指南为指南articles.md) ###提出那里
 变动是您能提出对贮藏库的变动的二种方式，在您编辑或增加一篇指南文章之后：
 - [使用GitHub网接口在您的浏览器](#using这github网接口在你浏览器)。
 - [工作在您的地方机器](#working在你地方机器) (_recommended_为预览变动)。
 ####使用GitHub网接口在您的浏览器
 手表录影示范或在它之下跟随步：
 **[ TODO] **更新GIF录音。
 ! [显示GitHub接口的GIF跨步](#)
 1。 进入** “页” **文件夹(位于 [`客户或src或者页或者指南`](/client/src/pages/guide)) 并且发现您希望写或编辑的文章残余部分。
    > 所有残余部分在index.md文件
 2。 点击<kbd>Edit这个file</kbd>铅笔像并且做您的对文件的变动在GitHub调味的减价。
    > 如果像是greyed，并且发出您警告“您必须是在做或提出对这个文件的变动的分支”，则您是可能的在另一个人的树。 在顶面左页，有认为“树的下落下来装箱： #######". 点击下落下来并且改变分支到“大师”。 铅笔像应该现在clickable。
 3. 纸卷对底部的屏幕和增加解释您的变动的一则做消息。
    (任意) ： 我们高度推荐做常规做消息。 这是您在某些将看普遍的开放来源贮藏库的很好的练习。 作为开发商，这鼓励您跟随标准操作。
    有些例子的常规做消息是：
    ```md
    固定： 更新HTML指南文章
    固定： 更新修造剧本为TravisCI
    技艺： 增加文章为Java语言卷扬
    docs ： 更新贡献的指南
    ```
    保留这些短小，不超过50个字符。 您在做消息的描述能总增加其它信息。
    这比一则跌荡的消息象‘更新文件’或‘增加index.md’不花费另外的时间
    您能学会更多在大约 [为什么您这里如果这些](https://www.conventionalcommits.org/en/v1.0.0-beta.2/#why-use-conventional-commits)。
 4. 然后选择单选按钮选择为** “创造一个新的分支为此做并且开始拉扯请求” **并且点击<kbd>Propose文件changes</kbd>。
 5. 在下个屏幕，您能增加关于您的PR的所有其他细节，然后点击<kbd>Create拉扯request</kbd>。
 祝贺🎉! 您创造了拉扯请求。
 运作在您的地方机器(_recommended_的####为预览变动)
 没有要求您在您的地方机器工作，除非您希望预览您编辑或者与UI固定和改进一起使用。 也推荐这您是否跑入git问题象合并冲突， rebasing等等。
 #####读了这些指南关于 [怎样设定得到PR的]地方freeCodeCamp (
 /docs/how对设定freecodecamp locally.md) ###这里
 被接受是评论者遵循的几指导方针，当回顾PRs时：
 -有一个相关的描述，并且标题
 - PR尊敬 [样式指南](/docs/style指南为指南文章)
 -我们跟随在调解人指南发现的一般 [QA技巧](https://forum.freecodecamp.org/t/freecodecamp-moderator-guidelines/18295)
 -，只要拉扯请求改进或扩展指南，我们接受它，即使它包含不完美的英国或部份内容
 -更旧的拉扯请求是被回顾的第一个
 ####标签
 - **内容**是为在指南的拉扯请求(他们修改文章内容增加一篇新的文章或更新一篇现有的文章)
 - **复制品**是为有内容和一样另一开放PR -的拉扯
 请求**以前需要变动的变动请求**是为拉扯请求 得到被合并的
 - **陈旧**为拉扯请求与_ “改变没在大约2个星期以后得到活动，并且随后是闭合的请求的” _标签。
  - _stale_拉扯请求应该是闭合的。
  -这 [例子](https://github.com/freeCodeCamp/freeCodeCamp/pull/235)。
 ####相冲突或复制内容
 A PR被认为a **复制品**，如果它做对文章的变动和另一PR一样。
 一般来说，评论者将：
 1. 排序PR从最旧
 2。 查寻PRs与相似的内容
 3。 合并从最老到它是
 非常可能的那里的最新将是合并冲突与复制PRs。
 评论者将作出每一努力解决这些冲突和合并复制PRs。
 ####请求变动
 ，如果拉扯请求不是完善的，评论者可以：
 -对贡献者的请求变动和增加*changes requested*标签
 -固定较小问题并且做做在所有PRs
 必须通过Travis
 CI检查的PR #### Travis CI修造顶部，在我们可以合并它之前。
 如果PR打破修造(Travis CI支票发生故障，并且展示红色“X”)那里是三个可能的来源。
 在我们可以合并您的PR之前，您将需要修理问题：
 1. 您的PR创造一篇新的文章，并且它错过`index.md `文件某处。
    -每个文件夹在`src或页`在它(和名字需要`index.md `文件必须是`index.md `)。
    -二个可能的情景是
      除`index.md `之外， -您命名了新的文章文件某事或者
      -您创造了一个新的文件夹，然后次级文件夹，您在次级文件夹在新的文件夹2写新的文章，但忘记投入残余部分`index.md `
 2.您的PR創建一個新文件夾，文件夾名稱格式不正確。
      - 您的文件夾名稱應全部小寫並以kebab-case格式化（即my-new-folder）。
 這篇文章的頂部沒有`title`字段。
      - 請參閱下面[編寫文章的樣式指南]下的[標題]（＃title）部分（/ docs / style-guide-for-guide-articles.md）。
 ###我們何時關閉拉取請求
 我們關閉拉取請求
 - 如果同一篇文章的較舊PR合併，並且您的PR不添加新內容
 - 如果它沒有/很少的努力（例如：從維基百科等其他來源複製粘貼）
 - 如果有受版權保護的來源複製文本 - 請參閱[引用問題]（https://github.com/freeCodeCamp/freeCodeCamp/issues/2503）
 - 如果它不尊重[撰寫文章的風格指南]（/ docs / style-guide-for-guide-articles.md）
 - 如果不尊重[學術誠信政策]（https://www.freecodecamp.org/academic-honesty）
 - 如果它是陳舊的（如果要求更改並且約2週沒有活動）
 此外，如果您正在處理“存根”文章，則您的更改必須足夠大，以替換存根文本。
 我們不接受只添加“更多信息：”部分鏈接的公關。
 存儲庫有一個`Normalise.js`腳本，它為鏈接添加屬性，但也通過RegEx檢查“這是一個存根...”文本。
 如果找到，它會將文章文本還原為通用存根文本（並刪除更改）。
 這是預期的行為，因為它允許我們在模板存根因任何原因而更改時更新所有存根。
 ###獲得幫助
 這是一個由整個貢獻者團隊提供支持的社區，您可以從中汲取創意，並在撰寫時提出意見。
 保持活躍在[貢獻者聊天室]（https://gitter.im/freecodecamp/contributors）並提出很多問題。
 ---
 ##披露指南文章拉取請求的步驟
 >本節針對此回購的評論者。
 ##壁球和合併
 在合併保持提交歷史記錄清潔的PR時，我們使用<kcd> Squash和merge </ kcd>選項。
 ！[GIF  - 壁球和合併]（https://files.gitter.im/FreeCodeCamp/Contributors/56MQ/9cb8db153d7bb1b3576cd1ffc207e39d.gif）
 ###過濾PR
 > PR，Open，Oldest First，Travis CI建立成功，沒有人分配，沒有評論
 [`是：pr is：open sort：updated-asc status：success no：assignee comments：0`]（https://github.com/freeCodeCamp/freeCodeCamp/pulls?utf8=%E2%9C%93&q=is% 3Apr％圖20是％3Aopen％20sort％3Aupdated-ASC％20status％3Asuccess％20no％3Aassignee％20comments％3A0）
 > PR，Open，Oldest First，沒有標籤：`platform`，`enhancement`，`invalid`或`change changes'
 [`是：pr是：open sort：updated-asc -label：platform -label：enhancement -label：invalid -label：“changes requested”“]（https://github.com/freeCodeCamp/freeCodeCamp/pulls?utf8 =％E2％9C％93＆q =是％3Apr％圖20是％3Aopen％20sort％3Aupdated-ASC％20-標記％3Aplatform％20-標記％3Aenhancement％20-標記％3Ainvalid％20-標籤％3A％22changes％20requested％ 22）。
 ###模板
 >您可以使用GitHub內置的[**已保存回复**]（https://github.com/settings/replies/）功能製作您自己的功能，或使用以下功能。
 ＃＃＃＃ 謝謝
 ```降價
 感謝您對該頁面的貢獻！ 👍
 我們很高興接受這些變化，並期待未來的貢獻。 🎉
 ```
 ####謝謝你，恭喜你
 >感謝和鼓勵第一次貢獻者。
 ```降價
 嗨@username。恭喜你的第一次拉動請求（PR）！ 🎉
 感謝您對該頁面的貢獻！ 👍
 我們很高興接受這些變化，並期待未來的貢獻。 📝
 ```
 ####構建錯誤
 ```降價
 嘿@username
 因此，我希望能夠合併您的更改，但看起來Travis CI版本存在錯誤。 ⚠️
 解決這些問題後，我將能夠審核您的PR並將其合併。 😊
 ---
 >請隨意參考[文章指南撰寫文章]（https://github.com/freeCodeCamp/freeCodeCamp#article-title），以便正確格式化文章，以便Travis CI構建通過。 ✅
 >
 >此外，GitHub在創建PR時寫下您的更改的簡要說明是一種很好的做法。 📝
 ```
 ####同步Fork
 >當PR與`master`分支不同時。
 ``````降價
 嘿@username
 因此，我希望能夠合併您的更改，但看起來Travis CI版本存在錯誤。 ⚠️
 ```慶典
 錯誤：ENOTDIR：不是目錄，打開'src / pages / java / data-abstraction / index.md'
 ```
 這個特殊錯誤實際上並不是由您的文件引起的，而是由於將錯誤代碼合併到`master`分支引起的舊錯誤。它已經解決了。
 要傳遞構建，您必須同步來自`freeCodeCamp / freeCodeCamp` repo的`master`分支的最新更改。
 使用命令行，您可以通過三個簡單的步驟完成此操作：
 ```慶典
 git remote add upstream git：//github.com/freeCodeCamp/freeCodeCamp.git
 git fetch upstream
 git pull上游大師
 ```
 如果你正在使用GUI，你只需“添加一個新的遠程...”並使用上面的鏈接`git：// github.com / freeCodeCamp / freeCodeCamp.git`。
 一旦你同步你的fork並傳遞構建，我將能夠檢查你的PR並合併它。 😊
 ---
 >隨意參考GitHub上的[Syncing a Fork]（https://help.github.com/articles/syncing-a-fork/）文章，了解如何讓您的叉子與最新版本保持同步上游存儲庫。 🔄
 >
 >此外，GitHub在創建PR時寫下您的更改的簡要說明是一種很好的做法。 📝
 ``````
 ####合併衝突
 >當PR出現需要解決的合併衝突時.¹
 ```降價
 嘿@username
 所以我希望能夠合併您的更改，但看起來您有一些合併衝突。 ⚠️
 解決這些衝突後，我將能夠檢查您的PR並將其合併。 😊
 ---
 >如果您不熟悉合併衝突過程，請隨時查看GitHub關於[“解決合併衝突”的指南]（https://help.github.com/articles/resolving-a-merge-conflict-上的github /）。 🔍️
 >
 >此外，GitHub在創建PR時寫下您的更改的簡要說明是一種很好的做法。 📝
 ```
 ¹如果第一次撰稿人有合併衝突，維護人員將為他們解決衝突。
 ####複製
 > PR重複或重複時。
 ```降價
 嘿@username
 對於您正在編輯的這篇文章，似乎已經接受了類似的更改，對此抱歉。 😓
 如果您覺得還有更多要添加的內容，請隨時打開新的PR。
 再次感謝！ 😊
 ---
 >如果您有任何疑問，請隨時通過[Gitter]（https://gitter.im/FreeCodeCamp/Contributors）或通過以下評論與您聯繫。 💬
 ```
 ####關閉無效的拉取請求
 > PR無效時。
 ```降價
 嘿@username
 你實際上沒有添加任何內容，所以我將無效拉請求此PR並將其標記為“無效”。 😓️
 隨意打開另一個公關！ 👍
 ```
--- a/docs/i18n-languages/portuguese/how-to-work-on-guide-articles.md
+++ b/docs/i18n-languages/portuguese/how-to-work-on-guide-articles.md
@ -1,415 +0,0 @@
 <!-- do not translate this -->
 | [Read these guidelines in other languages](/docs/i18n-languages) |
 |-|
 <!-- do not translate this -->
 # Como trabalhar em Artigos Guia
 Com a tua ajuda, nós podemos criar uma ferramenta de referência compreensiva que ajudará milhões de pessoas que estão a aprender código nos anos que aí vêm. 💛
 Tu podes:
 - [Ajudar-nos criando e Editando Artigos Guia](#steps-for-creating-and-editing-guide-articles).
 - [Ajudar-nos revendo <i>pull requests</i> para Artigos Guia]()
 ## Passos para Criar e Editar Artigos Guia
 1. 🍴 [Fazer <i>fork</i> a este repositório](https://github.com/freeCodeCamp/freeCodeCamp#fork-destination-box)
 2. 👀️ Seguir as guias de contribuição delineados mais abaixo.
 3. 🔧 Fazer algumas mudanças impressionantes!
 4. 📖 Ler este [guia de estilo de melhores práticas](/docs/style-guide-for-guide-articles).
 5. 👉 [Fazer um <i>pull request</i>](https://github.com/freeCodeCamp/freeCodeCamp/compare)
 6. 🎉 Ter o teu <i>pull request</i> aprovado - sucesso!
 Ou então apenas [criar um <i>issue</i>](https://github.com/freeCodeCamp/freeCodeCamp/issues) - qualquer pedacinho de ajuda conta! 😊
 ### [Segue estas guias recomendadas do nosso Guia de Estilo para um Artigo Guia interessante e completo](/docs/style-guide-for-guide-articles.md)
 ### Criar um <i>Pull request</i> (PR) para propor mudanças
 Há duas maneiras para propor uma mudança num repositório, depois de editares ou adicionar um Artigo Guia:
 - [Usando o GitHub Web Interface no teu <i>browser</i>](#using-the-github-web-interface-on-your-browser).
 - [Trabalhando na tua máquina pessoal](#working-on-your-local-machine) (_recomendado_ para pré-visualizar mudanças).
 #### Usando o GitHub Web Interface no teu browser
 Vê a demonstração em vídeo ou segue os passos abaixo:
 **[A FAZER]** Atualizar a gravação do GIF.
 ![GIF a mostrar os passos do GitHub interface](https://cdn-images-1.medium.com/max/1395/1*qnFS6ITMwcpsiZvF5b1pHw.gif)
 1. Ir à pasta **"pages"** (localizada no [`guide`](/guide)) e encontrar o artigo que gostarias de escrever ou editar.
    > Todos os <i>stubs</i> estarão num ficheiro index.md
 2. Carrega o icon de lápis do <kbd>Edit this file</kbd> e faz as tuas mudanças ao ficheiro usando o GitHub-flavored Markdown.
    > Se o icon estiver acizentado e a dar o aviso "You must be on a branch to make or propose changes to this file", então está provavelmente na <i>tree</i> de outra pessoa. No topo esquerdo da página estará uma caixa <i>drop down</i> que dirá "Tree: #######". Carrega no <i>drop down</i> e muda o <i>branch</i> para "master". Agora o lápis deve estar clicável.
 3. Faz <i>scroll</i> até ao fim do ecrã e adiciona uma mensagem de <i>commit</i> a explicar as tuas mudanças.
    (Opcional): Nós recomendamos vivamente fazer uma mensagem de <i>commit</i> convencional. Isto é uma boa prática que verás em alguns dos repositórios <i>Open Source</i> mais populares. Como developer, isto encoraja-te a seguir práticas <i>standard</i>.
    Alguns exemplos de mensagens de <i>commit</i> convencionais:
    ```md
    fix: update HTML guide article
    fix: update build scripts for Travis-CI
    feat: add article for JavaScript hoisting
    docs: update contributing guidelines
    ```
    Mantém-nas curtas, não mais que 50 caracteres. Podes sempre adicionar informação adicional na descrição da mensagem de <i>commit</i>.
    Isto não leva tempo adicional comparado com uma mensagem não convencional como 'update file' ou 'add index.md'
    Podes aprender mais sobre <i>commits</i> convencionais [aqui](https://www.conventionalcommits.org/en/v1.0.0-beta.2/#why-use-conventional-commits).
 4. Seleciona a opção de <i>radio button</i> para **"Create a new branch for this commit and start a pull request"** e clica em <kbd>Propose file changes</kbd>.
 5. No próximo ecrã podes adicionar outros detalhes sobre o teu PR e depois clica em <kbd>Create pull request</kbd>.
 Parabéns 🎉! Criaste um <i>pull request</i>.
 #### Trabalhando na tua máquina pessoal (_recomendado_ para pré-visualizar mudanças)
 Não é obrigatório trabalhares na tua máquina pessoal, a não ser que queiras pré-visualizar as tuas edições ou trabalhar com <i>UI fixes</i> e melhorias. Também é recomendado caso encontres problemas de git como conflitos de <i>merge, rebasing</i>, etc.
 ##### Lê estas guias em [Como configurar o freeCodeCamp localmente](/docs/how-to-setup-freecodecamp-locally.md)
 ### Ter um PR aceite
 Aqui estão algumas diretrizes que os <i>reviewers</i> seguem ao analizar PRs:
 - tem uma descrição e título relevantes
 - o PR respeita o [guia de estilo](/docs/style-guide-for-guide-articles)
 - nós seguimos dicas QA gerais em [Directrizes de Moderador](https://forum.freecodecamp.org/t/freecodecamp-moderator-guidelines/18295)
 - desde que um <i>pull request</i> melhore ou expanda o guia, nós aceitamo-lo mesmo que contenha linguagem imperfeita ou conteúdo parcial
 - <i>pull requests</i> mais antigos são analizados primeiro
 #### Labels
 - **content** é para <i>pull requests</i> que modificam o conteúdo dos artigos no guia (adicionam um novo artigo ou atualizam um já existente)
 - **duplicate** é para <i>pull requests</i> que têm o mesmo conteúdo que outro PR
 - **changes requested** é para <i>pull requests</i> que precisam de mudanças antes de serem <i>merged</i>
 - **stale** é para <i>pull requests</i> com uma <i>label</i> _"changes requested"_  que não tem actividade após 2 semanas e será consequentemente fechado
  - Um <i>pull requests</i> _stale_ deve ser fechado.
  - Aqui está [um exemplo](https://github.com/freeCodeCamp/freeCodeCamp/pull/235).
 #### Conteúdo Contraditório/Duplicado
 UM PR é considera um **duplicate** se faz mudanças ao mesmo artigo que outro PR.
 Em geral, um <i>reviewer</i> irá:
 1. Ordenar PR por mais antigo
 2. Procurar PRs com conteúdo parecido
 3. <i>Merge</i> do mais antigo para o mais recente
 É muito provável que existirão conflitos de <i>merge</i> com PRs duplicados.
 Reviewers farão todos os esforços para resolver estes conflitos e combinar os PRs duplicados.
 #### Pedir Mudanças
 Se um <i>pull requests</i> não é perfeito, o revisor poderá:
 - pedir mudanças ao contribuidor e adicionar a label *changes requested*
 - resolver problemas menores e fazer um <i>commit> no topo do PR
 #### Travis CI Build
 Todos os PRs devem passar a verificação do Travis CI antes de acontecer o <i>merge</i>.
 Se um PR quebra o <i>build</i> (uma verificação Travis CI falha e mostra um "X" vermelho) existem três causas prováveis.
 Precisas de resolver o provlema antes de podermos <i>merge</i> o teu PR:
 1. O teu PR cria um novo artigo e falta o ficheiro 'index.md' algures.
    - Todas as pastas no `src/pages` precisam de um ficheiro `index.md` (e o nome tem de ser `index.md`).
    - Dois cenários prováveis sãoT
      - deste algum outro nome ao ficheiro do novo artigo que não `index.md`, ou
      - criaste uma nova pasta e uma outra sub-pasta e escreveste o artigo na sub-pasta mas esqueceste-te de pôr um ficheiro `index.md` na nova pasta
 2. O teu PR cria uma nova pasta e o nome da pasta não está formatado corretamente.
    - O nome da tua pasta deve ser todo em minúsculas e formatado em kebab-case (ex. my-new-folder).
 3. O artigo não tem um campo para o `title` no topo.
    - Por favor refere à secção do [Title](#title) mais abaixo por baixo de  [Guia de Estilo para escrever artigos](/docs/style-guide-for-guide-articles.md).
 ### Quando fechamos <i>pull requests</i>
 Nós fechamos PR
 - se um PR mais antigo do mesmo artigo é <i>merged</i> e o teu PR não adicionar novo conteúdo
 - se há zero/pouco esforço (ex.: copiar e colas de outra fonte como a Wikipédia)
 - se há texto copiado de uma fonte com </i>copyright</i>i - ver [problema de citação](https://github.com/freeCodeCamp/freeCodeCamp/issues/2503)
 - se não respeita o [Guia de Estilo para escrever artigos](/docs/style-guide-for-guide-articles.md)
 - se não respeita o [Academic Honesty policy](https://www.freecodecamp.org/academic-honesty)
 - se está parado (se a mudança é pedida e não há atividade durante duas semanas)
 Também, se estiveres a trabalhar de um artigo <i>"stub"</i>, as tuas mudanças devem ser substanciais o suficiente para substituir o texto <i>stub</i>.
 Não aceitamos um PR que só adiciona links à secção de "Mais Informação:".
 O repositório tem um script `Normalise.js` que adiciona atributos a links, mas também procura texto "This is a stub..." via um RegEx.
 Se encontrado, vai reverter o artigo de volta para o texto <i>stub</i> genérico (e apagar as tuas mudanças).
 Este é comportamento pretendido, visto que permite-nos atualizar todos os <i>stubs</i> se o <i>template stub</i> por alguma razão.
 ### Encontrar Ajuda
 Há uma comunidade de suporte de uma equipa inteira de contribuidores, com quem podes trocar ideias e pedir opiniões sobre a tua escrita.
 Mantém-te ativo no [chat room de contribuidores](https://gitter.im/freecodecamp/contributors) e faz muitas perguntas.
 ---
 ## Passos para rever <i>pull requests</i> para Artigos Guia
 > Esta secção é direccionada a revisores deste repositório.
 ## Squash e Merge
 Nós usamos a opção <kcd>Squash and merge</kcd> quando <i>merging</i> o PR que mantém a <i>commit history</i> limpa.
 ![GIF - Squash and merge](https://files.gitter.im/FreeCodeCamp/Contributors/56MQ/9cb8db153d7bb1b3576cd1ffc207e39d.gif)
 ### Filtrar PRs
 > PR, Open, Oldest First, Travis CI Build successful, no one assigned, no comments
 [`is:pr is:open sort:updated-asc status:success no:assignee comments:0`](https://github.com/freeCodeCamp/freeCodeCamp/pulls?utf8=%E2%9C%93&q=is%3Apr%20is%3Aopen%20sort%3Aupdated-asc%20status%3Asuccess%20no%3Aassignee%20comments%3A0)
 > PR, Open, Oldest First, Does not have labels: `platform`, `enhancement`, `invalid` or `changes requested`
 [`is:pr is:open sort:updated-asc -label:platform -label:enhancement -label:invalid -label:"changes requested"`](https://github.com/freeCodeCamp/freeCodeCamp/pulls?utf8=%E2%9C%93&q=is%3Apr%20is%3Aopen%20sort%3Aupdated-asc%20-label%3Aplatform%20-label%3Aenhancement%20-label%3Ainvalid%20-label%3A%22changes%20requested%22).
 ### Templates
 > Podes criar os teus próprios templates na feature inserida no GitHub em [**Saved replies**](https://github.com/settings/replies/) ou usar os mais abaixo.
 #### Agradecimento
 Em inglês:
 ```markdown
 Thank you for your contribution to the page! 👍
 We're happy to accept these changes, and look forward to future contributions. 🎉
 ```
 Em português:
 ```markdown
 Obrigado pela tua contribuição para a página! 👍
 Estamos muito felizes em aceitar estas mudanças e esperamos ver mais tuas contibuições no futuro. 🎉
 ```
 #### Agradecimento e parabenização
 > Para agradecer e encorajar a primeira contribuição de um utilizador.
 Em inglês:
 ```markdown
 Hi @username. Congrats on your first pull request (PR)! 🎉
 Thank you for your contribution to the page! 👍
 We're happy to accept these changes, and look forward to future contributions. 📝
 ```
 Em português:
 ```markdown
 Olá @username. Parabéns pelo teu primeiro pull request (PR)! 🎉
 Obrigada pela tua contribuição para a página! 👍
 Estamos muito felizes em aceitar estas mudanças e esperamos ver mais tuas contibuições no futuro. 📝
 ```
 #### Erro de Build
 Em inglês:
 ```markdown
 Hey @username
 So I'd love to be able to merge your changes but it looks like there is an error with the Travis CI build. ⚠️
 Once you resolve these issues, I will be able to review your PR and merge it. 😊
 Em português:
 ```markdown
 Olá @username
 Adoraria juntar as tuas mudanças mas parece que há um erro com o Travis CI build. ⚠️
 Assim que resolveres estes problemas, poderei rever o teu PR e juntar ao repositório. 😊
 ---
 > Estás à vontade de referenciar o [Guia de Estilo para escrever artigos](https://github.com/freeCodeCamp/freeCodeCamp#article-title) para este repositório no que toca a formatar um artigo corretamente para que o teu Travis CI build seja aprovado. ✅
 >
 > Também é uma boa prática no GitHub escrever uma breve descrição das tuas mudanças quando crias um PR. 📝
 ```
 #### Syncing Fork
 > Quando o PR não está atualizado quanto ao `master` <i>branch</i>.
 Em inglês:
 ``````markdown
 Hey @username
 So I'd love to be able to merge your changes but it looks like there is an error with the Travis CI build. ⚠️
 ```bash
 Error: ENOTDIR: not a directory, open 'src/pages/java/data-abstraction/index.md'
 ```
 This particular error was not actually caused by your file but was an old error caused by merging faulty code to the `master` branch. It has since been resolved.
 To pass the build, you will have to sync the latest changes from the `master` branch of the `freeCodeCamp/freeCodeCamp` repo.
 Using the command line, you can do this in three easy steps:
 ```bash
 git remote add upstream git://github.com/freeCodeCamp/freeCodeCamp.git
 git fetch upstream
 git pull upstream master
 ```
 If you're using a GUI, you can simply `Add a new remote...` and use the link `git://github.com/freeCodeCamp/freeCodeCamp.git` from above.
 Once you sync your fork and pass the build, I will be able to review your PR and merge it. 😊
 Em português:
 ``````markdown
 Olá @username
 Adoraria juntar as tuas mudanças mas parece que há um erro com o Travis CI build. ⚠️
 ```bash
 Error: ENOTDIR: not a directory, open 'src/pages/java/data-abstraction/index.md'
 ```
 Este erro em particular não foi causado pelo teu ficheiro mas foi um erro antigo causado pelo <i>merge</i> de código defeituoso ao `master` <i>branch</i>. Foi, desde então, resolvido.
 Para ser aprovado, terás que sincronizar as mudanças mais recentes do `master` <i>branch</i> do repositório do `freeCodeCamp/freeCodeCamp`.
 Usando a linha de comandos, podes fazer isto em três passos fáceis:
 ```bash
 git remote add upstream git://github.com/freeCodeCamp/freeCodeCamp.git
 git fetch upstream
 git pull upstream master
 ```
 Se estás a usar um GUI, podes simplesmente `Add a new remote...` e usar o link `git://github.com/freeCodeCamp/freeCodeCamp.git` de cima.
 Assim que resolveres estes problemas, poderei rever o teu PR e juntar ao repositório. 😊
 ---
 > Estás à vontade para referênciar o artigo de [Sincronizar um Fork](https://help.github.com/articles/syncing-a-fork/) do GitHub para mais informação em como manter o teu <i>fork</i> atualizado com o repositório principal. 🔄
 >
 > Também é uma boa prática no GitHub escrever uma breve descrição das tuas mudanças quando crias um PR. 📝
 ``````
 #### Conflictos de Merge
 > Quando o PR tem conflitos de merge que necessitam de ser resolvidos.¹
 Em inglês:
 ```markdown
 Hey @username
 So I'd love to be able to merge your changes but it looks like you have some merge conflicts. ⚠️
 Once you resolve these conflicts, I will be able to review your PR and merge it. 😊
 ---
 > If you're not familiar with the merge conflict process, feel free to look over GitHub's guide on ["Resolving a merge conflict"](https://help.github.com/articles/resolving-a-merge-conflict-on-github/). 🔍️
 >
 > Also, it's good practice on GitHub to write a brief description of your changes when creating a PR. 📝
 ```
 Em português:
 ```markdown
 Olá @username
 Adoraria juntar as tuas mudanças mas parece que tens algums conflitos de <i>merge</i>. ⚠️
 Assim que resolveres estes problemas, poderei rever o teu PR e juntar ao repositório. 😊
 ---
 > Se não estiveres familiar com o processo de conflito de <i>merge</i>, consulta o guia do GitHub quanto a ["Resolver um conflito de merge"](https://help.github.com/articles/resolving-a-merge-conflict-on-github/). 🔍️
 >
 > Também é uma boa prática no GitHub escrever uma breve descrição das tuas mudanças quando crias um PR. 📝
 ```
 ¹ Se é um utilizador a contribuir pela primeira vez tem um problema de <i>merge</i> os <i>mantainers</i> irão resolver o conflito por eles.
 #### Duplicado
 > Quando um PR é repetitivo ou duplicado.
 Em inglês:
 ```markdown
 Hey @username
 It seems that similar changes have already been accepted earlier for this article you're editing, sorry about that. 😓
 If you feel you have more to add, please feel free to open up a new PR.
 Thanks again! 😊
 > Hey @username
 It seems that similar changes have already been accepted earlier for this article you're editing, sorry about that. 😓
 If you feel you have more to add, please feel free to open up a new PR.
 Thanks again! 😊
 ---
 > If you have any questions, feel free to reach out through [Gitter](https://gitter.im/FreeCodeCamp/Contributors) or by commenting below. 💬
 ```
 Em português:
 ```markdown
 Olá @username
 Parece que mudanças semelhantes já foram aceites antes para este artigo que estás a editar, desculpa. 😓
 Se achares que tens mais a adicionar, estás à vontade para abrir outro PR.
 Obrigada mais uma vez! 😊
 ---
 > Se tens alguma questão, contacta-nos através do [Gitter](https://gitter.im/FreeCodeCamp/Contributors) ou comentando abaixo. 💬
 ```
 #### Fechar pull requests inválidos
 > Quando o PR é inválido.
 Em inglês:
 ```markdown
 Hey @username
 You haven't actually added any content so I will be  invalid pull requests this PR and marking it as `invalid`. 😓️
 Feel free to open another PR though! 👍
 ```
 Em português:
 ```markdown
 Olá @username
 Não adicionaste nenhum conteúdo portanto vou ter de invalidar este <i>pull request</i> e marcá-lo como `invalid`. 😓️
 Estás à vontade para abrir outro PR! 👍
 ```
--- a/docs/i18n-languages/russian/how-to-work-on-guide-articles.md
+++ b/docs/i18n-languages/russian/how-to-work-on-guide-articles.md
@ -1,10 +0,0 @@
 <!-- do not translate this -->
 | [Read these guidelines in other languages](/docs/i18n-languages) |
 |-|
 <!-- do not translate this -->
 # Правила для внесения своего вклада в проекты
 Привет 👋 !
 Эти инструкции еще не были переведены. Чтобы узнать больше, пройдите по:[`#18312`](https://github.com/freeCodeCamp/freeCodeCamp/issues/18312)
--- a/docs/i18n-languages/spanish/how-to-work-on-guide-articles.md
+++ b/docs/i18n-languages/spanish/how-to-work-on-guide-articles.md
@ -1,317 +0,0 @@
 <!-- do not translate this -->
 | [Read these guidelines in other languages](/docs/i18n-languages) |
 |-|
 <!-- do not translate this -->
 # Cómo trabajar en artículos de la Guía
 Con tu ayuda, podemos crear un herramienta de referencia accesible que ayudará a millones de personas que están aprendiendo a programar ahora y en los años por venir. 💛
 Puedes:
 - [Ayudarnos creando y editando articulos de la Guía](#steps-for-creating-and-editing-guide-articles).
 - [Ayudarnos revisando Pull Requests para artículos de la Guía]()
 ## Pasos para crear y editar artículos de la Guía
 1. 🍴 [Fork este repositorio](https://github.com/freeCodeCamp/freeCodeCamp#fork-destination-box)
 2. 👀️ Sigue las normas de contribución expuestas a continuación.
 3. 🔧 Haz cambios asombrosos!
 4. 📖 Lee la [guía de buenas prácticas de estilo](/docs/style-guide-for-guide-articles).
 5. 👉 [Haz un Pull Request](https://github.com/freeCodeCamp/freeCodeCamp/compare)
 6. 🎉 Consigue que aprueben tu Pull request - Éxito!
 O simplemente [crea un tema](https://github.com/freeCodeCamp/freeCodeCamp/issues) - toda pequeña ayuda cuenta! 😊
 ### [Sigue estas recomendaciones de nuestra guía de estilo para crear un artículo atractivo](/docs/style-guide-for-guide-articles.md)
 ### Crear Pull Request para proponer cambios
 Hay dos formas de proponer cambios en el repositorio despues de editar o añadir un articulo:
 - [Utilizando el sistema de comunicacion de GitHub en tu navegador](#using-the-github-web-interface-on-your-browser).
 - [Trabajando en tu maquina local](#working-on-your-local-machine) (_recomendado_ para pre-visualiar cambios).
 #### Utilizar el sistema de comunicacion web de GitHub
 Mira este vídeo de demostración o sigue los siguientes pasos:
 **[TODO]** Actualizar la grabacion GIF.
 ![GIF mostrando los pasos de la interfaz de GitHub](#)
 1. Ve a la carpeta **"páginas"** (situado en [`guide`](/guide)) donde encontrarás el artículo raiz que quieras editar.
    > Todas las raíces estarán en un archivo index.md
 2. Pincha en <kbd>Editar este archivo</kbd> y hace tus cambios al archivo en la consola de edición de GitHub.
    > Si el icono aparece gris y te muestra la alerta "Debes estar en una rama para hacer o proponer cambios a este archivo", significa que probablemente estés en la rama de otra persona. En la parte superior izquierda de la página hay una casilla desplegable que dice: "Árbol: #######". Pincha en el desplegable y cambia la rama a maestra. El icono de edición debería estar disponible ahora.
 3. Desplázate a la parte de abajo de la pantalla y añade un mensaje explicando tus cambios.
    (Opcional): Recomendamos hacer un mensaje convencional. Esta es una buena práctica que verás en algunos de los repositorios Open Source más populares. Como desarrollador, deberías seguir las prácticas estándar.
    Algunos ejemplos de mensajes convencionales serían:
    ```md
    fix: Actualizar artículo de guía sobre HTML
    fix: Actualizar scripts para Travis-CI
    feat: Añadir articulo sobre JavaScript hoisting
    docs: Actualizadas recomendaciones de contribución
    ```
    Se breve, no más de 50 caracteres. Puedes añadir información adicional en la descripción del mensaje.
    esto no supone ningún esfuerzo adicional respecto a mensajes como 'update file' o 'add index.md'
    Puedes aprender más sobre [por qué deberías seguir esta práctica aquí](https://www.conventionalcommits.org/en/v1.0.0-beta.2/#why-use-conventional-commits).
 4. Selecciona el botón con la opción **"Crear una nueva rama para esta propuesta y enviar"** y click en <kbd>Proponer cambio en el archivo</kbd>.
 5. En la siguiente pantalla, puedes añadir más detalles sobre tu PR, luego click en <kbd>Crear pull request</kbd>.
 Felicidades 🎉! Acabas de crear un pull request.
 #### Trabajar desde tu sistema local (_recomendado_ para revisar cambios)
 No es obligatorio que trabajes en tu sistema personal, salvo que desees pre-visualizar tus cambios, o trabajar con version actualizada y arreglos de UI. También es recomendable si tienes problemas con git como errores de integración, rebase, etc.
 ##### Lee las recomendaciones en [Cómo configurar freeCodeCamp localmente](/docs/how-to-setup-freecodecamp-locally.md)
 ### Aceptación del PR
 Estos son algunos criterios utilizados por los criticos cuando evalúan PRs:
 - Descripción y título relevantes
 - El PR respeta la [guía de estilo](/docs/style-guide-for-guide-articles)
 - Consejos generales de QA de las [recomendaciones para Moderadores](https://forum.freecodecamp.org/t/freecodecamp-moderator-guidelines/18295)
 - Siempre y cuando el PR suponga una mejora o ampliación de la guía, será aceptado aunque tenga errores gramaticales o contenido parcial
 - Los PR más antiguos se revisan primero
 #### Etiquetas
 - **contenido** es para Pull Requests que modifican el contenido de artículos en la guía (añaden un nuevo artículo o actualizan uno existente)
 - **duplicado** es para Pull Request que contienen el mismo contenido que otro PR abierto
 - **cambios solicitados** es para Pull Requests que necesitan algún cambio antes de ser integrados
 - **pasado** es para Pull Requests que con etiqueta _"changes requested"_ que no han tenido actividad durante al menos 2 semanas y serán por tanto cerrados
  - Un  pull request _pasado_ debe cerrarse.
  - Este es [un ejemplo](https://github.com/freeCodeCamp/freeCodeCamp/pull/235).
 #### Contenido conflictivo/duplicado
 Se considera **duplicado** un PR si hace cambios al mismo artículo que otro PR.
 En general el revisor:
 1. Organizará los PR desde lo más antiguo
 2. Buscará para PRs con contenido similar
 3. Integrará desde lo más antiguo a los más nuevos
 Muy probablemente aparecerán conflictos al integrar PRs duplicados.
 Los revisores harán todos los esfuerzos posibles para resolver estos conflictos e integrar los PRs.
 #### Solicitar cambios
 Si el Pull Request no es perfecto el revisor podría:
 - solicitar cambios al contribuidor y añadir la etiqueta *cambios solicitados*
 - solucionar errores menores y hacer un envío encima del PR
 #### Travis CI Build
 Todos los PRs deben superar los test de Travis CI antes de poder ser integrados.
 Si un PR rompe la ejecución (un test de Travis CI falla y muestra una "X" roja) hay tres causas probables y tendrás que resolver el problema antes de que podamos integrar el PR:
 1. Tu PR crea un nuevo artículo pero le falta un archivo `index.md` en algún lugar.
    - Cada directorio en `src/pages` necesita un archivo `index.md` en él (y debe llamarse `index.md`).
    - Dos escenarios muy probables son
      - llamaste al archivo de forma distinta a `index.md`, o
      - creates un nuevo directorio y un subdirectorio, y escribiste el nuevo artículo en el subdirectorio pero olvidaste incluir un achivo raiz `index.md` en el nuevo directorio
 2. Tu PR crea un directorio nuevo y su nombre no tiene el formato correcto.
    - Tu directorio debería incluir solamente minúsculas y seguir el formato kebab-case (Ejemplo. mi-nuevo-directorio).
 3. El artículo no tiene un campo llamado `título` en la parte superior.
    - Por favor utiliza la sección [Título](#title) según la [Guía de Estilo para escribir artículoss](/docs/style-guide-for-guide-articles.md).
 ### Cuándo cerramos Pull Requests
 Cerramos Pull Requests
 - Si un PR más antiguo para el mismo artículo es integrado, y tu PR no añade nuevo contenido
 - Si hay poco o ningún esfuerzo por tu parte en su elaboración (Por ejemplo: copias literales de artículos de páginas como Wikipedia)
 - Si incluye contenido copiado de fuentes con Copyright - ver [Citas](https://github.com/freeCodeCamp/freeCodeCamp/issues/2503)
 - Si no respeta la [Guía de estilo para escribir articulos](/docs/style-guide-for-guide-articles.md)
 - Si no respeta la [Política Académica de Honestidad](https://www.freecodecamp.org/academic-honesty)
 - Si está estancado (un cambio ha sido solicitado y no ha habiado respuesta en 2 semanas)
 Además, si estás trabajando a partir de un artículo raiz, tus cambios deben ser lo suficientemente notables como para sustituir al original.
 No aceptaremos PRs que solamente incluyan links a la sección de "Más información:".
 El repositorio tiene un script `Normalise.js` que añade atributos a los link, pero también revisa si aparece el texto "This is a stub..." mediante RegEx.
 Si lo encuentra, revertirá todos los cambios al artículo raiz original eliminando todos tus cambios.
 Esta funcionalidad es deliberada, nos permite actualizar todos los artículos raiz si hubiese algún cambio en la plantilla original.
 ### Solicita ayuda
 Existe una comunidad de apoyo compuesta por un gran número de contribuidores, a quienes puedes pedir opiniones y con quienes contrastar ideas.
 Mantente activo en el [chat de Contribuidores](https://gitter.im/freecodecamp/contributors) y haz muchas preguntas.
 ---
 ## Pasos para revisar Pull Requests para artículos de Guía
 > Esta sección está orientada a revisores del repositorio.
 ## Aplastar e integrar
 Utilizamos la opción <kcd>Aplastar e integrar</kcd> al integrar un PR para mantener el historial de propuestas limpio.
 ![GIF - Squash and merge](https://files.gitter.im/FreeCodeCamp/Contributors/56MQ/9cb8db153d7bb1b3576cd1ffc207e39d.gif)
 ### Filtrar PRs
 > PR, Abierto, Más Antiguos Primero, Travis CI Build correcta, nadie asignado, sin comentarios
 [`is:pr is:open sort:updated-asc status:success no:assignee comments:0`](https://github.com/freeCodeCamp/freeCodeCamp/pulls?utf8=%E2%9C%93&q=is%3Apr%20is%3Aopen%20sort%3Aupdated-asc%20status%3Asuccess%20no%3Aassignee%20comments%3A0)
 > PR, Abierto, Más Antiguos Primero, No contiene las etiquetas: `platform`, `enhancement`, `invalid` or `changes requested`
 [`is:pr is:open sort:updated-asc -label:platform -label:enhancement -label:invalid -label:"changes requested"`](https://github.com/freeCodeCamp/freeCodeCamp/pulls?utf8=%E2%9C%93&q=is%3Apr%20is%3Aopen%20sort%3Aupdated-asc%20-label%3Aplatform%20-label%3Aenhancement%20-label%3Ainvalid%20-label%3A%22changes%20requested%22).
 ### Plantillas
 > Puedes crear tus propias plantillas en la herramienta de  GitHub's [**Respuestas guardadas**](https://github.com/settings/replies/) o utilizar las siguientes.
 #### Gracias
 ```markdown
 Gracias por contribuir a la página! 👍
 Estamos encantados de aceptar estos cambios y esperamos tus futuras aportaciones. 🎉
 ```
 #### Gracias y enhorabuena
 > Para agradecer y animar a contribuidores primerizos.
 ```markdown
 Hola @username. Enhorabuena por tu primer pull request (PR)! 🎉
 Gracias por contribuir a la página! 👍
 Estamos encantados de aceptar estos cambios y esperamos tus futuros aportes. 📝
 ```
 #### Error de intregración
 ```markdown
 Hola @username
 Me encantaría integrar tus cambio pero para que hay un error con Travis CI build. ⚠️
 Una vez resuelvas el problema, podré revisar tu PR e integrarla. 😊
 ---
 > Puedes conseguir más información en la [Guía de estilo para escibir Artículos](https://github.com/freeCodeCamp/freeCodeCamp#article-title) sobre cómo formatear tus artículos para que superen los test de Travis CI. ✅
 >
 > Además, es una buena práctica en GitHub escribir una decripción breve de tus cambios al crear un PR. 📝
 ```
 #### Sincronización de Fork
 > Cuando el PR no está actualizada con la rama `master`.
 ``````markdown
 Hola @username
 Me encantaría poder integrar tus cambios pero parece que hay un error con los test de Travis CI build. ⚠️
 ```bash
 Error: ENOTDIR: not a directory, open 'src/pages/java/data-abstraction/index.md'
 ```
 Este error en particular no fue provocado por tu archivo sino que se trata de un error antiguo debido a la integración de código erróneo en la rama `master`. Ha sido resuelto desde entonces
 Para superar el test, deberás sincronizar los últimos cambios en la rama `master` del repositorio `freeCodeCamp/freeCodeCamp`.
 Usando la línea de comandos, puedes hacer esto en tres pasos sencillos:
 ```bash
 git remote add upstream git://github.com/freeCodeCamp/freeCodeCamp.git
 git fetch upstream
 git pull upstream master
 ```
 Si utilizas una GUI, puedes simplemente hacer `Add a new remote...` y utilizar el link `git://github.com/freeCodeCamp/freeCodeCamp.git` de arriba.
 Una vez sincronices tu fork y superes los test podré integrar tu PR. 😊
 ---
 > Puedes conseguir más información en el artículo [Sincronizando un Fork](https://help.github.com/articles/syncing-a-fork/) sobre cómo mantener al día tu fork con el repositorio principal. 🔄
 >
 > Además, es una buena práctica en GitHub escribir una decripción breve de tus cambios al crear un PR. 📝
 ``````
 #### Conflictos de integración
 > Cuando el PR tiene conflictos de integración que debemos resolver.¹
 ```markdown
 Hola @username
 Me encantaría poder integrar tus cambios para parece que tienes conflictos de integración. ⚠️
 Una vez resuelvas estos conflictos, podré revisar tu PR e integrarlo. 😊
 ---
 > Si no estás familiarizado con los conflictos de integración, por favor revisa la guía de GitHub ["Resolviendo conflictos de integración"](https://help.github.com/articles/resolving-a-merge-conflict-on-github/) para más información. 🔍️
 >
 > Además, es una buena práctica en GitHub escribir una decripción breve de tus cambios al crear un PR. 📝
 ```
 ¹ Si un contribuidor primerizo tiene conflictos de integración, los encargados de mantenimiento lo resolverán en su lugar.
 #### Duplicado
 > Cuando el PR está duplicado o es repetitivo
 ```markdown
 Hola @username
 Parece que ya se han aceptado cambios similares para este artículo que estás editando, lo siento. 😓
 Si cees que tienes más que aportar, por favor abre un nuevo PR.
 Gracias de nuevo! 😊
 ---
 > Si tienes preguntas, no dudes en contactarnos a través [Gitter](https://gitter.im/FreeCodeCamp/Contributors) o comentando más abajo. 💬
 ```
 #### Cerrando Pull Requests no válidos
 > Cuando un PR no es válido.
 ```markdown
 Hola @username
 No has añadido ningún contenido real por lo que invalidaré este PR y lo etiquetaré como `inválido`. 😓️
 En cualquier caso, no dudes en abrir otros PR! 👍
 ```