Parsing/Replacing Tidy/FAQ/fr

Qu'est-ce que Tidy ?
Tidy is a library currently used by MediaWiki to fix some HTML errors found in wiki pages. Trouver du texte mal formaté est commun dans les pages wiki quand les éditeurs utilisent les balises HTML dans les modèles ou dans la page elle-même. (Exemple: les balises HTML non fermées, comme  sans , sont fréquents). Dans certains cas, MediaWiki peut aussi générer du code HTML érronné par lui-même. Tidy corrige ces erreurs de balises, mais fait aussi du nettoyage de son côté et qui n'est pas nécessaire pour la correction. Par exemple, il enlève les éléments vides et ajoute des espaces entre les balises HTML ce qui peut quelquefois modifier la présentation. Comme Tidy s'appuie sur la sémantique de HTML4 et que le web est passé à HTML5, il apporte aussi des modifications incorrectes au texte HTML pour 'corriger' les choses qui ne marchaient pas; par exemple, Tidy va, sans qu'on le prévoit, déplacer une liste à puces en dehors d'une zone de texte de table bien que cela ne soit pas autorisé.

Pourquoi le remplacez-vous ? Et par quoi ?
La technologie de Tidy date des années 1990, quand les explorateurs pour l'Internet étaient standardisés. Le comportement de Tidy est largement basé sur la sémantique HTML4 mais ne correspond plus aux explorateurs modernes. Après des années passées sans réelle maintenance, Tidy a maintenant été remis à jour sous le nom de "tidy-html5" avec un comportement très différent. L'ancien Tidy n'est plus regénéré. Comme expliqué précédemment, Tidy nettoie le HTML quelquesoit les erreurs à corriger. Conjugués, tous ces problèmes ont conduits à créer beaucoup de bogues qui ont donné lieu à des tickets dans Phabricator, et une demande de produit en remplacement a été faite depuis au moins 2013. HTML5 est le standard aujourd'hui, et l'algorithme d'analyse pour HTML5 est clairement spécifié, ce qui a conduit à des implementations compatibles à travers les navigateurs et autres librairies. Cet algorithme spécifie aussi clairement comment un balisage cassé devrait être corrigé. Dans ce nouveau paysage technologique, Tidy devrait réellement être remplacé par un analyseur HTML5 qui corrigerait le texte déffectueux et en génèrerait un texte HTML valide et bien formaté d'une manière standard. Mais les wikis Wikimedia ont un énorme corpus de pages dont le codage dépend des corrections de Tidy. Faire le remplacement intermédiaire et directement de Tidy par outils tiers basé sur HTML5 n'est pas faisable, car un outil basé sur HTML5 réparerait certains textes différemment et ceci pourrait casser l'aspect des pages. Aussi nous remplaçons Tidy par notre propre outil basé sur les spécifications HTML5, mais qui apporte aussi quelques palliatifs pour la compatibilité avec Tidy, afin de minimiser l'impact du remplacement de celui-ci. Après avoir expérimenté 3 solutions différentes, nous nous sommes fixés sur RemexHTML, un analyseur HTML5 basé sur PHP par-dessus duquel nous avons écrit des couches compatibles avec Tidy afin de pouvoir retrouver certains comportements de Tidy, que nous avons besoin de fournir pour l'instant. A l'avenir, RemexHTML pourrait aussi être utilisé pour activer de nouvelles fonctionalités du noyau de MediaWiki, comme le renforcement de la robustesse de l'édition des sections, le support équilibré des modèles, et un rafraichissement plus efficace des pages après que les modèles aient été modifiés. Pour ceux qui se posent des questions, notez que l'utilisation de tidy-html5 ne nous empêchera pas d'avoir à corriger les erreurs HTML étant donné qu'une partie du nettoyage demandé est due au passage de la sémantique HTML4 à la sémantique HTML5. Il y a d'autres critères pour la gestion des modifications, qui nous ont conduits à préférer un outil interne, entre autre la possibilité d'activer d'autre fonctionalités, comme mentionné ci-dessus.

Si vous êtes intéressé par d'autres détails techniques, veuillez voir https://phabricator.wikimedia.org/T89331 ou Remplacer Tidy.

