Jump to content

Wikisource:Scriptorium/Archives/2020-05

From Wikisource

These things bother me

(There's 'inclusionism' and 'deletionism', is there 'consistentism'?)

Looking the the multi-column widgets, and saw those templates are protected, except one.

Shenme (talk) 02:17, 2 May 2020 (UTC)

The unprotected template was created two years after the other three were protected. --EncycloPetey (talk) 02:19, 2 May 2020 (UTC)
Those are things that bother you? Glad that is the minutiae that gets your attraction. To me there are way bigger issues, and fixes. In fact, the template's use bothers me more. It is very undesirable and I would love to kill its use in page: ns, and I hope that is not why you are looking at it. — billinghurst sDrewth 05:02, 2 May 2020 (UTC)
No, just noticing upon reviewing all four templates for education. The "way bigger issues" require more deep context and experience to notice than I would possess. Though, cleanup tasks might interest some otherwise unaware of them. Is there a list or musings to look at? Shenme (talk) 18:19, 2 May 2020 (UTC)

Completed uploading the League of Nations Treaty Series on Commons

Would anyone please consider transcluding the files under commons:Category:League of Nations Treaty Series into source texts? The texts were published in French first then English from 1920 to 1946, plus any other authentic texts.--Jusjih (talk) 05:07, 4 May 2020 (UTC)

Projects similar to Wikisource

https://fromthepage.com/findaprojectJustin (koavf)TCM 06:53, 4 May 2020 (UTC)

16:59, 4 May 2020 (UTC)

FYI: British History Online—limited wider free access

Free access to all BHO content

From Friday 27 March, we’re making the transcribed texts of these additional 200 volumes available in full to individual users who visit the BHO site.

We’re very aware of the current challenges faced by students and researchers with the closure of universities, libraries and archives. We hope that by releasing these additional volumes BHO can provide access to a wider selection of valuable research materials. This extended access currently runs to 31 July 2020.

... (full description at link)

https://blog.history.ac.uk/2020/03/british-history-online-makes-all-research-content-free-to-individual-users/

This may be of interest to some. Plenty of their resources is typically free, however, some is not, and they have opened their doors. — billinghurst sDrewth 03:19, 6 May 2020 (UTC)

Bot task: archive pages category

Please can someone use a bot or script to add all sub-pages of Wikisource:Scriptorium/Archives (e.g. Wikisource:Scriptorium/Archives/2020-01) to Category:Scriptorium archives? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:54, 7 May 2020 (UTC)

For what purpose? Not certain why we would want to categorise the pages when they all sit in a hierarchy. — billinghurst sDrewth 12:40, 7 May 2020 (UTC)
I'm sure I'm not alone in finding such frequent negativity tiresome, and thus being disinclined to volunteer more of my time here. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:23, 7 May 2020 (UTC)
Don't shit me Andy. That is not negativity, that is asking a question to understand what we are doing, for what outcome, amd considering how to best achieve it. That is what we do with bot requests. As you are asking someone else to do something for you, we are not entitled to know the why? Why couldn't you simply answer rather than doubling down?
We have a page hierarchy set up, it is simply easier to transclude the special page and dump the list, which I have done. But I cannot give you the best result without knowing what you are trying to achieve. Not certain why we want to categorise them when they sit in a page hierarchy. — billinghurst sDrewth 13:52, 7 May 2020 (UTC)
"Not certain why we would want to" is not a question; it's negativity, pure and simple, so it appears to be you who is "shitting". And while we can "transclude the special page and dump the list" and that may indeed be "easier", it is not better, and does not have the same beneficial effect, as can be seen at the foot of every transcluded page, where the link to the category is... oh, wait, there isn't one. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:28, 7 May 2020 (UTC)
Not all ideas are good; getting annoyed when people question your ideas doesn't help in a collaborative project.--Prosfilaes (talk) 17:20, 7 May 2020 (UTC)

Lua module error

While adding the Wikidata info for Narrative of the life and adventures of Paul Cuffe, the software generated the following error message:

Lua error in Module:Edition at line 229: attempt to concatenate local 'badgeName' (a nil value).

This warning appears to be displayed on every page with a Wikidata item. Whatever mechanism was set up for pulling the badge information from Wikidata has broken, so hundreds of works now display this error message. --EncycloPetey (talk) 18:40, 7 May 2020 (UTC)

I believe Kaldari was working on something related a few months ago -- pinging in case it's relevant. -Pete (talk) 18:46, 7 May 2020 (UTC)
Looking... Kaldari (talk) 18:58, 7 May 2020 (UTC)
@EncycloPetey, @Peteforsyth: This looks like a wider Wikidata bug, as I'm seeing similar problems on other wikis that try to pull Wikidata labels via Lua. I've put in a workaround for now. Unfortunately, you may have to purge the cache of the page (by making a null edit) to get the error to go away. Kaldari (talk) 19:58, 7 May 2020 (UTC)
But this wasn't happening on just one page. It was happening on every page I looked at that has its proofread status marked on Wikidata. The workaround seems to have cleared the problem however, so hopefully it has done so for all of those pages. --EncycloPetey (talk) 19:59, 7 May 2020 (UTC)

You may have lost a long-term contributor because of apparent 'blindness' to a technical problem...

What should have been relatively simple to repair...Namely the lint erorrs in Page namespace here, has resulted in a lot of 'head-against-desk' moments.

This is not an unknown issue, given that there was a phabricator ticket about the attempted tidy up that occurs.

The blindness is not on the part of contributors and admins here, who are very aware of the issue raised here. The 'blindness' exists amongst certain other people I asked about this, whose response was that what was happening was the intended behaviour, which on a wiki that wasn't using proofread page would be understandable.

The other blindness was suggesting that the 'fix' was as I understood it to rewrite pages to conform to what the parser was actually doing, rather then what previous contributors thought or assumed it was doing. Again on another wiki, where pages get edited on a regular basis this would be partly expected. However on Wikisource, pages are generally not edited once they've reached a "stable" validated version, and editing half a million or so pages because of technical update is perhaps stretching the expectations of what a 'volunteer' effort can do. Re-writing pages was what the attempted changes on the pages were trying to do. However, for whatever reason, EVERY solution tried so far has seemingly had it's own issues, and NONE of them are a complete or stable solution.

A third 'blindness' was the suggestion to use POEM tags instead of BR. Yes, this would in some instances resolve the issues of multiple BR tags, However POEM generates it's own DIV wrapper internally, which in some instances is undesirable. Also in it's current form there is no <poem role=start><poem role=continuation><poem role=end> syntax to allow content formatted using it to span across Page: breaks. Having to guess where to put specfic line-feeds to do the tags page by page inline does not represent a stable-solution for contributors like myself.

As was pointed out, I am not compelled to sort of technical problems, so unless a long-term solution to this is forthcoming on a reasonable time-scale, I am considering if I desist from contributing anything to this project at-all, because I can no longer assume Mediawiki can actually support the Proofread page style arrangements in a stable, consistent and usable manner. ShakespeareFan00 (talk) 11:37, 7 May 2020 (UTC)

You choose to be concerned about lint issues, some of us are concerned about transcription and transcluding and couldn't give a toss about lint for lint's sake. We choose our battles. We are all free to make our choices. — billinghurst sDrewth 12:37, 7 May 2020 (UTC)
Thank you for a voice of sanity. And thanks for your suggestions regarding transcluded references on Phabricator.

ShakespeareFan00 (talk) 13:50, 7 May 2020 (UTC)

Query , Is there a way to filter the LintErrors reporting so the analysis excludes noincluded portions (like Header, footer or documentation content). You already I think expressed a view somewhere thatit was a waste of effort to repair talk namespaces (and for that matter certain archives in Wikisource:) namespace. I am starting to have the view that trying to repair endless headers and footer content, no one is going to see expect when transcribing is also a similar drain on resources? ShakespeareFan00 (talk) 13:50, 7 May 2020 (UTC)
The majority of our templates are sizing or positioning. What will typically break is that the span sizing, so the words will be a different size from expected. Almost a case of big deal. We have templates that break pages or push transclusion limits that kill the display of a page, and we are concerned about a bit of sizing of text? We have tens of works that are not transcluded. I know where my time is better spent. — billinghurst sDrewth 14:18, 7 May 2020 (UTC)
Template:Polytonic is a span template, and the usage there has <br /> and new lines. It will always trip up. It will need to be done as a <p> or a <div> — billinghurst sDrewth 14:40, 7 May 2020 (UTC)
What's happening is also related to what happens here... Page:Beowulf (Wyatt).djvu/115. In that there is NO line feed after a DIV which is opened in the header... or converserely there's no line-feed in the footer to force the behaviour...
<DIV><!-- No line break--><SPAN>
....
<SPAN>
<DIV>

when for mediawiki purposes what's technically needed is

<DIV>
<SPAN>
....
<SPAN>
<DIV>

Because the appropriate linebreaks between the opening DIV and opening SPAN are present on transclusion, this headache isn't present in transclusion. This as you say isn't a major concern, but it generates a LOT of 'useless' noise in Special:Lint-Errors

I did however find a work-around for putting {{center}} inside a {{float-left}}.. I had been using {{span|dpb|ac}} which seems to cure the div-span swap errors that resulted as well as NOT changing the intended layout. :). Various other block in a span or block in a paragraph problems can be resolved using this workaround. And given how you and other contributors set up the sidenotes, the same approach should in principle also be applicable to them. It's not a complete soloution for that, and I'm sure you would be the first to point out certain technical limitations on doing it that way.ShakespeareFan00 (talk)

