Ortho-typographie

Published : 3 February 2014 – updated on 21 December 2021 – by Cerdic, Fil, Patrice Vanneufville, Raphaël Meyssan, tetue, Vincent Ramos – 67 commentaires

1
2
3
4
5
57 Votes

Ce plugin rassemble plusieurs fonctions de correction typographique automatisées auparavant éparses dans plusieurs plugins : correction des guillemets, correction des raccourcis avec mise en exposant, césure des dates, typographie des mots en majuscule, et corrections automatiques personnalisées.

Configuration

Le plugin s’installe simplement et une page de configuration permet d’activer ou désactiver les fonctionnalités de correction. Par défaut toutes les corrections sont activées, sauf les corrections personnelles qui dépendent des règles que vous voudrez ajouter.

Voyons à quoi correspond chaque fonctionnalité.

Correction des guillemets

Cette fonction remplace les paires de guillemets droits (ou « chiures de mouches »), c’est-à-dire ‹"›, par les guillemets typographiques («», “”, etc.), lesquels dépendent de la langue dans laquelle on rédige. Elle est reprise du plugin original Correction typographique des guillemets

Présentation

Tous les claviers ne permettent pas de taper directement les guillemets : en effet, la touche <"> [1] n’insère pas un guillemet mais un symbole utilisé en informatique ; ce symbole, dans les textes en langues naturelles [2], doit être remplacé par les guillemets typographiques voulus par la langue dans laquelle on rédige. Ainsi, en français de France, les guillemets sont représentés par <«> pour l’ouvrant et <»> pour le fermant et en anglais par <“> et <”>.

En aucun cas <"> ne devrait, dans une bonne typographie, être employé : son principal défaut (outre sa forme droite) est en effet qu’il ne permet pas de distinguer le début et la fin d’une citation. Or, l’œil, déjà peu habitué à la lecture verticale qu’imposent les écrans, se repère mal lorsque les citations dépassent les quelques mots. Le confort de lecture est ainsi gêné.

L’absence des guillemets sur certains claviers informatiques [3] a cependant conduit de nombreux rédacteurs à ignorer ces règles autant typographiques que visuelles. De plus, rares sont les rédacteurs actuels à posséder des connaissances typographiques.

SPIP, pour pallier cette absence, propose un bouton permettant de mettre des mots sélectionnés entre guillemets. Ce bouton n’est cependant pas accessible pour tous les champs de saisie (ainsi, il n’y a pas de barre d’insertion de caractères spéciaux pour les rubriques) et de nombreux rédacteurs, par méconnaissance de la typographie ou par « paresse », ne s’en servent pas. D’autre part, s’il existe des raccourcis clavier (dépendant du système d’exploitation utilisé) pour entrer les guillemets à la main , il est parfois fastidieux de les utiliser [4].

Ce plugin permet donc de remplacer automatiquement les guillemets droits par les guillemets corrects, et ce de manière transparente pour le rédacteur, de la même manière que les apostrophes droites <'> sont remplacées par les apostrophes courbes <’> ou que les espaces insécables sont introduites automatiquement devant les ponctuations hautes (<?!:;>). Il va de soi que le texte entre les balises <code> et <cadre> n’est pas touché.

Le plugin prend également en charge le guillemetage correct de la balise HTML <q>, en CSS, sur les navigateurs modernes, selon la langue de composition et en tenant compte des imbrications (cf.: fichier css/typo_guillemets.css).

Exemples

Voici quelques exemples, selon la langue concernée :

  • “français” → « français » ;
  • “hongrois” → „hongrois” ;
  • “anglais” → “anglais” ;
  • “danois” → »danois« ;
  • “bulgare” → „bulgare“.

Limitations

Le plugin ne gère pas le remplacement des guillemets de second rang, c’est-à-dire ceux qu’on emploie dans un texte déjà guillemeté. Ainsi, en typographie française :

« Il dit : “Bonjour” »
« Il dit : “Bonjour” d’une voix chevrotante »

