Wikisource:Scriptorium/Archives/2020-09

How you find out what other people did

Hello, all, I'm looking at phab:T261023 about how people "patrol" other people's contributions. I know that some of you do this, but I've never done it myself here. I'm assuming that the process here is not quite what the big Wikipedias are doing, and I'd like your perspectives to be included. Feel free to join the Phab task (the etiquette there is that anyone can post "information", but "discussion" should usually happen elsewhere) or to ping User:Keegan_(WMF) to any discussion on wiki (or ping me, and I'll pass it along to him). Thanks, Whatamidoing (WMF) (talk) 17:25, 3 September 2020 (UTC)

@Whatamidoing (WMF): Thanks for thinking of us, and taking the time to invite us to the conversation. That is very very much appreciated!

But I'm not entirely sure the sort of patrolling we do here translates particularly to the Toolhub project, since that's a rather specialised use case. Patrolling here is basically a small scale and more laid back variation of enwp's patrolling, and just using plain old Special:RecentChanges with filters for IP and newbie (renamed "learner" now I think?) edits. Oh, and ad hoc use of +autopatrolled whenever an admin gets tired of patrolling edits from someone that's clearly ready to not need handholding.

The biggest difference with enwp is probably that we patrol more to spot, welcome, and assist newbies rather than look for vandals and bad faith actors. And that's more of a cultural thing than a technology issue (although having the tools reinforce the "We're the last line of defence!" mentality that so easily spreads in contexts like enwp's new page patrol is probably not the best idea: WikiLove should permeate all tools intended to interact with new editors). We also inherently have a vastly higher proportion of new pages created than enwp: each page of a scanned book is a wikipage in the Page: namespace here, and each such wikipage is usually only a single edit. Tools assuming that creation of a new wikipage is the best predictor of patroller interest are likely to not be a good fit here. A new editor creating fifty new wikipages is entirely normal here.

In any case… Happy to help, and pleased to be invited, but I'm not sure our experience will have very much to contribute to this particular discussion. I've subscribed to the task and will chime in if relevant. --Xover (talk) 14:28, 4 September 2020 (UTC)

We can/do also utilise a bot that can selectively patrol based on criteria, see User:Wikisource-bot/patrol whitelist though as time has progressed it has been less used. Xover pretty well covers that we have less targeted vandalism, and we use patrolling to more identify editors we wish to review. When we are comfortable that they have the gist of our namespaces, and our templates then we progress them. We are more likely to allocate the right then have someone ask for it. I will also note that we allow all autoconfirmed users to patrol edits, which is more relaxed than most wikis, and it has worked well here. — billinghurst sDrewth 15:16, 4 September 2020 (UTC)

I think it's important for the devs to hear these differences.

Am I correct in assuming that spam's not a significant problem here? Whatamidoing (WMF) (talk) 18:51, 4 September 2020 (UTC)

Spam here is mostly on User: or User Talk: pages, so relatively easy to deal with. Nuisance edits (e.g. changing dates of publication) are low volume. Other foci in patrolling are copyright violations and preserving the integrity of the text as printed (we get people "correcting" older spellings or changing text based on a newer edition). For the rest, I look for places where I can advise a new editor on proofreading problems and/or how to do things so as to comply with our house style. Beeswaxcandle (talk) 19:10, 4 September 2020 (UTC)

As we have a multiple of namespaces in which we undertake our edits, and lots of our content preparation is in the Page: namespace. So when we get a vandal or a spammer they are pretty evident in the main namespace. As you are aware editing in the Page namespace is a little more concealed from those unfamiliar with the site, so less targeted unless they are popping through RC. As we also have some standards like {{author}} and {{header}} in certain namespaces, when they are vandalised or missing they show up in AbuseFilters. Similarly as adding external links is less likely here in main namespace, having AF monitoring there is usually pretty effective. So with those other triggers, we will often find our vandals/spammers by other means equally with patrol marks. — billinghurst sDrewth 01:18, 5 September 2020 (UTC)

Not a forum‎

I've copied {{Not a forum}} from Wikipedia. Feel free to make it feel more at home. I just felt that in one case, I wanted a nice bright box to remind would-be commentators that we don't really need discussion of the aspects of the work that aren't relevant to Wikisource (in this case, what On the Creation of Niggers‎ says about its author.)--Prosfilaes (talk) 06:33, 6 September 2020 (UTC)

Legislation and Version History

I've started a project to upload documents related to the legislative history of Social Security in New Zealand. Starting with the Social Security Act 2018, I'm adding the first version of this, then will be adding acts that amend this document, as well as adding new versions of that document that resulted from said amendments. Following this, there are the predecessor acts to this, the Social Security Act 1964, and the Social Security Act 1938.

Once I get a good flow going, I'll be adding a significant amount of versions of largely the same document, as an act of Parliament is really a living document that changes with each amendment. Wikisource however, is static. So it'll involve potentially hundreds of pages that are exactly the same.

Normally here on Wikisource, different versions of publications are uploaded at their own root level, and are treated entirely as their own publication. While different issues/volumes of a magazine or encyclopedia are uploaded as sub-pages of their parent publication.

I feel that legislation is rather a mid-point between these, and since it's such a large area of history, warrants its own approach that works best for the way legislation works. I want to treat different versions as different "issues", and group them under the same publication.

To this end, I've started adding different versions of the Social Security Act 2018 as sub-pages, i.e. Version 56, and Social Security Act 2018/Version 59. I intend to eventually make the root page similar to a versions page, that links to the various versions, but also the amendment acts that affect this legislation.

I'm raising this here as the way I'm structuring this document and its versions has been highlighted as not following the norm of how things are usually done here, so thought I'd make the case that that legislation is different enough that it warrants a more unique approach. Happy to hear thoughts on this, or if people are happy for me to take this approach. Supertrinko (talk) 22:05, 1 September 2020 (UTC)

@Supertrinko: Having now also read through your discussion with Billinghurst on your talk page I'm beginning to understand what you're trying to do; and I think you've gotten a bit stuck on one conception of how you would like this to be that doesn't match Wikisource very well. On the one hand you argue that legislation is so unique that we should have special rules for it, but in the same breath you also argue that we have so much legislation here that we cannot possibly cope with it as independent mainspace works. Neither is actually accurate.

