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

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

ဆမိအခြုုခ === ျိ့ြထလူ
 * We don't yet know how to automatically determine all affected pages and templates, but we expect that the list of templates and suggestions will get more complete as we learn about problems that were not caught before. Community Liaisons will reach out to template experts, regulars at technical village pumps, etc. to make sure they become aware of the necessary changes and of resources that may help them.
 * ဆနနိ့ပြ့

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

A: As noted in T134423, the only valid self-closed HTML tags are:,  ,  ,  ,  ,  ,  ,  ,  ,  ,  ,  ,  ,  ,. Non-HTML self-closing tags (like  and  ) are not affected by this change. is a special case because while it is a HTML tag, MediaWiki treats it like an extension tag and hence remains unaffected. All other self-closing HTML tags should be fixed (and are already being fixed by editors at this time).

Since this usage is found in a lot of pages in our testing, in order to prevent unexpected rendering effects (e.g.  being treated as    and causing more text being bolded than intended), we added a fix to the parser to convert them to an empty tag (eg.   will be converted to  ). But, we don't intend to retain this fix indefinitely. So, we would like for editors to continue fixing this deprecated usage.

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. We also expect to leverage this tool to support well-balanced template output. Separately, but relatedly, this will also make the output of the PHP parser (used for reads) and the output of Parsoid (used for edits in VE, Content Translation) more consistent since Parsoid already uses HTML5 semantics. One of our goals is to make the two outputs fully consistent with each other and use one parser for both reads and edits.

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