If {{lang}} usage is getting highlighted as a breach of a <span>, then use {{lang block}} per its /doc page. — billinghurst sDrewth 22:47, 7 May 2020 (UTC)
We don't have a corresponding block template for {{polytonic}}. If we did, I expect it would solve a lot of the lang-related lint issues. Polytonic is not about a particular language, but about handling the pre-20th century forms of text written in Greek script, which included a set of diacritical markings not present in the current form of the language. --EncycloPetey (talk) 02:16, 8 May 2020 (UTC)
We have {{polytonic/s}} and {{polytonic/e}} because I 'cloned' them last night, also {{greek/s}} and {{greek/e}}
I'm using the /s /e convention for block templates. (but see my subsequent topic below.)
Well that approach is problematic. Firstly, please stop and think before acting, and implement an approach that is long term resilient and robust, not another ugly patch. Where we have a span and a block alternative, the block has used the BLOCK nomenclature, and then has the /s /e added to it. Please do not make /s /e based on the span alternative, you are just confusing matters. Also with all of these templates we have tried to have an underlying base template, where the variants spawn from the parent. They are also documented singularly based on the base template, and variations noted. We have {{lang}}, {tl|lang block}}, {{lang block/s}} and {{lang block/s}} as base templates that should be utilised. — billinghurst sDrewth 02:17, 9 May 2020 (UTC)
don't know why you are irritated by "whose response was that what was happening was the intended behaviour," this project has historically been unsupported, dependent on one volunteer hacker to maintain page code. we were lucky to get temporary attention for google OCR and VE, as much as WMF likes to market the global south wikisources. step back, and check out the other transcription projects off-wiki. there are plusses and minuses - you will be better appreciated, but the code will be opaque. treat wiki as the bad boyfriend: set lots of boundries, with lots of time outs. Slowking4Rama's revenge 23:02, 8 May 2020 (UTC)


Its seems that there is a problem of documentation. I'm not prepared to continue contributing until someone that knows what they are doing can actually sit down and properly document how things like this are SUPPOSED to be done for the long term. I'd also like an apology for my wasted time.

ShakespeareFan00 (talk) 10:44, 9 May 2020 (UTC) ShakespeareFan00 (talk) 10:46, 9 May 2020 (UTC)

Putting ultimatums to your fellow volunteers, especially those who have been around cleaning up other people's messes, including yours, is just bad form. If you need a break, take a break. Otherwise, please take your martyrdom somewhere private, your entrails are showing. — billinghurst sDrewth 11:23, 9 May 2020 (UTC)

Aribtary break

