Parsoid/Language conversion/Preprocessor fixups/20170501

About
Article counts from the 20170501 dump. It includes all wikis. All details about fixing are in the main page, Parsoid/Language conversion/Preprocessor fixups. As of June 2017, pages containing the syntax at fault are broken (in some cases, you may need to refresh to notice it).

Note that false positives are highly likely. Fixes are only truly necessary when the broken construct is inside a template, wikilink  , or template argument. Also, you decide how much you want to fix: if the local community doesn't care about whether stuff may look broken on pages outside the main namespace, you can just ignore those. Some of those fixes were applied by automatic tools such as AWB. Please ask for instructions if you want to know more about it.

As User:DePiep is doing, please put your name in the "notes" column when you start working through a section in order to avoid duplicating work. Thank you!

Legend:
 * c: chemical-related articles
 * u: URLs -- All are done. -DePiep (talk) 13:32, 12 May 2017 (UTC)
 * o: other/misc articles
 * n: non-articles (everything outside namespace 0)

wikidatawiki
The Wikidata main namespace should have been excluded from this grep because it does not contain wikitext, but JSON blobs of Entity serializations. There is no wiki syntax, so changes to the wikitext parser do not apply there. --Thiemo Mättig (WMDE) 15:16, 16 May 2017 (UTC)
 * I fixed the non-main namespace issues (1 fix, 1 skip). cscott (talk) 15:32, 16 May 2017 (UTC)
 * , . Does this cleanout extend to this situation: in enwiki my chemical template parameter calls wikidata P1234 (which contains the issue code "- {", to be escaped)? IOW, is my enwiki situation safe? -DePiep (talk) 22:20, 19 May 2017 (UTC)
 * You must make sure your code never injects unescaped labels into a wikitext context where certain combinations of characters do have a special meaning. Escaping is typically done with . --Thiemo Mättig (WMDE) 09:35, 20 May 2017 (UTC)
 * This is the answer, read late, to my demo posted below. -DePiep (talk) 22:30, 20 May 2017 (UTC)
 * ... but then: escape how, when and where? Like, in my example below. -DePiep (talk) 22:43, 20 May 2017 (UTC)
 * DePiep, can you mention such a template so we take a look? I don't know whether templates embedding stuff from Wikidata escape anything? --Elitre (WMF) (talk) 15:01, 20 May 2017 (UTC)
 * Example. Such a template would be like
 * :en:Template:Infobox chemical
 * With the property value being, example case: "3- {[(1S,2R)-2,15-Dimethyl-5,14-dioxotetracyclo]sulfanyl}-propanoic acid" (that is: has the tricky code, unescaped in Wikidata).
 * With the property value being, example case: "3- {[(1S,2R)-2,15-Dimethyl-5,14-dioxotetracyclo]sulfanyl}-propanoic acid" (that is: has the tricky code, unescaped in Wikidata).


 * Note 1: Actually not often applied this way in enwiki chemical templates, because editors are worried about data quality & sourcing (in Wikidata).


 * Note 2: The IUPAC name is not yet a Property in Wikidata. The example stays.


 * Now, we know that the value is safe within Wikidata. But in this case, it is read into an enwiki article for regular template parameter processing. This way, that value, while safe in WD, can create the error we are trying to prevent, in enwiki. -DePiep (talk) 22:28, 20 May 2017 (UTC)
 * I was under the impression we are talking about Lua code. In Lua you should make sure to embed labels in . This is not necessary when you use the #property or #statements parser functions. They take care of the necessary escaping. By the way, you should prefer #statements over #property whenever you can! --Thiemo Mättig (WMDE) 07:59, 21 May 2017 (UTC)
 * No, not about Lua code. The code example says it all, I claim. What is your point, ? — Preceding unsigned comment added by DePiep (talk • contribs) 21:26, 28 May 2017 (UTC)‎
 * I'm afraid I do not understand what you are missing? The example is broken. I tried to reconstruct it, ended with, but could not find a problem. --Thiemo Mättig (WMDE) 06:17, 29 May 2017 (UTC)

Thiemo Mättig (WMDE), DePiep, as wmf.2 has been around for a while now, I'm confident we would have known by now if massive breaking had occurred :) --Elitre (WMF) (talk) 09:11, 3 June 2017 (UTC)
 * we run into one issue (T166429) and are not sure if this is related to the parser change. Can you have a quick look, please? --Thiemo Mättig (WMDE) 10:24, 3 June 2017 (UTC)
 * It's the specific team that needs to look at that. I have now properly pinged them on Phab - although it's a Saturday, so there's that. (Not sure why they weren't involved when the issue was first discovered?) --Elitre (WMF) (talk) 11:28, 3 June 2017 (UTC)
 * Both subbu and I responded on Saturday in T166429. Short story: this is a pre-existing bug in LanguageConverter, has nothing to do with the preprocessor change in wmf.2.  (And in fact, the bug was filed before the preprocessor change was deployed.) cscott (talk) 20:21, 5 June 2017 (UTC)


 * Thanks a lot for the quick responses, this was very helpful! We are quite happy with the band-aid we applied for now, and will keep an eye on this. --Thiemo Mättig (WMDE) 19:34, 6 June 2017 (UTC)