Wikisource:Scriptorium/Archives/2018-06

Other discussions

Introducing Toolhub

What does your participation on the Wikimedia projects look like? Do you edit articles? Upload files? Patrol vandalism? Translate articles? Translate interface messages? Do you organize people, online or offline? Do you train new editors, or new trainers? Do you write code?

There are many different ways to contribute to Wikimedia – more than you would expect just from reading Wikipedia articles. Over the past several years, volunteers have developed technical tools that help Wikimedians improve content, patrol vandalism, and perform many other tasks. They make it possible to do what the wiki software alone cannot accomplish. Without these tools, many of our projects would slow down to a crawl.

I am very happy to announce a new project called Toolhub which seeks to create a searchable index of these tools in all languages. We are building this tool catalog based on what our communities need. If you would like to help, please take a look at m:Toolhub and review the question at the top of the page. You can also leave feedback in any language on the talkpage. You can also email me private feedback. Harej (WMF) (talk) 00:21, 3 June 2018 (UTC)

Anchor points in How To Adjust Spirella corsets.

On page 9 the previous editor has attempted to create links to anchor points to three illustrations within the main text, however they do not appear to work.

Unfortunately I don't understand anchor points so I am unable to correct these.

Would somebody be able to take a look and correct these for me?

Thanks Sp1nd01 (talk) 10:17, 3 June 2018 (UTC)

@Sp1nd01: Clash of anchors. Our page numbers have anchors, and the style used in the figures was the same, so the link was finding the first rendering. I have changed both the links and the targets to be "figure1", "figure2", "figure3", so those are fixed. Can I leave you with the remainder? — billinghurst sDrewth 11:20, 3 June 2018 (UTC)

Yes, now I understand what was wrong I'll continue my work. Thanks for the quick fix! Sp1nd01 (talk) 11:50, 3 June 2018 (UTC)

Tech News: 2018-23

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

• The MonoBook skin has been optimised for mobile devices. It now looks different. [1]
• Planet Wikimedia collects blogs about Wikimedia. It will now use the Rawdog feed aggregator to do this instead of Planet. [2][3]
• Redirect links in Special:WhatLinksHere now link to the original page and not the target page. This was done earlier and changed the used messages on some pages. This was a problem for wikis that customized the message. A new change fixed this by using the old messages with one more parameter for customization. Wikis that already changed their customized messages will have to move the customization back again. [4]

Problems

• You will not be able to edit some wikis between 06:00 and 06:30 UTC on 13 June. You can see if your wiki is one of them.
• MassMessage did not work 24–28 May. This is also why last week's Tech News was late. [5]

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 5 June. It will be on non-Wikipedia wikis and some Wikipedias from 6 June. It will be on all wikis from 7 June (calendar).

Meetings

• You can join the next meeting with the Editing team. During the meeting, you can tell developers which bugs you think are the most important. The meeting will be on 5 June at 18:30 (UTC). See how to join.
• You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 6 June at 15:00 (UTC). See how to join.

Future changes

• The new filters for edit review tools and interface for watchlists will leave beta. This is planned to happen in June or early July. [6][7]

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

21:54, 4 June 2018 (UTC)

Tools for Wikipedians: Keeping track of what’s going on on Wikidata from Wikipedia

This article by Jens Ohlig may be of interest to some Wikisourcers

• https://blog.wikimedia.de/2018/06/01/tools-for-wikipedians-keeping-track-of-whats-going-on-on-wikidata-from-wikipedia-2/

It has some pertinence for our editing, and as it is a blog there is the opportunity for direct feedback opportunity if you would like different articles or approaches for sister wikis. — billinghurst sDrewth 00:22, 5 June 2018 (UTC)

{{double link}} across pages

Can I have a {{double link}} that's broken across pages work properly? Adding the template separately to the parts of the link before and after the pagebreak results in only half of the text being underlined when hovering, and the space between the two parts not belonging to any of the links. Jellby (talk) 18:44, 4 June 2018 (UTC)

@Jellby: Can I say that I would simply not use that template, it is approaching ridiculous to do so; that adds complexity for no real value. Please don't try to add page: ns to page: ns wikilinks. They are of next to no value, only create work, and in terms of transclusions just add underlying gumph. — billinghurst sDrewth 22:04, 4 June 2018 (UTC)

I would suggest that the parts that you want to link that you put them into the footer. On the subsequent page just do something like {{hwe|aftertext|[[beforetext aftertext]]}}. It does not create a hyperlink in the Page: ns but who cares, it creates one in the transcluded work. Pure and simple and how I do such works like DNB where we regularly have authors and internal links split. — billinghurst sDrewth 22:04, 4 June 2018 (UTC)

This is what {{lps}} and {{lpe}} are for [Linked Phrase Start and Linked Phrase End], rather than fudging hwe. Beeswaxcandle (talk) 07:05, 5 June 2018 (UTC)

The "start" components, which are a hack from before footer availability, maybe are useful for helping newbies, are otherwise useless. The LPS/LPE pair are just painful, overly complex templates with not the benefit on the other side of the use, and I suspect just deter users through more complication for no special benefit. We could have just done the same thing with noinclude and includeonly tags. — billinghurst sDrewth 10:49, 5 June 2018 (UTC)

Image problems when editing

