Conventions typographiques en usage sur Zeste de Savoir

Parce qu’il n’y a pas que l’orthographe dans la vie…

a marqué ce sujet comme résolu.

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.

+4 -0

Je suis d'avis de garder les choses le plus simplement possible (et utiliser des néologismes/anglicismes à bon escient dans un tutoriel ne me pose pas de soucis, surtout si cela fait références aux notions essentielles)

È la banaaaana !

Gosh, ça me tourne dans la caboche maintenant ! :'(

+6 -0

Je ne vais pas réagir spécifiquement au débat sur l’utilisation des anglicismes dans les tutos. Je me contenterai de faire remarquer que si vous utilisez les mots anglais, c’est un choix pédagogique que vous faites, et qu’il vous appartient de l’assumer jusqu’au bout. Et à titre strictement personnel, dans la mesure où je rédige des cours de langue, par définition truffés de mots étrangers à mettre en italique, je vous trouve un peu gonflés de râler. :)

Pour le reste, je n’aime pas du tout la réorganisation proposée par SpaceFox. Je rappelle que le but de cet article n’est pas d’enseigner la typographie, mais de fixer des règles pour l’utilisation de celle-ci sur Zeste de Savoir.

En particulier, les parties « secrètes » ne sont pas conçues pour être lisibles par quelqu’un qui ne connaîtrait rien à la typographie, mais au contraire, sont là pour se prémunir contre un(e) emm***eur/se connaissant la typographie et qui viendrait contester les choix faits.

Du coup, l’optique étant — je rappelle — de fixer des règles et d’aider à les appliquer :

  • la partie 3 de SpaceFox n’a pas lieu d’être, puisque je laisse à un autre cours la charge d’enseigner la typographie ;
  • la partie 2 n’a pas lieu d’être non plus, puisque les règles présentées ici et réduites à l’essentiel1 sont conçues dans l’optique de les appliquer à tous les contenus de ZdS, sauf quand une marge de manœuvre a été explicitement laissée. Que ce soit l’auteur qui les applique lui-même, ou que quelqu’un lui donne un coup de main (comme pour l’orthographe, hein, je rappelle…), voire qu’une partie soit prise en charge automatiquement par le markdown, l’idée est bien de ne pas valider les contenus qui n’appliqueraient pas ces quelques règles. Sinon, le concept de « charte typographique » est vidé de son sens…

Du coup, il ne reste plus que la partie 1, qu’il faut bien organiser. ;)

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.

Mouais… Ça fait jamais que 10 lignes… Et des listes imbriquées, c’est pas si rare.

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.

Qu’entends-tu par là exactement ? :)

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.

Aabu

Le document est pour l’essentiel composé d’erreurs courantes qui reviennent tout le temps. ;)

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).

Ce n’est pas parce que cette règle précise t’emmerde que faire autrement est correct pour autant. Il n’y a pas d’interdiction explicite parce que la règle est « Une phrase commence par une majuscule et se termine par une ponctuation forte. » et que le cas des listes, des maths et des citations constitue une exception à cette règle. ;)

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.

Je me suis vraiment tâté pour savoir si j’en parlais ou non. Je vais le virer.

[Les différentes sortes d’espace] Alors on en parle pas, ou alors en partie 3.

J’ai mis cette question dans une boite, parce que je voulais attirer l’attention sur le point de dev à réaliser : elle disparaîtra de la version finale.

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.

Tu racontes n’importe quoi. Cela simplifie de très loin le problème des espaces avant ponctuations hautes pour l’auteur, ce qui est précisément le but recherché. Quant aux prétendus problèmes liés au code, tu en as déjà parlé dans la suggestion d’origine, et je t’avais déjà répondu : le markdown convertit automatiquement la séquence -- en tiret semi-cadratin, et pourtant, tu peux sans souci écrire i--; dans ton code. Il suffit de placer les conversions concernant les ponctuations hautes au même endroit que celles qui gèrent --, --- et ... et il n’y aura aucun problème.

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.

Je trouverais assez stupide de répartir la règle en deux endroits différents alors qu’elle tient en une ligne et demie. Ce n’est clairement pas compliqué, et surtout, cela ne tient pas du détail : la distinction entre titre d’article et titre d’ouvrage est une convention en usage dans toutes les typographies du monde utilisant l’alphabet latin, et qui se rencontre dans n’importe quel article scientifique.

De plus, j'apprécie moyennement me faire traiter de nazi.

J’avais déjà pu constater que tu es parfaitement dépourvu d’humour, et tu viens une nouvelle fois de le confirmer. Le concept de grammar nazi, ça te parle ?

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é).

Le but n’est pas d’apprendre une quelconque théorie, mais de fixer des règles en usage sur Zeste de Savoir, où les commentaires de code font la plupart du temps partie intégrante du cours, et méritent à ce titre un minimum de correction, entre autres typographique.

Je ne vois rien concernant l'usage des majuscules accentuées, des guillemets français et des trois points.

