Analyse/Remplacement de Tidy/FAQ

From MediaWiki.org
Jump to: navigation, search
This page is a translated version of the page Parsing/Replacing Tidy/FAQ and the translation is 70% complete.

Other languages:
العربية • ‎Deutsch • ‎English • ‎français • ‎italiano • ‎日本語 • ‎Nederlands • ‎українська

Qu'est-ce que Tidy ?[edit]

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 <small> sans </small>, 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 ?[edit]

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 ?[edit]

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 <b/> est synonyme de <b></b>). Nous avons également ajouté quelques autres schémas de compatibilité. After all these fixes were in place and we repeated our tests, we found that 93.4% of pages had no changes in rendering. And, 96.9% of pages had either no pixel diffs (93.4%) or insignificant vertical whitespace shifts only (3.5% = 96.9 - 93.4). The remaining 3.1% pages (100 - 96.9) showed pixel differences that had other reasons.

Based on these tests, we identified several classes of markup errors that will render differently between the two. For one class of markup errors (self-closing tags that aren't valid in HTML5), we added a maintenance category that editors have already been using to fix up templates and pages. But, the other classes of markup errors are not easy to detect automatically at this time and editors' assistance is necessary to identify and fix them up.

Qu'arrivera-t-il ? Quand ces modifications surviendront-elles ?[edit]

Comme indiqué antérieurement, nous ne pouvons cependant pas faire un remplacement ponctuel de Tidy avec un outil basé sur HTML5. We have added a maintenance category for one class of markup errors, which will help editors fix them up. To help editors identify and fix up other markup errors, we also built a ParserMigration extension that helps them compare output in production and fix markup errors. De plus, avons aussi réalisé l'extension Linter pour identifier quelques-unes des corrections nécessaires.

As of end March 2017, we deployed the ParserMigration extensions to all wikis. As of June 20, 2017, Linter has been deployed to all large wikis. Via these extensions, we hope to enable editors fix up pages for actually replacing Tidy in 2017. Once enough fixes are made and we are satisfied that the impact on editors and readers will be minor and tolerable, we will go ahead and replace 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.

Separately, the Tidy-compatibility fixups (mentioned in the previous section) are meant to be in place till we replace Tidy. After that, we will start replacing these fixups gradually while relying on similar testing and tooling support.

Que devront faire les éditeurs ?[edit]

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 ?[edit]

Please see the wikitext deprecation tool for this information. Note that in several cases the count refers to pages affected, but that includes template-generated issues. In other words, once a given template is fixed, all the pages featuring that template will disappear from the list. So it's highly likely that you won't have to fix thousands or millions pages, but a handful of templates. We are working to make this even more clear. You can also see some progress on Parsing/Replacing Tidy/Linter/Stats/July31, and the results of visual differences tests on a sample of ~73K articles from 60 wikis at http://mw-expt-tests.wmflabs.org/ .

Instructions simplifiées pour corriger les pages[edit]

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[edit]

{| <-- Table 1 starts here
| foo
|-
{| <-- Table 2 starts here. You can remove this code.
|- <-- Row for Table 2. You may remove this too if you wish so.
| bar
|} <-- this closing tag is now useless and should be removed too
|}

In this example, Tidy will delete Table 2 above. But, RemexHTML will not delete that table. This can change how pages look. To prevent this, editors should fix the wikitext and remove Table 2. While the following row-tag need not be removed, we recommend removing it. Since the closing table tag is no longer needed, it should be removed as well.

Alternatively, add an explicit | cell on the row started by the previous line before the start of Table 2 if you need nested tables. What is the correct fix depends on the page. But, in most cases deletion as above is going to be the right fix.

Palliatif pour corriger un bogue de l'analyseur dans les cas de repli de paragraphe[edit]

On most wikis, it looks like the biggest generator of these linter warnings are the nowrap or nowrap begin templates. The simplest fix that will handle the vast majority of these linter cases is to add a newline before the opening <span> tag in the template source of these templates.

In all other cases, when wikitext has a span next to a div/td (and other such "block" tags) and has a white-space:nowrap CSS property, please add a newline after the div tag.

<div><span style='white-space:nowrap'>      <------ ADD NEWLINE AFTER THE <div>
foo
</span>
</div>

Corriger les balises auto-fermantes invalides[edit]

Les balises auto-fermantes comme <div/>, <span/>, <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 </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 <nowiki/>. Veuillez vous reporter à la page d'aide détaillée pour cette catégorie.

Caveats[edit]

  • 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.
  • We are thinking about other easy, sustainable ways in which we may support "gnomes" and all the Wikimedians willing to help with this effort.


Autres FAQs[edit]

Q: Qu'arrive-t-il à <pre/> 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: area, base, br, col, embed, hr, img, input, keygen, link, meta, param, source, track, wbr. Non-HTML self-closing tags (like <references /> and <nowiki />) are not affected by this change. <pre> 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. <b/> being treated as <b> and causing more text being bolded than intended), we added a fix to the parser to convert them to an empty tag (eg. <b/> will be converted to <b></b>). 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: How does the replacement relate to other projects you are working on?

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[edit]

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).
    1. (ajoutez votre signature ici)
    2. ...
    3. ...
  2. Je suis disponible pour corriger les modèles.
    1. Jonesey95 (talk) 16:10, 14 November 2016 (UTC)
    2. Samuele2002 (talk)
    3. TheDragonFire (talk)
    4. Stryn (talk) 14:22, 17 July 2017 (UTC)
  3. Je suis disponible pour étudier et discuter des corrections concernant les modèles.
    1. Jonesey95 (talk) 16:10, 14 November 2016 (UTC)
  4. Je suis disponible pour diffuser les informations à ma communauté.
    1. (See this page) --Sannita (talk) 18:02, 8 July 2017 (UTC)
    2. See this page. Stryn (talk) 14:22, 17 July 2017 (UTC)