Esme Shepherd (talk) 10:14, 5 June 2018 (UTC) I am experiencing image distortions when editing. These correct if I select 'show preview' but are nevertheless annoying. The issues are: 1. Image appears very squashed horizontally thus rendering it unreadable. 2. Image appears extremely enlarged, so that only a little of it can be seen.

This has been going on for some days and doesn't seem likely to go away without intervention. Can you help?

RfC: Plans to graduate the New Filters on Watchlist out of beta

Collaboration team is announcing plans to graduate the New Filters for Edit Review out of beta on Watchlist by late June or early July. After launch, this suite of improved edit-search tools will be standard on all wikis. Individuals who prefer the existing Watchlist interface will be able to opt out by means of a new preference.

The New Filters introduce an easier yet more powerful user interface to Watchlist as well as a whole list of filters and other tools that make reviewing edits more efficient, including live page updating, user-defined highlighting,the ability to create special-purpose filter sets and save them for re-use and (on wikis with ORES enabled) predictive filters powered by machine learning. If you’re not familiar with the New Filters, please give them a try on Watchlist by activating the New Filters beta feature. In particular, it would be very helpful if you can test the new functionality with your local gadgets and configurations. The documentation pages provide guidance on how to use the many new tools you’ll discover.

Over 70,000 people have activated the New Filters beta, which has been in testing on Watchlist for more than eight months. We feel confident that the features are stable and effective, but if you have thoughts about these tools or the beta graduation, please let us know on the project talk page. In particular, tell us if you know of a special incompatibility or other issue that makes the New Filters problematic on your wiki. We’ll examine the blocker and may delay release on your wiki until the issue can be addressed. - -Kaartic (talk) 17:31, 5 June 2018 (UTC)

Paged layouts that laternate between right and left...

As many contributors are aware there are plenty of works that have layout which alternates between left and right shifted elements for items like sidenotes, line numbering, or section markers amonst other things...

Whilst there are versions of (some templates that take into account this left/right split and transclude cleanly) I am wondering in the interest of reducing complexity if there was a wider consensus for the sake of simpler markup and approaches if for some works this left/right split was in effect ignored and the relevant work was written as though it has one consistent layout throughout, the scans notwithstanding. This would for example make the transcriptions of some works easier to maintain longer term, and would hopefully reduce the complexity of some templates as a common layout could be assumed on each page. This was the approach I was considering on a fairly extensive work with so termed side-titles given certain interactions between templates. (Specfically interactions between multiple {{MarginNote}} and {{di}} i found in some test cases here User:ShakespeareFan00/Sidenotes testing with some contrived soloutions I'm unhappy with long term.).

It is my view if theres's a guideline to ignore paged layouts in scans, it should ideally be a consensus view, and documented.

ShakespeareFan00 (talk) 00:56, 6 June 2018 (UTC)

Lillypond scoring

Fixed (after some experimenting...) 198.84.253.202 04:08, 8 June 2018 (UTC)

In relation to Page:The Army and Navy Hymnal.djvu/32 someone indicated that notwithstanding it's validated status, that it was badly formatted.

Lillypond coding isn't my strong point, so I am asking if anyone else could have a look. ( I will be reviewing my validation of items on this work, as it seems it will need a second look given the complexities of using the markup for scoring...) ShakespeareFan00 (talk) 19:44, 7 June 2018 (UTC)

Statutes of the Realm

Is anyone with a HathiTrust partner membership able to grab these 12 volumes of the Statutes of the Realm and upload them to Commons? —Beleg Tâl (talk) 11:51, 9 June 2018 (UTC)

æ

Is there a problem with me changing the template {{ae}} and kin to use the html/xml æ (æ) rather than the non-ascii æ? --RaboKarbakian (talk) 19:02, 10 June 2018 (UTC)

Why would you want to do that? Wikimedia uses Unicode; I'd say that æ should be used instead of {{ae}}, but {{ae}} is easier for some people, I guess. There's no need to obfuscate it further by using æ instead of æ.--Prosfilaes (talk) 19:07, 10 June 2018 (UTC)

Portability. I think it is cool that a book can be downloaded here for ereaders. The only advantage is portability. {{dq}} uses “ and ” which made me assume the same for {{ae}}.--RaboKarbakian (talk) 20:03, 10 June 2018 (UTC)

These pages are in Unicode, and most ereaders can handle Unicode. The exporter needs to fix things if there's one that can't. If there's a real problem with a real ereader, it can be fixed, but changing one template isn't going to do anything about all the non-ASCII stuff we have throughout the system.--Prosfilaes (talk) 04:04, 11 June 2018 (UTC)

•  Comment {{dq}} should be deleted as it is outside our style guidance.

Please see Wikisource:Style guide and where you need to deviate please have an exceptional reason for doing that beyond what others would consider personal preference. We keep things simple so that proofreading is available to all and reproducible, not a speciality skill, wherever possible. Noting thatnumbers of bots will replace that code back to the unicode. Feel free to "subst:" the ligature template to have it put the hard character in place. — billinghurst sDrewth 11:34, 11 June 2018 (UTC)

Two things. 1. {{dq}} can be altered to match the style guide (and perhaps should have been if there is such a problem with it). and 2. An apologetic explanation where I divulge the enormous number of discussions I have encountered or participated in which determined that it is always better to let the rendering software make the non-ascii decisions (but I have not yet written this apologetic exp....)--RaboKarbakian (talk) 14:09, 11 June 2018 (UTC)

Problem with page display

I've added an old book in Persian to the commons (here is the file in commons and here is its index in fawiki). It’s resolution is so high that mediawiki can not display its pages. I tried different methods to compress it but I failed. Is there anyway to solve the problem? --Yousef (talk) 20:18, 10 June 2018 (UTC)

@Yoosef Pooranvary: It seems to be a problem with the rendering of the thumbnails, as I cannot get them at file:Montazem Naseri.pdf either. It may be the file, or it may be the rendering. I would start at c:Com:VP and see if you can get some help, and if that fails, then try a phabricator ticket. I am presuming that you can see the pdf file properly through other means. Alternately, try uploading it to archive.org, then pull back as a djvu using toollabs:ia-upload — billinghurst sDrewth 11:24, 11 June 2018 (UTC)

@Yoosef Pooranvary: Done -- please check. The problem with the file was high compression, beyond the handling competence of mediawiki software. I decompressed it, and now it displays properly, at least in my browser. Hrishikes (talk) 13:26, 11 June 2018 (UTC)

@Hrishikes: It would be worthwhile noting that with a phabricator ticket for the thumbnail/rendering. Capturing as much information as possible into the ticket is useful, and also your alternate solution. Having them in phabricator, with alternate solutions helps others until the issue is addressed. — billinghurst sDrewth 23:06, 11 June 2018 (UTC)

@Billinghurst: -- phab:T196961. Please amend as needed. -- Hrishikes (talk) 01:23, 12 June 2018 (UTC)

Okay why is the header sometimes "bouncing" to the bottom?

Broadcasting Act 1981 (United Kingdom)/Schedule7

I've looked through the code and can't find anything that's obviously misaligning it? Suggestions are welcome, as I've had this with other pages as well.ShakespeareFan00 (talk) 23:46, 10 June 2018 (UTC)

Guessing that you have the lint javascript activated. It doesn't play well in our main ns with the way that header is coded. — billinghurst sDrewth 11:41, 11 June 2018 (UTC)

That was one of my culprits, and I've left a note for the scripts maintainers ("upstreaming" the concern so to speak to borrow a term from other projects)ShakespeareFan00 (talk) 14:50, 11 June 2018 (UTC)

Formatting UK legislation..

Having reworked some of my contributions in this area, I was going to ask if someone has a style manual for formatting UK legislation? This is likely to either be an official document, or notes to printers in some older work.

Exact reproduction will not be possible (due to Mediawiki) limitations of course.ShakespeareFan00 (talk) 09:45, 11 June 2018 (UTC)

Page status buttons

It looks as though page status buttons have been modified once again! No longer do they resemble easter eggs, but are now perfectly rounded. I would make further changes to affected help pages such as Help:Page status again, but I think it is close enough to leave as is, if others are in agreement. Londonjackbooks (talk) 19:52, 11 June 2018 (UTC)

{{Rule}} not centering?

Is rule no longer automatically centering? [8] A previous page proofread on another day formatted the same way is still centered [9] Londonjackbooks (talk) 20:34, 11 June 2018 (UTC)

Here you go. BethNaught (talk) 20:40, 11 June 2018 (UTC)

Ugh. Time for bed. Thanks :) Londonjackbooks (talk) 20:42, 11 June 2018 (UTC)

