Still happening, will anyone look into this ? It has been reported for more than 8 months, and CX2 is still regularly producing incorrect syntax on many articles...

Does it include also problems with BookSource, like this article on frwiki ?

For example, T217585 seems to happen still, I've added a recent example

Still happening, see for example Little Gidding (poème)

Hi.
Is it in production? Meaning, if we see problems with new translations, it means the fix is not complete?

Reopening the task as it still doesn't work all the time: there are still id attributes in table titles.

Any news on this one?
CX2 continues to produce doubled ISBN number on articles in production wikis.

Other examples : Air Olaf (March 12th), Arvika (March 14th), Beechwood (manoir Vanderlip) (March 20th)...

@matmarex
Yes, that's wrong, ISBN-13 can start either with 978 or with 979 (currently 979-10 to 979-12 according to ISBN Range, but may increase in the future)
I think Citoid should be fixed to work properly with all ISBN.

It seems to be ok on the last edits I checked, thansk

@Etonkovidova
It doesn't seem to be fixed at all : see for example San Antonio Commanders with id in various places (tables, div inside tables) created today

@santhosh The problem is not only about prefering named HTML entities mentionned in T213275, but the conversion here is even incorrect:   is a regular whitespace character, not at all equivalent to   which is a non-breaking whitespace... I think   should be converted to a regular whitespace, I don't see any reason to have it instead of the regular whitespace inside a normal text.

Thanks, I couldn't find the project in Phabricator (the link in Extension:EasyTimeline creates a task with incorrect project) so I tried to assign the task the author of the extension...

Other edit from the same user seem to have the same kind of problems : https://fr.wikipedia.org/w/index.php?title=Forces_fran%C3%A7aises_%C3%A0_Djibouti&diff=prev&oldid=151141910

The first problem with your reasoning is the deletion ratio.
It's obvious that the deletion ratio should be much lower with CX than with a direct creation, but because the main reason for deleting a new article is that it's not admissible (people creating an article about their company, their band...). If the article already exists in an other language, it has a lot better chance of being admissible, and hence of not being deleted. But it has nothing to do with the fact that it's a translation with a tool like CX... So, using the deletion ratio as a justification is simply taking credit for something that has nothing to do with the tool. The articles that are not admissible are often not candidates for translation. Your conclusions with the difference on the deletion ration are biased towards your tool because you don't take into account the difference in the subjects of the articles...
On the other hand, the work effort to fix all the garbage wikitext that CX is producing requires a lot of efforts from volunteers like me...

@Pginer-WMF
Ways to facilitate the process of cleaning up articles until a stable version is out (as already requested 2 1/2 years ago...) :

I hope this is over and deployed because fixing the articles takes a very long time...
https://fr.wikipedia.org/w/index.php?title=7%2C62_%C3%97_51_mm_Otan&type=revision&diff=148188783&oldid=148054279

And the one I forgot to mention, but that is very frequent and means a lot of work: infoboxes replaced with buggy HTML code with links to modify the article inserted in the pseudo infobox code:

For example, on Elizabeth Reaser:

Similar issues on article Nafessa Williams, on article Amanda Peet and several others... Apparently many edits from user Stef 10 show the problem.

Please note that the request is for arbitrary wikitext : the endpoint must allow to provide the wikitext for the given page, independently of any existing revision (or even if the page exists at all or not). When I read your comments, I'm not sure this is still taken into account.

@cscott : the idea of this request was to be able to check if there are remaining errors before saving the page, so that you can fix them without saving multiple versions of the page...

@Legoktm : what I meant by the "current version of the text" is not necessarily the one saved in the wiki, but the rather the current version in the external tool or in the edit box, so that a user that is modifying an article can check what errors are still there before saving the new version of the text.

Some people started to replace the magic links by some other syntax (templates) on some wikis, and a strange case was also found : it seems that magic links is broken when there are several consecutive filling characters in the text.

@Esanders I was testing the new wikitext editor (included in VE) on beta, and when editing the World page, headings like == World literature == where correctly detected as a Heading, but not ==Test== (which has no whitespace characters between the heading markers and the heading itself).

@Trizek-WMF Not much time to check what's happening, but you can use CW lists to have a quick glance at potential candidates.

In T134423#2475665, @Danny_B wrote:

@NicoV Besides I don't think it's effectively doable to show whether the issue is on the current page or in any transcluded template (mind the transclusion can be several levels deep too), when you hit Preview you already see the tracking category.