Parce que la règle se résume à « Vous devez les utiliser. », mais si vous y tenez, je peux le préciser explicitement. :)

Je séparerais plus visuellement les 3 OS (avec des titres ?).

Je me suis demandé, aussi, si ça ne vaudrait pas la peine, mais en même temps, le texte de chacun est très court. Faudra faire un essai.

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é.

SpaceFox

Elle revient au même, la seule obligation posée est la paternité. :)

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.

mathiasm

L’espace insécable est invisible, et les tirets spéciaux se trouvent dans la quatrième section. :) Et je pense que les définir précisément ferait plus de mal que de bien, car la définition de « tiret semi-cadratin » est « tiret faisant la largeur d’un demi-cadratin, un cadratin étant l’unité servant à mesurer la taille des choses en typographie. ». ^^

Gosh, ça me tourne dans la caboche maintenant ! :'(

Arius

Ça me tournait dans la caboche au moment d’écrire le message. :D


  1. Un bouquin de typographie, ça fait 200-300 pages, hein… Ici, et dans un format équivalent, on en atteint une dizaine tout mouillé. 

+2 -3

Je propose d'ajouter également les définitions de certains termes tels que espaces insécables ou tirets semi-cadratins. […]

L’espace insécable est invisible, et les tirets spéciaux se trouvent dans la quatrième section. :) Et je pense que les définir précisément ferait plus de mal que de bien, car la définition de « tiret semi-cadratin » est « tiret faisant la largeur d’un demi-cadratin, un cadratin étant l’unité servant à mesurer la taille des choses en typographie. ». ^^

Ce que je voulais simplement dire, c'est que la 1ère fois que quelqu'un a utilisé le terme espace insécable dans un de ces topics parlant de typo, je me suis demandé ce que c'était et ai dû me renseigner via google. Donc sauf si je suis le seul dans ce cas*, je crains qu'il soit difficile de motiver les auteurs à respecter une charte qui ne fait que "fixer les règles".

* Je suis peut-être le seul dans ce cas, mais j'en doute fortement. Le problème dans ce topic est que seul des initiés participent, donc on a aucune idée de l'avis "du peuple".


D'un point de vue plus général, désolé de revenir là-dessus, mais je regrette qu'on ne tâte pas plus le terrain auprès de la communauté pour ces questions de typographie avant de se lancer dans ces grandes batailles pour fixer les règles. J'admets qu'il est légitime de resserrer la validation sur ce point (ou plutôt qu'il est difficile de justifier d'accepter de contenu avec des erreurs évidentes de typo), mais il y a un risque de perdre des auteurs. Admettons que certains auteurs refusent de faire l'effort d'apprendre certains trucs tirés par les cheveux, tout simplement parce que ça ne les intéresse pas, on fait quoi ? On refuse de publier, on corrige à leur place, etc. ?

Edit : ajout de la 2ème partie du message

+4 -0

Le principe de base à la base de ZdS, c'est que les sujets importants font l'objet d'une discussion donc oui, clairement (que ce soit porté par l'association ou par le staff responsable du contenu) il y a matière à débattre, recueillir des avis et surtout éviter des décisions unilatérales quand il ne s'agit pas d'une mesure urgente.

Ce tuto en bêta offrant une base de travail/discussion n'a pas été et n'est pas officialisé que je sache. Et ce ne sera pas le cas AMHA avant de tâter le terrain pour reprendre ton expression ou avant une discussion de l'association si cela entre dans les compétences de celle-ci.

Btw, je l'ai dit dans l'autre sujet (mais cela s'applique à toutes les discussions sur le site), on se passera de ceci.

J’avais déjà pu constater que tu es parfaitement dépourvu d’humour, et tu viens une nouvelle fois de le confirmer. Le concept de grammar nazi, ça te parle ?

De grâce, évitons d'émettre un avis sur l'autre. Gérer un projet comme ZdS et faire évoluer sa communauté est déjà un travail de titan, évitons de titiller l'autre (à la limite autour d'une bière/d'une bouteille de vin, je ne dis pas mais là, ce n'est pas approprié). C'est un sujet assez… sensible pour certains mais ça ne mérite certainement pas de se prendre le choux entre membres.

+3 -0

Admettons que certains auteurs refusent de faire l'effort d'apprendre certains trucs tirés par les cheveux, tout simplement parce que ça ne les intéresse pas, on fait quoi ? On refuse de publier, on corrige à leur place, etc. ?

mathiasm

C'est peut-être moi qui est pris le pli de certaines conventions typographiques et qui, dès lors, ne les trouve plus difficiles ou pénibles à mettre en place, mais en l'état, les règles du cours de Dominus me paraîssent assez simples.

Sinon, pour répondre à ta question, je suis d'avis que si l'on tombe sur un auteur récalcitrant (cela m'étonnerais tout de même, la communauté étant composée de personnes ouvertes d'esprit), c'est au validteur d'effectuer les modifications (sauf si la mise en forme est vraiment dégoûtante). Je l'ai déjà fais pour un cours de Mewtow où il y avait pas mal de termes anglais (il l'avait fait de lui-même après que je lui aie signalé, mais il y avait un ou deux oublis).

