Wikisource:Scriptorium/Archives/2022-08

From Wikisource
Jump to navigation Jump to search
Warning Please do not post any new comments on this page.
This is a discussion archive first created in , although the comments contained were likely posted before and after this date.
See current discussion or the archives index.

Tech News: 2022-31

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

Changes later this week

Future changes

Future meetings

  • This week, three meetings about Vector (2022) with live interpretation will take place. On Tuesday, interpretation in Russian will be provided. On Thursday, meetings for Arabic and Spanish speakers will take place. See how to join.

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

21:21, 1 August 2022 (UTC)

No Download Link on Portal:Sherlock Holmes (UK Strand)

No download link appears on the page Portal:Sherlock Holmes (UK Strand) even though it has an AuxToc. Can someone take a look? Languageseeker (talk) 00:02, 3 August 2022 (UTC)

Board of Trustees election 2022 -- Candidates

Hi all,

Affiliate representatives have finished voting.
The following six candidates were selected to continue to the community voting stage of the election:

For more information, see the statistics and the results.

Thanks to the community members who participated. The candidacy for the Board of Directors is not a small decision. The time and diligence that the candidates have shown so far speak of their commitment to the movement. Congratulations to the candidates who have been selected. We also express great respect and gratitude to those candidates who were not selected.

From these six candidates, the community will elect two who will become the new Trustees.
Community voting begins on August 16 and runs until August 30.

Next steps:

Before voting, plase take a moment to learn more about the candidates' positions. You can do this in one of the following ways:


Thank you!
--BPipal (WMF) (talk) 13:31, 3 August 2022 (UTC)

A Grammar of the Malayalim Language (Peet 1841)

This work is written for English speakers (see what it redirects to), and so the text should be moved here from the Malayalam Wikisource. Pinging @Vis M, @Manojk: who I think are active at that wiki. PseudoSkull (talk) 12:34, 4 August 2022 (UTC)

