Wikisource

Wikisource:Scriptorium/Archives/2020-06

< Wikisource:Scriptorium‎ | Archives
Warning Please do not post any new comments on this page.
This is a discussion archive first created in , although the comments contained were likely posted before and after this date.
See current discussion or the archives index.

Tech News: 2020-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

  • There is a new beta version of the Wikimedia Commons app for Android. It has a new zoom function when you look at images. It can also suggest places when you upload geotagged photos. [1]

Problems

  • There was a problem with the Commons database on 27 May. Commons could not be edited for eight minutes. Because of this problem the database was moved. This caused another short read-only time on 29 May. [2][3][4]
  • The Vector skin had a problem where you couldn't add links to the article in other languages. You couldn't see the section if there were no links to other languages already. It also removed content translation links and links to language settings. This has now been fixed. [5]

Changes later this week

  • You can get a notification when someone links to a page you created. You can turn these notifications off for individual pages. You can soon turn them off also in the notifications you get. [6]
  •   The new version of MediaWiki will be on test wikis and MediaWiki.org from 2 June. It will be on non-Wikipedia wikis and some Wikipedias from 3 June. It will be on all wikis from 4 June (calendar).

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

22:30, 1 June 2020 (UTC)

Question about copyright renewal

I would like to add the book Halek’s stories and evensongs, translated by W. W. Strickland, New York: B. Westermann Co., 1930, which is probably not available online anywhere but I hopefully may get it from a Prague library and scan it. However, before I do it, I would like to ask whether it can be added here. Help:Public domain says that a work is PD if published in the US before 1963 without later copyright renewal. The search I did using the recommended search engine was negative, but I would like to ask for confirmation as I do not have any experience with the renewal problematics. --Jan Kameníček (talk) 07:13, 1 June 2020 (UTC)

@Jan.Kamenicek: Translations are a bit tricky (cf. my discussion with Prosfilaes elsewhere).
The translation as a separate work, if it was first published in the US without copyright notice and without subsequent registration (renewal), is PD in the US. If the translation was first published outside the US and not published in the US within 30 days, this does not apply (it is considered a foreign work in that case; and I see this work exists in a German edition from about that time).
The original—presuming it was first published in Czechia—is subject to pma. 70 terms. Presuming Strickland translated Halek directly (not a later edited edition), this copyright would have long since expired (probably even longer since the pma. 70 term was presumably introduced much later).
Checking for renewal needs to be a reasonably exhaustive search. The Stanford database is a good quick start, but you also need to check all the relevant copyright registrations as published. And you need to document the search steps you performed. --Xover (talk) 08:43, 1 June 2020 (UTC)
@Xover: Hm, I thought that the Stanford database includes all the relevant copyright registrations… If not, where can I check them? --Jan Kameníček (talk) 09:24, 1 June 2020 (UTC)
BTW, the subtitle of the English edition says "translated from the Czech…" [7], so the German editions should not influence anything. --Jan Kameníček (talk) 09:39, 1 June 2020 (UTC)
You're conflating two different things; if it was published without copyright notice, it was immediately put into the public domain. If it was published with copyright notice, then it had a chance 28 years later to seize an extended period of copyright (now 67 years) by renewing.--Prosfilaes (talk) 09:48, 1 June 2020 (UTC)
Not so much "conflating" as "waving my hands and pretending that complicated stuff doesn't exist unless absolutely forced to go check what the rules were". :) I was sure there were some circumstances, depending on date of publication and the phase of the moon, where something published without notice could magically get copyright by filing a renewal that was really a registration (but here I may be conflating with authors recovering their copyrights in contributions to periodicals, which is a different beast). Or something like that anyway. I just couldn't be arsed to go check and didn't think the details were likely to be relevant. But, in any case, thanks for pointing it out (it's always better to be precise about these things when possible; I was just being lazy). --Xover (talk) 10:02, 1 June 2020 (UTC)
It's probably fine. However, Czech and Slovak literature in English* says the English edition was printed in Germany, but it was still probably technically published in the US? Walter W. Strickland was British, and it seems possible that some of it was originally published in the UK before this book. It seems unlikely that anyone is going to challenge it, but I'd want to look at the book, or at least the title page and verso (copyright page) before being definitive about it. The translation is moot.
The Stanford database should include all the relevant copyright registrations; provided it was searched multiple ways to get around single typos ("Nearer my Ood to thee" was one that escaped the Gutenberg proofing), it should be fine. But one could check out the scans of the physical volumes at Online Books or elsewhere.
* Czech and Slovak literature in English is another volume that you might be interested in. It's a recent bibliography, but PD-USGov. I'll try and set it up if you're interested.--Prosfilaes (talk) 09:46, 1 June 2020 (UTC)
I had a quick look at the scans for the renewals. Normally checking pub + 27, 28 and 29 years covers the bases. I didn't see any renewals under "Strickland" (or "Halek", for that matter):
The 1930 registrations are much more fiddly as they're split into 155 numbers. Inductiveload—talk/contribs 10:16, 1 June 2020 (UTC)
@everybody: Great, thanks very much for the help with checking. I also went through the links you have provided here and it really looks OK. I have also learned how to deal with similar cases in future. So now I will order the book using an inter-library service, and after it arrives check also its title page and scan it then.
@Prosfilaes: As for the Kovtun’s book Czech and Slovak literature in English, I know it and I already downloaded it from HathiTrust a couple of weeks ago. It is on my shortlist of works to add here as HathiTrust states it is in the PD, but I am not sure about the reasons, as it was published in 1988. Is it {{PD-USGov}}, because it was published by the Library of Congress? --Jan Kameníček (talk) 11:01, 1 June 2020 (UTC)
It's PD-USGov because it was made by an employee of the US government in the course of their duties; it says on the front that he's part of the "European Division". I'd consider waiting a year, because the front illustration is from Letters from England, 1925, and won't be PD in the US for another year, but could easily be cut out before uploading.--Prosfilaes (talk) 11:11, 1 June 2020 (UTC)
I see, no problem, it will really be better to wait until the next year. --Jan Kameníček (talk) 15:51, 1 June 2020 (UTC)
more info with pdf here https://www.loc.gov/rr/european/bibs/csle.html Slowking4 ⚔ Rama's revenge 12:57, 3 June 2020 (UTC)

Internet Archive

https://arstechnica.com/tech-policy/2020/06/publishers-sue-internet-archive-over-massive-digital-lending-program/

It would seem that Internet Archive might be in trouble.

ShakespeareFan00 (talk) 20:25, 2 June 2020 (UTC)

Not a surprise: this was entirely predictable, to the point of being inevitable. Nobody thought IA had a strong case when they announced this, and nobody thinks much of their chances now. Even if they can eventually avoid billion-dollar damages, the legal costs on the way will bleed them of (donation) funds and may eventually force them to accept onerous settlement terms. Think along the lines of semi-automated DMCA takedowns and geoblocking: of the kind that lets copyfraudsters squat on public domain works by republishing a new edition (like GBooks is now). I hope they have a brilliant secret legal strategy that will let them win this and set a good precedent, but I don't give much for their chances. I hope someone is currently arranging a mass mirroring of their public domain scans is what I'm saying: without IA our work is going to become a lot harder. --Xover (talk) 06:39, 3 June 2020 (UTC)
Without IA, one use case I had becomes considerably harder for me. IA has good scans of the Catalog of Copyright Entries Scans (and not just for Books and Pamphlets.) Without those I cannot without considerable expense confirm the status of many 1923-1964 (or pre 1978) works. Having the good scans of the CCE (via IA) was invaluable in confirming if some more obscure older works could be transcribed here, (and there are efforts on Wikisource to transcribe some of the other volumes to support efforts on Commons to help identify copyvios.). Potentially no Access to scans of these means someone would have to physcially go to the Copyright Office records in the US ( as pre 1978 registrations and renewals are not necessarily fully digitized as of 2020.) or has to assume that any post 1925 work is still in copyright until they can show otherwise. If the publishers desire to protect 'recent' works made it harder for to check the status of older works, there may be some less conscientious individuals who won't bother trying to check the status on older material. (Commons admins on the other hand can be very paranoid about confirming the status of uploaded material.)
The loss of post 1925 material still in copyright wouldn't be a concern for me (given that copyright in the UK is 70 pma and unlikely to change.) However the vast loss of material which is clearly public domain ( like the CCE which is a US Government work) or which in a number of instances was donated to IA by partnering libraries who would reasonably be expected to understand copyright, would be disproportionate. I also get the view that the lawsuit isn't just about the IA's recent actions though, I think the publishers want to send a message more generally.

ShakespeareFan00 (talk) 07:05, 3 June 2020 (UTC)

i would not worry. typical authors guild overreach. see also w:Authors Guild v. Google. internet archive will continue hosting content regardless of copyright status. and we will untangle the orphan work mess. IA has more support than the SOPA lobby. if you want to send a message, call western union.Slowking4 ⚔ Rama's revenge 12:45, 3 June 2020 (UTC)

Tracking down an old source

I'm looking for a copy of The Cooperative Production of Knowledge on the Internet—the Case of Wikipedia, can someone help me find it? Sj (talk) 13:17, 4 June 2020 (UTC)

@Sj: The original article is at s:it:Produrre sapere in rete in modo cooperativo - il caso Wikipedia. We have previously hosted one full user translation at The Cooperative Production of Knowledge on the Internet - the Case of Wikipedia and one partial at The Cooperative Production of Knowledge on the Internet—the Case of Wikipedia. Both where deleted in 2006/2007; one as a duplicate, the other as out of scope. There was also a copyright issue raised, and I couldn't find any licensing info at itWS just now. Unless it's a copyvio we can temporarily undelete the translation so you can grab a copy. --Xover (talk) 14:17, 4 June 2020 (UTC)
Interesting. If it was out of scope for Wikisource, is it possible it would be permissible in Wikisource space, or on another project like Wikipedia (WP: namespace), or Wikibooks...? If so, perhaps it could be restored for transfer. -Pete (talk) 19:08, 4 June 2020 (UTC)
It is definitely available under a free license, and silly for it to be considered out of scope (both by current policy, and given that it's in scope on it:s). (C) grant was noted by the original author, I believe in the document itself and also on Meta around 2005. If you could undelete so I can move it to userspace, I would appreciate it -- as a stopgap :) Thanks for tracking this down, xover! Sj (talk) 19:48, 4 June 2020 (UTC)
Indeed, if this is a thesis that passed review and earned a degree, it would be covered by WS:WWI, as I understand it: "An example of such acceptable research work is a thesis that has been scrutinized and accepted by a thesis committee of an accredited university". Unless this didn't pass review or UNICATT is not accredited, but I would say that speedy would not the be right process for that now. The other issue if if UNICATT claims copyright over theses, but I think that is not very common.
Not to say I'm criticising the original determination, as the inclusion of theses in WWI didn't happen until December 2011. Inductiveload—talk/contribs 20:06, 4 June 2020 (UTC)
@Inductiveload: In addition to being outside scope based on the then policy, the text was flagged as a copyvio, so I imagine the G5 speedy was an expediency measure as much as anything. However, a thesis would only be in scope iff it had been through the equivalent of peer review, and I can find no indication that that's the case here. It was prepared for that purpose, certainly, but there's no evidence it was accepted.
@Sj: I've trawled through the author's (Valentina Paruzzi) contributions on itWP (Vala) and meta (Elian; note that this identification is dubious as Elian says elsewhere that they do not speak Italian) and can find no reference to this work, much less its licensing. On itWS talk page histories I find that Frieda claims to be a personal friend of Paruzzi, and that the author has sent them the text in an email. They later write the text "is clearly GFDL" (I'm paraphrasing), but does not indicate on what basis they draw that conclusion (it sounds like it's the text itself, but I've not found that while skimming the Italian original nor our two English translations). None of the above accounts are active anymore, but the Elian account was sporadically active up until 2018, responding to talk page messages, so you may be able to contact them that way (I'd suggest deWP as that seems to be their home wiki).
Absent an actual OTRS ticked confirming the licensing, or at the very least some clear and plausible statement somewhere, I'm not comfortable undeleting this. If someone can find me better info on that I would otherwise be happy to do so. However… It looks like Pathoschild actually has a cut&paste of the text at their meta talk page after someone else asked for it. If that's all you need you can grab it from there.
If anyone wants this hosted permanently here under the revised scope rules (and the copyright stuff has been resolved), I'd be happy to temporarily undelete pending an undeletion discussion at WS:PD. I have to caution that on closer inspection and comparison with the itWS text, it looks like even the "complete" translation is not actually complete, and the quality of it is far from perfect. It would probably be better to start from a PDF of the original thesis and do a new scan-backed translation from that, if a suitably licensed copy was obtained. --Xover (talk) 16:44, 5 June 2020 (UTC)
Agreed, sorry, that was not well expressed. I meant that a speedy under G5 is probably no longer the right approach, since it's no longer clearly out of scope (it might very well be, but it'd probably be worth a check if it happened today). Since the author edited (albeit very briefly) at itWP and wrote about Wikipedia, you could imagine they might legitimately have licensed it GFDL and could be asked (though they appear gone now, so it's probably too late), and the review status could be checked (though I guess for an undergrad thesis, that might be between very rare and unlikely, maybe more possible for a PhD thesis).
The GFDL statement is the itWS textinfo (simply "Rilasciata in GFDL dall'autrice"), but without OTRS or a concrete source to prove it or any of the contributors active for years, it's not really worth much. And if it was incomplete, it's realistically never going to be finished anyway. Inductiveload—talk/contribs 17:10, 5 June 2020 (UTC)
https://wikispore.wmflabs.org/wiki/Wiki:Main_Page might take it. you really should not predict what work will not be done, some might take it as a challenge. (even if experience shows a growing backlog of unfinished work) Slowking4 ⚔ Rama's revenge 20:37, 5 June 2020 (UTC)

  Comment I have undeleted both versions to allow a review

@Sj: nice to see you. The works would have been out of scope at that time as they were not published translations. We have since modified our scope to allow Wikisource translations of other language wikisource works, and host them in the Translation: ns. (where I hve parked both these works).

We should review the two works, determine 1) can we retain, 2) which version is a better translation, and if yes 3) move to best title, and 4) to retained edition then add {{translation header}} to the work. — billinghurst sDrewth 09:07, 6 June 2020 (UTC)