+2 -0

@mathiasm : je vois ce que tu veux dire. Disons que ça ne me paraît pas aberrant que les discussions préliminaires soient essentiellement portées par ceux qui ont un certain bagage en typographie, qui reste un domaine assez technique, de la même manière que je ne me sentirais pas apte à donner un avis éclairé sur la meilleure solution technique à adopter pour gérer le temps réel sur ZdS.

Maintenant, si un novice veut vraiment comprendre de quoi il en retourne sur la question des caractères spéciaux et des espaces insécables, voici l’essentiel à savoir.

À l’époque des machines à écrire, pour des raisons techniques, il a fallu limiter le nombre de caractères différents disponibles sur le clavier. Pour cette raison, un certain nombre de caractères sont tout simplement passés à la trappe (œ, majuscules accentuées, points de suspension…), tandis que pour d’autres, les distinctions ont été gommées en fondant plusieurs caractères en un seul : par exemple, le signe mathématique moins, les tirets cadratins et semi-cadratins et le trait d’union ont tous été fondus en un unique caractère « tiret » ; le symbole « prime », l’apostrophe guillemet et quelques autres sont devenus le guillemet droit simple ' inventé pour l’occasion ; etc. Le problème, c’est que ce qui n’était qu’une limitation technique a été transformé par certains imbéciles en une prétendue règle du style « Il ne faut pas accentuer les majuscules. », et que ça a été enseigné… :-(

Quant aux différentes espaces, elles servent essentiellement à ce que des signes de ponctuation ne se retrouvent pas tous seuls sur la ligne en dessous. À l’époque des machines à écrire, cette considération est tombée en désuétude, parce que c’est la dactylo qui décide à quel moment elle revient à la ligne, et elle n’a donc pas besoin d’un caractère spécial pour marquer le fait que cette espace précise ne doit pas devenir un retour à la ligne. Mais avec l’arrivée de l’informatique, où c’est l’ordinateur qui décide de lui-même où se terminent les lignes, il redevient indispensable de signaler les espaces qui ne doivent pas être transformées en retour à la ligne. Avec la difficulté supplémentaire que la question de l’espacement avant les signes de ponctuation est un vrai merdier entre les différents pays de la Francophonie.

Alors la proposition que je fais pour Zeste de Savoir est en trois parties :

  • pour les majuscules accentuées, y’a pas de miracle, il faut que les auteurs les utilisent eux-mêmes ;
  • pour les espaces insécables, pas insécables, fines ou non, on fait au plus simple pour l’auteur : il met des espaces ordinaires partout, et c’est le zMarkdown qui gère les différents cas ;
  • pour les autres caractères spéciaux, la question reste ouverte.

En effet, le fichier smarty.py du zMarkdown gère déjà la transformation de -- en tiret semi-cadratin, de --- en tiret cadratin, et de ... en points de suspension. Reste la question des guillemets français et des apostrophes typographiques.

À l’heure actuelle, telle que la charte est rédigée, c’est à l’auteur de les entrer par ses propres moyens. Mais je viens de me rendre compte que smarty.py inclut la possibilité, actuellement désactivée sans que je sache trop pourquoi, de remplacer automagiquement << par un guillemet ouvrant « et >> par un guillemet fermant ». Il inclut également tout un bout de code, actuellement désactivé, pour gérer les guillemets anglais, qu’il serait assez simple de modifier de manière à lui faire transformer tous les ' en apostrophes typographiques.

Je suis assez partisan de l’idée, pour ma part.

Si quelqu’un a les moyens de tester, voici les modifications à effectuer dans le code de Python-ZMarkdown pour avoir automatiquement les guillemets français et les apostrophes typographiques.

Dans /markdown/extensions/zds.py, remplacer la ligne 70 par la suivante.

1
        sm_ext          = SmartyExtension(smart_angled_quotes=True)

Dans /markdown/extensions/smarty.py, commenter les lignes 226 à 237, sauf la 233. Dans cette ligne 233, remplacer lsquo par rsquo.

La gestion des espaces insécables demanderait un petit peu plus de boulot, mais si quelqu’un pouvait déjà vérifier que ça, ça marche, je lui en serais très reconnaissant.

Admettons que certains auteurs refusent de faire l'effort d'apprendre certains trucs tirés par les cheveux, tout simplement parce que ça ne les intéresse pas, on fait quoi ? On refuse de publier, on corrige à leur place, etc. ?

On fait comme pour les auteurs qui refusent d’apprendre les règles orthographiques qui leur paraissent trop tirées par les cheveux. ^^

+1 -1

à noter que Grammalecte, le fameux correcteur ortho-typo-gramatical, va bientôt (quand ça sera prêt quoi) sortir une version firefox, je pense que cela va aider beaucoup !

+0 -0

Bonjour, je tombe sur ces débats assez tard. Désolé.