Legislation acts very much like any other works except that it has stronger divisions between editions. That is precisely why any change to a law is, in most jurisdictions, made in the form of an act in the legislative assembly describing the ways in which an existing law is to be amended. The original law is a work, of which the published version is an edition, and the amending legislation is a separate work with an edition (the published version). The original law does not get another edition until and unless a competent body published a consolidated version (the original text but incorporating the subsequent amendments). In the legal sense the law has changed when the amendment is enacted, but in a bibliographic sense the published version of the law is unchanged until a new version is published. Practices vary, but often these are published as "as amended up to date of last amendment" (as, indeed, NZ does: there are 13 editions of this law, the latest edition identified as "as at 01 August 2020"). For us to generate interim "versions" by ourselves applying the amendments would be outside of scope of the project; and if a competent body issues running amended versions those would be simple editions of the original and can be handled like all other editions of works.

And that works just fine with the existing setup for the United States Code and a myriad other pieces of legislation. The limiting factor here is absolutely not anything technical, but sheer man-power. No project to "continuously amend" that I've ran across here has been anything but an abject failure: it is a niche project of interest to a single person and dies with that person's waning interest. And the more divergent the setup the less likely anyone else will ever untangle it or be able to contribute. In fact, I note the original text of this law (the "as enacted" edition) hasn't even been proofread yet, but we're expending energy on a navigational and organisational construct for 59+ versions of it. This just doesn't scale.

It also doesn't actually give you what you indicate that you're after. Comparisons between versions are essentially a diff view, which is actually what the amendments are except written to be legible to humans (well, to the degree your ontological classification of practitioners of the legal arts intersects). For that purpose simply proofreading the amendment as written would be better. For more technical text comparison, the version construction is neither necessary (you can compare any two wikipages) nor sufficient (you'll get a diff at the wikitext level, not text level).

However, all that being said, we do have several alternate approaches that may help to achieve your goals. For one thing, it is entirely possible to construct a novel navigation system through standardised templates, regardless of the organisation of the pages. Once all the relevant editions have been proofread, our annotations policy would also permit doing something like a color-coded version that indicates the last time a given paragraph was amended. As an annotation it would have a lot more leeway to be innovative, and might even serve as a useful testing ground for technical innovation that would benefit other such cases.

In sum, I suspect you've jumped straight to a solution before the "figure out how best to solve it" step. --Xover (talk) 06:35, 2 September 2020 (UTC)

@Xover: First I'll say you're actually completely right, I've been solution focused! I do think there's a problem to be solved, but happy to look over the best way to do this.

That said, I'm not suggesting that we can't cope with the number of acts/amendments/versions, I was just suggesting that organisation is necessary, and my go-to was treating different versions of legislation like issues of a periodical, which would neatly organise them via the URL.

A couple points which may be specific to NZ legislation, you mentioned "The original law does not get another edition until and unless a competent body published a consolidated version (the original text but incorporating the subsequent amendments).", in NZ legislation, every amendment triggers a reprint of the original act in a new version, so there's no risk of us generating interim versions that don't exist as a work. In that respect, I think everything is in scope.

Secondly, yes, there's the risk that I lose interest in this project (though with it being related to my work, this'll take a while), from what I've read of discussions on "collective works" on this site, the key thing there is setting up a project in such a way that anyone can make sense of its structure and can pick it up at any moment. I agree this is essential. And with reference to "59+ versions", just a note, with the SSA 2018 that I've added, "Version 56" is weirdly the first version of the document. Other versions are internal versions held by the Parliamentary Counsel Office that aren't publicly available. The second version available is called "Version 59", as versions 57/58 are internal only. I know these are just side-points, just wanting to add some clarity to my particular project.

You're right that it doesn't completely allow version comparison. I did want to keep everything as static separate texts, which is how things are done here at Wikisource, so I did the closest thing I could. But, I can access Section 8 (v56) and Social Security Act 2018/Version 59/Section 8 and see the note that details the change and see the act as it appeared in each version.

So, I'm happy to take a step back from my solution and look at the problem. The problem statement is that navigation of related legislation and versions of that legislation is challenging. So it's not that Wikisource can't handle it, it's that I think navigation of this content might be challenging. Perhaps first I should ask, do people agree this is a problem, that this is a problem that hasn't been solved, and should be solved?

The United States Code is not presented as separate versions as far as I can tell, it's just continuously added to as new laws are incorporated into it. There's nothing like that in NZ law that I can compare to.

The annotation suggestions you've mentioned are something I'll definitely look into, I'll scope out some examples and see how that might look. That might help with the version comparison side of things, but yeah, I think the organisation of the information is still an important issue. Supertrinko (talk) 07:49, 2 September 2020 (UTC)

@Supertrinko: I'm failing to find the time to dig into the details here, so I can't really propose a specific solution. But in the interest of not just leaving you hanging here… From my relatively superficial look my thinking is that what you're after can be achieved by the normal organisation as editions combined with a custom work-specific navigation template. We have some precedent for that approach, and it would be analogous to our use of {{AuxTOC}} (not present in the original work, but clearly visually distinguished as an addition made by Wikisource). So my proposal is that we investigate that approach to see if it meets your needs and can be implemented without running into anything unforeseen. --Xover (talk) 10:36, 5 September 2020 (UTC)

Okay, that's a really good suggestion! In that respect, I could include amendment acts under this template, even though they are not versions of the original act, they just impact it. That is what I'm looking for, so I'll give that a go. Appreciate your assistance here. Supertrinko (talk) 22:14, 7 September 2020 (UTC)

Tech News: 2020-37

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Changes later this week

• Normally pages can be moved to a title that has no existing page yet or to a page that has only one revision, which is a redirect to the page to be moved. A new user right allows editors to move pages over one-revision pages that redirect to anywhere. [1]
• The new version of MediaWiki will be on test wikis and MediaWiki.org from 8 September. It will be on non-Wikipedia wikis and some Wikipedias from 9 September. It will be on all wikis from 10 September (calendar).
• All MediaWiki API modules will now use watchlist instead of watch. This was inconsistent before. [2]