Silver lining...now I know how to handle those pesky rules from the left side that so often precede a footnote section. Something I've been meaning to look into for ages. Thanks, and goodnight! :) -Pete (talk) 21:46, 11 June 2018 (UTC)

Tech News: 2018-24

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

• In the Wikipedia app for Android or iOS users can create reading lists. The reading lists can be seen on different devices if you are logged in to your account. There is now a browser extension so you can add pages to your reading list from a web browser. At the moment it works with Firefox and Chrome. [10]
• There is a new version of Pywikibot. Pywikibot is a tool to automate tasks on MediaWiki wikis. [11]

Problems

• The MonoBook skin was changed to make it work better for mobile users. This caused some problems. The change was rolled back to fix them. The new version is now back on the wikis. MonoBook users can opt out from the new responsive design. [12]

Changes later this week

• The new filters for edit review tools and interface for watchlists will leave beta. For most wikis this will happen on 18 June. For the rest it will happen on 25 June. [13][14]

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 12 June. It will be on non-Wikipedia wikis and some Wikipedias from 13 June. It will be on all wikis from 14 June (calendar).

Meetings

• You can join the Readers Web team IRC office hour. There you can discuss tools to contribute on the mobile web for the existing MediaWiki skins. The meeting will be on 18 June at 16:00 (UTC). See how to join.
• You can join the next meeting with the Editing team. During the meeting, you can tell developers which bugs you think are the most important. The meeting will be on 12 June at 18:30 (UTC). See how to join.
• You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 13 June at 15:00 (UTC). See how to join.

Future changes

• You will be able to move local wiki files to Commons and keep their original data intact. This is planned to come to the first wikis in June.

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

21:55, 11 June 2018 (UTC)

Statutes at large, a different approach...

No lengthy arguments needed but in deprecating a template (that was for technical limitations never ideal.), this was implemented Page:Ruffhead_-_The_Statutes_at_Large_-_vol_3.djvu/100, because it isn't possible to cleanly implement the original layout in web form . I will note that other than {{frame}} it's only using existing templates (or footnotes), not some over-complicated half-baked attempt to get it exactly like the print layout (a critical view from certain other contributors). Whilst the logical intent of the original is followed, given that "annotated" copies are generally disliked, I wanted a second opinon. ShakespeareFan00 (talk) 08:56, 7 June 2018 (UTC)

