Wikisource:Scriptorium/Archives/2023-08

Adding a 1935 book written in 4 languages (about the Piri Reis map)

Moved to a more appropriate location, Rjjiii (talk) 05:23, 2 August 2023 (UTC)

More of a request than a proposal

Please consider replacing our regex editor style and location with the location and the features of the same used in the French Wikisource.

The differences are:

• The French version is displayed inside the Page edit view frame, and the search and replace fields are included in the same frame.
• The French version needs no regex statement to replace all occurrences of plain text. Ours requires the use of regex. — ineuw (talk) 05:06, 7 August 2023 (UTC)

Tech News: 2023-32

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

• Mobile Web editors can now edit a whole page at once. To use this feature, turn on "⧼Mobile-frontend-mobile-option-amc⧽" in your settings and use the "Edit full page" button in the "More" menu. [1]

Changes later this week

• There is no new MediaWiki version this week.

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

MediaWiki message delivery 21:20, 7 August 2023 (UTC)

Best forum in Wikimedia to ask technical questions relating to our editing environment?

Wikimedia family of sites have undergone a major revamp in the past three years and I lost my way. During the same time, I also underwent a loss of relevant bookmarks to the Wikimedia/Phabricator discussion sites.

I am looking for technical information about the changes relating to visual presentation, and what a user can, or can no longer modify through .js and .css. — ineuw (talk) 04:33, 7 August 2023 (UTC)

@Ineuw: Technical documentation is most often found on mediawiki.org, but it's never been great and doesn't impress me as getting better. What you can and can not modify through user .css and .js is the same as always: only what you happen to find out works, and only at your own risk. The support for user .js / .css was a lot more enthusiastic in the old days, but it was never documented (and certainly not guaranteed) to enable anything much specific. I am also not aware of any particularly good global forums to ask for that kind of help so it's probably the Scriptorium or other project's village pump.

But let me just say right off the bat that if what you're aiming for is fighting changes in Vector / Vector-2023 or the 2017 Wikitext editor you might as well give up right now. That kind of platform change you're never going to be able to effectively counteract, and trying will only bring you grief. (I even recommend against using monobook and the other non-default but supported skins, because while technically supported it is clear the support for them is minimal compared to Vector as the default). Xover (talk) 06:34, 7 August 2023 (UTC)

@Xover: Much much thanks for this clarification. I consider it an affirmation of what I discovered, tracing back step after step, after user:billinghurst commented, that I have "high expectations". :-D.

Flummoxed, I scurried to re-examine my request based on past knowledge. Needlessly to say that I was shocked, and please accept my apologies for asking without checking first. I also came to understand why this was necessary. — ineuw (talk) 07:25, 7 August 2023 (UTC)

 Comment All depends on what you are trying to do. Mediawiki and its WMF's version is set to make things easier and not for overly being customised. What doesn't work well is that WMF's toolbars are not suited to the Wikisources where we utilise a whole heap of standard (for us) templates. I have stuck with monobook for enWS as I have heavily invested in custom toolbar without all the heavy lifting of unrequired components. I would always recommend keeping things as simple as possible, as the more one deviates with customisation, the more things become unseen or have the chance to break, and expecting others to fix one's own introduced complex customisation is IMNSHO unreasonable. — billinghurst sDrewth 03:21, 8 August 2023 (UTC)

I just wanted to understand the new limits of using the CSS page to style my work environment. That is all. — ineuw (talk) 09:00, 8 August 2023 (UTC)

License templates at author pages

Various license templates at author pages give among others this text: The longest-living author of these works died in ..., so these works are in the public domain... However, this may be useful for the main NS, but not for the author NS. The license should give information only about the specific author whose author page it is. The practice is that contributors set the author's death into the template, not the death of the longest living co-author of one of the many listed works. I remember that some (long?) time ago the template gave information about the author only, so I suggest returning this wording for the Author's NS. -- Jan Kameníček (talk) 17:49, 7 August 2023 (UTC)

@CalendulaAsteraceae: for Module:PD. user:Jan.Kamenicek typically we'd put something to Module talk:PD though it is not the easiest to dig down to there. — billinghurst sDrewth 03:13, 8 August 2023 (UTC)

Thanks for the ping, @Billinghurst! @Jan.Kamenicek, I've added some author-specific wording to Module:PD; let me know if you'd like me to change anything. —CalendulaAsteraceae (talk • contribs) 03:47, 8 August 2023 (UTC)

Wikisource logo with wikidata pattern -- anyone?

Wondering whether we ahve someone who likes creating icons. I am wish to have something styled to the Wikisource logo, though filled with the wikidata style as shown as c:Category:SVG_Wikidata_logos. I am wanting to utilise such a logo in Template:Category populated to identify that the WS data is from WD. Thanks if we have someone with the skills. — billinghurst sDrewth 03:11, 8 August 2023 (UTC)

@billinghurst: Would something like this work? The SVG still needs some cleanup so this is just to check whether it's the concept you had in mind. --Xover (talk) 11:52, 8 August 2023 (UTC)

In my simple mind, pretty much anything would work, just trying to get the concept over visually that we are pushing our data over to populate and then retrieving it. I am not a graphics person. — billinghurst sDrewth 21:50, 8 August 2023 (UTC)

@Billinghurst: Ok, I've cleaned it up and transferred it to Commons. Should be good to go if it suits your purpose. Xover (talk) 18:04, 9 August 2023 (UTC)

Redirects

Is there a way to not have a redirect formed when you move an entry. A redirect just clutters the automated index with the versions with errors, adding a duplicate in italics. I want to switch entries in San Francisco Call from volume-number to year, so they sort chronologically. RAN (talk) 22:09, 6 August 2023 (UTC)

Only those with the Administrator right can supress a redirect. The best thing to do is ensure that the redirect has no incoming internal links, and then tag it for Speedy Deletion. The reason should start with "M2" as that is the category for "Unneeded redirects". However, do note that this speedy deletion category has different criteria depending on how long the page has been extant. The two month soft-redirect criterion is to allow incoming external links time to change before deletion. Beeswaxcandle (talk) 06:19, 7 August 2023 (UTC)

• @Beeswaxcandle: Why don't links get replaced automatically the way they do Commons and Wikidata? It looks like editors early on used "volume 1" and "volume 10", instead of year. Is there any consensus to move them to years? If they were "volume 01" and "volume 10" they would sort chronologically in the index. It looks like the project standardized on years instead of volumes at some point. --RAN (talk) 18:58, 7 August 2023 (UTC)

  What do you mean by automatically replaced? Commons has bots doing the job, and WD is a different and specialised structure. One could ask why you aren't using the structure of earlier users. We have numbers of structures of works, and none is perfect, and we adjust depending on the work, how it is scanned and/or otherwise available. To also note that a redirect is retained so that old links work, so we should always query ourselves about the usefulness of redirects, AND whether we have an article fully linked through WD, which can remove administrative burden. Horses for courses. — billinghurst sDrewth 03:29, 8 August 2023 (UTC)

That really doesn't answer the question: "Why don't links get replaced automatically", if Commons and Wikidata both have automated the work, why don't we have the work automated? You asked: "One could ask why you aren't using the structure of earlier users" (volume 1 and volume 10 versus 1895 and 1910) and I had already answered that: "[so they] sort chronologically in the index". --RAN (talk) 12:56, 8 August 2023 (UTC)

It is an answer to why they don't get automatically replaced, as there is NO automatic. Bots are not automatic, and they don't spring into existence through wish. Bots are managed by people at a wiki with the skills to write the software to undertake a task. Wikidata is a different beast with a whole dedicated team and funding source, it should not be considered THE standard.

That is not an answer for why an existing work should be reconfigured to how you want it. The guidance is at Wikisource:Periodical guidelines — billinghurst sDrewth 22:22, 8 August 2023 (UTC)

That was written 10 years ago, and no one follows it now. "Volume 1/May 1872". Even if we followed it today, it should be "Volume 001/May 1872" so it sorts properly in the automated index.

• @Richard Arthur Norton (1958- ) - if you are going to edit the old page so it is no longer a redirect, and then put it up for speedy deletion, you need to also edit the incoming links to that old page - otherwise they will be left as redlinks. -- Beardo (talk) 12:52, 8 August 2023 (UTC)

Please note the commentary when you move a work about the use of {{dated soft redirect}} which I believe is still the preferred means for long standing pages. Also to note Help:Redirects which gives instruction. — billinghurst sDrewth 22:21, 8 August 2023 (UTC)