Future changes

• The Wikipedia Android app team might work on patrolling tools in the future. You can let them know what tools would be useful for you or for less experienced patrollers. See the page on mediawiki.org.
• OTRS will be updated to a new version. This will probably take around two days. OTRS agents will not have access to the system during these days. Emails that come in during the update will be delivered when the update is done. The plan is to start around 08:00 UTC on 14 September. This could change. [3]
• The Wikipedia Android app will send push notifications if users want them. This could help you see for example when someone wrote on your talk page or your edit was reverted. This will need Google Play Services to work. It will also be possible to get the app without Google Play Services but push notifications will not work. Google Play Services is also used to make the app work for Android 4.4 users. [4][5]
• Wikimedia code review could move to GitLab. It would be hosted on Wikimedia servers. You can take part in the consultation.
• Dropdown menus in the Vector skin use a .menu class. This will not work in the future. Scripts can use nav ul instead. .vectorTabs and .vectorMenu will also not work. Some scripts need to be updated. You can read more in Phabricator.

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

15:59, 7 September 2020 (UTC)

Missing horizontal rules (height:0 in global CSS)

It seems that horizontal rules using the <hr> element are no longer visible, due to the following CSS in the global CSS:

hr{height:1px;background-color:#a2a9b1;border:0;margin:0.2em 0}
....
hr{box-sizing:content-box;height:0;overflow:visible}

This appears to be phab:T262507, which is hopefully going to get a fix soon. I have "repaired" the primary user, {{rule}}, where it was reported on the talk page, as this template should be entirely independent of the Mediawiki skin. However, there are quite a few other users of the raw HTML which are also broken. I think we can probably wait for this to be merged rather than faffing with our own site CSS, but we should also probably be looking at the use of bare HR's in content spaces which should probably be {{rule}} (paging WS:IGD?). Inductiveload—talk/contribs 11:38, 10 September 2020 (UTC)

Invitation to participate in the conversation

We are excited to share a draft of the Universal Code of Conduct, which the Wikimedia Foundation Board of Trustees called for earlier this year, for your review and feedback. The discussion will be open until October 6, 2020.

The UCoC Drafting Committee wants to learn which parts of the draft would present challenges for you or your work. What is missing from this draft? What do you like, and what could be improved?

Please join the conversation and share this invitation with others who may be interested to join, too.

To reduce language barriers during the process, you are welcomed to translate this message and the Universal Code of Conduct/Draft review. You and your community may choose to provide your opinions/feedback using your local languages.

To learn more about the UCoC project, see the Universal Code of Conduct page, and the FAQ, on Meta.

Thanks in advance for your attention and contributions, The Trust and Safety team at Wikimedia Foundation, 17:55, 10 September 2020 (UTC) 

Tech News: 2020-38

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Problems

• The Wikipedia apps briefly showed pages without CSS last week. This meant they looked wrong. It was quickly fixed but cached pages without CSS were shown for a few hours. [6][7]

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 15 September. It will be on non-Wikipedia wikis and some Wikipedias from 16 September. It will be on all wikis from 17 September (calendar).

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

16:19, 14 September 2020 (UTC)

File import

On reflection, I think File:A note on grappling tail-hooks in anopheline larvae - M.O.T. Iyengar - 1922.pdf (published in India in 1922, author died in 1972) is not eligible to be hosted on Commons, and should be imported here. Can someone oblige, please? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:06, 12 September 2020 (UTC)

@Pigsonthewing: Done Please update the file locally, and add {{do not move to Commons}} Thanks. — billinghurst sDrewth 15:21, 15 September 2020 (UTC)

I have no idea what you mean by "update the file locally". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:36, 15 September 2020 (UTC)

Typically we would use {{book}} and have a valid licence, and amend categorisation. — billinghurst sDrewth 15:39, 15 September 2020 (UTC)

yeah, just to elaborate - when stuff gets deleted at commons, then there is no mirror here linking to it, and we edit it locally at this project. also information template is notoriously generic, with the wrong fields for artworks and books, so we resort to custom metadata templates. Slowking4 ⚔ Rama's revenge 17:11, 16 September 2020 (UTC)

Pagelist widget

From Sohom Datta, on the 'Wikisource-l' mailing list:

We are excited to announce that the Wikisource Pagelist widget is now available to be enabled on all Wikisources. Any interface admin on your wiki can enable it by using the instructions on the following page:

https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Extension:ProofreadPage/Pagelist_widget

[...]

Feel free to also give us any feedback on the project talk page on Meta-Wiki as well.

Can someone enable this, please? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:41, 11 September 2020 (UTC)

@Pigsonthewing: Done and appears to work. Thanks for the heads-up and thanks to the developer. Great tool! Inductiveload—talk/contribs 10:07, 11 September 2020 (UTC)

Pagelist defaults

This widget allows to select defaults from a list, configured by MediaWiki:Proofreadpage pagelist dropdown values.json. I have used the example values with some minor changes. What is the actual preferred terminology for the various pages:

• Covers: "Cover" or "Cvr"
• Blank un-numbered pages: "-", "–" or "—" (hyphen, en, em dash)
• TOCs: "TOC", "ToC"
• Plates (i.e. whole page images inserted outside the usual numbering sequence): "Image", "Img" or "Plate"

All have the implied "something else" option too and we can add more ("Title"?) Inductiveload—talk/contribs 10:17, 11 September 2020 (UTC)

My preferences would be:

"Cover"

"-"

(because it is on the keyboard)

"ToC"

"Image"

(because I understand them faster.) --Zyephyrus (talk) 15:31, 13 September 2020 (UTC)

 Comment I would like to remind people that we should be utilising existing page numbers over someone's created labels, even when the page numbering is mute, though explicit from surrounding numbers. There is nothing more irritating than seeing ugly, repeating and unusable TOC TOC TOC for adjacent pages. I still fail to see why we use either COVER or CVR, what is that? what is the purpose? just put a dash. Similarly what is the value in "PLATE" unless we are linking to it. These are page numbers/bookmarks, so in the end set them as they should be rather than some creation.

To the question, the hyphen becomes very small to select from pagelist, so I prefer a larger endash, especially as it is the same width as a numeral. — billinghurst sDrewth 23:57, 13 September 2020 (UTC)

• I also think hyphen instead of dash as it's easier to type. And 'Title' would be useful. What about 'Index' and 'Advertisement/Adv.'? Although, it's always possible to type those in, and they're not that common. @Billinghurst: the reason for 'plate' and similar is mostly for when they're not part of the pagination, i.e. have been pasted in after binding. You're right about hyphen being too small, so maybe it could be a dash for the dropdown label but added to the pagelist as a hyphen? —Sam Wilson 00:02, 14 September 2020 (UTC)

  It should be an endash in the final presentation, so what displays on a ready Index page, and what shows in a page numbering. I care not about the dropdown. I understand that it is a plate and outside of the page numbering. I would still state that it doesn't need a presented label and page numbering that says plate, it can just be the dash. I much prefer to put in the anchors on the page for plates and not rely on a generic page numbering ad an ugly displayed label. — billinghurst sDrewth 15:27, 15 September 2020 (UTC)

Wikisource Pagelist Widget: Ready to be enabled

Note: This message is in English, but we encourage translation into other languages. Thank you!

Hello everyone,

We are excited to announce that the Wikisource Pagelist widget is now available to be enabled on all Wikisources. Any interface admin on your wiki can enable it by using the instructions on the following page:

https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Extension:ProofreadPage/Pagelist_widget

In case, your wiki doesn’t have an interface admin, reach out to us on the ‘Help with enabling the widget on your wiki’ section of the project talk page and we will connect you with a global interface admin:

https://meta.wikimedia.org/wiki/Talk:Wikisource_Pagelist_Widget#Help_with_enabling_the_widget_on_your_wiki

You will need to hold a local discussion around what would be the labels for different page types in your language for the visual mode. (For example, ToC = ਤਤਕਰਾ in Punjabi, title = শিরোনাম in Bengali)

Feel free to also give us any feedback on the project talk page on Meta-Wiki as well.

Regards

Sohom Datta

Sent by Satdeep Gill (WMF) using MediaWiki message delivery (talk) 05:56, 15 September 2020 (UTC)

See above. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:00, 15 September 2020 (UTC)

Widget making pagelist box too small

@Sohom data: With the change the pagelist box size is now only three rows, which is a right PITA. If one is not using the gadget, I would be expecting a standard pre-change box size. — billinghurst sDrewth 22:11, 15 September 2020 (UTC)

@Billinghurst: a workaround in the meantime might be something like the following in your common.css:

#wpprpindex-Pages {
	min-height: 15em;
}