ou, d’après la marche typographique de l’Imprimerie nationale :

« Il dit : « Bonjour » [5]
« Il dit « Bonjour » d’une voix chevrotante ».

Dans tous les cas, des guillemets droits enchâssés seront mal rendus.
Par exemple : "Il dit : "Bonjour" d'une voix chevrotante." sera rendu par :

« Il dit : »Bonjour« d’une voix chevrotante. »

Pour contourner cette limite :

  • le plugin ne touche à rien si jamais le texte contient déjà des guillemets élaborés, ce qui vous permet de gérer manuellement vos guillemets dans les cas complexes ;
  • l’emploi de la balise HTML <q> dédiée aux citations en ligne sera correctement guillemetée par ce plugin, en respect de la langue de composition. Par exemple, <q>Il dit : <q>Bonjour</q> d'une voix chevrotante et Ursula lui répond enjouée : <q lang="de">Guten Tag!</q></q> sera rendu par :

    « Il dit : “Bonjour” d’une voix chevrotante » et Ursula lui répond enjouée : >Guten Tag!< »

  • les liens automatiques [->1] vers des articles dont le titre contient des «guillemets français» passent en guillemets “de second niveau”.

Correction des abréviations avec exposant

Cette fonctionnalité améliore le rendu typographique des abréviations courantes, en mettant en exposant les éléments nécessaires (ainsi, Mme devient Mme) et en corrigeant les erreurs courantes (2ème ou 2me, par exemple, deviennent 2e, seule abréviation correcte).

Elle est reprise du plugin Typo exposant lui même tiré du Couteau Suisse, qui a repris cette fonction de Filtre typographique exposants

Présentation

Dans l’état actuel, ce plugin remplace (singuliers et pluriels) :
-  Melle ou Mlle par : Mlle ;
-  Mme par : Mme ;
-  1ier, 1ière, 1ère ou Iier, Iière, Ière par : 1er (masculin) et 1re (féminin) ou Ier et Ire ;
-  2ième, 2ème, 2me ou IIième, IIème, IIme (fonctionne aussi avec les autres chiffres) par : 2e et IIe (seules formes correctes) ; 2nd par 2nd.

Dans certaines conditions précises (abréviations suivies d’un espace, d’un point ou d’un tiret simple), sont également remplacés :
-  Dr et Pr par : Dr et Pr (au singulier uniquement)

Ici seront remplacées les expressions suivantes si elle sont suivies par un espace puis une majuscule :
-  Me par : Me (Maître, au singulier uniquement)

D’autres expressions (au singulier et parfois au pluriel) sont encore remplacées :
-  m², m2, m3 par : m2 et m3 ;
-  Mgr par : Mgr (Monseigneur, au singulier uniquement)
-  Mn(s) et Md(s) par : Mn(s) et Md(s)
(Million(s), Milliard(s))
-  Vve par : Vve (Veuve, au singulier uniquement)
-  Cie(s), Sté(s) et Ets par : Cie(s), Sté(s) et Éts (Compagnie(s), Société(s), Établissements)
-  ro, vo 1o, 2o, etc. par : ro (recto), vo (verso), 1o (primo), 2o (secundo), etc.

Les éventuelles formes plurielles sont traitées (soit intégrées dans le cas de Mmes → Mmes, soit annulées dans le cas de 2es — et autres variantes erronées — qui reste 2e) et les abréviations obtenues sont conformes à celles indiquées dans l’article « Abréviations » du Lexique des règles typographiques en usage à l’Imprimerie nationale (presses de l’Imprimerie nationale, Paris, 2002).

Le cas de Monsieur, que l’on devrait, d’après l’Imprimerie nationale, abréger en M. et non Mr ou Mr, n’est pas pris en charge par un remplacement de Mr en M., afin que l’on puisse écrire l’abréviation de Mister, soit Mr (usage anglais) ou Mr. (usage américain), sans mise en exposant (de même que Mrs ou Mrs.).

Limitations