Happy to see the discussion above, but one detail: the "soft redirect" template gives instructions that are specific to Wikisource. Notifying Wikisource administrators might be helpful for other publicly editable wiki sites (i.e., it's probably safe to assume that Wikisource admins are familiar with editing wikis and willing to do so) but would not apply to incoming links from websites or documents generally. (There's probably an elegant way to address that by editing the template, but I'll leave that alone for now.) Part of the reason to avoid deleting a page that has been around for a while is because it's not possible to know what links might be in play outside the Wikimedia universe. -Pete (talk) 23:26, 8 August 2023 (UTC)

I imagine outside users will have to deal with link rot, like everyone else. Some Wikipedia entries have been moved a least a half-dozen times as "John Smith" became "John Smith (politician)" and was later moved to "John Smith (disambiguation)" and then split into "John Smith (New York politician)" and "John Smith (New York politician, born 1752)" --RAN (talk) 23:51, 8 August 2023 (UTC)

I don't follow -- your example supports my point, RAN. Link rot is a negative in terms of the public accessing information (a key focus of the Wikimedia vision) wherever it occurs; and we should strive to minimize it. In fact, Wikipedia typically does minimize it. In cases like you described, on Wikipedia, a trail of breadcrumbs is almost always diligently left for the reader: "John Smith" gets a hatnote linking to the "John Smith (politician)" page, and so on.

Redirects are cheap. There is little downside to having a bunch of redirects scattered around to address possible confusion, confusion that is impossible to fully anticipate. What is the upside -- the benefit -- of deleting a redirect, when the cost of keeping it is so very low? That's the core principle that should be considered with this stuff. In these cases, I can't imagine what the value (to readers, to administrators, to the world at large) could possibly be. Can you address that? -Pete (talk) 16:33, 9 August 2023 (UTC)

• As pointed out earlier redirects clutter the index. See: San Francisco Call as an example. If I am looking for an article in the index, I am confronted by twice the number of articles, half of which are redirects. It only confuses the end user, it doesn't help them. If you are assuming the end user is a Wikisource editor, creating content, they may not be confused, because all involved in this discussion are. But look at this as an outsider looking for an article in the index. --RAN (talk) 18:07, 10 August 2023 (UTC)
  • Okay, I think I am starting to see where you're coming from. I can see the concern, but I don't think removing redirects is the proper remedy; I'll explain. The page version of The San Francisco Call you linked to used {{header periodical}}, which is a template I've not seen very much, despite doing a great deal of work on periodicals here over the years. While I'm not 100% sure of its intended purpose (and maybe User:Billinghurst, who created it, can speak to this), the notes in it make me think it's intended as a stopgap, creating an approximation of an overview of the contents from a periodical, where no human editor has yet manually created a page for it. But in my view, the accepted practice is that periodicals with multiple texts transcribed should have a human-edited overview page. I've demonstrated more or less what I mean in this edit to the SF Call (and obviously, further improvements can be made). A more mature page would be The Overland Monthly. So, in my view the "redundancy" you're seeing results from pages that were only ever intended as hacks, and the proper remedy is to create a page, manually linking all the available transcriptions. (Or, I suppose, maybe somebody more technically inclined than me wants to improve {{header periodical}} to make it more savvy about redirects.) -Pete (talk) 20:19, 10 August 2023 (UTC)

As the documentation says, it is a stopgap. It allows for automated contents of subpages where someone hasn't curated the base/parent page. It was created as some people were only creating a subpage of a work, and as such that page was orphaned. It is also useful where we are moving base level newspaper articles to an appropriate subpage, and that allows for the quick population at the base level. Noting that t can be used at the base level or on intermediate subpage level per its documentation. — billinghurst sDrewth 22:35, 10 August 2023 (UTC)

Also, I agree with RAN that it is worthwhile to inquire why something isn't automatic. I don't think there's any disrespect inherent in that line of questions. Sure, "it requires labor" is a reasonable answer, but it's only one step along the path. "What kind of labor, and what can be done to facilitate that labor" might be good followup questions. Gotta start somewhere. -Pete (talk) 23:30, 8 August 2023 (UTC)

Where does Wikipedia link come from in this transcript?

The New York Sun/1835/Police Office and do we have a category for transcripts that are missing their backing images, so that someone can look that has access to a newspaper archive. RAN (talk) 18:07, 11 August 2023 (UTC)

The link in the header area comes via the Wikidata link. Beeswaxcandle (talk) 18:20, 11 August 2023 (UTC)

But why in the world is a reproduction of a newspaper article linked to a Wikipedia article about a historical neighbourhood in Manhattan? I think that either our logic for using Wikidata (in {{header}}) is incorrect, or the properties on Police Office – Saturday. Morning Returns. (Q19028329) are set incorrectly. Xover (talk) 07:00, 12 August 2023 (UTC)

A forensic answer: The page was originally created by RAN under the title "Five Points (Manhattan)" in 2005. He moved it to the present title in 2022—presumably to bring it in line with the periodical naming convention. A few minutes before this query was posted a main subject claim for Five Points was created on the WD item, which (I think) caused the WP link to appear. Beeswaxcandle (talk) 07:14, 12 August 2023 (UTC)

Oh, hmm, we're probably looking up main subject (P921) and creating a Wikipedia link for the first value because for a biographical article (in EB1911 or whatever) that would link our reproduced biographical article on "Shakespeare, William" to Wikipedia's article on "William Shakespeare". But for something like this—a newspaper article linking to an article on a neighbourhood—the results are certainly surprising, and I am not at all sure desirable. The data set on the Wikidata item look correct to me, so I think it's our logic (in {{header}}) or presentation of the data that's at fault.

Maybe we should reserve the sisterlinks block as it is today for actual sitelinks on Wikidata, and relegate values found from main subject (P921) to some lesser position and labelled as "topics" or "keywords" or something like that (but actually grab all of them)?

@Billinghurst: you've probably done the most on our Wikidata integration: do you have any input here? Xover (talk) 07:45, 12 August 2023 (UTC)

Rubbish addition of "main subject", I removed them. Main subject is meant to be quite specific, and they were not. — billinghurst sDrewth 10:07, 12 August 2023 (UTC)

Poll regarding August 2023 Wikisource Community meeting

Hello fellow Wikisource enthusiasts!

We will be organizing this month’s Wikisource Community meeting in the last week of August and we need your help to decide on a time and date that works best for the most number of people. Kindly share your availability at the wudele link below:

https://wudele.toolforge.org/U9b5TC4QJMPuu1tY

Meanwhile, feel free to check out the page on Meta-wiki and suggest topics for the agenda.

Regards

KLawal-WMF and PMenon-WMF

Sent via MediaWiki message delivery (talk) 10:53, 12 August 2023 (UTC)

Tech News: 2023-33

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

Recent changes

• The Content translation system is no longer using Youdao's machine translation service. The service was in place for several years, but due to no usage, and availability of alternatives, it was deprecated to reduce maintenance overheads. Other services which cover the same languages are still available. [2]

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 15 August. It will be on non-Wikipedia wikis and some Wikipedias from 16 August. It will be on all wikis from 17 August (calendar).
• Starting on Wednesday, a new set of Wikipedias will get "Add a link" (Latin Wikipedia, Ladino Wikipedia, Luxembourgish Wikipedia, Lak Wikipedia, Lezghian Wikipedia, Lingua Franca Nova Wikipedia, Ganda Wikipedia, Limburgish Wikipedia, Ligurian Wikipedia, Lombard Wikipedia, Lingala Wikipedia, Latgalian Wikipedia, Latvian Wikipedia, Maithili Wikipedia, Basa Banyumasan Wikipedia, Moksha Wikipedia, Malagasy Wikipedia, Armenian Wikipedia, Kyrgyz Wikipedia). This is part of the progressive deployment of this tool to more Wikipedias. The communities can configure how this feature works locally. [3]

Future changes

• A few gadgets/user scripts which add icons to the Minerva skin need to have their CSS updated. There are more details available including a search for all existing instances and how to update them.

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

MediaWiki message delivery 05:59, 15 August 2023 (UTC)

{{sc}} and {{asc}} with diacritical marks below the letter

Whilst editing a page of text in an Indian work, some of which appeared to be in small caps, I noticed that neither of these templates works with letters having an 'under dot' (e.g. ḄḅṂṃỌọ, ḄḅṂṃỌọ cf. BbMmOo BbMmOo. They work OK with all the other common marks. Is this intentional? Chrisguise (talk) 10:53, 12 August 2023 (UTC)

The font is probably missing these accents for small-caps. All the template does is wrap its input in <span class="smallcaps" style="font-variant:small-caps;"> … </span>. The transformation to small-caps happens in the web browser and its font rendering engine. Xover (talk) 12:24, 12 August 2023 (UTC)

For example, in Firefox, the diacritics look fine to me in the example line above. If you are not seeing them correctly, it is a result of your browser and/or loaded fonts on your computer. --EncycloPetey (talk) 00:28, 14 August 2023 (UTC)

Not working for me in Chrome. To note that this is one of the reasons that we don't force fonts in works, as we try to keep the maximum flexibility that browsers and their updates allow. Sounds like making a bug request for Chrome would be useful. — billinghurst sDrewth 04:35, 14 August 2023 (UTC)

@EncycloPetey, @Xover I use Firefox. Chrisguise (talk) 06:01, 16 August 2023 (UTC)

Churchill

Am I correct the final volume of Churchill's "World in Crisis" hits Public Domain next year? Is it something we could start transcribing now with a template covering the text until the date? Does such a template exist allowing work on projects to be unveiled on the day of their release? Virginia Courtsesan (talk) 01:54, 14 August 2023 (UTC)

@Virginia Courtsesan: According to a basic scouring of the author page for Winston Churchill, his work called "World in Crisis" ran from 1923 to 1931, and considering that he's a British author, a {{PD-US-not-renewed}} license is highly unlikely. So, what I would think is the last volume will be in the public domain in the US on January 1, 2027, while any volumes from specifically 1928 will go into the public domain in the US next year. (Note, however, that scans of most of these works will not be able to be uploaded to Wikimedia Commons until 2036 due to the lingering UK copyrights, being 70 years p.m.a.).

But, yes, you can feel free to start a transcription of any volumes between 1923 and 1927, as those are PD-US. That it's incomplete due to reasons related to copyright won't matter. But I'm not aware of a specific template for that... I would recommend following the transclusion model at many periodical pages, for example: The Masses (periodical), which uses {{Auxiliary Table of Contents}}. There you could use {{copyright-until}} next to the name of one of the volumes in the auxTOC. Happy editing! PseudoSkull (talk) 02:23, 14 August 2023 (UTC)

The one that interested me was actually the 1929 volume, I'd put some hours into transcribing that - but are you suggesting it'd be Jan 1 2026 before it could be shared? Would the files be uploadable to Wikisource instead of Commons in the meantime, or not at all? I can't do much work if I can't get started sooner than 2026 :) Virginia Courtsesan (talk) 03:06, 14 August 2023 (UTC)

Not at all until they're PD in the US, which will be on 1 Jan 2026. Wikisource does not allow materials to be housed here if they are under copyright in the United States. --EncycloPetey (talk) 04:05, 14 August 2023 (UTC)

Appreciate the answer, doubt I'll return then - but anyways, it's worth a read :) Virginia Courtsesan (talk) 04:54, 14 August 2023 (UTC)