Obviously you can change the 15em to suit your preference. Inductiveload—talk/contribs 10:40, 18 September 2020 (UTC)

We originally wanted to make the box autosizing, so that it would fit all the text the user had currently entered, as well as making sure that people who wanted to use the widget wouldn't have to scroll through quite a bit of empty space. However, due to some issues with OOUI, we couldn't include that in the release. (T262144) I'll create a patch to fix the rows parameter until we have proper autosizing. :) Sohom data (talk) 18:44, 18 September 2020 (UTC)

Georgia v. Public.Resource.Org, No. 18-1150

[Moved here from Wikisource talk:Copyright discussions#Georgia v. Public.Resource.Org, No. 18-1150. --Xover (talk) 07:07, 18 September 2020 (UTC)]

I am sorry if this is the wrong place to post this. I am most active on en.wikipedia. I just wanted to note this decision and make sure you know about it. In Georgia v. Public.Resource.Org, No. 18-1150, the US Supreme Court ruled that "Georgia may not copyright its entire official code, which includes both the state's laws and annotations".[8] I think this applies not only to Georgia but to every state in the US, when it comes to their laws. The annotations are very useful information for us to archive but I believe they only apply to Georgia because the interpretive works were done by members of the Georgia government. The decision is here. Coffeeandcrumbs (talk) 04:56, 18 September 2020 (UTC)

@Coffeeandcrumbs: Thanks for thinking of us! That is indeed a very useful reference. To ensure it gets seen I've moved it here to the Scriptorium (our version of the Village Pump).

Provided I've understood it correctly, the key factor is that USSC established a new test for "Edict of Government" that focusses not on force of law but rather on the work in question being authored by legislators or a legislative body. On Wikisource—whose copyright policy is to only require a work to be public domain under US copyright law (vs. Commons that also requires the same in the country of first publication)—this has the effect of significantly expanding the application of the "Edict of Government" exception. In practice we've not had many cases where that would have made a difference, but I think there are now a significant number of works that are eligible to be hosted here that were not previously so. --Xover (talk) 07:07, 18 September 2020 (UTC)

Bigger spaces between paragraphs

I don't expect to get much traction for this, but it's been bothering me for a while so here goes.

In prose text, the spacing between paragraphs doesn't really matter too much. The current paragraph spacing is fine. If we increased the paragraph spacing a bit, it would still be fine.

In poetry, however, the semantic encoding of the poems in HTML is best done by using line breaks between lines, and paragraph breaks between stanzas - but our paragraph breaks are too small for this to adequately space the stanzas, leading many editors to use the less-semantic habit of using a double line break between stanzas. This could be easily and neatly handled by modifying our site-wide CSS to have a little bit more space between paragraphs.

The only downside I can think of is the (relatively) small number of texts that use complex workarounds that depend on the height of paragraph breaks to display properly - but I argue that these do not matter because a) there aren't really that many of them, b) such a display constraint is (essentially) a hack and could not be expected to work forever, c) such a display constraint violates the responsive design principles of web-based texts, especially on websites like Wikisource where multiple formats are presented (web, mobile, epub), and d) we can fix them when we see them.

I am interested to hear the community's thoughts on the subject. —Beleg Tâl (talk) 14:36, 18 September 2020 (UTC)

