So it is indeed the page code that's wrong... [12:18:52] However I've seen this situation arise a lot on Wikisource/Wikiquote etc.. [12:19:44] So was thinking this might be a situation where (as far as mediawiki is concerned) certian phrasing tags should be treated as pusdeo tags and 'cooked' in the rendered output [12:19:51] into div or span as appropriate [12:20:23] The issue of 'flow' vs 'phrasing' content may also be the cause of my endless rows when doing certain layouts [12:20:34] yes but this is mostly because the people that make these templates don't know advanced html semantics and aren’t necessarily using the correct markup, which is causeing issues when debugging [13:40:18] Is there a means of get MW docs offline? [13:40:50] Like what is here; https://doc.wikimedia.org [13:41:17] Is it possible to get something similar offline on local instance? [15:16:13] Hi anyone got access to the Linterorr queue? [15:16:21] https://en.wikisource.org/w/index.php?title=Page:Ruffhead_-_The_Statutes_at_Large_-_vol_9.djvu/625&action=edit&lintid=748673 [15:16:36] I updated the underlying template and wanted to make sure the logic was know working [15:16:40] now [15:27:09] Okay [15:27:23] Can someone check the logic in a template before I really get annoyed? [15:27:36] https://en.wikisource.org/wiki/Template:Cl-act-paragraph [15:27:56] Thanks to the new parser being pedantic about tag matching this template broke [15:28:17] Meaning that as a sizeable chunk of material on Wikisource causes a lot of errors [15:28:34] *relies on that template [15:59:00] Dysklyver: ^ see above [15:59:39] yes [16:03:05] The issue is one of mis-matched

and I thought in the most recent update of the template I'd added some logic to address those concerns. [16:03:17] However the logic doesn't seem to be working yet [18:05:12] Yet another broken template due to parser issues [18:06:07] https://en.wikisource.org/wiki/Page:The_Traffic_Signs_Regulations_and_General_Directions_2016_(UKSI_2016-0362).pdf/524 [18:06:33] Somewhere in this page there is "intterupted phrasing" but having looked at my code I can't see it [18:06:54] Congratulations, you've finally triggered my stress point [18:07:36] If updating the parser is going to produce countless busted templates... [18:08:08] and associated stress in resolving them perhaps it's time to reconsider some fundamental architecural issues as well? [18:08:37] Let's break everything once rather than have a continual cycle okay? [18:14:57] no? [18:18:17] andre: I am saying that whilst you have major work going on , it would be sensible if some other long standing issues that would also cause breakages if addressed can also be accounted for [18:18:46] Like redoing the wiring when you have the floor-board ups for putting in pipes :) [18:21:26] nah, then you usually get "'while at it' seemed like a good idea but now it's broken and we can't tell whether it was due to the wiring or the pipes" [18:21:58] that ^ [18:31:06] The problem with the linked page seems to be some kind of "intterupted" phrasing [18:31:26] There's a missing SPAN identfied for the page, but also a stripped SPAN [18:31:43] suggesting a block level element is being placed inside nominal span somehow [18:32:17] I may file a ticket on Phab asking for a documentation page detailing what you can and can't embed in what [18:32:44] And then use that to Strongly suggest local project start compiling more detailed lists of what templates can go inside each other [18:33:12] d3r1ck: Answering your question about the docs. First of all, those are generated automatically, so I think there should be a way to generate local copy. And there is also another way - you can just use special application which will scrap docs and download everything to your computer to be viewable offline. [18:33:14] Currently other than Linter, there's no sanity checks involved in nesting templates ;) [18:33:51] which means that many many pages break because people have in error assumed that because something worked it was valid [18:33:53] ;) [18:33:58] (myself included) [18:34:20] If the parser is being updated to be a lot tighter in how it handles things, perhaps it would be wise [18:34:32] (given that a number of templates are already nominaly broken) [18:34:46] to enforce nesting rules on which templates you can put inside others [18:35:10] But nah... that would be eminently too sensible wouldn't it ? [18:37:30] Are you trying to be productive or just rant? [18:41:39] greg-g: it looks likes hes describing an issue of a sort [18:49:31] In an unhelpful manner, as best as I can tell. [18:55:47] greg-g: Trying to rant productively... XD [18:56:09] Okay I'll take it elsewhere... [18:57:02] A task describing the problem would be a good next step. But alas. [19:17:42] hi [19:17:57] what happening with zuul? [19:18:42] what happening with zuul? [19:19:10] see how much patches in postmerge [19:19:23] which waiting from yesterday [19:25:12] I've calmed down a little [19:25:21] I had a question [19:25:28] which was as follows: [19:25:42] Does mediawiki define a tag precedence ? [19:25:58] In maths you have the BODMAS rule... for determing how you do things... [19:25:59] Zoranzoki21: nodepool had a issue with the restarts that been going on (IIRC) it has been said it should return to normal on its own [19:26:08] hi Zppix [19:26:12] ShakespeareFan00: not to my knowledge [19:26:39] Would it be sensible to define a 'preceedence' list of formatting tags? [19:26:50] Zoranzoki21: those look to be stale, do you have one that shows a test for a patch that is actually needed? The top one is already tested/merged. [19:27:06] greg-g: I just killed the "next to be run" one [19:27:12] The one after is running now... [19:27:14] I.e there are tags like shich have to be outside etc [19:27:20] Zppix: I see to now is small faster [19:27:34] Obviously has to be inside