Quels test avez-vous réalisés jusqu'ici ?
Pour identifier l'impact du remplacement de Tidy par un outil basé sur HTML5, nous avons utilisé une stratégie de test (en utilisant un outil appelé "VisualDiff") qui compare pixel par pixel l'image de sortie de MediaWiki avec Tidy activé, avec celle de l'image remplaçante. Assez tôt, nous avons vu qu'une différence commune résidait dans les modifications mineures des espaces blancs verticaux. En croyant que ceux-ci seraient soit non perceptibles, soit acceptables, nous avons écrit un outil appelé « UprightDiff » qui est capable d'identifier le déplacement vertical à l'intérieur d'une image et de réduire un tel déplacement pour les tests automatisés. Ceci nous a permis ainsi d'assigner une valeur numérique aux différences, et d'identifier immédiatement les différences les plus énormes. Nous avons exporté un sous-ensemble d'environ 64.000 articles (certains issus du flot de modifications récentes, et le reste choisi de manière aléatoire) venant de wikis Wikimedia différents (40 wikis parmi lesquels Wikipedia, Wikisource, Wiktionary, et Wikivoyage), que nous avons fait passer par Tidy et RemexHTML, et ensuite utilisé "UprightDiff" pour analyser le résultat. Ceci occupe beaucoup de cycles du processeur, de la mémoire, et de l'espace disque, et prend 2 jours pour parcourir l'ensemble des tests. Ceci limite la taille du corpus à tester main nous pensons que 64K est un échantillon suffisant pour mettre en évidence les types de corrections nécessaires.

Pour réduire le nombre de différences et l'impact des corrections qui seraient nécessaires aux éditeurs, nous avons ajouté des correctifs compatibles avec Tidy. En remarquant que les balises auto-fermantes étaient très utilisées sur les wikis wikimedia, nous avons ajouté une correction de compatibilité pour les traiter comme des balises vides (par exemple  est synonyme de  ). Nous avons également ajouté quelques autres schémas de compatibilité. Après que tous ces correctifs aient été mis en place et que nous ayons répété nos tests, nous avons trouvé que 93,4% des pages ne présentaient pas de modification dans l'affichage. Et, 96,9% des pages n'avaient soit aucun pixel de différence (93,4%) soit seulement un décalage non perceptible dans l'espacement vertical (3,5% = 96,9 - 93,4). Le reste des 3,1% des pages (100 - 96,9) ont montré des différences de pixel mais pour d'autres raisons.

Sur la base de ces tests, nous avons identifié plusieurs classes d'erreurs de balisage qui provoquaient deux affichages différents. Pour l'une de ces classes d'erreurs (les balises auto-fermantes qui ne sont plus valides en HTML5), nous avons ajouté une catégorie maintenance que les éditeurs utilisaient déja pour corriger les modèles et les pages. Mais les autres classes d'erreurs de balisage ne sont pas faciles aujourd'hui à détecter automatiquement et l'aide des éditeurs est nécessaire pour les identifier et les corriger.

Qu'arrivera-t-il ? Quand ces modifications surviendront-elles ?
Comme indiqué antérieurement, nous ne pouvons cependant pas faire un remplacement ponctuel de Tidy avec un outil basé sur HTML5. Nous avons ajouté une catégorie de maintenance pour une classe d'erreurs de balisage, qui aidera les éditeurs à les corriger. Pour aider les éditeurs à identifier les autres erreurs de balisage, nous avons également écrit l'extension ParserMigration qui les aidera à comparer les sorties en production et à corriger les erreurs de balisage. De plus, avons aussi réalisé l'extension Linter pour identifier quelques-unes des corrections nécessaires.

Ainsi à la fin mars 2017, nous avons déployé les extensions ParserMigration sur tous les wikis. Au 20 juin 2017, Linter a été déployé sur tous les gros wikis. Via ces extensions, nous espérons permettre aux contributeurs de corriger les pages pour effectivement remplacer Tidy en 2017. Une fois qu’assez de corrections seront faites et que nous serons convaincu que l’impact sur les contributeurs et lecteurs sera faible, nous remplacerons enfin Tidy. Mais aussi, nous n'aimerions pas tirer ceci indéfiniment. Il serait donc idéal si les problèmes identifiés par l'extension Linter avec la priorité haute, soient résolus en premier lieu par les éditeurs.

Par ailleurs, les correctifs de compatibilité avec Tidy (mentionnés dans la section précédente) sont supposés être en place jusqu’à ce que nous remplacions Tidy. Après cela, nous commencerons le remplacement de ces correctifs progressivement en s’appuyant sur des tests et outillages similaires.

Que devront faire les éditeurs ?
L'extension Linter a été déployée sur tous les wikis. Comme il est dit sur la page d'aide, veuillez corriger les patterns wikitext et les modèles identifiés parmi les  catégories de haute priorité sur la page Special:LintErrors de votre wiki. Chaque élément dans cette catégorie a une page d'aide avec des exemples qui indiquent ce qui doit être corrigé. Voir les instructions simplifiées ci-dessous.