@Beleg Tâl:: this is easy to do with site CSS, if the poem extension emitted sane HTML. Rather than BR-separated lines and P-separated stanzas, I think it would make more sense to do it this way: for the poem markup:

<poem>
Line 1a
Line 1b
Line 1c

Line 2a
...
</poem>

generate the following HTML:

<div class="poem">
  <div class="stanza">
    <p>Line 1a</p>
    <p>Line 1b</p>
    <p>Line 1c</p>
  </div>
  <div class="stanza">
    <p>Line 2a</p>
    ...
  </div>
</div>

This is because this was you can also achieve the very common formatting of hanging-indents for continued lines something like this:

Now Jones had left his new-wed bride to
        keep his house in order.
And hied away to the Hurrum Hills above
        the Afghan border,

by setting a CSS rule for .poem > .stanza, either with TemplateStyles or site-wide. Using BR-separated lines means you get the following, since it's all one paragraph and therefore doesn't get a new indent:

Now Jones had left his new-wed bride to
        keep his house in order.<br/>
        And hied away to the Hurrum Hills above
        the Afghan border,

Once this HTML structure is present, you can also have control over stanza padding-top/-bottom to control the inter-stanza spacing.

There is a Phabricator task for this: phab:T199075, and the similar phab:T8419. Inductiveload—talk/contribs 15:05, 18 September 2020 (UTC)

Many editors (myself included) don't use the poem extension because it doesn't output sane HTML. Unless the poem extension were to be improved (which is unlikely, according to the devs at Phabricator), then maybe the poem extension isn't a useful way of handling this. Also, I do not understand why it would make sense for individual lines of a poem to be semantically tagged as paragraphs unto themselves? I do agree that the ideal method would to have a special markup for poems that works and that spaces the stanzas accordingly, but my proposal is based on what we ourselves are actually able to do. I suppose we could do it as a template, if we can get past our usual issues with template spread {{Poem begin}} {{Poem-on}}. —Beleg Tâl (talk) 15:10, 18 September 2020 (UTC)

I understand about the poem extension being busticated, but it looks extremely simple and I wonder if we can make/beg for a new or variant poem tag to use for "correct" poems.

Re: Also, I do not understand why it would make sense for individual lines of a poem to be semantically tagged as paragraphs unto themselves?

This is because <p>Line 1<br/>Line 2</p> is considered a single line for the purposes of indentation. Which means on a small screen the following poem:

Now Jones had left his new-wed bride to keep his house in order.
And hied away to the Hurrum Hills above the Afghan border,

wraps to something like

Now Jones had left his new-wed bride
to keep his house in order.
And hied away to the Hurrum Hills
above the Afghan border,

or, with a hanging indent, something like

Now Jones had left his new-wed bride
        to keep his house in order.
        And hied away to the Hurrum Hills
        above the Afghan border,

which means you can't see the original lines. As opposed to how the poems are actually formatted in nearly all books:

Now Jones had left his new-wed bride
        to keep his house in order.
And hied away to the Hurrum Hills
        above the Afghan border,

I think SPAN would work as well as P. Inductiveload—talk/contribs 16:39, 18 September 2020 (UTC)

Category conversations—some proposals

I am going to be addressing a number of components about categories as I start to do some re-organisation and some tidying. The basis of the re-organising is to primarily to allow categorisation of our biographies; the aligning of occupations of authors and biographies of authors; the creation of meta categories and their alignment to existing WD cats for people.

Some issues that I would like to address and resolve

• Nomenclature of occupations
• Deprecate the use of category parameter in headers, with aim of removing
• To group or not to group biographical/encyclopaedic/dictionary/... subpages by work

Nomenclature of occupations

Previous discussion at Wikisource:Scriptorium/Archives/2020-05#Time to talk nomenclature of author classification by occupation that looked to determine how we would categorise occupations for more than authors. Examples are

• Category:Physiologists (meta caegory)
  • Category:Authors who are physiologists <=> Category:Physiologists as authors
  • Category:Biographies of physiologists‎

The meta category is configured for HotCat to not allow its selection as the final choice, instead it will show the next layer down.

Still trying to get opinion on which style of category name people would prefer, noting that there are going to be lots,

1. Authors who are physiologists
2. Physiologists as authors

I have tossed and turned, though think 2), as they up in HotCat quicker, and they will sort better in alphabetical lists without the need for defaultsort.

Actions:

• Please indicate which style of author occupation nomenclature is preferred/

Discussion

It might be enough to have just Category:Physiologists which would contain authors who are physiologists + its subcategory Biographies of physiologists‎. This subcategory would be indexed by a space or an asterisk so that it was not alphabetically mixed among other potential author subcategories. The reason is that both names of the suggested subcategory for authors are quite long for a category name. However, if the opinion to have such subcategory prevailed, I would prefer "Authors who are physiologists". --Jan Kameníček (talk) 15:43, 19 September 2020 (UTC)

The issue with this approach is that would not be able to restrict the addition of author pages or biographical works to the category, so we are still going to need to eyeball and manually clean the categories. I was trying to avoid that sort of process wherever possible.

To also note that I started on biograhical and have yet to introduce how we categorise other non-fictional and fictional works, they still need to be within the model. — billinghurst sDrewth 14:17, 20 September 2020 (UTC)

I like this idea of subcategorizing only the biographies. Or, what if we called the author category "Physiologist authors" ? The closest parallel I have found in a brief search of our sister wikis is w:Category:Politicians by occupation which uses the pattern "Physiologist-authors". —Beleg Tâl (talk) 19:25, 19 September 2020 (UTC)

On the other hand, considering that we don't allow categorizing by Biographies-of-Person, then why do we even have categories for Biographies-of-Person's-Occupation at all? —Beleg Tâl (talk) 19:40, 19 September 2020 (UTC)

We don't allow categories based on individuals, and that is due to preferring curated pages for collection(s) of works. — billinghurst sDrewth 14:08, 20 September 2020 (UTC)

"Psychcology authors", surely? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:51, 20 September 2020 (UTC)

Deprecate category parameter in headers

I would like to propose that we deprecate the use of categories in {{header}}. My reasons are:

• It makes maintenance difficult. None of pywikibot, AutoWikiBrowser, and HotCat can inherently know that the parameter is used so it takes text replacement methodology; or manually editing categories
• The use of the parameter allows the categorisation into categories that are either redirected or meta categories (category:category redirects and category:disambiguation categories). Such categorisation should be avoided wherever possible.

You can see list of usage of the parameter in Category:Works using categories parameter

 Comment Embedding categories inside templates is a bit ugh, unless they are distinct values, and I would suggest we probably shouldn't use that methodology unless it is data that is recorded against the item in Wikidata, eg. gender, birth_year, death_year, etc. and changes align with a WD edit. — billinghurst sDrewth 12:53, 19 September 2020 (UTC)

Discussion

Agree. --Jan Kameníček (talk) 15:44, 19 September 2020 (UTC)

 Support. Also as mentioned, it would be useful to have the header template the logic to auto-categorize based on Wikidata, but removing the ability to manually categorize this way is a good idea. —Beleg Tâl (talk) 19:27, 19 September 2020 (UTC)

@Beleg Tâl: once a hierarchy is built, then the community can decide on next steps. — billinghurst sDrewth 13:45, 20 September 2020 (UTC)

To group or not to group biographical/encyclopaedic/dictionary/... subpages by work

The categories utilised by EB1911 have a thorough category hierarchy of its own Category:1911 Encyclopædia Britannica that is basically independent of our standard category build. Other categorisation has been quite flat. so the question is do we mass collect in category of type with a parallel hierarchy, or do we have a subhierarchy that collates subpages by works

So which is preferred

• Category:Biographies of politicians has a conglomeration of works which are forced to defaultsort by the subpagename, so become a mix of all the biographical works by person. This gives a straight alphabetical, though the long page names makes eye-reading difficult.
• [[:Category:Biographies of politicians in Thom's Who's Who in Ireland]] (as a possibility) means that there names would be a little more eye-readable and further categorised, though requires additional digging, and biographical types could be linked to a parent, something like [[:Category:Biographies by occupation in Thom's Who's Who in Ireland]]

— billinghurst sDrewth 14:04, 20 September 2020 (UTC)

Tech News: 2020-39

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Recent changes

• There is a new tag for reverted edits. For example you can see it in the recent changes feed or in the article history. It is added to edits when they have been undone, rollbacked or manually reverted to an older version of the page. [9][10]

Changes later this week

• The number of times you can do something in a period of time on wiki is limited. This could be the number of edits per minute or the number of users you email in a day. Some users are not affected by all limits because of their user rights. They could soon see the limit even if it does not affect them. [11]
• The new version of MediaWiki will be on test wikis and MediaWiki.org from 22 September. It will be on non-Wikipedia wikis and some Wikipedias from 23 September. It will be on all wikis from 24 September (calendar).

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

21:28, 21 September 2020 (UTC)

Math symbols available?

I am not certain whether the page Page:The Evolution of British Cattle.djvu/107 is able to be done with math symbols or some variance. Very happy if someone can do something better than I have in place. Thanks. — billinghurst sDrewth 12:19, 22 September 2020 (UTC)

and Page:The Evolution of British Cattle.djvu/111 — billinghurst sDrewth 12:42, 22 September 2020 (UTC)

I don't believe that our math plugin supports this kind of diagram. w:Help:Displaying_a_formula recommends building the diagram in TeX, exporting to SVG, and uploading to Commons to use as an image. I do like your approach to it though; maybe you could do something like ●
 /●→
⤨/→●
 /○ for the more complicated ones? —Beleg Tâl (talk) 13:33, 22 September 2020 (UTC)

Anyway, if you can render TeX to export as SVG, I found this site which allow you to create diagrams like this to generate code like this:

\begin{tikzcd}
● \arrow[r] \arrow[rd] & ● \\
● \arrow[r] \arrow[ru] & ○
\end{tikzcd}

—Beleg Tâl (talk) 13:43, 22 September 2020 (UTC)

Thanks. I am going with KISS, these representations will do. I am not looking for a facsimile. — billinghurst sDrewth 13:55, 22 September 2020 (UTC)

Index:The famous speeches of the eight Chicago anarchists in court.djvu

Can someone (@Xover: you are good at this) fix the text layer offset in this Index? —Beleg Tâl (talk) 15:45, 23 September 2020 (UTC)

@Beleg Tâl: Done. Minimal quality control, but I rebuilt it from the source scans at ~2.5x resolution, and a few spot checks didn't show any OCR offset problems. --Xover (talk) 17:54, 23 September 2020 (UTC)

New feature: Watchlist Expiry

Hello, everyone! The Community Tech team will be releasing a new feature, which is called Watchlist Expiry. With this feature, you can optionally select to watch a page for a temporary period of time. This feature was developed in response to the #7 request from the 2019 Community Wishlist Survey. To find out when the feature will be enabled on your wiki, you can check out the release schedule on Meta-wiki. To test out the feature before deployment, you can visit Mediawiki.org or testwiki. Once the feature is enabled on your wiki, we invite you to share your feedback on the project talk page. For more information, you can refer to the documentation page. Thank you in advance, and we look forward to reading your feedback! --IFried (WMF) (talk) 16:46, 23 September 2020 (UTC)

Subject to change, the implementation date is listed as September 22, 2020 for Enwikisource. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:12, 24 September 2020 (UTC)

Wikisource Pagelist Widget: Wikisource Meetup (29th September 2020)

Hello everyone,

We hope you are doing well!

We reached out to you a couple of weeks ago to share that Wikisource Pagelist Widget is now ready to be enabled to Wikisource. Since then, many language Wikisources have enabled the widget but many are yet to do so.

So, we have decided to organize a Wikisource Meetup to give a live demonstration on how to use the widget in both wikitext and visual modes. There will be some time for the participants to share their feedback and experience with the widget. We will also provide support in case some Wikisource communities are seeking help in enabling the widget.

The meetup will take place on 29 September 2020 at 9:30 AM UTC or 3 PM IST. Google Meet link for the meeting is: http://meet.google.com/khu-dfph-qsd

