Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add french translation #148

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
145 changes: 145 additions & 0 deletions README-fr.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,145 @@

[中文版](./README-zh.md)
| [日本語版](./README-ja.md)
| [한국어](./README-ko.md)
| [Русский](./README-ru.md)
| [Português](./README-pt-BR.md)

[<img src="./images/elsewhen-logo.png" width="180" height="180">](http://elsewhen.co/)


# Lignes directrices de projet &middot; [![Les PRs sont les bienvenues](https://img.shields.io/badge/PRs-welcome-brightgreen.svg?style=flat-square)](http://makeapullrequest.com)
> En développant un nouveau projet, c'est comme rouler sur un terrain vierge pour vous; le maintenir est un cauchemar sombre et tordu pour quelqu'un d'autre.
Voici une liste de lignes directrices que nous avons trouvé, écrit et rassemblé que (nous pensons) fonctionne très bien avec la plupart des projets JavaScript ici à[elsewhen](http://elsewhen.co).
Si vous voulez partager une pratique exemplaire ou si vous pensez qu'une de ces lignes directrices devrait être supprimée,[n'hésitez pas à nous en faire part] (http://makeapullrequest.com).
<hr>

- [Git](#git)
- [Quelques règles Git](#some-git-rules)
- [Workflow Git](#git-workflow)
- [Ecrire de bon messages de commit](#writing-good-commit-messages)
- [Documentation](#documentation)
- [Environments](#environments)
- [Consistent dev environments](#consistent-dev-environments)
- [Consistent dependencies](#consistent-dependencies)
- [Dependences](#dependencies)
- [Test](#testing)
- [Structure et dénomination](#structure-and-naming)
- [Code style](#code-style)
- [Some code style guidelines](#code-style-check)
- [Enforcing code style standards](#enforcing-code-style-standards)
- [Logging](#logging)
- [API](#api)
- [API design](#api-design)
- [API security](#api-security)
- [API documentation](#api-documentation)
- [Licence](#licensing)

<a name="git"></a>
## 1. Git
![Git](/images/branching.png)
<a name="some-git-rules"></a>

### 1.1 Quelques règles Git
Il y a un ensemble de règles à garder à l'esprit :

<a name="git-workflow"></a>
### 1.2 Workflow Git

<a name="writing-good-commit-messages"></a>
### 1.3 Ecrire de bon messages de commit

<a name="documentation"></a>
## 2. Documentation

![Documentation](/images/documentation.png)

* Utilisez ce [modèle](./README.sample.md) pour le `README.md`, ajoutez des sections non couverte si nécessaire.
* Pour des projects ayant plus d'un repository, donnez des liens vers eux dans leurs fichiers `README.md' respectifs.
* Gardez le `README.md` à jour au fur et à mesure que le projet évolue.
* Commentez votre code. Essayez de le rendre aussi clair que possible ce que vous prévoyez dans chaque section majeure.
* S'il y a une discussion ouverte à propos du code ou de l'approche que vous utilisez sur github ou stackoverflow, insérez le lien dans votre commentaire.
* N'utiliez pas des commentaires comme une excuse pour écrire un mauvais code. Gardez votre code propre.
* N'utiliez pas de code propre comme une excuse pour ne pas commentez du tout.
* Gardez des commentaires pertinents à mesure que le code évolue.

<a name="environments"></a>
## 3. Environments

![Environments](/images/laptop.png)


<a name="consistent-dev-environments"></a>
### 3.1 Consistent dev environments:

<a name="consistent-dependencies"></a>
### 3.2 Consistent dependencies:

<a name="dependencies"></a>
## 4. Dependences

![Github](/images/modules.png)


<a name="testing"></a>
## 5. Test
![Testing](/images/testing.png)

<a name="structure-and-naming"></a>
## 6. Structure et dénomination
![Structure and Naming](/images/folder-tree.png)


<a name="code-style"></a>
## 7. Code style

![Code style](/images/code-style.png)

<a name="code-style-check"></a>
### 7.1 Some code style guidelines



<a name="enforcing-code-style-standards"></a>
### 7.2 Enforcing code style standards

<a name="logging"></a>
## 8. Logging

![Logging](/images/logging.png)

<a name="api"></a>
## 9. API
<a name="api-design"></a>

![API](/images/api.png)

### 9.1 API design

_

<a name="api-security"></a>
### 9.2 API security

<a name="api-documentation"></a>
### 9.3 API documentation

<a name="licensing"></a>
## 10. Licence
![Licensing](/images/licensing.png)

Assurez-vous d'utiliser les ressources que vous avez le droit d'utiliser. Si vous utilisez des bibliothèques, n'oubliez pas de chercher MIT, Apache ou BSD mais si vous les modifiez, jetez un oeil aux détails de la licence. Des images et des vidéos protégées par le droit d'auteur peuvent causer des problèmes juridiques.


---
Sources:
[RisingStack Engineering](https://blog.risingstack.com/),
[Mozilla Developer Network](https://developer.mozilla.org/),
[Heroku Dev Center](https://devcenter.heroku.com),
[Airbnb/javascript](https://github.com/airbnb/javascript),
[Atlassian Git tutorials](https://www.atlassian.com/git/tutorials),
[Apigee](https://apigee.com/about/blog),
[Wishtack](https://blog.wishtack.com)

Icones par [icons8](https://icons8.com/)