Pour aider les éditeurs dans la migration de leur texte wiki et vérifier les corrections qu'ils ont faites, nous avons déployé l'extension ParserMigration. Si vous activez "ParserMigration" dans vos préférences, un liens sera ajouté à la boîte à outils de tous les articles, qui pourra montrer côte à côte les sorties courantes (Tidy) et attendues (RemexHTML). Vous pouvez prévisualiser les modifications du texte des articles dans la même vue côte à côte et voir comment vos mises à jour modifient / corrigent l'affichage.

Quel est l'impact sur mon wiki ?
Reportez-vous à l’outil pour le wikicode obsolète pour ces informations. Remarquez que dans plusieurs cas, le compteur indique les pages affectées, mais cela inclue les pages qui contiennent un modèle affecté. En d’autres termes, une fois qu’un modèle donné est corrigé, toutes les pages utilisant ce modèle disparaitront de la liste. Il est donc fort probable que vous n’ayez pas à corriger des milliers ou millions de pages, mais une poignée de modèles. Nous travaillons à rendre cela plus clair. Vous pouvez aussi voir en partie la progression sur Parsing/Replacing Tidy/Linter/Stats/July31, et les résultats de tests d’écarts visuels sur un échantillon d’environ 73 000 articles de 60 wikis sur http://mw-expt-tests.wmflabs.org/.

Instructions simplifiées pour corriger les pages
Il existe quelques instructions simplifiées pour gérer toutes les catégories linter de priorité haute. Certaines pages d'aides référencées peuvent contenir des instructions pour utiliser des outils d'assitance comme WPCleaner.

Supprimer OU corriger les tables mal imbriquées
Dans cet exemple, Tidy supprimera le tableau 2 du dessus. Mais RemexHTML ne supprimera pas ce tableau. Cela peut changer l’apparence des pages. Pour empêcher cela, les contributeurs devraient corriger le wikicode et supprimer le tableau 2. Bien que les balises en ligne suivante ne nécessitent pas d’être supprimées, nous recommandons de le faire tout de même. Puisque la balise de fermeture du tableau n’est plus nécessaire, elle devrait être supprimée également.

Une autre solution est d’ajouter une cellule explicite  sur la rangée commençant par la ligne précédente avant le début du tableau 2 si vous souhaitez des tableaux imbriquées. La correction à appliquer dépend de la page, mais dans la plupart des cas, la suppression décrite ci-dessus sera une bonne correction.


 * Help:Extension:Linter/deletable-table-tag

Palliatif pour corriger un bogue de l'analyseur dans les cas de repli de paragraphe
Sur la plupart des wikis, il semble que le plus gros générateur de ces problèmes de syntaxe sont les modèles nobr (nowrap, pas de retour à la ligne) ou nowrap begin. Le correctif le plus simple qui corrigerait la grosse majorité de ces détections d’erreur est l’ajout d’une nouvelle ligne avant la balise ouvrante  dans le code source de ces modèles.

Dans tous les autres cas, lorsque le wikicode a un span à côté d’une div ou td (et autres balises de type bloc similaires) et a la propriété CSS, ajoutez une nouvelle ligne après la balise div.


 * Help:Extension:Linter/pwrap-bug-workaround

Corriger les balises auto-fermantes invalides
Les balises auto-fermantes comme &lt;div/>, &lt;span/>, &lt;b/>, etc... ne sont pas valides en HTML5. Elles doivent être corrigées en fonction de l'intention de l'éditeur. Dans certains cas, il s'agissait d'une faute de frappe où un &lt;/b> était attendu. Dans d'autres cas, ils ont dûs être supprimés. Dans d'autres encore, ils ont dûs être remplacés par un &lt;nowiki/>. Veuillez vous reporter à la page d'aide détaillée pour cette catégorie.


 * Help:Extension:Linter/self-closed-tag

=== နမအအ့်ပုး

ဆမိအခြုုခ === ျိ့ြထလူ
 * Nous ne savons pas encore comment déterminer automatiquement toutes les pages affectées et modèles, mais nous espérons que la liste de modèle et suggestions sera plus complète lorsque nous serons au courant de problèmes n’ayant pas été détectés auparavant. Les Community Liaisons (personnels faisant le lien avec les communautés) se mettront en lien avec les experts modélistes, les habitués des bistrots, etc. pour s’assurer qu’ils soient au courant des changements nécessaires et des ressources qui pourraient les aider.
 * ဆနနိ့ပြ့

Autres FAQs
Q: Qu'arrive-t-il à  et aux balises similaires si elles sont utilisées dans une forme auto-fermante ?