Je suis convaincu qu'un minimum de typo est nécessaire (et pas forcement atteint ici). Cependant, sur le tuto, il va parfois un peu loin :

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.

Trop complexe. Est-ce que

La dernière d’une série de formules mathématiques doit être terminée par un point.

n'est pas suffisant ?

Idem pour les listes imbriquée, qui complique pas mal.

Pour les abréviations (c'est une question que je pose et non une remarque sur le tuto), quid des apostrophes et des accords. On dit « les maths » ; j'écris ou dis facilement phy' stat'.

Espaces fines insécables, si c'est inapplicable, peu utile d'en parler.

Pour les espaces insécables automatiques, si c'est vraiment possible, je plussoie !

Pour les typonazis, je ne pense pas que ce soit pertinent comme blague, j'entends que si on s'adresse à des gens qui ne connaissent pas la typo', ils risquent de prendre ça au 1er degré.

Tu ne parle d'ailleurs pas de la syntaxe de 1er, 2ème… (que j'écris systématiquement mal, par ailleurs), est-ce un oublie ou as-tu jugé cela inutile ou trop compliqué ?

De manière générale, s'il était possible de raccourcir le tuto, ce serait pas mal, mais je le trouve globalement correcte.

+2 -0

Trop complexe. Est-ce que

La dernière d’une série de formules mathématiques doit être terminée par un point.

n'est pas suffisant ?

Comme dit plus haut dans ma réponse à SpaceFox, je vais carrément supprimer ce passage-là. :)

Idem pour les listes imbriquée, qui complique pas mal.

J’en ai bien conscience, mais la typographie des listes est un des points que l’on doit le plus souvent faire corriger, en tant que correcteur, donc c’est impératif qu’il y soit.

