User talk:Inductiveload/Archives/2018

Please do not post any new comments on this page. This is a discussion archive first created in 2018, although the comments contained were likely posted before and after this date. See current discussion or the archives index.

A personal "next" project under consideration:

I was pleased to see your edit of one of my pages. I had the impression you had chosen to stay away. We have not communicated since I discovered 35 additional small works of Ferrier. Currently, I have begun preparatory measures as if to fully publish the 1876 Edition of The Imperial Dictionary of Universal Biography... in which those Ferrier pieces were found. I will not involve you if that's your preference. I would prefer to ask for your guidance.Klarm768 (talk) 17:16, 17 January 2018 (UTC)

Hi again :-) I've been annoyingly busy in real life (and I will sadly soon be so again). I'm just trolling around on WS for a bit and mixing looking around with my long term ongoing work (which gets a little dry sometimes). IDUB looks like a fairly major undertaking - you could ask on the Scriptorium if you'd like help with it, I'm afraid I can't commit to anything. The people who do things like the DNB or even EB1911 might be interested? Inductiveload—talk/contribs 17:27, 17 January 2018 (UTC)

I never learned to be a team player. You are surely aware that I was poorly instructed since my Ferrier pages do not "align to existing styles." I am accustomed to to learn that no one would care to join my ill-conceived vocations. For this project, I am considering assorted strategies. I prefer guidance from (a) knowledgeable individual(s). Nevertheless, I will implement a course of action. Eventually someone may inform me that my work does not "align to existing styles," and she will soft-redirect two of the then-already-published-four-thousand pages... making an ass of herself and her own criticism. Recent Scriptorium advice is a few light-years in arrears of my own efforts and not encouraging as a resource. Klarm768 (talk) 05:10, 18 January 2018 (UTC)

Djvu

I found into Commons a script by you about jpg to djvu conversion, that shows your interest about this file format; are you interested too about hidden text management? I'm working about a hOCR to dsed conversion script, that allows to mount tesseract output into djvu pages: am I rediscovering the wheel in your opinion? --Alex brollo (talk) 00:00, 21 January 2018 (UTC)

Hi Alex - I have never done anything with DjVu text layers, so you won't be reinventing any wheel of mine! Any time I needed OCR on a DjVu, I put it on archive.org and let them deal with it! Inductiveload—talk/contribs 00:03, 21 January 2018 (UTC)

As you perhaps know, IA doesn't builds any more djvu files for new uploads - but it shares _djvu.xml files, and this allows to build excellent djvu files with IA original OCR. Even in bad case that IA would discontinue _djvu.xml publishing, mapped OCR could be derived from _abbyy.gz files parsing. I'll try to start some talk about using the new talk channel, Discourse, just to test it. See you there if you too have time and interest about - it's IMHO a relevant issue, that deserves the work of true developers, much more skilled than me. --Alex brollo (talk) 22:02, 21 January 2018 (UTC)

Actually, I did hear about that, but I haven't needed a DjVu from them for quite some time. It is a shame they don't provide this.

Do you mean https://discourse-mediawiki.wmflabs.org ?

As a side-thought here, if making a DjVu from the IA's files is not too hard, there could be a Labs tool to produce DjVus for IA items that don't have them? Inductiveload—talk/contribs 22:38, 21 January 2018 (UTC)

Presently IA Upload is being updated by Sam Wilson, I'm in contact with him, there are some bugs to fix; mounting _djvu.xml into djvu derived from _jp2.zip images is a possible, but tricky task. Take a look to IA Upload queue, you'll find a number of "possibly failed" (really failed) uploads. --Alex brollo (talk) 11:18, 22 January 2018 (UTC)

Ah right of course, I was even going to look at the problem with IA Upload last year, but I failed signally to get it set up on my machine and then real life happened in various exciting ways! Inductiveload—talk/contribs 12:51, 22 January 2018 (UTC)

Nothing to do into Discourse channel - probably I did'y understand well Discourse scope :-(. See you into wikisource-l for a new try. --Alex brollo (talk) 15:34, 22 January 2018 (UTC)