A : Comme noté sur T134423, les seules balises HTML autofermantes autorisées sont :,  ,  ,  ,  ,  ,  ,  ,  ,  ,  ,  ,  ,  ,. Les balises autofermantes non HTML (comme  et  ) ne sont pas concernées par ce changement. est un cas à part puisque, bien que ce soit une balsie HTML, MediaWiki la traite comme une balise d’extension et elle n’est par conséquent pas affectée. Toutes les autres balises HTML autofermantes doivent être corrigées (et sont déjà en train d’être corrigées par les contributeurs en ce moment).

Puisque cette syntaxe est utilisée dans de nombreuses pages de nos tests, dans le but d’éviter des conséquences inattendues sur le rendu (par exemple  traitée comme   et mettant donc plus de texte en gras que souhaité), nous avons ajouté un correctif à l’analyseur syntaxique (parser) pour les convertir en balises vides (par exemple,   sera converties en  ). Mais nous n’avons pas l’intention de laisser ce correctif indéfiniment. Nous aimerions donc que les contributeurs continuent à corriger ces syntaxes obsolètes.

Q: Quels sont les résultats des tests pour les langues différentes de l'anglais, ou sur les projets frères ?

R: Il n'y a rien dans ce que Tidy et RemexHTML font, qui soit spécifique à Wikipedia ou à la langue anglaise. Ce projet concerne initialement un changement des sémantiques HTML4 en HTML5 et du désir de se débarasser de certains réarrangements faits sur le HTML par Tidy. Ces modifications concernent tous les projets et toutes les langues sans distinction, sauf si certains projets ou certaines langues ont tendance à avoir plus d'erreurs HTML, ou utilisent plus de balises auto-fermantes que d'autres.

'''Q: Quels sont les autres changements que les éditeurs pourraient voir, après ce remplacement ? '''

R : l'effet de cette substitution va d'abord toucher les lecteurs qui pourront éventuellement remarquer que la page ne s'affiche pas normalement (par exemple, des boîtes de navigation trop larges, sans retours à la ligne ni repli). However, if anything, this might lead to the rendering seen in VisualEditor to match the rendering seen outside it much more than before, since Parsoid's output has been HTML5-compliant since the beginning, and we are now moving the read output to HTML5. We do not expect any impact on VisualEditor edits, but we will promptly address any bugs reported with respect to dirty diffs. In addition, we do not plan to add any error messages or warnings displayed on pages if the markup errors are not fixed.

Q: Comment le remplacement garde-t-il les liens avec les autres projets sur lesquels vous travaillez ?

R : En autorisant le passage à la sémantique HTML5, voici un point concernant l'évolution des balises dans notre corpus à garder en accord avec le standard du web. Nous souhaitons également élever cet outil pour prendre en charge les sorties de modèles équilibrés. Par ailleurs, cela rendra les sorties de l’analyseur syntaxique PHP (utilisé pour la lecture) et de Parsoid (utilisé pour les modifications avec l’éditeur visuel et l’outil de traduction de contenu) plus cohérentes puisque Parsoid utilise déjà la sémantique du HTML5. Un de nos objectifs est de rendre les deux sorties complètement cohérentes entre elles et utiliser un unique analyseur pour la lecture et la modification à la fois.

--L'Equipe de l'Analyseur

Des volontaires disponibles pour supporter cet effort
''Les membres de liaison de la Communauté invitent les Wikimediens intéressés à bien vouloir ajouter leur nom dans les sections ci-dessous et à soutenir les efforts de la Communauté dans ses engagements. Merci. Comme avec les initiatives similaires par le passé, l'adhésion est optionnelle.'' Veiller consulter Parsing/Get_involved, et le mettre dans vos favoris, car les demandes d'assistance utltérieures se feront par l'intermédiaire de cette page !
 * 1) Je suis disponible pour faire les tests avec l'outil ParserMigration (analyse de la migration).
 * 2) (ajoutez votre signature ici)
 * 3) Je suis disponible pour corriger les modèles.
 * 4) Jonesey95 (talk) 16:10, 14 November 2016 (UTC)
 * 5) Samuele2002 (talk)
 * 6) TheDragonFire (talk)
 * 7) Stryn (talk) 14:22, 17 July 2017 (UTC)
 * 8) Je suis disponible pour étudier et discuter des corrections concernant les modèles.
 * 9) Jonesey95 (talk) 16:10, 14 November 2016 (UTC)
 * 10) Je suis disponible pour diffuser les informations à ma communauté.
 * 11) (See this page) --Sannita (talk) 18:02, 8 July 2017 (UTC)
 * 12) See this page. Stryn (talk) 14:22, 17 July 2017 (UTC)
 * 1) (See this page) --Sannita (talk) 18:02, 8 July 2017 (UTC)
 * 2) See this page. Stryn (talk) 14:22, 17 July 2017 (UTC)