Cette fonctionnalité sur les exposants ne fonctionne pour l’instant que sur les textes français, mais d’autres langues peuvent être intégrées facilement.

Les textes anglais bénéficient d’une mise en exposant des nombres ordinaux : 1st, 2nd, 3rd, 4th, etc.

Le texte situé entre les balises <html> et </html>, <code> et </code>, <cadre> et </cadre>, <frame> et </frame>, <script> et </script>, <acronym> et </acronym> ou <cite> et </cite> est protégé : aucune modification d’exposant n’y sera faite.

Les petits chiffres romains (I, V & X) sont pris en compte, mais pas dans le cas de «Ire» ou «Ires» ni des 50, 100, 500 & 1000 (L, C, D & M) pour des raisons de performances (et compte tenu de leur faible occurence d’utilisation)

Correction des dates

Cette fonctionnalité est tirée du plugin non documenté Typo Mois.

Très simple mais indispensable, elle prend en charge la reconnaissance des dates du type 10 mars en remplaçant l’espace entre numéro et nom du mois par une espace insécable, afin de ne pas risquer une césure entre les deux.

Typographie des capitales

Le plugin reconnait les mots écrits en lettres capitales et les encadre dans une balise <span class="caps">. Par exemple, ONU devient <span class="caps">ONU</span>. De ce fait, les mots en lettres capitales peuvent être stylés en css à volonté.

(Cette fonctionnalité est tirée du plugin non documenté Typo Caps.)

Espaces fines

Les insécables c’est bien, mais quand elles sont fines, c’est mieux : cette fonctionnalité remplace donc &nbsp; par <small class="fine">&nbsp;</small> aux endroits où c’est pertinent : guillemets français et ponctuations doubles : <? ; ! %>.
À noter, les deux-points <:> ne sont pas concernés par cette règle.

(Fonctionnalité originale apportée par Fil.)

Corrections automatiques

Le plugin permet de définir ses propres corrections automatiques. Les corrections sont réalisées à l’affichage uniquement, et non lors de la saisie (comme le ferait un traitement de texte).

Règles de correction

Les règles de correction automatique sont indiquées dans le formulaire de configuration du plugin. Vous devez indiquer une seule règle par ligne, sous la forme mot=remplacement [6].

Remplacements simples
Ainsi par exemple, pour corriger la coquille fréquente de l’oeuf qui s’écrit avec un e dans l’o, vous pourrez indiquer la règle :

oeuf = œuf

qui remplacera donc toutes les occurrences du mot oeuf par le mot œuf.

Remplacements par expression rationnelle
Dans des cas plus compliqués, il peut être utile de recourir aux expressions rationnelles. Par exemple, toujours pour notre œuf, si on veut aussi repérer les cas où le mot est en début de phrase, avec parfois son E en majuscule, on peut utiliser une expression rationnelle comme suit :

/O[Ee]uf/ = Œuf

Le fait de faire commencer et finir le terme de gauche par un / indique qu’il s’agit d’une expression rationnelle. Ici Oeuf et OEuf seront remplacés tous deux par Œuf.

Limitations

Les règles de remplacement ne sont pas classées par langue. Le plugin ne permet pas de gérer des règles pour le français et d’autres pour l’anglais : les mêmes règles seront adaptées à tous les textes, ce qui peut être inadapté en cas de site multilingue.

L’ordre des règles de remplacement n’est pas strictement respecté. Pour être exact, toutes les règles de remplacement simples sont appliquées dans l’ordre indiqué, puis toutes les règles de remplacement par expression rationnelle sont appliquées dans l’ordre indiqué.

(Cette fonctionnalité est tirée du plugin Swiss Knife.)

Footnotes

[1] Ou « chiures de mouche » en jargon typographique. Cf. cette page.

[2] Français, anglais, catalan, basque, etc.

[3] Héritée du temps des machines à écrire, où, par économie de place, une seule touche avait été consacrée aux deux formes du guillemet.