Okay deep breath. Once again you are voice of sanity, and
A good response would be that someone implements {{polytonic block}}{{polytonic block/s}}{{polytonic block/e}} in an appropriate manner. The difference from a standard lang call, is that the XML-lang tag seems to be set up directly (same approach as {{lang}} but implemented directly for performance reasons perhaps? It also chooses the font with a stylesheet (not a font param).
I've also in reviewing some other template code, found some other /s /e versions of templates that don't math what appears to be the naming convention.

Per the naming conventions and usage these I think should be "_block/s" "_block/e" pairs instead, notwithstanding that at present the parent block template for the group might not yet exist. ShakespeareFan00 (talk) 11:59, 9 May 2020 (UTC)


Conventions for naming block equivalent versions of span templates.

Currently there are two approaches used. One is to append -block or block to the name, with /s /e then added for the start and end variants...

Some templates have bypassed this, and use /s and /e directly for thier block version pairs (albiet without a corresponding template for a block that sits within an entire page.

It would be reasonable, to perhaps establish one naming convention moving forward?

(Aside: With some templates, the /s /e BLOCK versions do not behave identically to their SPAN versions.. {{float left/s}} for example doesn't even accept the same parameters as {{float-left}}, which is confusing. Maybe someone competent should re-align templates like this so the behaviour IS consistent? ) ShakespeareFan00 (talk) 08:54, 8 May 2020 (UTC)

There is a convention, that there are a few examples of it not being used, means they should be fixed, not propagated. — billinghurst sDrewth 02:19, 9 May 2020 (UTC)
There is a convention but it's not actually documented anywhere, and as SF00 points out there are clearly divergent and inconsistent applications of it. I absolutely agree with billinghurst that diverging examples should be fixed rather than propagated, but I think we need to approach that somewhat systematically. And since a lot of the divergent cases will be in fairly broad use, I think we will need at least a modicum of discussion for each instance before we go ahead with any actual changes. Maybe not for simple renames that leave a redirect behind; but things like merging the inline and block versions to use same/similar code and taking the same arguments should be approached with some caution. --Xover (talk) 07:10, 9 May 2020 (UTC)
Right so the next question is what the naming conventions is for
  1. The inital span-based template.
  2. It's block equivalent
  3. the "paired version" for Page: namespace

? ShakespeareFan00 (talk) 14:33, 9 May 2020 (UTC)

The consensus would seem to be {{foo}} {{foo block}} {{foo block/s}} {{foo block/e}} ?

Conversely there are templates like {{center}} which are conventionaly block based but which for certain purposes a span based version would be useful. should these be named Template:Foo inline or Template:Foo span ? ShakespeareFan00 (talk) 14:33, 9 May 2020 (UTC)

Centering should always be a div template; it is necessarily a function applied to a block of text to reposition it in the center. A span template, when it exists, allows the function to be applied to part of a line of text. I can think of no situations where we would center a word within an un-centered line of text. There are likewise going to be some templates that should only ever be span, and never div. --EncycloPetey (talk) 15:06, 9 May 2020 (UTC)
The instance is where the nominal parameter of template is span based.. so you do something like this to get a centered heading in a sidenote for example.
...
This is only an example {{sidenote|{{span|dpb|ac}}heading</span> Rest of sidenote.}}  Rest of main body of text...

The other instance when having an 'in-line' version of centerain templates is inside {{FI}} image captions, although In the sandbox version I wrote a multicap option to try and resolve that issue..

(ASIDE: See also {{FIS-c}}, for an inline-floated to the center image. - Because of how FIS works, all the caption content must be necessity be a SPAN because of HTML conventions. Thus a SPAN based centering would have to exist for that, (albiet it's an in-line block Convoluted, but that's what's provided... ShakespeareFan00 (talk) 16:19, 9 May 2020 (UTC)

Lint-noise

The Lint-noise (and I will call it noise (because as it's not showing a major structural problem) about misnsted SPAN's with header DIV SPAN combos, I was experiencing is easily solved, like this.

Header:

{{fooblock/s}}
<!-- -->

Body

{{barspan|content}}
...

Placing the comment seems to force the tidy-up without adding any line-feeds in the Page:namespace.. It also doesn't add any lines on the transclusion, which I checked.

Given how this handling seems to work, an approach like you used for on tables might also work. with a {{@force}} dummy template at the start of the page. However, I'm concerned that approach might introduce line-feeds on transclusion which is course completely undesirable.

An analogous situation can be applied to a SPAN DIV closing situation in a footer. (The comment line and line-feed needing to at the start of the footer. I put a comment rather than a blank-line, so it's not seen as entirely white-space.

If this relatively easy fix can be applied more universally, then I'd like to consider applying it, alongside other reviews for missing formatting or removal of typos as it is undertaken. ShakespeareFan00 (talk) 12:05, 9 May 2020 (UTC)

Index:Japan-Korea GSOMIA (English Text).pdf

The source file of this index was deleted from Commons by Krd (talkcontribs). * Pppery * it has begun... 19:55, 11 May 2020 (UTC)

@Pppery: Thanks for the notification. I have recovered the file and moved it locally, and opened a conversation at WS:CV to have the conversation here about our considerations. — billinghurst sDrewth 02:21, 12 May 2020 (UTC)

20:40, 11 May 2020 (UTC)

More indexes with deleted source files

* Pppery * it has begun... 02:29, 12 May 2020 (UTC)

Was there a style guide for this because it seems to change style mid-book ?

I'm also finding that although 'validated', a lot of lint-errors are showing up, something that I thought validation was supposed to catch? (Not that I'm the best person to comment, given some of my less than prefect validation in the past). ShakespeareFan00 (talk) 22:09, 4 May 2020 (UTC)

The work has been completed by users who are not usual editors of enWS, and they have applied different styles and techniques. Validation is typically only about the text and typical formatting, that it has a lint error means nothing to validation. Lint errors are a process that WMF uses to identify coding that does not align with a standard, nothing more, nothing less.
I started working through transcluding this work yesterday, and I am slowly fixing the formatting, please leave it and ignore it for the while. It also has publishing difficulties that make it slower to transclude. I will need to bot it again as trying to fix all the errors in one hit is problematic with different editors using different syntax. — billinghurst sDrewth 22:24, 4 May 2020 (UTC)
Transcluded and running some span <-> div swaps. Feel free to run some checks after user:sDrewthbot has finished its run. I am guessing that I won't have got it all. It had lots of contributors, and lots of styles. — billinghurst sDrewth 18:32, 6 May 2020 (UTC)
Markign this as Done unless someone has specific that they see as problematic. — billinghurst sDrewth 15:44, 9 May 2020 (UTC)

Noting the works for a later bot cleanup:

I am uncertain that the former of these is out of copyright in the US. @Rachmat04: who I am guessing is having some role. I will have to look further tomorrow, too late now. — billinghurst sDrewth 15:42, 9 May 2020 (UTC)

Dear everyone. Apologize for creating a mess. The participants were notified about the style and they were asked to follow the guidelines here, but most of them are new at Wikisource and sometimes they think they need to format the paragraphs as in the book. I will inform them again shortly and clean up the formatting. Thank you! ··· 🌸 Rachmat04 · 16:06, 9 May 2020 (UTC)
@Rachmat04: When running things like Kompetisi Wikisource 2020 and Pengguna peserta kompetisi beasiswa ke Jakarta nonton bareng Truth in Numbers on English Wikisource then please at the very least notify us (on our Scriptorium) that you are going to do so, and it would be strongly preferable if you designated someone that could coordinate with the community here. Big bonus points for having a page with information about the competition (or whatever it is) in English if English Wikisource will be more than trivially involved. Anyone can contribute, and we're obviously happy to see any new contributor on the project, but having a bunch of people suddenly swarm in with little familiarity with the local practices is just a recipe for disaster. --Xover (talk) 07:14, 10 May 2020 (UTC)
<standard URAA comment about following WMF legal advice to the letter>--Slowking4Rama's revenge 14:21, 13 May 2020 (UTC)
even better add the link m:Wikilegal/Use of Foreign Works Restored under the URAA on Commonsbillinghurst sDrewth 04:36, 14 May 2020 (UTC)

A question about Preferences

Is there a history of edits in either of the my Local and Global Preferences? — Ineuw (talk) 22:34, 10 May 2020 (UTC)

Nothing visible, they are your preferences, not edits, so there is no need for public information. — billinghurst sDrewth 11:54, 11 May 2020 (UTC)
Further questions about preferences would be better among the tech heads at mw: rather than here. — billinghurst sDrewth 11:55, 11 May 2020 (UTC)

History of global and local preference changes

Is there such a thing as a history record of a user's Preference edits?— Ineuw (talk) 02:20, 16 May 2020 (UTC)

@Ineuw: No, sorry. Your changes to the preferences are not "edits" in any meaningful sense. They're like the preference settings in your web browser or other software. It's not unlikely the software logs them somewhere, but that'd be in low-level logs that are not exposed anywhere and would need a pretty severe situation of some kind to justify the developers accessing them. --Xover (talk) 07:50, 16 May 2020 (UTC)
@Ineuw: This is pretty much the second time you have asked that question. I am uncertain why, when you know the solution, that you continue to look for the problem. All of these questions are Mediawiki questions, not enWS questions, and you are better to take them all to mediawikiwiki for the detailed answers. You have had them addressed in the phabricator ticket that you raised. — billinghurst sDrewth 08:06, 16 May 2020 (UTC)

Do we have a template like, for example, w:Template:Interlanguage link? It allows users to enter a red link for a non-existent but plausible page which is followed by a parenthetical link to an equivalent page on a sister project. When the red link is created, the sister link is hidden and the regular link is displayed. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:29, 17 May 2020 (UTC)

Importing images from Wikidata in author-pages

We had an excellent system of automatically importing images from Wikidata in author-pages. But now some items on wikidata have more than one image, and this creates problems. See e.g. Author:Edwin Ray Lankester. It does not look very useful to me to have more than one image on wikidata, but apart from that, we now have no image at all at our author-pages. What is the opinion about this? --Dick Bos (talk) 11:41, 10 May 2020 (UTC)

@Dick Bos: We fix it. Pop over to WD and make one preferred. If you are after the list that needs attention, then category:Pages with missing filesbillinghurst sDrewth 13:03, 10 May 2020 (UTC)
@Dick Bos: Fix the template. For example, species:Template:Image handles this well. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:53, 10 May 2020 (UTC)
I am afraid that the supposition that we will keep up with the bots adding non-sencically another (usually worse) image to items which have already had one did not prove right. I have corrected some, but I have other work to do, and so probably do other people too. The problem has been continuing for several weeks (i. e. some of our author pages have been lacking images for several weeks) and nobody knows how long it will continue. And after we finally fix all the broken images, nobody knows when the bots create new mess. Some of the images I checked were really bad and so I removed them from Wikidata completely, but I guess the bot may add them again after some time. Unfortunately, Wikidata lacks any systematic control of the bots and too many people are allowed there to make hundreds of thousands of contributions without any supervision. So if we want to use Wikidata, we also have to create our defence against irresponsible WD bot operators and set the templates to ignore newly added images until a human checks them (and possibly decides that the new one is better and sets it as a preferred one). --Jan Kameníček (talk) 21:15, 10 May 2020 (UTC)
I can't parse "non-sencically"; but to which bots do you refer? Can you provide a diff of a "bot creating new mess"? No-one is "allowed there to make hundreds of thousands of contributions without any supervision"; please don't spread such disinformation. I described the best the solution, in the post under which you have commented. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:30, 11 May 2020 (UTC)
I thought it was clear that I wrote the contribution to support your suggested solution, I am sorry if it was not.
Here is a diff] of one of many examples of a bot creating mess, here with a picture of Jan Hus. Portraits of many historical people are just imaginary as nobody often really knows their real appearence. But the bot added a portrait with which it is even not sure whether the unknown painter wanted to depict Jan Hus or somebody completely different, despite the fact that there already was a portrait widely known as depicting Jan Hus and there are also other different portraits in Commons, but the bot added the worst one of them all (and the result was that Wikisource did not show any). I would understand it if there was no image at WD, but there was quite a good one. If the only reason for adding this ambiguous portrait was, as EncyloPetey suggests, that they have this portrait in Catalan Wikipedia, it is one of the worst reasons I can imagine. --Jan Kameníček (talk) 17:42, 11 May 2020 (UTC)
As I've noted elsewhere, these images are most often imported from the Catalan Wikipedia. Making an edit over there to replace a bad image with a better one will typically correct the problem. The other solution would be to request someone with a bot at Wikidata to identify data items for humans that have more than one image, and process them by setting one image to preferred status. --EncycloPetey (talk) 15:43, 11 May 2020 (UTC)
One of the purposes of Wikidata is helping to solve some issues centrally so that they do not have to be solved locally in every single Wikipedia. So why should contributors to a local project go correcting issues to another local project? If Wikidata has a better image than Catalan Wikipedia, there is no reason why Catalan Wikipedia should push their image there. Second image should be added to Wikidata only if there is a good reason to do so. If the reason is that the other image is better, they should remove the worse one at the same time. If the reason is that the image depicts the person e. g. at a different age, they should state so using the qualifier and set the rank of preference. But this should be done immediately upon adding the image, not many weeks later after some other contributor accidentally notices that the image in their local project disappeared. If Wikidata contributors are allowed to run bots without taking responsibility for these basic issues, we need to protect ourselves. About 340(!) author pages are currently experiencing this problem (and there were many more, as people have already fixed many of them). Our contributors should spend their time in a better way than fixing 340 pictures in Catalan WP. And the main thing is that the author pages should not be lacking images until somebody notices and fixes Catalan WP. We need to set our templates in such a way that they would protect us from such problems. --Jan Kameníček (talk) 17:42, 11 May 2020 (UTC)
don't know why you are complaining about wikidata here. a little image quality circle at wikidata could knock out this image issue in no time, and maintain a preferred image. demanding bot operators do it before the fact, is a recipe for drama. you don't want to delete the image, but rather you should deprecate it to avoid edit warring with a bot.Slowking4Rama's revenge 14:00, 13 May 2020 (UTC)

Period in the title in the template

Should it be "First Sentence in the Title. Second Sentence in the Title" or "First Sentence in the Title. Second Sentence in the Title." in the template for title. Note the period at the end of the second one. I see a mix of the two in use. --Richard Arthur Norton (1958- ) (talk) 02:41, 18 May 2020 (UTC)

Are you asking about {{BASEPAGENAME}} or the title parameter in the header template?
  • If the former, then usually just the title, rather than the subtitle of the work. Never have a terminating space in a BASEPAGENAME / url as it will fail miserably in a copy and paste, especially to something like twitter.
  • If the title field, I have seen both, and I have seen a colon used too, and I think that colon is the current guidance for "title: subtitle". My practical guidance is that we don't want to be over-powering the header field, or having prodigious line wraps. If it is shorter then it's fine, if it is really long, then don't, as the title page is sufficiently descriptive, though if it is long and you want it, then consider put the title/subtitle into the notes field
Be mindful to guidance like https://www.annemini.com/category/how-to/how-to-format-a-title-page-if-your-book-has-a-subtitle/ and the value in what you are reproducing and to the reader. — billinghurst sDrewth 04:00, 18 May 2020 (UTC)

17:18, 18 May 2020 (UTC)

Discord Chat/Channel in the "Wikimedia Community" Discord server

Would anyone here be interested in getting Wikisource specific chat in the Wikimedia Community discord server, en.wikipedia.org/wiki/Wikipedia:Discord, in order to help with coordination, project news, project advertising, etc. If we don't want to be involved in the main server, we could create a Wikisource specific server for ourselves instead.

Link for anyone interested discord.com/invite/e8xxGMP --Reboot01 (talk) 04:11, 17 May 2020 (UTC)

@Reboot01: I honestly think there should be a Wikisource-specific server. I created a Wiktionary-specific server in 2018, for instance (for info on that, see wikt:Wiktionary:Discord server). PseudoSkull (talk) 22:02, 17 May 2020 (UTC)
I agree, then it'll allow us to have separate chats for different wikiprojects, and cross-language wikisource collaboration if other language wikisource's join. --Reboot01 (talk) 23:02, 17 May 2020 (UTC)
I don't feel it appropriate for me to create the server since I'm not an admin, but I'm more than willing to help out in any way I can! The Wiktionary server has proven to be very useful and effective, and is being used actively at present. PseudoSkull (talk) 00:22, 18 May 2020 (UTC)
Are there any admins who would be willing to sort of 'sponsor'/create the Discord server? --Reboot01 (talk) 21:31, 19 May 2020 (UTC)

Vandalism

Hi Admins, I reverted some modifications by User:2604:6000:100E:8160:D069:14F:F972:D1B0. Should his new pages be deleted? --M-le-mot-dit (talk) 05:42, 20 May 2020 (UTC)

@M-le-mot-dit: Thanks for letting us know. The new pages have been deleted. PS. You may want to post message specifically for the admins at WS:AN since that's a lot less trafficked and may be noticed quicker. --Xover (talk) 06:01, 20 May 2020 (UTC)

Duplicate Index.

Index:First six books of the elements of Euclid 1847 Byrne.djvu and Index:The first six books of the Elements of Euclid.pdf

Which to retain given that the first linked entry already had some effort attached to it? ShakespeareFan00 (talk) 20:30, 20 May 2020 (UTC)

Some CSS for Vector has been simplified

Hello!

I'd like to make a double-check about a change that was announced in Tech/News/2020/21.

Over-qualified CSS selectors have been changed. div#p-personal, div#p-navigation, div#p-interaction, div#p-tb, div#p-lang, div#p-namespaces or div#p-variants are now all removed of the div qualifier, as in for example it is #p-personal, #p-navigation …. This is so the skins can use HTML5 elements. If your gadgets or user styles used them you will have to update them. This only impacts the Vector skin.

On this wiki, this impacted or still impacts the following pages:

How to proceed now? Just visit all these pages and remove div before these CSS selectors if it hasn't been removed so far.

Thank you! SGrabarczuk (WMF) (talk) 13:05, 25 May 2020 (UTC)

14:17, 25 May 2020 (UTC)

Index:Wm. M. Bell's "pilot"; an authoritative book on the manufacture of candies and ice creams (1911).djvu

I don't really know what I'm doing wrong here, I was trying to create the red link index page here just so I could take a look at how the book is looking.

I copied an existing template and replaced the index name, page no's etc. but when I preview the page before creating it, it reports a message

Error: No such index

I copied and pasted the index name so it shouldn't be a typo, is this a problem with the index name having "" and ; in it? or maybe I am just making some other basic mistake by not really understanding the process.

If anyone has the time, would you be able to create the page for me please? Thanks Sp1nd01 (talk) 13:57, 26 May 2020 (UTC)

@Sp1nd01: I'm betting it's the quotation marks that's confusing ProofreadPage, but I'm not certain. @Tpt: Can you shed any light and suggest possible workarounds? --Xover (talk) 14:54, 26 May 2020 (UTC)
@Xover: Thanks for checking and progressing for me. I hope a workaround is possible, otherwise maybe it can be renamed to remove the quotation marks, but I wouldn't know if that is a valid option at all. Sp1nd01 (talk) 20:32, 26 May 2020 (UTC)

@Sp1nd01: I would suggest use {{#tag:pages}} syntax, otherwise the use of single quotes to wrap the page name

  • {{#tag:pages||index=Wm. M. Bell's "pilot"; an authoritative book on the manufacture of candies and ice creams (1911).djvu|from=xx|to=yy}} and yes there is a gap between the first two pipes
  • <pages index='Wm. M. Bell's "pilot"; an authoritative book on the manufacture of candies and ice creams (1911).djvu' from=xx to=yy />

What is happening is that typically it is looking for the containers to identify the start and finish of the filename, and the filename is just confusing to it.

Also to note that in the jargon sense, you are trying to transclude the pages, it did take me a while to work out what you meant. — billinghurst sDrewth 21:26, 26 May 2020 (UTC)

@Billinghurst: @Xover:, Thanks for the suggestion, the tag pages did the job, the page is created (transcluded) and I can now browse the book. Sp1nd01 (talk) 22:29, 26 May 2020 (UTC)
@Sp1nd01: Works can be renamed, but since we don't have good tools to do so it's not something we usually do unless it's absolutely necessary. Each Page: of the work would need to be moved individually, and there's no way to automate it short of an actual bot run. The Javascript API for Mediawiki lets you move pages, but it's made with Wikipedia (all single articles) in mind so it has limits that don't really work for Wikisource (where 1000 pages to a work is completely normal). In addition, the Index:, Page: pages, and the File: are all interdependent and connected through the file name (which is already fragile), and the File: will usually be hosted on Commons where we can't rename it directly (it's subject to Commons policy and processes). In other words, if we have any other alternative it is probably preferable to trying to move a work to a new name. --Xover (talk) 04:59, 27 May 2020 (UTC)
{{#tag:pages}} is a great get-out-of-jail-free card that avoids a range of issues and can be used to perform better wiki-magic (described elsewhere).
Generally I would discourage the use of single or double quotes in a name, as they can quirky, either in transclusion, or when you are trying to utilise some of the tools that convert to unicode. — billinghurst sDrewth 05:53, 27 May 2020 (UTC)

Gutenberg blocked in Italy

confused reports of Gutenberg block. here is an account https://www.balcanicaucaso.org/eng/Areas/Italy/Project-Gutenberg-obscured-in-Italy-many-doubts-few-certainties -- Slowking4Rama's revenge 12:53, 27 May 2020 (UTC)

See also Wikisource:Copyright discussions#Project Gutenberg blocked in Italy --Jan Kameníček (talk) 13:54, 27 May 2020 (UTC)

Community Tech Launches Wikisource Improvement Initiative

Apologies for the broken links in the previous message. This message is in English, but we encourage translation into other languages. Thank you!

Hello everyone,

We hope you are all healthy and safe in these difficult times.

The Community Tech team has just launched a new initiative to improve Wikisource. We will be addressing five separate wishes, which came out of the 2020 Community Wishlist Survey, and we want you to be a part of the process! The projects include the following:

For the first project, the team will focus on the #1 wish: improve ebook exports. We have created a project page, which includes an analysis of the ebook export process. We now invite everyone to visit the page and share their feedback on the project talk page. Please let us know what you think of our analysis; we want to hear from all of you! Furthermore, we hope that you will participate in the other Wikisource improvement projects, which we’ll address in the future. Thank you in advance and we look forward to reading your feedback on the ebook export improvement talk page!

-- IFried (WMF) (Product Manager, Community Tech)

Sent by Satdeep Gill (WMF) using MediaWiki message delivery (talk) 10:51, 28 May 2020 (UTC)

Senator Paul on Impeachment of President Trump (our censored version)

I understand that we've decided to censor Senator Paul on Impeachment of President Trump per this discussion, but the way it is currently titled is misleading. A casual reader might think the document was actually redacted by the government -- which I imagine is how the {{redacted}} template is most often used, but this isn't true; the U.S. Printing Office has published the speech in full. One obvious way to clear this up would be to move it to a more clear versioning title such as Senator Paul on Impeachment of President Trump (censored by Wikisource), but I thought I'd run this by the community for any other ideas. Do we perhaps have a template we normally put on our censored documents? -- Kendrick7 (talk) 22:55, 23 May 2020 (UTC)

I agree that the reader deserves better cues about how this has been handled and whose decision resulted in the redaction, thank you for bringing this up. I feel hesitant about the word "censor," which is a bit of a charged word; I would prefer the word "redacted," and ideally it should link to the discussion where the decision was made. -Pete (talk) 00:37, 24 May 2020 (UTC)
Also, I think it would be better in the "description" field in the header, and/or a note or link in the redaction itself, rather than in the page title. (Keep in mind, the page might be printed, and thereby separated from its title.) -Pete (talk) 00:39, 24 May 2020 (UTC)
I see no need to change the title of the work, especially as it was argued that the redacted parts are inconsequential to the work. I have added a comment to the {{textinfo}} on the document's talk page — billinghurst sDrewth 12:56, 24 May 2020 (UTC)
since no one is transcribing the side by side version, it does not matter what you call it- delete it. Slowking4Rama's revenge 01:43, 26 May 2020 (UTC)
Thanks, billinghurst, that adaquately addresses my concerns. -- Kendrick7 (talk) 13:13, 30 May 2020 (UTC)

I'm interested in contributing transcripts related to the official work of the Trump administration. It would add a lot for these transcripts to have links to video of the events. However the Trump administration has discontinued the Obama administration policy of hosting videos at whitehouse.gov (while also posting on Youtube). The only available video links currently are at Youtube and account-required sites like Facebook. Is it the case that no links to video of (for example) Presidential briefings can be made now since Youtube is blacklisted? Or is there a work-around where I ask for each relevant Youtube link to be whitelisted? thanks Dennis the Peasant (talk) 14:55, 13 May 2020 (UTC)

What type of YouTube pages are they? If they're free, they should be uploaded here. If they're copyrighted uploads with no permission on YouTube, we shouldn't be linking to them. If they're legit but copyrighted, you could ask link by link, or we could whitelist YouTube altogether. What's the account name on YouTube?--Prosfilaes (talk) 00:25, 14 May 2020 (UTC)
If these videos are marked Public Domain on YouTube (and it sounds like they should be, from your description) then I believe it's possible to download them, and upload them to Commons. That would be the ideal scenario, because we would not be reliant in the long run on YouTube or government entities to keep the videos online. -Pete (talk) 01:18, 14 May 2020 (UTC)
Thanks for replies. Copyright-wise, there are two categories of video I am concerned with.
  1. The White House posts content at their Youtube channel https://www.youtube.com/user/whitehouse/videos. This type of self-produced and official content used to be also hosted at whitehouse.gov and would be archived to a new URL after a new president was elected. Now it's only on YouTube.
  2. There is also video of presidential activities that are produced by another entity such as C-Span.
Category 1 could be uploaded to Commons and I have seen this done with some of this content. It's not clear to me that this could be done with Category 2, in which case whitelisted links might be a better solution.
I do not see any indication on the YouTube videos are to whether they are in PD. They are all free as in not requiring a paid subscription or a YouTube account to view. Dennis the Peasant (talk) 16:02, 14 May 2020 (UTC)
there is no public domain tag on youtube so it is on you to discern that. https://support.google.com/youtube/answer/2797449?hl=en the white house feed does not clarify matters https://www.youtube.com/channel/UCYxRlFDqcWM4y7FfpiAN3KQ you have a custom license on commons https://commons.wikimedia.org/wiki/Template:PD-USGov-POTUS uploading video is hard https://commons.wikimedia.org/wiki/Commons:YouTube_files#youtube2mediawiki and https://commons.wikimedia.org/wiki/Commons:List_of_Wiki_video_projects -Slowking4Rama's revenge 13:23, 3 June 2020 (UTC)

Discussion on encouraging page scans?

Hello all! Recently I was looking at the ProofreadPage stats and I noticed that a few sites have a "pages with scans" percentage of higher than 97% – meaning that virtually all of their texts are based on transcluded page images, not just copy/pasted text like many of our works. I imagine that those sites have undertaken major efforts to encourage the use of page scans, perhaps by placing restrictions on new texts coming in or even deleting some texts without scans. I haven't been involved in discussions here much lately, so I'm wondering if there have been any discussions along these lines here. I tried a few searches but didn't come up with anything – could someone point me to recent discussion on this topic, if there has been any? Thanks. –Spangineer (háblame) 00:36, 29 May 2020 (UTC)

97% is more than encouraging pages with scans. We probably couldn't get there if we backed every scanned page with scans. I don't think there's been much discussion recently, though we are pushing for it.--Prosfilaes (talk) 03:14, 29 May 2020 (UTC)
Some other interesting comparisons: frWS and deWS have about 0.02% and 0.03% ratios of problematic (blue) pages to total page-namespace pages respectively (enWS is 1.3%) and the unproofread (red) pages to total pages ratios are 25% and 5% to enWS's 39%. I'm pretty sure much of it is down to stricter rules on those subdomains (especially deWS), though I would be interested to know how the first figure is achieved, since most of our problematic pages are either bad scans or pending image extraction. Inductiveloadtalk/contribs 10:12, 29 May 2020 (UTC)
Hey Spangineer; good to see you around. I'm not aware of any discussions specifically addressing this. There have been some indications the community would like to raise our standards, but often in the context of deletion discussions where the issue gets conflated with "deletionist" vs. "inclusionist" tendencies.
I am personally of the opinion that it is past time we made it policy for new additions that they should be scan-backed, and raise the bar on grandfathered old works (e.g. if they have style problems, and are not scan backed, and insufficient source information, they should be deleted; or if they are a conflated text, probably copied and pasted from Gutenberg from no specific edition; etc.). Combined with a concerted community effort to migrate old texts to scans, I think we could improve our overall quality massively in relatively short order.
But we are, I think, suffering under some kind of weird aversion to having proper written policy. A lot of stuff that would improve our quality turns out to have been discussed and agreed as policy, only for our actual policy pages never to have been updated accordingly. In the mean time, practice has diverged due to the lack of written policy, to the point where the previously agreed policy can no longer be assumed to be valid. I think that if we are to do anything about our quality, we absolutely need to get over this fear of having proper policy to codify our standards. --Xover (talk) 06:32, 2 June 2020 (UTC)
Thanks for your thoughts! I've been thinking along the same lines... seeing if we can get agreement on a policy that would place some limitations on works with no scans. I agree that it seems reasonable to make sure that our policy pages document actual practice, identifying both the areas where we are strict and areas where we are flexible (and of course there has to be a lot in the latter category given the vast diversity of types of works we host here). Spangineer (háblame) 13:26, 3 June 2020 (UTC)

When a source was/is dubious...

So trying to figure out why the Author:Nathan Haskell Dole doesn't mention project The Russian Fairy Book (of course, since project isn't done, maybe that?) when I come across another of the author's works, a translation from Tolstoy, Where Love is, There God is Also.

Only..., when I look at that, it strikes me immediately as from a bogus, corrupted source. Out pops at me:

"If he can finish and order by a certain time, he accepts it"

and the rest of the sentence has a hyphen where an em-dash would have to be. The source for this was not an edited, printed book.

Then I search on the web, and there are billions of copies of copies, all saying "finish and order". Some you can buy for $40! ;-)

But then when I specifically search for the gotta-be-right "finish an order", out pops matches: e.g. from 1896. Em-dashes! Good English! Hmmm. Another [18]

Then I finally find a decent scan from the author's book of translations. Even the text version at archive.org isn't broken enough to have 'and' instead of 'an'.

So something contributed in 2007 without source attribution, when found to be *not* faithful to a believable source, what to do? Shenme (talk) 06:39, 24 May 2020 (UTC)

@Shenme: Tag it with {{no source}}; upload the good scan; set up an index for it; proofread the relevant pages; and replace the dubious unsourced version with the newly proofread one. If the work in question is too large to reasonably replace like this then tagging it as without a source is the minimum, and it would be very helpful to set up the scan and index and then tag the bad text with {{migrate to}}. --Xover (talk) 07:27, 24 May 2020 (UTC)
@Shenme: Iván Ilyitch and Other Stories; Iván Ilyitch and Other Stories/Where Love Is, There God Is Also; and Index:Iván Ilyitch and Other Stories (1887).djvu. --Xover (talk) 18:46, 4 June 2020 (UTC)

Help with transclusion required.

I thought I'd have a try transcluding sections in Lancashire Legends, Traditions, Pageants, Sports, &c., by copying some existing transcluded pages and editing them for the new sections. I've done a few transclusions OK, but have come across a couple of transclusion situations where I'm now out of my depth and need help.

The first issue I hit is that I can't get the links between the Introduction and Memoir of John Harland, F.S.A. to turn blue. (the next and previous links.)

The second issue is that when transcluding the section Sir Bertine Entwisel, it ends on a page where there are also two other sections, one complete section is found on that page, and the last one crosses over a few more pages. My attempt to add section tags for this situation isn't working, my transclusion of section Sir Bertine Entwisel now shows the whole other section as well as the start of the next, and I don't know how to fix it. Thanks Sp1nd01 (talk) 16:34, 29 May 2020 (UTC)

Issue number one: the relative link from title/Part 1/Subpage to Title/Memoir is ../../Memoir, as it has to go "up" two levels and then down to "Memoir"
Issue number two: You were missing the <section end="s1"/> on the last page, so the sections couldn't be parsed. I suggest using the "EasyLST" gadget (Preferences -> Gadgets -> Editing tools) as it takes care of that for you. Inductiveloadtalk/contribs 16:41, 29 May 2020 (UTC)
Thank you for the help, I think I now understand the solution for the first issue.
Re the second issue, I now have the "EasyLST" gadget enabled, but must admit I don't know how to use it. I am not seeing any new button or link for it anywhere obvious in my interface.
I was checking the diff between your edit and mine to see what was done, and I see the change adding the end of section (<section end="s1" />), however when I actually edit the page I don't see that line present. Is this some system internal code that is hidden from me? Just wondering if I can manually add that line when I next come across one of these tricky pages? I think I spotted a few more of them further on in the book. Sp1nd01 (talk) 21:35, 29 May 2020 (UTC)
With EasyLST, the sections are marked with a ## section_name ## syntax. For example, in old style:
<section begin="s1"/>
Section 1
<section end="s1"/>
<section begin="s2"/>
Section 2
<section end="s2"/>
and with EasyLST:
## s1 ##
Section 1
## s2 ##
Section 2
The ## s1 ## is then replaced with the <section begin="s1"/> by the gadget. Inductiveloadtalk/contribs 21:55, 29 May 2020 (UTC)
Thanks again for the help, I've now managed to transcribe one of those situations correctly. Sp1nd01 (talk) 09:35, 30 May 2020 (UTC)
I'm back again with another problem. I have transcluded all of Part 1, but now I don't know how to make the jump from the end of Part 1 to the Part 2 Introduction. The link I've created takes me back to the Part 1 Introduction. Could someone take a look and fix it for me please? Sp1nd01 (talk) 15:27, 5 June 2020 (UTC)

Wikilivres is live again

https://wikilivres.org/wiki/Special:RecentChanges Does anyone know anything about this? —Justin (koavf)TCM 02:52, 3 May 2020 (UTC)

It looks very very broken. :-( --Zyephyrus (talk) 15:58, 3 May 2020 (UTC)
Extremely broken. As I've said to our friend Koavf elsewhere, hardly any of the links work. And those recent changes end in May 2019. I kept editing it, while it kept getting frustratingly slower and slower, until the start of August 2019. So I guess some work is lost forever. I'll probably look in from time to time to see if it gets unbrokem. But that wiki has caused me to shed quite enough blood, sweat and tears over the past few years. It came. It went. It came back. It changed its name. Someone took over and wanted all admins to pay for the privilege of being one. It disappeared and came back under its old name. If it does come back again, its history suggests it won't be long before it disappears once more. I don't think I'll contribute to it again. Simon Peter Hughes (talk) 16:09, 4 May 2020 (UTC)
Chinese Wikisource and I will boycott Wikilivres as being too unstable.--Jusjih (talk) 03:42, 5 May 2020 (UTC)

Is there a summary anywhere of what happened, and/or does anybody have a clear idea what should ideally happen going forward? If it helps, I was in touch with Eclecticology's family after his passing (he was a friend, I wrote his obituary for the Signpost). If there is something a family member would be in a position to do (e.g. taking ownership of the domain), I'd be happy to pass along a request. -Pete (talk) 19:54, 5 May 2020 (UTC)

@Peteforsyth: I own the .ca domain: I got it from his family. I have never owned the .org. —Justin (koavf)TCM 06:58, 12 May 2020 (UTC)

Btw. Some time ago I tried to talk with Dysklyver, the last wikilivres.org domain owner and the site admin, about wikilivres future but with no big success, see the comments section here -> https://thewikicabal.com/2019/09/16/fascism/ Electron (talk) 14:26, 6 June 2020 (UTC)

Replacing image of musical score with Lilypond in non-scan-backed works?

A recent discussion elsewhere has brought to light an issue that could benefit from wider community input.


How should we deal with replacing a score image with Lilypond in non-scan-backed works?


Our practice is generally to use Lilypond (gory details) to present musical scores to our readers—including replacing existing images of scores with Lilypond—even if they are not pixel-for-pixel identical. This is generally good and desirable for several reasons, including the ability to automatically generate an audio version of the score.

However, we have a large legacy of works that are not scan-backed, and that include the score as an image in the page. If we replace that image with Lilypond then we also break any possibility of validating the score, which is an even more fundamental practice on the project.

I have not found any specific guidance on this issue anywhere, so I am hoping the community can chime in with some views on how to handle this issue going forward. It's not the biggest problem we have, but it has led to disagreements, so a common course on it would be useful.

Some possibilities that point themselves out:

  • Ignore it. Just replace the image with Lilypond and ignore the lack of validation. The work in question is not scan-backed in any case, so this matters little.
  • Don't do it. Independent validation is fundamental to our processes, and when something precludes that it should not be done. We can live with static images of music scores on these works.
  • Link image in textinfo. We have other information about works in the {{textinfo}} template on the work's talk page, so the image can live there and be available for validation.
  • Include image thumbnail. The image of the score can be included directly on the work's page as a thumbnail so it is available for validation. This is how many non-scan-backed works include other illustrations so it's good enough for this case too.
  • Tag the score with a notice. We can put a text tag on the Lilypond score that makes clear that it is not yet validated, and links to or explains how to find the original image for verification.
  • Something else. A much better idea that the community will come up with in this discussion. 😎

I don't think this the sort of issue that has a clear-cut right and wrong answer, so is best dealt with by discussion and seeing if we can extract some rough consensus (as opposed to holding a vote or something like that). In other words, I would very much appreciate any and all thoughts and opinions on this; including "I really don't care about this!" because that's also useful guidance from the community. --Xover (talk) 08:48, 11 May 2020 (UTC)

  • Note: Pinging possibly interested contributors: Beeswaxcandle, EncycloPetey, Beleg Tâl. If there are others who may have a particular interest or relevant perspective on this, please ping them to this discussion. --Xover (talk) 08:52, 11 May 2020 (UTC)
  • I have seen a number of pages like this, especially from Portal:Sheet music. I believe that the preferable solution would be to create an index which includes the images, transclude the pages (if any Lilypond has been written), and leave it like any other work. (It could look like this if there is no Lilypond.) By the way, is there any reliable way for cross-page creation of Lilypond files? I think that it would help with this? TE(æ)A,ea. (talk) 11:35, 11 May 2020 (UTC).
  • I think the best solution which would keep the advantages of using Lilypond instead of a static image would be to link to the source image using {{textinfo}}. This keeps everything simple enough that people who wish to contribute new works in this fashion can do it without difficulty while allowing easy double-checking (without having to comb through the page history...). Similarly, if there are non-trivial differences between the Lilypond and the image then it would pose no problem to tag the page and notify the relevant persons of perceived problems (assuming the person who notices it does not know how to fix it). 107.190.33.254 14:01, 12 May 2020 (UTC)
  • My personal opinion is that labour-intensive improvements like Lilypond markup are not worth the effort for non-scan-backed works. Find a scan and back it first, and then you can craft the Lilypond score to match. Otherwise, I would just ignore it. —Beleg Tâl (talk) 03:12, 11 June 2020 (UTC)

Time to talk nomenclature of author classification by occupation

We have dodging the fix for a while and it is probably time to start what I think could be a long conversation in what we could do, and then probably followed by another on how we will do. (People may prefer that this is put to a separate RFC subpage rather than here at WS:S)

We have long had occupation categories for author pages (subcats of category:authors by occupation and category:authors by nationality. Below that we have the plainest of names that don't distinguish that pages there should be from our Author: namespaces.

At the same time we have not had a good set of categories for biographies of people (as the subject), though I have been working on the creation of these subcats (through category:biographies of people by nationality and category:biographies of people by occupation) though these creations will be well behind the corresponding author set.

Suggestions

To me, it is time that we start to have clarity to our author category nomenclature, and I don't know exactly what people would want, though we could be as basic as converting Category:Physicians

  • Category:Physicians (authors); or
  • Category:Author:Physicians; or
  • something more natural text Category:Physicians as authors

All have strengths, and with the HOTCAT system if we utilise {{category redirect}} we can even utilise a couple of schemes and HotCat will put to the designated target. Personally if using HotCat getting it to differentiate quickly is always my ideal.

Ultimately we would have to decide whether the existing Category:Physicians is permanently going to point to its author derivative for all time, or for a temporary time whilst we migrate and settle down the setup, and at a point possibly become a category "disambiguation" page that points to the alternatives for physicians.

And the final question are we creating separate (and maybe matching) category hierarchies one for author namespace pages, another for main ns pages, splitting portal ns pages between one or the other. Noting that in the general subject categories when we get some layers down we start to pick up both forms so the names do become necessary. For example Category:Medicine will have below it (somewhere) both biographies and author pages of physicians.

Further, for something like sailors we could have Category:…
  • Sailors as authors or Sailors (authors) or Authors:Sailors
  • Biographies of sailors
  • Stories of sailors new category created just now to take pages
and reasonably all three have been added to category:Sailors. The more that I look at it, I think those generic names should be disambiguation categories, especially as HotCat c:Help:Gadget-HotCat has means to manage disambiguation targets.
Do I take this as either a) people don't care, and I can go ahead and do as I please? or b) this is way too big a conversation, and you numb my brain? or c) what the hell are you talking about? — billinghurst sDrewth 04:43, 17 May 2020 (UTC)
A bit of both column B and C. I think your problem statement and the rough thrust of your proposed course of action make sense. I see nothing in the above I actively disagree with.
I think category names should always be "fully qualified" rather than rely on its parent categories to provide part of its definition. I also think long category names are a good thing, and natural language construction of them the best approach. We can have Category:Physicians as a top(ish) level cat, but it would just be a container for Category:Authors who are physicians and Category:Biographies of physicians and Category:Novels about physicians, and so forth (possibly with intermediate "…by topic" container cats).
But I would also very strongly urge that we start by making a guide/principles/documentation/policy/whatever page that describes the entire scheme (principles, examples, guidance on tricky cases, what pages should have what kind of categories, and what pages should have no categories, etc.), before asking the community to actually decide. This stuff is going to be de facto policy (even if we don't call it that) and will be "enforced" (I use the term loosely) through various mechanisms, so fleshing it out more is necessary before properly deciding. And if we have good guidance and a sensible category naming scheme and hierarchy, it's going be much easier for the community to help clean up / maintain it without stepping on each others' toes. --Xover (talk) 07:16, 17 May 2020 (UTC)
We already have Help:Categorization so let us work from there. I am going to push through changes based on your PHYSICIANS example above, as HotCat will give useful restrictions, and I want to test those in action as I go. — billinghurst sDrewth 14:27, 16 June 2020 (UTC)
Not "Author as ..." too much typing to get to the keyword as the point of differentiation. So much recommending is "Occupation as authors" — billinghurst sDrewth 04:00, 17 June 2020 (UTC)
Question Question Is it possible the cats can be inhaled from Wikidata: e.g. author's item has "nationality: French" and "occupation: painter, poet", then a template and/or module looks at that and auto-cats into Category:French authors, Category:Painters and Category:French poets based on a set of rules: what categories we want, and how they are laid out at enWS (e.g. we have a cat for French poets but not Lithuanian poets, so Lithuanians go into Category:Poets). It seems a bit of a shame to expend so much effort of categories here when all the data is (or should be) at Wikidata.
Of course any categories not captured by Wikidata properties can still be manually added. Inductiveloadtalk/contribs 14:57, 16 June 2020 (UTC)
@Inductiveload: Ultimately I believe so, though we still need to build the categories and the structure. Though that is only going to work for the authors, AND we have to do more for our works. WHAT I would hope that we achieve at a point in time is through a WS biographical article, to the WD biographical item at and through main subject, and then access the person data and categorise the biographical work. (AGAIN I need an available structure, and to invert the current name structure). — billinghurst sDrewth 15:34, 16 June 2020 (UTC)

Existing maintenance

I have been very slowly cleaning main namespace articles from our author categories, and down to less than 200 , or thereabouts

which will be a reasonable sweep, though not perfect.

Some of the remaining maintenance is people categories (our somewhat contentious people categories) eg.

+++

billinghurst sDrewth 17:49, 6 May 2020 (UTC)

Project Gutenberg blocked in Italy

Section moved here from Wikisource:Copyright discussions

see also https://www.punto-informatico.it/project-gutenberg-sequestro-copyright/

https://twitter.com/aubreymcfato/status/1264828299395637254

Slowking4Rama's revenge 02:34, 26 May 2020 (UTC)

It looks like the rest of the EU is going to go that way, and possibly Wikisource will join them if we get big enough to be noticed. From the EU's perspective, they're not going to tolerate works copyrighted in the EU being available on the Internet in their country.--Prosfilaes (talk) 03:59, 26 May 2020 (UTC)
Ouch! But that's really not a particularly surprising outcome, and a demonstration of the various risks our US-only copyright policy entails. I haven't been following this specific case (pointers welcome!), so I base this only on the headline, but I'd still be willing to bet Commons' will run clear of this while ours will land us square in it if they ever deign to notice we exist. --Xover (talk) 07:04, 26 May 2020 (UTC)
As we have English works, and UK drops out of the EU next year, that is unlikely to problematic for us, and then that comes down to what the other language wikis are doing. So it would seem that frWS and deWS are primarily the focus. — billinghurst sDrewth 11:51, 26 May 2020 (UTC)
The UK may still want to block us for that reason; Ireland is primarily English-speaking and has English as an official language, and Malta has English as an official language, so I don't see us as off the hook. Not that I suggest doing anything about it on Wikisource's side; if political maneuvers don't stop them, people will just use VPNs to get around the block.--Prosfilaes (talk) 00:48, 27 May 2020 (UTC)
VPNs won't help us. The reason why VPNs have not been stopped yet is simple: only a tiny fraction of readers know about their existence and only a fraction of this fraction can use them. If this changed they would be stopped. --Jan Kameníček (talk) 06:25, 27 May 2020 (UTC)
I'll add a "ditto" for what Prosfilaes said. And add that the issue isn't just whether we get blocked from those places, but also the legal jeopardy this places our readers and (especially) reusers in everywhere that's not the US. Large parts of Asia and some parts of Africa (and let's not forget Australia) have English as a primary written language or as a primary written language for certain purposes. In all these cases we put reusers at risk when we ignore the copyright laws of the country of origin; and our contributors from those areas too, but I am more willing to accept that they can make an informed decision regarding their own risk than our reusers. This move in Italy just exemplifies a risk that is everpresent for all these cases so long as we choose to be so US-centric in our copyright policy.
Note that I am not proposing we should immediately change our copyright policy based on one single country being stronzos. But it's a concrete example of the general and ongoing problem with our policy which I think we should consider very carefully going forward. --Xover (talk) 07:17, 27 May 2020 (UTC)
I'm not worried about legal jeopardy for our readers. Unlike torrents, they have no way of knowing who our readers are, and like torrents, trying to chase down random users is unprofitable and backlash-inducing. Reusers are going to have to deal; if you're going to reuse, you need to know the law you have to follow. Certainly Wikipedia strikes me as hugely dangerous for many reusers, as many pages will violate libel or blasphemy laws, or various local laws prohibiting certain viewpoints. (E.g. India apparently bans maps that they don't agree with, and Poland is getting on anyone who thinks Poles might have had a role in the Holocaust.)
Note that "copyright laws of the country of origin" is a bit of a farce; there's a table of countries on w:en:Rule of the shorter term and many countries don't have the rule of the shorter term, like Mexico and Brazil, with English speaking nations including Australia and Canada (at least wrt the US). The list is pretty short, so I don't know about most of Africa or Asia. I don't know what rules are needed to make Wikisource or Commons copyright-safe in all parts of the world, but we're talking at least life+70 (plus wartime extensions?) and 95 years from publication.
Maybe Commons is safer from widescale blocks like this, but I sure wouldn't reuse anything from there without double-checking, with uploads with bad licenses and many, many works that aren't free in my nation (the US).--Prosfilaes (talk) 11:01, 27 May 2020 (UTC)
Project Gutenberg in Germany has already been blocked for five years, see Court Order. - R. J. Mathar (talk) 10:02, 23 June 2020 (UTC)
Project Gutenberg does not care about how works may be copyright-restricted outside the USA, so Italy, having to generally copyright for life plus 70 years until year end per the European Union, would thus block it as a preventive measure. Please feel thankful that I brought Template:Pd/1923 from Chinese Wikisource to automatic license updating over years.--Jusjih (talk) 03:04, 20 August 2020 (UTC) (your Eastern Asian cultural bridge)
it is not about " if we get big enough to be noticed", but rather, hard headed enough not to delete 18 works when requested by a european court, seeking to impose european law upon the internet. no chance of that here, with PRP. (interesting Italy should adopt german methods on this occasion, given the conflict here [19]) don't know why you would waste time spinning up anxiety. Slowking4Rama's revenge 12:23, 20 August 2020 (UTC)
I disagree your theory of spinning up anxiety. Project Gutenberg has asked for it. Assume good faith.--Jusjih (talk) 00:45, 7 September 2020 (UTC)