I think your layout does justice to the demanding, idiosyncratic formatting of the source text even if it doesn’t perfectly duplicate its visual appearance on the page. The marginalia serve their purpose as annotations to the original text whether they appear in sidenotes or at the bottom of the page, and I have a feeling that when multiple pages are transcluded together in the final version, the use of footnotes will make the finished product much easier to read. I find the box produced by the {{frame}} template a little distracting and I’m not sure it’s really unnecessary, although it does call attention to the presence of easy-to-overlook content that the reader might have been expecting to see in the sidenotes, which is at least somewhat beneficial. In time, I hope the annotations can be linked up with the content to which they are referring. Tarmstro99 13:18, 7 June 2018 (UTC)

Well I used {{frame}} as I wanted to box out the sidenotes from the run of the original text, it's style can be tweaked if needed. Cross referencing an entire work like this would be a BIG project, which you are welcome to attempt. (Noting of course that: Whereas many early Statutes, having been long since expired or been rendered void, as such have no official "Short-titles" applied for convenience of citation, and although various Acts have since subsequently applied official "short-titles" for the convenience of citation, many of the aforesaid statutes without short titles as included on English Wikisource, the said included Statutes have had unoffical short-titles applied on Wikisource for convenience, &c. ) you'd probably need a law student or academic specialist to have definitive titles. See the notes here for the official ones: User_talk:ShakespeareFan00/Archive1#Acts_that_confer_short_titles. ShakespeareFan00 (talk) 15:46, 7 June 2018 (UTC)

yeah, good work. i would go for a broad consensus for either going left sidenote or even ignoring sidenotes, and converting some to footnotes. if we get an end product with more readability, that is an improvement. while we strive to replicate the layout of the original, we should not be wedded to it, to the point of stopping progress as "too hard". Slowking4 ‽ SvG's revenge 14:58, 12 June 2018 (UTC)

FYI: Changes to numbers of "link" templates in author ns:

I have been migrating the suitable internal link templates to utilise Template:authority/link as the base, generally used for reference works. I think that I have captured all the quirks and variations that have occurred in the templates, though ask users to check the author ns: pages, when passing, to look for new irregularities in display. Any problems or suggestions for a particular template should be noted on the respective talk page of the template, and users can feel welcome to ping me. Similarly if you need templates developed for your reference work.

For suggestions for the base template, please note those at Template talk:authority/link. I still need a better way to notate in the documentation that there is a base template, and as templates are created for these reference-type works that the base template exists.

The migration to utilise a base template allows for consideration of additional fields to existing templates where considered pertinent, and further development of better standardised/coding. It should provide potential for better data extraction capability and manipulation due to being standardised.

Notes

• templates that only had positional parameters, will now also have named parameters for those fields
• templates utilise <onlyinclude> to tighten display components; the display generally shows minimum requirements of required parameters
• in changed templates the old code has been left and rem'd out—feel free to delete those components when comfortable that the job has been done successfully
• there is an extensive set of testcases in the base, and each template is documented for its uses and variations of parameters
• Template:authority/lkpl exists for the lkpl-type templates
• Template:article link does a similar job for periodicals.

To do

• Work out what to do with the DNB stuff, that is non-standard
• Continue to find those hand-coded references and run a bot through and convert them (if you have these, please list them at Wikisource:Bot requests)
• Templatedata should be added, and identified that much documentation can be improved

If there are any questions, fire away.— billinghurst sDrewth 23:32, 11 June 2018 (UTC)

I have based also {{CE lkpl}} on the lkpl base template (hopefully correctly). Not sure if it was skipped intentionally, so I report it here.— Mpaa (talk) 20:19, 12 June 2018 (UTC)

Update on page issues on mobile web

Update on page issues on mobile web

Please help translate to your language Hi everyone. The Readers web team has recently begun working on exposing issue templates on the mobile website. Currently, details about issues with page content are generally hidden on the mobile website. This leaves readers unaware of the reliability of the pages they are reading. The goal of this project is to improve awareness of particular issues within an article on the mobile web. We will do this by changing the visual styling of page issues.

So far, we have drafted a proposal on the design and implementation of the project. We were also able to run user testing on the proposed designs. The tests so far have positive results. Here is a quick summary of what we learned:

• The new treatment increases awareness of page issues among participants. This is true particularly when they are in a more evaluative/critical mode.
• Page issues make sense to readers and they understand how they work
• Readers care about page issues and consider them important
• Readers had overwhelmingly positive sentiments towards Wikipedia associated with learning about page issues

Our next step would be to start implementing these changes. We wanted to reach out to you for any concerns, thoughts, and suggestions you might have before beginning development. Please visit the project page where we have more information and mockups of how this may look. Please leave feedback on the talk page.

CKoerner (WMF) (talk) 20:58, 12 June 2018 (UTC)

"Short-titles" and related...

The review of internal link templates previously has been noted (in relation to Author pages), If there is a wider review of link templates underway I'd like to politely request that {{short-title}} and {{topic-link}} also get reviewed as part of this.

