Malheureusement, cet article qui était en bêta a été supprimé par son auteur.
Cet article est une proposition de charte typographique pour ZdS, dans le cadre de cette discussion. Merci de vous y reporter pour comprendre de quoi il en retourne.
Notez également que si une autre liste est imbriquée dans un telle liste
Ca n'a pas de sens d'imbriquer une liste dans une liste du premier type (comportant des phrases) ?
Notez, par ailleurs, que « etc. » signale à lui seul une énumération incomplète. Il est donc incorrecte de le répéter, ou de le faire suivre de points de suspension.
Tu pourrais ajouter un exemple pour illustrer "ou de le faire suivre de points de suspension".
par exemple, au Québec, common law est considéré
Pourquoi ne met-on pas de guillemets autour de "common law" ?
Il ne me semble pas que tu aies dit qu'il fallait utiliser des guillemets français plutôt qu'anglais (pour lesquels on ne met pas d'espaces), ni des tirets d’incise (au lieu de tiret normaux), ni si on devait mettre les accents sur les majuscules. D'un côté, on peut le déduire du fait que tu indiques comment obtenir ces symboles avec le clavier.
Comme d'hab, c'est de l'excellent boulot. Merci.
Pour la partie avec OS X (clavier français, je pense que les autres fonctionnent de la même manière) :
À, Ç, È, É, Ù: Verr maj puis touche correspondante
—: alt + -
–: shift + alt + -
œ: alt + o
Œ: shift + alt + o
…: alt + .
’: shift + alt + '
«: alt + è
»: shift + alt + è
espace-mot insécable: alt + space
Juste, j'aime la forme des trois blocs : à pas faire, à faire, et la justification. Simple, efficace ! sur le fond, rien à redire (lu en diagonal).
Salut,
Pour ma part, je trouve cette charte claire et assez simple à suivre. Merci pour la rédaction de celle-ci. 
J'ai juste une petite question concernant les listes imbriquées : que fait-on si l'on a trois listes imbriquées (ou plus), mise à part revoir notre copie ? 
Ca n'a pas de sens d'imbriquer une liste dans une liste du premier type (comportant des phrases) ?
Si, c’est juste que tu te contentes d’itérer récursivement. Tu peux soit terminer la phrase introductive par un point et utiliser des phrases complètes dans les éléments de niveau inférieur, soit terminer la phrase introductive par un deux-points et utiliser les points-virgules. Genre comme ça.
Tu pourrais ajouter un exemple pour illustrer "ou de le faire suivre de points de suspension".
Si tu veux… Ça veut juste dire que c’est incorrect d’écrire « etc… », ou pire encore « etc, … ». 
Pourquoi ne met-on pas de guillemets autour de "common law" ?
Parce qu’il est déjà en italique, pas besoin d’une double couche de mise en exergue.
Il ne me semble pas que tu aies dit qu'il fallait utiliser des guillemets français plutôt qu'anglais (pour lesquels on ne met pas d'espaces), ni des tirets d’incise (au lieu de tiret normaux), ni si on devait mettre les accents sur les majuscules. D'un côté, on peut le déduire du fait que tu indiques comment obtenir ces symboles avec le clavier.
J’ai hésité à le dire explicitement dans la dernière section, et je me suis dit que ce serait un peu trop insistant. Selon les retours, je l’ajouterai.
Comme d'hab, c'est de l'excellent boulot. Merci.
Vayel
Avé plaisir. 
@Luthaf : merci. Si quelqu’un a des infos pour les autres dispositions.
Juste, j'aime la forme des trois blocs : à pas faire, à faire, et la justification. Simple, efficace !
qwerty
Je me suis dit que ce serait le plus pédagogique.
J'ai juste une petite question concernant les listes imbriquées : que fait-on si l'on a trois listes imbriquées (ou plus), mise à part revoir notre copie ?
Taurre
Revoir ta copie. 
Plus sérieusement, cf. plus haut ma réponse à Vayel.
Je suis d'avis de simplifier le passage sur les listes. En l'état, ça fait juste décrocher. Les deux possibilités (points ou points-virgules) sont suffisantes et je ne pense pas que détailler les listes imbriquées soit vraiment nécessaire.
Beaucoup d'auteurs seront amenés à écrire autour des sciences et techniques, et c'est à mon avis intéressant d'avoir l'essentiel pour présenter les nombres avec leurs unités et éventuellement leur symbole.
Ce sera sûrement pour les versions suivantes (ou un autre document), mais d'avoir un point sur les erreurs courantes pourrait augmenter la qualité typographique des contenus avec un moindre effort. En bref, il s'agirait de prévenir ce qui pique les yeux et revient tout le temps.
J'ai noté deux typos en passant.
le tout de la question
le « tour »
Il est donc incorrecte de le répéter, ou de le faire suivre de points de suspension.
Un « e » en trop a « incorrect ».
Hello,
D'abord, un grand merci pour avoir pris le temps de faire ce tuto.
De mon point de vue, il est très intéressant, mais a perdu de vue le but d'origine, qui était : « Donner aux auteurs un moyen simple d'améliorer leur typographie sur Zeste de Savoir ».
Dans l'état actuel des choses, le tuto est long : 14 000 SEC sans lire aucun secret, 37 000 SEC en les lisant tous. Pour comparaison, le tuto sur les licences (avec explication du concept et historique) est à 19 500 SEC, la référence complète Markdown fait 18 000 SEC et l'article sur la rédaction des mathématiques 14 000 SEC.
Ma crainte est donc qu'en mettant fortement en avant un tel tuto on effraie l'auteur (en tous cas, personnellement je serais effrayé, par la longueur et la complexité des règles, cf ci-après). Une alternative serait de le laisser à disposition sans trop le mettre en avant (comme les autres contenus sus-cités), mais alors je crains qu'on ne s'éloigne du but recherché.
Afin de corriger ceci, je propose de revoir le plan, par exemple en le scindant en 3 parties :
D'autre part, il devrait être extrêmement clair pour le lecteur que :
Il est ainsi incorrect de terminer un paragraphe par un deux-points lorsqu’il introduit une image, une vidéo, un tableau, un bloc de code ou un bloc spécial (« Attention », « Information », etc.). Les légendes sous une image, un tableau, etc. et les notes de bas de page suivent cette même règle.
Personnellement, je ne vois pas le problème à laisser l'auteur libre sur ce point. J'utilise souvent cette convention car je la trouve plus claire, et annulerai toute modification visant à « corriger » mon texte. D'autant que d'après les justifications, on est dans une zone de flou (aucune interdiction ni obligation explicite).
En théorie, la dernière d’une série de formules mathématiques devrait être terminée par un point en romain, nettement séparé de la formule, mais cela est assez difficile à faire avec MathJax, aussi n’est-ce pas obligatoire sur Zeste de Savoir.
Si c'est « En théorie » et non appliqué sur ZdS, on en parle pas – ou alors dans la partie 3 selon mon plan. Outre le fait que pour le coup, je trouve le point à la fin de la formule perturbant pour la lecture.
Pour une énumération verticale, ou liste, deux situations sont possibles.
Règle compliquée –> partie 2
Ce point abréviatif fait partie intégrante du mot, et ne doit être omis que s’il est immédiatement suivi d’un point final ou de points de suspension.
Notez, par ailleurs, que « etc. » signale à lui seul une énumération incomplète. Il est donc incorrecte de le répéter, ou de le faire suivre de points de suspension.
Détails –> partie 2
Certaines de ces espaces sont censées être des espaces ordinaires, d’autres des espaces-mots insécables, d’autres encore des espaces fines insécables. Cependant, ces dernières sont mal gérées par les navigateurs
Alors on en parle pas, ou alors en partie 3.
Par conséquent, et dans un but de simplicité, il a été décidé d’utiliser des espaces ordinaires dans la rédaction, et de laisser le logiciel de gestion du markdown se charger des conversions.
Conversion = complexité supplémentaire dans un processus déjà lourd + risque de problèmes (notamment à cause de la présence de code dans le texte). C'est à éviter tant que possible, et pour moi le peaufinage d'une typographie ne justifie pas les risques et le développement/maintenance induits par cette conversion.
Lorsque vous citez une œuvre constituant un tout, son titre doit être en italique. Pour une partie au sein d’une œuvre plus vaste, en revanche, on met le titre entre guillemets. Il existe un certain nombre d’exceptions, mais vous avez là de quoi couvrir au moins 95 % des cas.
En partie 1, le fait que le titre doit être distingué du reste du texte (guillemets, italiques, …). En partie 2 la règle donnée. Les exceptions en partie 3.
Les mots, expressions ou phrases complètes en langue étrangère doivent être mis en italique […] Faites au mieux, en gardant à l’esprit que les mots du vocabulaire technique d’un domaine ont peu de chances d’être considérés comme du français courant. Un cas qui n’est pas abordé par les ouvrages de référence est celui des mots indubitablement étrangers, auxquels on a rajouté une terminaison française pour pouvoir les conjuguer : par exemple, « blacklister un site » ou « un portable rooté ». Ils témoignent d’un malaise indéniable, aussi, essayez d’employer un mot français, et si cela n’est vraiment pas possible, mettez le mot en italique.
Partie 2. De plus, on a beaucoup de tutos informatique qui utilisent massivement du jargon anglophone sans traduction massivement adoptée à utiliser à la place. Pour alléger à la fois le texte et le travail de tout le monde, ce jargon devrait être composé en romain comme le reste. La fait est est que dans le cadre de ce tuto ça devient du langage courant.
De plus, j'apprécie moyennement me faire traiter de nazi.
Cela est souvent répété : abuser des émoticônes nuit à la lisibilité et au sérieux du texte. Cependant, si vous en utilisez, placez-les après les signes de ponctuation.
L'usage courant est plutôt de les utiliser à la place de la ponctuation, en réalité – au grand dam de pas mal de monde.
Les commentaires [de code] sont très généralement des phrases comme les autres : respectez la typographie usuelle, en particulier le fait de mettre un point à la fin des phrases.
Ce serait bien mais dans la vraie vie ce n'est presque jamais le cas (et le but n'est jamais d'apprendre une théorie déconnectée de la réalité). Disons qu'on peut la mettre en partie 2, mais je reste dubitatif.
Je ne vois rien concernant l'usage des majuscules accentuées, des guillemets français et des trois points. Pour moi ces deux éléments devraient être dans la partie 2. Par contre, espaces spécifiques (autres que normale et insécable) et apostrophe typographiques devraient être en partie 3 (ils sont chiants à obtenir même avec un clavier bépo, et certains correcteurs signalent des fautes si des apostrophes typographiques sont utilisées…).
Les bons symboles
Je séparerais plus visuellement les 3 OS (avec des titres ?). Un titre dédié à bépo peut être intéressant, personnellement ça m'a beaucoup aidé, malgré l'investissement initial lourd.
Ce texte est placé sous licence BiPu,
Il me semblait que par convention, on préférait la licence CC-BY pour les écrits ayants trait à l'asso, mais ça ne semble pas respecté. À vérifier.
Je pense qu'on pourrait aussi alléger certaines tournures de phrases, parfois très « administratives » (j'ai pas d'autre mot à cette heure ). Je laisse les autres s'exprimer à ce sujet.
Voilà, j'espère que j'ai été clair et utile. Le but de ce (trop) long message n'est pas du tout de démonter l'excellent travail fait dans ce tuto, simplement de tenter d'en améliorer, à mon sens, l'équilibre entre respect des règles théoriques et emmerdement pour l'auteur lambda. D'ailleurs, mes propositions peuvent majoritairement s'appliquer à coup de copier/coller.
Salut,
Je plussoie la structure en trois parties proposée par SpaceFox.
Je propose d'ajouter également les définitions de certains termes tels que espaces insécables ou tirets semi-cadratins. Ou à défaut des définitions, au moins s'assurer qu'ils sont montrés "visuellement". Sinon tous ces beaux discours ne servent à rien pour ceux qui ne savent pas ce que ce sont ces symboles.
J'ai lu rapidement, ça me semble pas mal. Comme qwerty, je trouve la mise en forme claire et efficace.
PS : j'ai vu que plusieurs fois, les guillemets « » été évoquées : dans la prochaine version de l'assistant d'édition markdown, il sera possible de les utiliser directement.
Ce point abréviatif fait partie intégrante du mot, et ne doit être omis que s’il est immédiatement suivi d’un point final ou de points de suspension.
Notez, par ailleurs, que « etc. » signale à lui seul une énumération incomplète. Il est donc incorrecte de le répéter, ou de le faire suivre de points de suspension.Détails –> partie 2
Je pense, si le cours doit être divisé comme tu le décris, que cette indication mériterait d'être dans la première partie. Il s'agit d'une erreur assez fréquente et facile à éviter.
Les mots, expressions ou phrases complètes en langue étrangère doivent être mis en italique […] Faites au mieux, en gardant à l’esprit que les mots du vocabulaire technique d’un domaine ont peu de chances d’être considérés comme du français courant. Un cas qui n’est pas abordé par les ouvrages de référence est celui des mots indubitablement étrangers, auxquels on a rajouté une terminaison française pour pouvoir les conjuguer : par exemple, « blacklister un site » ou « un portable rooté ». Ils témoignent d’un malaise indéniable, aussi, essayez d’employer un mot français, et si cela n’est vraiment pas possible, mettez le mot en italique.
Partie 2. De plus, on a beaucoup de tutos informatique qui utilisent massivement du jargon anglophone sans traduction massivement adoptée à utiliser à la place. Pour alléger à la fois le texte et le travail de tout le monde, ce jargon devrait être composé en romain comme le reste. La fait est est que dans le cadre de ce tuto ça devient du langage courant.
Sur ce point, je ne suis pas d'accord. Avec une réflexion pareille, il n'y a plus besoin de mettre quoi que ce soit en italique puisque « les mots deviennent courant pour un texte donné ». Non, les règles et le français ne varient pas d'un texte à l'autre et, à mon sens, ce n'est pas la mort de demander la mise en italique des termes étrangers. J'ajouterai même que cela est bénéfique puisque cela fait réaliser à l'auteur qu'il utilise des termes étrangers et qu'il serait bon d'en trouver une traduction qui serait plus parlante pour le lecteur.
Je pense, si le cours doit être divisé comme tu le décris, que cette indication mériterait d'être dans la première partie. Il s'agit d'une erreur assez fréquente et facile à éviter.
Le non-respect des règles de la partie 1 est assez gênant pour la lecture pour qu'on refuse la publication d'un tuto qui les viole. Ce n'est pas le cas de cette règle.
Sur ce point, je ne suis pas d'accord. Avec une réflexion pareille, il n'y a plus besoin de mettre quoi que ce soit en italique puisque « les mots deviennent courant pour un texte donné ». Non, les règles et le français ne varient pas d'un texte à l'autre et, à mon sens, ce n'est pas la mort de demander la mise en italique des termes étrangers. J'ajouterai même que cela est bénéfique puisque cela fait réaliser à l'auteur qu'il utilise des termes étrangers et qu'il serait bon d'en trouver une traduction qui serait plus parlante pour le lecteur.
Tu n'as pas bien compris ce que je voulais dire : je parle justement du jargon sans traduction massivement adoptée, qui serait donc très lourd à mettre systématiquement en italique et dont l'usage est normal dans le contexte concerné.
Exemple : je fais un tuto sur Git. L'immense majorité des concepts de Git n'ont aucune traduction communément admise et usitée (certains disent « pousser » pour « push », mais personne ou presque ne comprends « tirer » pour « pull »). Ce n'est pas non plus du code parce que je parle là des concepts et non des commandes associées. Imposer une traduction arbitraire rendrait le tuto incompréhensible pour ceux qui connaissent déjà Git, et pire, empêcherait ceux qui n'ont suivi que ce tuto de communiquer correctement avec ceux qui ne l'ont pas suivi par manque du vocabulaire réellement utilisé.
La théorie dit donc qu'on devrait barder le texte de mots en italique, puisque presque tous les concepts enseignés sont des mots anglais. Je l'ai fait dans un document interne à ma boite, c'est insupportable à lire comme à écrire.
Ce que je dis, c'est que dans ce genre de cas – et il est fréquent en informatique – les mots étrangers qui sont directement imposés par le sujet traité doivent être considérés comme du langage courant (ce qu'ils sont de fait) et écrits en romain.
Le non-respect des règles de la partie 1 est assez gênant pour la lecture pour qu'on refuse la publication d'un tuto qui les viole. Ce n'est pas le cas de cette règle.
À mon sens, le non-respect des espacements pour les signes de ponctuations, du moment qu'il est cohérent (par exemple, comme c'est souvent le cas, l'utilisation des conventions anglophones), n'est pas non plus gênant pour la lecture. Pourtant, il est également dans la première partie. Je pense qu'on peut y mettre également les règles simples même si elles s'apparentent plus à du détail.
Sur ce point, je ne suis pas d'accord. Avec une réflexion pareille, il n'y a plus besoin de mettre quoi que ce soit en italique puisque « les mots deviennent courant pour un texte donné ». Non, les règles et le français ne varient pas d'un texte à l'autre et, à mon sens, ce n'est pas la mort de demander la mise en italique des termes étrangers. J'ajouterai même que cela est bénéfique puisque cela fait réaliser à l'auteur qu'il utilise des termes étrangers et qu'il serait bon d'en trouver une traduction qui serait plus parlante pour le lecteur.
Tu n'as pas bien compris ce que je voulais dire : je parle justement du jargon sans traduction massivement adoptée, qui serait donc très lourd à mettre systématiquement en italique et dont l'usage est normal dans le contexte concerné.
J'avais bien compris.
Exemple : je fais un tuto sur Git. L'immense majorité des concepts de Git n'ont aucune traduction communément admise et usitée (certains disent « pousser » pour « push », mais personne ou presque ne comprends « tirer » pour « pull »). Ce n'est pas non plus du code parce que je parle là des concepts et non des commandes associées. Imposer une traduction arbitraire rendrait le tuto incompréhensible pour ceux qui connaissent déjà Git, et pire, empêcherait ceux qui n'ont suivi que ce tuto de communiquer correctement avec ceux qui ne l'ont pas suivi par manque du vocabulaire réellement utilisé.
La théorie dit donc qu'on devrait barder le texte de mots en italique, puisque presque tous les concepts enseignés sont des mots anglais. Je l'ai fait dans un document interne à ma boite, c'est insupportable à lire comme à écrire.
À mes yeux, s'il y doit y avoir autant de mise en italique, c'est qu'il y a un problème dans la rédaction. À un moment donné, il me paraît nécessaire de tenter d'expliquer les choses en français quitte à sortir des sentiers battus. Il ne me semble pas insurmontable de traduire « push request » et « pull request » avec des mots simples et porteurs de sens.
Je pense, mais cela n'engage que moi, qu'il serait bénéfique de pousser les auteurs dans cette voie justement en leur faisant réaliser, par la mise en forme, qu'il y a un problème. Je réalise que c'est un point de vue peut-être un peu excessif (quoi qu'utilisé auparavant, il suffit de lire des livres d'informatique un peu plus anciens pour s'en convaincre), mais je ne peux m'empêcher de penser que le résultat serait bénéfique.
Dans la vraie vie, personne ne traduit "pull request". Le terme doit donc être utilisé.
Zeste de Savoir est là pour faire des tutos utiles, pas pour faire du prosélitisme francophone.
Ce n'est qu'une suggestion, il n'est pas nécessaire de se braquer.
Dans la vraie vie, personne ne traduit "pull request". Le terme doit donc être utilisé.
C'est parfaitement ton droit, mais certains le font. Par exemple, « faire un commit » peut être traduit par « archiver », de même qu'une requête push revient finalement à synchroniser les données sur le serveur. La « vraie vie » est plurielle.
Non, mais c'est lourd de voir ce genre de suggestion alors que le but du topic est précisément de trouver des compromis le plus simples pour tout le monde.
Quant aux termes Git que tu utilises, je ne les ai jamais vus, même sur LinuxFR ou dans les traductions bizarres des logiciels que j'ai testés. Je ne dis pas que ça n'existe pas, mais que le consensus de non-traduction est massif.
Non, mais c'est lourd de voir ce genre de suggestion alors que le but du topic est précisément de trouver des compromis le plus simples pour tout le monde.
Ben c'est-à-dire qu'ici, on a bien une règle simple : les mots étrangers seraient mis en italique. Après, tu as raison, dans certains cas, cela peut faire beaucoup de mise en forme. Cependant, et c'est là l'objectif de mon propos, cela est peut-être le signe que l'auteur peine à expliquer ses propos en français. Je ne dis pas qu'il faut refuser les contenus sous prétexte qu'il y a un faible effort de traduction (ce serait stupide), mais je pense qu'il peut être bénéfique d'encourager les auteurs à écrire et expliquer en français.
Je veux dire, franchement : tu penses qu'il n'est pas possible de rédiger un cours sur Git sans avoir des push, pull et commit à tous les coins de rues ? Ces mots vont forcément apparaître puisqu'il s'agit de commandes, mais ce n'est pas pour autant que leurs actions ne peuvent pas être traduites.
Quant aux termes Git que tu utilises, je ne les ai jamais vus, même sur LinuxFR ou dans les traductions bizarres des logiciels que j'ai testés. Je ne dis pas que ça n'existe pas, mais que le consensus de non-traduction est massif.
À mon grand désespoir, il y a peut d'effort de traduction, en effet. Pour la traduction de commit, elle vient du GDT (il y a d'ailleurs pas mal de suggestions intéressantes en rapport avec l'informatique).
Je veux dire, franchement : tu penses qu'il n'est pas possible de rédiger un cours sur Git sans avoir des push, pull et commit à tous les coins de rues ?
Personnellement, dans ce cas précis, je pense que parler de push-er ou pull-er dans un tuto git a le mérite de faire rentrer les noms des commandes. Sauf qu'en markdown *push*-er est hyper lourd à taper, donc je serais bien du genre à dire « dans la suite, on utilisera les verbes pusher (prononcé poucher) et puller (prononcé pouler) », sachant que ce sont exactement ces néologismes que j'utilise au boulot tous les jours.
Un tutoriel Git, à mon sens, c'est un tutoriel à vocation purement pratique : utiliser quelques néologismes pour rendre l'utilisation d'un système aussi complexe le plus intuitif possible dans la tête du lecteur tout en le familiarisant avec le jargon associé à ce système, me semble une entorse tout à fait acceptable à la langue française puisqu'elle sert la pédagogie.
Personnellement, dans ce cas précis, je pense que parler de push-er ou pull-er dans un tuto git a le mérite de faire rentrer les noms des commandes. Sauf qu'en markdown
*push*-erest hyper lourd à taper, donc je serais bien du genre à dire « dans la suite, on utilisera les verbes pusher (prononcé poucher) et puller (prononcé pouler) », sachant que ce sont exactement ces néologismes que j'utilise au boulot tous les jours.
Dans le cas où tu francises un terme en en faisant un verbe, il n'est a priori plus nécessaire de le mettre en italique (je pense qu'il est juste nécessaire de le présenter entre guillemets la première fois pour bien signaler que c'est un verbe crée de toutes pièces). Après je trouve cela affreux, mais c'est une autre question.
Un tutoriel Git, à mon sens, c'est un tutoriel à vocation purement pratique : utiliser quelques néologismes pour rendre l'utilisation d'un système aussi complexe le plus intuitif possible dans la tête du lecteur tout en le familiarisant avec le jargon associé à ce système, me semble une entorse tout à fait acceptable à la langue française puisqu'elle sert la pédagogie.
Je suis d'avis que les exemples multiples d'utilisation des commandes suffisent pour ce qui est du jargon, l'explication n'a à mon sens pas besoin de comporter des néologismes ou des anglicismes.
Je suis d'avis que les exemples multiples d'utilisation des commandes suffisent pour ce qui est du jargon, l'explication n'a à mon sens pas besoin de comporter des néologismes ou des anglicismes.
La langue impactant la façon de penser, utiliser des termes tirés de cette langue pour désigner en un seul mot les notions qu'il y a derrière (et qui ont été conçues dans cette langue) évite de chercher à faire rentrer des ronds dans des trous carrés¹.
Bref, on est d'accord sur le fait qu'on ne soit pas d'accord. Je ne pense pas que ça serve à grand chose de poursuivre ce débat.
¹: Bon courage pour franciser "rebase" en un seul mot aussi simple et explicite que l'original.
Ce serait bien de recentrer le débat sur quelque chose de plus productif comme la structure du tutoriel proposée par Spacefox. Vous n’arriverez pas à vous mettre d’accord, et je pense qu’on ne doit pas placer de règles à ce propos mais gérer au cas par cas durant la bêta en fonction des traductions existantes et de l’usage du mot étranger en français.
J’aime beaucoup l’idée de plan proposé par Spacefox, il faut juste se mettre d’accord sur quelles règles mettre dans chaque partie.
