User talk:SWilson (WMF)

 — billinghurst sDrewth 10:03, 2 September 2016 (UTC)Reply

Thanks @Billinghurst! Nice to be here full time. :-) SWilson (WMF) (talk) 12:04, 2 September 2016 (UTC)Reply

I requested a half-hour unconference session on Thursday Aug 10, hopefully with a demo from you of an upload to wikisource + related discussion. I'll get a pdf or some jpg files together. Here is how I described the proposed half-hour session. Edit that freely. After the demo we may agree on what to ask for on phabricator and pile on to an issue/task. Thanks for offering! -- econterms (talk) 20:55, 8 August 2017 (UTC)Reply

@Econterms: sounds good! Should we get together beforehand and run though the demo? Or can it be a bit casual and we'll figure it out as we go? Sam Wilson 11:24, 9 August 2017 (UTC)Reply

@SWilson (WMF): -- Let's reschedule for later. I'm sorry. I took it down from the unconference table. It would overlap with other sessions I want to attend, and it's not a North-America-specific topic anyway. Also I'm not ready yet with my images. I'm thinking of a putting up a Wright brothers airplane patent. It's an ideal thing for wikisource, I think. I can make images for each page given time. Should I upload each page to commons or just keep them on my laptop? Thank you for seizing the opportunity. Hopefully there is a chance to do this later in the main conference. -- econterms (talk) 13:00, 10 August 2017 (UTC)Reply

@Econterms: no worries! Let's figure out another time. Sam Wilson 17:09, 10 August 2017 (UTC)Reply

Hello,

I’d like to point out to you that the “Noongar WP” version of the website—whatever that means—has been overrun by spambots, which affects the search engine results pretty badly. Could something be done about that, perhaps?

Thanks,
—94.189.163.55 20:47, 25 November 2018 (UTC)Reply

@94.189.163.55: Thanks for the reminder! It's a known issue, but was untracked. I've opened T210363 and will hopefully see to it soon (in my volunteer capacity). SWilson (WMF) (talk) 01:15, 26 November 2018 (UTC)Reply

In specfic 2 categories of LintError.

1. Div Span Swaps (in relation to footnotes)- https://en.wikisource.org/wiki/Special:LintErrors/misc-tidy-replacement-issues?namespace=0&titleprefix=

Having attempted to eradicate a few of these, I've found that a number of the remaining concerns apparently relate to the seeming embedding of a DIV based tag within the current structure of the REF tag (which is currently wrapped using a SPAN. Being able to indicate that (and have rendered with an appropriate wrapper) that a reference should be treated as a block based item (and thus needs , (or as a "subpage" that should be parsed independentlyu of the context of the rest of the page.) would.

This was raised as https://phabricator.wikimedia.org/T49544. I wasn't happy with removing the wrapper entirely, but would like to see a way of specfiying a block wrapper is needed as opposed to a SPAN, so that there is one clear robust approach used, and all the various workarounds currently used can be deprecated, in favour of a clear implementation of the required functionality in the Cite extension, without a user having to know the more arcane interactions in order to support such things as lists/table or multi-paragraph footnotes which occur in works being trabscribded At Wikisource. (see s:https://en.wikisource.org/wiki/Category:Pages_with_block_based_footnotes for some pages where some of the current workarounsd have been applied)

Would it be possible to have a FOOTNOTE tag which has a block based DIV wrapper instead of a SPAN based one which REF uses.?

2. SECTION tags in 'continued' tables - https://en.wikisource.org/wiki/Special:LintErrors/fostered?namespace=104&titleprefix=

