User talk:AuFCL

Tables (again)

User:ShakespeareFan00/Sandbox/Short-titles is a pared down example to the simplest I could think of quickly.

Even though I am on the page telling the {{aligned table}} not to do the header or footer generation when transcluding, something's generating an additional table end marker, and thus the |} which I added to EXPLICITLY balance up the EXPLICITLY given opening {| at the start of the table, is being treated as text not markup. I was using this approach because of the multi-page nature of the table concerned, with a view to replacing a rather complex template I was using on a previous attempt elsewhere. I've also checked to see if some of my other templates were 'mismatching' tags (namely {{numbered/s}},{{numbered/e}},{{numbered div/s}},{{numbered div/e}}.. ) and couldn't find a mismatch.

Before I go around in circles getting more and more frustrated, I'd like someone else to take a look at this, and provide a solution to the issue of multi-page tables once and for all, with a "satisfactory" solution that will be consistent, in all uses, irrespective of the underlying quirks of Mediawiki and extensions. (I'm getting the distinct impression that Mediawiki's table markup was not written with LST in mind.) ShakespeareFan00 (talk) 11:14, 15 August 2016 (UTC)

@ShakespeareFan00: O.K. This is going to be harsh so brace yourself.

LST always encloses the section "ripped out" inside <div>…</div> (the code is buried deep within the PHP portion of ProofreadPage) and there is nothing as a user or even administrator you can do about it except live with the consequences. One of those consequences is that if the parser "sees" an unclosed table it will close it on your behalf. Only thereafter does it encounter your |} and of course by that stage it is too late…

In practice {{aligned table}} is such an outlier on the wikisource scene (as discussed elsewhere it is truly a product of the single-page-only wikipedia ethos and usage) I hesitate to mention it at all in any kind of policy or help page, so coming up with multipage rules of use is not going to be a rewarding exercise.

A side observation along the way: May I suggest adding {{ts|bc}} to the sequence on Page:Short Titles Act 1896(ukpga 18960014 en).pdf/2:

{{center|{{larger|FIRST SCHEDULE.}}}}
{|
{{aligned table

—making it:

{{center|{{larger|FIRST SCHEDULE.}}}}
{|{{ts|bc}}
{{aligned table

—so that the table "rules" may coalesce into unbroken lines again? AuFCL (talk) 21:41, 15 August 2016 (UTC)

1. So that would also explain why on other multi-page tables I've had to use {{page}} vs <pages> possibly. It's a shame there isn't a way to tell the parser to not wrap. (which would makes things so much easier.) ;( Why it works in a particualr instance where technically it shouldn't ((see the other Short Titles Act transclusion in mainspace is beyond me.

2. That sounded very like a "you can't use this template for THAT" argument, which is understandable, but it's a shame no-one including developers seems to care about this. :(

3. Noted and a fix applied.

ShakespeareFan00 (talk) 21:51, 15 August 2016 (UTC)

I'm not sure I understand your point 1. above.

As for 2. I am not trying to suggest you do not use anything you can get to work satisfactorily, as that proof is in the pudding. What I am saying is that some things are harder to justify when they subsequently break, and expecting a "developed-for-another-purpose-in-another-environment" solution like aligned table to remain forever stable here is a bit like presenting your delicate anatomy to the mad person wielding a hammer and daring them to do their very worst? AuFCL (talk) 22:03, 15 August 2016 (UTC)

On 2. Quite. , On 1 I suggest reading what I said there, and looking over the recent edits related to the Index concerned. I think at present I am going to be unilateral and insert a note on the relevant Help page saying Mediawiki can't do multi-page

tables very well at present, at least then it will be explicitly clear that any solution is "experimental" shall we say. ShakespeareFan00 (talk) 22:09, 15 August 2016 (UTC)

I think I misread your intent on point 1. Perhaps what I should have asked was: Have you come across any cases which cannot be explained by the phantom-<div> insertion and consequent compromises argument? If so please point out the examples and I'll have a look—though as ever not confident a satisfactory outcome always possible. AuFCL (talk) 22:17, 15 August 2016 (UTC)

Thank you. That's probably the wording I should have used at the Scriptorum/Help thread.

I've also commented here - Help_talk:Page_breaks, in that we both know it's "semi-broken" but the help doesn't mention it.

ShakespeareFan00 (talk) 22:20, 15 August 2016 (UTC)

And further to this disscussion : Short_Titles_Act_1896/First_Schedule/Pre_Union shouldn't work, I'm not sure why it does.

On the subsequent sections ( It had to split because the number of template calls hit the limit in Mediawiki internally), such as Short_Titles_Act_1896/First_Schedule/6_Ann I've so far had to use a different approach (a rather brute-forced method) to get it to display consistently at all. It works, but barely. ShakespeareFan00 (talk) 22:24, 15 August 2016 (UTC)

Regarding First_Schedule/Pre_Union the best explanation I can come up with is "you can't be unlucky all the time!" The failure case arises when the page-end marker (automatically inserted, so you may not even be aware of it) happens to fall between table rows. In this particular instance it happens to lie just inside the final table cell on the page and thus works correctly. The only way I know to influence the positioning of this is to insert the Billinghurst-disputed {{nop}} at the end of page contents (certainly not present in this example.) I apologise this is but a poor explanation. AuFCL (talk) 22:45, 15 August 2016 (UTC)

Also there's a different issue here: Chronological Table and Index of the Statutes/Chronological Table/Edw1 namely some unexpected white-space at the lead. Someone else needs to throw the underlying templates in the bin and start the entire work again, manually entering each line of the table in full, as it seems that's going to be the only way of being really sure it will format properly, because having spent countless hours and days playing hunt "the whitespace in a template or transclusion, which the parser decides should be treated in three completely different ways depending on where its buried in a complex set of nested transclusions", I've had enough of trying to work around 'quirks'.

The entire {{Statute table}} template family is in my view unrepairable, to some extent un-maintanable and should be replaced with something a LOT cleaner (a LUA module perhaps) which is designed from the outset to take into account the 'quirks' which have been encountered during it's creation.

The same can probably be said for {{cl-act-paragraph}} and related which as it has been expanded has also become un-maintainable. I especially asked for {{short-title}} to be converted to LUA because it had get sufficiently complex I couldn't read it any-more, even though I had initially written it and some short-cut versions (sigh).

I appreciate that no-one gets paid for Wikisource efforts. Perhaps if they were things would get fixed.

ShakespeareFan00 (talk) 22:55, 15 August 2016 (UTC)

The Abominations

Much appreciated if you could use a suitable invocation regarding these.

• {{statute table/header}}
• {{statute table}}
• {{statute table/footer}}
• {{statute table/titles/entry}}
• {{statute table/titles/header}}

• {{Sn-paragraph}}
• {{cl-act-paragraph}}
• {{tf}}

As such they've become un-maintainable by normal users like me. Despite me having written them! These aren't the only ones, but they are the ones I could remember quickly. ShakespeareFan00 (talk) 23:06, 15 August 2016 (UTC)

And more hellspawn ....

• {{Statute table/chapter}}
• {{Statute table/year}}
• {{UKroadsign}}
• {{UKroadsign/cy}}
• {{Sn-note}}

ShakespeareFan00 (talk) 23:15, 15 August 2016 (UTC)

@ShakespeareFan00: Wow! If you are wondering why I haven't responded you have completely swamped me! I can only pick away at the side-issues and hope some useful conclusion presents itself.

To concentrate for the moment on your earlier issue: Chronological Table and Index of the Statutes/Chronological Table/Edw1; I can see what you want to achieve but I fear you might be being rather more ambitious than mediawiki will assist you in attaining.At a fundamental level I think you are up against the triple syntactic meanings of "|" as you have used it:

1. as wiki-table, row and cell delimiters;
2. as template parameter delimiters; and
3. as parser function delimiters.

To reduce the opportunity for confusion (and I am not at all sure this will solve your problems; though it can only help!) I would recommend converting all table constructs into <table>, >tr> and <td> equivalent form. This should free up the various {{!}} usage to further reduce the opportunity for confusion. It is even possible (though admittedly unlikely) that this might enable you to relax the current {{#section: usage and once more permit <page … onlysection=…> use—that is if that introduced <div> doesn't re-scupper the vessel!

Believe it or not this whole exercise is simply to address the extra <p><br></p> at the top of the page. I hope the outcome might make it worth the effort, though.

And before I forget: in {{Statute table/header}} the CSS on this construct does nothing (past the essential opening of a new table row) in most browsers:

|-style="vertical-align:middle; padding-top:0.50em; padding-bottom:0.50em;"

—the vertical-align is the default anyway, and (as far as I am aware) rows ignore any kind of padding directives completely. AuFCL (talk) 04:58, 16 August 2016 (UTC)

If you check the history of {{statute table/titles/entry}} I HAD tried converting it (and the pages using it over to using HTML markup, at which point the long standing issue with the non-appearance of page numbers in transclusion re-asserted itself. As I said, someone else, who has the time needs to re-do the entire work with a set of templates that have been written to take account of the quirks, rather than both of us trying to fix a template which is broken by them.

For reference :-

• https://en.wikisource.org/w/index.php?title=Template:Statute_table/titles/entry&oldid=6389889
• https://en.wikisource.org/w/index.php?title=Template:Statute_table/titles/header&oldid=6389888
• https://en.wikisource.org/w/index.php?title=Short_Titles_Act_1896/First_Schedule/6_Ann&oldid=6389887
• https://en.wikisource.org/w/index.php?title=Short_Titles_Act_1896/First_Schedule/Geo1&oldid=6390036

where I had tried to use the approach you had suggested. I at present don't consider any solution would be entirely satisfactory until the underlying low level issue inside the parser is sorted out once and for all. ShakespeareFan00 (talk) 09:03, 16 August 2016 (UTC)

Attempted here - Displays start of tables page number, but ONLY that one. (using {{page}}

https://en.wikisource.org/w/index.php?title=Short_Titles_Act_1896/First_Schedule/6_Ann&oldid=6392328

Attempted here - using <pages /> https://en.wikisource.org/w/index.php?title=Short_Titles_Act_1896/First_Schedule/6_Ann&oldid=6392341 - The page numbers will display (and link), but only if they are NOT displayed within the text, suggesting a lower level issue with how the page-numbers are inserted. As I've tried MANY approaches to resolve this, I am of the view that this is an issue outside the control of normal users. What a shame no-one else seems to care about fixing the real problem which based on the above would seem to be buried within the code for generating the page numberings to the side. This means that to get the page numbers consistently with a table crossing a page boundary, you can't use HTML markup, or LST via <pages> at present. What a shame mediawiki is weak in this area. :( ShakespeareFan00 (talk) 09:25, 16 August 2016 (UTC)

@ShakespeareFan00: Regarding Short_Titles_Act_1896/First_Schedule/6_Ann, I shall not claim this is not an act of utter bastardy but try:

{{header
 | title      = [[../../]]
 | author     = 
 | translator = 
 | section    = First Schedule, 6 Ann. - 13 Ann.
 | previous   = [[../Pre Union]]
 | next       = [[../Geo1]]
 | notes      = 
}}
<span><span class="pagenum" id="16" title="Page:Public General Statutes 1896.djvu/36"></span></span>
{{statute table/titles/header}}
{{page:Public General Statutes 1896.djvu/36}}
<tr><td style="position:absolute;"><span><span class="pagenum" id="17" title="Page:Public General Statutes 1896.djvu/37"></span></span></td></tr>
{{page:Public General Statutes 1896.djvu/37}}
<tr><td style="position:absolute;"><span><span class="pagenum" id="18" title="Page:Public General Statutes 1896.djvu/38"></span></span></td></tr>
{{Page:Public General Statutes 1896.djvu/38}}
</table>

To explain: by direct transcluding all three pages I sidestep any <pages>-<div> insertion issues but (obviously at the cost of no page number information. That was step 1.

Step 2 is the <span><span class="pagenum" &c. guff. That force-inserts the page numbers in a form acceptable to mediawiki:PageNumbers.js. So far so good, and works for page 16.

Step 3 is to further enclose the page-meta-info inside <tr><td> to make them compatible with the ongoing {{statute table/titles/header}} structure. PageNumber likes this but there are now 1px "holes" in the vertical rules due to a table element we don't want to see.

Step 4 is to make the dummy <td>s style position:absolute which effectively hides them. Can't use display:none as inheritance hides the page number displays and defeats the effort.

So here is an abomination-squared which works. I have no idea how to justify it though! Call it research in progress? AuFCL (talk) 08:53, 17 August 2016 (UTC)

Be careful, abominations have a habit of doing nasty things on invocation! ;) . I may revert my efforts given that the version using normal table syntax and {{page}} sort of worked. But at present I am not exactly a practioner of the dark arts of mediawiki. ShakespeareFan00 (talk) 08:59, 17 August 2016 (UTC)

Well just to tempt you further toward the dark side, it would be fairly easy to split off a derivative template of {{page}} which (tentatively) incorporated the enhanced structure. I have not (yet) tested it but by reverse logic I expect it would work for ordinary pages (and damn it all tables are extended backward in a parse to enclose the first row reference. Bloody parser! There goes the neat works-everywhere solution!) as well as those containing tables… and could well have the side-effect of eliminating any requirement for {{nop}} outside of its traditional to-protect-new-lines function… Sort of introduce it by stealth and hold off explaining until somebody actually asks intelligent questions…? Could take years! Got-your-soul-stuff? AuFCL (talk) 10:00, 17 August 2016 (UTC)

I would strongly suggested a lead pentagram lined sandbox to trial it first! Such are the ways a Wikisourcerer ? ShakespeareFan00 (talk) 13:09, 17 August 2016 (UTC)

Well as I said using normal table syntax and {{page}} albiet with num- params all over the place sort of worked, not sure why though. ShakespeareFan00 (talk) 13:10, 17 August 2016 (UTC)

Your last remark cannot be referring to the current state, as that is achieved through use of <pages>—no explicit num parameters at all.

In any case both the above and this edit (even allowing for the typo!) work both better and worse than you imagine: all three page (er. two—three after said typo is addressed) number links are technically present although a bit of protective code in PageNumbers.js hides pages 17 and 18 due to an inability to decode the vertical area occupied by page 16 (hover your mouse pointer over the page-number-link to see what I am talking about—only a single line is highlighted; whereas the grey area ought to extend down to "7 Anne, c. 12."—as it does with my dirty hack in place.)

In any case this is all a learning exercise and if you are happy with the status quo I shall not further rock this boat. AuFCL (talk) 22:16, 17 August 2016 (UTC)

Well if that's still a gltich that you managed to solve, invoke away until you have tamed the abomination. You are a better contributor than I. {{table-x}} ? ShakespeareFan00 (talk) 22:29, 17 August 2016 (UTC)

I'm at the moment going to walk away from this. If you solve it for good let me know. ShakespeareFan00 (talk) 22:30, 17 August 2016 (UTC)

@ShakespeareFan00:Well what do you think of this? Will it fly? Any obvious (or otherwise) simplifications? It is a shame one needs to be conscious of whether the page is to be included as being of table-nature {{table-page}} or normal {{page}}; and of course from/to ranges are impractical but nevertheless.

Even my inadvertent lapse is illustrative. Note the hover-highlighting of page 16 is different in the two versions: using {{page}} back-extends the highlight region to the start of the end-result-page; whereas use of {{table-page}} (where practicable to so use) supports highlight of the actual transcluded content, excluding the direct-specified table header contribution from (in this case) {{statute table/titles/header}}. AuFCL (talk) 00:01, 18 August 2016 (UTC)

Looking longer-term the changes to make <pages> accept a new parameter context="table" which if present suppressed the <div> wrapping and inserted page back-links per above proposal are pretty straightforward—the major difficulty not being technical in nature; but rather requiring I would need at the very least Tpt on board to get it through the implementation process.

And as for intelligent detection of—and reaction to—content: forget it; one would still have to <page>-include tabular and textual content in distinct blocks.

In other words: dream on. Are you any good at pulling strings? AuFCL (talk) 00:25, 18 August 2016 (UTC)

Looks good so far. Have you tested it with sections yet? I used these extensively later on? ShakespeareFan00 (talk) 07:40, 18 August 2016 (UTC)

No I have not—though written everything so as sections should not be an issue. I wanted a little feedback before going too far per spin-off at WS:S#Making_.3Cpages.3E_more_flexible.3F I suspect most feedback will be along the lines of "Why would anybody want to do that?" so please be warned.

Please try the new template out and let me know if it causes grief. It is a fairly simple clone of what I envisage {{page}} ought to be—arrogant or what?—but as it is protected from editing I cannot do anything about it. AuFCL (talk) 08:27, 18 August 2016 (UTC)

Side issue in {{page}} {{table-page}}

From my limited understanding at present {{page}} and {{page}} can only pull out a single section. They can't necessarily pull multiple sections. Is my understanding correct? Just means more lines in the transclusion page but would probably need to be documented. ( Not sure without converting to LUA code you would implement a {{page}} with fromsection= and tosection=) Not a concern with pages I've written, but in some future instances it may become so. I've noted your discussion elsewhere. ShakespeareFan00 (talk) 09:49, 18 August 2016 (UTC)

You are quite correct about single-sections-at-a-time for now. I have deliberately linked {{table-page}}'s documentation to the documentation for {{page}} for now; mainly because it is a poor long-term solution which merely demonstrates a possibility—and thus there is no point in overly encouraging its use except in case of dire necessity.

I also quite deliberately over-specified the proposed upgrade to <pages> at Scriptorium as that is the superior solution (and handles multiple-ranges and multiple section inclusion to boot.) A sensible tame administrator could do a lot if suitably educated and motivated—and if the go-ahead is granted.

You should be warned that really {{table-page}} is only really required for instances where a "slice" of a table is to be extracted for transclusion. If (for instance) a complete table including header-body-and-footer is selected by a section then you might as well use <pages> as normal current practice anyway. (Aside: you may remember <pages> explicitly will not work inside the Index: name space, so if you are building a contents page for use there you are stuck with {{page}} anyway.) AuFCL (talk) 11:25, 18 August 2016 (UTC)

The Tablecrux (as I understand it)

At present :

{|
|-
|1||2
<!-- page split --->
|-
|3||4
....
|}

Will in my experience actually transclude from the parsers perspective depending on the circumstances as

{|
|-
|1||2|-
|3||4
..
|}

An "implied" line feed being ignored. Which means the table row end/start gets ignored. Naturally when using HTML table synatx directly this parser quirk doesn't occur because the browser at best will see a </tr><tr> pair in a non-pretty way.

The {{nop}} immediately before the |- at the start of page with the rest of a table is seemingly needed so that the parser thinks it's seeing the start of a new line, (as opposed to the continuation of a line or the end of a table entry/row from a previous page.

This is why the {{nop}} is overloaded. A hack solution would be to amend the Proofread page extension to make an explicit check for a |- sequence at the immediate start of a page/section once the header noinclude has been stripped. Idealy a check could also be made for a trailing |- sequence just before a footer noinclude, It's not ideal because of some other use cases that may arise.

As you are already looking into implementing a page number fix and some other options, it would be a recomendation that you also come up with some kind of invocation that shall free the {{nop}} from unclean usage, that will banish the Tablecrux and bar it from returning in the future! Do this and great Sourcer of the wiki shall ye be!last part is tounge in check, but as we were in that theme. ShakespeareFan00 (talk) 13:31, 18 August 2016 (UTC)

Side note, when trying to get cl-act-pragraph working I had the reverse issue, in that some transclusion methods and template parsing was adding or removing "implied" line/paragraph breaks due to quirks. ShakespeareFan00 (talk) 13:31, 18 August 2016 (UTC)

┌──────┘
Please pardon me if I am over-simplifying. Your example as stated:

{|
|-
|1||2
<!-- page split --->
|-
|3||4
....
|}

simply works under transclusion of both {{page}} and <pages> ilk. The reason why is that all of the table header, body and footer are present in the final result. Also because the page split fortuitously occurs at the end of a table cell the automatic process of inserting page number information enclosed within a <span> happens to be compatible. In this case page number links probably work.

Now please consider this subtle change:

{|
|-
|1||2
|-
<!-- page split --->
|3||4
....
|}

Looks very similar, transclusion works but page number links do not. Why?

Well where does the page-info-span go? Yes it is now nestled in after the table row start mark that |- becomes. In other words the HTML generated looks like:

...
<td>2</td>
</tr>
<span>..page split..</span>
<tr>
<td>3</td>
...

and that just is not legal in HTML. The parser is still processing when it hits this and (guess what?) the span and all its content are either expunged or moved outside of the table altogether.

In point of detail it matters not which fate it incurs as the whole point of this span is to mark where it is in the HTML stream. PageNumbers.js then uses this location to generate the actual page links which means it cannot be moved or removed. Either choice results in a train-wreck.

My "solution" as implemented in {{table-page}} is to further enclose the span:

...
<td>2</td>
</tr>
<tr style="position:absolute;"><td><span>..page split..</span></td></tr>
<tr>
<td>3</td>
...

which I won't pretend is not ugly! However it is a kind of parser-viral matter which is sufficiently innocuous to the process that it is left in place without visual effect. PageNumbers.js finds its magic span and is happy so page numbers work again.

Now the situation as it occurs in, say, Chronological Table and Index of the Statutes/Chronological Table/Edw1 is yet one more step removed beyond the above. What you really want to do is to generate almost an SQL-like extraction of multiple named sections from multiple pages. As you know <pages> can do this for you. The problem now is that the output of <pages> becomes effectively:

<div>
|1||2
<!-- page split --->
|-
|3||4
....
</div>

no headers! But you solved that in main space by adding an enclosing {{statute table/header}} and {{statute table/footer}}. Well didn't you? The result being logically:

{|
<div>
|1||2
<!-- page split --->
|-
|3||4
....
</div>
|}

But wait! The <div> is now inside table headers and that is not allowed. So the parser removes them and the result sort-of works again with all the issues of page-break placement discussed above.

In other words every level of complication adds to the problems wrapped up in layers below. Sometimes you are lucky. Sometimes not. The whole situation is an exercise in gambling and nobody fully knows the rules of the game.

I am no sorcerer, just a ticked-off apprentice with a magical broom and (so far) no authoritative oversight. Lets just see how far this ride takes me? AuFCL (talk) 21:56, 18 August 2016 (UTC)

Hmm, so this to me still doesn't really explain why the

{{nop}}

is needed, when technicalyl it shouldn't, based on the above explanation. hmm.

And with the short titles I was getting precisely the situation I was seeing in my first example namely a

|-

in the wrong place, meaning 2 table rows were getting pushed together. :(. Willing to write some insanely arcane test cases to prove the exact interaction between table syntax and LST? If not no worries. ShakespeareFan00 (talk) 23:44, 18 August 2016 (UTC)

(Sigh! This is aimed at myself, not you!) At the risk of confusing you further, about an hour after I put the above together I realised I had reversed reality. Nothing wrong with the concepts but I had analysed the examples as if the page-number-marker block trailed after the page content, when in fact it leads the content. This still means there is a 50:50 chance of things going wrong; just in precisely the opposite order. So please let me try again, and I will attempt to address some of your other questions along the way:

Lets imagine you want to transclude table content using <pages> to be sandwiched within user-specified table open and closure bookends:

<!-- manually created table header -->
{|
<!-- table body transcluded via <pages/> - first part -->
|1||2
|-
<!-- page split: table body transcluded via {{page}} or <pages/> - second part --->
|3||4
....
<!-- end of <pages/> transclusion -->
<!-- manually created table footer -->
|}

—this in reality is theoretically a failure case. At an intermediate stage the parser is looking at:

{|
<div>
<span>{{:MediaWiki:Proofreadpage_pagenum_template|page=(Page:link)|num=(pagenum)}}</span>
|1||2
|-
<span>{{:MediaWiki:Proofreadpage_pagenum_template|page=(Page:link)|num=(pagenum)}}</span>
|-
|3||4
....
</div>
|}

—which is not legal HTML (the <div> should not be there. neither are the spans syntactically permitted.) Fortunately the parser happens to throw the div away—which is good. However not so good, it moves (current parser quirk: please don't rely on this behaviour!) the spans treewise up to the previous outer table or div. This is bad because all the inter-table pages then appear to lie on top of one another at the start of the table. PageNumbers.js then compounds the error by hiding all the overlaid pages past the first one. So the net result is a correct table display with but a single usable page number link to the first page (worse yet: if the user-specified table header is of non-zero length, the page is interpreted as including the header which precedes the transclusion proper. This is the effect I was trying to demonstrate earlier with the difference between the hover effects on page 16 in special:permalink/6395312 and special:permalink/6392328. AuFCL (talk) 05:00, 19 August 2016 (UTC)

Another fix that works

The fix being this: https://en.wikisource.org/w/index.php?title=Template:Statute_table/year&oldid=6398603

But I am not sure why even with your previous explanations, that the two nops should be needed here. It seems that someone should generates some diabolically pervese and pathalogical test cases because I think this is a quirk in the parser that should be fixed. You should NOT need to have to put in {{nop}} 's when using normal table syntax. ShakespeareFan00 (talk) 12:01, 20 August 2016 (UTC)

I really don't understand what you are doing here. Can you possibly supply an example which fails without the {{nop}}s because they do not appear necessary at all in any of the cases I have examined to date using {{Statute_table/year}}. I can only assume you introduced them (and all the {{!}} usage) as a result of an undesirable interaction with another template—otherwise you are simply introducing complication for complication's sake and might well be battling phantoms of your own creation? AuFCL (talk) 22:01, 20 August 2016 (UTC)

What i was having problems with was unexpected white space on Page:Chronological Table and Index of the Statutes.djvu/33, with the nops the unexpected whitespace went away, if you think they aren't need you are welcome to remove them and test, but as I said, I'd like to hand over this set of efforts to someone to do the full assembly of it.

ShakespeareFan00 (talk) 15:02, 21 August 2016 (UTC)

A thought

Part of the complexity with {{statute table}} arises because of handling table rowspans. It would be nice if the parser could cope with these in a cleaner way.

Would implementing an extension to table syntax as such be useful?

• |~ Extension and merge of next cell horizontally to this column of the table. (effective colspan), The parser seeing this would do generate the rowspan part internally.
• |^ Extension and merge of next cell verticaly to this cell (effective rowspan)

A very much simplified example would be.

1	2
3	4	5
	6	7

Currently you need to do:-

{|{{ts|bc}}
|{{ts|ba}}|1
|colspan=2 {{ts|ba|ac}}|2
|-
|rowspan=2 {{ts|ba}}|3
|{{ts|ba}}|4
|{{ts|ba}}|5
|-
|{{ts|ba}}|6
|{{ts|ba}}|7
|-
|}

With the syntax extensions you would have instead...

{|{{ts|bc}}
|{{ts|ba}}|1
|~
|{{ts|ba|ac}}|2
|-
|^
|{{ts|ba}}|4
|{{ts|ba}}|5
|-
|{{ts|ba}}|3
|{{ts|ba}}|6
|{{ts|ba}}|7
|-
|}

Which means that each 'cell' is nominally defined ( which would make some templates less complex.), This is a long-term idea, I'm not expecting anything to happen soon. ShakespeareFan00 (talk) 12:50, 20 August 2016 (UTC)

I expect I am the wrong audience for this. I am a little concerned already about the ambiguities of |- and your proposed syntax might face similar problems. How would you recreate, for example:

1		2
3	4
	5

reproduced more for being "pretty" than for a challenge. Which is maybe why I feel this sort of syntactic change might be resisted in the current push for a visual editing approach. AuFCL (talk) 21:55, 20 August 2016 (UTC)

What would you suggest was a "cleaner" syntax? ShakespeareFan00 (talk) 00:00, 21 August 2016 (UTC)

{|
|~
|1
|^
|-
|^
|4
|2
|-
|3
|~
|5
|}

BTW. That said I'm not sure they way the parser constructs tables would allow for the <noiwki>|^</nowiki> anyway.

ShakespeareFan00 (talk) 00:00, 21 August 2016 (UTC)

Your notation makes no apparent allowance for spans more than two—unless you envisage multiple modifiers to indicate higher span values? In the most general case one starts to come around to the current notation |(cell-attribute-list)|(cell-content) or indeed <td (cell-attribute-list)>(cell-content)</td> as prosaic no doubt that is. AuFCL (talk) 04:24, 21 August 2016 (UTC)

Re html5 and <tt>

Do I read correctly that with html5 that we should not be using <tt> and should instead use <kbd>? — billinghurst sDrewth 00:06, 18 August 2016 (UTC)

I admit I have never looked that closely into the matter but according to [1] your premise is basically correct in pure HTML5 terms. Don't forget mediawiki enforces a layer of intervention so the same may not necessarily be true at least for the immediate future in the wikisource environment (what I am trying to say is you need some feedback from the WMF developers as well. I do not know.) AuFCL (talk) 00:25, 18 August 2016 (UTC)

@Billinghurst: Upon further reflection, wouldn't the "wiki"-way be to use <code>? AuFCL (talk) 06:07, 18 August 2016 (UTC)

<shrug> I will interpret this as rather say and do nothing, and leave it in our editlist markup, we prod WMF for their guidance, and look to set ourselves front-facing. Thanks for your thoughts. — billinghurst sDrewth 07:18, 18 August 2016 (UTC)

Parser quirks..

Page:United Nations Treaties and international agreements registered - Volume 221 (13 November 1955 - 30 November 1955).pdf/380

Take an example :

1. Outside the template

Mr. James S. Killen
Counsellor for Economic Affairs
Embassy of the USA
Beograd

Mr. James S. Killen
Counsellor for Economic Affairs
Embassy of the USA
Beograd

Inside {{tf}}

Template:Tf

But when done slightly differently: Template:Tf

Consistent behaviour would be nice. :) ShakespeareFan00 (talk) 19:59, 20 August 2016 (UTC)

In the first example it generates a

block right in the middle, which breaks the intended layout XD.

I doubt this will get fixed any time soon (as changing what exactly equals terminating white-space would potentially break so many other bits of Mediawiki...)

ShakespeareFan00 (talk) 20:05, 20 August 2016 (UTC)

Welcome to the wonderful world of compromise mediawiki really is! I suspect all along what you really wanted to do was this:

<p style="margin-bottom:0;margin-top:0;">Mr. James S. Killen<br />
Counsellor for Economic Affairs<br />
Embassy of the USA<br />
Beograd</p>

which produces:

---

Mr. James S. Killen
Counsellor for Economic Affairs
Embassy of the USA
Beograd

---

HTML-like tags appearing in wikitext are not always passed through literally. Hard as it is to grasp <div> is one of these cases, and for best fidelity needs to appear on a line alone. My unqualified suspicion is that the parser needs to "see" a new line before properly closing off prior paragraphs—with the result at some stage it has to grapple with a div-inside-a-paragraph which is not permitted by the rules of HTML and what you are observing is the results of trying to recover from that basic mistake.

Incidentally don't think my approach above is bullet-proof either. Simply enclosing the whole thing in a table cell reintroduces the problem all over again.

My only suggestion is to try to keep things to the simplest case which works. Ironically with your example this is the first ("outside the template") case. In other words in this particular instance {{tf}} is doing noting useful. This is not a criticism of the template in other circumstances. AuFCL (talk) 21:41, 20 August 2016 (UTC)

Render quirks (Part 1)

Page:Cowie's Printer's pocket-book and manual.djvu/66

I'd been attempting to get a table which looked like the page on screen.

I've got the table; but setting up a transform so it displayed consistently, in both the Page: view and the edit preview, seemed to beyond Mediawiki to cope with. It rendered differently in both views.

ShakespeareFan00 (talk) 11:51, 21 August 2016 (UTC)

Once more I don't really understand. This version seemed pretty close so what went wrong? (If you were happy using {{rotate}} for the individual cells then why not use it again to get the overall orientation desired. I confess transform matrices make my head spin so I consider use of that was a bit "courageous." AuFCL (talk) 04:09, 22 August 2016 (UTC)

Tried that, Still couldn't get it to render. Parser quirks on how it reads table synatx. What a shame to do anything complicated, you have to write non-portable HTML code directly :( ShakespeareFan00 (talk) 10:21, 22 August 2016 (UTC)

A very very simple table , It won't rotate, because {{rotate}} appears to use a span, which per previous disscussion can't have a block level tag like a table within it.

{{rotate|90|
{{{!}}
{{!}}-{{ts|height:3em}}
{{!}}{{ts|ba|ac|vbm|width: 2em}}{{!}}{{rotate|180|2}}
{{!}}}
}}

2

What the parser gennerated as HTML was,

<p><span style="display:inline-block; -webkit-transform:rotate(90deg); -moz-transform:rotate(90deg); -o-transform:rotate(90deg); -ms-transform:rotate(90deg); transform:rotate(90deg);">
</p>
<table>

<tr style="height:3em;">
<td style="border:1px solid black;text-align:center;vertical-align:bottom;width: 2em;"><span style="display:inline-block; -webkit-transform:rotate(180deg); -moz-transform:rotate(180deg); -o-transform:rotate(180deg); -ms-transform:rotate(180deg); transform:rotate(180deg);">2</span>
</td></tr></table>
<p></span>
</p>

That's why I was using a hard coded div, which wouldn't display consistently. It would of course be "helpful" if mediawiki was at least consistent about it's handling of hard-coded div's, an issue which I'm going to add to the long list of "known concerns, nobody is interested in actually doing anything about because they don't care about actual contributors." ShakespeareFan00 (talk) 10:31, 22 August 2016 (UTC)

Because of another parser quirk - {{{!}} has to be on a new line, which causes the generation of a spurious (and unblanced <nowiki<>

</nowiki> pair (as seen above), that as you can see (again above) isn't nice HTML. In the above example the parser would seem to have a quirk no-one wants to fix <seethe>.

Presumably there must be a way to code the DIV wrapped around the table to be coded in such a way that it WILL format consistently (in all views), but at present owing to all the quirks of Mediawiki, it eludes me.

ShakespeareFan00 (talk) 10:39, 22 August 2016 (UTC)

And after a LOT of looking at documentation elsewhere - Page:Cowie's Printer's pocket-book and manual.djvu/66.

I'm still not entirely happy, for reasons to do with possible "registration"(printing term) issues if the table layout here is used as the direct basis for doing a print layout, but it's getting there. Any chance of being able to wrap the code there into some kind of script so I don't have to spend hours typing table code? ShakespeareFan00 (talk) 15:17, 22 August 2016 (UTC)

And when I akssed some Mozilla people they came up with :- [[2]], which worked better.

Gven it's complexity some kind of template or LUA implementation would be advisable in my view. ShakespeareFan00 (talk) 19:49, 22 August 2016 (UTC)

What I was suggesting before was {{rotate|ele=div}}; i.e.:

{{rotate|90|ele=div|
{{{!}}
{{!}}-{{ts|height:3em}}
{{!}}{{ts|ba|ac|vbm|width: 2em}}{{!}}{{rotate|180|2}}
{{!}}}
}}

2

There has been some discussion in the past about the unsuitableness of {{rotate}} due to it not being (if I recall correctly) compatible with Internet Explorer. As history has moved on since then… AuFCL (talk) 21:05, 22 August 2016 (UTC)

layout improvement

Hello AuFCL. Can you have a look at Page:Sir Martyn (1777).djvu/20 (picked somewhat at random) – how would you improve its layout/presentation? (If you can do it in one, I can then copy the same format and apply it to the rest.) A larger problem: notice the space between the stanzas? Why does it not appear in transclusion? Thanks in advance for your help. ~ DanielTom (talk) 23:06, 30 August 2016 (UTC)

Never mind, I think I got it. Just another minor question about (you guessed it) braces (again). How to make the one here work (Ctrl+F "Stownd")? Thanks ~ DanielTom (talk) 23:55, 30 August 2016 (UTC)

@DanielTom: Please pardon my tardy response. Yesterday instead of presenting "Sir Martyn", mediawiki was having a snit and giving me the "all our servers are kaput" error on that page so I left to today. I rearranged the brace problem as side-by-side floating divisions (effectively columns: I hope that is the effect you wanted?) The {{clear}} at the end simply indicates the end of the stacking operation, and the return to normal text flow. The whole thing could also have been organised as an embedded table if you prefer. AuFCL (talk) 22:32, 31 August 2016 (UTC)

No problem at all. Hmm, I had to zoom out to see if it works... And it does. Thanks for always being so helpful. ~ DanielTom (talk) 23:07, 31 August 2016 (UTC)

Something is wrong with image container.

Hi,

You knew that it was inevitable that I drop in on you. I am having a problem with the container of the picture ON THIS PAGE and can't figure out what it is. Could you please take a look at it whenever. There is no rush. Thanks. — Ineuw talk 06:48, 6 September 2016 (UTC)

Share your experience and feedback as a Wikimedian in this global survey

Hello! The Wikimedia Foundation is asking for your feedback in a survey. We want to know how well we are supporting your work on and off wiki, and how we can change or improve things in the future.^{[survey 1]} The opinions you share will directly affect the current and future work of the Wikimedia Foundation. You have been randomly selected to take this survey as we would like to hear from your Wikimedia community. To say thank you for your time, we are giving away 20 Wikimedia T-shirts to randomly selected people who take the survey.^{[survey 2]} The survey is available in various languages and will take between 20 and 40 minutes.

Take the survey now!

You can find more information about this project. This survey is hosted by a third-party service and governed by this privacy statement. Please visit our frequently asked questions page to find more information about this survey. If you need additional help, or if you wish to opt-out of future communications about this survey, send an email to surveys@wikimedia.org.

Thank you! --EGalvez (WMF) (talk) 22:25, 13 January 2017 (UTC)

1. This survey is primarily meant to get feedback on the Wikimedia Foundation's current work, not long-term strategy.
2. Legal stuff: No purchase necessary. Must be the age of majority to participate. Sponsored by the Wikimedia Foundation located at 149 New Montgomery, San Francisco, CA, USA, 94105. Ends January 31, 2017. Void where prohibited. Click here for contest rules.

Aligned table of Statutes (and how to support "ribbon" headers?)

The page: Page:A_Collection_of_Statutes_Relating_to_India_(Second_Edition)_Vol_1.djvu/17

The Template/Module concerned.: {{Aligned table}}

I was using aligned table for this as it's a static format that continues over a number of pages, and calling {{ts}} for every row, cell etc seems to be overkill. Possibly this is instance of it needing a specific CSS class applied to the relevant tables, but I am not that familiar with how to request new ones for use on English Wikisource.

However, I've I am reasonably confident that the English Wikisource version of the template could be udpated in a specfic way. Currently the template concerned is not necessarily page/LST aware, leading to the approach I have on the page linked, which I consider to be a temporary soloution even if it appears to work.

I was thinking given that you were able to implement |starting=yes |continuing=yes |ending=yes and |rowXpageribbon=yes functionality in {{TOCStyle}} whether you in a spare moment would be interested in producing a forked version of aligned table, which also had this functionality.

Being able to do a starting/continuing/ending/pageribbons aligned table more cleanly would be appreciated, as it would no longer need to worry about precisely where to put in certain arcane syntax.

I am suggesting the |rowXpageribbon=yes for things like the column headings row, in the example above which need to be on pages, but don't necessarily need to be in mainspace, as that's what you used in TOCstyle. ShakespeareFan00 (talk) 12:52, 28 February 2017 (UTC)

Template:Table-page

This has remained unused for a while, so I've started a disscussion at WS:PD.

The attempted usage of it didn't it seems work out. ShakespeareFan00 (talk) 18:46, 1 March 2017 (UTC)

Apologies, I had a "meltdown" on wiki :(ShakespeareFan00 (talk) 22:38, 1 March 2017 (UTC)