{{Short-title}} in it's current form will not scale well, and currently would be unable to cope with disambigs between short-titles used to distinguish between otherwise identically titled works in different jurisdictions. It was however converted to a Lua module which may make it easier to maintain.

The issue of short-titles is not just about the template however, given that Wikisource seems to be use a combination of both "official" short titles (directly mentioned in legislation.), widley known but not necessarily official 'short-titles' based on a long-title or widely used name/title, and unofficial short-titles seemingly derived from subject descriptions in Chornological Tables.

To the extent that it's ever possible to have one standard on Wikisource, it would be nice to have ONE standard, and be able to tweak any relevant templates/module to that standard so that as new Acts get transcribed redlinks turn blue without additional effort. On the other hand I am more than willing to throw the whole thing out and hard-code relevant links, which would be simpler, but create more effort when "missing" items in redlinks were added.

{{topic-link}} is not widely used outside one highly specfic work. It was originally written with works that in print are essentialy a specialist index with page numbers. In main space the transclusions would be to anchors in an article page, whereas in Page namespace: they would either suppress of be references to other pages. It could be argued that the template is too complex, and should be abandoned in favour of coding only for mainspace use, suppressing in the Page: and other namespaces.

Given past concerns, I felt these issues needed a wider discussion. ShakespeareFan00 (talk) 13:02, 13 June 2018 (UTC)

Two very similar disambigs: Moon & the Moon

Too tired to be reasonable in my decision making. Would someone be kind enough to look at and resolve Moon and The Moon. We did have an earlier discussion that we would look to not have such similar disambiguation pages. Thanks if someone can. — billinghurst sDrewth 15:42, 13 June 2018 (UTC)

I've merged the two.--Prosfilaes (talk) 20:06, 13 June 2018 (UTC)

Agree. FWIW, I believe the result of the previous discussion was to not have separate disambiguation pages where the only difference was "A", "An", or "The" in the title, although lengthy lists might be subdivided. In this situation it's certainly a short list and not worth keeping them separate. --EncycloPetey (talk) 22:18, 13 June 2018 (UTC)

A Lost Lady

I cannot remember which person here was compiling a list of works which will enter PD in the US next year. Please remind me who you are!

Also, please add A Lost Lady (1923) by Willa Cather to your list of such works. --EncycloPetey (talk) 21:47, 14 June 2018 (UTC)

I've got the list at Wikisource:Requested texts/1923. A Lost Lady is on the part of the list copied from w:1923 in literature.--Prosfilaes (talk) 21:56, 14 June 2018 (UTC)

@Prosfilaes: Thanks. I've added a play translation by Murray, a novel by Edith Wharton, and a collection of poetry by E. E. Cummmings. --EncycloPetey (talk) 23:08, 14 June 2018 (UTC)

A little off topic but we/I do this every year at bibliowiki:. E.g. bibliowiki:Bibliowiki:1968 deaths, therefore now in the Public Domain. If the mystery user wants to work together on PD issues at en.ws and bw, that would be great. —Justin (koavf)❤T☮C☺M☯ 21:52, 14 June 2018 (UTC)

I'm in the US, so I'm going to put most of my time into 1923 works.--Prosfilaes (talk) 21:56, 14 June 2018 (UTC)

@Prosfilaes: Great. You're probably familiar with this already but in case you aren't, Public Domain Review publishes a "Class of [Year]" every December. E.g. https://publicdomainreview.org/collections/class-of-2018/ —Justin (koavf)❤T☮C☺M☯ 22:03, 14 June 2018 (UTC)

This is a little bit of a bigger deal in the US than elsewhere, since the PD cutoff has been frozen at pre-1923 for a very long time. In January 2019, that will advance to pre-1924, which is the first cutoff advance in the US in a very long time. One consequence of the frozen cutoff is that works published in 1923 generally aren't available through Gutenburg, IA, Hathi, etc., except in cases where a work can be "checked out". I'm assuming you're in Canada, so you might be able to help us get a head start scanning the works of Willa Cather, who died in 1947, so that all her works went into PD for most countries outside the US at the beginning of 2018. However, because she is an American author, many of her works have not been scanned. A Lost Lady is a novel for which there is no scan available in IA. --EncycloPetey (talk) 22:33, 14 June 2018 (UTC)

@EncycloPetey: Oh yes, it is a huge deal in the States. I'm kind of surprised Disney didn't swoop in and buy some legislators yet to extend it, tho we're trying with the century+ copyrites on music proposed. —Justin (koavf)❤T☮C☺M☯ 23:04, 14 June 2018 (UTC)

A Lost Lady is available in Gutenberg (1) and HathiTrust (2, 3, 4), although the scans are currently locked. Hrishikes (talk) 01:49, 15 June 2018 (UTC)

We'll have to wait until sometime next year to see whether the scans at Hathi are of good quality, and to determine which edition they are. Gutenburg texts too often have editorial issues for me to trust them anymore. I'd rather see a high-quality scan made fresh from a first edition, if we can get one. --EncycloPetey (talk) 02:41, 15 June 2018 (UTC)

Author:Sylvanus Urban, he was and he wasn't; disambiguate? portal?