(see also - https://phabricator.wikimedia.org/T216350 )

SECTION tags are used extensively on Wikisource as part of LST. However, in the Page namespace, the reasonable use of a section tag to mark of a section of a continued table, causes the generation of a 'fostered-content' warning, even if the syntax of a page is nominally correct. It would be reasonable to ask if consideration is given to stripping out Section tags from a Page: when doing the Lint based analysis for content in Page: namespaces, where it is only the presence of a section tag that is seemingly causing generation of 'fostered' content.

Whilst neither of these are "simple" patches to make, they would assist in still further reducing the level of 'noise', allowing contributors to focus on the much reduced number of 'genuine' concerns in the Linter classes concerned.

Thanks. ShakespeareFan00 (talk) 14:22, 15 April 2022 (UTC)Reply

@ShakespeareFan00: I've been thinking a bit about the blocks-in-footnotes thing recently, and it really does feel like we should be able to switch to a <div> wrapper and solve the other issues with CSS. That way it'd be backwards compatible and there wouldn't be a need for a new tag. As for sections in continued tables, I'm not sure… it does sound tricky! I'll add both these to the next triage meeting's agenda. SWilson (WMF) (talk) 02:20, 16 April 2022 (UTC)Reply

@SWilson (WMF): Another tangentially related issue for English Wikisource issue is that there are currently various approaches used to sidenotes, not all of which are entirely ideal for mobile devices. Some of these sidenotes and marginals, can be straightforwardly converted to footnotes (which is the approach I've used on some transcription efforts.). In others the sidenotes are effectively crossheadings and section headers in the margin (particularly Legislation deriving from British and Commonwealth printing conventions for such works.). Would it be possible in updating the CITE extension to do the 'blocks' in footnotes to have some kind of 'display', 'clear' and 'float' style functionality for REF tag, which could be adjusted for different media types? The thinking here is to perhaps have a way of defining something to be <REF name="pXXXr1" role="marginal" default_pos="">A Marginal Note</ref> which could e collated to the end of a work (or the next References tag) if there was a user decision not to display the sidenotes/marginals directly, in position, whereas <ref name="hSec1" role="crosshead">Crossheading format</ref> would be a crossheading which should be placed "before" the block it is nominally contained in when sidenotes/mraginals are not displayed in 'position'. It would also be nice very very long term, to be able to have sideheadings in advance of their appearance in a given run of text, to do with how some OCR effrots have encountered them. (This is essentially not that different to using named references, but the option to 'hide' the initially definition but retain the other uses was not something I knew how to do easily currently.ShakespeareFan00 (talk) 08:17, 16 April 2022 (UTC)Reply

I wonder if supporting the <aside> tag would be good? Although I guess it doesn't do anything that a plan div can't. And I must admit I'm not totally on top of all the history of discussions around this stuff — and I know there's been quite a lot. It seems that the troubles with display and usability (small screens, printing, epubs, etc.) are pretty tricky to solve. SWilson (WMF) (talk) 00:26, 17 April 2022 (UTC)Reply

It's not as simple as just supporting an Aside tag, given that I am not sure even an ASIDE tag would allow you to do the kind of collation to heading or collation to footnotes , as required. That said, supporting additional HTML tags with semantic meaning is probably a good idea.

An Aside tag is also 'flow content' , which means it cannot be placed inside a tag like P or SPAN that only accepts (phrasing content). It is the additional handling to 'break' content out of the flow, and position it differently which cannot be done directly in HTML/CSS at present. (It is also due to the need for sidenotes to be placed within the run of other content as to why the current sidenotes templates at English Wikisource are nominally SPAN based.) This is why a REF tag with a role=marginal would need to be handled in the Cite extension , and could not in some instances be merely an aside tag. ShakespeareFan00 (talk) 06:36, 17 April 2022 (UTC)Reply

A very long term idea...

On a site called https://incompetech.com/graphpaper/ there are a serious of generators for various forms of 'regularised pattern' printing, for things such as lined paper and various sorts of lined, dotted and grid/graph papers.

Would it be possible for there to be some kind of mechanism in Mediawiki ( most likely as an extension), to allow these to be generated on the fly at Commons?

The thinking is that given the existence of various libraries for Lua, that support the generation of SVG, it would be feasible for this to be some as some kind of scriptable SVG generation (subject to appropriate sandboxing environment) in Mediawiki?

The various generators for 'gridpapers' and other types of 'regular content' could then be written in LUA, with the in-page SVG being generated as content from that script.

Really long term, you could also have script that's represented componenentised libraries of specifc types of symbol used on 'paper' or 'blank-diagrams' ( Examples being stripboard for electronic circuits, polar charts used in the audio and sensing fields, amonsgt others.).

I will also note as an aside here, that various forms of notation (that are not necessarily part of Unicode) could also potentially be gnereated by Lua scripted SVG generation, in complement to the approaches taken for Math (via Latex) and music (via Score). (One example of a different notation I had in mind was Ballet notation, or representation of signing symbols.)

08:35, 16 April 2022 (UTC)

This partly in follow-on to my comments earlier..

Would it be possible to add an attribute to noinclude content, that can be used to define the role the noincluded content has?

The thinking is that you could have something more like:-

<noinclude role="header"><pagequality level="1">{{rh|100|Headers and Ribbons}}</noinclude><noinclude role="ribbon">{|
|-
!Suggested role value
!Usage</noinclude>{{nopt}}
|-
|header||Content in the header for Page: namespace.
|-
!footer||Content in the footer for Page: namespace.
|-
!ribbon||Ribbon content such as that appearing as table headers.
|-
!sic||Notes not forming part of the original, related to updating the page such as [sic] markings for known misprints and addenda.
|-
!note||User annotations
|-
!ruby||Annotations giving transliterations of specific glyps, symbols or letters.
|-
<noinclude role="ribbon">{{nopt}}
|}</noinclude>
This is an example of a page with roles for no-inlcude defined 
<noinclude role="footer"><references /></noinclude>

ShakespeareFan00 (talk) 14:51, 16 April 2022 (UTC)Reply

@ShakespeareFan00: That does sound possible, but what would be the purpose? What is "ribbon"? Also, the noinclude tags for header and footer are managed by ProofreadPage and aren't directly editable. Although, there was a discussion last month about the idea of perhaps getting rid of them and making it all editable within a single wikitext page. That'd mean they could be customized. SWilson (WMF) (talk) 00:17, 17 April 2022 (UTC)Reply

• The role attribute would allow for Proofread page (or other extensions to handle different noinclude sections differently depending on what the role attribute was set as, in the way that you can class DIV (or span) using CSS, having an attribute by which noincludes can be subclassed would be useful.
• A 'ribbon' is a portion of (repeatable) content that should only appear in a specfic namespace , such as header lines of a table that should only be displayed at the start of a table in Page namespace. In some situations these 'ribbons' of content might not be continuous with the main page header. (See also s:Template:TOCStyle's rowXpageribbon option.)

One of the objective of having additional attributes for noinclude, is that assuming ProofreadPage ad LST were extended to process the additional attributes, is that a set of rules (i.e shcmea) could be more transparently specified, as to how different 'role's of noincluded content were to be processed and rendered, as opposed to having a single noinclude rule for everything. Without a 'role' attribute (or a blank one) the handling would be as at present. With an additional 'role' attribute, Proofread page and LST, could use the 'role' attribute and a set of rules elsewhere to determine how to process a specifc noinclude, and the desired behaviour would be defined in code. An example of the sorts of 'rules that could be defined are that soft newlines should be inserted around the content (so that 'doLevels' can insert it's P wrapping more correctly, or that trailing whitespace/linefeeds should be stripped/added. For example a 'ribbon' could be defined to always start on a newline, such that the SOL context needed for table or list syntax was always cleanly seen that way, without needing to use additional modifiers like s:Template:nopt, comments and so forth to 'force' newline and 'dolevels' behaviour to work as a content contributor intended. Perhaps as well as a 'role' attribute, you need some kind of equivalent of a 'display' attribute to explicitly indicate that a Noincluded section should be treated as 'inline','block', table section etc, which all need different combinations of SOL and significant whitespace for the mediawiki parser (even with use of explicit HTML syntax )?

Why are the Wikisource Triage meetings always held at 3 am? --EncycloPetey (talk) 01:43, 24 June 2022 (UTC)Reply

@EncycloPetey: I know, it's not very convenient! Sorry. We did put out poll asking for popular times, and choose based on that. It's really hard to find a good time for such a small and global-distributed community. Suggestions welcome!! SWilson (WMF) (talk) 09:00, 27 June 2022 (UTC)Reply

Item 1. https://phabricator.wikimedia.org/T311769 The cause is known (line breaks inside the input to a span based template, then nested in a DIV based one) sand I also requested a new linter for the resultant situation in the output concerned https://phabricator.wikimedia.org/T311827. It just needs someone to implement the relevant linter, or parser fix.

Item 2. Automated conversion of 'obselete' tags - English Wikiversity has a bot that can do this, but it needs all the mismatched tags to be cleaned up before it can run reliably in a given namespace.

Item 3. Lint Erorrs - Thanks to efforts by WikiGnomes, a fair proportion of the "Stripped tags" for English Wikisource content namespace have been resolved. To do this for Missing tags it would be nice to be able to partition the task, by being able to only list specfic tasg on the relevant sub page of Special:LintErrors. (This would also help in identifying mismatched tags for things like lists and blockquotes which can have an impact when Page:s are translcuded.)

I would strongly also suggest having a look through some of my o0lder tickets on Phabricator... more than a few are related to Wikisource use cases. ShakespeareFan00 (talk) 18:54, 1 July 2022 (UTC)Reply