[4] Quand ce n’est tout bonnement pas possible de le faire : sous MS Windows et Firefox, entrer les caractères étendus au moyen d’ALT suivi du code voulu, conduit le navigateur, en raison de l’existence de touches d’accès rapides propres à SPIP, à quitter la page en cours.

[5] Le guillemet fermant de premier rang est absorbé par le fermant de second rang, les deux ayant la même forme : « Il dit : « Bonjour » » n’est donc pas admis.

[6] vous pouvez indifféremment laisser des espaces autour du signe =, ils seront ignorés.

Discussion

5 years 1 year 3 months Without limit
par date
Filter

21 discussions

  • 16
    Spectre

    Est-ce normal que le plugin Ortho-typographie en version 2.2.0 et 2.1.0 ne fonctionne pas sur SPIP 4.4.5 ?
    Les espaces fines ne sont plus corrigées correctement. Cela me génère ceci dans le code HTML :

    plus obscur mais plus précis : «
                    <small class="fine d-inline"></small>
                    Le Capital social
                    <small class="fine d-inline"></small>
                    »

    En revanche, pour les capitales, cela semble fonctionner :
    <span class="caps">II</span>

    • Spectre

      J’ai le même problème avec SPIP 4.3.9, mais j’ai un vieux site sous SPIP 4.3.3 sur lequel les espaces fines du plugin Ortho-typographie (version 2.2.0) fonctionnent bien.
      Suis-je le seul à rencontrer ce problème ?

    • Spectre

      Bon, j’ai modifié la function orthotypo_espaces_fines_post_rempl par:

      function orthotypo_espaces_fines_post_rempl($t = '') {
    $fine = '<small class="fine d-inline">&nbsp;</small>';

    $t = str_replace('&#171;&nbsp;', '&#171;' . $fine, $t);
    $t = str_replace('&nbsp;&#187;', $fine . '&#187;', $t);
    $t = str_replace('&nbsp;:', $fine . ':', $t);
    $t = str_replace('&nbsp;?', $fine . '?', $t);
    $t = str_replace('&nbsp;;', $fine . ';', $t);
    $t = str_replace('&nbsp;!', $fine . '!', $t);
    $t = str_replace('&nbsp;%', $fine . '%', $t);
    while (strpos($t, $fine . $fine) !== false) {
        $t = str_replace($fine . $fine, $fine, $t);
    }
    return $t;
}

      et maintenant j’ai bien des espaces insécables qui sont insérés dans ma balise d’espace fine <small class="fine d-inline">&nbsp;</small>

      Il faudrait corriger le plugin.

    • Maïeul

      Oui enfin tu envoi des messages à 2 heures du matin, tu t’attendais vraiment à ce qu’une personne te dise si oui ou non elle à le même problème ?
      Je vais regarder ce qu’il en est, mais &nbsp; c’est une espace insécable quadratin, pas une espace fine insécable. Donc à mon avis si correctif il doit y avoir, c’est ailleurs.

    • Maïeul

      Et donc chez moi j’ai bien une espace qui est inséré. Mais par contre il n’est ni fine, ni insécable...

      donc la question c’est

      1. Pourquoi toi tu n’a pas d’espace alors que moi oui
      2. Pourquoi chez moi l’espace est normal, et non pas fine ni insécable.

      Je suppute une erreur dans le caractère unicode inséré. Je continue de fouiller.

    • Maïeul

      Et donc, j’en suis arrivé à la conclusion suivante

      1. Il doit y avoir un problème chez vous quelque part, car vous auriez du avoir des espaces (pas insécable, mais au moins des espaces)
      2. Dans tous les cas il y avait un problème puisque nous avions des espaces non fine, alors que précisement on veut des espaces fines ; maintenant que les navigateurs savent gérer cela, il ne faut pas utiliser &nbsp; mais &#x202F; qui correspond vraiment à l’espace fine insécable
      3. Le bon correctif serait donc https://git.spip.net/spip-contrib-extensions/orthotypo/-/merge_requests/11/diffs

    • Spectre

      Salut Maïeul,
      Ton correctif fonctionne parfaitement chez moi. Utiliser &#x202F; est bien plus élégant en effet.
      Il manque dans la liste des doubles ponctuations à traiter le : aussi.
      Désolé pour l’heure tardive, je suis assez nocturne.
      Aussi, quand on a du texte aligné sur une grille de base, l’insertion d’une balise <small> (ou <sup> pour les exposants) peut produire un décalage dans le line-height. On peut corriger ça côté CSS avec :

      .fine {
    line-height: 0;
    vertical-align: baseline;
}

      ou

      sup.typo_exposants {
	font-size: 0.8em;
	line-height: 0;
	vertical-align: baseline;
	position: relative;
	top: -0.4em;
}
    • Maïeul

      Pour les 2 points, visiblement c’est fait exprès. VOir doc. Pour le reste je t’invite à ouvrir un ticket...

    • Spectre

      Pourquoi ne pas traiter exprès l’espace avant les : ?

    • Maïeul

      Je ne sais pas, il faudrait demander aux auteurs originaux...

    • Spectre

      D’accord, c’est certainement un oubli ou une erreur d’interprétation des conventions typographiques. Car soit on suit la convention française (espace insécable normale partout), soit on suit la convention suisse (espace fine partout). Mais le deux-points ne souffre d’aucune exception dans la microtypographie suisse. Je peux ouvrir un ticket sur le git SPIP si nécessaire.

    • Maïeul

      Oui ce serait bien d’ouvrir un ticket. Et aussi commenter la MR.

    • Cerdic

      Quand la doc dit explicitement

      À noter, les deux-points <:> ne sont pas concernés par cette règle.

      c’est un peu rapide de décreter que c’est un oubli...

      Et donc je suis pas un spécialiste mais il m’a fallu 2 minutes de recherche pour confirmer qu’en typographie fr (fr_fr plus précisemment donc), le signe deux points <:> prend un espace insécable avant, et non un espace fine insécable
      * https://typomanie.fr/tag/micro-typographie/
      * https://guide-typographie.com/ponctuation_Espaces.htm
      et je retrouve cette règle partout sur internet...

    • Spectre

      Je comprends la distinction, mais je maintiens qu’il existe une incohérence par rapport à l’Imprimerie nationale, qui préconise des espaces insécables normales avant toutes les ponctuations doubles, sans distinction.
      Si le plugin propose une option « espaces fines », deux approches cohérentes pourraient exister :
      • Suivre strictement les recommandations de l’IN : aucune espace fine.
      • Adopter la norme typographique suisse : espaces fines partout, y compris avant les deux-points.

      Le mélange actuel suit les guides que tu cites (Typomanie, Guide typographique.com), qui ne sont pas les standards typographiques ni français ni suisse.
      Serait-il envisageable d’ajouter une option dans la configuration du plugin ? Cela permettrait à chacun de choisir sa convention, sans casser la compatibilité avec les sites existants.

      En somme, une simple case à cocher pour activer ou pour désactiver l’espace fine avant les deux-points.

    • Cerdic

      je t’invite à ouvrir un ticket sur le plugin (ici donc) et à donner des références pour appuyer ton argumentation, car toutes les ressources que je trouve sur le web (pas uniquement les 2 sites cités au-dessus) sont unanimes sur la différence entre le : et les autres caractères de ponctuation double.

      Peut-être que tout le monde à tort mais il semble quand même y avoir un consensus sur le sujet, et le plugin suit donc cette règle...

    • Spectre

      Autant pour moi, je viens de consulter le Lexique des règles typographiques en usage à l’Imprimerie nationale dans sa dernière édition et vous avez raison. Il y a bien dans la convention typographique française une exception pour le deux-points. Toutes les ponctuations hautes (: ; ? !) sont précédées d’une espace fine sauf le deux-points. Par contre, il y est aussi stipulé qu’à l’intérieur des guillemets doubles chevrons il doit y avoir une espace insécable et pas une espace fine.
      J’utilise personnellement la convention typographique suisse éditée en français dans le Guide du typographe, car elle me semble plus logique avec ses espaces fines partout. Le but étant d’éviter tant qu’il se peut les trous dans le gris de page qui pourraient distraire les lecteurs.
      Peut-être cela vaudrait-il la peine de proposer deux options donc. Une version “Typographie française” avec l’espace fine seulement avant le ; ? ! et plus dans les guillemets doubles chevrons, et une version “Typographie suisse” avec l’espace fine partout. Je poste ça ici pour compléter la conversation mais je vais ouvrir un ticket sur le git aussi.

    • ANDRE VINCENT

      Le correctif proposé par Maieul pour remplacer l’espace insécable &nbsp; encapsulée dans un élément small par une véritable espace fine insécable &#x202F; dans ce plugin est une bonne nouvelle. C’est plus sémantique. C’est conforme à toutes les règles et les codes typographiques en vigueur dans la francophonie. Ça améliore la lisibilité des textes en français. Et en prime, U+202F est une espace fixe (non justifiante) contrairement à l’espace insécable normale qui est justifiante. Que du bon, quoi !

      Mais pourquoi continuer à l’encapsuler dans un élément small. Quelle utilité y aurait-il à styler la fine ? Pourquoi alourdir le code pour si peu d’avantages ?

      Depuis quelques mois, j’ai simplifié le code ainsi :

      $nbsp = '&#x202F;';