Sylvanus Urban was for 100+ years the editor/publisher/writer of The Gentleman's Magazine. We are right that it was initially Author:Edward Cave though as he died mid 18th century, it is doubtful that he was still writing "Table Talk" in The Gentleman's Magazine/Volume 271. As it became an eponymous for the editor, we can disambiguate it and point to all the editors by years, or we can convert it to a portal. I am favouring the disambiguation, though think that a collective opinion may be better. — billinghurst sDrewth 13:58, 16 June 2018 (UTC)

EnWS should unlock Mein Kampf and My Struggle.

"Existing translation identified as being copyright until 2039 in United States." does not justify this protection. Everyone in Wikimedian could translate Mein Kampf. Moreover, It's dubious that Muphy's translation is copyrighed in United States. —Preceding unsigned comment added by 2001:2d8:e070:a11d::9ee:90a5 (talk)

Please see Wikisource:Translations, which states our policy regarding Wikisource created translations. One requirement is that "A scan supported original language work must be present on the appropriate language wiki, where the original language version is complete at least as far as the English translation". Since there is no German-language original backed by a scan on the German WS, a user-created translation is not currently within our scope. --EncycloPetey (talk) 18:08, 16 June 2018 (UTC)

It's noexitence in German wikisource is due to cencorship law of Germany. Wikimedia oppose censorship. THERES A PDF VERSION OF GERMAN LANGUAGE VERSION OF MEIN KAMPF.—Preceding unsigned comment added by 2001:2d8:e070:a11d::9ee:90a5 (talk)

I don't see any reason why Murphy's translation would be out of copyright in the US. I'm not really sure what the copyright status of Mein Kampf is in the US; it has a renewal, though questionably timely, and whether or not Houghton Mifflin had the right to file for renewal? It will be moot in a few years, as a work published in 1925/1926. If agreed to be PD and published on wikisource.org, which will publish US PD works the German Wikisource won't, we could start a translation here. But translations aren't nearly as trivial as you suggest, and I don't know of a successful Wikisource translation of a work this long, and this one looks to be a mess.--Prosfilaes (talk) 22:28, 16 June 2018 (UTC)

•  Comment Our main namespace is for published works, and there is no public-domain, published English-language version. It's continual re-creation meant that the pages were locked. — billinghurst sDrewth 22:29, 18 June 2018 (UTC)

Excerpting stories from long subpages

I'm working on Italian Popular Tales, a project that had been mostly stalled since 2012. The bulk of the work is translations of folktales, interspersed with commentary, followed by endnotes (some of which are very long, including one or more numbered tales themselves). There seems to be about a dozen of these tales that have articles devoted to them on Wikipedia, on one of which I've placed a link back to the text here: w:Thirteenth (fairy tale). As you can see the link is to an anchor in the middle of a very long subpage. My question is, would it be advisable to make supplementary transclusions for individual tales that would be easier to link to from Wikipedia and could be entered into Wikidata? Or should the long subpages simply be broken up? Or should translations pages or redirects be used? I would greatly appreciate any advice. — Mudbringer (talk) 05:10, 18 June 2018 (UTC)

I would not make supplementary transclusions. I would either use anchors as currently used, or break up the subpages into sub-subpages, using {{AuxTOC}} as necessary (example). If each tale can be considered a work per se, and it seems like they can be in this case, then I would encourage creating translation pages or redirects regardless. —Beleg Tâl (talk) 10:37, 18 June 2018 (UTC)

@Beleg Tâl: thanks for the suggestions. Splitting into sub-subpages would be of limited usefulness since many of the stories are in the endnotes, sometimes more than one story in a single endnote. I've made a translations page for Thirteenth and recorded that in Wikidata. So now I'd like to ask, should links from the Author page (in this case Author:Giuseppe Pitrè) and the Wikipedia pages preferably go to this translations page, or straight to the location on the book's subpage? Also, I linked the title of the tale on the book's subpage to the translations page, which seemed to be the most obvious pathway to the related Wikipedia and Author pages. I'll need to put a note in the header explaining what the links are for. — Mudbringer (talk) 12:01, 18 June 2018 (UTC)

A {{translations}} page has typically been to disambiguate multiple works, so historically we would not have created such a page and listed one item. [That said that practice/approach eventuated prior to WD when we have coordinated interwikis, and to where we would indeed place the interwiki for the conceptual item.] In the examples that you provide, if we are not going to separate transclusions, I think that this methodology is the means to find the balance. — billinghurst sDrewth 22:22, 18 June 2018 (UTC)

Tech News: 2018-25

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

• Syntax highlighting has been a beta feature on Wikimedia wikis with text written from left to right. It is now a normal feature. It is based on CodeMirror. [15]

Changes later this week

• There is no new MediaWiki version this week.

Meetings

• You can join the next meeting with the Editing team. During the meeting, you can tell developers which bugs you think are the most important. The meeting will be on 19 June at 18:30 (UTC). See how to join.
• You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 20 June at 15:00 (UTC). See how to join.

Future changes

• Some old web browsers will not be able to read the Wikimedia wikis. This is because they use an insecure way to connect to them. This means that we get less security for everyone else too. This affects about 0.08% of all traffic to the Wikimedia wikis. This affects for example those who read Wikipedia on a PlayStation 3. [16][17]
• The new filters for edit review tools and interface for watchlists will leave beta. Because there is no new MediaWiki version this week it will happen on 25 June for most wikis. For the rest it will happen in early July. [18][19]
• All wikis that have not already done so will switch to use the Remex parsing library on 5 July. This is to replace Tidy. You can help fix remaining errors. [20]

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