In addition to the categorization in [[Category:Pages using invalid self-closed HTML tags]], would it be possible to also have an error message when previewing in edit mode, like what is done for [[Category:Pages using duplicate arguments in template calls]] ? It would help a lot to find where the problem is, and if it's coming from a template used inside the page, rather than from the text in the page.

On frwiki, the problem appeared in the following pages between the February and March dump, I haven't checked what is the proportion of VE edits.
Problems with only [[1990|2000]] are not listed here but can be found with the abuse filter
https://fr.wikipedia.org/w/index.php?title=Sp%C3%A9cial:Journal_du_filtre_antiabus&wpSearchFilter=241

For the 1st and 3rd, I know, but there are only a few articles in these cases (5 of them exactly in total). And they appear at the beginning of the list, because they are recognized as special and my bot didn't flag them with {{Lien à corriger}}... So none of them appear in the dedicated category "Article avec un lien à corriger", and are not counted in the "more than 6.000 articles"

@Whatamidoing-WMF
In addition to the abuse filter that was put in place last year, I've also recently run a bot on a dump from frwiki to find the incorrect links to pages related to years like [[2000|2015]] or [[2000 en musique|2015]].
Result is at https://fr.wikipedia.org/wiki/Projet:Correction_syntaxique/Analyse_526

Still happening on a lot of edits.
Example: https://fr.wikipedia.org/w/index.php?title=Gabrielle_Althen&curid=1425134&diff=123055986&oldid=116857623

Could Parsoid detect this kind of problem (Problem 1) and emit a warning in its ouput, so that the tool using Parsoid (VE here) would prevent the edit and give the user explanation of the kind of problem detected ? That would prevent such extensive damages and let users know about existing problems in articles.

@cscott
I'm only using the edit filter that detects the addition of nowiki tags, no automated tool at all to find them.
I will repeat what I already said so many times : I'm not working for WMF, I'm not the one who has decided to deploy tools too early on large scale without properly testing them, I'm a simple volunteer and I already spend too much time reporting so many problems created by tools deployed without being properly tested (like Content Translation which has been deployed like 6 months ago, and is still creating more damaged articles than clean articles).
So, no I'm not going to hunt the users to understand what they have done to produce the problem : I gave you an easy way to find problematic edits, why the WMF can't contact these users to understand what they did ?
Especially given that often, I don't even get an answer to the problems I'm reporting (see for example T110826), I'm not going to spend my time doing work that is obviously WMF's responsibility.

You also have a different kind of ISBN garbage, like in this edit (and ISBN is only one of the many problems in this edit) :
<cite class="citation book" contenteditable="false">Burton, Brian K. (2007). ''The Peninsula & Seven Days: A Battlefield Guide''. Lincoln: University of Nebraska Press. </cite><cite class="citation book" contenteditable="false">[[International Standard Book Number|ISBN]]&nbsp;978-0-8032-6246-1.</cite><span class="Z3988" title="ctx_ver=Z39.88-2004&rfr_id=info%3Asid%2Fen.wikipedia.org%3ABattle+of+Hanover+Court+House&rft.aufirst=Brian+K.&rft.aulast=Burton&rft.btitle=The+Peninsula+%26+Seven+Days%3A+A+Battlefield+Guide&rft.date=2007&rft.genre=book&rft.isbn=978-0-8032-6246-1&rft.place=Lincoln&rft.pub=University+of+Nebraska+Press&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook" contenteditable="false">&nbsp;</span>

@cscott
If you want a much simpler example, you can take a look at this edit
https://fr.wikipedia.org/w/index.php?title=Alain_Guyard&curid=5509552&diff=120464764&oldid=120423956

Still happening
https://fr.wikipedia.org/w/index.php?title=Diffraction_des_%C3%A9lectrons&type=revision&diff=120404103&oldid=118345718

In T110826#1773815, @ssastry wrote:

Worth verifying that CX is generating the right HTML for ISBN links. If it generates plain text for ISBN numbers, Parsoid will correctly add nowikis around that text. Similar to T113565.

I can confirm that the didn't get an edit conflict, so didn't try to submit the same text again.

Just to be sure: I did a similar test on a test page with a test text, and everything worked as expected : edit conflict detected and I couldn't save my modification.

OK !
I think a content with only whitespace characters could at least be treated as empty (a ref with only whitespace characters is useless).
This will avoid side effects with the parser, and will have 2 advantages :

• do not raise an error in the situation I reported above
• raise an error when you have <ref> </ref> like you have with <ref></ref>

@matmarex
Yes, removing the space works, that's my fix for the second example I provided ;-)
So, it wasn't really correct before, it's just that now the error is visible when it's was completely transparent before ?