$fine = '$nbsp’;

      Et ça fonctionne très bien.

      Mais en fait, l’idéal serait que SPIP intègre ce changement, nativement dans sa prochaine version.

    Reply to this message

  • 4
    Sylvain Nogues

    Bonjour,
    j’ai un (gros) paquet d’erreurs dans spip.log :
    orthotypo_filtre_texte_echappe() : orthotypo_espace_fines_rempl() non definie
    spip 4.2.14, php 8.2.21, orthotypo 2.1.0
    Je constate cela suite à une mise à jour d’un site de 3.2 à 4.2, mais je ne sais pas si le problème existait auparavant.
    Une idée ?

    • Syd

      Je constate la même erreur (très très gros paquet) dans spip.log.
      Sans aucune mise à jour de SPIP, c’est un site que j’ai commencé en SPIP 4.2.
      Mais ce plugin est très très bien…

    • Maïeul

      Arf oui j’ai eu cela l’autre jour et pas eu le temps de comprendre le pourquoi du comment. Je vais regarder tiens.

    • Maïeul

      C’est corrigé en v2.2.0

    • Syd

      Super, c’est parfait !!
      Merci

    Reply to this message

  • LeFred

    Bonjour,
    Ortho-typo permettrait-il de séparer les milliers avec des espaces fines insécables ? Je vois (et apprécie) cette fonction pour les mots : pourquoi pas pour les chiffres ?
    Si oui, comment faire ?
    Merci de votre réponse

    Reply to this message

  • Luc

    Bonjour
    Sous Spip 3.2.9
    J’ai activé l’amélioration des abréviations avec exposant.
    Cela semble fonctionner correctement partout, sauf dans la page agenda générée par l’organiseur de plugin-dist (fullcalendar).
    Un titre d’événement, du genre “Détachement 2d degré” affiche ceci sur la page agenda :

    Détachement 2<sup class="typo_exposants">d</sup> degré

    À priori, Ortho-typographie fait son boulot, mais fullcalendar ne l’interprète pas ?

    Reply to this message

  • DD

    Je remarque sur un site en plusieurs langues (la langue par défaut est l’anglais) que les corrections orthographiques d’un article définit comme en français ne sont pas appliquées sauf si le lecteur est un auteur connecté et si sa langue est le français.
    Cela donne des bizarreries comme un saut de ligne avent un “!” (puisqu’il y a un espace avant) et les exposants comme pour Mme qui ne sont pas traités.
    Est-ce parce que ce plugin ne traite que la langue par défaut du site ?

    dd

    Reply to this message

  • 1
    DD

    Bonjour,

    Sur un SPIP 3.1.3 avec les plugins à jour le flux RSS des révisions n’est plus complètement valide :

    49<sup class="typo_exposants">es</sup> Journées 2017 / article 12 / Version : 3

    http://www.feedvalidator.org me dit :
    «This feed is valid, but interoperability with the widest range of feed readers could be improved by implementing the following recommendations.

    line 25, column 149: title should not contain HTML: sup (3 occurrences) [help]

    ... #233;ans 2017 / article 12 / Version : 3
    ^
    line 126, column 0: Missing atom:link with rel=“self” [help]

    »

    Mon lecteur de news ne reconnaît pas le flux

    Merci

    • DD

      Je relance un coup.
      Sur un site en 3.1.6 et ce plugin Version : 1.4.5 SVN [105483] il y a toujours un problème avec les exposants. Le titre de l’item du flux indique en clair :

      30<sup class="typo_exposants">e</sup> anniversaire de l'association  / evenement 2442 / Version : 2

      mais bon progrès : le flux n’est plus marqué comme invalide.

      dd

    Reply to this message

  • eplan

    Bonjour,

    En employant le plugin Ortho-typographie, le titre d’un article rédigé pour partie ainsi «[15**]. XXXX.» se transforme en «[15*. XXXX.». Cela est pour moi dommageable. Existerait-il une solution pour éviter cela en modifiant le code du plugin sans toucher les titres ? En vous remerciant par avance.

    SPIP 3.1.1 [22913]
    Ortho-Typographie 1.4.2
    php5.6

    Reply to this message

  • 1
    Adelaide Barbey

    bonjour, je ne comprends pas comment l’installer..... je ne vois pas de .exe dans la liste des fichiers téléchargés.. help. et comment entrer des guillements directement autour d’un groupe de mots ? merci

    Reply to this message

  • Matthieu Marcillaud

    Un autre souci que je viens de croiser : dans un texte d’article, s’il y a des balises HTML en majuscules, tel que <STRONG>, c’est transformé en <<span class="caps">STRONG</span>>, ce qui casse du coup le code HTML !

    Reply to this message

  • 1138

    Bug dans la correction de « Mn » quand il est suivi d’un caractère accentué

    Hello.

    En utilisant le mot « Mnémotechnique », j’ai constaté qu’il est corrigé en « Mnémotechnique ».

    Pour info, cela fonctionne correctement avec la lame Mise en exposant du Couteau suisse.

    Merci pour ce plugin.

    1138.

    Reply to this message

Add a comment

Avant de faire part d’un problème sur un plugin X, merci de lire ce qui suit :

  • Désactiver tous les plugins que vous ne voulez pas tester afin de vous assurer que le bug vient bien du plugin X. Cela vous évitera d’écrire sur le forum d’une contribution qui n’est finalement pas en cause.
  • Cherchez et notez les numéros de version de tout ce qui est en place au moment du test :
    • version de SPIP, en bas de la partie privée
    • version du plugin testé et des éventuels plugins nécessités
    • version de PHP (exec=info en partie privée)
    • version de MySQL / SQLite
  • Si votre problème concerne la partie publique de votre site, donnez une URL où le bug est visible, pour que les gens puissent voir par eux-mêmes.
  • En cas de page blanche, merci d’activer l’affichage des erreurs, et d’indiquer ensuite l’erreur qui apparaît.

Merci d’avance pour les personnes qui vous aideront !

Par ailleurs, n’oubliez pas que les contributeurs et contributrices ont une vie en dehors de SPIP.

Who are you?
[Log in]

To show your avatar with your message, register it first on gravatar.com (free et painless) and don’t forget to indicate your Email addresse here.

Enter your comment here

This form accepts SPIP shortcuts {{bold}} {italic} -*list [text->url] <quote> <code> and HTML code <q> <del> <ins>. To create paragraphs, just leave empty lines.

Add a document

Follow the comments: RSS 2.0 | Atom