Tech News: 2020-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

  • Some articles have tables that can be sorted in different ways. For example a list of countries can be sorted alphabetically but you can click on the size column to sort them by size. If you clicked on the column a second time it would sort the countries from the bottom to the top instead. A third click will now take you back to the original sorting. [8]
  • Self-closed tags now work as in the HTML5 specifications. This means you should stop using some of them. <b/> is an example of a self-closed tag that won't work. area, base, br, col, embed, hr, img, input, keygen, link, meta, param, source, track, wbr can be self-closed. Pages with tags that should not be self-closed have been listed in a tracking category since 2016. They will be listed in Special:LintErrors/self-closed-tag. This doesn't affect <references /> or <ref />. [9]
  • There is a banner called WikidataPageBanner. It is for example used by the Wikivoyages, Wikimedia Russia and the Catalan, Basque, Galician and Turkish Wikipedias. It will now been seen by mobile visitors too. Before this it was only seen on desktop. The wikis should update instructions on MediaWiki:Sitenotice so that editors know to test and style for mobile too. [10][11]

Changes later this week

  •   You can now edit MassMessage descriptions through the API. This is useful for tools and gadgets. [12]
  •   The new version of MediaWiki will be on test wikis and MediaWiki.org from 9 June. It will be on non-Wikipedia wikis and some Wikipedias from 10 June. It will be on all wikis from 11 June (calendar).

Future changes

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

21:11, 8 June 2020 (UTC)

Main page on mobile

Hi, all,

From the Tech News above, there is an upcoming change that will affect the display of MediaWiki (or maybe just WikiMedia) main pages on mobile web.

Removing the hack from back-end and instead using TemplateStyles for special main-page formatting will give the communities more control of how it displays on mobile, so I think this will be good in the long term.

But in the immediate term, it would mean Wikisource main page will display in two columns rather than the current single-column. Looks okay to me on a tablet but phone will likely be not pretty.

JDLRobson has a quick CSS tweak at the Phab ticket (Option 1) which looks like it should only affect Minerva and not have other side-effects.

Is that something we can put into production for a quick live test (will need an admin as Main Page is protected), or do we want to create a separate page for testing and discussion?

Pelagic (talk) 22:17, 9 June 2020 (UTC)

@Pelagic: Working on it at Main Page/sandbox new. --Xover (talk) 23:09, 9 June 2020 (UTC)
Thanks, Xover. That looks awesome already! (And I learned something about CSS grid layouts.) Struck part of my original, since the existing layout doesn't work that way. Pelagic (talk) 06:54, 10 June 2020 (UTC)

Stale policy: shortcuts

Quick prod at some stale-looking policy: Wikisource:Shortcut says "Reserved for Wikisource project reference pages (WS: namespace) only.", which is a statement which hails from back in in 2006.

This is clearly not true in practice, as WS:CUTS lists official shortcuts in several namespaces. I suggest replacing it with something that allows shortcuts in (off the top of my head) Main, Portal, Wikisource, Translation, Help and Category (I can't think why we'd need shortcuts to File, Page, Author, Index, User, Gadget; and Template, Module and MediaWiki are doubtful to me). And then add something that prevents over-keen shortcut creation for every single work, i.e. only large collective works like EB1911 and the other current denizens of Category:Mainspace pages with shortcuts are eligible. Basically any work that is eligible for {{engine}} is eligible for a shortcut, but not mandatory. Perhaps:

Shortcuts are allowed to the following namespaces: Main, Portal, Wikisource, Translation, Help and Category.
Shortcuts to the main namespace are allowed only for large collective works (e.g. encyclopedias, newspapers, etc.) that would benefit from the ability to access them quickly. Not every work needs a shortcut.

Obviously standard sanity overrides apply, as always. But if we're going to bother to have policy written down, we should make sure it reflects reality. Inductiveload—talk/contribs 08:49, 10 June 2020 (UTC)

@Inductiveload: Very much agree on your last point, and the rest of your thoughts sound sensible. If you write that up I'd support the change. --Xover (talk) 08:58, 10 June 2020 (UTC)
The indented text above is a suggestion for the new text. I have purposely kept it short and simple and slightly open ended (e.g. define "large", "collective" and "benefit") in order to not pre-emptively shut down reasonable shortcut targets, while also not advocating a policy-driven shortcut creation spree (e.g. as would be implied if you said "large collective works should have shortcuts"). Perhaps it could say "generally allowed only" to imply a bit of latitude for sensible exceptions.
I can add the musing about {{engine}} but that's more a rule of thumb and there have been cases of over-keen addition of that template in the past. Plus, AFAIK, {{engine}} usage isn't regulated by policy, so using it to inform policy is ill-defined.
Any wording can always be refined if it turns out to be deficient, it's not life-and-death. Inductiveload—talk/contribs 11:17, 10 June 2020 (UTC)

Validating texts against alternate sources

Quick question about what to do in a situation that arises occasionally. Sometimes a scan has illegible text, either because of bad printing, damaged pages or bad scanning (e.g. folder pages, obscuration, blurring or out of focus areas; generally, but not always, scans done by a particular company). Without access to alternative scans, that work cannot be completed. Sometimes, we'll even patch two or more incomplete scans of the same work together to make a complete version.

However, it's also common than works are published in many forms (republished, syndicated, etc., especially periodicals), and you could complete the text from a different source. For example the content of Page:Melancholy consequences of two sea storms.pdf/7 has a combination of scan defects (obscured left margin) and printing defects. The same content is available in various other places, for example The European Magazine, May 1796, which must have been within 8 years of the original (the event described was in 1786), another book and The Mariner's Chronicle, all of which appear consistent with the damaged scan.

How do we feel about proofreading the damaged scan from an alternate source that isn't simply a different scan of the same work, assuming that the alternative source is entirely consistent with the damaged one (e.g. if there's a 2em gap, the alternate has "the" in that place and it makes grammatical sense)? Naturally, the source that was used to fill in the gaps should be indicated, e.g. on the index talk page. Inductiveload—talk/contribs 17:36, 9 June 2020 (UTC)