Pour les abréviations (c'est une question que je pose et non une remarque sur le tuto), quid des apostrophes et des accords. On dit « les maths » ; j'écris ou dis facilement phy' stat'.

Vite fait (j’ai pas les références sous la main), il y a trois types d’abréviations :

  • les abréviations par contraction, quand on enlève une partie de l’intérieur du mot (par exemple « Mlle ») : comme la fin du mot ne disparaît pas, elles s’accordent si besoin (par exemple « Mlles »). Le mot « maths » en fait partie, c’est la contraction de « math[ématique]s » ;
  • les abréviations par suspension, quand on enlève la fin du mot (par exemple « M. ») : la suspension est signalée par un point abréviatif (il faudrait donc écrire « phy. stat. »), que l’on omet lorsqu’il touche un point final, et du coup, l’abréviation ne s’accorde pas (« MM. » est une exception) ;
  • les apocopes, quand même à l’oral on sabre la fin du mot (par exemple, « restau », « condo » ou « Sécu ») : comme il s’agit d’un mot à part entière, il s’accorde. Du coup, pour ton « phy' stat' », si tu le prononces aussi comme ça à l’oral (et que tu n’es pas tout seul à le faire ^^ ), il faudrait sans doute l’écrire « phystat », à la manière de « surgé » pour « surveillant général ».

Espaces fines insécables, si c'est inapplicable, peu utile d'en parler.

Comme dit plus haut, cela n’apparaîtra pas dans la version définitive, le cadre n’est présent que pour lancer la discussion sur une intégration de la typographie française au markdown.

Pour les espaces insécables automatiques, si c'est vraiment possible, je plussoie !

C’est effectivement possible. Le module suivant (réécrit en anglais pour faire plaisir à SpaceFox) gère tout ce qu’il est possible d’automatiser dans la typographie française sans empiéter sur la typographie des autres langues.

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
# -*- coding: utf-8 -*-

# Gestion fine de la typographie française, du moins, ce qui peut être
# automatisé, par Dominus Carnufex. Lointainement inspiré de l’extension
# SmartyPants. Licence CeCIll-B.

import markdown
from ..inlinepatterns import HtmlPattern

class ReplacePattern(HtmlPattern):
    def __init__(self, pattern, replacement, markdown):
        """ Replace the pattern by a simple text. """
        HtmlPattern.__init__(self, pattern)
        self.replacement = replacement
        self.markdown = markdown

    def handleMatch(self, m):
        return self.markdown.htmlStash.store(self.replacement, safe=True)

class FrenchTypographyExtension(markdown.extensions.Extension):
    def __init__(self, *args, **kwargs):
        self.config = {
            'apostrophes': [True, 'Typographic apostrophes'],
            'em_dashes': [True, 'Em dashes'],
            'en_dashes': [True, 'En dashes'],
            'unbreakable_spaces': [True, 'Unbreakable spaces'],
            'angle_quotes': [True, 'Angle quotes'],
            'per_mil': [True, 'Per mil symbol'],
            'ellipses': [True, 'Ellipses'],
        }
        super(FrenchTypographyExtension, self).__init__(*args, **kwargs)

    def replaceApostrophes(self, md):
        apostrophesPattern = ReplacePattern("'", "&rsquo;", md)
        self.replacements.add('apostrophes', apostrophesPattern, '_begin')

    def replaceEmDashes(self, md):
        emDashesPattern = ReplacePattern(r'(?<!-)---(?!-)', "&mdash;", md)
        self.replacements.add('em_dashes', emDashesPattern, '_begin')

    def replaceEnDashes(self, md):
        enDashesPattern = ReplacePattern(
            r'(?<!-)--(?!-)', "&ndash;", md
        )
        self.replacements.add(
            'en_dashes', enDashesPattern, '_begin'
        )

    def replaceSpaces(self, md):
        semicolonWithSpacePattern = ReplacePattern(" ; ", "&nbsp;; ", md)
        colonWithSpacePattern = ReplacePattern(" : ", "&nbsp;: ", md)
        interrogationWithSpacePattern = ReplacePattern(" \?", "&nbsp;?", md)
        exclamationWithSpacePattern = ReplacePattern(" !", "&nbsp;!", md)
        perCentWithSpacePattern = ReplacePattern(" %", "&nbsp;%", md)
        perMilWithSpacePattern = ReplacePattern(
            " ‰".decode("utf8"), "&nbsp;&permil;", md
        )
        openingAngleQuoteWithSpacePattern = ReplacePattern(
            "« ".decode("utf8"), "&laquo;&nbsp;", md
        )
        closingAngleQuoteWithSpacePattern = ReplacePattern(
            " »".decode("utf8"), "&nbsp;&raquo;", md
        )

        self.replacements.add(
            'semicolon_with_space', semicolonWithSpacePattern, '_end'
        )
        self.replacements.add(
            'colon_with_space', 
            colonWithSpacePattern, 
            '<semicolon_with_space'
        )
        self.replacements.add(
            'interrogation_mark_with_space', 
            interrogationWithSpacePattern, 
            '<colon_with_space'
        )
        self.replacements.add(
            'exclamation_mark_with_space', 
            exclamationWithSpacePattern, 
            '<interrogation_mark_with_space'
        )
        self.replacements.add(
            'per_cent_with_space', 
            perCentWithSpacePattern, 
            '<exclamation_mark_with_space'
        )
        self.replacements.add(
            'per_mil_with_space', 
            perMilWithSpacePattern, 
            '<per_cent_with_space'
        )
        self.replacements.add(
            'opening_angle_quote_with_space', 
            openingAngleQuoteWithSpacePattern, 
            '<per_mil_with_space'
        )
        self.replacements.add(
            'closing_angle_quote_with_space', 
            closingAngleQuoteWithSpacePattern, 
            '<opening_angle_quote_with_space'
        )

    def replaceAngleQuotes(self, md):
        openingAngleQuotesPattern = ReplacePattern(r'\<\<', "&laquo;", md)
        closingAngleQuotesPattern = ReplacePattern(r'\>\>', "&raquo;", md)
        self.replacements.add(
            'opening_angle_quotes', openingAngleQuotesPattern, '_begin'
        )
        self.replacements.add(
            'closing_angle_quotes', 
            closingAngleQuotesPattern, 
            '>opening_angle_quotes'
        )

    def replaceAngleQuotesWithSpaces(self, md):
        openingAngleQuotesPattern = ReplacePattern(
            r'\<\< ', "&laquo;&nbsp;", md
        )
        closingAngleQuotesPattern = ReplacePattern(
            r' \>\>', "&nbsp;&raquo;", md
        )
        self.replacements.add(
            'opening_angle_quotes', openingAngleQuotesPattern, '_begin'
        )
        self.replacements.add(
            'closing_angle_quotes', 
            closingAngleQuotesPattern, 
            '>opening_angle_quotes'
        )

    def replacePerMil(self, md):
        perMilPattern = ReplacePattern("%o", "&permil;", md)
        self.replacements.add('per_mil', perMilPattern, '_begin')

    def replacePerMilWithSpace(self, md):
        perMilPattern = ReplacePattern(" %o", "&nbsp;&permil;", md)
        self.replacements.add('per_mil', perMilPattern, '_begin')

    def replaceEllipses(self, md):
        ellipsesPattern = ReplacePattern(
            r'(?<!\.)\.{3}(?!\.)', "&hellip;", md
        )
        self.replacements.add('ellipses', ellipsesPattern, '_begin')

    def extendMarkdown(self, md, md_globals):
        configs = self.getConfigs()
        self.replacements = markdown.odict.OrderedDict()
        if configs['apostrophes']:
            self.replaceApostrophes(md)
        if configs['em_dashes']:
            self.replaceEmDashes(md)
        if configs['en_dashes']:
            self.replaceEnDashes(md)
        if configs['unbreakable_spaces']:
            self.replaceSpaces(md)
        if configs['angle_quotes']:
            self.replaceAngleQuotes(md)
        if configs['angle_quotes'] and configs['unbreakable_spaces']:
            self.replaceAngleQuotesWithSpaces(md)
        if configs['per_mil']:
            self.replacePerMil(md)
        if configs['per_mil'] and configs['unbreakable_spaces']:
            self.replacePerMilWithSpace(md)
        if configs['ellipses']:
            self.replaceEllipses(md)
        processing = markdown.treeprocessors.InlineProcessor(md)
        processing.inlinePatterns = self.replacements
        md.treeprocessors.add('french_typography', processing, '_end')
        md.ESCAPED_CHARS.extend(["'"])

def makeExtension(*args, **kwargs):
    return FrenchTypographyExtension(*args, **kwargs)

Il y a quelques bricoles aussi à changer dans le module zds.py pour l’intégrer, mais c’est du détail. J’y ajoute aussi les explications que j’avais données sur quelques choix d’implémentation.

  • Le module smarty.py ne gère pas à proprement parler la transformation d’apostrophes droites en apostrophes typographiques : il va transformer les guillemets droits simples en guillemets typographiques simples, si on active le module qui transforme les guillemets droits doubles en guillemets typographiques anglais. Il est possible de le modifier pour obtenir ce qu’on veut (ce sur quoi j’étais parti au départ), mais ça donne un résultat sale.
  • J’ai préféré faire une extension distincte spécifiquement dédiée à la typographie française plutôt que de modifier smarty.py parce que le gros du code de smarty.py est dédié à la gestion des guillemets anglais. Au final, je perdais plus de temps à faire des modifs propres dans smarty.py qu’à écrire un autre module fonctionnant sur le même principe. Ça évite aussi de « pourrir » un module de typographie anglaise très bien fait avec des considérations de typographie française en contradiction avec la typographie anglaise.
  • D’où les doublons. L’idée est bien de désactiver l’extension smarty.py qui ne serait plus nécessaire.
  • J’ai pensé au fait que l’on pourrait vouloir mélanger des textes en français et en une autre langue (par exemple, une bête citation) : dans ce cas, insérer des espaces avant les ponctuations ruinerait la typographie des passages en langue étrangère. C’est pourquoi les espaces insécables ne sont insérées que si le passage a été explicitement identifié comme utilisant la typographie française, en mettant des espaces ordinaires là où se trouveront les espaces insécables. Par exemple, Bonjour le monde ! recevra une espace insécable, mais pas Hello, World!.
  • Dans ces conditions, comment distinguer "Hello, dear sir!" (où les guillemets droits représentent des guillemets anglais “” non séparés de leur contenu) et "Bonjour, Monsieur !" (où les guillemets droits représentent des guillemets français devant être séparés de leur contenu par des espaces insécables) ? Ce n’est pas possible, il faudrait appliquer la règle de l’espacement explicite en amont (" Bonjour, Monsieur ! "), mais il devient alors impossible (sauf si quelqu’un trouve une solution, mais a priori, il n’y en a pas) de savoir quel guillemet droit doit être un guillemet ouvrant et lequel doit être un guillemet fermant. Dans un exemple simple, comme ici, pourquoi pas, mais en situation réelle, comment distinguer deux citations imbriquées de deux citations séparées (" Il m'a dit " Georges, vous êtes un imbécile ! " et je n'ai su que répondre. " vs. " Lève-toi et marche " dit le prophète. " Je voudrais bien t'y voir ! " répondit l'infirme.) ?
  • J’ai également fait attention que les smileys commençant par un point-virgule (;)) et un deux-points (:)) ne se retrouvent pas précédés d’une espace insécable.