Formatting templates...

Thanks...

Any chance you could examine a template like {{Uksi/paragraph}} or {{cl-act-paragraph}}'s logic at some point. I am starting to wonder if this family of templates should be handled by a module. ShakespeareFan00 (talk) 20:54, 21 January 2018 (UTC)

What exactly do you see to be the problem here? Please give me a specific example (i.e. a link). You say "whitespace related semantic issues" or whatever, but you haven't actually pointed to the problem. For example, I see no linter errors on The Traffic Signs (Welsh and English Language Provisions) Regulations and General Directions 1985 except an obsolete CENTER tag.

And that CENTER tag error came from {{OGL3}} which I've fixed.

Also I don't think spamming the mainspace with hundreds of angry red warnings about the issue is really constructive - perhaps start a maintenance page somewhere to list pages and templates with these issues. "What links here" is enough to find uses of questionable templates then. Normal users don't care abut the parser (not that the message even really says what the problem is), and that's who is affected by that kind of thing. Inductiveload—talk/contribs 21:19, 21 January 2018 (UTC)

Doubly so when the warning itself contains an unbalanced SPAN tag....

It's also rather hard to work out what is going on where this isn't even documentation on the template pages about what they are even trying to achieve, let alone comments or something in-line to explain the template. Doubly so when there are sub-templates that include the parent templates. And what does "Cl-" mean? Clause? Common law? Cinnamon loaf? Inductiveload—talk/contribs 22:15, 21 January 2018 (UTC)

The lack of documentation is something that I will need to look into, and about the unbalanced spans, I've commented out the entire warning messages now. It should only categorise.. I will be taking another look at some of the affected templates, when I am less likely to explode. ShakespeareFan00 (talk) 11:21, 22 January 2018 (UTC)

Oh and thanks for the Parser migration guide. Is there a method for proposing that because semi-formal guidelines in Help: ? ShakespeareFan00 (talk) 11:21, 22 January 2018 (UTC)

I have no idea - anyone is free to take the page in whole or part and place content in the Help: namespace, not sure is there is a process. Inductiveload—talk/contribs 13:00, 22 January 2018 (UTC)

Malformed tables

Not strictly an Error but in the process of checking for lint errors I came across some table coded like this:-

{|
||content item 1
||content item 2
|-
|}

which based on informal comments, is sub-optimal in at least 2 ways. Linter doesn't check for these currently but a ticket has been raised as task T185203 ...ShakespeareFan00 (talk) 11:43, 22 January 2018 (UTC)

If it's not causing errors and it's not going to break dramatically with the new parser, then why worry too much about it? It's obviously nice to have perfectly formed Wikitext, but that just polish that a reader would never even notice. If the parser can handle it, it's fine: the output HTML will be well formed in any case - there is zero effect to the reader. In the above case, I see expected (and identical) output with both parsers:

<tr>
  <td>content item 1</td>
  <td>content item 2</td>
</tr>

Do you have an example of an actual problem you have encountered due to formatting like this? Inductiveload—talk/contribs 12:58, 22 January 2018 (UTC)

Not yet.. so we can probably not worry about this. ShakespeareFan00 (talk) 14:20, 22 January 2018 (UTC)

Misnesting

https://en.wikisource.org/w/index.php?title=Page:Railways_Act_1921_(ukpga_19210055_en).pdf/91&action=edit&lintid=777443

This one is ENTIRELY of my own making... Originaly cl-act-paragraph was div based which proved to be incompatible with many other parts of Wikisource.

Not entirely sure how to fix this one, cleanly but as the side-titles were not actually being displayed, I can probbaly remove the usage outright.

Implementing a P DIV switch in the template is another possiblity, but the template is reaching the limits of markup and parser functions... The whole family of templates should probably be converted to LUA code, which should be easier to maintain...

ShakespeareFan00 (talk) 14:20, 22 January 2018 (UTC)

