Update README.md

LICENSE

@@ -1,5 +1,5 @@
 The MIT License (MIT)
-Copyright (c) 2018 Elsewhen https://www.elsewhen.com
+Copyright (c) 2018 Elsewhen http://elsewhen.co
 Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
 The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
 THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

README-ja.md

@@ -5,12 +5,12 @@
  | [РУССКИЙ](./README-ru.md)
  | [Português](./README-pt-BR.md)
 
-[<img src="./images/elsewhen-logo.png" width="180" height="180">](https://www.elsewhen.com/)
+[<img src="./images/elsewhen-logo.png" width="180" height="180">](http://elsewhen.co/)
 
 
 # プロジェクトガイドライン[![PRs Welcome](https://img.shields.io/badge/PRs-welcome-brightgreen.svg?style=flat-square)](http://makeapullrequest.com)
 > 開発中の新たなプロジェクトは草原のようですが、メンテナンスは誰にとっても悪夢になります。
-ここには私たちが見つけ記載し、集め考えたガイドラインがあります。 このガイドラインはほとんどの[elsewhen](https://www.elsewhen.com)のJavaScriptのプロジェクトで機能しています。
+ここには私たちが見つけ記載し、集め考えたガイドラインがあります。 このガイドラインはほとんどの[elsewhen](http://elsewhen.co)のJavaScriptのプロジェクトで機能しています。
 もしもベストプラクティスを我々と共有したかったり、このガイドラインの項目は削除した方が良いと思ったら[気軽に私たちに報告してください](http://makeapullrequest.com)。
 - [Git](#git)
     - [Gitのルール](#some-git-rules)

README-ko.md

@@ -5,12 +5,12 @@
  | [РУССКИЙ](./README-ru.md)
  | [Português](./README-pt-BR.md)
 
-[<img src="./images/elsewhen-logo.png" width="180" height="180">](https://www.elsewhen.com/)
+[<img src="./images/elsewhen-logo.png" width="180" height="180">](http://elsewhen.co/)
 
 
 # Project Guidelines &middot; [![PRs Welcome](https://img.shields.io/badge/PRs-welcome-brightgreen.svg?style=flat-square)](http://makeapullrequest.com)
 > 새로운 프로젝트를 개발하는 할 때는 초원에서 뛰어노는 것 같지만, 유지보수는 모두에게 잠재적인 악몽입니다.
-이것은 우리가 발견하고, 작성하고 수집한 가이드라인의 목록입니다. 이 가이드라인은 대부분의 [elsewhen](https://www.elsewhen.com)에서의 JavaScript 프로젝트에 잘 맞습니다.
+이것은 우리가 발견하고, 작성하고 수집한 가이드라인의 목록입니다. 이 가이드라인은 대부분의 [elsewhen](http://elsewhen.co)에서의 JavaScript 프로젝트에 잘 맞습니다.
 만약 모범 사례를 공유하고 싶으시거나 여기에 있는 가이드라인 중 어떤 것이 지워져야 한다고 생각하신다면, [부담없이 우리에게 공유해주세요](http://makeapullrequest.com).
 - [Git](#git)
     - [Git 규칙](#some-git-rules)

README-pt-BR.md

@@ -4,12 +4,12 @@
 | [РУССКИЙ](./README-ru.md)
 | [ENGLISH](./README.md)
 
-[<img src="./images/elsewhen-logo.png" width="180" height="180">](https://www.elsewhen.com/)
+[<img src="./images/elsewhen-logo.png" width="180" height="180">](http://elsewhen.co/)
 
 # Padrões de Projeto &middot; [![PRs são bem vindos](https://img.shields.io/badge/PRs-welcome-brightgreen.svg?style=flat-square)](http://makeapullrequest.com)
 
 > Enquanto desenvolver um novo projeto é apenas diversão para você, manter esse projeto pode ser um dos piores pesadelos para outra pessoa.
-> Isso aqui é uma lista dos padrões que encontramos, coletamos e escrevemos que (para nós) funcionam realmente bem com a maioria dos projetos JavaScript aqui na [elsewhen](https://www.elsewhen.com).
+> Isso aqui é uma lista das padrões que encontramos, coletamos e escrevos que (para nós) funciona realmente bem com a maioria dos projetos JavaScript aqui na [elsewhen](http://elsewhen.co).
 > Se você quer compartilhar alguma prática que considera importante ou acha que alguma das coisas descritas aqui deve ser removida, [Sinta se a vontade para nos dizer](http://makeapullrequest.com).
 
 🔥 [Confira](https://github.com/elsewhencode/react-redux-saucepan) nosso [react redux projeto base](https://github.com/elsewhencode/react-redux-saucepan) em Flow com hot reloading e server-side rendering.
@@ -61,11 +61,11 @@ Essas são algumas regras do Git para manter em mente:
 
   > Desse jeito você pode garantir que o código na master vai estar sempre pronto para fazer build sem problemas e poderá ser usado a qualquer momento para fazer releases (isso pode ser exagero para alguns projetos).
 
-- Nunca dê push direto na `develop` ou `master`. Sempre faça Pull Requests.
+- Nunca push direto na `develop` ou `master`. Sempre faça Pull Requests.
 
   _Por que?_
 
-  > Isso permite outros membros do time saberem que você terminou uma feature. Também possibilita code review e dicussões sobre o código que está prestes a ser introduzido no code base.
+  > Isso permite outros membros do time saber que você terminou uma feature. Também possibilita code review e dicussões sobre o código que está prestes a ser introduzido no code base.
 
 - Atualize sua `develop` local e faça rebase interativo antes de subir sua feature e abrir um Pull Request.
 
@@ -78,15 +78,15 @@ Essas são algumas regras do Git para manter em mente:
 
   _Por que?_
 
-  > Vai reduzir sua lista de branches removendo branches mortas. Vai garantir que você apenas faça o merge de uma branch uma única vez. Feature branches só devem existir enquanto o código ainda está em progresso.
+  > Vai reduzir sua lista de branches removendo branches mortas. Vai granteir que você apenas faça o merge de uma branch uma única vez. Feature branches só devem existir enquanto o código ainda está em progresso.
 
 - Antes de fazer um Pull Request, tenha certeza que sua feature branch está fazendo build corretamente e passando em todos os testes (incluindo os padrões de estilo de código).
 
   _Por que?_
 
-  > Você está prestes a colocar seu código em uma branch estável. Se sua feature branch faz algum teste falhar, a chance é alta de que você vai quebrar o build na branch destino. Você também precisa conferir o code style antes de fazer um Pull Request. Isso contribui para legibilidade e reduz a chance de algum problema de formatação is para o code base com as outras alterações.
+  > Você está prestes a colocar seu código em uma branch estável. Se sua feature branch faz algum teste falahar, a chance é alta de que você vai quebrar o build na branch destino. Você também precisa conferir o code style antes de fazer um Pull Request. Isso contribui para legibilidade e reduz a chance de algum problema de formatação is para o code base com as outras alterações.
 
-- Faça uso desse [`.gitignore`](./.gitignore).
+- Faça uso desse [this](./.gitignore) `.gitignore`.
 
   _Por que:_
 
@@ -104,7 +104,7 @@ Essas são algumas regras do Git para manter em mente:
 
 Devido a maioria dos motivos listados acima, nos usamos [Feature-branch-workflow](https://www.atlassian.com/git/tutorials/comparing-workflows#feature-branch-workflow) com [Interactive Rebasing](https://www.atlassian.com/git/tutorials/merging-vs-rebasing#the-golden-rule-of-rebasing) e alguns pontos do [Gitflow](https://www.atlassian.com/git/tutorials/comparing-workflows#gitflow-workflow) (nomeação e ter uma develop branch). Os principais passos são:
 
-- Em um projeto novo, inicialize o git na pasta do projeto. **Para qualquer features/changes ignore esse passo**.
+- Em um projecto novo, inicialize o git na pasta do projeto. **Para qualquer features/changes ignore esse passo**.
 
   ```sh
   cd <pasta do projeto>
@@ -218,9 +218,9 @@ Ter um bom padrão para criar commits e se atentar a ele faz com que trabalhar c
 - Mantenha o `README.md` enquanto o projeto evolui.
 - Comente seu código. Tente sempre deixar claro o que uma grande parte do código tem a intenção de fazer.
 - Se existe alguma referência em relação a forma como você resolveu o problema ou uma discussão em aberto, adicione os links.
-- Não use comentários como desculpa para fazer um código ruim. Mantenha seu código limpo.
+- Não use comentários como desculpa para fazer um código ruim. Matenha seu código limpo.
 - Não use código limpo como uma desculpa para não fazer nenhum comentário.
-- Mantenha apenas os comentários relevantes enquanto o código evolui.
+- Matenha apenas os comentários relevantes enquanto o código evolui.
 
 <a name="environments"></a>
 
@@ -232,7 +232,7 @@ Ter um bom padrão para criar commits e se atentar a ele faz com que trabalhar c
 
   _Por que?_
 
-  > Diferentes informações, dados, tokens, APIs, portas etc... podem ter que ser diferentes em cada ambiente. Você provavelmente vai querer isolar seu ambiente de `desenvolvimento` para fazer chamadas fake para a API que retornará dados previsíveis, tornando tanto os testes automatizados quanto os manuais muito mais facéis. Ou você pode querer ativar o Google Analytics apenas em `produção` e etc... [Leia mais sobre...](https://stackoverflow.com/questions/8332333/node-js-setting-up-environment-specific-configs-to-be-used-with-everyauth)
+  > Diferentes informações, dados, tokens, APIs, portas etc... podem ter que ser diferentes em cada ambiente. Você provavelmente vai querer isolar seu ambiente de `desenvolvimento` para fazer chamadas fake para a API que retornará dados previsíveis, tornando tanto os testes automatizados quanto os manuais muito mais fácil. Ou você pode querer ativar o Google Analytics apenas em `produção` e etc... [Leia mais sobre...](https://stackoverflow.com/questions/8332333/node-js-setting-up-environment-specific-configs-to-be-used-with-everyauth)
 
 * Carregue suas configurações específicas de deploy de variáveis de ambiente e nunca as adicione no seu codebase como constantes, [veja aqui um exemplo](./config.sample.js).
 
@@ -260,7 +260,7 @@ Ter um bom padrão para criar commits e se atentar a ele faz com que trabalhar c
 
   > Permite que todos saibem em qual versão o projeto funciona. [Leia mais sobre...](https://docs.npmjs.com/files/package.json#engines)
 
-- Adicionalmente, use `nvm` e crie um arquivo `.nvmrc` na raíz do seu projeto. Não se esqueça de menciona-lo na sua documentação.
+- Adicionamente, use `nvm` e crie um arquivo `.nvmrc` na raíz do seu projeto. Não se esqueça de menciona-lo na sua documentação.
 
   _Por que?_
 
@@ -312,7 +312,7 @@ Ter um bom padrão para criar commits e se atentar a ele faz com que trabalhar c
 
 ![Github](/images/modules.png)
 
-- Acompanhe seus pacotes disponíveis atualmente: e.g., `npm ls --depth=0`. [Leia mais sobre...](https://docs.npmjs.com/cli/ls)
+- Acompanhe seus pacoes disponíveis atualmente: e.g., `npm ls --depth=0`. [Leia mais sobre...](https://docs.npmjs.com/cli/ls)
 - Confira se algum dos seus pacotes não está em uso ou se tornou irrelevante: `depcheck`. [Leia mais sobre...](https://www.npmjs.com/package/depcheck)
 
   _Por que?_
@@ -329,14 +329,14 @@ Ter um bom padrão para criar commits e se atentar a ele faz com que trabalhar c
 
   _Por que?_
 
-  > Ter muitos contribuidores não var ser tão efetivo se os mantenedores não fizerem os merge fixes e patches rápido.
+  > Ter muitos contribuidores não var ser tão efetivo quando se os mantenedores não fizerem os merge fixes e patches rápido.
 
 - Se você precisa de uma dependência menos conhecida, discuta com o time antes de usa-la.
 - Sempre tenha certeza que sua aplicação funciona com a ultima versão das dependências: `npm outdated`. [Leia mais sobre...](https://docs.npmjs.com/cli/outdated)
 
   _Por que?_
 
-  > Atualização de dependência as vezes possuem 'breaking changes'. Sempre confira a descrição da nova versão sempre que sair, isso faz com que lidar com os possíveis problemas seja mais fácil. Use uma dessas ferramentas maneiras, como: [npm-check-updates](https://github.com/tjunnone/npm-check-updates).
+  > Atualização de dependência as vezes possuem 'breaking changes'. Sempre confira a descrição da nova versão sempre que sair, isso faz com que lidar com os possíveis problemas seja mais fáceis. Use uma dessas ferramentas maneiras, como: [npm-check-updates](https://github.com/tjunnone/npm-check-updates).
 
 - Confira problemas de segurança com a dependência que você quer adicionar, e.g., [Snyk](https://snyk.io/test?utm_source=risingstack_blog).
 
@@ -382,7 +382,7 @@ Ter um bom padrão para criar commits e se atentar a ele faz com que trabalhar c
 
   _Por que?_
 
-  > Você não quer ser a pessoa a fazer com que a branch com código pronto para produção pare de funcionar. Rode seus teste depois que fizer `rebase` e antes de fazer push para sua feature branch.
+  > Você não quer ser a pessoa a fazer a branch com código pronto para produção parar de funcionar. Rode seus teste depois que fizer `rebase` e antes de fazer push para sua feature branch.
 
 - Documente seus testes incluindo instruções importantes em uma seção no arquivo `README.md`.
 
@@ -472,7 +472,7 @@ Ter um bom padrão para criar commits e se atentar a ele faz com que trabalhar c
 
   _Por que?_
 
-  > Nós simplesmente preferimos `eslint`, você não precisa necessariamente o usar. Ele tem mais regras suportadas, a possibilidade de configura-las e criar regras customizadas.
+  > Nós simplesmente preferimos `eslint`, você não precisa necessariamente. `eslint` da suporte a mais regras, a possibilidade de configura-las e criar regras customizadas.
 
 - Nós usamos [Airbnb JavaScript Style Guide](https://github.com/airbnb/javascript) para JavaScript, [Leia mais sobre](https://www.gitbook.com/book/duk/airbnb-javascript-guidelines/details). Escolha os padrões necessário para seu projeto.
 
@@ -492,7 +492,7 @@ Ter um bom padrão para criar commits e se atentar a ele faz com que trabalhar c
 
   _Por que?_
 
-  > É normal desabilitar o `eslint` para focar na lógica de uma parte do código. Apenas se lembre de remover o `eslint-disable` quando terminar.
+  > É normal desabilitar o `eslint` para focar na lógica de uma parte do código. Apenas se lembre de remover o `eslint-disable` quando terminar.rules.
 
 - Dependendo do tamanho da task, use comentários com `//TODO:` para ajudar na criação de novas tasks para o backlog.
 
@@ -526,7 +526,7 @@ Ter um bom padrão para criar commits e se atentar a ele faz com que trabalhar c
 
   _Por que?_
 
-  > O EditorConfig consiste em um arquivo para edição de estilo de código e declaração de plugins para habilitar o editor a ler os arquivos em um determinado formato e  formatá-los de acordo com o esperado. EditorConfig são fáceis de ler e funcionam muito bem com sistemas de controle de versão.
+  > O EditorConfig consiste em um arquivo para edição de estilo de código e declaração de plugins para habilitar o editor a ler os arquivos em um determinado formato e  formarta-los de acordo com o esperado. EditorConfig são fáceis de ler e funcionam muito bem com sistemas de controle de versão.
 
 - Configure seu editor para alertar sobre erros de estilo de código. Use [eslint-plugin-prettier](https://github.com/prettier/eslint-plugin-prettier) e [eslint-config-prettier](https://github.com/prettier/eslint-config-prettier) com seu arquivo ESLint já existente. [Leia mais sobre...](https://github.com/prettier/eslint-config-prettier#installation)
 
@@ -578,7 +578,7 @@ _Por que?_
 
   > Falta de consistência e simplicidade podem aumentar de forma expressiva os custos de manutenção e integração. E por isso `API design` está nesse documento.
 
-- Devemos seguir o padrão orientado a recursos. O qual tem 3 principais fatore: recursos, coleções, e URLs.
+- Devemos seguir o padrão orientado a recursos. O qual tem 3 principais fatore: recursos, coleçÕes, e URLs.
 
   - Um recurso possui dados, gets aninhados, e methods para permitir operações.
   - Um grupo de recursos é chamado coleção.
@@ -598,7 +598,7 @@ _Por que?_
 
   > Basicamente, é melhor para ler e torna a URL mais consistente. [Leia mais sobre...](https://apigee.com/about/blog/technology/restful-api-design-plural-nouns-and-concrete-names)
 
-- No código fonte, converta plurais para variáveis e propriedades com uma lista de sufixos.
+- No código fonte, converta plurals para variáveis e propriedades com uma lista de sufixos.
 
   _Por que?_
 
@@ -625,7 +625,7 @@ _Por que?_
 
   _Por que?_
 
-  > Porque se você usar verbos para cada operação em um recurso você vai acabar com uma lista enorme de URLs e nenhum padrão consistente, o que torna difícil para desenvolvedores lerem. Além disso, nos usamos verbos para outra situação.
+  > Porque se você usar verbos para cada operação em um recurso você vai acabar com uma lista enrome de URLs e nenhum padrão consistente, o que torna difícil para desenvolvedores lerem. Além disso, nos usamos verbos para outra situação.
 
 - Use verbos para 'não recursos'. Nesse caso, sua API não retorna nenhum recurso. Ao invés, você executa uma operação que retorna um resultado. Essas **não são** operações de um CRUD (criar, ler, atualizar, e deletar):
 
@@ -641,18 +641,19 @@ _Por que?_
 
   _Por que?_
 
-  > Esse é um padrão de projeto para JavaScript, onde a linguagem usada para gerar e parsear JSON é, em teoria, JavaScript.
+  > Esse é um padrão de proejto para JavaScript, onde a linguagem usada para gerar e parsear JSON é, em teoria, JavaScript. 
 
-- Mesmo que um recurso seja um conceito singular, similar à uma instância ou registro do banco de dados, você não deve usar `nome_da_tabela` para o nome de um recurso e `nome_da_coluna` para a propriedade de um recurso.
+- Mesmo que um recurso seja um conceito singular, similar à uma instancia ou registro do banco de dados, você não deve usar `nome_da_tabela` para o nome de um recurso e `nome_da_coluna` para a propriedade de um recurso.
 
   _Por que?_
 
   > Porque sua intenção é expor os recursos, não detalhes do schema do seu banco de dados. 
 
-- Novamente, apenas use substantivos quando nomeando a URL de um recurso e não tente explicar a funcionalidade.
+- Novamente, apenas use substantivos quando nomeando a URL de um recurso e não tente explica a funcionalidade. 
 
   _Por que?_
 
+  > Only use nouns in your resource URLs, avoid endpoints like `/addNewUser` or `/updateUser` . Also avoid sending resource operations as a parameter.
   > Apenas use substantivos nos recursos na URL, evite coisas como `/addNewUser` ou `/updateUser`. Também, evite enviar operações sobre os recursos como parâmetros.
 
 - Explicite as operações de CRUD usando funcionalidades do métodos HTTP:
@@ -730,12 +731,14 @@ _Por que?_
 
   _Por que?_
 
-  > Desenvolvedores dependem de erros bem descritivos em momentos críticos quando eles estão com dificuldades resolvendo problemas da aplicação que eles construíram usando sua API.
+  > Desenvolvedores dependem de erros bem descritivos em momentos críticos quando eles estão com dificuldades resolvendo problemas da aplicação que eles construiram usando sua API.
 
-    _Nota: Mantenha mensagens relacionadas a exceções de segurança o mais genéricas possível. Por exemplo, ao invés de 'Senha incorreta', você pode responder dizendo 'Usuário ou senha inválidos' para que não vaze informações sobre dados corretos que não deveriam ser conhecido por terceiros._
+    _Nota: Mantenha mensagens relacionadas a exceções de segurança o mais genéricas possível. Por exemplo, ao invés de 'Senha incorreta', você pode responder dizendo 'Usuário ou senha inválidos' para que não vazamos informações sobre dados corretos que não deveriam ser conhecido por terceiros._
     
-- Use códigos de status para enviar e descrever suas respostas ao invés de **tudo funcionou corretamente**,
+- Use these status codes to send with your response to describe whether **everything worked**,
-   **App do cliente fez algo errado** ou A **API fez algo errado**.
+  The **client app did something wrong** or The **API did something wrong**.
+- Use códigos de status para enviar descrever suas respostas ao invés de **tudo funcionou corrretamente**,
+  O **App do cliente fez algo errado** ou A **API fez algo errado**.
 
   _Quais?_ > `200 OK` resposta de sucesso para requisições `GET`, `PUT` ou `POST`.
 
@@ -749,11 +752,11 @@ _Por que?_
 
       > `401 Unauthorized` para quando a requisição não possui credenciais suficientes para ser executada.
 
-      > `403 Forbidden` siginifica que o servidor entendeu a requisição mas se recusa a realizá-la.
+      > `403 Forbidden` siginifica que o servidor entendeu a requisição mas recusa a realiza-la.
 
       > `404 Not Found` indica que o recurso da requisição não foi encontrado.
 
-      > `500 Internal Server Error` indica que a requisição foi recebida mas devida à algum erro interno a requisição não pode ser completada.
+      > `500 Internal Server Error` indica que a requisição foi recebida mas devida algum erro interno a requisição não pode ser completada.
 
       _Por que?_
 
@@ -783,7 +786,7 @@ Algumas boas práticas básicas de segurança:
 
 - Códigos de autorização devem ter "tempo de vida curto".
 
-- Rejeite qualquer requisição não-TLS não respondendo nenhuma requisição HTTP para evitar vazamento de dados. Apenas responda `403 Forbidden`.
+- Rejeite qualquer requisição não-TLS não respondendo nenhuma requisição HTTP para evitar vazamento de dados. Apenas resposnda `403 Forbidden`.
 
 - Considere usar Limite de requisições.
 
@@ -801,9 +804,9 @@ Algumas boas práticas básicas de segurança:
 
   _Por que?_
 
-  > Uma das principais preocupações lidando com JSON encoders é previnir JavaScript malicioso de ser executado no browser... Ou, se você está usando `node.js`, no servidor. É vital usar JSON corretamente serializados para evitar a execução de código enviado como input pelo broswer.
+  > Uma das principais preocupações lidando com JSON encoders é previnir JavaScript malicioso de ser executado no broswer... Ou, se você está usando `node.js`, no servidor. É vital usar JSON corretamente serializados para evitar a execução de código enviado como input pelo broswer.
 
-- Valide o content-type e na maioria dos casos use `application/*json` (Content-Type header).
+- Validate o content-type e na maioria dos casos use `application/*json` (Content-Type header).
 
   _Por que?_
 
@@ -830,7 +833,7 @@ Para cada `endpoint` explique:
 
 - Se o tipo da requisiçõa é POST, forneça alguns exemplos de código. Essa regra se aplica para parâmetros de URL também. Separe a seção entre `Requeridos` e `Opcionais`.
 
-- Resposta de sucesso, qual deveria ser o código de status e tem algum dado à ser retornado junto? Isso é útil quando as pessoas precisam saber o que os seus `callbacks` devem esperar:
+- Resposta de sucesso, qual deverias ser o código de status e tem algum dado à ser retornado junto? Isso é útil quando as pessoas precisam saber o que os seus `callbacks` devem esperar:
 
   ```
   Code: 200
@@ -847,7 +850,7 @@ Para cada `endpoint` explique:
   }
   ```
 
-* Use ferramentas de design de API, existem muitas ferramentas de código aberto para uma boa documentação como [API Blueprint](https://apiblueprint.org/) e [Swagger](https://swagger.io/).
+* Use ferramentas de desing de API, existem muitas ferramentas de código aberto para uma boa documentação como [API Blueprint](https://apiblueprint.org/) e [Swagger](https://swagger.io/).
 
 <a name="licensing"></a>
 
@@ -855,7 +858,7 @@ Para cada `endpoint` explique:
 
 ![Licensing](/images/licensing.png)
 
-Tenha certeza de usar recursos aos quais você possui o direito de uso. Se você usa bibliotecas, lembre-se de procurar por MIT, Apache ou BSD mas se você precisa modifica-las, então confira nos detalhes da licença. Imagens e vídeos com copyright podem te causar problemas.
+Tenha certeza de usar recursos aos quais você possui o direito de uso. Se você usa bibliotecas, lembre-se de procurar por MIT, Apache ou BSD mas se você precisa modifica-las, então confira nos detalhes da licensa. Imagens e vídeos com copyright podem te causar problemas.
 
 ---
 

README-ru.md

@@ -5,12 +5,12 @@
  | [English](./README.md)
  | [Português](./README-pt-BR.md)
 
-[<img src="./images/elsewhen-logo.png" width="180" height="180">](https://www.elsewhen.com/)
+[<img src="./images/elsewhen-logo.png" width="180" height="180">](http://elsewhen.co/)
 
 
 # Советы по созданию проектов &middot; [![ПРы приветствуются](https://img.shields.io/badge/PRs-welcome-brightgreen.svg?style=flat-square)](http://makeapullrequest.com)
 > Тогда как для некоторых разработка нового проекта - это прогулка по парку, то для других поддержка этого проекта -  полнейший кошмар.
-Здесь представлен список советов, которые мы нашли, написали, собрали и которые, как мы думаем, прекрасно подходят к большинству JavaScript проектов в [elsewhen](https://www.elsewhen.com).
+Здесь представлен список советов, которые мы нашли, написали, собрали и которые, как мы думаем, прекрасно подходят к большинству JavaScript проектов в [elsewhen](http://elsewhen.co).
 Если вы хотите поделиться лучшей практикой или считаете, что какой-нибудь из советов стоит убрать, [можете спокойно сообщить нам об этом](http://makeapullrequest.com).
 
 🔥 [Попробуйте](https://github.com/elsewhencode/react-redux-saucepan) наш [минималистичный react redux проект](https://github.com/elsewhencode/react-redux-saucepan) на Flow с горячей заменой кода (hot reloading) и серверным рендерингом (SSR, server-side rendering).
@@ -181,7 +181,7 @@
     _Зачем:_
     > Коммиты должны быть краткими и максимально сфокусированными; это не место для многословия. [узнать больше...](https://medium.com/@preslavrachev/what-s-with-the-50-72-rule-8a906f61f09c)
 
- * Начните краткое описание с заглавной буквы.
+ * Начните краткое описание со строчной буквы.
 
  * Не заканчивайте краткое описание точкой.
 

README-zh.md

@@ -5,13 +5,13 @@
 [РУССКИЙ](./README-ru.md) | 
 [Português](./README-pt-BR.md)
 
-[<img src="./images/elsewhen-logo.png" width="180" height="180">](https://www.elsewhen.com/)
+[<img src="./images/elsewhen-logo.png" width="180" height="180">](http://elsewhen.co/)
 
 # 项目规范 &middot; [![PRs Welcome](https://img.shields.io/badge/PRs-welcome-brightgreen.svg?style=flat-square)](http://makeapullrequest.com)
 
 JavaScript工程项目的一系列最佳实践策略
 
-> 当您在青葱的田野里翻滚一般欢乐（而不受约束）地开发一个新项目，对其他人而言维护这样一个项目简直就是一个潜在的可怕的噩梦。以下列出的指南是我们在[elsewhen](https://www.elsewhen.com)的大多数JavaScript项目中发现，撰写和收集的最佳实践（至少我们是这样认为的）。如果您想分享其他最佳实践，或者认为其中一些指南应该删除。[欢迎随时与我们分享](http://makeapullrequest.com)。
+> 当您在青葱的田野里翻滚一般欢乐（而不受约束）地开发一个新项目，对其他人而言维护这样一个项目简直就是一个潜在的可怕的噩梦。以下列出的指南是我们在[elsewhen](http://elsewhen.co)的大多数JavaScript项目中发现，撰写和收集的最佳实践（至少我们是这样认为的）。如果您想分享其他最佳实践，或者认为其中一些指南应该删除。[欢迎随时与我们分享](http://makeapullrequest.com)。
 - [Git](#git)
     - [一些git规则](#some-git-rules)
     - [Git工作流](#git-workflow)
@@ -565,7 +565,7 @@ _为什么：_
     ```
 
     _为什么：_
-    > 因为对于 CRUD，我们在`资源`或`集合`URL上使用 HTTP 自己带的方法。我们所说的动词实际上是指`Controllers`。您通常不会开发这些东西。[更多请阅读...](https://github.com/byrondover/api-guidelines/blob/master/Guidelines.md#controller)
+    > 因为对于 CRUD，我们在`资源`或`集合`URL上使用 HTTP 自己带的方法。我们所说的动词实际上是指`Controllers`。您通常不会开发这些东西。[更多请阅读...](https://byrondover.github.io/post/restful-api-guidelines/#controller)
 
 * 请求体或响应类型如果是JSON，那么请遵循`camelCase`规范为`JSON`属性命名来保持一致性。
 

README.md

@@ -5,12 +5,12 @@
  | [Русский](./README-ru.md)
  | [Português](./README-pt-BR.md)
 
-[<img src="./images/elsewhen-logo.png" width="180" height="180">](https://www.elsewhen.com/)
+[<img src="./images/elsewhen-logo.png" width="180" height="180">](http://elsewhen.com/)
 
 
 # Project Guidelines &middot; [![PRs Welcome](https://img.shields.io/badge/PRs-welcome-brightgreen.svg?style=flat-square)](http://makeapullrequest.com)
 > While developing a new project is like rolling on a green field for you, maintaining it is a potential dark twisted nightmare for someone else.
-Here's a list of guidelines we've found, written and gathered that (we think) works really well with most JavaScript projects here at [elsewhen](https://www.elsewhen.com).
+Here's a list of guidelines we've found, written and gathered that (we think) works really well with most JavaScript projects here at [elsewhen](http://elsewhen.co).
 If you want to share a best practice, or think one of these guidelines should be removed, [feel free to share it with us](http://makeapullrequest.com).
 
 <hr>
@@ -34,7 +34,6 @@ If you want to share a best practice, or think one of these guidelines should be
     - [API design](#api-design)
     - [API security](#api-security)
     - [API documentation](#api-documentation)
-- [Accessability](#a11y)
 - [Licensing](#licensing)
 
 <a name="git"></a>
@@ -48,7 +47,6 @@ There are a set of rules to keep in mind:
     
     _Why:_
     >Because this way all work is done in isolation on a dedicated branch rather than the main branch. It allows you to submit multiple pull requests without confusion. You can iterate without polluting the master branch with potentially unstable, unfinished code. [read more...](https://www.atlassian.com/git/tutorials/comparing-workflows#feature-branch-workflow)
-
 * Branch out from `develop`
     
     _Why:_
@@ -565,7 +563,7 @@ _Why:_
     ```
 
     _Why:_
-    > Because for CRUD we use HTTP methods on `resource` or `collection` URLs. The verbs we were talking about are actually `Controllers`. You usually don't develop many of these. [read more...](https://github.com/byrondover/api-guidelines/blob/master/Guidelines.md#controller)
+    > Because for CRUD we use HTTP methods on `resource` or `collection` URLs. The verbs we were talking about are actually `Controllers`. You usually don't develop many of these. [read more...](https://byrondover.github.io/post/restful-api-guidelines/#controller)
 
 * The request body or response type is JSON then please follow `camelCase` for `JSON` property names to maintain the consistency.
     
@@ -688,7 +686,7 @@ The **client app did something wrong** or The **API did something wrong**.
 
 * The amount of data the resource exposes should also be taken into account. The API consumer doesn't always need the full representation of a resource. Use a fields query parameter that takes a comma separated list of fields to include:
     ```
-    GET /students?fields=id,name,age,class
+    GET /student?fields=id,name,age,class
     ```
 * Pagination, filtering, and sorting don’t need to be supported from start for all resources. Document those resources that offer filtering and sorting.
 
@@ -756,46 +754,17 @@ For each endpoint explain:
 * Error Response, Most endpoints have many ways to fail. From unauthorized access to wrongful parameters etc. All of those should be listed here. It might seem repetitive, but it helps prevent assumptions from being made. For example
     ```json
     {
-        "code": 401,
+        "code": 403,
         "message" : "Authentication failed",
         "description" : "Invalid username or password"
     }   
     ```
 
+
 * Use API design tools, There are lots of open source tools for good documentation such as [API Blueprint](https://apiblueprint.org/) and [Swagger](https://swagger.io/).
 
-<a name="a11y"></a>
-## 10. Accessibility ([a11y](https://www.a11yproject.com/))
-![Accessibility](/images/accessibility.png)
-
-* Take the following steps **at the start of your project** to ensure an intentional level of accessibility is sustained:
-    _Why:_
-    > Web content is [accessibile by default](https://developer.mozilla.org/en-US/docs/Learn/Accessibility/HTML). We compromise this when we build complex features. It's much easier to reduce this impact by considering accessibility from the start, rather than having to re-implement these features later.
-
-    * Arrange to do regular audits using [lighthouse](https://www.notion.so/elsewhen/Accessibility-at-Elsewhen-5e495685b508402bad209b8804922922#1302363f87ac49bd9d3ffe9cd721ef1a) or the [axe DevTools extension](https://www.notion.so/elsewhen/Accessibility-at-Elsewhen-5e495685b508402bad209b8804922922#1302363f87ac49bd9d3ffe9cd721ef1a). Agree a minimum score based on your projects requirements. The scoring in both tools is based on [axe user impact assessments](https://github.com/dequelabs/axe-core/blob/develop/doc/rule-descriptions.md#wcag-21-level-a--aa-rules).
-        > **Note:** [some important checks](https://web.dev/lighthouse-accessibility/#additional-items-to-manually-check) must be done manually, eg logical tab order. The above tools list these as manual/guided tests alongside the automated results. With axe you have to save your automated results to view these.
-
-    * Install an a11y linter:
-        - React: [eslint-plugin-jsx-a11y](https://www.npmjs.com/package/eslint-plugin-jsx-a11y)
-        - Angular: [Angular Codelyzer](https://github.com/mgechev/codelyzer)
-        - Vue: [eslint-plugin-vuejs-accessibility](https://github.com/vue-a11y/eslint-plugin-vuejs-accessibility)
-
-        _Why:_
-        > A linter will automatically check that a basic level of accessibility is met by your project and is relatively easy to set up.
-
-    * Set up and use a11y testing using [axe-core](https://www.notion.so/elsewhen/Accessibility-at-Elsewhen-5e495685b508402bad209b8804922922#7e83a08d6a794cab8a2bfc8c9a6ed11f) or similar. If you're using storybook, do [this](https://storybook.js.org/blog/accessibility-testing-with-storybook/).
-
-        _Why:_
-        > Including a11y checks in your tests will help you to catch any changes that affect your projects accessibility and your audit score.
-
-    * Consider using an accessible design system such as [React Spectrum](https://react-spectrum.adobe.com/react-spectrum/) or [Material Design](https://material.io/design).
-        
-        _Why:_
-        > These components are highly accessible out of the box
-
-
 <a name="licensing"></a>
-## 11. Licensing
+## 10. Licensing
 ![Licensing](/images/licensing.png)
 
 Make sure you use resources that you have the rights to use. If you use libraries, remember to look for MIT, Apache or BSD but if you modify them, then take a look at the license details. Copyrighted images and videos may cause legal problems.

README.sample.md

@@ -1,4 +1,4 @@
-<img src="./images/logo.sample.png" alt="Logo of the project" align="right">
+![Logo of the project](./images/logo.sample.png)
 
 # Name of the project &middot; [![Build Status](https://img.shields.io/travis/npm/npm/latest.svg?style=flat-square)](https://travis-ci.org/npm/npm) [![npm](https://img.shields.io/npm/v/npm.svg?style=flat-square)](https://www.npmjs.com/package/npm) [![PRs Welcome](https://img.shields.io/badge/PRs-welcome-brightgreen.svg?style=flat-square)](http://makeapullrequest.com) [![GitHub license](https://img.shields.io/badge/license-MIT-blue.svg?style=flat-square)](https://github.com/your/your-project/blob/master/LICENSE)
 > Additional information or tag line
@@ -70,7 +70,8 @@ We can maybe use [SemVer](http://semver.org/) for versioning. For the versions a
 
 ## Configuration
 
-Here you should write what are all of the configurations a user can enter when using the project.
+Here you should write what are all of the configurations a user can enter when
+using the project.
 
 ## Tests