Maintenant, il semblerait que ça coince du côté des développeurs, et je ne sais pas quoi faire pour que ça avance et que ça ne se retrouve pas au fond d’une oubliette comme la dernière fois que j’ai proposé un tel module. :(

Pour les typonazis, je ne pense pas que ce soit pertinent comme blague, j'entends que si on s'adresse à des gens qui ne connaissent pas la typo', ils risquent de prendre ça au 1er degré.

C’est déprimant…

Tu ne parle d'ailleurs pas de la syntaxe de 1er, 2ème… (que j'écris systématiquement mal, par ailleurs), est-ce un oublie ou as-tu jugé cela inutile ou trop compliqué ?

Pourrais-tu te montrer plus explicite sur ce que tu entends par là ? ^^

De manière générale, s'il était possible de raccourcir le tuto, ce serait pas mal, mais je le trouve globalement correcte.

Gabbro

Difficilement faisable sans sabrer des aspects importants ou se montrer peu clair dans les explications.

+0 -0

Tu ne parle d'ailleurs pas de la syntaxe de 1er, 2ème… (que j'écris systématiquement mal, par ailleurs), est-ce un oublie ou as-tu jugé cela inutile ou trop compliqué ?

Pourrais-tu te montrer plus explicite sur ce que tu entends par là ? ^^

Dois-t-on écrire 1er, $1^{\text{er}}$, 2ème, $2^\text{e}$, 2ième, 2me… Existe-t-il un moyen simple d'appliquer la bonne règle (ici, j'ai fait du mathjax, donc ce n'est pas simple).