and so on [19:27:45] Reedy: I was wondering what happened there :) [19:27:52] idle hands [19:28:12] Defining which way round you are supposed to do things like [19:28:16] would be helpful [19:28:46] HTML 5 to some extent define a tag precedence by tag model... [19:28:48] *content [19:28:57] but doesn't go into more detail [19:28:57] Does the HTML spec not define this? [19:29:09] Only in terms of flow vs phrasing [19:29:29] It doesn't I think say is higher than etc [19:30:00] Mediawiki on the other hand might need to [19:30:15] in order to resolve situation where you have nesting... [19:30:25] (if only to indicate a possible mismatch) [19:30:36] ShakespeareFan00: I think its first i dont know about the rest of the order [19:31:00] I've also found that sometimes I've had to move ''' ''' inside a font tag [19:31:07] or span [19:31:35] If this is defined in mediawiki by some kind of behaviour it would be nice to know the conventions [19:31:37] :) [19:35:45] I think to is finally all ok with zuul. [19:36:38] But I no believe to is for "easy patch" so slow [19:38:13] But, what happening with beta-mediawiki-config-update-eqiad now? [19:41:39] Zoranzoki21: which easy patch is so slow? remember, these that you are looking at are *post-merge* jobs. [19:42:05] they are de-prioritized so that pre-merge tests are not slowed down by post-merge doc updates [19:42:09] greg-g: ok. why 5 patches for beta-mediawiki-config-update-eqiad patches for 1 minutes removed from list? [19:42:29] greg-g: Is it ok or? [19:42:37] yes, they were being processed. [19:42:49] see the "deployment-in" executer [19:43:04] they update the code on the beta cluster (deployment-prep) [19:43:08] they're doing fine afaict [19:43:08] greg-g: Ok, super than. Now is all ok [19:43:17] Now is all ok. Thank you for replies [19:43:17] it was all ok :) [19:43:46] Now on list are not much patches from yesterday [19:43:55] Now is cleaner [19:44:39] yeah, one was stuck (due to the nodepool restart which was due to the Cloud Services fleet wide restarts due to a kernel upgrade), Reedy kicked it, now they all went. [19:44:53] lot's of nested "due to"s there :) [20:01:36] greg-g: "It was on a monday morning the gas-man came to call.." [20:01:38] ;) [20:01:39] XD [20:01:46] Classic Comic song... [20:03:38] Another thought... Is it documented anywhere what the precise semantics for when whitespace is a line break vs just whitespace defined? [20:03:56] I've had plenty of templates that rely on very specfic handling of that [20:06:21] ShakespeareFan00: heh, nice (first I've heard of that song) [20:06:36] Let me find more informatiob [20:07:08] http://iankitching.me.uk/humour/hippo/gas.html [20:12:38] that's the link I found, too [20:29:39] greg-g: Where can I suggest a 'documentation' issue on phabricator? [20:30:39] ShakespeareFan00: http://phabricator.wikimedia.org/tag/documentation/ [20:30:58] ^ [20:31:32] ShakespeareFan00: also include the relevant project/software if applicable. #documenatation is just a "tag" so it can get lost without a home [21:01:39] thanks [21:02:15] BTW A lot of the errors I'm finding at the moment are due to the stuff that shouldn't have worked [21:02:33] Like a [[File:]] (IMG level element inside a span) [21:02:44] inside an anchor [21:03:11] It won't work because the relevant template use a span wrapper [21:04:31] Do you know how to do make an anchor that works to link a File: ? [21:04:38] https://en.wikisource.org/w/index.php?title=Template:Anchor%2B&action=edit being the code that broke [21:12:43] Hmm - Time to make a request I think.. [21:14:52] greg-g: Would there be any interest in being able to link directly to images? [21:15:24] if you embed an image by default it already does have a link to its File: page? [21:15:32] or what is "link directly"? [21:15:46] As in link to a specfic image in a wiki page [21:15:59] https://en.wikisource.org/w/index.php?title=Page:UK_Traffic_Signs_Manual_-_Chapter_7_-The_Design_of_Traffic_Signs_2013.pdf/21&diff=prev&oldid=7205222 [21:16:08] contains 2 figures which are referenced eslewhere [21:16:42] Currently there's doesn't seem to a way to directly link to them as the generated img tag doesn't contain an id= field [21:16:43] so you want an anchor by default for any file embedded in a wiki page? [21:16:50] No.. [21:17:17] I am wanting an option in the image syntax to say [[File:Complex figur_1.svg|500px|a=fig1]] [21:17:33] and a=fig1 solves which problem? [21:17:35] which would mean id="fig1" gets put in the generated IMG tag [21:17:37] he wants a HTML id=FOO or name=FOO so that section links work. [21:17:49] ah. [21:18:06] why isn't such an ID auto-generated, based on the file name? [21:18:41] what's the usecase for having to manually add a custom value for such an additional parameter? [21:18:46] andre__: That I don't know, but filenames may contain charcters that aren't valid for an id file [21:19:15] andre__: The sue case in this example is cross referencing a text mention of the figure to the actual figure [21:19:19] *use [21:19:52] yeah, IDs in HTML4.01 must not start with a number etc [21:20:10] IE when you find a text reference to Figure 3.1 or whatever you can put [[#fig3.1|Figure 3.1]] to create a hyperlink [21:20:17] how often is that needed? [21:20:37] In respect of the work linked in wikisource at least 50 or so times [21:21:25] But being able to do cross referencing to images would be useful on Wikisource, and for some scientific works on Wikiversity [21:21:37] which cross-refence text content to specfic figures. [21:22:27] probably Wikibooks, too. [21:22:48] I'm saying it should ideally be a user supplied option in the File syntax because generally not all images need to be linked in this way [21:23:21] and in respect of my usecase I'd set up the links with anchor+ to use a specfic naming system [21:23:40] which would be realtivly static [21:23:51] compared to what might be automatically generated [21:23:51] ShakespeareFan00, I agree you should write this down as a clear/concise phab feature-request. Tag it with #multimedia -- I don't think we can help much in here. [21:24:03] I'll certainly think about [21:24:37] An extension to it would be much more complex and more like the link to specic frame functionality that YouTube has on Video clips [21:25:01] * Platonides hasn't still understood what is needed [21:25:31] couldn't you link to the section of the image? [21:25:44] of do
[[File:Bar.png]]
[21:25:44] Platonides: Not easily... [21:26:22] Platonides, yes, but what if the section is many paragraphs long, and the image is near the end (or just below the fold because of window size etc). [21:26:46] Platonides: Yes.. but there may be instances where using a DIV in that manner may cause other formatting breaks or mis parsing [21:26:46] sure, that's the limitation [21:26:53] are there? [21:26:55] ShakespeareFan00, one issue per task ;-) [21:27:09] I thought [[File: ]] added a div [21:27:17] It doesn't [21:27:22] so another div around it shouldn't harm [21:27:24] hmm :/ [21:27:25] At least not in the code I am looking at it [21:27:29] in [21:28:08] It generates 2 wrapped div and an img [21:28:22] div yes, id no. [21:28:29] One of those wrapped div could have an id="" tag added. [21:28:48] which would be immensely useful.. [21:28:51] ShakespeareFan00: xD [21:28:55] (to the song) [21:29:17] ShakespeareFan00: my point was, you could add a third div with a custom tag [21:29:25] True [21:29:26] *a custom id [21:29:51] though I agree it's cleaner doing it in the File: syntax [21:29:51] But adding a manual wrapping div on 50 or so images is time-consuming and error prone [21:30:23] Platonides and quiddity... Do you mind me quoting you in any phab ticket if I file one? [21:30:40] sure, no problem [21:30:52] andre__ : Same question? [21:31:20] not that I have said anything specially enlightening, thoughprobably [21:31:31] I don't mind, but it's best to write clear *short* descriptions. Don't just dump a large discussion into the description, and expect people to read it all. :) [21:31:54] I'll try and distill it down a bit... won't post the log unless someone asks for it.. [21:32:14] I need to take a break, so it may be a few weeks before I post anything on phab... [21:32:17] This whole idea could be expressed in 3 lines. Use-case, current missing functionality, suggested solution. [21:32:37] Besides I've exceeded my bug reporting quota for the week :(