[00:00:03] Ivy: sure, but we also like minimal testcases :) [00:00:07] That's unhelpful [00:00:32] I don't consider trying to find out why something that should be simple [00:00:40] is proving to be a 3 day hassle [00:00:43] Should be simple? [00:01:01] especially when the SAME approach was used on other pages with no issues [00:01:05] Complex input --> complex output? [00:01:18] bawolff: There were and are lots of approaches we could've taken to make templates less horrible, and yet! [00:01:52] What I am trying to do is "wrap" content so that I can add side-titles in a clean way [00:02:13] The previous approach using a DIV based system didn't work either [00:02:55] I remain convinced that it MUST be a coding error of mine [00:03:11] but having tried at least 3 different ways I am starting to wonder [00:03:54] of course if Mediawiki handled proofread page stuff in a sane way [00:04:05] We would not be having this conversation [00:04:45] As no one seemingly cares, it looks like I'll have to conclude the template or that page can't be fixed. [00:10:15] Note to self [00:10:22] Do not attempt to code when angry [00:10:31] You'll miss the obvious mistake [00:10:35] ¯\_(ツ)_/¯ [00:10:59] got the parameters for something mixed up... [00:11:13] * ShakespeareFan00 offers the group an unconditional apology [00:12:54] Ivy... [00:13:06] I figured out my coding error eventually [00:13:30] I'd confused two parameters and used the 'wrong' one... [00:13:33] ShakespeareFan00: Nice! [00:13:44] It solves the immediate issue [00:13:48] ShakespeareFan00: Using named parameters can help with that. [00:13:58] These WERE named :( [00:14:08] Silly. [00:14:30] and I wrote the original template [00:14:34] XD [00:15:48] And I'm sorry about getting heated [00:16:08] That said I've noted something in it works and shouldn't [00:16:12] XD [00:18:44] Ivy: Can I ask I very odd question? [00:18:56] ShakespeareFan00: Sure. [00:20:16] In user pyschology is there a situation when under stress that you will become utterly convinced you can;t be the one making a mistake and that it must be a bug? [00:21:45] Denial? [00:24:21] http://www.baltimoresun.com/health/maryland-health/bs-hs-caring-for-caregivers-20150621-story.html seems vaguely related. [00:26:33] ShakespeareFan00: for what it's worth I learned through repetition to always believe that my code is broken first. That was not my instinct when I started coding though. :) [00:27:07] I've not got an escaping DIV https://en.wikisource.org/wiki/Page:Railways_Act_1921_(ukpga_19210055_en).pdf/92 [00:27:16] *I've now got an escaping [00:31:04] ShakespeareFan00: if you can trick subbu into looking he may be able to spot something for you [00:31:28] Nah.. He's too busy on fixing morr important templates I asked [00:41:13] ShakespeareFan00, this may just be another instance of https://phabricator.wikimedia.org/T162935 [00:41:59] Also sometimes I've found I;ve had tyo do parameter=\n{{nop}} to get it to render correctly [00:42:21] Sometimes the whitespace handling miniutiae gets confusing [00:42:38] Very confusing. [00:42:44] It would be nice to have ONE universal line-feed marker [00:43:13] or a way to mark, no this isn't a new item, squash it to the previous line [00:43:20] , span, p or block [00:43:46] This is why HTML has explicit
and closing tags ;) [00:44:02] generally it ignore white space other than in PRE [00:44:12] Mediawiki on the other hand... [00:44:24] Depending on context see whitespace as: [00:44:38] Okay start a new paragraph [00:44:53] merge thsi line into the previous one [00:45:22] Intterupt the current item and start a new P [00:45:43] It's NEVER been clear precisely where each situation applies [00:45:51] Especially when coding templates.. [01:07:36] Linter doesn't understand parser function code it seems - https://en.wikisource.org/w/index.php?title=Template:Statute/Header/Chapter&action=edit&lintid=777438 [01:27:11] https://en.wikisource.org/w/index.php?title=Template:Statute/Header/Chapter&action=info shows no lint errors on that page? [01:50:53] legoktm: Only because I added a default [01:51:00] The one here is more subtlehttps://en.wikisource.org/wiki/Page:Asoka_-_the_Buddhist_Emperor_of_India.djvu/183 [01:51:24] The missing end occurs because the parser is doing some wrapping... [01:51:49] I.e it may be seeing the
\n sequence differently [09:53:52] Morning [09:54:01] Another ongoing puzzle with Linter- https://en.wikisource.org/w/index.php?title=Page:1888_Cicero%27s_Tusculan_Disputations.djvu/207&action=edit [09:54:13] This was flagged as having a missing end DIV [09:54:32] The page itself doesn't use any which would be unbalanced [09:54:54] other than the line-feed structure matching the book, rather than being collapsed into blocks [09:55:13] this is not an error so I'd like a second view [09:59:22] And what seems to be happening is that a stray * charcter is being misread. :) [10:00:25] Has thought about rasing another ticket [10:03:57] since yesterday I get a 502 Bad Gateway error clicking on the "Show location on an interactive map" Globe icon - is this a known issue ? [10:15:37] ... or is it only me? [11:15:45] Morning [11:16:34] hi [11:18:58] Is there a parameter to make images inline? [11:19:12] I.E not generate the surronding DIV ? [11:19:31] I've come up across another Linter concern [11:19:58] On English wikisource - take the following line of code :- [11:20:00] : RESULT: {{sinogram|description=⿰火乚|variantof=炸|comment=not in Unicode}} [11:20:29] into Special:ExpandTemplates and look at the RAW HTML output [11:20:45] It's malformed... as the DL is closed early [11:21:32] The generated span should be part of the DD item, but due to whitespace handling/wrapping something is getting confused ;) [11:22:03] Not sure how to easily repair this... [11:22:29] Considering a Phabriactor ticket [11:22:37] When I can explain what's going on [15:57:01] Hi [15:57:10] hI [15:57:31] can you in wiki markup do <{{{wrapper|P}}}> to generate tags on the fly? [15:58:12] If you can I don't think it's a good idea. [16:01:02] that sounds highly dodgy [16:01:48] I personally don't understand why