@PseudoSkull: Yes, agree. Last year, I had requested its import here Wikisource:Administrators'_noticeboard#Import_help. We have to "Special:Import" those books. Only an enWS admin has the ability to import them.
One more book would meet the criteria (ml:മലയാള വ്യാകരണ ചോദ്യോത്തരം/Catechism of Malayalam grammar (Hermann Gundert 1897); see Wikisource:Requested_texts#Import_5_books_about_Malayalam_language)
All these 5 books are written for English speakers to learn Malayalam words, and the definitions are all in English. But only an enWS admin can use Special:Import. Please do so if you can. Thank you. Vis M (talk) 15:37, 4 August 2022 (UTC)

A dictionary of high and colloquial Malayalim and English

Ditto above. PseudoSkull (talk) 12:37, 4 August 2022 (UTC)

A Malayalam and English dictionary

Ditto above. PseudoSkull (talk) 12:49, 4 August 2022 (UTC)

Malayalam Selections

Ditto above. PseudoSkull (talk)

How to Think Like a Computer Scientist

This is currently transcribed at Wikibooks, but why? Isn't that less in scope for Wikibooks and more in scope for Wikisource? (Idk anything about Wikibooks, though, to be fair...) Also, I did find out that this book apparently exists in paperback form, so it could reasonably be transcribed. So I think we should transcribe the book here, which would get rid of the necessity of the interwiki redirect, and also (hopefully) get rid of the book at Wikibooks so we don't have it in two places. Pinging @Jusjih: who apparently has admin rights both here and there. PseudoSkull (talk) 12:44, 4 August 2022 (UTC)

Don't bother following the link shown on the Wikibooks page. Here's where the book can be found: https://open.umn.edu/opentextbooks/textbooks/80. There are links there for HTML and PDF versions. Rather than import from Wikibooks, why not just bring it here directly from the UMN website? Arbitan (talk) 15:51, 5 August 2022 (UTC)
Just to add, it is within the scope for Wikibooks, but how it'll be used there is different. Wikisource would store an exact representation of the book as it existed when it was published in 2002. Wikibooks can use the same book as the basis for their own version, which can evolve over time with user edits. (The license of the book allows for that.) For example, there's currently a merge proposal there where they would combine features of two different editions. Arbitan (talk) 16:13, 5 August 2022 (UTC)

Bookreader app

When I was uploading a scan of an English book to Wikisource a few days ago I noticed the bookreader app icon on the index page of the work, and was very impressed. We would like to be able to use the same programme on Wicidestun, the Welsh version of Wikisource. I can't find any information on how we might set up the application ourselves or who to ask to enable it for us. Could anybody point me in the right direction please? AlwynapHuw (talk) 19:35, 5 August 2022 (UTC)

@AlwynapHuw Those app icons are done with mw:Help:Page status indicators, as defined in MediaWiki:Proofreadpage index template. There doesn't seem to be any complex setup involved; it should work as long as the right link is generated. I believe the relevant line of code is 
<indicator name="bookreader">[[File:BookReader-favicon.svg|18px|link={{fullurl:toollabs:bookreader/en/{{{n|{{PAGENAMEE}}}}}}}|Open file in BookReader]]</indicator>
I'm not certain, but I think this could be copied right over to cy:MediaWici:Proofreadpage index template, simply changing bookreader/en/ to bookreader/cy/ (and translating the tooltip text). Shells-shells (talk) 00:35, 6 August 2022 (UTC)

It would sometimes be helpful if IA-upload didn't make files tiresome to use.

Index:NBS Technical Note 11176 (1983) (IAutilityprogramsf1176dick).djvu The OCR is out by one page. ShakespeareFan00 (talk) 14:07, 6 August 2022 (UTC)

I guess it is the usual bug. I personally stopped using it due to this "one page offset". Mpaa (talk) 09:00, 7 August 2022 (UTC)
Tracked in PhabricatorTask T194861
I sometimes use IA uploader and do not experience this problem, but it probably occurs from time to time, see the phabricator link. --Jan Kameníček (talk) 09:13, 7 August 2022 (UTC)

Portal:Devon

Something's wrong with this page. The header template has the class and subclass1 (IC), but the page renders with a ? where the class would go, and it's included in Category:Unclassified portals. I can't figure out why it isn't working. Arbitan (talk) 04:19, 7 August 2022 (UTC)

@Arbitan: Fixed. Experimenting with the portal header I found out that there was some problem with the spaces, I guess there must have been some invisible characters or something of that kind. --Jan Kameníček (talk) 10:57, 8 August 2022 (UTC)
Thanks! --Arbitan (talk) 11:13, 8 August 2022 (UTC)

Index:Bismarck and the foundation of the German empire (IA bismarckfoundati00head).pdf

The are two images missing from this scan: PRINCESS BISMARCK and EMPEROR WILLIAM I. coming after page 88 and 162 respectively. I don’t know if there’s another copy of this same edition elsewhere but these images are present in other editions. Can they be added? Ciridae (talk) 07:18, 8 August 2022 (UTC)

Here's another copy that seems to have the images: https://archive.org/details/bismarckfoundati0000jame --Arbitan (talk) 09:57, 8 August 2022 (UTC)

Copyright of the Pandora Papers

Are they subject to copyright? Blahhmosh (talk) 19:23, 8 August 2022 (UTC)

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

Changes later this week

  • There is no new MediaWiki version this week.
  • Some wikis will be in read-only for a few minutes because of a switch of their main database. It will be performed on 9 August at 07:00 UTC (targeted wikis) and on 11 August at 7:00 UTC (targeted wikis).

Future meetings

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

19:49, 8 August 2022 (UTC)

Template:ct

This template was recently deleted and all uses of it deleted by user:Billinghurst either manually or automatically by user:SDrewthbot with the reasoning "community has already decided against such a template". The only remains of the template are Template:Ct/doc

I don't see why this had to be done, as the text, when complied, copied as regular ct, and not a ligature, the works still were able to be searched as normal, and it makes the works that used it in the texts that much more authentic, since those ligatures are used in the texts.

I also haven't seen any discussion against templates like this, and the main reason I was told why we don't see them, is due to them messing with searching and copying, which this template had no issues with. Reboot01 (talk) 16:37, 1 August 2022 (UTC)

Strong agree. The reason for deleting it in the past was due to text searchability issues, but I re-created it specifically to get around those issues, by using regular ct in a <span> with CSS styling, which meant that it was completely optional. This honestly just felt like an overreaction by someone who didn't bother to look into how the template worked and/or has forgotten why the old version was deleted in the first place. @Billinghurst: please undelete this and revert your mass changes. You've mucked up a lot of hard work. Theknightwho (talk) 16:44, 1 August 2022 (UTC)
I'm not an active part of English WS, but I strongly agree. This is destruction of meaningful information, without any gain except for (doubt) wikicode readability.--Ignacio Rodríguez (talk) 16:50, 1 August 2022 (UTC)
Thanks for the responses, guys, I also just found the reasoning from Billinghurst on Theknightwho's talk page, linked here User talk:Theknightwho#template:ct for others to read. Reboot01 (talk) 16:55, 1 August 2022 (UTC)
I slightly misremembered the issue, as there is no "ct" ligature in Unicode. However, tracing back the supposed consensus, it stems from:
  • This brief discussion about the Unicode st ligature, clearly raising issues about text searchability.
  • This discussion about the ct ligature, where someone had inserted the private use charaacter  into a text, because that's the ct ligature in the MUFI extension to Unicode. This was (rightly) deleted, but apparently on the basis that we don't include ligatures as it's "what the community discussed several years back", referring to that brief 2011 conversation.
It's pretty obvious that neither of these issues are relevant here. In fact, one of the contributors to the 2011 discussion even said "This kind of ligature is properly implemented by a suitably intelligent font/browser and Unicode, which spots "st" combos and substitutes the ligature.", which is precisely what the new template did. Theknightwho (talk) 17:48, 1 August 2022 (UTC)
I have unprotected it. Even if you personally disagree with the existence of this template, I think without super-clear consensus in a previous discussion, and with only one deletion in the past, I think admin-protecting it at this point is a bit overkill. @Beleg Tâl, @Billinghurst: what is the harm of having this template around? PseudoSkull (talk) 20:57, 1 August 2022 (UTC)
I don't recall where the various previous discussions on this kind of ligature are, but it was consensus that purely orthographic ligatures would not be reproduced here. [Quite possibly it was in the context of a discussion about fi and fl.] Ligatures for an actual letter/glyph/character that represent a distinct phoneme, such as æ and œ were accepted. Whereas those that are publisher's orthography such as fi and ct were not. Yes, the arguments about copy/paste are increasingly irrelevant these days with modern browsers. Searches can still be problematic in some browsers. However, there is still the issue of these not being about reproducing the content of the work—which is our main goal and purpose. They are solely about reproducing the arcana of a font used by a publisher.
Also, the quote about "spotting combos and substituting the ligature" is not replicated by using a template. That is done when the browser sees "st" in the text flow and automatically ligatures them—much like most browsers today do with "fi" and "fl". Beeswaxcandle (talk) 21:19, 1 August 2022 (UTC)
The consensus was that we don’t want to use specially encoded ligatures, because they muck up searching. That is not relevant to this discussion, because this particular template only uses CSS styles to apply OpenType features in order to enable the ligature in fonts that support it, which is the kind of unobtrusive implementation that we should be fine with, because the text itself remains unchanged. In fact, this problem is exactly why Unicode haven’t encoded any more ligatures after the handful they added right at the beginning. By the way - CSS styles like this are quite literally how you get a browser to automatically substitute the ligature in the way you’re claiming this doesn’t do, so I don’t really follow your point at all. Nobody is suggesting we use the ligature characters, and given that we go to great pains in order to replicate the look of the original work very often, it feels very strange to rule this out. Seems like a post-hoc rationalisation, especially when we’re fine with long S, despite that being no less stylistic; the only difference is that it’s more widely supported in text search, which is the real issue here.
Thank you @PseudoSkull. @Billinghurst please revert your changes. There are too many of them. Theknightwho (talk) 22:35, 1 August 2022 (UTC)
I have gone ahead and reverted these anyway. There is clearly no consensus for speedy deleting this. Theknightwho (talk) 04:26, 2 August 2022 (UTC)
Browsers often ligate fl and fi and ffi automatically, and always ligate ي and ة that is, (ية). If the right font is used, it should ligate ct automatically. We don't want to mark up every copy of ct in a work to get it to ligate.--Prosfilaes (talk) 01:13, 6 August 2022 (UTC)
@Prosfilaes But you don't have to. It's entirely optional, which is the point. Theknightwho (talk) 17:06, 7 August 2022 (UTC)
Nothing's entirely optional; the {{ct}} would have to be used consistently throughout a work. I'm aware of only two current features that are optional in a similar way, the {{ls}} and and the curved versus straight quotes, and both are pains, because you want to maintain consistency over a whole, possible multivolume work. I don't see the value in adding a third. Again, this should be done automatically over a text, not manually on each and every occurrence of ct.--Prosfilaes (talk) 21:05, 7 August 2022 (UTC)
@Prosfilaes The reason for doing it that way is because it wasn't necessarily used consistently throughout the work, but did seem to be used in the same way between editions. I have no idea why that would be the case, but an example of where we might genuinely want to reproduce it is in a textual extract in which it's used as an intentional archaism, in the same way that blackletter is used. In a small number of contexts it carries semantic value, simply by virtue of the fact that the ligature itself is being discussed (works on printing, for the most part). Theknightwho (talk) 18:38, 9 August 2022 (UTC)
My personal opinion is that per the Unicode standard, the presence/absence of a "ct" ligature is a mere byproduct of the font chosen by the work's printer, and we do not/should not try to replicate fonts, nor should we encourage editors to do so by making templates available for them to use for this purpose. That's my opinion; I do not pretend that it is or should be anyone's opinion but my own. —Beleg Tâl (talk) 00:39, 2 August 2022 (UTC)
Wouldn't the same also apply to Long S and the various ae, oe, etc, ligatures that we do use? They're all byproducts of those 1700 typefaces. Reboot01 (talk) 01:01, 2 August 2022 (UTC)
No. Æ and Œ and their lower case equivalents œ and æ represent distinct vowels in Old English and many of the words they appear in are older than 18th Century typefaces. See the enWP article on ligatures for more. My opinion is that the stylistic ligatures should not be deliberately reproduced here (if a browser does it that's different), while those that were/are distinct letters should remain. The long-S is a separate case and we await the ability for readers to chose which to see—which is why the {{ls}} has been accepted. Beeswaxcandle (talk) 01:31, 2 August 2022 (UTC)
@Beleg Tâl I don't see how that's relevant when this doesn't involve a hard-encoded Unicode ligature. I don't see why this is any more of a problem than including any other stylistic elements from works. We have a vast number of style options already - there is no reason to exclude this one. Theknightwho (talk) 04:18, 2 August 2022 (UTC)

The template was deleted by community discussion in WS:PD. There is also a long-standing, clear statement in the Wikisource:style guide about our typography. If someone is wishing to go outside the community consensus of those two forums then that person should have the conversation first, not ignore our community's consensus.

@Pseudoskull: The reason why I protected the template was because of exactly what happened. You removed the protection and the user immediately reverted my edits and recreated the template. What is the point of WS:PD discussions and style guides if we so blithely ignore them? — billinghurst sDrewth 10:31, 2 August 2022 (UTC)

The style guide says that "Typographic ligatures such as ƈt, ff, fi, fl, and ſt should not be used in page text even if they appear in the original source (as they interfere with the searchability of the text)." This template did not insert a ƈt, it used CSS to make ct display as ƈt, and it did not interfere with the searchability of the text whatsoever. Reboot01 (talk) 10:43, 2 August 2022 (UTC)
Addendum: These discussions were years old, and the old version of the template, from what I can gather, did just insert a ƈt, this new version is nothing like that old version of the template, it just used the same title because, it does the same effect, but far better and in a modern, up to date way. Reboot01 (talk) 10:45, 2 August 2022 (UTC)
And what is the intent of the community's decisions? That it is year's old means what? That it can just be ignored? Our purpose is NOT to produce a facsimile copy, that has not been our purpose. — billinghurst sDrewth 10:50, 2 August 2022 (UTC)
@Billinghurst As has been pointed out numerous times, Typographic ligatures such as ƈt, ff, fi, fl, and ſt should not be used in page text even if they appear in the original source (as they interfere with the searchability of the text). does not apply because this template did not interfere with text searchability. It's obvious you've made no effort to even read the discussion, and you seem to have the idea that consensus is decided once and then never changes, which is never how it's worked. The original version of the template used a private use character, which is obviously not acceptable, but also completely different. I don't see you advocating for removing any other style options, either, so this is inconsistent at best and suggests a complete failure to understand why the original template was deleted.
Deleting the templates while this is clearly a contentious issue, edit warring using your bot, and then abusing your administrator privileges by banning recreation of the template is completely out of line. You have also presented zero reasoning other than pointing at discussions that happened years ago and which are not relevant due to the issues at hand. You are not behaving appropriately at all. Consensus from years ago is not law. Theknightwho (talk) 11:15, 2 August 2022 (UTC)
@Theknightwho: In a word: chill.
That you're frustrated is understandable, but you're now flinging accusations against one of our longest-standing admins; one who is probably the single person who has put the most overall work into making this project a success, and who has been around as all these policies and practices were established. That's very much uncalled for, and when they speak to these issues one should most certainly listen (disagree, sure, but definitely listen).
In this particular case, there is no question that there is an established consensus and an established practice against the reproduction of these ligatures on the site, irrespective of technical implementation. Billinghurst was implementing that consensus. Now, as you've pointed out, a lot can change on the technical side in the years since that consensus was established, and even absent changed circumstances consensus itself can change over time. It is therefore entirely appropriate to raise such issues anew so the community can assess both any changed circumstances and their position on the issue in general. But unless and until a new consensus is established the old consensus holds sway. And that is indeed how consensus has always worked on Wikimedia projects.
And on that note, let's please not get bogged down in one single detail of this. Whether or not it breaks search is just one aspect. We need to also consider things like whether we want to encourage or merely permit such practice from perspectives like what will that do to the practical aspect of trying to read and modify the wikitext (I've seen some very bad examples of pages drowned in a gazillion ligature templates), or from the perspective of the more abstract purpose of Wikisource (we do not, and cannot, perfectly replicate the original; do we really want to move the line to the other side of reproducing such minute typographic features of a given typeface and printer? How does that affect our general principle of not trying to reproduce artefacts of the printer, unless it reflects the author's intent?). If we allow or encourage the ct-ligature, what about the myriad other ligatures for which the same arguments can be made?
This isn't a straight-forward question, and we should take the time to get it right if we're to reexamine the status quo. Not least to make sure we head off future drama in this area. Xover (talk) 16:20, 2 August 2022 (UTC)
@Xover While I agree about being all that being a bit harsh on Billing and others, the way they worded their responses did make it seem like they only cared about the outdated template inserting a ƈt, or the fact that 'consensus says this so...', they didn't even acknowledge the fact this was updated to not due that, and I guess it led to some flare ups because of it.
And it's in my opinion that trying to transcribe a work, even with a large amount of wikitext for ligatures in, is no harder than transcribing any other work, especially with the modern editing tools we have these days. I feel that at least there should have been some kind of discussion before speed deleting a template, and the large amount of work that I, and other editors using this template, did in older works that used that Ligature, and definitely feel that there needs to be a wider debate and discussion on this policy.
I've seen multiple things, such as Long-s, where it can either be transcribed like it is in the text, or just use s, and I see no reason why this has to be any different from that. Reboot01 (talk) 17:46, 2 August 2022 (UTC)
I see long s as a different case, as it used to be used as a separate character, although representing the same sound as the short s, and its usage was connected with some rules. On the other hand, I understand the ƈt ligarure to be just a kind of typeface not distinguished from common ct characters. --Jan Kameníček (talk) 18:17, 2 August 2022 (UTC)
Then, with it being just part of a typeface, couldn't we say that using different fonts, like blackletter, or using something like template:old style for some numbers, is just a decision of the printer and shouldn't be included since they're just typographical? Reboot01 (talk) 18:51, 2 August 2022 (UTC)
Precisely. The logic behind that argument in the first place was to say that it was fine not to use the hard-encoded Unicode ligature characters. It does not follow that any attempt to stylise ligatures should be disallowed. PseudoSkull raised an excellent question that mobody has yet been able to answer: what is the harm that is done by this template? I'm also unconvinced by the attempt to argue long S is a separate character - it carries no semantic value, which is precisely why we all view it as optional (i.e. stylistic). The reason it was never disallowed is because it didn't disrupt text searchability. If it did, I have no doubt it would have been treated in the same way.
And yes, @Xover, @Reboot01 is entirely right about why I got so annoyed about this. @Billinghurst has made absolutely no effort whatsoever to be cooperative, has all but ignored this discussion, and has by any measure abused their position as an administrator, regardless of whether anyone agrees with their view on the matter itself. It's extremely clear that they are not interested in engaging in this topic in a constructive way, being perfectly happy to ignore this discussion, but jumping into action immediately if they felt they weren't getting their way. That is not a sign of good faith, and is pretty insulting when they've just undone something that took effort to implement in the first place (a couple of hundred instances). Theknightwho (talk) 01:22, 3 August 2022 (UTC)
I did not write any argument for or against, at the moment I am still just reading and considering arguments of others. I only reacted to Reboot01’s argument explaining the difference between long s and ƈt, nothing more. As for black-letters: that is much different too, these are often used to make e.g. some titles more prominent/visible and I am far from being sure whether it was printer’s or author’s decision. However, you are right that the old-style template for numbers looks like pretty the same case, so we should decide whether we want to add another similar template: I am still not sure, Xover is afraid of flooding our texts with them.
I would also like to ask Theknightwho to stop offending others as they are the only one to be blamed for breaking an established rule before making an attempt to establish new consensus, which resulted into the current drama. If you re-read the discussion at your talk page, you will notice it was explained there to you politely and you started with your offenses there already, making it such a drama. Let’s leave this to history now and let’s concentrate on factual arguments only. --Jan Kameníček (talk) 06:35, 3 August 2022 (UTC)
Just to be clear: I've taken no particular position on this issue. I'm saying the question is multi-faceted so we can't just argue one aspect of it, and the principles underlying the current (status quo) consensus have implications that go beyond ct-ligatures and which also need to be considered. It is to me also important that if we are to change established practice in this area, we do it properly and document it in a way that removes the potential for future drama as much as possible.
To that end, my suggestion would be to take a step back, and start with a neutral and dispassionate description of the issue. Starting from the assumption that at least some contributors want to reproduce ct-ligatures: what are their motivations (why ct-ligatures, rather than st, ffi, or ny number of others), what are the technical options and how do they differ from when this issue was last discussed, what are the potential downsides, and what other issues will be affected by such a change (e.g. those other ligatures). I would also like to eventually arrive at some kind of actual policy page describing this and related issues, for which purpose some thought of how to formulate either the status quo or a hypothetical uti possidetis would be beneficial. Xover (talk) 07:07, 3 August 2022 (UTC)
Long s is a special case because it appears outside of printed works. Authors such as John Milton and Jane Austen used the long s in their manuscripts. The rest are ligatures to beautify the text and can be added automatically by some ebook reader software. Honestly, I think that such ligatures bog down the proofreading and validation of works without adding anything. Languageseeker (talk) 00:36, 4 August 2022 (UTC)
@PseudoSkull: Just flagging this to your attention, as it's clear that billinghurst neither understands the issue nor cares about acting cooperatively with other editors. Theknightwho (talk) 11:19, 2 August 2022 (UTC)
Deleting was in accordance with both the current practice and the rule expressed in Wikisource:Style_guide/Orthography#Ligatures. Although the given reason might not apply anymore, the rule is valid until it is cancelled by new consensus. I understand this discussion as an attempt to reach such consensus, so we will see what comes out of it. The template should definitely not be recreated before reaching an agreement. --Jan Kameníček (talk) 12:02, 2 August 2022 (UTC)
@Theknightwho: You are speaking out of your hat. I well and truly understand the issue. I definitely do care and have worked with cooperatively with people here for 15 years. That I don't agree with your argument and that I follow the consensus of this community should not be condemnation, they should have you listening. There is ZERO requirement to produce facsimile copies of works and that has been the opinion of this community for years. We have tried to not overburden our works with templates,; to keep our proofreading as simple as possible. What does this community or the library gain from a reproduction of a CT ligature-look. Nothing. Read the archives of this page and you will see this argument about facsimile reproduction and the community's higher interest in the written and reproduced word, not a publisher's artefact. — billinghurst sDrewth 12:44, 5 August 2022 (UTC)
Then let's do away with everything stylistic then. Why target this and only this? Theknightwho (talk) 12:50, 5 August 2022 (UTC)
If you wish to have a conversation then please produce a logical argument about what you are proposing, or the changes that you are wishing to see undertaken. We do try to represent a work without slavish facsimile reproduction. We are not wishing to have no formatting, many styles are clearly pertinent and add definition, clarity or readibility to works. We made allowance for "long s" though some of would still like it gone, and that template is required to display in the main namespace as a standard "s" without imposition of any stylistic aspect. "ct" is only a visual artefact without any benefit and was not even continued as a style by publishers. This community determined that we wished to not progress with the template and the published look. It is definitely unfortunate that you spent time doing that editing, however, if you followed the style, then you wouldn't have spent that time, so please do not blame us. We have deleted completed works so we all understand about effort spent ending up being no longer valid. I have had to delete works that I have spent hours upon. C'est la vie. — billinghurst sDrewth 13:16, 5 August 2022 (UTC)
I mean...if anything, this new discussion shows that 'this community' is not all in agreement on this topic, and I still feel that there could be more discussion and voting on this, as @Xover and a few others have said we should. Just because the responses have slowed doesn't mean it's just case closed, it's staying deleted. Reboot01 (talk) 14:22, 5 August 2022 (UTC)
And on top of the whole 'we don't make facsimile's of works' arguments, that makes a page like this, with it's formatting make the tail, completely unnecessary and out of scope by those arguments, among so many other works that go beyond it. Page:Lewis Carroll - Alice's Adventures in Wonderland.djvu/57. Reboot01 (talk) 14:29, 5 August 2022 (UTC)
@Billinghurst I have already explained what the "changes" I have proposed are. Why are you against this particular stylistic element and not others? The onus is on you to explain why this one is not justified, given the fact that there are so many others that we do allow, because at this point it feels like a mantra rather than something with any real logic behind it. I see no proposals to delete any other templates which could impede proofreading, of which there are many, either.
And yes - the community is clearly not in agreement about this. "The community" determined that we should not be using private use characters or templates which impede searchability, which do not apply here, and the fact that you keep making that point despite several other people pointing out that we aren't even talking about the same thing is starting to become absurd. Either you don't understand the issue at hand, or you do understand it but choose to ignore the fact that people are explaining why this is different. Neither looks good. At this point, it's not even about the fact we disagree - it's the fact you keep stonewalling the arguments made against your view. Theknightwho (talk) 16:47, 5 August 2022 (UTC)
No, in a community, the onus is never on one person to explain something. You didn't bother responding to my post below. I think Billinghurst might have been a little quick to delete, but you were quick to recreate and edit war, so let's go beyond that. Whether certain characters are ligatures are part of a font style, and we don't do font styles. Blackletter is more like italics or bold, and Alice in Wonderland's tail ... is one of those idiosyncratic things. If you look at the Penguin Alice, it looks like every other book in the series, and reproduces the tail.--Prosfilaes (talk) 00:56, 6 August 2022 (UTC)
The "ct" is a publishing artefact used in a very small period of publishing time, and was only ever a publishing artefact, it is not a real set of characters and the publishing industry stopped doing it. Other styles that we do have been specifically inserted into works as a clear means of styling. Template:ct as you had it displayed in main ns, template:long _s does not. You are only presenting half of a story and solely because you like the look of the "ct" to replicate a publisher. As you have it, it still impedes search and your statement that it does not is just wrong, and you clearly don't know local search as the span exists in the reproduction and always will, it still makes proofreading more complex and it does nothing to build a good library.

@Reboot01: With regard to your !vote. How many times should we have to re-prosecute a case that has been addressed in multiple ways and in multiple means about facsimile reproduction? Just because you have arrived with you really good idea about which we have already had a discussion many years ago. Are we going to back and discuss replicating fonts as published> Do you want to go back and insert every hyphen we have removed from a work? We have had these conversations, and the results of these conversations come through in Wikisource:Style guide and related pages. So always the conversation should be if you want a change to the style guide is discuss first, not ignore the guide and impose your own styles that we have determined to not do. — billinghurst sDrewth 02:31, 6 August 2022 (UTC)

Except you're ignoring the multitude of style options that get freely applied to works in the wikitext, such as the one already pointed out to you. Plus it does not disrupt search at all, because the span does not show up in search results. I had already tested this. As you can see here, search results show the final display form if it finds a match there. It doesn't only look in the raw wikitext. Please explain what the actual problem is, because I'm really not seeing one. Theknightwho (talk) 17:03, 7 August 2022 (UTC)
We are not going to reproduce fi ligatures because they're universal and practically mandatory. The ligated ct and st are likewise mandatory in those font styles, and not at all in more modern font styles. In scripts like Latin and Greek, characters like the s in pre-1800 usage, or sigma in modern Greek usage, that have mandatory positional variation are encoded separately instead of requiring complex shaping. I'm not a fan of using the long-s, but the distinction is a plain text distinction.
The letters æ and œ are more complex. Both are full letters in some languages; æ is used in Old English and Danish, and œ is used in French and various Cameroon languages. (For example wikt:coeliaque is considered a misspelling in French.) Likewise, æ and œ are often but not always converted to e in American English, instead ae or oe which is more common in British English. Even in just English, we can't blindly convert it, which makes it a spelling conversion, which we don't do.--Prosfilaes (talk) 03:05, 4 August 2022 (UTC)
Without wishing to get involved too any major extent in such a fractious topic, it seems that the easy option has been overlooked: add the relevant ct-ligature-enabling CSS in the index CSS for the relevant work. No templates at all are needed to gunk up the editing interface. Regardless of whether ct-ligatures are good or bad, having to replace every "ct" pair in Wikicode is, I think self-evidently, a complete non-starter in terms of workflow or maintenance and has been rendered completely unnecessary by the software anyway. Inductiveload—talk/contribs 22:12, 10 August 2022 (UTC)

Wikisource:General disclaimer addendum proposal

I propose that, in the licensing section, we include a line about trademark law. Something to the effect of this (feel free to suggest better wording):

While works hosted here are freely licensed, certain names used in works, such as titles of books, names of fictional characters, or product names, may be trademarked in some jurisdictions. This does not impact the copyright status of the work. Care should be taken to ensure that certain usages of a work do not violate local trademark law.

Rationale: We have several project disclaimers for encyclopedias which have been an ongoing deletion discussion here at WS (which has recently been closed). Those project disclaimers specifically mention the trademarks of those encyclopedia names. And in that discussion I noted that our project pages, most notably our general disclaimer, do not mention trademark law at all, and probably should, since this is a more universal issue that doesn't just apply to encyclopedias. PseudoSkull (talk) 22:20, 10 August 2022 (UTC)

Copyright of the Bin Laden Files

Are the Bin Laden Files subject to copyright?—unsigned comment by Blahhmosh (talk) 7 August 2022.

You have to write to the Al-Queda copyright department to find out. — ineuw (talk) 04:54, 7 August 2022 (UTC)

Be careful before ever trying to contact Al-Qaeda while I see w:Al-Qaeda with an external link about ""Bin Laden documents at a glance". CBS News. Archived from the original on May 11, 2012."--Jusjih (talk) 13:09, 7 August 2022 (UTC)

The CIA said they redacted all the material they knew to be copyrighted, but looking through the list of items there's a ton of stuff from media outlets and other stuff that at first glance seems like it would be under copyright. I suspect a large proportion of the material (if not all) would be speedy deleted for that reason if uploaded to Commons. --Arbitan (talk) 04:07, 12 August 2022 (UTC)

Copyright of the Panama Papers

Are the Panama Papers subjected to copyright? Blahhmosh (talk) 19:17, 11 August 2022 (UTC)

I am afraid that most of these leaked materials (if not all) are documents of private people or companies and thus are not in public domain. Besides that, some of the leaked materials describes also legal financial operations of private persons and companies, and in such cases there might be problems with w:Privacy laws of the United States. --Jan Kameníček (talk) 07:15, 12 August 2022 (UTC)

How do I split a bilingual text between two Wikisources, so that it's visible to both?

I saw this done with Fitzgerald's Rubaiyat, where the Persian pages are housed on WS-fa, and the facing English translations on WS-en. In the indices, the pages in the other language are colored grey, but are integrated together when you read the book. The same should be done with Whinfield's Rubaiyat, which is all housed on WS-en but with most of the Persian pages marked 'problematic' blue and some without even an attempt at digitization.

Recently I came across Bose's Essential Religion on WS-bn, which is in English for the first half and then in Bengali. I'd like to migrate the English pages here, but keep them visible on WS-bn, and at the same time make the Bengali pages visible here. (Please ping.) Kwamikagami (talk) 20:04, 6 August 2022 (UTC)

@Kwamikagami: For interwiki transclusions you can use the template {{iwpage}}. An example can be seen at Page:The seven great hymns of the mediaeval church - 1902.djvu/86. However, it works well only if the other language wikisource page does not include any local templates or only templates compatible with en.ws templates. --Jan Kameníček (talk) 10:54, 7 August 2022 (UTC)
I noticed that if I download a PDF of your listed example (from https://en.wikisource.org/wiki/The_seven_great_hymns_of_the_mediaeval_church), the resulting PDF doesn't have the transcluded pages. Do you know if this a bug with iwpage, and if so, if it is likely to be fixed? Persimmon and Hazelnut (talk) 22:01, 8 August 2022 (UTC)
@Persimmon and Hazelnut: The reason is that the non-English pages are not transcluded into the main namespace, see e. g. The seven great hymns of the mediaeval church/Stabat Mater and Mater Speciosa/Stabat Mater, Lindsay where there are only odd pages with English text and even pages in Latin are omitted. --Jan Kameníček (talk) 22:30, 8 August 2022 (UTC)
I wanted to verify that the whole Rubaiyat would download, but I can't find it! We list 5 editions of Fitzgerald's translation, but all of them are monolingual.
BTW, so I don't lose track of this too, Whinfield's English pages are here, and the Persian pages are here. Kwamikagami (talk) 21:55, 15 August 2022 (UTC)

Invitation to join the fifth Wikisource Triage meeting (18th August 2022)

Hello fellow Wikisource enthusiasts!

We are the hosting the fifth Wikisource Triage meeting on 18th August 2022 at 4 PM UTC / 9:30 PM IST (check your local time) according to the wudele poll and also based on the previous feedback to have a Europe-Americas friendly meeting.

As always, you don't have to be a developer to participate in these meetings but the focus of these meetings is to improve the Wikisource infrastructure.

If you are interested in joining the meeting, kindly leave a message on sgill@wikimedia.org and we will add you to the calendar invite.

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

Regards

Sam Wilson (WMF) and Satdeep Gill (WMF)

Sent using MediaWiki message delivery (talk) 15:05, 15 August 2022 (UTC)

Tech News: 2022-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 Persian (Farsi) Wikipedia community decided to block IP editing from October 2021 to April 2022. The Wikimedia Foundation's Product Analytics team tracked the impact of this change. An impact report is now available.

Changes later this week

  • The new version of MediaWiki will be on test wikis and MediaWiki.org from 16 August. It will be on non-Wikipedia wikis and some Wikipedias from 17 August. It will be on all wikis from 18 August (calendar).
  • Some wikis will be in read-only for a few minutes because of a switch of their main database. It will be performed on 16 August at 07:00 UTC (targeted wikis) and on 18 August at 7:00 UTC (targeted wikis).
  • The Realtime Preview will be available as a Beta Feature on wikis in Group 1. This feature was built in order to fulfill one of the Community Wishlist Survey proposals.

Future changes

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

21:08, 15 August 2022 (UTC)

Transclusion issue in Index:Canadian Alpine Journal I, 1.djvu

When I click the red link to create the transclusion page for Receipts and Expenditures, Yoho Camp it returns a message The page isn't redirecting properly. I've created a number of transclusion pages for this Journal previously without issue, but for some reason I cannot create this page. Could someone take a look for me please? Thanks Sp1nd01 (talk) 21:29, 17 August 2022 (UTC)

@Sp1nd01 it works for me. Mpaa (talk) 21:39, 17 August 2022 (UTC)
@Mpaa, Thanks for checking, It still doesn't work for me, but I just noticed that there are also two red links below, Constitution and List of Members, and when I click those it will allow me to create the pages. It seems strange that it won't allow me to create just that one page. Would you be able to create a basic page for me and I will add the details? Thanks Sp1nd01 (talk) 21:50, 17 August 2022 (UTC)
@Sp1nd01 done Mpaa (talk) 22:22, 17 August 2022 (UTC)
@Mpaa, Thank you! Sp1nd01 (talk) 22:42, 17 August 2022 (UTC)

OCR button not working?

Tracked in PhabricatorTask T315554

The "Transcribe text" button in the proofreading toolbar doesn't seem to work for me; I can press it, but it doesn't change the page text. I'm pretty sure it was working fine a month ago, so this seems like a recent development. Are others experiencing this same problem? Fortunately, https://ocr.wmcloud.org itself still works, but it is slightly more inconvenient to use. Does anyone know what's going on? Shells-shells (talk) 19:05, 3 August 2022 (UTC)

@Shells-shells Hey, would it be possible for you to identify/give an example of a page where this is occuring ? Might be worth filing a phabricator bug as well if you can get it to reliably occur. Sohom Datta (talk) 14:06, 17 August 2022 (UTC)
@Sohom data I just now figured out the issue: the OCR button doesn't seem to work when syntax highlighting is switched on. Shells-shells (talk) 17:30, 17 August 2022 (UTC)
@Shells-shells That does sound like a bug that we would want to fix. I'll file a ticket on phabricator and take a look later today :) Sohom Datta (talk) 09:21, 18 August 2022 (UTC)

A possible additional annotated work: "Secret History of the French Court under Richelieu and Mazarin"

Please discuss here: Talk:Secret_History_of_the_French_Court_under_Richelieu_and_Mazarin#Annotated_version?. This is just to serve as a pointer and wider invitation to discussion. JesseW (talk) 23:10, 19 August 2022 (UTC)

The Hound of the Baskervilles

Can the The Hound of the Baskervilles be moved to [[The Hound of the Baskervilles (Newnes, 1902) to make way for a disambiguation page? Languageseeker (talk) 11:49, 20 August 2022 (UTC)

@Languageseeker done. Mpaa (talk) 17:14, 20 August 2022 (UTC)

"New texts" feed is insufficient

I began contributing to Wikisource not long ago, so I'm writing this here to gather more opinions and hopefully draw more attention to this before creating any actual hard proposals. But it seems to me that the "new texts" feed on the main page is incomplete and ambiguous - its documentation says it is for "completed" or "proofread at least once, if not fully validated" texts (depending where you look - not good), yet the talks on its discussion page about what that would actually mean (fully proofread? fully validated? only relevant portions validated?) have gone stale with no new recommendations implemented. It seems to me that the "new texts" header is fundamentally ambiguous (flawed, even) - even if we agree on a hard definition, it won't be made clear to contributors as no step of the add - proofread - validate - fully transclude ("complete") process is named like that internally. We use similar words to mean different things to contributors or readers, which is needlessly confusing.

Wouldn't it be better to have a few separate feeds for each step of the process? One for recently completed texts for readers to browse, another for recently added transcriptioons for editors looking for a project, perhaps an intermediary one for works just finished proofreading but not yet validated and transcluded (so not "completed", by the definition used in the Index pages)? Could the process of updating some of these feeds - the least visible to readers, at least - be made automatic? Please give your thoughts. I'll also post on the talk page linked above, hopefully this draws some new comments to the discussion. YuriNikolai (talk) 16:04, 19 August 2022 (UTC)

No, having a feed for each step of the process would mean listing works not ready for the public on the one hand, and duplicating or triplicating listings as works go through additional steps. A work may go through the complete process in a few days, or over several years. We typically use the listing so that each completed text is listed, and each work is completed only once, so it is listed on the main page only once. It may be refined in the Validation process, or tidied in other ways, but we do NOT want to list incomplete works, unproofread works, or untranscribed works on the main page. We certainly do not want to post untranscluded works where there is no Mainspace page.
And no, it can't really be automated because there is no mechanism in place that would allow that. Some works have a scan of their own, but even when the scan is fully validated, the contents may not be transcluded, or the intermal linkages between sections may not be set up correctly. We cannot check that automatically. Some completed works are part of a scan, and we have no way of spotting those automatically. Some works are Wikisource translations by members, and some are transcriptions of text from films. We have no way to spot those automatically. --EncycloPetey (talk) 19:34, 19 August 2022 (UTC)
@EncycloPetey:I think an index of new works not ready for the public would be of great value to contributors. I may not have expressed myself well, but these editor-oriented filters wouldn't need to be (or shouldn't be) on the main page, and could easily have every single work as it gets added without filtering that, as you said, cannot be automated - no transclusion needed when a feed is just looking for new scans, for example. Perhaps a user page template could house that list, like so many other lists people add to their pages to speed up navigation to 'get to work'? YuriNikolai (talk) 19:48, 19 August 2022 (UTC)
How would that list be monitored? As I say, some works go from Index to completely validated in a few days. Others linger for years. We have thousands of works in various stages of processing. Maintaining a List of those works is not feasible. The Monthly Challenge is the means we've adopted for creating and completing significant works. --EncycloPetey (talk) 00:22, 20 August 2022 (UTC)
  • I think it would be good for their to be optional lists on which editors can place works which need specific work, such as additional proofreading, validation, etc. Where to put these lists is a difficult question, however, as they have been tried before to only limited success. TE(æ)A,ea. (talk) 00:44, 20 August 2022 (UTC)
How about a template with the newest djvu files for adding to our talk pages? That would be unobtrusive as no one would see them without wanting to, and would not require any more oversight than new uploads already do (and could actually make checking them quicker). YuriNikolai (talk) 23:41, 20 August 2022 (UTC)
An obvious place to put these sorts of lists would be on the WikiProject pages: Wikisource:WikiProject Proofreading and Wikisource:WikiProject Validate. They're both currently inactive, but if editors are looking for a list of works to work on, that's a central place for them to look and potentially coordinate with each other.
There are also Category pages: Category:Proofread texts and Category:Index not transcluded. There is also a Category:Not proofread, but that lists mostly individual Page: pages.
But you could use advanced search to find works in one of those categories. In the search bar in the upper right corner, click on the magnifying glass. That opens a "Search results" page. Put your search term in the box, and open the "Advanced search" tab. In "Pages in these categories" put "Proofread texts" (for example). Then you'll get all the works categorized as needing validation that have your search term. That could be a way of finding a validation project on an interesting subject. --Arbitan (talk) 12:41, 21 August 2022 (UTC)

File:Laws of the Earliest English Kings.djvu

Hello Wikisource,

this 1922 UK publication is in the public domain in the USA, but not in the UK (the author died in 1973). It's a book by the Cambridge Unviversity Press, UK; that it was simultaneously published in the USA does not make it a US publication as far as Wikimedia Commons is concerned.

This file is in use here at Index:Laws of the Earliest English Kings.djvu (created by User:Rho9998), though apparently no pages were created. If you want to keep the file, please transfer it to Wikisource, as Commons will delete it. Thank you. --Rosenzweig (talk) 19:00, 20 August 2022 (UTC)

@Rosenzweig: Thank you for the notice. Very (very!) much appreciated!
But regarding the specific file, I think there must be some confusion: that it was simultaneously published in the US means precisely that it is a US publication due to the rules of the Berne convention, and therefore a US work for Commons' policy purposes (as the policy was designed to match Berne here; cf. COM:L, second bullet of the lede, that are in the public domain in at least the United States and in the source country of the work [my emphasis; the term was picked to match Berne for this very reason].). The short version is that Berne specifies that when works are simultaneously published in multiple countries, the source country is the country with the shortest effective term (which is going to be the US for works like this that were published before the pub.+95 term but that happen to have long-living authors in pma.+70 countries). See e.g. COM:VP/C#Source country vs simultaneous publication for the last time this came up.
@ShakespeareFan00: You may want to be aware of this issue. Xover (talk) 09:55, 21 August 2022 (UTC)
@Xover: Alright, that convinced me. I will change the result of the deletion request to keep and retain the file. Regards --Rosenzweig (talk) 11:45, 21 August 2022 (UTC)
@Rosenzweig: Thank you! And I think I'm on record various places that this really should be clarified in policy and/or guidance pages; because this state of affairs is really obscure and non-intuitive (you're not the first Wikimedian who is well versed in copyright issues but still unaware of this particular quirk, not by a long shot). Xover (talk) 12:06, 21 August 2022 (UTC)

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

  • Two problems with Kartographer maps have been fixed. Maps are no longer shown as empty when a geoline was created via VisualEditor. Geolines consisting of points with QIDs (e.g., subway lines) are no longer shown with pushpins. [5][6]

Changes later this week

  • The new version of MediaWiki will be on test wikis and MediaWiki.org from 23 August. It will be on non-Wikipedia wikis and some Wikipedias from 24 August. It will be on all wikis from 25 August (calendar).
  • Some wikis will be in read-only for a few minutes because of a switch of their main database. It will be performed on 25 August at 7:00 UTC (targeted wikis).
  • The colours of links and visited links will change. This is to make the difference between links and other text more clear. [7]

Future changes

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

00:12, 23 August 2022 (UTC)

Voting has begun in the Board of Trustees elections!

Hi all!

The community voting period in the Wikimedia Foundation Board of Trustees elections is now open.

Before you go on to vote, you can:

Votes are accepted until September 6, 2022 at 23:59 UTC
 Vote now on the SecurePoll page.

Kind regards,
BPipal (WMF) (talk) 19:09, 23 August 2022 (UTC)

Downloading The ancient Irish church

A reader was complaining about downloading the book at Talk:The ancient Irish church and when I tried it myself I got into the same problems as described. Could somebody who knows more on the subject reply to the reader, please? -- Jan Kameníček (talk) 15:46, 24 August 2022 (UTC)

@Jan.Kamenicek: Fixed. When using {{AuxTOC}}, either all links must be inside the auxtoc or you must wrap the lot of 'em in {{Export TOC}}. Not very intuitive, but there's actually some logic behind it. Xover (talk) 16:54, 24 August 2022 (UTC)
I see. It is really very un-intuitive and if there is any logic behind it, it must be well hidden :-) --Jan Kameníček (talk) 17:02, 24 August 2022 (UTC)
It is "makes sense to software developers"-type logic. The exporter uses links on the root page to figure out what to export. Usually it grabs all links. But sometimes that's wrong, so it supports a special tag (well, a special CSS class name) that can be used to indicate "these are the pages that should be exported", which is what {{AuxTOC}} uses. When that's present the exporter assumes that a human has told it what to export, and so it exports that and only that. That works fine in most cases, because in most cases where you use {{AuxTOC}} it's because there is no toc at all in the work. But on The ancient Irish church there is a toc, it's just missing an entry. When that entry is added with AuxTOC the exporter does what it's been told to do, which in this case is the wrong thing. So, to work around this problem, we have to manually give the exporter the right instructions: wrap the whole toc in {{Export TOC}}.
See? There is a method to the madness, albeit one that only makes sense to mad people software developers. :-) Xover (talk) 17:14, 24 August 2022 (UTC)
i take it, you may have applied to [9] , developer whisperer. --Slowking4 亞 Farmbrough's revenge 23:35, 24 August 2022 (UTC)

A default layout related inquiry

Is there a bot that could insert the {{default layout}} template set to [Layout 4], in all the main namespace pages I created? If this is beyond the scope of our bots, (permissions etc,) how can I get it done? Comments are most appreciated. — ineuw (talk) 03:08, 15 August 2022 (UTC)

Perhaps I should have asked if I am allowed to do this. My page namespace layout width matches Layout 4, and without it, I don't know how to bring it to the attention of the random reader. I will be able to construct the SQL statement, but it would need someone with execute rights to implement it. Suggestions are welcome. — ineuw (talk) 00:51, 21 August 2022 (UTC)
@Ineuw: Absent actual opposition you're free to set whatever default layout you think best serves the texts you work on (just make sure you base it on what best serves the reader of that specific work, and not your own preferences for viewing pages), and that includes adding it retroactively like any other little tweak or improvement you subsequently think of. And since it's something you're allowed to do manually it is also something you can request that a bot operator do on your behalf.
That being said, I'm not sure we can find any reasonable definition of "all the main namespace pages [you] created" that we could easily use as the set of pages to work on. I haven't really looked at what's possible (i.e. what pywikibot supports out of the box), but this selection doesn't jump out at me as something that would be supported without writing a significant amount of custom code. I'll try to have a look when time allows (I could be wrong), but in the mean time: can you define the pages to work on any other way? If you can find a query page on-wiki, or a query tool on Toolforge or similar, that gives you the relevant list then we can always just tell the bot to work on that static list of pages (vs. dynamically querying for it itself). NB! Make sure the list doesn't contain "false positives": things that are obviously irrelevant to a human may be completely invisible to a bot. Xover (talk) 10:55, 21 August 2022 (UTC)
I'm not quite sure I follow what you're trying to do here... in particular, the phrase "bring it to the attention of the random reader" concerns me, given that a number of those readers will be exporting as ePub (or finding an ePub elsewhere, etc) and not reading it on this site. Are you formatting works assuming a specific page width? — Dcsohl (talk)
(contribs) 14:32, 23 August 2022 (UTC)
I am not formatting anything. This is a display setting. — ineuw (talk) 00:32, 25 August 2022 (UTC)
@Xover: Thanks for the reminders. My contributions' list quickly extracted my main namespace contributions (only those that were created). Is there a way to extract it from contributions as a text file? or see the SQL construct? And then who can I ask to implement this? Years ago I was able to do this on Toolforge but the data tables' designs have been upgraded several time since. — ineuw (talk) 04:35, 25 August 2022 (UTC)
I understand "Layout 4" is a display setting -- your wording in your initial inquiry set off some internal alarm bells and I thought that maybe you wanted Layout 4 because your pages had somehow been formatted assuming that particular page width. As long as they still look good with other widths, or in epub readers, it's all good. — Dcsohl (talk)
(contribs) 14:15, 25 August 2022 (UTC)
@Dcsohl: The "Layout 4" was kindly added at my request years ago, because I found the screen width pages of the default "Layout 1" were impossible to read. Layout 2 is also narrow, but appears with a Garamond like font. My original intent was to place a note to the reader to select "Layout 4" of the Display Options, because that is how the editor intended his work to appear at first, in a format approximating a printed page. My personal bias towards printing and paper, prevented me from considering downloading any works. Also, at that time, formatting for printing was problematic, so I ignored it. Since that time I also realized that screen displays are also a user's personal choice, and others never see my work as I see it. — ineuw (talk) 18:09, 25 August 2022 (UTC)
@Ineuw I well appreciate the sentiment, especially as someone who prefers reading on e-readers and can't imagine reading an e-book some other way! You have more than satisfied my concerns, and I thank you for that! — Dcsohl (talk)
(contribs) 17:09, 26 August 2022 (UTC)

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

Problems

  • In recent months, there have been inaccurate numbers shown for various Special:Statistics at Commons, Wikidata, and English Wikipedia. This has now been fixed. [10]

Changes later this week

  • The new version of MediaWiki will be on test wikis and MediaWiki.org from 30 August. It will be on non-Wikipedia wikis and some Wikipedias from 31 August. It will be on all wikis from 1 September (calendar).
  • Some wikis will be in read-only for a few minutes because of a switch of their main database. It will be performed on 30 August at 07:00 UTC (targeted wikis) and on 1 September at 7:00 UTC (targeted wikis).

Future changes

  • The Wikimedia Foundation wants to improve how Wikimedia communities report harmful incidents by building the Private Incident Reporting System (PIRS) to make it easy and safe for users to make reports. You can leave comments on the talk page, by answering the questions provided. If you have ever faced a harmful situation that you wanted to report/reported, join a PIRS interview to share your experience. To sign up please email Madalina Ana.

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

23:05, 29 August 2022 (UTC)

Nihongi: Chronicles of Japan from the Earliest Times to A.D. 697

Move to Nihongi: short title by which the work is generally known, disambiguation not being required as this is the only public domain English translation. TE(æ)A,ea. (talk) 02:04, 20 August 2022 (UTC)

Not done The contributor put it where it is and back in 2014, there is no requirement to move it. I will create the redirect to the work — billinghurst sDrewth 09:00, 18 September 2022 (UTC)
If there were to be a naming convention on this (I wish people were on board with actually having this), I think having subtitles in nonfiction books is fine (as long as you don't include sub-subtitles and so on), because nonfiction books are often referred to (and distinguished) by their subtitles. But I think in fiction books the subtitles (such as silly things like "The Fifth Wheel: A Novel", "..., or, The Lover's Quarrel" or "...: The Story of a ... and His ...") are excessive and should never be included in the titling, except under exceptional circumstances. PseudoSkull (talk) 14:36, 22 September 2022 (UTC)
billinghurst, PseudoSkull: The subtitle for this work was added by the translator; the original had no subtitle. It is not as if this work is frequently referred to with the subtitle, either, as (since this is the only English translation) it is simply the Nihongi. There is no reason to have the work at the longer title, and it is much easier to use a work with a shorter title. TE(æ)A,ea. (talk) 14:59, 22 September 2022 (UTC)
We are displaying the translation, so it is suitable to display it if that is the choice of the original contributor. A redirect exists, I don't see the problem. — billinghurst sDrewth 12:59, 25 September 2022 (UTC)
  • Well, I do, and I’m the one working on it. I shouldn’t have to write a thesis to defend this move; if I knew that it would be this useless, I would have just moved the pages myself, which I intend to do later. TE(æ)A,ea. (talk) 22:11, 26 September 2022 (UTC)
Retrieved from "https://en.wikisource.org/w/index.php?title=Wikisource:Scriptorium/Archives/2022-08&oldid=12703470"