I'm still not entirely clear what these templates do. What is the /x variant? What do the layouts do? What are the various levels? Do these instances just add an anchor? If you have start/end variants, why do you need to put the table in the parameter? They don't seem to do much formatting as it's all done manually in the parameters. These templates are almost impenetrable and totallylargely undocumented, both in terms of a documentation page and inline comments. All I can can tell you is what the linter tells me which is that there is appears to be an unterminated <p> tag in each of the last two template calls on that page. Inductiveload—talk/contribs 16:47, 22 January 2018 (UTC)

OK I see some documentation on the main template. First question: does the template need to contain the paragraph? Could save yourself a lot of escaping if the template just went at the start of the paragraph (or multi-paragraph block)? Plus page-break spanning would be free then and you wouldn't have to noinclude inside the templates, you'd put it in the header, as normal. Much less scope to have the template upset by the text parameter content if there is no text parameter:

<!-- open some kind of block environment/add anchors etc -->
{{cl-act-paragraph/s
 | section=.....etc
}}
The text is free to do what it wants <!-- no escaping required here -->

Look, ma! Another paragraph
{{cl-act-paragraph/e}} <!-- probably just a </div> or similar -->

Inductiveload—talk/contribs 17:21, 22 January 2018 (UTC)

The basic problem at present is that the template wraps a P tag... and you can't put a table inside that. The previous DIV based version of cl-act-paragraph was simplified down to try and get this working. I am increasingly of the view that the problem template should be deleted and someone else starts again, with a nice clean LUA version that can cope with additional situations rather than having to code individual exception clauses, in markup. Could probably add in a wrapper as well, but that's not something for right now ShakespeareFan00 (talk) 20:58, 22 January 2018 (UTC)

Now I'm actually angry, I modify the template so it just passes the text straight thru, and it STILL claims there is something missing an end tag, as you can tell from the history, I've tried SEVERAL methods for trying to get this working. I am having to conclude there is some really obscure interaction occuring. This is now beyond a joke. ShakespeareFan00 (talk) 23:36, 22 January 2018 (UTC)