+0 -0

Les formes correctes1 sont « 1er(s) » (premier(s)), « 1re(s) » (première(s)), « 2d(e)(s) » (second(e)(s)), puis « 2e » (deuxième), « 3e » (troisième), etc. Pour mettre des lettres en exposant, tu as le zMarkdown ^exposant^. :)

Et pour répondre à ta question de départ, j’ai considéré effectivement que ça rentrait dans les nombreux points de « détail » qu’il serait trop fastidieux d’intégrer à une charte typographique que d’aucuns trouvent déjà trop longue. ^^


  1. D’après [LEX], je ne suis pas allé regarder dans les autres. 

+0 -0

Le texte vient d’être mis à jour, avec les changements suivants.

  • J’ai reçu le Ramat de la typographie ce matin, et j’ai donc pu l’intégrer parmi les références.
  • L’histoire des points après les formules mathématiques a été supprimée.
  • Le cadre qui parlait des espaces insécables a été supprimé.
  • La blague sur les grammar nazis a été expliquée, pour que personne ne la prenne au premier degré.
  • La section sur les caractères spéciaux est doté d’une introduction qui rappelle rapidement quand on doit les utiliser.
  • Je parle des modifications automatiques effectuées par le markdown.

Ce bloc de texte intègre des modifications automatiques qui ne sont pas encore faites par le markdown actuel, et qui ne le seront que lorsque le module que je présente plus haut sera intégré au code. Il est donc impératif que ce module soit intégré avant que la charte typographique soit publiée.

  • J’ai ajouté les combinaisons de touches à faire sous OS X en disposition française.

J’ai toujours besoin d’aide pour les dispositions belges, suisses et québécoises !

  • J’ai corrigé quelques fôtes qui traînaient. Si vous avez un peu de temps, prenez la peine de vérifier qu’il n’en reste plus : vu la thématique du contenu, ça la foutrait mal d’avoir des fautes d’orthographe, et je ne suis pas infaillible. ^^
+2 -0

Et voici une nouvelle mise à jour avec des nouveautés supplémentaires.

  • Je me suis procuré le Ramat européen de la typographie et ai pu l’intégrer au texte : les différences avec le Ramat tout court ne sont pas flagrantes, mais c’était histoire de dire.
  • J’ai fouillé mes cartons pour retrouver le Nouveau Code Typo : j’avais oublié à quel point il était mal foutu et vieillot, mais maintenant c’est fait, j’ai intégré tout ce qu’il y avait à en tirer.
  • J’ai enfin les combinaisons de touches pour toutes les variantes de OS X, ouf ! Merci à Ymox et Sandhose pour leur aide.

Quelles évolutions possibles, encore ?

A priori, le texte devrait être définitif et peut désormais être proposé à l’adoption par l’assoc et entrer en vigueur sur le site. Il y a cependant quelques points qui peuvent ou doivent encore être réglés.

Je le rappelle, cf. supra, il va falloir faire quelque chose pour le markdown : le module de typographie doit être intégré au site avant la publication de la charte typographique. Mais c’est le calme plat sur le GitHub du markdown, alors je sais pas, si quelque chose est en cours, faites-moi signe, si rien n’est en cours, dites-moi pourquoi, quelque chose, n’importe quoi !

J’ai encore relevé des fautes voire plus grave dans le texte. Maintenant que celui-ci est (théoriquement) définitif, il me faudrait vraiment un retour sur l’orthographe.

Dans les références, je parle du Guide du typographe (romand), mais je ne l’utilise pas dans le texte. Pourquoi cela ? Parce qu’il n’existe pas dans une BU près de chez moi (on le trouve à Rennes ou à Paris, seulement, pour une version récente) et qu’il est beaucoup trop cher pour que je l’achète neuf (plus de 50 balles >_< ). Quant à l’acheter d’occasion, il ne semble possible de trouver que la 3e édition, de 1963 ! Donc bof…

Alors je refais un appel à bonnes volontés : si vous habitez en Suisse, et que vous voulez bien prendre une heure pour aller à la BU relever les passages pertinents (ou me faire un scan complet du bouquin, à vous de voir ce qui vous prend le moins de temps), on peut trouver la toute dernière édition à Lausanne et à la Bibliothèque nationale, et la précédente dans des centaines de bibliothèques dans tout le pays. Plus d’infos sur swissbib.

+1 -0

Introduction

Premier contenu masqué, premier paragraphe, deuxième phrase : est-il sûr que Francophonie prend une majuscule ici ? Voir ici

Idem, deuxième paragraphe : c’est étrange que la phrase termine par un point et non un deux-points.

Idem, septième paragrahpe : lien mort sur les recommandations de l’Université de Mons.

Idem, quatrième liste à puces, quatrième puce : « quelques uns » ou « quelques-uns » ?

Du bon usage de la ponctuation

Deuxième paragrahpe, première phrase : je ne mettrais pas de virgule avant le « et ».

