Parsing/Replacing Tidy/FAQ/fr

Qu'est-ce que Tidy ?
Tidy est une bibliothèque actuellement utilisée par Mediawiki pour corriger certaines erreurs HTML trouvées dans les pages de wiki. Le balisage mal formé est courant dans les pages wiki quand les contributeurs utilisent des balises HTML dans les modèles ou dans la page elle-même. (Exemple : les balises HTML non fermées, comme  sans , sont fréquentes). Dans certains cas, MediaWiki peut aussi générer du code HTML erroné par lui-même. Tidy corrige ces erreurs de balises, mais fait aussi de son côté du nettoyage non nécessaire à l’exactitude du code. 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 HTML 4 et que le web est passé à HTML 5, il apporte aussi des modifications incorrectes au code HTML pour « corriger » les choses qui n’étaient auparavant pas permises ; par exemple, Tidy va, sans qu'on le souhaite, déplacer une liste à puces en dehors d'une zone de légende d’un tableau bien que cela soit autorisé.

Pourquoi le remplacez-vous ? Et par quoi ?
La technologie de Tidy date des années 1990, quand les navigateurs web n’étaient pas standardisés. Le comportement de Tidy est librement basé sur la sémantique HTML 4 mais ne correspond plus aux navigateurs 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 empaqueté. Comme expliqué précédemment, Tidy fait du nettoyage de HTML sans lien avec les erreurs à corriger. Conjugués, tous ces problèmes ont conduit à créer beaucoup de bogues qui ont donné lieu à des tickets dans Phabricator, et une demande de son remplacement a été faite depuis au moins 2013. HTML 5 est le standard aujourd'hui, et l'algorithme d'analyse pour HTML 5 est clairement spécifié, ce qui a conduit à des implantations compatibles à travers les navigateurs et autres bibliothèques. 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 HTML 5 qui corrigerait le code défectueux et en génèrerait un code HTML valide et bien formé d’une manière standard. Mais les wikis Wikimedia ont un énorme corpus de pages dont le codage dépend des corrections de Tidy. Remplacer immédiatement et directement Tidy par un autre outil basé sur HTML 5 n'est pas faisable, car un outil basé sur HTML 5 réparerait certaines balises 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

Avertissements
ျိ့ြထလူ
 * 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). Cependant, dans tous les cas, ceci pourrait amener le rendu visible dans l’éditeur visuel à correspondre bien davantage avec le rendu en lecture, puisque la sortie de Parsoid est conforme au HTML 5 depuis le début et nous travaillons maintenant à le rendu en lecture devienne du HTML 5. Nous n’attendons aucune conséquence sur les modifications faites avec l’éditeur visuel, mais nous corrigerons rapidement tout bogue signalé concernant des différences inattendues. De plus, nous ne prévoyons pas d’ajouter des messages d’erreur ou d’avertissement sur les pages où les erreurs de balises ne seraient pas corrigées.

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)