21:47, 18 June 2018 (UTC)

Template:Plain sister and bibliowiki

I have updated Wikilivres visual presentation through {{plain sister}} (template and module) to now be Bibliowiki. I think that I got it working fine, please report any problems back here and ping me. Thanks. I think that completes the presentation space. There are still mentions in templates, and editors should feel comfortable in changing parameters to use bibliowiki, and again if any problems, please report back here. — billinghurst sDrewth 03:22, 19 June 2018 (UTC)

Lint filter fix for float right, somewhat counter-intuitive—others check/replicate?

I think that I have found the solution to {{float right}} pages showing up in the lint filter. Starting the span containing "float right" at the start of the paragraph, before all the text to which it will float, and it seems to resolve from my couple of trials. If others confirm that is the case, then we can have another tick for our resolution processes. — billinghurst sDrewth 10:55, 19 June 2018 (UTC)

@Billinghurst: Could you provide some specific examples of what you're describing. I don't follow what you're saying, and believe it might be at odds with situations where float right needs to be at the end of a paragraph for dramatic works. --EncycloPetey (talk) 15:24, 19 June 2018 (UTC)

"New texts" -- reasons

I think there's a great deal of thought that goes into the decisions we make about what works to transcribe, but it's largely invisible, both to us Wikisource editors and to the world at large. I imagine that reasons might vary from "my dad loved this book, and I always wondered why" to "I think it's important to civilization that more people read this essay" to "this poet's style is mostly forgotten" to "this is a horrible and misunderstood piece of propaganda, and I think everybody should have the chance to evaluate it themselves."

I'm curious if others might like to see a few words -- or perhaps a field for a link to a page in user space -- under the "new texts" section. Perhaps an optional field.

Do others share this curiosity about our fellow editors' reasoning? Are there other ways we could make it more apparent to our readers or one another? Apart from technical requirements or layout considerations, what do you all think of finding a way to make this more visible? -Pete (talk) 22:21, 19 June 2018 (UTC)

This sounds to me more like something to be printed in a newsletter than something to be linked in the New Texts. --EncycloPetey (talk) 00:49, 20 June 2018 (UTC)

There appears to be some form of discussion at Template talk:New texts. I think OP was pointing towards something more akin to the kind of process used on the WP main page, for example the Did you know section. Whether we should copy that (or do something even remotely similar) is of course debatable, but that particular example is in itself a "rough starting point", since the purpose of both pages/templates seems to be "To showcase new and improved content, illustrating to readers the continuous improvement and expansion of Wikipedia's [or in our case, Wikisource's] corpus of articles [...];". 198.84.253.202 03:24, 20 June 2018 (UTC)

Edit size/'wrong diffs"?

Can anybody explain what this is? The only change I actually did was add the </poem> tag which was missing at the end. Yet, for some reason, the page history shows a change of -114 bytes, and the diff of course shows the addition of quotation marks (") around the section begin and section end tags, which oddly enough are not even on the page, there's simply a ## hymnal85 ## at the top. 198.84.253.202 03:13, 20 June 2018 (UTC)

The hashtags are the "wiki-friendly" display form for a section start. The sudden drop in page size may reflect some hiccup from the last time the page was edited. From time to time the system seems to vastly overestimate the size of a page, and a subsequent edit returns the size to its correct value. --EncycloPetey (talk) 03:39, 20 June 2018 (UTC)

My guess is that the website back end software (MediaWiki) changed how they calculate the length of pages since 2013, and editing old pages that uses the header/body/footer format will cause the incorrect size difference. And the additional quotes is probably how MediaWiki wants to represent the section tags now which isn't visible on the edit page except through the hashtags. So 198.84.253.202, it's nothing to worry about, you didn't remove any text. --Riley AJ (talk) 04:09, 20 June 2018 (UTC)

I wasn't worried, just curious. By my (short) investigation, the earliest edit which I can confirm beyond all doubt has this kind of page size change is from December 2013 (-116 bytes), while the latest edits I can find which don't have it are from September 2013 (+82 bytes). Of course, that is from a very small sample (with only sporadic activity). I haven't bothered to check further to see if the date can be pinpointed more accurately. A browse through the archives looking for "size" does not yield anything about this between October and December of that year. Overall, a minor change which seems to have been mostly unnoticed. 198.84.253.202 05:02, 20 June 2018 (UTC)

Changes in how proofread page operates means that some code that was there is redundant and was removed with that edit. — billinghurst sDrewth 07:56, 20 June 2018 (UTC)

Page status issues

Tracked in PhabricatorTask T198470

I seem to be experiencing issues when viewing the page status in most indexes. As far as I can tell the issue began for me yesterday.

Many pages are not displaying any colours at all or are only showing the correct status on some of the pages.

I have done a hard purge and a standard purge of the pages numerous times as well as reboot, and I also see the issue using an alternate browser. (I use Firefox and Edge) I even dual booted into Ubuntu and see the same issue.

e.g. a project I am working on with the issue is Index:Life with the Esquimaux - 1864 - Volume 2.djvu

Is anyone else seeing the issue? or can provide any help on how to resolve this?

Thanks Sp1nd01 (talk) 08:55, 29 June 2018 (UTC)

Yes, it happens randomly to me on various Index pages. I just do a Null-edit (alt-shift-0 on Firefox) and it displays properly. Beeswaxcandle (talk) 09:45, 29 June 2018 (UTC)

this has been going on a while Wikisource:Scriptorium/Archives/2009-12#Stale_page_link_coloring_on_index_page? could not find a phabricator ticket. i've turned on Adds a "*" tab or a "Purge" option gadget for a null edit tab. Slowking4 ‽ SvG's revenge 11:01, 29 June 2018 (UTC)

Thanks, the null edit does reset the status for each individual page, but not when I try it on the main Index (The overall status page view). I guess I have to Null edit the whole set of missing status files to clear that issue.

I also noticed in the page activity following a null edit that it is showing quite a large diff, although it reports no change. i.e. Page:Life with the Esquimaux - 1864 - Volume 2.djvu/44‎; 10:56 . . (-119)‎ - Is that anything I should be concerned about?

Appologies, I wasn't aware this was a long ongoing issue, it just seemed to start for me yesterday, its been fine for the year or so I've been editing here. It's not a major issue for me, I can work round it now, thank you for the help and info. Sp1nd01 (talk) 11:24, 29 June 2018 (UTC)

I've noticed it today too (my last activity was the 21st, and I didn't notice it then). To be clear: I've been experiencing all pages displaying without status for a long time, but it was solved with a purge on the index page. Now what I see is that some apparently random pages (not all) appear without status, and it doesn't change with a purge. The status bar at the top of the main namespace seems to be correct Jellby (talk) 17:06, 30 June 2018 (UTC)