(1929 would actually be January 1, 2025, while 1931 = 2027. It's based on the fourth year, not the fifth.) PseudoSkull (talk) 05:12, 14 August 2023 (UTC)

@User:Virginia Courtsesan There was, or is, an unconnected Canadian website which hosted works that were still copyrighted in the US, but not in Canada. Unfortunately, I didn't keep up with their continuance, nor is Canadian copyright laws are known to me. — ineuw (talk) 02:17, 16 August 2023 (UTC)

Wikilivres is long dead, so that's not a go. Beeswaxcandle (talk) 06:14, 16 August 2023 (UTC)

Footer of header template not styled green anymore

Above is what the footer looks like on all transcluded pages on my end. Where was the CSS recently broken for specifically the footer and not the header? PseudoSkull (talk) 01:48, 16 August 2023 (UTC)

@PseudoSkull: It was a "pardon our dust"-type situation. Should be back to normal now. Xover (talk) 08:24, 16 August 2023 (UTC)

@Xover: Thanks. Is it supposed to be appearing above the {{Authority control}} and PD templates? PseudoSkull (talk) 12:04, 16 August 2023 (UTC)

@PseudoSkull: No, that's a bug (probably related to dynamic layouts) if it is. I'll take a look as soon as I have a moment. Xover (talk) 13:41, 16 August 2023 (UTC)

@PseudoSkull: Fixed. Please let me know if you find any other weirdness. Xover (talk) 16:54, 16 August 2023 (UTC)

Defaultsort automatically "The ", "A ", "An "?

Is there a reason the site doesn't automatically defaultsort beginnings like "The ", "A ", and "An " in titles? Why do we have to add the {{DEFAULTSORT}} keyword every time? It's the same thing over and over again... More work for something that seems to me to be wholly unnecessary... And the margin of error is very high; forgetting to add the defaultsort happens an awful lot, and then users like Simon Peter Hughes or Captain Nemo (or even me sometimes) need to be active so they can come and add it behind us, but human beings can't get everything...

Long, linguistic explanation: The only exceptions to "the" not referring to the English definite article "the" would be something like a variant of the Danish and Swedish word for "tea" (the drink), or one of many Vietnamese variant words (usually containing accent marks) that happened to be spelled "the"; see English Wiktionary's full list of language entries for the for even more rare examples than that from other languages. "A " not referring to the indefinite article but instead referring to the letter A (such as in "A B C"), is certainly possible, but still exceedingly rare especially to begin a title. I feel like we could just use the template for exceptions to the rule, and that would be more worth our time than manually defaultsorting for every case of "the" etc.. So maybe for those exceptions (if they exist), we could do something like {{DEFAULTSORT:A B Cs of the Animal Kingdom}}, or {{DEFAULTSORT:The Vi Kan Lave: A Scandinavian Tea Recipe Book}} (and the fact that I had to make up these names, instead of pulling actual examples, tells you just how rare these sorts of things are).

So in 99.999999% of cases, the, a, and an in the beginning of titles refer to the English articles that need to be defaultsorted against. So maybe let's make the software do the defaultsorting for us, so we don't have to ever manually add {{DEFAULTSORT}} in these cases. PseudoSkull (talk) 22:37, 8 August 2023 (UTC)

A bit more answer: (1) How would the software reliably detect whether it should drop an "A" or should not drop the "A" for sorting? In Spanish "A" means "to, by, at" and since it's a preposition, it should be kept for sorting purposes. In Galician, "A" is a pronoun, and should likewise be kept. The same is true for many other languages, so an automated default would need to know the language of the title or phrase being sorted, and that's not as straightforward as making a list for every language and applying each list on the projects in that language. (2) Would Mediawiki do this only for English, or for every language's non-sortable articles? English has a simple list of three possible words to drop, but some languages have longer lists, and for which those words might be attached to the beginning of a title word, or to the end of a word, rather than appear as a separate word. French articles form a contraction, so for Victor Hugo's novel L'Homme qui rit, the "l'" would need to be dropped, which is part of a contracted word rather than a separate word. In Portuguese and Galician, the articles are "o, a, os, as, lo, la, los, and las", however these words also function as 3rd-person pronouns. So, these words should only be dropped when they function as articles, and not when they function as pronouns, and there is no computer algorithm for making that determination. While you might expect default sorting to be easy based solely on experience with English, it quickly becomes a very complicated issue in other major world languages. --EncycloPetey (talk) 23:25, 9 August 2023 (UTC)

Addendum: go look on English Wiktionary at [the forms of ὁ] = "the". You will have to expand three separate tables to see all the forms. --EncycloPetey (talk) 23:33, 9 August 2023 (UTC)

It could be done this way in just English Wikisource, and other Wikisources can have their own defaultsorting keywords or rules. There is a very straightforward categorization there. "English Wikisource does this. Greek Wikisource does that." Is it really so hard? And is it really worth all the effort on enWS to do this manually when we know that "The " is 99.999% of the time going to refer to the English pronoun? Yes, I understand the existence of those Romance language pronouns, but we won't be using those most of the time here, especially where they coincide with the three English articles. And where those other languages are used in English titles, we can handle those cases on an individual basis, IMO.

The structure on English wikis should first assume "The ", "A ", and "An " are going to be autosorted against. Then we can handle the exceptions manually. That's what I'm proposing.

And that sort of thing should generally be the rule in any similar discussion to this; if you have to do something manually the same way in over 99% of all cases, then just make that automatic and make the scant exceptions manual. There's nothing difficult about doing it that way. It seems that the post above is coming primarily from the place of a fear of change, which seems to be the common theme in a lot of EP's posted rebuttals. If all wikis were to use that same logic everywhere, we would be as far behind technically in 2023 as a lot of US state government web pages that look like they haven't been modified since 1997. PseudoSkull (talk) 23:51, 9 August 2023 (UTC)

@EncycloPetey: We would typically implement this in the {{header}} template. Other projects would be free to steal our code, but we'd only try to solve the needs of enWS (so a much much simpler task). What I am actually most concerned about before doing some testing is whether DEFAULTSORT is one of those magic words that has severe limitations on where it can appear and whether it can be overridden and so forth (like DISPLAYTITLE has). Because if we by default add a sort key to every single text, it had better be straightforward and easy to manually override it on the texts where the computer gets it wrong (even if it is just one in ten thousand texts). Xover (talk) 07:34, 10 August 2023 (UTC)

 

Searching a list of En.WS titles gives 36495 titles with an "A " in the name, and ABC gives three or four examples of works that shouldn't have an "A" dropped. So that's one in ten thousand, 99.99%, at worst.--Prosfilaes (talk) 23:45, 9 August 2023 (UTC)

And what about cases where it's the first word of a subpage, because we need to sort a work contained inside a collection of works? You don't want to also handle those? Even in English, this quickly becomes complicated. --EncycloPetey (talk) 00:07, 10 August 2023 (UTC)

@EncycloPetey: Either we decide that all subpages get a default sort key, and we compute that sortkey using the usual rules except ignoring the subpage prefix, or we decide that subpages do not get a default sortkey. I'm not aware of any particular special rules for subpage titles beyond needing to ignore the subpage prefix. The default sortkey also has no effect unless the subpage actually is in a category, which most(?) of our subpages are not. Xover (talk) 07:52, 10 August 2023 (UTC)

 Comment With so many biographical compendiums, we often have defaultsort set on the subpagename, so we would need to differentiate between rootpage and subpage. — billinghurst sDrewth 05:39, 12 August 2023 (UTC)

Since we're mainly concerned with "The ", "A ", and "An " at the beginning of a page name here, the vast majority of biographical subpages would not get an automatic sortkey. And for any that do, the last DEFAULTSORT in the page wins; so if {{header}} adds one that is for some reason wrong, any manually added DEFAULTSORT later in the page will override it.

I've looked quickly at what it'd take to implement this and it looks pretty straightforward, and of the concerns raised so far I don't see any that we could not address, so my inclination is to move forward with this. Are there any other pitfalls or gotchas we need to consider? Any other concerns with doing this? Xover (talk) 06:49, 12 August 2023 (UTC)

Ok, the main technical gotcha seems to be that MediaWiki generates a big honkin' error message for duplicate sort keys (for some reason), and any later (source order) defaultsort will override an earlier one. So if we're to do this through {{header}} we'd need to require the override to be provided using a |defaultsort= parameter to header rather than using the DEFAULTSORT parser function. The migration of existing cases should be fairly straightforward with a bot. But since we'd require doing this through |defaultsort= in some cases we would probably need to make that the standard way we do it so the guidance doesn't have to have lots of if this then do that, but in this other case you should do this. --Xover (talk) 17:30, 20 August 2023 (UTC)

Tech News: 2023-34

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

Recent changes

• The GDrive to Commons Uploader tool is now available. It enables securely selecting and uploading files from your Google Drive directly to Wikimedia Commons. [4]
• From now on, we will announce new Wikimedia wikis in Tech News, so you can update any tools or pages.
  • Since the last edition, two new wikis have been created:
    • a Wiktionary in Pa'O (wikt:blk:) [5]
    • a Wikisource in Sundanese (s:su:) [6]
  • To catch up, the next most recent six wikis are:
    • Wikifunctions (f:) [7]
    • a Wiktionary in Mandailing (wikt:btm:) [8]
    • a Wikipedia in Ghanaian Pidgin (w:gpe:) [9]
    • a Wikinews in Gungbe (n:guw:) [10]
    • a Wiktionary in Kabardian (wikt:kbd:) [11]
    • a Wikipedia in Fante (w:fat:) [12]

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 22 August. It will be on non-Wikipedia wikis and some Wikipedias from 23 August. It will be on all wikis from 24 August (calendar).

Future changes

• There is an existing stable interface policy for MediaWiki backend code. There is a proposed stable interface policy for frontend code. This is relevant for anyone who works on gadgets or Wikimedia frontend code. You can read it, discuss it, and let the proposer know if there are any problems. [13]

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

15:25, 21 August 2023 (UTC)

'Edit pages in sequence' tab

I'm not sure if this is the right place to provide feedback, but a new (to me at least) tab has appeared on Wikisource pages. I gave it a go, and the tool does seem to offer some benefits, mostly by reducing the number of 'clicks', and movement around the page, in some circumstances. It's principal deficiency at the moment is that it doesn't pull in any pre-defined header and footer text from the index page when it creates a new page. Chrisguise (talk) 06:18, 16 August 2023 (UTC)

@Chrisguise: The developer of this feature is @Sohom Datta. There's a mass message with information about it coming, but due to timing issues it's coming after the feature got deployed. I haven't had time to test it myself so I can't comment on the points you raise. Xover (talk) 08:28, 16 August 2023 (UTC)

@Chrisguise @Xover That's a good point, I had assumed the pre-defined headers would be loaded on preview :( I'll try to get 941776 fixed and deployed as a fix for this issue with the next week/few weeks. -- Sohom (talk) 17:10, 16 August 2023 (UTC)

Thanks for this @Sohom Datta:! Great to see new tools rolling out here. -Pete (talk) 17:32, 16 August 2023 (UTC)

how do i disable the tab? it shoves the toolbar down, wasting space. --Slowking4 ‽ digitaleffie's ghost 18:12, 16 August 2023 (UTC)

@Slowking4 Currently that is not possible outside of custom CSS, however I'm unsure of what you mean by pushing the toolbar down. The tab should fold into the "more" dropdown if there isn't space for it :( Sohom (talk) 00:26, 17 August 2023 (UTC)

thank you for removing the tab for the moment. a check box opt in would be nice. the text of the tab is so wide that it pushes down the "transcribe text" tab to a new line. changes to UX can be controversial. --Slowking4 ‽ digitaleffie's ghost 01:48, 17 August 2023 (UTC)

Without the option of disabling it and documentation it must be disappear! No matter how great an idea is. — ineuw (talk) 12:33, 17 August 2023 (UTC)

┌─────────────────────────────────┘
Context: Correction, it must disappear from the editing space. One must get used to it, and decide if it's appearance and use is beneficial in all circumstances. In my case, the increase of the frame with overpowering and large icons is very bothersome. — ineuw (talk) 12:51, 17 August 2023‎ (UTC)

@Ineuw, @Slowking4: Let me guess, you're using a skin other than Vector (guessing monobook)?

@Sohom Datta: Based on extremely quick and superficial testing it looks like EIS is kinda broken on any skin other than classic Vector due to the length of the tab's text combined with the lack of a dynamic "More" menu in other skins. Vector 2023 is… well it's generally broken on Wikisource as yet so probably not worth spending any effort on just now. Whether other skins are worth fixing, or perhaps EIS should be disabled in other skins, I've no real opinion. We have a handful of monobook users on enWS that I know of, but more and more features and Gadgets are missing or broken there so so long as we don't actually make things worse for them I think that's reasonable.

PS. EIS seems to break the useskin=skin URL parameter (and probably other URL parameters too). Or at least when testing this it stayed in Vector and offered to create the wikipage Page:War and Peace.djvu/123&useskin=monobook. It could just be me being dumb, but... Xover (talk) 14:45, 17 August 2023 (UTC)

@Xover Responding to your last point, EIS should not be breaking any kind of parameter. Page:War and Peace.djvu/123&useskin=monobook probably means that useskin=monobook is the first in the list of parameters. You would want to use something like ?useskin=monobook for it to work.

Also, I daily drive Vector22 (and explicitly tested it in Monobook), I haven't (yet) observed the broken behaviour that you mentioned, would it be possible to provide a screenshot ? Sohom (talk) 15:28, 17 August 2023 (UTC)

@Ineuw @Slowking4 It is technically feasible to make it "disappear", however, as I have previously mentioned in the associated phabricator ticket, making it "opt-in" only/hiding it in preferences is going to make it impossible for editors to find and enable when required. My initial assumption was that "just adding a tab" similar to how Visual Editor (and many gadgets currently used by the community work) would be unobstrusive and uncontroversial enough of a UI change.

I'm open to other less obstrusive places where this can be placed, where it would still be easily accessible when required. Sohom (talk) 15:49, 17 August 2023 (UTC)

@Sohom Datta: If you're looking for alternatives, a button in the toolbar along with the Proofread Page buttons (show header/footer, vertical/horizontal) would be an obvious one (or top level in the toolbar for that matter). Unless we at some point in the future get to the point where EIS is what you get by default when you hit the "Edit" pseudo-tab, it's going to be somewhat a power-user feature and so doesn't need to be as incredibly in-your-face as the current tab for discoverability purposes. It's generally problematic to subsume or abandon the fundamental UI of MediaWiki (we're still a wiki); so much like the new OCR tool shouldn't have invented a completely new UI for their "Transcribe" button, mimicking the main MediaWiki "Edit" pseudo-tab is a (IMO) a bad idea for this kind of higher-level feature. I understand the reasoning, and when looking at it from the perspective of the person who is developing this feature it'll make sense, but it's a bit of a "everyone wants highest priority / primacy of place" situation. Xover (talk) 16:03, 17 August 2023 (UTC)

@Sohom Datta: Interesting. I can't reproduce now. But it wasn't the lack of a ?. I opened a non-existent page from an Index, so at that point you already have ?title=…&action=edit, and added &useskin=monobook to it. But since I can't reproduce let's just assume I fatfingered something. Regarding Vector 2022 my point was just that it's not been adapted for use on Wikisource so any suboptimal behaviour or breakage there is probably not top priority. If it's your daily driver your calculus may differ. :-) My point was mainly that looking at the other skins (very very quickly and superficially) it looked kinda bad (monobook especially since it doesn't support dropdown menus; combined with other Gadgets that add stuff up there the toolbar extends way off the width of the page on my 15.4" widescreen laptop display). And for these you may want to look closer and consider whether it can be fixed / optimized, or whether that'd be too expensive (take too much time/effort/hacks/etc.) and a better option would be to disable EIS in those skins. I've no particular opinion, I just looked quickly at the other skins while trying to figure out what the issues Slowking and Ineuw are reporting are. Xover (talk) 15:53, 17 August 2023 (UTC)

yeah, i am using timeless skin. and for small screens the tabs do funny things. if you don’t like opt in, how about opt out? and it’s a wiki community, so unannounced UX changes is not cool. but feel free to code on and ignore my griping, everyone else does (hence the Visual Editor non- take-up). --Slowking4 ‽ digitaleffie's ghost 21:09, 17 August 2023 (UTC)

 Comment When we are offering additional tabs, I would suggest that we would always look to offer an opt-out gadget by default. The issue is that for many of us, the old monobook serves many of us way too well for proofreading, and vector still hasn't delivered the wins and the ease to make us move. Noting that my use of monobook is typically only here on the WSes, not elsewhere, so I am not just a grumpy dinosaur. — billinghurst sDrewth 00:07, 18 August 2023 (UTC)

I am using vector.—As I sat down to proofread and while away a rainy summer morning, I clicked on this new feature, and faced something so unexpected, that I panicked. Before posting, I tried to figure it out but ran out of time. I thought about it off and on, and would rather give constructive comment.

It's a very good idea. But, for instant user recognition and no documentation, it would help if you used the old radio buttons, instead of the window icons, and retained the controls' layout and size as it appears at the bottom. — ineuw (talk) 01:33, 18 August 2023 (UTC)

I tested this some days ago and I found that new links added to a page aren't reflected when the changes are published. Ciridae (talk) 04:39, 23 August 2023 (UTC)

This is working now. Ciridae (talk) 13:23, 23 August 2023 (UTC)

Default tab position in pages messed up

Probably in connection with that new sequencing feature, as that is the only recent change (that I know of, at least) to the pages. The default tab position is the bottom, not the top, which is a pain when switching from header to body. Can this be turned off? TE(æ)A,ea. (talk) 22:55, 17 August 2023 (UTC)

Speaking only for myself, wish I could read your mind. — ineuw (talk) 10:40, 23 August 2023 (UTC)

De-linting..

Thanks to some efforts by myself and other dedicated contributors,

A reasonable chunk of the what was listed on Special:LintErrors in respect of content in Page: namespace, that had been proofread or validated has been resolved. :)

Ignoring pages that have not yet been proofread, I am noting that in terms of what remains a sizeable chunk is unclosed italics, search query

In many situations, resolving the unclosed italics in a single page takes 20-30 seconds, when reading against the page scan, and if a number of contributors do this in parallel, the remaining concerns could be resolved by the end of the year! ShakespeareFan00 (talk) 10:37, 19 August 2023 (UTC)

And I looked at the last page there and saw an entry that I had created earlier in the day ! -- Beardo (talk) 12:07, 20 August 2023 (UTC)

Should we do anything where the page showing there is raw OCR with a mess of odd punctuation ? Should we get rid of stray italics so that page does not show in that listing ? -- Beardo (talk) 13:28, 23 August 2023 (UTC)

I'd genrally been focusing on already proofread content which should not have Lint Errors if proofread. If you want to try and reduce the mess of "Not-proofread" raw OCR in the listings, feel free. ShakespeareFan00 (talk) 13:33, 23 August 2023 (UTC)

Edit pages in sequence: Cannot change status

I have this issue on 2 pages now (linked below). Both were proofread by another user. I made changes and published those changes using the 'Edit pages in sequence' method but without changing the status to 'Validated'. Now I can't change the status to 'Validated' at all even though I should be able to. It seems this method is overwriting the user who made the status change even in cases where no status change was made, instead of simply saving.

• Page:Bismarck and the Foundation of the German Empire (1899).djvu/398
• Page:Bismarck and the Foundation of the German Empire (1899).djvu/467

- Ciridae (talk) 11:36, 25 August 2023 (UTC)

Periodicals listing

Hello. I have been an active member of the German Wikisource for around 12 years now and was one of those who have finally achieved that pages only listing links to digitized works of individuals on the one hand and pages listing links to digitized versions of magazines and journals could be set up the German Wikisource.

Over the years, we have the following different kinds of pages on periodicals

• 1) a comprehensive listing of all titles covered A-Z at WS Zeitschriften, each title followed by a link to the subject area the journal is on (and where the journal may be further discussed or its sequence of titles and sub-titles is listed).
• 2) Several sub-pages dedicated to individual subject areas like, to give just some examples, Classical Studies / Studies of the antiquity, Books and library sciences including Book printing and production etc. On these subpages we also interlink the title sequence (previous title - new title) of each journal that had more than one title so that the full sequence of titles one journal had is covered, plus on the other hand we list the mergers of two or more journals into one or the absorption of one title by another journal (takeover, purchase of one journal by another) - (see example for the linking of previous and new title or an example for a journal which absorbed another one.
• 3) Journals generally having more than 15 or 20 volumes have aditionally been separated into an individual page dedicated to this journal alone (e.g. Building news and engineering journal). All separated pages are linked both in the general comprehensive list of titles and in the individual subject area (where title sequences etc. are also discussed). As a result we not only have a list of titles by subject area, but also a comprehensive list of all titles covered and where this journal can be found.