tags are being inserted into anything via a template [16:03:56] Typically it's to apply highly specifc formatting [16:04:02] Like chaning a margin [16:04:13] *changing a margin or alignment [16:04:33] for a specfic paragraph [16:05:10] oh i see [16:05:15] fair enough [16:07:27] Anyone have an idea how to get Phab to stop with changing U2 to a project? https://phabricator.wikimedia.org/T185582 [16:38:56] Sigh [16:39:24] It would of course as I have said repeatedly in the past be useful to know EXACTLY where Linter didin't like smething [16:39:40] https://en.wikisource.org/w/index.php?title=Page:Ruffhead_-_The_Statutes_at_Large_-_vol_9.djvu/642&action=edit&lintid=783699 [16:39:56] Rather than a somewhat cryptic "Not from one template" [16:46:33] Expanding out the relevant markup DIRECTILY from the page in Special:ExpandTemplates [16:46:41] Didn't show an obvious erors [17:39:06] Anyone here like minimal test cases? [17:39:24] I'm still trying to figure out why a complex template is showing up as generating an error [17:39:32] https://en.wikisource.org/w/index.php?title=Page:Ruffhead_-_The_Statutes_at_Large_-_vol_9.djvu/642&action=edit&lintid=783701 [17:39:42] being the current version of a page calling it [17:40:44] I cannot see WHERE the claimed missing

tag is given that the relevant code in the template should be generating balanced code [17:52:50] However I have a guess [17:53:07] Is there an experienced template coder here that can check a single line for me? [21:10:25] https://en.wikisource.org/w/index.php?title=Page:An_Answer_to_the_Declaration_of_the_American_Congress.djvu/10&action=edit&lintid=768566 [21:10:57] Once again the misnestings seems to be do with white-spabe handling [21:11:00] *pace [21:11:10] *space [21:11:28] Is to much to ask for ONE consistent approach? [21:12:16] It would be nice to know WHEN you add in a carridge return between templates and when you don;t [21:12:42] Having to play hunt the minutiae one EVERY single intended edit is unreasonable [21:12:46] *on [21:12:57] Fix the documentation, or fix the code... [21:13:30] But sending potential contributors on a "hack it it until works" is unhelpful [21:14:24] Especially on a project like Wikisource where the aim is to try and get stuff matching consistently across many,many pages [21:16:06] On many pages I've attempted to repair today, I've had to eventually to do it line by line savuing in between edits trying to find out what the problem was [21:16:26] This is a waste of bandwidth [21:16:55] Perhaps as I have repeatedly asked, someone can explain what's going on with whitespace? [21:17:15] Document what it's supposed to be doing, and conform the code to ONE approach [21:17:56] Perhaps then I can contribute actual content instead of running around chasing esoteric errors [21:18:28] caused because in the past, the previous parser let you do things that shouldn't have been possible [21:18:44] Sorry for the rant... [21:19:07] But this has been going on for a few days, and no-one it seems cares to actually explain WHERE the problems arise [21:19:17] in respect of this whitespace glitching [21:19:43] If Mediawiki was sensible it would use EXPLICT break markers [21:19:47] like HTML does [21:19:56] mhm [21:20:23] But No... it relies on users knowing the esoterics of where and where not to put in whitespace [21:20:36] and exactly how the parser is mangling it [21:20:47] and template code written in good faith [21:21:24] and of course there is no garuntee that having made a page stable someone else isn'ty going to squash everything up [21:21:41] inadvertently breaking it [21:22:03] because there's NO indication as to why something needs to be on a new line [21:22:42] The interaction of behaviours on Wikisource adds another complexity to this [21:23:36] where owing to the way page headers and footer are treated in the User Interface, what you think might be an implied line-feed isn't [21:23:44] depending on context [21:24:25] I have contributed many works to Wikisource... [21:24:38] (and although not all of them can be 100% free from iffy code) [21:25:11] I am angry that I am now having to in some cases re-do entire pages because of the parser migration rendering old approaches unviable [21:25:38] This is NOT reasonable [21:26:05] Especially when the original content was formatted in good faith based on the situation prevaling at the time [21:27:07] At the very least SHOWING where a paragraph pair might be wrapped IN the editing interface [21:27:09] might help [21:27:28] Or abandoning the idea of using text markup altogether [21:28:27] and isolating directly coded HTML to the Template or Module namespaces... [21:29:14] Arguably template markup is also one of the increasingly badly designed things in mediawiki [21:29:26] especially for complex templates... [21:30:34] However when I ask about these things, I get the general view that no one cares. [21:30:36] :( [21:30:53] Okay rant over