Looking forward to seeing the global Wikisource community connect amid these difficult times when physical meetings have not been taking place.

P.S. If you are planning to attend this meetup and are comfortable in sharing your email address then send us your confirmation in the form of a small email to sgill@wikimedia.org, this will help us in getting a sense of the number of people that are planning to show-up. We are aware that this time-zone is not convenient for everyone and more meetups can be organized in the future.

Regards

Sohom, Sam and Satdeep

Sent by Satdeep using MediaWiki message delivery (talk) 11:03, 24 September 2020 (UTC)

Relationship with Project Gutenberg

I'm new here, and wondered what Wikisource's relationship with Project Gutenberg is. I've found books like A Passage to India which are incomplete here and have a proofread page while Gutenberg have a finished copy, but no mention is made of that here either for the book or on E. M. Forster's page other than an authority control reference.

But I've also seen other Gutenberg texts imported here, but books Gutenberg finished in 2003 are missing.

Do you have a policy to avoid duplication of effort and bring the sites together, either by manual updates or bots Vicarage (talk) 09:26, 20 September 2020 (UTC)

@Vicarage: We have no relationship with Gutenberg, though there may be editors who contribute at both places. Some have copied works transcribed there to here, presumably because they wanted to do so. Most people will typically work on something new, rather than regurgitate a work from elsewhere. We can just as easily link to a work at Gutenberg from an author page. — billinghurst sDrewth 13:40, 20 September 2020 (UTC)