Some years ago, I was repeatedly approached by some members of the German Wikisource if I could help them with getting together a collection of the one or other foreign-language journal on a given topic, which finally gave rise to a discussion to install sub-pages in the individual subject areas for journals/magazines in other languages than German if a number of such journals has been integrated into the actual "German" listing of German-speaking journals on the given topic. As a result we have a large number of journals, among them many in English, e.g. on Technology, Architecture and Building, Books and library sciences including book printing, Photography, Parapsychology, The Arts or Medicine. Why I am writing is that now in the German Wikisource a discussion was started if it weren't wiser to integrate our efforts to have lists of journals in foreign languages other than German in the dedicated WS department, e.g. English-speaking journals here in your WS section, French in the French sub-section.

I generally support this idea and am glad to see that meanwhile the English Wikisource allows such listings of links to digitized volumes of a journal. Of course I simply could integrate the journals dedicated to one journal in the appropriate subject area, but I would also like to open a discussion if a system similar to the German Wikisource system now adapting the separation into

• one main portal page comprising an alphabethic listing of all titles covered A-Z on the one hand and
• sub-pages of the relevant subject area (what area of interest the journal is on), on which title sequences, mergers, absorptions etc. could be properly illustrated would be a feasible way to further develop the English periodicals section.

plus

• pages dedicated to one journal (either in the full run or interlinked individual pages for each title a journal had (provided that the journal was published over more than a certain minimum of volumes, for "small" journals covering only 3 or 7 volumes like The Builders' journal, Boston or Electrical industries, Chicago can easily be integrated into the sub-pages on individual subject areas and only "bigger" journals get their dedicated page.

I see a number of advantages in such a system for the bigger the number of titles finally covered is the more difficult it might become to keep an overview of whether a title is already covered or not,, the more so with numerous journals like "The Builder" which could either be classified as a technology journal or one of the subject area architecture and building. Also a journal that e.g. has 3 volumes overall only like Architecture : a monthly magazine of architectural art (London : Talbot 1.1896 - 3.1898) would not have to be separated into a separate page but could be simply listed on the page of the subject area with the links to the digitized items of all three volumes and the title simply be integrated in the portal page comprising an alphabetical list of all journals covered (and where).

I am starting a discussion here in the general discussion, as I do not want to simply make changes to the existing periodicals section. I would like to actively support the development of the English periodicals section / portal and of course would be delighted to move the many listings I have already made to the English Wikisource for this purpose. If such a move seems sensible to you as well, I would appreciate it if certain automated templates we have introduced e.g. for Google Books, Hathitrust, Archive etc. would also be installed in the English WS, so that if any changes are made to the big repositories in the future, those link templates can be reviewed so that still all links to GBS, HT or IA remain working.

I would also like to continue to try to establish which gaps finally exist (which volumes have not yet been scanned anywhere) and identify libraries that could help getting these digitized and ingested e.g. into Hathitrust, Google Books only, Internet Archive or on individual pages of university libraries that are no members of the Hathitrust consortium or do not have a workflow established to ingest their digitized volumes into Hathitrust (like e.g. Linda Hall library for the history of sciences and technology or U Chicago with whom I have completed a number of journal listings with volumes not yet scanned, but whose volumes are not ingested into Hathitrust or Google Books but only on their page (or if I upload a copy also on Internet Archive).

Sorry for the long message. I hope I can make myself understood. Ptherwise I am happy to arrange for a video call to explain in further detail what I am suggesting. Haendelfan (talk) 15:06, 11 August 2023 (UTC)

@Haendelfan: enWS has a somewhat different approach through our use of namespaces. Our main namespace is for reproduced works, our author: ns for author pages, and our topic pages are in Portal: ns, and then numbers of other namespaces that would replicate deWS/. We have long allowed a curated approach to subject matter and for periodicals, and especially in our Portal namespace allowing a lot of latitude. As such the reproduced components of our periodical should be the only existing component in the main namespace, anything else that is constructed would be in the portal namespace, and that could be solely as topic matter, or it could be for the periodical and subject matter splits; we truly let allow plenty of latitude for people to experiment within reason there. — billinghurst sDrewth 05:29, 12 August 2023 (UTC)

@Haendelfan: Since I am not familiar with deWS's approach I am having a little trouble following you. Perhaps you could give one narrow and concrete example of what you are proposing to do? Cooperation between the Wikisourcen is awesome, but experience indicates that the different projects have at times taken very different approaches. What you describe sounds like a fairly rigorous and preemptive approach to the issue, but as Billighurst succinctly describes above enWS has allowed quite a bit of latitude and as a result has a fairly large spread of approaches. I suspect the two approaches are not really compatible, but perhaps there is a limited subset where they could be made to be so? At very least I am interested in exchanging experiences and learning across the projects so that we all evolve over time. Xover (talk) 07:11, 12 August 2023 (UTC)

@Billinghurst: @SDrewth: @Xover:Hello and thanks for coming back to me on my suggestions. I am a bit puzzled as I understand your feedback like none of what I was talking about is existing in enWS. If that is the case, sorry for troubling you. Yet in fact I discovered something very similar - namely Portal:Periodicals, which however is a mixture of what I suggest to be split in 2 kinds of pages : one alphabetical list of all journals to be covered and then sub-pages for e.g. Periodicals (Arts), Humanities, Periodicals (Philology), Periodicals (History), Periodicals (Archaeology), Periodicals (English / American ... / Foreign Literature) or Periodicals (Literature) (comprising all of these), Book-related topics comprising Library Sciences, Book printing and binding etc (or again separate pages for Book Production, Library Sciences, Bibliographies).

From your Portal:Periodicals all periodicals covered so far are separated onto separate pages. This is very useful for the bigger journals with a long production run, while the advantage of having separate pages for e.g. Periodicals (Architecture) etc. would be that journals which were only published in 3-10 or 12 (to give a sample number) like Architecture : a monthly magazine of architectural art with just three volumes (London : Talbot 1.1896 - 3.1898) could be simply listed in the subject area page (e.g. Periodicals (Architecture)). Anyway, you have the other category of pages, namely pages listing links to the individual volumes of a journal e.g. The British Architect. This latter is just one example where the equivalents in the German WS are much more complete and could supplement the enWS very good (see The British Architect on German WS (ten volumes available in enWS compared to 70 of 88 available in digitized form on GermWS). Also if you compare the pages of the two, you will see that in the GermanWS the subpages on individual journals have a header categorising it as a journal volume listing page Template:Zeitschrift which again gives a lot of possibilities for categorisations e.g. by Publication year, by the place of publishing or again the area. Also we have included the link to the ZDB Periodicals database, which is one of the best freely accessible journals database, which however has a lot of gaps with regard to American or Canadian journals as it was instituted as a central German register of all journals and magazine volumes preserved in libraries in Germany. Primarily the register is for the print volumes, but meanwhile many of them, primarily of course German, are interlinked with an electrical edition. GermanWS has been acticvely working on getting our curated list of links to electrical copies in open access registered in the ZDB as well (which could be another benefit for the world).--Haendelfan (talk) 00:34, 13 August 2023 (UTC)

Rather than creating a Portal:Periodicals (Philiology), we would use the existing Portal:Philology and linguistics and add a section for ===Periodicals=== under the General heading. We already have Portals on most major subjects, arranged according to the Library of Congress Catalog system. See Portal:Portals and navigate down to any topic. --EncycloPetey (talk) 01:17, 13 August 2023 (UTC)

Thanks for this suggestion. If I may say, we started similarly in the GermanWS, but then let go of this approach as the portal pages on technology on the one hand comprising encyclopedia, textbooks, handbooks etc. on the subject and the part of the journals alone on the other increased to a degree that it became very difficult to find a journal again. Rather we now have a reference to the relevant periodicals sub-page on the portal page for a subject area. --Haendelfan (talk) 22:36, 13 August 2023 (UTC)

I can't see how it would be better to have one Portal for a topic and a separate portal for the periodicals on that topic. --EncycloPetey (talk) 00:25, 14 August 2023 (UTC)

Portal subpages are feasible, but should only be used when the parent gets unwieldy. My preference would be that such subpages would be by topic/subtopic, rather than by type of publication. That way journal articles, books, and encyclopædia entries can still remain on the same page. Beeswaxcandle (talk) 06:31, 14 August 2023 (UTC)

Thanks for referring to another place where periodicals can be found. Comparing Portal:Periodicals and Category:Periodicals I found that there are journals which are grouped in one category, but which are not included in the general overview of journals in the portal. I find it a good idea summarising all journals at one place and likewise bring a system into the categorization, i.e. that each individual page dedicated to one journal should also have the appropriate categorization, possibly for more than one subject area if applicable. (See for example #REDIRECT Portal:Printers' Ink is included in the but not in the Portal:Periodicals.

Also I would like to agree on rules as to what to do with e.g. Electrical Review (Chicago) and the individual titles it had. Should these all become individual pages, if so would there be a possiblity to have a page template for journals in which a category "previous title" and "new title / succeeding title" vs. "new title / merged into", so that the page for one title refers to the following or to the preceding title. As for the mixture of pages only having references to scanned items elsewhere or in the wikimedia subsection and those set to become an edition of some kind (even though sometimes only 2-3 articles from one volume from a volume run of 120 volumes or more, I suggest to first have the reference to the scanned item and opening up a reference to the WS edition of a volume behind that volume so that for convenience reasons a volume of the journal can be accessed irregardless of whether a complete or selected proofread edition of that volume exists. Sorry to bother you with all these questions, but I do not want to open up another new system or so.--Haendelfan (talk) 12:31, 14 August 2023 (UTC)  Comment For organisations of periodicals by subject, I would still think that we would simply use the categories and subcats => Category:Periodicals. Our portals have typically been created through need with latitude for the creator to identify which and where, not through a systematic approach. None of us identified ourselves as being skilled cataloguers

If a periodical has had multiple titles, one solution is to create a Portal for that Periodical, which lists and links the various titles and volumes / issues. We have a |portal= option in our {{header}} template that would backlink to the Portal. --EncycloPetey (talk) 20:07, 14 August 2023 (UTC)

During the discussion here and following a first contribution it became more and more evident that my intentions are incompatible with enWS's principles, goals and intentions. Even though there are some periodicals which only have links to selected volumes even though many more would be available, building a collection of periodicals with pure links where the texts are available in full text (even though not proofread) does not seem to have any meaning for enWS in itself and so I will no longer bother you with any suggestions, questions or contributions. Thanks for your feedback and sorry for bothering you with expanding the few already existing collections of links only. Feel free to delete my collection of links to The British Journal of Nursing. I will open a discussion on the subject in the WS for all languages, maybe we can build a all-European or even worldwide digital library of links to periodicals (in terms of references to where an individual volume of a journal etc can be found and freely accessed) there. --Haendelfan (talk) 17:47, 26 August 2023 (UTC)

Pages in Category:Typography templates

I see large numbers of pages being categorized automatically into Category:Typography templates, possibly because of use of {{separator}}, that aren't templates but are presumably using them. MarkLSteadman (talk) 05:42, 26 August 2023 (UTC)

Resolved, it was in Template:!) as someone has categorised the template, not the documentation; and the template component hadn't been suitably wrapped to avoid that issue. The categorisation will take a while to unravel. — billinghurst sDrewth 09:27, 26 August 2023 (UTC)

 Comment That is a horrible and brutal way to do that sort of line separator using a table that expands. i reckon that it should be converted into a redirect to {{***}}. Another of those facsimile rather than thoughtful replication templates. — billinghurst sDrewth 09:31, 26 August 2023 (UTC)

Thank you. MarkLSteadman (talk) 14:55, 26 August 2023 (UTC)

Wikisource Community meeting 26 August 2023

Wikisource Community User Group held a google call, m:Wikisource Community meetings. there was an ether pad [14]

• BUB2 tool presentation : https://bub2.toolforge.org
• Google not indexing Wikisource
• List of grants for Wikisource (hand curated)
• Wikisource conference in 2024 in Denpasar, Indonesia.

Slowking4 ‽ digitaleffie's ghost 02:53, 27 August 2023 (UTC)

Tech News: 2023-35

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

• As part of the changes for the better diff handling of paragraph splits, improved detection of splits is being rolled out. Over the last two weeks, we deployed this support to group0 and group1 wikis. This week it will be deployed to group2 wikis. [15]
• All Special:Contributions pages now show the user's local edit count and the account's creation date. [16]
• Wikisource users can now use the prpbengalicurrency label to denote Bengali currency characters as page numbers inside the <pagelist> tag. [17]
• Two preferences have been relocated. The preference "Enable the visual editor" is now shown on the "Editing" tab at all wikis. Previously it was shown on the "Beta features" tab at some wikis. The preference "Use the wikitext mode inside the visual editor, instead of a different wikitext editor" is now also shown on the "Editing" tab at all wikis, instead of the "Beta features" tab. [18][19]

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 29 August. It will be on non-Wikipedia wikis and some Wikipedias from 30 August. It will be on all wikis from 31 August (calendar).
• New signups for a Wikimedia developer account will start being pushed towards idm.wikimedia.org, rather than going via Wikitech. Further information about the new system is available.
• All right-to-left language wikis, plus Korean, Armenian, Ukrainian, Russian, and Bulgarian Wikipedias, will have a link in the sidebar that provides a short URL of that page, using the Wikimedia URL Shortener. This feature will come to more wikis in future weeks. [20]

Future changes

• The removal of the DoubleWiki extension is being discussed. This extension currently allows Wikisource users to view articles from multiple language versions side by side when the <=> symbol next to a specific language edition is selected. Comments on this are welcomed at the phabricator task.
• A proposal has been made to merge the second hidden-categories list (which appears below the wikitext editing form) with the main list of categories (which is further down the page). More information is available on Phabricator; feedback is welcome!

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

MediaWiki message delivery 14:00, 28 August 2023 (UTC)

Review the Charter for the Universal Code of Conduct Coordinating Committee

More languages • Please help translate to your language

Hello all,

I am pleased to share the next step in the Universal Code of Conduct work. The Universal Code of Conduct Coordinating Committee (U4C) draft charter is now ready for your review.

The Enforcement Guidelines require a Building Committee form to draft a charter that outlines procedures and details for a global committee to be called the Universal Code of Conduct Coordinating Committee (U4C). Over the past few months, the U4C Building Committee worked together as a group to discuss and draft the U4C charter. The U4C Building Committee welcomes feedback about the draft charter now through 22 September 2023. After that date, the U4C Building Committee will revise the charter as needed and a community vote will open shortly afterward.

Join the conversation during the conversation hours or on Meta-wiki.

Best,

RamzyM (WMF), on behalf of the U4C Building Committee, 15:35, 28 August 2023 (UTC)

Leonard Arthur Bethell - letters

• Leonard Arthur Bethell

Firstly, a note re the history - from Omphalographer talk page. (Omphalographer removed this document from Wikimedia) "I note you deleted Bethell-Bailey_Letters.pdf recently, and suggested using Wikisource instead. Happy to do that - I have discussed with the British Library (owners of the original documents) and they are happy for me to put my transcript up, but not the photos of the documents. Odd rules, but that's what they say. So - do I need any special guidance to put this up on Wikisource, or shall I just go ahead and try it ? Charles.bowyer (talk) 16:54, 29 August 2023 (UTC)[reply] I'm not terribly familiar with Wikisource's policies on hosting transcriptions without scans. I'd ask for guidance at s:Wikisource:Scriptorium. Omphalographer (talk) 17:32, 29 August 2023 (UTC)

So this is my question: the original documents are available at the British Library (at F157/228) and they are happy for me to put up the transcripts, but not the originals. The originals are available to the public - at the library. Can I put up the transcript on its own - and if so, how do I do that ? (I will include a reference to the documents in the library. ) Charles.bowyer (talk) 20:37, 29 August 2023 (UTC)

• Charles.bowyer: Ordinarily, we would avoid adding new texts without the original images, but in a case like this an exception is clearly warranted. TE(æ)A,ea. (talk) 11:50, 30 August 2023 (UTC)

  Thank you Charles.bowyer (talk) 22:13, 30 August 2023 (UTC)

• What is their copyright status ? -- Beardo (talk) 14:00, 30 August 2023 (UTC)

  Yes - I checked on that. The British Library say I own the copyright of the transcript because it is my own work. Bethell's family - who I am in touch with - say they do not own any copyright on Bethell's material - so I think that covers the copyright question ? I don't know if it makes a difference but the letters are all well over 80 years old. The British Library, by the way, are keen on putting the transcript onto Wikisource, and say that they will include a link to it from their website.

  If all that does satisfy the issues, I would welcome some guidance as to how I would put the material onto Wikisource. Charles.bowyer (talk) 22:11, 30 August 2023 (UTC)

  PS - Sorry - I found the help pages afterwards. Charles.bowyer (talk) 22:17, 30 August 2023 (UTC)

@Charles.bowyer: If the British Library is claiming copyright in the scans (the image files) they are 1) in contravention of the law, and 2) acting against UK government policy. Scanning or photographing a page of text does not create a new independent copyright and all claims to that effect can be safely ignored (see w:Bridgeman Art Library v. Corel Corp and various copyright circulars and guidance for GLAMs in the UK; they are explicitly not allowed to refuse anyone access to their collections on copyright grounds). If they still do this after ca. 2018 (when the central guidance was updated) they are being deliberately obstructive. The fact that UK GLAMS are chronically and shamefully underfunded and have a real need to supplement their income by selling copies and use licenses for digital reproductions of items in their collections is an explanation but not an excuse.

For similar reasons your transcription of the letters would not create an independent copyright: you're just mechanically reproducing the original so no matter the skill and knowhow or amount of effort (aka. "sweat of the brow" in legal circles) there is no creative input that would be eligible for copyright protection.

That being said, copyright springs into being when a creative work (such as a letter or other piece of writing) is fixed in a tangible form (e.g. being written down on paper), and for published works in the UK runs for 70 years after the year in which the author died. So for Bethell who died in 1950 the term will run until the end of 1950 + 70 = 2020.

On enWP enWS we are mainly concerned with copyright status in the US, which for non-US works often means it depends on its copyright status in the UK on the URAA date (1996 for the UK). When a UK work is in copyright at home on the URAA date US copyright comes into play with a term of 95 years after first publication. Merely including the work in an archive where it may be accessed does not start the copyright clock running (it is "limited publication" and the copyright clock triggers off "general publication"; think "offering copies for sale to the general public" as a coarse rule of thumb).

So, if the letters were published at the time they were written (uncommon, but not impossible) the US term of protection would be something like 1930 + 95 = 2025 or 1940 + 95 = 2035. If the letters were never published (general publication) then other more complicated rules apply (and in the UK they could theoretically be under perpetual copyright due to a dumb flaw in the UK copyright act).

In other words, we'd need to know a lot more about where and when and if they were first published in order to determine their copyright status.

PS. And if a copyright exists it is his heirs that own it the same way they inherited all his tangible possessions (copyright is primarily an economic right and can be inherited like any other such asset). If we can determine the legal owners of that copyright and they do not wish to exploit that right, another avenue might be to persuade them to release the letters under a free license (such as the Creative Commons Attribution-ShareAlike license, or even the public domain through the Creative Commons Public Domain Dedication {{CC-zero}}). We'd need them to verify this through the VRT process, but it's another option if the letters are still in copyright. Xover (talk) 07:12, 31 August 2023 (UTC)

If they were unpublished in 2002, then they would be life+70 in the US.--Prosfilaes (talk) 18:18, 6 September 2023 (UTC)

Good point. That'd be another way they could be in the public domain. It all depends on the when/where/if of publication. Xover (talk) 18:30, 6 September 2023 (UTC)

I abandon my request to put this transcript on Wikisource – I think I’m unlikely to win the debate on the complexities of copyright.

(By the way, I find it puzzling that any piece of paper once written on becomes automatically copyrighted - without anyone asserting a copyright over it. Does this apply to a shopping list.? If so, the process would appear to have submerged itself in its own complexity?)

To answer some of your questions -

'If the British Library is claiming copyright' - no, the British Library is not claiming copyright.

The British Library is not asking money for any part of this process.

The letters have never been published - nor was there ever any intention to publish them. They are not really that interesting. They are just social letters.

It is the British Library rules which preclude publishing their archive material.

Some emails for background below.

From the British Library

==============================================================================

RE: [Reference - Asia & Africa] Lt-Col Leonard Arthur Bethell (1879-1950), Indian Army 1899-1927.

You replied on Wed 30/08/2023 09:11

You replied on Wed 30/08/2023 09:11

[email and name redacted. --Xover (talk) 10:30, 9 September 2023 (UTC)

You

Dear Charles

Yes, as the transcript is your own work you can put it on Wikisource. If you send me the link I can put a note in our catalogue entry for Mss Eur F157/228 directing readers to it.

Best wishes

John

From: [email and name redacted. --Xover (talk) 10:30, 9 September 2023 (UTC)

Sent: 29 August 2023 16:24

To: [email and name redacted. --Xover (talk) 10:30, 9 September 2023 (UTC)

Subject: Re: [Reference - Asia & Africa] Lt-Col Leonard Arthur Bethell (1879-1950), Indian Army 1899-1927.

John

Thanks for that, and thanks for the information re the transcript.

Can I take it then that I can put the transcript (only) onto Wikisource ?

Charles

From:[email and name redacted. --Xover (talk) 10:30, 9 September 2023 (UTC)

Sent: 29 August 2023 16:12

To: [email and name redacted. --Xover (talk) 10:30, 9 September 2023 (UTC)

Subject: RE: [Reference - Asia & Africa] Lt-Col Leonard Arthur Bethell (1879-1950), Indian Army 1899-1927.

Dear Charles

I see what you mean now, I’m sorry for that misunderstanding.

As to your question, the BL does not own the copyright in the letters, but generally speaking we allow photographs to be taken in the reading rooms on the understanding that they are for the purpose of non-commercial research and private study only. Putting them on Wikisource would be a form of publishing and would therefore go against BL regulations on reading room photography, and it could potentially violate the rights of whoever does own the copyright in the letters.

The transcriptions are of course your own work.

============================================================================

and this is the email from the senior family member (oldest grandchild)

============================================================================

Re: Leonard Arthur Bethell

You replied on Thu 18/05/2023 17:51

You replied on Thu 18/05/2023 17:51

[email and name redacted. --Xover (talk) 10:30, 9 September 2023 (UTC)

You

I have no idea, Charles.

The thought of a copyright on LAB’s work has never arisen. And I do not think there should be a problem with using the drawing, which I have never heard of before. If I have any rights, you can have my approval!

Jock

============================================================================

On Thu, 18 May 2023 at 17:34, [email and name redacted. --Xover (talk) 10:30, 9 September 2023 (UTC) wrote:

John

Quick question - in advance of our much looked forward to meeting !

Do you know what is the copyright for Bethell's writings - or has it expired ?

I ask because I want to use a drawing from 'The Blind Road' as the picture for the Bethell Wikipedia - and Wikipedia are fiercely sensitive about copyright issues

Charles

============================================================================

Charles.bowyer (talk) 21:38, 7 September 2023 (UTC)

@Charles.bowyer: Short version: based on the information you've provided we can host the transcription of the letters here on enWS. Long version below:

Yes, copyright law is pretty insane, and international copyright is a maze.

But based on your information above, under US copyright law the letters, because they were never published before 2003, are subject to a pma. 70 copyright term (so until the end of 1950 + 70 = 2020). In other words, in the US they entered the public domain in 2021. In the UK, however, as they were not published before the end of 1988 and the author died before 1969, they are subject to copyright until the end of 2039 (it's a transition rule with a specific date term, known as the "2039 rule").

Wikimedia Commons' licensing policy requires content to be public domain or compatibly licensed in both the US and the country of origin (the UK), so no version (text, scans) of the letters can be hosted there currently. On English Wikisource we only require works to be public domain in the US, and so we can host both the scans and the transcription here.

Additionally, absent complicating factors (like the author selling the copyright in the letters to a publisher or similar) the UK copyright was a part of the author's estate and was inherited like all other assets. We can therefore assume the heirs currently own that copyright. If they are amenable they can thus grant a compatible license using the VRT process (basically they email a specific email address, answer a few questions, and conform that 1) they have standing to license the work, 2) are willing to license it under a given license, and 3) understand the implications of that license). If they do then both enWS and Commons can host the work. {{CC-zero}} is the most permissive license (it's essentially public domain), and {{CC-BY-SA-4.0}} the most commonly used generally permissive license (let me know if you need advice on the details of these and what they mean).

That the British Library and several other UK GLAMs are being recalcitrant about scans is a known issue. For a long time it was the established understanding that they could claim copyright on scans and photos of items in their collections. That notion was finally formally put to rest around 2018 (I think) and new government guidance was issued. Unfortunately, UK GLAMS are shamefully and chronically under-funded so 1) they almost have to supplement their income by selling prints and usage right to scans and photos, and 2) they can't really afford to do the sort of copyright clearance that would otherwise be required. The result is what you can observe here: a library and archive (one of the world's largest) that are bending over backwards to reduce the reach of their collections. I've had conversations with curators/archivists/librarians that speak like lawyers to try to justify refusing to release scans contrary to the guidance, without seeming to be refusing access to their collections or claim a non-existent copyright. Oh well...

…it's a pity, but as enWS policy currently does not actually require scans (it only requires there be a reliable source, and something vaguely similar to "notability") you can still add the transcription here. I would personally recommend you try all options for getting scans to back the transcription because I think it is likely that at some point in the future scans will become mandatory, but it is not a current or imminent requirement and the BL may very well have come to their senses by then.

One option for getting scans would be if you took the photos / made the scans yourself. Unless you actually signed a contract with the BL were you accepted terms prohibiting you from distributing them you're legally speaking free to do with them as you wish. The heirs have a copyright that you would need to adhere to, but the BL does not and thus could only use contract law to prevent you. Another option, if you got a legal release from the heirs, would be to explain the situation to the BL and ask them to confirm that they will not pursue any claim that might exist since you have independently gotten permission from the heirs. You may not want to deal with all that hassle (most people probably wouldn't), so I'm mostly just listing options here. Whether you want to pursue them is up to you.

Oh, PS., regarding your shopping-list example: a shopping list probably won't be eligible for copyright protection because it lacks creative merit. It's a mere listing of facts, and facts are not eligible for copyright. Letters, however, are an creative expression, and thus are treated as roughly equivalent to a novel, play, or speech. See e.g. A Letter to the Reverend Richard Farmer for one, extreme, example of why letters are subject to copyright. Copyright law is extremely complicated and often has pretty dumb effects, but all in all it does make sense once you begin to understand it. Xover (talk) 10:23, 9 September 2023 (UTC)

Many thanks for your help, efforts and information on this – much appreciated. I have asked the copyright holders – let’s see what happens. Charles.bowyer (talk) 19:09, 10 September 2023 (UTC)

The heirs - copyright holders - have agreed to putting the transcript on Wikisource - so now I need to lead them through 'VRT'. I know nothing about this - so would welcome help. Charles.bowyer (talk) 14:26, 12 September 2023 (UTC)