I also noticed this nasty problem today for the first time! I had been working for a couple of days on a small group of books only. And now that I want to come back, after a little bit less than a month to this index, for instance, I see that a lot of pages are non-coloured, although they are proofread already. The same for this index, which has the same problem to a very large extent. I'm sure that I worked on it at June 12th, and that the problem did not happen then. The suggestion given to load a "white page" and save it, whithout any edits, gives the page its colour, in the index indeed. But that is of course very much work, for a complete book. So what can we do to solve this? --Dick Bos (talk) 17:31, 6 July 2018 (UTC)

Should be OK now. I 'touched' it to refresh it.— Mpaa (talk) 21:03, 6 July 2018 (UTC)

Wonderful! Thank you for that, @Mpaa. This sounds like magic. But, there are (many) more indexes to bewitch! Like:

• Index:Darwinism by Alfred Wallace 1889.djvu
• Index:BirdWatchingSelous.djvu
• Index:William Petty - Economic Writings (1899) vol 1.djvu

and so on, and so on (and we have the same problem on the Dutch Wikipedia as well). So can you please explain what you have done (if it is not too difficult to understand for a non-technical person), and do you know anything about the cause of this strange problem, and about a structural solution? --Dick Bos (talk) 08:32, 7 July 2018 (UTC)

@Dick Bos: The same conversation is at WS:Scriptorium/Help. I have started a bot run to resolve these, ahead of the technical semi-fix. Doing ps:0 and ps:4 to start. I have recently put a note to nlWS offering to have the bot run through that wiki, though the bot or any other with task will need bot rights. — billinghurst sDrewth 10:39, 7 July 2018 (UTC)

Addendum. Please refer to the "Tracked" template top right of this section for the Phabricator ticket with all the (gory) detail. — billinghurst sDrewth 10:41, 7 July 2018 (UTC)

Approval request for new bot task

I'm requesting approval for UnderlyingBot (talk • contribs), operated by me. The bot would execute two tasks, both exclusively relating to An Etymological Dictionary of the German Language:

1. divide the OCR text into sections (as in this diff) and
2. create new subpages based on those sections (like this one).--Underlying lk (talk) 07:39, 26 June 2018 (UTC)

•  Comment Please refer to WS:BOTS to see what items are needed in a request. --EncycloPetey (talk) 19:50, 26 June 2018 (UTC)
  • purpose: fixing common errors in the OCR import of the work An Etymological Dictionary of the German Language, such as Tentonic -> Teutonic, and make it more easily proofreadable by humans, more in general;
  • scope: pages about the Etymological Dictionary exclusively;
  • programming language or tools: pywikibot, mostly the replace.py script;
  • degree of human interaction involved: both automated and semi-automated.--Underlying lk (talk) 19:24, 1 July 2018 (UTC)
•  Comment

Point 1: I am fine with it (with the comment that it would be good to include as many replacements as possible in a single edit). BTW, you might find pagefromfile.py quite useful as well.

Point 2: technically you should do it once pages are Proofread unless there is a special reason for that.— Mpaa (talk) 19:34, 1 July 2018 (UTC)

About point 2, the subpages are already there by now. The bot will be responsible for applying automated fixes to the OCR text.--Underlying lk (talk) 03:14, 3 July 2018 (UTC)

•  Comment I would like to see you document in your bot user space the replacements that you are undertaking. Having such available is always useful for next time around. — billinghurst sDrewth 04:02, 3 July 2018 (UTC)

I made a list of the regex replacements here, and will keep it updated when it changes.--Underlying lk (talk) 04:45, 3 July 2018 (UTC)

If there are no objections, I will set the bot flag.— Mpaa (talk) 17:09, 7 July 2018 (UTC)

Flag set.— Mpaa (talk) 21:42, 9 July 2018 (UTC)

This section was archived on a request by: — Mpaa (talk) 13:26, 29 July 2018 (UTC)