My attempt to add a Gutenberg reference to the Author:Jules_Verne article was reverted, User:EncycloPetey arguing in User_talk:Vicarage that because Gutenberg's process is flawed, we must not mention them here. My response is that while Gutenberg may not be ideal, I feel that before people embark on the major task of doing a proof read they should be aware that others have already done similar work. That allows them to decide that another project is more worthy of their time. I worry that excluding gutenberg references (and the fact there is a template shows that someone felt them worthwhile) smacks of NIH, and makes perfect the enemy of the good. I'd be a lot more reluctant to contribute here if Gutenberg (and FadedPage's) efforts were not recognised, and I found I'd proofread edition 4 of a book where Gutenberg had done edition 3, and the difference was 2 words. I would appreciate comments from others on the subject. Vicarage (talk) 17:22, 26 September 2020 (UTC)

Part of the problem is that Gutenberg does not distinguish between editions. We often don't know which edition Gutenberg has, unless someone with specialized knowledge takes the time to do extensive research and comparisons. But even after that, Gutenberg has no transparency of their quality control, so we don't know when Guenberg has a franken-edition cobbled together, and no simple way to check for errors. If a scan-backed edition is possible, we should always aim for that. Adding links to Gutenberg editions on top of the editions we host here is not what Author pages are for. Our Author pages are meant to supply links to the works hosted here and not to collections elsewhere on the internet. Where no edition exists, and no good scan is available, we might temporarily link to Gutenberg so that a local copy can be created. But once we have a local copy, the Gutenberg link (or any external link to that work) on the Autnor page should be removed. Wikisource is a library, not a link farm. --EncycloPetey (talk) 17:33, 26 September 2020 (UTC)

And, frankly, it is not our job to advertise for Project Gutenberg. --Xover (talk) 17:52, 26 September 2020 (UTC)

@Vicarage: Just to add to this. The linking on author pages is to public domain works has an hierarchical approach. This has evolved through discussion and sensible practice, and probably not (well-)documented (following list is meant to be indicative and informative, not set policy)

• Link to local edition (public domain works)

  > If no local edition, though have a scan available, then append link with {{small scan link}}

  > If no local edition, then append link to external scans available {{ext scan link}} or {{IA small}}

  Implicit in both these is that when we progress works we will remove these templates from author pages

  > If no local edition, then you can external link to another edition (hyperlink title), can also append {{ext scan link}}

  > If no editions, then you can link to an external version/work.

Notes:

• External links to external works can be added if legally published and not able to be hosted locally. We wouldn't be looking at the edition level.
• Listing works not in the public domain and no external links on the internet is suitable where an author page exists, but we generally would not be creating an author page where it will not be possible to host or link works

As said, editions are important to us, and we want it to be one of our points of difference. Verifiability in editions and proofreading are important to us. It does mean that we will throw out some things, though we will do it with eyes wide open approach, and focus on copyright, editions, verification, and quality.

We are well aware of Gutenberg. It does not holistically guide the community on what works we do, though it may guide individuals' choices. We accommodate its works where it aligns with our goals. Being part of WMF wikis allows a different focus and presentation, it allows more interlaced approach with Commons, Wikidata, Wikipedia, +++ and supports those wikis in their goals, and that often guides the choices that individuals make. — billinghurst sDrewth 23:29, 26 September 2020 (UTC)

Tech News: 2020-40

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Recent changes

• Admins can now see links to diffs of deleted revisions on Special:AbuseLog. This uses the interface of Special:Undelete. [12]
• Editors are automatically added to some user groups. For example editors are added to autoconfirmed users when they have edited enough times and long enough. Abuse filters can hinder users from automatically getting user rights for a period of time. They can also remove rights user have. Wikis can now ask to change how long this period of time is for their wiki in Phabricator. It is currently five days. [13]

Problems

• Last year some abuse filters stopped working because of a new change. If they tried to use variables that were unavailable for that action they would fail. This has now been fixed. [14]

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 29 September. It will be on non-Wikipedia wikis and some Wikipedias from 30 September. It will be on all wikis from 1 October (calendar).

Future changes

• You can't see the language links to other language versions from the talk page or history page. They are also not shown when you edit an article. This could change. It is not decided if for example the history page should link to another history page or to the article. You can take part in the discussion in Phabricator.
• The link colours could change. This is to make the difference between links and other text more clear. You can read more in Phabricator.
• In your preferences you can choose to get different notifications on the web or by email. You will see Apps as one of the alternatives later this week. This is because the Android and iOS Wikipedia apps will use push notifications for those who want them. You can see the preferences on the test wiki. The goal is to have push notifications on Android in October and on iOS in early 2021. [15]
• You can soon put pages on your watchlist for a limited time. This could be useful if you want to watch something for a shorter time but don't want it on your watchlist forever. It now works on mediawiki.org and will come to more wikis later. You can read more and see when it will come to other wikis.
• You can see what Wikimedians think are the best new technical tools this year. You can also nominate them.

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

21:24, 28 September 2020 (UTC)

Paragraph breaks in footnotes not rendered

As can currently be seen in this page, paragraph breaks in footnotes are not rendered. Is this a bug? Is there a preferred work-around? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:39, 25 September 2020 (UTC)

Stick some <p> in place. The MW designers consider a reference to be a single paragraph, we have to tell it different. — billinghurst sDrewth 13:22, 25 September 2020 (UTC)

Using {{pbr}} is better (see comments in the docs of that template about screen readers). Jarnsax (talk) 15:18, 25 September 2020 (UTC)

{{pbr}} is fine in normal sized text, but in a smallrefs list using it leaves too much space between the paragraphs. Beeswaxcandle (talk) 18:47, 25 September 2020 (UTC)

Can we add an optional parameter to {{pbr}} that will allow us to use a more fitting custom margin?—Zhaladshar ^(Talk) 19:24, 25 September 2020 (UTC)

That says: "This template is used mostly in footnotes, where a visual break is desired, without adding an additional paragraph navigation point. " - the footnote in question has two paragraphs. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:33, 25 September 2020 (UTC)

Into itwikisource, I use commonly a <br> tag followed by a new line and a {{gap}}, so saving the mediawiki idea "footnotes contain only one paragraph" and avoiding that unpleasant block spacing.

A general comment: I feel that block spacing between paragraphs should be removed from wikisource settings, since it's very uncommon into printed sources, while default paragraph indentation should be used for the same reason. Is it simply a "wikipedia remnant"? --Alex brollo bis (talk) 05:40, 28 September 2020 (UTC)

Printed sources are very worried about paper usage. Even if we were worried about every byte, \t\n takes up the same amount of space as \n\n. That extra space is supposed to make works easier to read, and the Washington Post, the Library of Congress, the British Library, and the London Times all use that same format online. We're not making print replicas, so there's no reason to mess with an Internet standard.--Prosfilaes (talk) 06:23, 28 September 2020 (UTC)

(ec) The community has long considered that we are not trying to mimic printed books, so we don't indent paragraphs. The paragraph break and space is totally suitable and lends uniformity to our works. We don't have to worry about white space and the cost of paper! We don't have to worry about centering images of pages and breaking up a paragraph when we transclude and concatenate pages, we can move an image to end of a paragraph. — billinghurst sDrewth 06:36, 28 September 2020 (UTC)

Back from the digression, what actually caused me to comment here was that I was just working on Hayburn's Case (migrating it from an unsourced text to the actual book scan) and.... lets just say getting that to work correctly was nuts, the footnote spans five pages, and a subsequent section... {{pbr}}, and lots of sections, was the only way I could figure out to make it work. Jarnsax (talk) 20:56, 29 September 2020 (UTC)

Wiki of functions naming contest

Please help translate to your language.

Hello. Please help pick a name for the new Wikimedia wiki project. This project will be a wiki where the community can work together on a library of functions. The community can create new functions, read about them, discuss them, and share them. Some of these functions will be used to help create language-independent Wikipedia articles that can be displayed in any language, as part of the Abstract Wikipedia project. But functions will also be usable in many other situations.

There will be two rounds of voting, each followed by legal review of candidates, with voting beginning on 29 September and 27 October. Our goal is to have a final project name selected on 8 December. If you would like to participate, then please learn more and vote now at meta-wiki. Thank you! --Quiddity (WMF)

21:13, 29 September 2020 (UTC)

Index:UNTS 1.pdf→Index:UN Treaty Series - vol 1.pdf and related pages/transclusions

This hideously short file name should be lengthened only if someone makes a bot to quickly move everything and coordinates with Commons where the renaming has been reverted pending any viable way to quickly move everything.--Jusjih (talk) 23:49, 25 September 2020 (UTC)

Done. Mpaa (talk) 09:46, 4 October 2020 (UTC)

m:Requests for comment/Global ban for Slowking4

Naleksuh (talk) 01:58, 30 September 2020 (UTC)

This notification has been moved from WS:AN to here as it should sit before the whole community not just in front of administrators. — billinghurst sDrewth 05:46, 30 September 2020 (UTC)

I noticed this too, on Wikimedia Commons this notification also wasn't posted to the village pump and the requesting user seems to conflate "administrators" with "the community". I'd oppose it if I was allowed to, I'm not sure if there is any use to verbalising that here. But is it standard procedure to only notify administrators' noticeboards? -- DonTrung (徵國單)  (討論 🤙🏻) (方孔錢 ☯) 10:35, 1 October 2020 (UTC)

that is a tell, that the user is probably a socking admin, who privileges the input of admins not editors. you asked years ago, why i did not go over to simple, and this incident is why. Slowking4 ⚔ Rama's revenge 15:01, 2 October 2020 (UTC)

For the record: This discussion was closed yesterday at meta as "No consensus". Inductiveload—talk/contribs 10:28, 16 October 2020 (UTC)

This section was archived on a request by: — billinghurst sDrewth 11:08, 29 October 2020 (UTC)

Index:United Nations Treaties and international agreements registered - Volume 221 (13 November 1955 - 30 November 1955).pdf→Index:UN Treaty Series - vol 221.pdf and related pages/transclusions

This hideously long file name should be shortened only if someone makes a bot to quickly move everything and coordinates with Commons where the renaming has been declined pending any viable way to quickly move everything.--Jusjih (talk) 23:49, 25 September 2020 (UTC)

I have done the moves at WS but need someone with admin rights at Commons to move the file. Mpaa (talk) 20:13, 4 October 2020 (UTC)

I as an admin on Commons just renamed the file. Thanks so much for your effort.--Jusjih (talk) 00:34, 5 October 2020 (UTC)

This section was archived on a request by: — billinghurst sDrewth 11:10, 29 October 2020 (UTC)