Deuxième contenu masqué, troisième paragraphe en partant du bas : il est écrit « sont introduits pas » au lieu de « sont introduits par ». Par ailleurs, le « non ponctués » est, je trouve, ambigu : signifie-t-il que les exemples ne se terminent pas par un point ou bien faut-il le lire comme « non pas par un point » ?

Première liste à puces, deuxième puce, première sous-puce : il est écrit « dans un telle liste » au lieu de « dans une telle liste »

Troisième contenu masqué, deuxième paragraphe : la première apostrophe utilisée est l’apostrophe dactylographique au lieu de l’apostrophe typographique. Il est en outre écrit « les énumération ordonnées » au lieu de « les énumérations ordonnées ». J’écrirais plutôt « celles dont le chiffre » à la place de « celles le chiffre ». Dans la citation qui suit, deuxième ligne, il est écrit « même s’il n’est pas début de phrase » au lieu de « même s’il n’est pas en début de phrase » (mais c’est peut-être une faute de l’ouvrage cité).

Troisième contenu masqué, quatrième paragraphe : il est écrit « de manière beaucoup plus cryptiques  » au lieu de « de manière beaucoup plus cryptique ».

Cinquième contenu masqué, troisième paragraphe à partir de la fin, troisième phrase : il est écrit « Bépo » au lieu de « bépo ».

Mettre en exergue : gras, italique et guillemets

Troisième paragraphe, boîtes « Attention » et « Information » : l’apostrophe dactylographique est utilisée au lieu de l’apostrophe typographique.

Troisième contenu masqué, premier paragraphe, première phrase : j’enlèverais la première virgule.

Les bons symboles

Premier paragraphe, deuxième phrase : j’écrirais plutôt « limitation purement technique » au lieu de « limitation purement technologique ».

Windows

Deuxième paragraphe : il est écrit « Bépo » au lieu de « bépo ».

OS X

Idem.

GNU/Linux

Premier paragraphe, dernière phrase : idem.

Voilà pour les corrections. J’ai quelques remarques à faire sur les règles proposées.

  • Je pense plutôt qu’un paragraphe introduisant une image, un tableau, etc. devrait se terminer par un deux-points, car ils peuvent être considérés comme des explications et ainsi correspondre à la règle suivante :

Le deux-points introduit une explication, une citation ou un discours. — [LEX], p. 147

  • Le partie sur les espaces insécables est très instructive. Je pensais que les guillemets et les tirets cadratins pouvaient être accolés d’espaces fines insécables : Wikipédia. Je suis notamment très étonné par les espaces justifiantes pour les tirets. En ce qui concerne le compromis pour Zeste de Savoir, je ne comprends pas pourquoi une espace fine insécable pour le « % », l’espace-mot insécable me semble plus approprié ici (puisqu’il est recommandé plus souvent dans le tableau récapitulatif). En ce qui concerne le deux-points, j’ai une certaine réticence contre l’espace-mot à la place de l’espace fine insécable, peut-être à cause de sa « fonction » différente des autres signes de ponctuation double (cela reste confus) mais je comprends tout à fait qu’on puisse arguer qu’il n’y a pas de raisons de le traiter différemment des points d’exclamation, d’interrogation et du point-virgule.

  • Enfin, il serait peut-être judicieux de placer la partie « Les bons symboles » avant les autres, étant donné qu’elle contient des instructions très simples ainsi que la syntaxe Markdown (tient d’ailleurs markdown devrait toujours avoir une majuscule non ?). Il est donc assez probable que l’on revienne vers cette partie si on a oublié quelque chose, et ce serait donc plus agréable qu’elle soit accessible plus rapidement.

Bon travail.

+0 -0

Je commence une relecture orthographique.

Edit : grillé.

Introduction

Elles semblent très proche des normes françaises.

Du bon usage de la ponctuation

[NCT] ne fournit pas de règle particulière, mais les exemples p. 86-87 sont introduits pas un deux-points

Soit la phrase introductive se termine par un deux-points. Auquel cas, chaque élément de la liste se termine par un point-virgule, indépendamment de la ponctuation interne de l’élément1, et le dernier élément se termine par un point.

Quid de la première lettre ? Majuscule ?

si une autre liste est imbriquée dans un telle liste

[RAM] donne globalement les mêmes indications que [LEX], quoique de manière beaucoup plus cryptiques

le point, la virgule et les points de suspension sont collés au mot qui précède ;

Quid du mot qui suit ?

En revanche, il semble ne pas poser de problème à LaTeX, qui le représente par la commande \, (à vérifier)

http://www.xm1math.net/doculatex/espacements.html

Mettre en exergue : gras, italique et guillemets

Certaines références, ne parlent pas explicitement

+0 -0

OS X (Suisse) pour Ç : Il faut taper Alt + 4, pas Alt + ç. (Le ç s'obtenant par Maj + 4, si on dit Alt + ç les gens vont faire Maj + Alt + 4 et vont obtenir au lieu de Ç.)

+0 -0
Ce sujet est verrouillé.