Diverses corrections (surtout typographiques)

Coucou, 

Déjà je tiens à te remercier pour avoir écrit ce guide, et le distribuer librement sur Internet. Tes conseils et retours d'expérience sont très intéressants, et j'avais envie de mettre des « +1 » quasiment partout sur les points dont j'ai déjà fait l'expérience. :D

Au fil de ma lecture, j'ai relevé quelques erreurs et/ou inconsistances typographiques. Étant plutôt maniaque à ce sujet, et comme tu propose si gentiment de *forker* et contribuer, je me suis empressé de cloner ton repo pour faire ces quelques corrections. Tout est détaillé en-dessous *(je copie les messages de commit ici pour bénéficier de l'interprétation Markdown)*.

J'ai également quelques [questions](#questions).

## Commits

### Factorisation du titre et de la description

Le Gruntfile utilise désormais les données du `package.json` plutôt que ce copier/coller les infos.

### Corrections typographiques en tout genre

Corrections typographiques en tout genre

* Utilisation de guillemets français `«»` à la place des *quotes* anglaises (c'était inconsistant selon les pages).

* Utilisation du caractère UTF-8 `…` pour les points de suspention plutôt que trois points consécutifs (on trouvait aussi un peu des deux selon les pages).

* Ajout d'espaces insécables devant les caractères `&,:,;,!,?,%`, autour des guillemets français et des tirets de césure, *et avant les smileys (OUI BAH OUI)*. Ça permet en particulier de corriger les problèmes de ce type :

  ![Bug espaces insécables 1](http://image.noelshack.com/fichiers/2014/34/1408882333-2014-08-24-141212-825x83-scrot.png)
  ![Bug espaces insécables 2](http://image.noelshack.com/fichiers/2014/34/1408882460-2014-08-24-141420-790x84-scrot.png)

* Pas de `…` après un « etc. » ! *(C'est l'un, ou l'autre, pas les deux.)*

* En anglais, capitalisation des nom de langues.

* Dans les titres en anglais, pas d'espace avant le caractère `:` (entre autres).

* En français, pas de capitalisation des langues/pays/unions si utilisé en tant qu'adjectif.

* Mise en italique des des parenthèses et guillemets lorsque tout le contenu est en italique.

* Capitalisation et typographie des noms de logiciels / formats / sites webs selon la casse « officielle ».

* Capitalisation des acronymes.

* Adaptation des titres entre le sommaire et le titre de page (sur certaines pages, le lien du sommaire et le titre de la page ne correspondaient pas).

* Utilisation de tiret cadratin pour délimiter une citation de son auteur. Ça évite que Markdown interprète l'auteur comme une liste non-ordonnée.

  ![Bug liste non-ordonnée](http://image.noelshack.com/fichiers/2014/34/1408882673-2014-08-24-141753-398x82-scrot.png)

* Point virgule pour séparer les éléments d'une liste.

* Consistence pour les encarts (de type « Note ») : formatage systématique dans une citation de type bloc (c'était le plus commun dans ce projet), et mise en `<strong>` du « Note » et des `:` qui suivent, e.g. :

  ```md
  > **Note :** ceci est une note.
  ```

  > **Note :** la phrase qui suit ne commence pas par une majuscule, la phrase commence bel et bien au « Note » (mais cette règle était déjà respectée).

* Capitalisation systématique du mot *Internet* (ça variait selon les pages).

* Ajout d'une mention à Redshift dans le paragraphe qui parle d'adaptation de la luminosité des écrans, juste après l'évocation de f.lux.

* Correction de fautes d'orthographe mineures :
  * ~~Celle-la~~ Celle-là
  * Et en fait, c'est tout. GG.

* J'ai enlevé des italiques sur l'acronyme « CC », des fois il était en italique, des fois non. C'est discutable…

* Mention des makefiles dans la partie sur les outils d'automation. J'ai mis un lien vers un article de SitePoint car c'est la page la plus simple d'accès que je connais comme introduction aux makefiles, du moins pour des gens qui sont peu habitués à la ligne de commande et aux *man pages*. Le lien de référence serait plutôt le suivant : <http://pubs.opengroup.org/onlinepubs/009695399/utilities/make.html>, mais j'ai peur que ça fasse fuir les gens plutôt qu'autre chose. Malgré tout je trouve ça intéressant d'évoquer les makefiles, c'est un outil très pratique et léger quand on bosse en environnement POSIX. Encore une fois, cet ajout est discutable, libre à toi de juger de sa pertinence.

## Questions

J'ai corrigé quelques titres dont le titre du sommaire n'était pas équivalent au titre de la page, mais il en reste deux pour lesquels je n'ai pas su trancher :

* « Centralisé ou décentralisé ? » (sommaire) ou « Centralisés ou décentralisés ? » (titre) ?
* « Bonnes pratiques & conventions » (sommaire) ou « Bonnes pratiques et conventions » (titre) ?

---

À propos des serveurs de type Apache/PHP/MySQL, dans `methodo/workflow.md` :

> Ceci dit, les outils d'automation comme Gulp, Grunt et CodeKit, cités plus haut, permettent de
faire la même chose aussi.

Je ne connais pas CodeKit, mais j'ai du mal à voir comment tu peux remplacer un classique \*AMP par Gulp ou Grunt, en particulier dans le cas où tu veux exécuter du PHP et avoir une base de données MySQL…

---

À propos du versionning centralisé ou décentralisé, dans `versionning/centralise-ou-decentralise.md` :

> Pour les sites clients, qui ne sont généralement que des templates, feuilles de styles et images, j'utilise **SVN**, qui me permet de ne mettre en ligne que certaines parties du dépôt.

Je ne comprend pas le « qui me permet de ne mettre en ligne que certaines parties du dépôt ». Du moins ce qu'il y a de spécifique à SVN… c'est pas ce qu'on ferait simplement avec un `.gitignore` sur Git (ou encore plus simplement, en ne faisant pas de `git add` sur certains fichiers ? Et pire, j'ai jamais réussi sous SVN à mettre en place un équivalent (du genre `.svnignore`), alors que c'est un jeu d'enfant avec Git.

---

À propos du « petit conseil d'organisation » sur le branching, dans `versionning/petit-conseil-organisation.md` :

> Un dernier petit conseil d'organisation pratique : créez une branche **dev** et **prod** sur vos projets.

Dans ce cas là, que devient `master` ? Sur *A successful Git branching model* (que tu cites d'ailleurs), la branche `master` a l'air de servir de branche `prod`, right ? Tu n'as pas de `master`, du coup ? Sinon, quelle sémantique tu lui donne ?

---

Et un dernier point ; j'ai été surpris de voir que les `<em>` sont affichés en gras. Je ne sais pas si c'est un choix de ta part, ou si c'est « juste le thème » (je ne connais pas assez bien GitBooks pour savoir si c'est un thème original ou pas), mais en tout cas c'est un choix typographique qui me surprend. L'italique est souvent plus lisible que le gras, dans la mesure où il met en emphase certains bouts de phrase sans pour autant attirer l'œil de façon trop violente (comme c'est le cas avec le gras). Voir la partie « Souligné, gras ou italique ? » de [ce PDF](http://tex.loria.fr/typographie/typo.pdf).