@Inductiveload: I would say that's a judgement call: if the missing or illegible bit is short and you're confident the alternate source is accurate, I'd say go for it. The longer/larger the missing part is and the less certainty can be had that the alternate source is accurate, the harder the substitution is to justify. So long as we're talking single words, even multiple instances of single words on a page (a cut off margin, say), and there's no particular reason to suspect changes between editions, I would pretty much always call it ok. Don't overthink it, is probably apt advice here. --Xover (talk) 17:57, 9 June 2020 (UTC)
Great, thanks. That what I thought, I just don't recall ever seeing the question asked. Obviously if you can't have confidence the text is that same then it's a no-go. Generally, except for the very worst scans, it's just a word here and there or maybe a bit of margin or a stray finger. Inductiveload—talk/contribs 18:09, 9 June 2020 (UTC)
It also turns out there is a "secret" (as in, the documentation wasn't transcluded and there's no reference to it anywhere other than one User pages) template created recently: {{reconstruct}}, which is exactly what I'm talking about. That seems a sensible solution to mark out text that's "knowable" but not actually in the scan. (Turn out it was mentioned here: Wikisource:Scriptorium/Archives/2020-04#Reconstruction_on_context,_and_clipped_scans... but clearly I missed it). Inductiveload—talk/contribs 11:23, 10 June 2020 (UTC)
I was just going to say we should create a template for such purposes but good to see one has already been created. But I think we need to make it more obvious that the text is reconstructed and from what source. I think it is very important we make know that the text is reconstructed and not part of the source and shouldn't just be added without the reader knowing. Maybe with a tooltip? a footnote? or maybe with an explanation after the reconstructed text? Maybe highlight the reconstructed text with a background color? What do you think? I'm thinking highlight the background text with a light color and add a footnote with an explanation that the text is reconstructed and from which source. @ShakespeareFan00: created the template. What do you think? Jpez (talk) 17:15, 11 June 2020 (UTC)
I think this is true only for reconstructing a completely lost text whose wording nobody can be certain of. But if we have a bad scan with some missing words which can be added from another source and if there is no reasonable doubt that the text of both sources is identical, we can add the text without disturbing the reader with some unnecessary templates reducing the enjoyment of reading. E. g. if all the legible text of our scanned work is identical with the text of the alternative source, we can often assume that also the missing words along the edge of a badly scanned page would be identical as well. However, our attitude should depend also on the ratio of the missing text and other factors, so we should consider it individually in different cases. --Jan Kameníček (talk) 17:46, 11 June 2020 (UTC)
Yeah I agree that if there's a word or a few letters missing or illegible we shouldn't go too crazy, especially if it's obvious what it is that is missing or can be found elsewhere. I do this myself many times, adding what it is that is obviously missing, and no one will ever be the wiser. But I guess there is a limit, and we are Wikisource after all, and it's important that we provide source backed texts. So I think that it's important that we should mention where inserted text has come from in many cases especially when it comes to larger blocks of text. Jpez (talk) 19:11, 11 June 2020 (UTC)
I think leaving a note on the Index talk (and maybe Page, or in a <!--comment-->) should be sufficient. I made a quick {{reconstructed from}} template which can put the sources in a nice list and add a category to the index. Feel free to hack with it! Inductiveload—talk/contribs 20:54, 11 June 2020 (UTC)

Interwiki is coming back

Tracked in PhabricatorTask T128173

As work-edition model based interwikis slowly become real in Wikisource, maybe somebody would be interested in discussion that I had with Tpt in this phabricator ticket recently. This presents my POV that may be different to others' POV in this matter. However, I think we still do not know how this model (and its implementations) should behave with complex cases so probably we should wait for an initial implementation and then start a wider inter-community discussion somewhere. Ankry (talk) 19:11, 11 June 2020 (UTC)

@Ankry: I thought this is going to be solved by the Community Tech team any moment because of meta:Community Wishlist Survey 2020/Wikisource/Inter-language link support via Wikidata, i. e. a wish that was chosen to be fulfilled by the community in the end of 1919. --Jan Kameníček (talk) 10:05, 12 June 2020 (UTC)

Transcluding a collection of interesting tidbits from the PSM project

I bookmarked about 160 paragraphs from The Popular Science Monthly which I found interesting and whimsical on their own, and especially when compared with the knowledge of today. Started to assemble a small sample HERE to give the community an idea of what I am talking about. I would like to transclude them to the main namespace in the next couple of months. Are there any objections or suggestions? — Ineuw (talk) 21:25, 11 June 2020 (UTC)

@Ineuw: I am uncertain what it is that you're proposing to do. Do you mean you intend to create a mainspace page with an arbitrary selection of interesting excerpts? If so, I would say that'd be against our policy on excerpts and, I suppose, annotations. Interesting as those tidbits are, they would be your selection and not reflect any published collection. --Xover (talk) 06:13, 13 June 2020 (UTC)
No problem.— Ineuw (talk) 17:09, 14 June 2020 (UTC)

Address by Theodore Roosevelt before the convention of the National Progressive Party in Chicago

Could an index be created for this page from the scan images here? The page is one of a number created by User:Progressingamerica recently, with links to on-line scans, but without a scan basis. TE(æ)A,ea. (talk) 21:42, 13 June 2020 (UTC).

File:Address of Theodore Roosevelt NPP - 1912.djvu. Annoyingly they seemed to be blocking automated downloads andthe basic user agent trick didn't work. >:(. Inductiveload—talk/contribs 22:15, 13 June 2020 (UTC)
there you go Index:Address of Theodore Roosevelt NPP - 1912.djvu - text layer good. more of a pamphlet, the special collections librarians are more used to manuscripts, than books. Slowking4 ⚔ Rama's revenge 23:47, 13 June 2020 (UTC)

Should Category:Formatting templates and Category:Typography templates be combined?

I noticed these two categories, which seem to have a great deal of overlap, not only in their descriptions, but also in their contents. Is there any reason to separate the categories? If not, could someone (perhaps using a bot) deprecate one of the categories? TE(æ)A,ea. (talk) 21:16, 14 June 2020 (UTC).

Translation header template -- seems to have just started rendering in duplicate

Tracked in PhabricatorTask T255073Resolved

Translation header template -- seems to have just started rendering in duplicate.

For example


For example


Nissimnanach (talk) 15:14, 10 June 2020 (UTC)Nissimnanach Nissimnanach (talk) 15:14, 10 June 2020 (UTC)Nissimnanach

It's not only translations, all headers are doing it today. Not sure why, but it's something to do with Javascript. Inductiveload—talk/contribs 15:36, 10 June 2020 (UTC)
@Nissimnanach, @Inductiveload: There was a new MediaWiki deployed today (1.35/wmf.36) and it looks like some change to its HTML output broke local javascript here. I'm guessing it's the darned dynamic layouts / pagenumbers scripts causing the havoc: they move the HTML that the header template emits around in the DOM in… careless ways. Note for example that there are now two #mw-content-text nodes in these pages(!). And the code, besides being spread over multiple files, is loaded unconditionally from (and partially is implemented in) Common.js and runs for all users, so it's a right royal pain to debug. --Xover (talk) 17:18, 10 June 2020 (UTC)
@Xover: yep, I was trying to poke at that as it's the only place I could see mw-content-text and headerContainer being used locally. But as you say, Common.js is pretty impervious to debugging. Maybe as everything is broken right now anyway, now is a good time to rip it out into a turn-offable module (e.g. PageNumbers.js), since it can't get much more borked?
Having two #mw-content-text elements can't be intentional, isn't the whole point of IDs is they should be unique?
Also the heederContainer bit looks pretty suspect. Inductiveload—talk/contribs 17:25, 10 June 2020 (UTC)
@Inductiveload: Don't get me started. (IDs should be unique; heeder is not a typo(!))
@Billinghurst: or anyone else with global-interface-admin: could you try disabling (delete, comment out, whatever) lines 135–142 in MediaWiki:Common.js and see if that fixes this problem? It'll break some other stuff, but it'll let us narrow down where the problem lies. --Xover (talk) 17:41, 10 June 2020 (UTC)
Meh. I'm having trouble catching the culprit in the debugger. MediaWiki:PageNumbers.js is what wraps #mw-content-text in three div elements (#pageContainer, #regionContainer, and #columnContainer). MediaWiki:Common.js lines 135–142 then picks out the header in the DOM and moves it outside those wrappers. And MediaWiki:DisplayFooter.js automatically generates a footer based on the header. I've been trying to set breakpoints in the debugger to catch the bit that's causing problems, and I can catch the double header (which is just a symptom) but I've so far failed to catch whatever it is that causes duplicate #mw-content-text. And despite breakpoints on the relevant line in PageNumbers.js I am failing to catch the DOM before those three wrapper div elements are added (which should be impossible).
I'll have to go offline for a bit now, but I'll get back to this when I can (breadcrumbs above if anybody else wants to try tackling this in the mean time). --Xover (talk) 18:23, 10 June 2020 (UTC)
BTW, line 141 in Common.js is what is adding the duplicate header ($( 'div#headerContainer' ).prependTo( $( 'div#mw-content-text' ) );). But it is getting thrown off by something else that I've not been able to track down. Possibly related to the html5 changes in the latest Tech News, and possibly also involving the previous issue about over-specified selectors (note the element name in the jQuery selectors there). --Xover (talk) 18:40, 10 June 2020 (UTC)
Note: in jQuery, $( 'div#mw-content-text' ) will return a list of two items if there are two elements with that ID. According to the jQuert prependTo docs, "If there is more than one target element, however, cloned copies of the inserted element will be created for each target except the last." So this is the culprit. Inductiveload—talk/contribs 19:03, 10 June 2020 (UTC)

Also the while 1911 Encyclopædia Britannica/Nuisance has two headers the pagination at the side works correctly (via the translucent inclusion) however the next page 1911 Encyclopædia Britannica/Nukha uses ‹div class=indented-page>{{page break|485|left}} and the page number is being mixed into the text. -- PBS (talk) 17:35, 10 June 2020 (UTC)

┌─────────────┘
 @Nissimnanach, @Inductiveload, @PBS, @ネイ, @Jan.Kamenicek: This looks like a Mediawiki bug (probably in Vector), cf. phab:T255073. --Xover (talk) 20:05, 10 June 2020 (UTC)

Ok, Jdlrobson just uploaded a patch for this, so it's possible we'll get it fixed in an out-of-cycle deploy relatively soon (the alternative is the next scheduled deploy on next Wednesday). If that doesn't pan out I think I have a workaround we can implement locally (we just need to flag down an interface-administrator). Details on request, but I'm hoping we can avoid it. --Xover (talk) 21:03, 10 June 2020 (UTC)

  Comment The fix has been rolled out, though there is now an ugly artefact of visible <div class=indented-page> see 1911 Encyclopædia Britannica/Nukha. In the main namespace on transcluded pages PrP ignores that class, and in non-transcluded pages it should function. I cannot put time into working out the issue. — billinghurst sDrewth 00:02, 11 June 2020 (UTC)

This is now resolved. The indented-page issue appears to have been a followon problem that disappeared when page caches were purged. --Xover (talk) 06:05, 13 June 2020 (UTC)
I have just made this edit to 1911 Encyclopædia Britannica/Pittsburg (Pennsylvania) edit comment: "‹div class=indented-page>{{page break|678|left}} – {{page break|682|left}}" and the page is now displaying the problem that user:billinghurst describes. -- PBS (talk) 20:45, 15 June 2020 (UTC)

Tech News: 2020-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

  •   Toolforge hosts several tools created by the Wikimedia community like edit counters or enhanced editors. It is changing the domain from tools.wmflabs.org to toolforge.org. The routing scheme is moving from tools.wmflabs.org/toolname to toolname.toolforge.org. You can read the details. Tools that use OAuth will have to be updated to keep working. You can ask for help.

Problems

  • There is a Wikidata item link in the sidebar on many pages. This disappeared for a couple of days for users who have the Monobook skin. This was because of a bug. It has now been fixed. [14]
  • Editing, logging in and logging out didn't work properly for a short period of time last week. It was soon fixed. [15]

Changes later this week

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

Future changes

  •   Pywikibot is a Python library to automate work on wikis. It will not support Python 2 after the new version in July. Support for Python 3.4 and MediaWiki below 1.19 will also be dropped. You should migrate to Python 3. You can ask for help. [16]
  • The selectors .menu and .vectorMenu will no longer work in the Vector skin. This can affect gadgets and user scripts. .menu should be replaced by ul. .vectorMenu should be replaced by .vector-menu. [17]

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

21:37, 15 June 2020 (UTC)

Easy LST overhaul with handy new features

Hi, I have overhauled the Easy LST gadget to allow (what I think) is a pretty handy thing: automatic replacements of text on save.

For example, you can configure it to replace <<cxlsc|XXXX>> with {{center|{{x-larger|{{small cap|XXXX}}}}}}. It will be replaced when you preview the page, so there is no further action you need to take.

You can also configure it to perform generic actions on load and save, which could be used for auto-generating a running header or page numbers without fragile templates. This could be done with other scripts, but this gadget provides a perfect hook-in location for these functions.

I combined this stuff with the Easy LST gadget we have because the LST thing requires to overwrite the click handler for the Save buttons, and having a separate gadget would allow only one to work, unless there was some really delicate interdependency. Since the functionality is exactly the same (text transform on load and save, it seems easy to combine). Other changes:

  • It is no longer naughtily placing its functions in the global namespace, it's all inside an IIFE
  • General tidy-up and linting
  • Can disable it with JS, so if you do want to disable Easy LST dynamically based on namespace or page name or something, you can do that

The script is at User:Inductiveload/easy_lst.js, there is some simple documentation at User:Inductiveload/easy_lst. As usual, you can try it out with 

importScript('User:Inductiveload/easy lst.js');

If people like it, it can be gadgetised by putting it in the right place, which will need an Interface Admin. With no configuration, there should be no different visible to the user. I find it rather useful, hope you do too! Inductiveload—talk/contribs 20:42, 12 June 2020 (UTC)

@Inductiveload: Awesome! And I'm ecstatically happy to see someone take an interest in our technical aspects: we have an insane amount of site-local custom CSS and JS that was not particularly well designed (in aggregate; I don't necessarily mean individual pieces of it), is prone to break due to changes in browsers or MediaWiki or skins, and often isn't actually needed anymore. We also have lots of opportunities for improvement and utility that we aren't taking advantage of.
That being said, I do have some comments on this particular script…
First of all, ResourceLoader modules do not execute in global scope; they get a "private" closure from RL's implementation method, so the IIFE is not needed. MediaWiki:Common.js, Special:MyPage/common.js, and similar do execute in global scope, but that's by design (for compatibility reasons) and is a completely different issue.
Second, you'll want to use jQuery to bind the event handlers using something like $('#wpPreviewWidget').click(on_save);; or, since you're installing the same handler for all the buttons, just attach it to the nearest parent with $('.editButtons').click(on_save);. The event handlers are executed sequentially in the order they are attached, so there's no problem with multiple Gadgets attaching handlers to the same nodes; and events bubble up from innermost elements to their parents until there's a handler for that event, so you can just install one handler for a containing element when you don't need to differentiate between the buttons. Which brings me to my final point…
As a general rule, it is a bad idea to mix multiple functionalities into the same script. This is true both from the user perspective (easy labelled sections isn't really a "replace text strings" type of function from a user perspective), and from a technical perspective (it bloats the code and makes it harder to figure out what it does, and creates a tight coupling between things that are functionally independent of each other). You want the least possible lines of code in a Gadget that still gets the job done. There're exceptions, of course, particularly when you get into huge utilities like Twinkle, where you might want to collect common code into a shareable library, but for anything we're futzing about with here on enWS the rule of thumb should hold in almost all cases.
My suggestion would therefore be to let Easy LST be Easy LST (well, it could certainly do with a more descriptive name and a link to docs from its Gadgets prefs entry!), and implement the new functionality as a separate Gadget. Easy LST is the kind of thing we want to enable by default for all users; the other code is more of a power-user feature that must be explicitly opted in to. --Xover (talk) 07:58, 13 June 2020 (UTC)
@Xover: Great tips, thanks! I'll look at doing it that way. I had used the old-skool handler registration directly from the original, and didn't think my way out the box. Is there any way to debug a script "as a Gadget"? I saw the functions in the global scope when I was manually loading the script from common, I didn't realise Gadgets get special treatment. Inductiveload—talk/contribs 10:28, 13 June 2020 (UTC)
@Inductiveload: Not that I know of, no. If you have 2FA set up, once you get +sysop back, you can request interface-admin permissions and set up a copy in a hidden gadget (it can default to on, but then disable itself unless the user is your account). It's hacky and awkward, but it might do in a pinch. --Xover (talk) 11:39, 13 June 2020 (UTC)
@Xover:, OK, I'll hack along as I am for now and maybe revisit in future.
I also hope I'm doing the config hook thing correctly - I got the idea and method from the lint check tool, which seems to be pretty "modern" JS.
Also, what level of JS modernity do we target? In particular, can we use "let" rather than "var"? CanIUse says it's got about 95% support, mostly missing IE 11 (c. 2013). Inductiveload—talk/contribs 12:28, 13 June 2020 (UTC)
Hmm, looks like the config hook thing will not work reliably (or at all?) in a gadget, because the fire/add function ordering is not defined. Anyone know the canonical way to post configs into gadgets? The current gadget looks at a global variable, which seems almost as dodgy. Inductiveload—talk/contribs 14:57, 13 June 2020 (UTC)
@Inductiveload: Oh, by the way, since you mentioned headers and footers, you might find some use of a… dingus… I made to make finishing Match&Split works easier (that operates on similar principles to your script). See my message to BT at "Lab rat?". It's really hacky and prone to fail, but for my own use it's been really helpful. In short it's a user script that tries to eliminate any manual labour involved in setting page headers and footers. For the large volume of pages, the only manual job is to remember to tell it the new chapter title once the chapter changes. I plan to eventually clean it up and document it, but as it's a rather narrow use case it's not been a priority. Feedback and suggestions are always welcome though. --Xover (talk) 12:00, 13 June 2020 (UTC)
@Xover: I'll take a look. User:Inductiveload/Running header.js has a similar aim, but it copies content from the previous (actually n-2th) page. It's a manual Templatescript thing, but an option to auto-insert if the page is being created should be quite possible.Inductiveload—talk/contribs 12:28, 13 June 2020 (UTC)
@Xover: a related issue I just opened that would be useful for your script (and I've run into the need myself before): phab:T255345 Inductiveload—talk/contribs 13:59, 13 June 2020 (UTC)

Take 2

@Xover: I've split it back out into 2 scripts. The jQuery suggestion for the click handler was (of course) right, so the two can live in harmony, side-by-side. The Easy LST script is now called "Easy Section Syntax" and if fundamentally unchanged, though a little bit tidier. I haven't been able to find a "correct" way to deal with the configuration as yet, so if a user does want to configure it (e.g. disable it on certain pages, etc), they have to turn the gadget off, then load it after their config in their user JS. I have therefore kept the IIFE, since it's needed in debug contexts and in user-configured contexts, and I don't think double IIFE won't cause any drama.

Probably the auto-replace script will stay as a user script rather than a gadget if this is how configuration has to work. Slightly annoying as it won't appear in the gadget list, but since it would need config anyway on a per-user basis, the only functional different is an extra importScript call. Inductiveload—talk/contribs 22:49, 14 June 2020 (UTC)

@Inductiveload: You can still access globals as a Gadget, so just proxy the config through the window object. Something like:
// Custom replace functions are added to this array
window.SLAactions = [];

// A custom function
function fixOCR (wikiText) {
   …
};

// Add custom function to the array
SLAactions.push(fixOCR);
If you also need traditional "user preferences" style configuration, you can link the user to Special:BlankPage/SLAactions, catch that page in the script and display a prefs UI there, and then save the choices to the user's MW prefs using mw.user.options.set(). Or you can let the user use mw.config.set() from Special:MyPage/common.js and then just not persist the values. There's a simple example of using such a pref in User:Xover/Gadget-NopInserter.js (see WS:S#Update to NopInserter Gadget for context). --Xover (talk) 06:42, 15 June 2020 (UTC)
@Xover: Right, but is there any guarantee this:
// common.js
window.SLAactions = {...};
runs before the Gadget reads from it? It doesn't really matter for something like HotCat, where the user will only interact with it once common.js has almost certainly executed and completed. But for Easy LST (or SLAction, if there are load actions), if the user set a config, say that disabled the gadget, the gadget needs to know that before it storms ahead and messes with the text.
The hook method forces this by fire()ing before loading the script at all (thus before the add() is called). This introduces extra delay, as you have to do "load, run, load, run", rather than just "load, run, hook_fire"/"load, wait, hook_add, run" in parallel.
For very simple, static, config, the prefs-style would work fine, as mw.config.get("myPrefs"); should be available to the gadget. But say your config was "only do Easy LST if the page isn't DNB", what to do? Unless you have a dedicated page filter baked into Easy LST (code, complexity, size and maintenance overhead), you can't do it, and even if you had a page filter, maybe the user wants to key on phase of the moon, or user agent, etc etc etc.
My workaround so far is to allow the gadget to be run as a user script or a gadget, so the interested user can configure it and the default user can just get the defaults loaded by the gadget mechanism (faster and easier). In the case of SLAction, it'll probably have to be only a user script, as there's no huge benefit to gadgetising since the user will need to list their own actions in JS anyway. But if there were way, it would speed things up a tiny bit. Inductiveload—talk/contribs 10:07, 15 June 2020 (UTC)
@Inductiveload: I'm having trouble tracking down information on the load order here. But I'm not sure it matters in this case: you can't start modifying the page until the DOM coalesces anyway ($.ready), and by that point any code in user scripts should have finished running. Or so I would assume in any case. --Xover (talk) 18:14, 16 June 2020 (UTC)
I feel like you might be right, but it's quite tricky to test out, since the gadgets are so undebuggable, and debug mode is not representative. As long as User:Common.js "gets on with it" and doesn't (say) apply config within a callback from a slow load† or something (which could run after the DOM settles, even if the main "thread" of commons.js is complete), I imagine common.js would be done, and it does seem that way when I place a breakpoint at the end of User:common.js, or at least the main thread is done before functions like $(function(){this_one;}) fire.
My concern stems from mw:Extension_talk:Gadgets/Archive#Gadget_scripts_loaded_too_early, which indicates this was once an issue, but in 2008, but the thread died and I can't tell what the upshot was. I also asked at mw:Topic:Vo7zs0yio0xtp78g. The only suggestion so far is a fancified version of what you suggest with Special:BlankPage.
Perhaps I'm faffing about pointlessly for 99.9% of practical cases, but I'd quite like to know the One True Way to do this, especially if it concerns a default gadget.
† Actually my user:common.js is loaded from a local server, so what I think of a my common.js is already inside an async callback, but it loads fast. Inductiveload—talk/contribs 09:08, 17 June 2020 (UTC)

User:350bot

For creating the remaining red links of A Chinese and English vocabulary, in the Tie-chiu dialect#Contents. I might use AWB for future tasks, but this task will probably be manual. Suzukaze-c (talk) 05:15, 18 June 2020 (UTC)

Auto-generated reports -- to portal: namespace?

Miraclepine and I started a nascent conversation about the generation of reports of curated lists from Wikidata that might of interest and especially in lieu of categorisation which is hard work and forever incomplete here. Also with WD's data being regularly updated and curated it seems that we are wasting the power of how it can help us outside of the main namespace.

For example if we had a page Portal:Royal Victorian Order we could have section(s) that generate a series of lists of authors for each class of the order. Here we would be looking to use something like d:Wikidata:Listeria to do the heavy-lifting. (Not that I am an expert in Listeria)

Does the community see that the portal namespace is the place to generate such output?

I know that the Wikidatans like to generate those interesting queries, eg. d:Wikidata:Status updates/2020 06 15 and it would be great if we could have those pages generated in a curated means in a ready namespace.

Interested to hear the community's thoughts. — billinghurst sDrewth 13:58, 16 June 2020 (UTC)

@Billinghurst: As a Wikidatan, I would like to note here that I recently prepared this SPARQL query which may be useful for the Listeria lists. This one is for GCVOs, but may be used for any award as long as that award is listed in the items' "award received" property. It may take seconds to load.
#People on Wikisource with GCVOs
SELECT ?item ?itemLabel ?article WHERE {

    ?item wdt:P166 wd:Q12192290 . # person with GCVOs
    ?article schema:about ?item .
    ?article schema:isPartOf <https://en.wikisource.org/>.
  
    SERVICE wikibase:label {
       bd:serviceParam wikibase:language "en"
    }
}

Go to query page

ミラP 00:56, 17 June 2020 (UTC)

  I know that I have been adding that award data as I generate the entries from TIWW. Though of course, the information about entries here is quite sparse compared to the data that one enters into the main subject, and referencing the data additions at WD from the local data is just a complete PITA. Also one is always inhibited with the issue that WD is not great for having data on institutions from early 20thC and before.

I sometimes wonder what it is that people want to see in the generative/informational space that could be Wikisource. And when we do output, what is the output that is desired. I do know that ages ago Charles Matthews started Portal:British Museum which seems to me a could sort of Listeria-target page if the data has been added to WD, and we could concpetually looking to construct, either as complete pages, or constructed subpages. — billinghurst sDrewth 01:36, 17 June 2020 (UTC)

On the general idea of using Listeria here: I would be in favour. It's a versatile technology, and given knowledge of SPARQL not hard to apply.

d:Wikidata:ScienceSource focus list/Main subject needed is an example of mine where, in a Wikidata namespace, it is combined with a focus list (use of P5008 on Wikidata) to provide a maintenance list. Custom focus lists on Wikidata need only the creation of a single item identifying the underlying project, and are a neat way to handle curated sets on Wikidata.

I think such lists would be suitable in both the portal and Wikisource: namespaces here. Charles Matthews (talk) 04:32, 17 June 2020 (UTC)

yes, i would support migrating hand curated lists in general to listeria. you could also try a DNB , EB1911, etc. author list. eventually bibliographic metadata will be from wikidata (wikicite) as well. Slowking4 ⚔ Rama's revenge 12:33, 18 June 2020 (UTC)
I support using Listeria. It has the added advantage that, with minor tweaks, a query from here can be used in any other language version of Wikisource, or vice- versa. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:55, 20 June 2020 (UTC)

British works published after 1925

Help:PD says that works published outside the US between 1925 and 1977 are public domain if they were PD in its home country as of 1 January 1996 and never published in the US prior to that date. According to Wikipedia:Copyright law of the United Kingdom, "Under the 1995 Regulations (set out below), the period of author's copyright was further extended, to the lifetime of the author and 70 years thereafter" so I understand the 1996 rule cannot be applied to British works whose authors died after 1925. Unfortunately, there is not written what the British laws say about works published in the UK after 1925 (e. g. in 1941) whose author is not known. May I ask for advice? --Jan Kameníček (talk) 21:59, 18 June 2020 (UTC)

If it's fiction (i.e. an "artistic work") then it might be PD if it was published before 1950. Commons has a template that summarises that. I'm not really sure though. —Sam Wilson 00:49, 19 June 2020 (UTC)
Thanks very much, although the work I am speaking about now is not fiction and so I cannot apply this, it useful to know for future. --Jan Kameníček (talk) 06:21, 19 June 2020 (UTC)
The UK gives 70 years from publication for anonymous works; so combined with the lack of the rule of the shorter term, UK anonymous works published after 1925 are still under copyright in the US.--Prosfilaes (talk) 04:27, 19 June 2020 (UTC)
@Prosfilaes: Thanks for the reply. I know that it is 70+ from publication for anonymous works in the UK now, what I was not sure was whether it had been 70+ from publication for anonymous works in 1996 too. --Jan Kameníček (talk) 06:21, 19 June 2020 (UTC)
@Jan.Kamenicek: It's probably better if you just give us the details about the specific work. It's hard to guess what factors may apply without that. --Xover (talk) 07:44, 19 June 2020 (UTC)
@Xover: Here is an catalogue entry. However, there is one problem with the entry: they state that it was published in Czechia (Česko), which must be an error. The work itself does not indicate the place of publication, there is just written "Compiled on the occasion of the Czechoslovak Army Exhibition, Stratford-upon-Avon, January, 1941". Czechia was occupied by Germany which was in war with the UK, where Czechs were trying to form some military units to fight against Germany. I cannot imagine that a work for an army exhibition in Britain was published in occupied Czechia. I think it must have been published directly in Britain. However, it is not that important, just three pages of text, so if it is too complicated, I can leave it. --Jan Kameníček (talk) 08:49, 19 June 2020 (UTC)
@Jan.Kamenicek: I can't prove it, but it seems almost certain that they went from 50 to 70 for anonymous works at the same time they went from life+50 to life+70.--Prosfilaes (talk) 01:21, 20 June 2020 (UTC)
UK went from 50 to 70 years in 1995 presumably per legislation per http://www.legislation.gov.uk/uksi/1995/3297/contents/made where it all aligned with the EU requirements. — billinghurst sDrewth 06:06, 20 June 2020 (UTC)
Thanks very much! I went through the linked text and there is written that 50 years were substituted by 70 years for anonymous works in the 1995 regulations too :-( So PD-anon-1996 cannot be applied to this work. --Jan Kameníček (talk) 08:31, 20 June 2020 (UTC)
@Jan.Kamenicek: Do you have a source file? I'd like to read it; and I believe it would be eligible to be uploaded to Commons. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:36, 20 June 2020 (UTC)
This catalogue entry names "Czechoslovak Army" as the publisher; I wonder if this was considered as de jeure publication "in" Czechoslovakia, given the Czechoslovak government-in-exile? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:49, 20 June 2020 (UTC)
@Pigsonthewing: Not yet, but I could scan it (the book is not allowed to be borrowed away from the library, so I just have to take my own scanner and scan it there).
Ad publisher: I understand what you mean but I am not able to decide this :-( --Jan Kameníček (talk) 11:00, 20 June 2020 (UTC)

Always needing to confirm when leaving Page editing?

Tracked in PhabricatorTask T255846

Does anyone else find that they are always asked to confirm when leaving a Page NS editing form, even when nothing in the form has been changed? I think I've got a fix for it, but maybe it's not an issue or is even helpful? —Sam Wilson 03:48, 19 June 2020 (UTC)

@Samwilson: I've not noticed this happening, and quick testing now was not able to reproduce in latest-ish Safari. If needed I can check a couple of other browsers. --Xover (talk) 05:24, 19 June 2020 (UTC)
@Xover: Hmm interesting, thanks. Maybe it's a Firefox- and Chrome-only issue? I see it reliably in both those browsers when I click edit on any page and then hit any link to leave the page. Actually, if I click a link super quickly (I guess before JS has finished loading) it doesn't happen, but every other time it does. —Sam Wilson 05:37, 19 June 2020 (UTC)
@Samwilson: On macOS I cannot reproduce in Safari, Firefox, Chrome, or Vivaldi in their latest release versions. On Windows I can reproduce it in Internet Explorer 11 and Chrome 83 (the only two I can easily access). --Xover (talk) 07:41, 19 June 2020 (UTC)
@Samwilson: I have got the same experience and it is pretty annoying. It would be brilliant if you were able to fix it! --Jan Kameníček (talk) 06:26, 19 June 2020 (UTC)
BTW, I have tried three browsers and I have this problem in all Chrome, FF and Opera. --Jan Kameníček (talk) 09:03, 19 June 2020 (UTC)
@Samwilson: To confirm that your preferences do not have ticked Warn me when I leave an edit page with unsaved changes. It isn't happening to me with Firefox. — billinghurst sDrewth 05:49, 20 June 2020 (UTC)
Noting that there will be pages where there are zero observable changes as there can be changes happening in the background of ProofreadPage. Try Page:The Catholic encyclopedia and its makers.djvu/162 and see if you get the same issue? — billinghurst sDrewth 05:51, 20 June 2020 (UTC)
@Billinghurst: Yep, I have that preference enabled, but I'm getting the warning even when there are no changes. It does happen on the page you linked. I'm not sure what changes in the background you're talking about, but it seems to me that it's poor UX to get this warning. If a user opens an edit page, and doesn't do or click on anything at all, and then tries to navigate away, they shouldn't get a confusing message about "data you have entered may not be saved". I think I've found the fix; see the above phab ticket. —Sam Wilson 05:36, 22 June 2020 (UTC)
@Samwilson: save the page and see if there is a micro-edit, or whether it is a false artefact. — billinghurst sDrewth 06:40, 22 June 2020 (UTC)
@Billinghurst: Nope, saving it produces no diff. I'm pretty sure it's a bug. —Sam Wilson 01:13, 23 June 2020 (UTC)

Publication date of files uploaded to en.ws

When uploading a file to en.ws, the uploading form asks to choose some licensing. One of the offered options is "First published in the United States before 1923", while the uploader should be offered "… before 1925". Can it be changed locally or is it necessary to ask at phabricator? --Jan Kameníček (talk) 08:45, 23 June 2020 (UTC)

@Jan.Kamenicek: The options in that dropdown come from MediaWiki:Licenses and can be changed there. On the presumption that the change is not controversial I have gone ahead and made that change. If that should not be the case then please let me know and I'll revert it while we discuss the issue. --Xover (talk) 09:02, 23 June 2020 (UTC)
Yes, that is what I meant, thanks for quick reaction. --Jan Kameníček (talk) 09:29, 23 June 2020 (UTC)
BTW, is it possible to make it automatic, so that it does not have to be changed manually every year, to prevent the current situation when the options were updated 2 years later than needed? --Jan Kameníček (talk) 09:34, 23 June 2020 (UTC)
@Jan.Kamenicek: Nope. Extensions (like ParserFunctions) are not run in that context so we can't (easily) make that value calculated. --Xover (talk) 09:49, 23 June 2020 (UTC)

A not insubstantial effort at Commons...

As reported previously, Internet Archive is facing a lawsuit over copyright concerns.

There was a proposal at Commons to mirror public domain works from Internet Archive to Commons.

This is a partly courtesy notification to let Wikisource contributors and admins know about this.

Relevant threads at Commons:

As what was intended to be 'mirrored' is intened to be public-domain books (and some other resources which are "compatible" with Commons licensing), it would be appreciated if contributors and admins from Wikisource with relevant expertise and the time could assist in reviewing what's been uploaded so far and what may be coming shortly. The aim of this reviewing would be to ensure that anything still in copyright, but inadvertently uploaded, is rapidly removed.

In addition it would be helpful (if feasible) to have a complete list of IA identifers for "public-domain" works linked to from Wikisource as External Links, but which for whatever reason do not yet have a local copy available for transcription. This is so that if needed an appropriate script could be used to ensure the appropriate files for those identifiers are uploaded in future batches.

I am likely to be away from Wikisource and Commons for a while however... ShakespeareFan00 (talk) 21:37, 24 June 2020 (UTC)

I thought you should know (useful tip for transcriptions!)

Just for you to know, in one of the last Windows 10 updates, they added an "emoji" menu, [Win + . (dot) ], that gives you access to not only emojis, but a variety of unicode symbols and letters, as well as mathematical signs. It's slightly more convenient than the "Special characters" tab. Take care. --Ninovolador (talk) 19:30, 26 June 2020 (UTC)

Empty space at the top of a page

How can I get rid of the empty space at the top of Page:A Book of Czech Verse.pdf/24? --Jan Kameníček (talk) 16:42, 25 June 2020 (UTC)

Please see if this is what you meant. There is space on top because of the font-size line-height.— Ineuw (talk) 17:53, 25 June 2020 (UTC)
@Ineuw: The result is what I needed, thanks very much. However, the way to achieve it is far from being intuitive and, honestly, I do not understand it much :-(
I am also not sure about the reason (font-size line-height). When I look at the original layout of the page, it seems to me that there are empty lines at the very top of the page (CTRL+A makes it visible), not a line with a larger line-height. I have also seen many other pages with the title written in a larger font where no empty space appears above the title (example). What is the reason that this page needs such a complicated solution while other pages do not? --Jan Kameníček (talk) 18:05, 25 June 2020 (UTC)
One more thing: Can the block be aligned to the left? The problem of {{Bilingual}} is that every pair of pages has to be transcluded separately, and so it is impossible to align the text to the center as one block. Therefore it is better to align it to the left, which ensures that the left edge of the text is in one line with the text of the other pages. --Jan Kameníček (talk) 18:14, 25 June 2020 (UTC)
@Ineuw: Here is the result after transclusion to show how the pages got misaligned. --Jan Kameníček (talk) 19:06, 25 June 2020 (UTC)
@Ineuw: I have noticed that you tried to simplify it and align the poem to the left, thanks very much for that, but I still do not like this solution very much. While originally the problem was only a redundant empty line at the top, now two problems have appeared instead:
  1. The block from page 16 is not aligned with the block of the following page no. 18, see the transcluded result at A Book of Czech Verse/Jan Kollár, although this probably could be solved by adding the table and margin parameters to the poem in page 18 too.
  2. The author and the title of the poem are aligned to the center of the page, not the center of the block, which is visible when I for example change the width of the browser’s window. --Jan Kameníček (talk) 21:41, 25 June 2020 (UTC)
I really do not understand why these complicated things are needed. The original layout looked simple to me, so why does the empty line appear there? Is it connected with the problem that Xover tried to solve with the {{center}} and then returned it back? --Jan Kameníček (talk) 21:41, 25 June 2020 (UTC)
There is a very easy way, had I known that page two is a translation. I will fix it.— Ineuw (talk) 22:28, 25 June 2020 (UTC)
@Jan.Kamenicek: A_Book_of_Czech_Verse is the end result but the only way I could do this, is to place them in a table in a left and right cell and with a center cell to space the two columns apart.— Ineuw (talk) 00:14, 26 June 2020 (UTC)
@Ineuw: This looks much better! The only disadvantage I can see are the missing little numbers linking to the individual pages with English translation, which is imo very important too :-(
  Comment Why are we producing the Czech at all, it doesn't belong here, it should be at csWS? It should only appear here by interwiki transclusion, not through our proofreading and displaying. — billinghurst sDrewth 06:01, 26 June 2020 (UTC)
@Billinghurst: I would gladly transcribe it to cs.ws but there are several problems:
  1. Czech WS uses different formatting templates which fail after the page is transcluded to English WS.
  2. Local admins at cs.ws do not like the proofreading extension for some reason and so it is very badly maintained there and solving a problem often takes weeks or months. At the same time the request for Addition of csWS to global bots was absolutely ignored by the admins and failed as a result. So even if we found some working solution now, I am not sure whether it can be guaranteed that it will work in the future too. --Jan Kameníček (talk) 07:37, 26 June 2020 (UTC)
Still not a particular reason why the Czech text ends up here. I left a message for Danny to see what we can sort out. — billinghurst sDrewth 11:32, 26 June 2020 (UTC)
@Billinghurst: One more thing: I was thinking about the transwiki problems generally and have forgotten about an insurmountable problem connected with this particular work, and that is copyright: {{PD-US-no-renewal}} is not an acceptable license at cs.wiki. --Jan Kameníček (talk) 14:25, 26 June 2020 (UTC)
@Jan.Kamenicek: no-renewal really just means "public domain in the US"; there is no legal difference between PD-old, Pd/1923, PD-no-notice, and PD-no-renewal. Is the issue perhaps that the work is only PD in the US, but still in copyright in Czechia? --Xover (talk) 14:59, 26 June 2020 (UTC)
Yes, exactly, some of the poems are still in copyright in Czechia. --Jan Kameníček (talk) 20:30, 26 June 2020 (UTC)
@Jan.Kamenicek: There's an invisible U+FEFF character (aka. Unicode w:Word joiner) between the | in {{block left}} and the opening { of {{c}} in your original version of the page. Due to its position in the markup stream it effectively ends up giving you an additional seemingly-blank line in the output (Word joiner is an invisible character, so the line is visually empty, but it triggers the generation of a line-box that takes up space in the browser). --Xover (talk) 10:32, 26 June 2020 (UTC)
@Xover, @Ineuw: I have remembered that in the past I did something similar and it worked well and so I found it, see Page:Modern Czech Poetry, 1920.djvu/56. So I copied the code and adjusted it, and suddenly it started working as I desired, see A Book of Czech Verse/Jan Kollár. What is really strange is that the code seems absolutely the same as the one which did not work, as you can see in the diff.. I am glad it works now, but I have no clue why…
In fact there must be some invisible difference, as the line with {{lang|cs|inline=no|{{block left|{{c|{{larger|{{al|Ján Kollár|JAN KOLLÁR}}}}<br /> is highlighted in the diff, although visually I do not see anything different. --Jan Kameníček (talk) 20:26, 26 June 2020 (UTC)
Wonderful. I am glad you found what you preferred. — Ineuw (talk) 01:13, 27 June 2020 (UTC)
And I thank you for the effort to help me. Although I did not use it finally, I learnt a couple of good tricks.
However, I am really curious about the difference between the two seemingly identical "lines 1" at [18] and why they give different outputs… --Jan Kameníček (talk) 19:56, 27 June 2020 (UTC)
@Jan.Kamenicek: See my reply above. --Xover (talk) 20:22, 27 June 2020 (UTC)
@Xover: Ah, sorry, I did not get it at once, I was reading too quickly. These invisible characters make problems too often… Is there any way to make them visible in the editing windows? --Jan Kameníček (talk) 06:44, 28 June 2020 (UTC)
@Jan.Kamenicek: In theory, yes; but in practice, probably not. I use a programmers’ text editor that makes such characters visible. And if you know or suspect such a character is there you can often discover it by using the arrow keys to move the insertion point character by character. Most invisible characters will cause the insertion point to seemingly not move, because it is technically moving but over an invisible character so visually it stays put. In this specific case it also had disproportionate effect due to an unfortunate position in the markup, and it took me quite a bit of effort to figure out what was going on. Most of the time such invisible characters will either not create issues that anybody even notices, or their presence will be obvious from their effects. --Xover (talk) 09:16, 28 June 2020 (UTC)

Transclusion of pages from Oldwikisource

I am working on Index:A Book of Czech Verse.pdf which is a bilingual book with poems in Czech and English. It was written in such a way so that readers who can read both languages could compare the original versions of poems and their English translations. I believe it is worth keeping this intention after its transcription to English Wikisource too, similarly as I have done with Modern Czech Poetry.

It is quite natural that both English and Czech Wikisource can be interested in this work. Although I think it would be easier to transcribe it separately to both wikisources, I am considering Billinghurst’s suggestion to transcribe part of the above mentioned Index:A Book of Czech Verse.pdf outside en.ws and then transclude it here. There was also an interesting suggestion at Czech Wikisource to transribe either the whole work or its Czech part to oldwikisource (some poems are in copyright in Czechia and so the whole Czech part cannot be accepted at cs.ws) and then both English and Czech Wikisource can transclude what they want from there. If this is possible, I will be happy to transcribe it there, but first I would like to ask some questions to people who have some experience with both oldwikisource and interwiki transclusion:

  1. Is there an easy way to apply the same formatting I am used to apply at English Wikisource in such a case? Having look e. g. at the Wikidata item of the template:larger I cannot see its equivalent at mul. The templates I have used so far when transcribing the above mentioned work include e.g. {{lang}} (including its inline=no parameter), {{larger}}, {{block left}}, {{dhr}}, {{ditto}}… I am afraid that if I used some other templates instead, they would not work at en.ws after transclusion.
  2. How can the links be treated? If a page contains e.g. the name Ján Kollár, and it is going to be transcluded to both Czech and English Wikisource, is there a way how to link the name to Author:Ján Kollár when the page is transcluded to en.ws, and at the same time to cs:Autor:Ján Kollár when it is transcluded to cs.ws?

Answers to these questions would help me to consider whether the interwiki transclusion is worth the effort or whether it is better to transcribe it to both wikisources directly (using their local templates).

Another thing to consider is the "danger" of having some texts outsourced: if something goes wrong at the other wiki from which we transclude the text and they do not fix it, nobody may notice it for a long time here. --Jan Kameníček (talk) 18:59, 28 June 2020 (UTC)

Books from the Biodiversity Heritage Library

A mass upload of books from the Biodiversity Heritage Library, to Commons, is underway. Please assist in categorising them, and make use of them on Wikisource. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:07, 29 June 2020 (UTC)

Tech News: 2020-27

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

  • Everyone was logged out. This was because a few users saw the wikis as if they were logged in to someone else's account. The problem should be fixed now. [19]
  • Some readers didn't see new edits to pages. If the page had been recently changed they saw an older version of the page instead. This only affected readers who were logged out. It lasted for ten days. It has been fixed. [20]

Changes later this week

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

Future changes

  •   The Modern and Monobook skins use the ID searchGoButton for the go button. This is searchButton for Vector. To have the same ID for all skins it will change to searchButton in Monobook and Modern too. This will affect gadgets and user scripts. It will happen on 23 July. They should be updated to use searchButton. You can read more and see a list of affected scripts.

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

16:30, 29 June 2020 (UTC)

People moving unsourced pages to make an edition

Twice in the last couple of weeks I have seen editors moving unsourced versions of work to be subpages of a specific work. I have reverted those moves and left notes to the users. I just wanted to flag, to the community who may be watching, that this is not a practice that we want. If we have sourced pages that came from a work, then we can move them to be subpages; if they are unsourced, they, however, become their own version, and we create a versions page. We are happy to have editions, that is a good thing, not a negative. If you need a hand to tidy up, or to create version pages, etc. then please ask for it, as I doubt anyone, especially any admin, minds assisting. If an old unsourced page is problematic then utilise WS:PD. — billinghurst sDrewth 06:46, 22 June 2020 (UTC)

As a person to whom this post is undoubtedly referring, I have to take issue with this.
The Wikisource USP is supposed to be side by side transcription. The most recent case where the above person has undone things is Coleridge's poem 'Monody on the Death of Chatterton'. According to the Versions page for it, there are 5 different versions on the site (Coleridge kept revising it), none of which is sourced (i.e. has an index page). I moved the 1796 version to Coleridge's 'Poems on Various Subjects', which I have started transcribing from Index:Poems on Various Subjects - Coleridge (1796).djvu, since the Versions page stated that it came from that source. So now there two versions of the same thing, from the same source (one verifiable, the other not (and which also contains several obvious errors)). How is that 'a good thing'?
If you look at the statistics pages, the English Wikisource is by far and away the worst of the sites for unsourced work. As part of the transcription work I do, I try and do some that migrates unsourced texts (e.g. Milton's 'Paradise Regain'd', Addison's 'Cato', Johnson's 'Rasselas') to help improve this, but one wonders what the point of doing so is.Chrisguise (talk) 09:05, 22 June 2020 (UTC)
Not sure I'm following the rest of this issue, but I'll note that an unsourced text that is redundant to scan-backed text is eligible for speedy deletion. And, again without necessarily having direct relevance to this discussion, I think scan-backing existing unsourced texts is one of the most important tasks for the project, and among the best for improving our overall quality. Light bulb comes on… Oh, wait a minute… @Chrisguise: Did you move the page before scan-backing it? There's no real reason to do that, and when you do it can look like what you're doing is creating a new unsourced edition from random bits and pieces (or putting unsourced text inside the structure of a scan-backed edition). I would strongly recommend either proofreading or using Match&Split and then transcluding over the unsourced text first and then moving it within the work's structure afterwards. If you need to check the transclusion while the proofreading is still in progress you can easily do that in a sandbox (or with just preview in an edit window without saving). --Xover (talk) 10:38, 22 June 2020 (UTC)
(edit conflict)
I am not taking this issue up with specifics with anyone in this forum, this is the more general reference and reminder to community about what we do.
Yes, the preferred means for text reproduction is side-by-side transcription followed by transclusion. That does not mean that we move an unsourced version, and the work that you are referring to is simply unsourced, and you don't know the source that OR used to bring the work here, it is quite unlikely that it was directly from the 1796 edition, so it is its own version, that just means that when you have your new version that we move Monody on the Death of Chatterton (1796) to Monody on the Death of Chatterton (1796) unsourced (or similar) and make the former page the {{versions}} page. As I mentioned, at that point we can address whether we want to delete the unsourced version. The mention is on the disambiguation page is just that, where it was published, it is not the source of our work, which is unsourced, we don't presume.
Who gives a toss about the statistics page, that is not what drives us; there is no WORST, there is what there is. We deal with deletions by community consensus, not by someone unilaterally overwriting a version. — billinghurst sDrewth 10:51, 22 June 2020 (UTC)
Not that this has any relevance to the general point you're making here, but in this specific instance it actually happens that Ottava specified which edition it was from, and it was Ottava that added it to the versions page with the reference to the edition. Personally I would have been satisfied with just the year given in the title (the early editions of this poem are relatively well mapped), but the additional datum should be sufficient even for a stringent standard of evidence, I would argue. But this is of course an exception: many if not most unsourced texts are not so unequivocally identifiable to a specific edition (which is one reason I would typically vote delete in a proposed deletion discussion for such texts). --Xover (talk) 11:12, 22 June 2020 (UTC)
don't know why you are elevating here. add your sourced and unsourced version here Monody_on_the_Death_of_Chatterton. it appears to be a textural match, compared to other versions. redirect or transclusion, is better than move. Slowking4 ⚔ Rama's revenge 15:29, 22 June 2020 (UTC)
I don't see the point in having an unsourced version alongside a source version. A version that has some clear sourcing that's different from the sourced version might be worth keeping, but an unsourced version might have copyright problems, might have deliberate or accidental changes or errors, and has no audience. Anyone who doesn't care should be using the sourced version, and anyone who does care will be using the sourced version or find the correct, if untranscribed, version on Archive.org or HathiTrust. We shouldn't be adding replaced unsourced works to versions pages and make things more complex for no value; we should just be deleting them.--Prosfilaes (talk) 16:02, 23 June 2020 (UTC)
Maybe I am misunderstanding this, but if an unsourced work is (essentially) identical to a portion of a work that is in progress, I think the best thing to do is move the unsourced work to a subpage of the sourced work and then replace the unsourced content with a transcluded scan-backed copy. I do this a lot. It keeps the redirects and links all tidy and ensures that the work is improved by the addition of a source and a scan. —Beleg Tâl (talk) 16:47, 24 June 2020 (UTC)
As for my page moves, (being the other person here attacked,) I have created the Index: page here for the work which contained a large number of the hymns which I had moved.
In this instance, the earlier copy is not "unsourced", it is "unbacked by scan but with source identified". Adding the backing scan seems entirely the right action to take. --EncycloPetey (talk) 15:35, 10 July 2020 (UTC)

Tech News: 2020-26

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

  • There are some new tools to make it easier for newcomers to start editing. They are available on some wikis. These wikis had a problem with the visual editor for a short period of time last week. This was because of a bug in the new tools. It was soon fixed. [21]
  •   Some user scripts and gadgets stopped working because of a change to CSS selectors. .vectorTabs should be replaced with .vector-menu-tabs to fix this. [22]

Changes later this week

  • The developers are working on a new interface to solve edit conflicts on talk pages. This will be released on 24 June. You can give feedback. [23]
  •   The new version of MediaWiki will be on test wikis and MediaWiki.org from 23 June. It will be on non-Wikipedia wikis and some Wikipedias from 24 June. It will be on all wikis from 25 June (calendar).

Future changes

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

18:48, 22 June 2020 (UTC)

Changes to the Main Page are coming before 13 July

Regarding A temporary fix helped wikis make their main pages more mobile friendly. This was in 2012. It has not been recommended since 2017. It will not work after 13 July. above.

This change in MediaWiki necessitated changes to our Main Page, because the current version will be somewhat broken (on mobile) after the cutoff (mobile, desktop).

To address this I have made a new version at Main Page/sandbox new (mobile, desktop) that uses a different approach to achieving the same effect as the Mobile Frontend's "legacy transform"; slightly cleans up and modernises the code; and otherwise tries to make as few changes as possible.

These changes will have to be put in place no later than July 12 (I'll probably aim for doing it a little earlier), and before that it would be very good to have as extensive testing as possible in order to shake out the inevitable problems. Please include operating system and version (Windows, macOS, Linux, etc.); web browser (Safari, Chrome, Firefox, etc.) and version; type and preferably model of device (PC, Mac, iPhone, Galaxy, etc.); and, of course, a description of the problem. Reports confirming the absence of problems are also very useful!


Pinging users who have previously expressed an interest in this issue (but the more testers the better!): Pelagic, Billinghurst.

@Inductiveload: You have qualifications / interest relevant to this I believe?

@Mpaa: You're pretty technical. You around, and is this your cuppa?


As noted above this change is trying to mimic the existing version as best possible under the circumstances, so it is not "Main Page 2.0" or anything else that could be called a "redesign" or "new design". However I do think there's some potential for an actual redesign there to freshen up the design (a little; our design should be a little stodgy), make better use of available space, and perhaps rethink what we put on the mainpage and in what order they should be. Possibly some of the supporting templates could be beneficially rethought too to make them simpler to use. But that sort of thing would require proper community discussions unhampered by the looming deadline of MediaWiki changes, so that'll have wait for a different occasion. --Xover (talk) 08:13, 23 June 2020 (UTC)

@Xover: It seems to work pretty slickly for me. I only have one, non-critical observation:
  • The heading come out as UPPER CASE when it goes to single col mode. If you write them in "Title Case" in the template, and apply a CSS "text-transform: uppercase;" in the dual-col CSS only, you can avoid that
I have a few more in terms of general design on the page, but I don't want to mess with it in the same breath as fixing this. Inductiveload—talk/contribs 09:08, 23 June 2020 (UTC)
@Inductiveload: Fixed. The current version has sentence case so I went with that rather than title case. --Xover (talk) 10:00, 23 June 2020 (UTC)
Agreed, there are lots of things we could discuss, but let's not make a bikeshed-tarball. Maybe a sub-component of WS:IGD (under the "I")? I have other problems with various issues regarding CSS for export, printing, etc, as well as gadgets and sidenotes, which could all do with a central "sweat the small stuff" location. Inductiveload—talk/contribs 09:08, 23 June 2020 (UTC)
WS:GEARS where the gearheads collect issues and try to fix stuff? :) --Xover (talk) 10:05, 23 June 2020 (UTC)
Ok, the switchover to the new code has been completed and all is looking good so far. Please report any problems here (and feel free to ping me).
There is some cleanup needed in site-global CSS (MediaWiki:Common.css and various Gadgets), but as that requires interface-admin rights it'll have to wait until I get around to setting up 2FA (or someone else with 2FA enabled and a technical bent feels like having a go). --Xover (talk) 08:57, 10 July 2020 (UTC)
@Xover: I have 2FA (it's quite easy, BTW), but I haven't got interface-admin rights. What exactly needs doing at Common.css and gadgets (specifically related to this, as opposed to the big ol' slop-bucket of random other issues?). Inductiveload—talk/contribs 09:36, 10 July 2020 (UTC)
@Inductiveload: MW 2FA has some… issues… and I already have it on my developer account, so I've been loath to have to start juggling two sets of 2FA. Mostly it's just procrastinating because I need to set aside the time to do it properly.
In any case, if you want to have a stab at it, there are Main Page-specific style rules spread around a couple of places. Some, I believe, are in MediaWiki:Common.css or stylesheets loaded from there. Some are in various Gadgets in MediaWiki:-space. These rules include ones affecting Main Page/sandbox by page title, as well as Main Page itself. All these style rules are now redundant and should be removed, both to avoid interfering with the TemplateStyles-loaded styles and for maintainability reasons. I'd be more specific, but it's been too long since I was spelunking around in that mess, sorry.
As for interface-admin, to my never ending annoyance, the issue has been up for discussion multiple times and ended up concluding we should treat it like the other local special permission bits: ask the local bureaucrats (Hesperian and mpaa) to assign it ad hoc for whatever time period you need it. Requests go on WS:AN#Bureaucrat requests, but it's probably a good idea to ping them as neither one is very active lately (hopefully not for Covid-related reasons). As far as I know, we've never actually tested this process, but I believe Mpaa has confirmed they have the technical ability to assign the permission. --Xover (talk) 13:58, 10 July 2020 (UTC)
@Xover: [insert video-game power-up sound]. Looks like on MediaWiki:Common.css, all the hdng rules can be killed, is that right? this search seems to indicate it's not actually used anywhere.
MediaWiki:Dynimg.css, ( the only other thing of note called from MediaWiki:Common.css) needs to become TemplateStyles from {{FI}} and any other related templates, but it'll need a little care to avoid a period of breakage during changeover.
MediaWiki:Gadget-Site.css is a mess and can be gradually reduced by breaking out TemplateStyles and working out what is obsolete.
MediaWiki:Gadget-enws-mainpage.css appears entirely unused: I can't see where, if anywhere calls that. MediaWiki:Gadgets-definition doesn't mention it. Inductiveload—talk/contribs 21:08, 11 July 2020 (UTC)
@Inductiveload: You've got it. If MediaWiki:Gadgets-definition doesn't mention MediaWiki:Gadget-enws-mainpage.css then it doesn't get loaded and can be deleted outright. MediaWiki:Common.css and MediaWiki:Gadget-Site.css should be systematically emptied by identifying unused rules that can be removed, and rules that can be migrated to TemplateStyles where they are actually used. I'll give good odds there is nothing, or nearly nothing, that actually needs to be in the site-wide styles. The abuse filter editor thing in Common.css, for example, is not unlikely to have been fixed "upstream" since the custom rule was added here, or, alternately, the ~5 users that ever touch the abuse filter editor can have that rule in their Special:MyPage/common.css so it doesn't get loaded un-optimized for every single user of the site. Heck, it'd even make more sense to make that one rule a separate Gadget that is not enabled by default, as that puts it within ResourceLoader's control.
What's needed for the immediate issue is just to get rid of any CSS that targets the Main Page; but beyond that the utter mess of CSS and JS needs to be cleaned up, modernised, and pruned. Some of it is now plain broken by the intervening changes in MediaWiki, but mostly it's that it is messy in a way that makes it hard to maintain and hard to make wanted changes to.
BTW… Back just before interface-admin and the 2FA requirement from WMF Legal put a bit of a crimp on my grandiose plans, I asked the community about how much a priori control was wanted for this, and the conclusion was that it's ok to just clean stuff up and retroactively fix anything that breaks. In other words, I think that so long as you don't go so fast that it gets impossible to identify and fix any unintended breakage you should just have at it. Bigger changes to behaviour or look still need community approval, of course, but changes that are primarily technical should be within your remit to just go ahead with. --Xover (talk) 07:46, 12 July 2020 (UTC)
A great "responsive" layout! The two-column to one-column transition happens at a little bit narrower than where Timeless hides its left panel, so it's not jarring as you resize the window. I miss the Current Collaborations panel in old mobile and new narrow views, but that's a separate discussion. Is a copy of the old layout preserved somewhere? I haven't tried all the desktop skins but can confirm it's fine on iOS devices. Much thanks, Xover, for creating this. Pelagic (talk) 06:07, 14 July 2020 (UTC)
@Pelagic: Thanks for checking! The old layout is kinda sorta preserved in the edit history; but since a lot of the main page content is provided by templates, it's a good bit of digging to piece it together. The new layout should be essentially identical, with just minor variations; and it is explicitly not a "new layout" so much as a "new way to make it look the same".
But I think we're now in a good place to discuss an actual redesign of the Main Page. Issues such as what widgets should appear there, and in what order (prominence), and who is the Main Page for (readers/visitors, or Wikisourcers/contributors; ie. should the collaboration be there at all?). There is plenty of opportunity to make the current design "smoother" if we're not trying to preserve old design elements (like the 55%/45% width split of the two columns), and lots of opportunity to make it "fancier" if we want. GOIII started on this half a decade ago, with rounded corners, gradients in the headers, some shadow effects, etc. Some of those things we might want to adopt, some not (design sensibilities have evolved a lot since then). We might want to get real fancy and have a carousel of featured items up top, or we might prefer to keep things simpler and a bit stodgy (because we are by nature a bit of a stodgy project).
I may try to mock up something at some point, but for now I'm hoping people at least do some thinking on what we can do, and what we want to do. Brainstorming, is maybe the short description. And anybody with thoughts or ideas should feel free to kickstart such a thread here (otherwise I'll do it when I get around to collecting some kind of coherent thought about it). --Xover (talk) 07:00, 14 July 2020 (UTC)

Adding texttip functionality to Template:Reconstruct

The title speaks for itself. If somebody is not familiar with the formatted output of Template:Reconstruct, the angle brackets look strange and (in my opinion) harm the authenticity of the text. Adding a "texttip" parameter to the template could provide additional context for the reconstruction; the word or phrase as it appears in the scan could be provided, for example. --EnronEvolved (talk) 17:15, 27 June 2020 (UTC)

@EnronEvolved: I'm inclined to agree. I have added a tooltip with an optional reason parameter. I also think the angle brackets are a bit much. They are indeed used in this way in textual criticism, but WS is not a textual criticism. I'd support to remove them, or at least make them optional and default "off". Inductiveload—talk/contribs 20:31, 15 July 2020 (UTC)
Retrieved from "https://en.wikisource.org/w/index.php?title=Wikisource:Scriptorium/Archives/2020-06&oldid=12574331"