Note to self, Don't debug your own code when you are getting annoyed with it... You'll miss the obvious mistake :( , and I agree that maybe it's time to rethink the approach entirely... ShakespeareFan00 (talk) 00:17, 23 January 2018 (UTC)

Templates...

Hi.. I'd attempted to fix a few templates, but it's getting increasingly to the point of WT&&!!&&%% is going on here, with the whitespace handling interactions, between template code, table code, noincludes, pages and transcludes, and I've reached the limit of what I can do.

I hope my changes did NOT break anything, but I am increasingly of the view that the lack of EXPLICIT line/block terminations is a liability...

As for {{cl-act-paragraph}}, It's not salvageable in it's current form... It should be deleted and replaced with something that actually works as intended when Mediawiki is capable of rendering something that complicated without needing to write complex code. ShakespeareFan00 (talk) 21:06, 24 January 2018 (UTC)

lintHint

Hi, recently you asked for Wikisource support.

Meanwhile I found time to make a quick test in both regular and Wikisource Page:/Index: environment. My impression was that all content model obstacles have been removed now.

Today I learnt that you are running a bot. Then it will be easy for you to change in JavaScript load statement from r.js (r for release) into d.js (d for debug/development). The version info on special page should turn into -2.13.

If there are any complaints please do not hesitate to notify me. If everything is going well, this will be disseminated also as r.js occasionally.

Greetings --PerfektesChaos (talk) 14:50, 7 February 2018 (UTC)

• @PerfektesChaos: Thank you very much! Just one thing: on enWS and mulWS, Page namespace is 104 and Index is 106. On deWS, it is 102 and 104, respectively. It's different again on frWS (104, 112) and itWS (108, 110). I have copied the JS to my local server and modified it and it does work in edit mode in Page namespace at enWS. This API query can get you the namespace mappings:
  • enWS: https://en.wikisource.org/w/api.php?action=query&meta=siteinfo&siprop=namespaces&formatversion=2
• Thanks again! Inductiveload—talk/contribs 17:09, 7 February 2018 (UTC)

• I just uploaded a multilingual Wikisource namespace version -2.14.
  • I would recommend not to fork but to keep global versions.
  • One idea I would like to implement if there are some hours left unused is a self-learning category name procedure. Once an unknown category ID has been encountered a system message was not loaded in time. However, the category ID might be memorized on local browser storage. From next page visit on it might be added to the system messages decorating table entries. Some time later it will be added to the JS code as well.
  • The linter framework has been born last summer and is still growing up. We will see where it goes for.
• The JS startup code has to decide very fast whether the current context is a candidate for linter analysis. It is loaded into all pages and should not consume more resources than really needed. If there are some suspicious numbers 102, 104, 106, 108, 110, 112 it is okay to look at the content model.

Enjoy --PerfektesChaos (talk) 20:35, 7 February 2018 (UTC)

@PerfektesChaos: That's now working for me here at enWS. I'm not planning on forking, I just could try out different IDs from a local server I keep running anyway! Thank you for the quick fix! Inductiveload—talk/contribs 21:01, 7 February 2018 (UTC)

@PerfektesChaos: Thanks for the updates for the WSes; it seems to be running fine previously from my global.js page through from very light usage. Thanks Inductiveload for getting local customisations identified and suggested. — billinghurst sDrewth 21:43, 7 February 2018 (UTC)

Wikisource support is now live for all.

If you have activated your own version I recommend to return to upstream now, since an automatic handler for unknown error types is now implemented.

Best --PerfektesChaos (talk) 10:05, 18 February 2018 (UTC)

@PerfektesChaos:, any chance to have also header/footer included in lint checking? Very often checking a page in read mode is not the same as checking in edit mode and it is a bit confusing. Thanks.— Mpaa (talk) 20:54, 26 February 2018 (UTC)

“Any chance” – this is a tricky expression.

Say never never.

However, I have a pile of Wiki work to do and I am committed over years.

There is one regular button, as in any text view and source code editing, feeding the body field.

The minor fields would need their own buttons.

I would not expect them this year. If you see such buttons one day, donate to amnesty international.

Until then there is the C&P way over special page.

Sincerely --PerfektesChaos (talk) 16:20, 28 February 2018 (UTC)

OK, I'll take it as a sarcastic "no". Thanks.— Mpaa (talk) 22:58, 28 February 2018 (UTC)

lintHint – split header and body

Hi, I received a complaint on dewiki.

• In these cases {{TOCstyle|header=yes}} has been put into header region.
• {{TOCstyle|completing=yes|model=CD.P ... }} is in the body field.
• {{TOCstyle|header=yes}} is opening <div><ol>
• The body contains the adjacent </ol></div>.
• Naturally, lintHint is detecting that body contains no complete HTML, and header would do so either.

I don’t see that lintHint can be of any help here nor being modified.

• From my point of view, it is no valid strategy to distribute a self-contained thing over various fields.
• I would expect to get every field independent, complete and closed in itself.
• However, I have no idea of customs or practises or namespaces on Wikisource projects.

Please solve this issue internally within enWS and contact the user directly.

TIA --PerfektesChaos (talk) 11:36, 12 March 2018 (UTC)

This was the reason for my question above.— Mpaa (talk) 22:57, 12 March 2018 (UTC)

Hi @PerfektesChaos: - the triple-input field form is how Wikisource performs proofreading of scanned works. The top and bottom fields are for the header and footer of the page, which are not transcluded, the central field is content that is transcluded into the mainspace. These elements are done on the server side, by the proofread-page extension. The actual Page-namespace content Wikitext then looks something like this:

<noinclude><pagequality level=\"3\" user=\"Inductiveload\" />HEADER CONTENT</noinclude>MAIN CONTENT<noinclude>FOOTER CONTENT</noinclude>

Whereas the transcluded mainspace content is just:

MAIN CONTENT

I understand that it may not be practical to adapt your tooling to accommodate the Wikisource projects (which, AFAIK, all use the proofread-page extension). However, I also don't think there is a way to "solve the issue internally", as the extension is a core part of how Wikisource operates. I am also not in any kind of admin position that means I speak for the project or any other user. Kind regards, Inductiveload—talk/contribs 12:03, 14 March 2018 (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. 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. 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 survey on the project page and see how your feedback helps the Wikimedia Foundation support editors like you. This survey is hosted by a third-party service and governed by this privacy statement (in English). 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 through the EmailUser feature to WMF Surveys to remove you from the list.

Thank you!

WMF Surveys, 18:36, 29 March 2018 (UTC)

Reminder: Share your feedback in this Wikimedia survey

Every response for this survey can help the Wikimedia Foundation improve your experience on the Wikimedia projects. So far, we have heard from just 29% of Wikimedia contributors. The survey is available in various languages and will take between 20 and 40 minutes to be completed. Take the survey now.

If you have already taken the survey, we are sorry you've received this reminder. We have design the survey to make it impossible to identify which users have taken the survey, so we have to send reminders to everyone. If you wish to opt-out of the next reminder or any other survey, send an email through EmailUser feature to WMF Surveys. You can also send any questions you have to this user email. Learn more about this survey on the project page. This survey is hosted by a third-party service and governed by this Wikimedia Foundation privacy statement. Thanks!

WMF Surveys, 01:34, 13 April 2018 (UTC)

Your feedback matters: Final reminder to take the global Wikimedia survey

Hello! This is a final reminder that the Wikimedia Foundation survey will close on 23 April, 2018 (07:00 UTC). The survey is available in various languages and will take between 20 and 40 minutes. Take the survey now.

If you already took the survey - thank you! We will not bother you again. We have designed the survey to make it impossible to identify which users have taken the survey, so we have to send reminders to everyone. To opt-out of future surveys, send an email through EmailUser feature to WMF Surveys. You can also send any questions you have to this user email. Learn more about this survey on the project page. This survey is hosted by a third-party service and governed by this Wikimedia Foundation privacy statement.

WMF Surveys, 00:44, 20 April 2018 (UTC)

{{Dotted TOC line}}

Hi! I am having some problem in transclusion due to template overload. I am not able to transclude pp. 115-120 of Index:The Pālas of Bengal.djvu. Can you help? Hrishikes (talk) 02:59, 14 May 2018 (UTC)

The problem here is that there isn't, as far as I am aware, a really "nice" way to do do dot leaders in HTML+CSS. {{Dotted TOC line}} and friends use a hack that looks OK in most cases (though it can interfere with some things in the containing table). However, it is a very intensive way to do it in terms of the Wikitext expansion limits - every cell basically contains another mini-table. This means that you can plausibly run into the limits set on the Wikisource server. There are the following remedies that I know of:

• Don't use dotted leaders at all and save all the pain - this is what I normally do. It's a shame not to have the dots, but at the end of the day, they're not essential.
• Split the dotted table across multiple mainspace pages, so that no one page runs into the limit.
• Find a way to implement the dotted templates without such insanely heavy markup so that it's not so likely to run into the expansion limits. I feel like tables-in-tables is not a good way to do it, but the templates are very complex and I don't really understand them.
  • This could be simplified greatly if we could add to the common.css file so we don't have to set CSS styles on every element individually but instead just add a class to the parent. However, that would reduce the flexibility a lot.

Sorry to be the bearer of bad news! Inductiveload—talk/contribs 12:51, 14 May 2018 (UTC)

OK, thanks. I have now done it in a hybrid way, but not completely eschewing the dots. (here.) Hrishikes (talk) 17:28, 14 May 2018 (UTC)

Author:Zhuanxu

Author? If not writing, wouldn't a collection be better in the Portal namespace? — billinghurst sDrewth 07:58, 18 May 2018 (UTC)

Yes, that might make sense. Maybe just a section on Portal:History of China? Sadly, like nearly all Chinese things we have, it's a pain to see if there are any suitable mentions we can link, as there are many transliterations, and, due to the age of most works here, none of them are the modern one! "Chuan Hsü" is a common one. Inductiveload—talk/contribs 14:27, 19 May 2018 (UTC)