Wikisource:Scriptorium/Archives/2023-11

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.

Trying to help myself by asking for yes or no answers.

  1. I am looking for the bot with which I can create the page: namespace pages. I looked at the list of users': bots, but I can't tell. Are there any general maintenance bots? I cannot do this manually, and my mouse+keyboard based macros no longer work in browsers. Is there such a script? Yes or No?
  2. When Tesseract finishes, would it be possible to terminate the cursor position in the top row of the 'text area'? - Can I, manage this from my .js file? Yes or No?
  3. Would it be also possible that at the termination of same process, to reset the image to the 'original size'? Yes or No? — ineuw (talk) 00:56, 5 November 2023 (UTC)

Tech News: 2023-45

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

Recent changes

  • In the Vector 2022 skin, the default font-size of a number of navigational elements (tagline, tools menu, navigational links, and more) has been increased slightly to match the font size used in page content. [1]

Problems

  • Last week, there was a problem displaying some recent edits on a few wikis, for 1-6 hours. The edits were saved but not immediately shown. This was due to a database problem. [2]

Changes later this week

  • The new version of MediaWiki will be on test wikis and MediaWiki.org from 7 November. It will be on non-Wikipedia wikis and some Wikipedias from 8 November. It will be on all wikis from 9 November (calendar).
  • The Growth team will reassign newcomers from former mentors to the currently active mentors. They have also changed the notification language to be more user-friendly. [3][4]

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

MediaWiki message delivery 21:05, 6 November 2023 (UTC)

Automated creation of TOC from list

I'm using a list in Excel to produce a TOC, and also to fill out header templates for each chapter of a book in the main namespace. Excel is not the very best tool for the job. In the example of a TOC, it would be useful to create a Lua module that loops through a list to produce a TOC. Then others could utilize the template with their own lists. That raises a few questions: What namespace would the list be stored in? Is anyone using a similar programmic method? Am I reinventing the wheel? Heyzeuss (talk) 15:07, 12 November 2023 (UTC)

To answer your second question, I have done the same thing with the LibreOffice equivalent of Excel before, yes: it allowed me to do some simple addition and replacement easily. —Justin (koavf)❤T☮C☺M☯ 20:00, 12 November 2023 (UTC)
Unfortunately, technical limitations like this are why transcription is a tough thing. In an ideal world, proofreading templates, etc. could be more dynamic to the point where autogeneration of something like a TOC would be easy and native to our system. These are exactly the types of things I've been working tirelessly to find solutions to for my own projects, hoping that one day they can actually be integrated into our frontend, rather than having to do software workarounds through Pywikibot for basically every kind of useful edit.
@Heyzeuss: I don't have code I can give you right at the moment, but if you're developing software for this (or even just proofreading generally), I would personally recommend to do the headers first, and then have your code dynamically generate a TOC based on the headers you've already created. That way, you can deal with the nuances of the TOC as they come up, with the headers already being perfect as is. So you only have to treat one page for your chapters, rather than thirty.
I could produce something if you need (given a little time though). I have messed with Excel spreadsheets in Python for quite a lot of projects professionally, albeit never for a wiki. But let's see if anyone else has a solution before I jump in too readily. PseudoSkull (talk) 20:56, 12 November 2023 (UTC)
After looking around, I found that there's a data namespace in Commons for .tab files in JSON format. Some templates that draw on JSON lists would be ideal for making TOCs and other things that draw on lists of chapters. Heyzeuss (talk) 21:20, 12 November 2023 (UTC)
That's not a bad idea, actually. Being able to construct tables of content from some markdown shorthand would be really helpful. We may want to propose this at the next community wishlist... —Justin (koavf)❤T☮C☺M☯ 01:27, 15 November 2023 (UTC)
I'm actually of the opinion that almost everything in Wikisource should be done in a markdown shorthand: that is, shorter than what MediaWiki can natively provide. Considering the absolute ocean of works that in theory need to be transcribed but are so far untouched, with each individual work taking quite a magnanimous effort in and of itself, that is what has separated Wikisource from the public eye up to this point. If you consider the vast amount of tasks that need to be done, minimizing clicking and typing in the transcription process in every possible place is necessary for the best outcomes. Centralize every bit of data, only enter the most necessary data once, and pull in as much as possible from external sources (don't do a bunch of typing that some librarian already did in the 1990s). And I'm saying all this, because I'm actively putting this philosophy to the test, and it's working exactly as hoped. PseudoSkull (talk) 02:07, 15 November 2023 (UTC)
We already have one: Module:TOCstyle, used by Template:TOCstyle. Supports a decent variety of table of contents styles, but for some reason I don't see it used often. Arcorann (talk) 06:56, 16 November 2023 (UTC)

 Comment Beside the automatic generation, there are many templates already available for TOCs. It is likely that they already cover your needs and a per-work template is not needed. See Category:TOC templates. Mpaa (talk) 21:15, 12 November 2023 (UTC)

I'm happy to see that there are already templates for dotted TOCS.........😅 Heyzeuss (talk) 18:23, 13 November 2023 (UTC)
Mostly dreadful things that should be avoided as they cause code bloat and not infrequently blow-out the template limit on transcluding more complex TOC and Indices. Beeswaxcandle (talk) 20:46, 13 November 2023 (UTC)
Just to keep @Xover: from making this topic insanely long with his HTML demonstration of how bad the dot templates are 😏... Let's suffice it to say the dot templates have some very notable flaws. Maybe use {{TOC row 2-1}}, or any of the templates in the same template family, that are listed starting at the "3-column tables" section of that template's documentation. Though these templates don't replicate the dotted nature of the TOC, the dots are not semantic anyway and therefore aren't strictly necessary to be included. The dots are insanely hard to replicate digitally and dynamically at the same time, so I'd say it's best to avoid trying. PseudoSkull (talk) 21:04, 13 November 2023 (UTC)
You know me too well… 😎
Also, let me take the opportunity to say that I generally recommend avoiding using any templates for tables. They can be a little easier for people to deal with before internalizing wikitext table syntax, but they also introduce a lot of complexity on their own. Most of the complexity of tables are inherent to the tables we're reproducing, and neither HTML nor MediaWiki supports our use case particularly well, so in my opinion it's better to bite the bullet and climb the (admittedly steep) learning curve for table wikimarkup. There are always exceptions of course, but as a rule of thumb… Xover (talk) 09:32, 14 November 2023 (UTC)
i concur that dotted templates are to be avoided - bloatware. the learning curve for tables is a chronic pain-point. VE helps a little, and the help is not very - with much trial and error. there is an old magnus tool excel to table - https://magnustools.toolforge.org/tab2wiki.php ; the expert editors rendering of tables in EB1911 is a marvel, and major improvement over gutenberg, but we should be happy with approximation. we could use more toc examples that new editors could cut and paste for future toc's. --Slowking4 ‽ digitaleffie's ghost 00:16, 15 November 2023 (UTC)

Tech News: 2023-46

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

  • Last week, users who previously visited Meta-Wiki or Wikimedia Commons and then became logged out on those wikis could not log in again. The problem is now resolved. [9]
  • Last week, some pop-up dialogs and menus were shown with the wrong font size. The problem is now resolved. [10]

Changes later this week

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

Future changes

  • Reference Previews are coming to many wikis as a default feature. They are popups for references, similar to the PagePreviews feature. You can opt out of seeing them. If you are using the gadgets Reference Tooltips or Navigation Popups, you won’t see Reference Previews. Deployment is planned for November 22, 2023.
  • Canary (also known as heartbeat) events will be produced into Wikimedia event streams from December 11. Streams users are advised to filter out these events, by discarding all events where meta.domain == "canary". Updates to Pywikibot or wikimedia-streams will discard these events by default. [11]

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

MediaWiki message delivery 23:52, 13 November 2023 (UTC)

Proposal to decide whether replacing a broken URL with a Wayback Machine archive counts as an annotation per WS:ANN

I have been looking at some older works in our collection that were sourced from digital web pages (specifically this one), and I noticed that several of the URLs in the original publication are now broken. I think it would be beneficial to replace the links to point to an archived version on the Wayback Machine.

My question is: would this count as an annotation per WS:ANN? On the one hand, replacing the URL would no longer faithfully represent the original edition as written—but on the other hand, it would better represent the original edition as intended.

Thus, I propose that we decide whether changing the URL in a source text to point to the Wayback Machine counts as an annotation; and if not, that we update WS:ANN#What are not annotations? accordingly. Beleg Âlt (talk) 14:14, 2 November 2023 (UTC)

I personally  Support allowing this replacement of URLs with archive links, and updating WS:ANN to exclude this as a type of annontation under the policy. — Beleg Âlt (talk) 14:17, 2 November 2023 (UTC)
 Support Link-rot has to be managed somehow and I don't see this as a true annotation. However, I suggest a small amendment to have the link-text showing as published with the updated link piped behind it. It is only acceptable to do this if the new link is to the Wayback Machine (or some similar future repository). We may need a new filter? Beeswaxcandle (talk) 17:25, 2 November 2023 (UTC)
I agree that only the link destination should be changed, and not the text of the link, even when the text of the link is the original URL itself. I also agree that an archive of the original page is the only acceptable use of this, but I don't know how a filter would be able to make that distinction. —Beleg Âlt BT (talk) 18:17, 2 November 2023 (UTC)
 Support, a very useful and practical thing to do. Since it's getting around a technical limitation, being that the webpage no longer exists, it's pretty straightforward to say that if the text was written in the modern day, they would've included a valid link rather than an invalid one. And leaving the text of the original link in, but have it link to the archive, would be the best solution since it leaves in that bit of the historical context of the work. PseudoSkull (talk) 19:09, 2 November 2023 (UTC)
I personally  Support this update, along with linking to other persistent name repositories (like doi or purl) to handle internal moves. I personally am undecided in preference between linking to the wayback link vs. linking to the moved content via using something like doi / or a purl instead. MarkLSteadman (talk) 05:07, 5 November 2023 (UTC)
  •  Comment The works that we publish should always display the text of the published work. That does not mean that you cannot have a corrected url subsidiary to that text that points to an amended target. Easily accomplished with our works, and clearly not an annotation, just a wikilink per our accepted wikilink process. Whether you want to standardise it, and look to adopt the "url-status" components in things like w:en:Template:Cite news is a different conversation. I would say be wary of adding all that complexity for little benefit. — billinghurst sDrewth 14:06, 5 November 2023 (UTC)
    I find it interesting that you think that amending the target of a link is "clearly not an annotation". I do agree with this of course, but since neither WS:ANN nor WS:Links allows for this, I think it does need to be formalized. Note also that our accepted wikilink process explicitly disallows adding links to non-Wikimedia pages where those links are absent in the original source. —Beleg Âlt BT (talk) 14:33, 6 November 2023 (UTC)
 Support. This preserves many useful links.--Jusjih (talk) 01:59, 19 November 2023 (UTC)

Encyclopedias

What is today the best known way to present an old encyclopedia on the web? Wikisource has several examples in Category:Encyclopedias, created at different dates. Are the most recent additions better than those of 5, 10, 15 years ago? Among the earliest is The New Student's Reference Work, which I scanned in 2005, 18 years ago (see talk page for internal history.). If I started that project today, with 18 more years of collective experience, which path should I follow? Are there examples (of web presentations of old encyclopedias) outside of Wikisource that we admire and envy? -- LA2 (talk) 09:38, 1 November 2023 (UTC)

I don't think we have The One True Solution for this. The newer examples should generally be followed because the old ones are 1) made in a world that was very different in terms of tools etc. and 2) before those 18+ years of experience and 3) under different policies and guidelines. For example, the first encyclopedias were made as completely new presentations, but our standards have since shifted towards presenting works true to how they were actually published. In addition, to some degree each encyclopedia will have its own needs and quirks (because it has its own structure and approach as it was published), so I don't think we can mandate One True Way by fiat.
All of which leads to my conclusion that we need to look at the specific encyclopedia and discuss a bit—at least among interested contributors, but maybe also broader in the community—how best to solve it. If it's a one or two volume work it's probably easier (just treat it like any other book), but if it's something on the order of EB1911 it's going to be much more complicated to find some way to balance all the different concerns. Xover (talk) 11:45, 1 November 2023 (UTC)
I'm intending next to scan Swedish encyclopedias from the 1950s. They are borderline copyright cases, meaning that I can get away with it, but can't grant a free license. Since these can't be hosted in Wikimedia Commons/Wikisource, I'll continue to use Project Runeberg as my base. So you don't need to limit your suggestions to what is currently possible in Wikisource and its ProofreadPage module.
The history is this: In 1992, I started Project Runeberg inspired by Project Gutenberg, just putting e-text online. In 1995, Project Gutenberg released volume I of EB11, and I thought that digitizing encyclopedias might be a nice idea, but it's a lot of work and the e-text routine (proofread first, then publish) was very slow. In 1998, I started to put facsimile scans + raw OCR text online, publishing first and proofreading later. In 2001, Wikipedia started and I started to scan an old Swedish encyclopedia, Nordisk familjebok. This was finished (scan + OCR) in 2003. In 2005, German Wikipedians wanted something similar for German books, and I suggested to use Wikisource for publishing scans + raw OCR instead of just e-text. The aforementioned The New Student's Reference Work was scanned by me as a proof of this concept. Originally, it used its own templates and categories. The ProofreadPage module was designed some years later.
Most likely, I will continue to use my existing method for scanning and presenting encyclopedias. But if radically new ideas are available, I will pick up what I can. --LA2 (talk) 12:26, 1 November 2023 (UTC)

 Comment I have probably done the most contribs and organisation and tidying to align collective works and the templates we have settled upon. For these sorts of works, we should be presenting each article independently and it should have wikidata that allows it to be referenced and linked to a main subject, volume, pp, contributor, language all captured data (think about how you can best scrape data and botify it into WD). Noting that the volumes of the work are not pertinent to the hierarchy, and just can be added to the header as detail. Contributors should be noted and we now use the contributor field which puts aligns with the section field. How to label articles and disambiguate is always a challenge and needs the early consideration, from there I use section labels that align with the article name to make transclusion easier and sensible when you have to pull multiple articles off a page (use of s1, s2, s3, ... names is ugh!) DjVu is still the best form, especially when these pages have columns. Look at how you want to internally link a work where it has internal references, and not overlink the rest of the work, let it be fairly self-contained. Set up your link templates early, and replicate what we already have in place with .../link / ... lkpl templates. Leverage Template:Collective work header to build the header for the work. Setting up a WikiProject is useful to bring together the editing information. There are many learnings and commentary.

Keep it as simple as possible, and remember that this is about reproduction not replication, so leverage existing templates, and don't try to drill into highly specific and quirky templates that don't align with the community's existing editing style, it just makes tidying impossible. — billinghurst sDrewth

If you want a permanent URL for each article, which is useful for Wikidata, the current design of the Page: namespace and the ProofreadPage extension forces us to create a page (a subpage like The New Student's Reference Work/Steam-Whistle) for each article, that contains a <pages index=... fromsection=... tosection=...>, that pulls the text from one or more proofread pages. It would be a lot easier if just adding the mark-up during proofreading could fix this automatically. --LA2 (talk) 23:52, 5 November 2023 (UTC)
editor effort centered on EB1911 and DNB based on the copy paste on wikipedia. some of the older scans text layers are not as clean as the more recent ones. converting to scan backed page view, does take some work. maybe a contest to spur clean-up interest will be necessary, to proofread. --Slowking4 ‽ digitaleffie's ghost 23:08, 20 November 2023 (UTC)

Index:The Celestial Omnibus and Other Stories - Forster (1912).djvu

This file needs to be moved to Wikisource, as it is still under copyright in the UK. It is a copyvio on Commons and marked for deletion. --EncycloPetey (talk) 19:25, 19 November 2023 (UTC)

@EncycloPetey: Done Xover (talk) 07:11, 20 November 2023 (UTC)

Tech News: 2023-47

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

Changes later this week

  • There is no new MediaWiki version this week. [12][13]
  • Starting on Wednesday, a new set of Wikipedias will get "Add a link" (Quechua Wikipedia, Romansh Wikipedia, Romani Wikipedia, Rundi Wikipedia, Aromanian Wikipedia, Tarandíne Wikipedia, Rusyn Wikipedia, Kinyarwanda Wikipedia, Sanskrit Wikipedia, Sakha Wikipedia, Santali Wikipedia, Sardinian Wikipedia, Sicilian Wikipedia, Scots Wikipedia, Sindhi Wikipedia, Northern Sami Wikipedia, Sango Wikipedia, Serbo-Croatian Wikipedia, Sinhala Wikipedia, Slovak Wikipedia, Slovenian Wikipedia, Samoan Wikipedia, Somali Wikipedia, Albanian Wikipedia, Serbian Wikipedia, Sranan Tongo Wikipedia, Swati Wikipedia, Southern Sotho Wikipedia, Saterland Frisian Wikipedia, Sundanese Wikipedia, Silesian Wikipedia, Tamil Wikipedia, Tulu Wikipedia, Telugu Wikipedia, Tetum Wikipedia, Tajik Wikipedia, Thai Wikipedia, Turkmen Wikipedia, Tagalog Wikipedia, Tswana Wikipedia, Tongan Wikipedia, Tok Pisin Wikipedia, Turkish Wikipedia, Tsonga Wikipedia, Tatar Wikipedia, Twi Wikipedia, Tahitian Wikipedia, Tuvinian Wikipedia, Udmurt Wikipedia, Uyghur Wikipedia, Uzbek Wikipedia, Venda Wikipedia, Venetian Wikipedia, Veps Wikipedia, West Flemish Wikipedia, Volapük Wikipedia). This is part of the progressive deployment of this tool to more Wikipedias. The communities can configure how this feature works locally. [14][15][16]
  • The Vector 2022 skin will have some minor visual changes to drop-down menus, column widths, and more. These changes were added to four Wikipedias last week. If no issues are found, these changes will proceed to all wikis this week. These changes will make it possible to add new menus for readability and dark mode. Learn more. [17]

Future changes

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

MediaWiki message delivery 00:55, 21 November 2023 (UTC)

Old OCR gadgets and the newarticletext message

The text in MediaWiki:Newarticletext has (in part): If no text layer is automatically made available, click the OCR button on the toolbar to try to generate one. which is now sort of out of date (although it still works) because of the OCR functionality being moved to the new toolbar button (at the right side of the toolbar). The reason I bring this up today is that I was helping a few people edit Wikisource at the WikiCon in Brisbane, and quite a few clicked on that 'OCR button' link and ended up on Gadgets where there are the two old OCR gadgets, and they got really confused about why we have three ways of doing much the same thing. So I'm wondering a) if there's anything about the old OCR gadgets that the new system doesn't handle yet; and b) whether we can remove that sentence from the newarticletext message. (This came up a couple of years ago, but it looks like it wasn't resolved then.) Sam Wilson 21:04, 18 November 2023 (UTC)

@Samwilson: Just updating the message to refer to current standard UI is sufficiently uncontroversial that I can do that on my own cognisance. Do you happen to have a good way for me to replicate the two relevant icons (the standard toolbar button to toggle the header, and the custom "Transcribe text" button) without having to futz about with screenshots and static images (cf. T346469)? Is there a ready-made SVG somewhere of the buttons including chrome that I could use (maybe something used in the docs already)?
Regarding the two old Gadgets, there are some contributors that have strong preferences regarding their OCR Gadgets; and at least the phetools-backed Gadget is useful as an additional option to try on pages where the standard ones don't give great results. Is the old Google OCR Gadget still using a different Google API than the new OCR tool? It used to, but ISTR it was changed at some point; in which case we might be able to drop that one.
Also, what's the state of exposed API for the new OCR backend? I think the UI and interaction model of the new tool is the main drawback for some contributors, so being able to build our own frontend in a Gadget might help with that. For my own part it takes too many clicks and awkward jumps to offsite web pages to do the things I want, so I'm instead relying on my own custom OCR tool (user script + WMCS backend) that also has performance optimizations that make it more or less instantaneous. I'm not really the target audience here, but those kinds of things are what drive the preferences for experienced users.
It's also possible the users with strong preferences have mellowed on the point over time, but we'd need to poll pretty widely (watchlist notices++) to figure that out with any degree of certainty, and my assessment so far has been that it's not yet time for that. Of course, phetools is currently on borrowed time due to the Grid Engine to Jobs Framework migration, so unless I manage to find the time to port phetools at some point that part will resolve itself (to nobody's satisfaction, but it will at least be definitively resolved). Xover (talk) 10:54, 19 November 2023 (UTC)
@Xover: Thanks for the great info, this is super useful. The new OCR icon is File:Wikisource OCR toolbar icon.svg which is probably good at about 20px: . The header/footer icon is File:Header and footer toolbar button.svg, which might be nicer a little shorter, say 18px.
The Phetools gadget is using Tesseract, so I'm assuming the differences are due to the options being passed to it (or maybe the fact that it's an old version of Tesseract?). I think that's fine to leave as-is, if it's useful (I'd love to dig into what the differences are and add them to the main tool, but I don't think I've got time — any spare OCR energy I've got I'm currently putting towards Transkribus stuff).
The Google gadget on the other hand is using ocr.wmcloud.org as the backed (because ws-google-ocr.toolforge.org redirects there), so I don't think it's providing any difference at all from the Wikisource-extension provided button (the URL parameters are designed to be an exact match, and I've not heard of any bugs with that in the last couple of years — not to say that there aren't any!).
The API for the new backend is documented at https://ocr.wmcloud.org/api/doc and I think the main missing things there are things like not being able to get the raw structured output from the various engines (e.g. hocr, or Google's response format.
Oh, and hopefully at some point soon we'll have Kraken as a fourth engine.
Thanks for helping with all this! :-) Sam Wilson 23:54, 19 November 2023 (UTC)
@Samwilson: cf. the linked Phab, I was kinda hoping y'all had an image of the whole button. In MediaWiki:Newarticletext we should show the actual button with "Transcribe text" in addition to the icon or nobody'll find it.
Since you confirm that the old Google OCR Gadget is using the same backend as the Google option in the new OCR tool I'm going to start the process for deprecating it. There are still ~400 people with it active so it may have to go through a period of watchlist notices and stuff for that.
PS. Since you mention Kraken. Somebody might want to investigate TrOCR at some point (OCR based on a transformer model, like ChatGPT et al that have been creating so much fuss over the last year or so). Xover (talk) 07:00, 20 November 2023 (UTC)
@Samwilson: Text updated in MediaWiki:Newarticletext, with a hacky faux button and all. Xover (talk) 07:29, 20 November 2023 (UTC)
@Xover: Thanks, and good point about the full button images. I've uploaded new screenshots of both buttons now, and suggest the following wikitext for the message (with a bit more line spacing so things don't overlap on narrower screens):

If no text layer is automatically made available, click the Example of the 'Transcribe text' button. button on the toolbar to try to generate one. To open and close the header and footer fields, toggle toggle in the "Proofread tools" section of the toolbar. Also see Proofreading instructions.

Being careful about deprecating the Google OCR gadget sounds sensible. There's no great harm in having it, as long as it's not promoted to new users. Sam Wilson 02:22, 21 November 2023 (UTC)
Updated accordingly (modulo tweaked alt text). Xover (talk) 07:08, 21 November 2023 (UTC)
@Xover: Great, thanks! Looks good. Sam Wilson 11:07, 21 November 2023 (UTC)

Google OCR

Tracked in PhabricatorTask T332125

I have been experiencing some problems with the Google OCR since yesterday. When I press the button, the original OCR text reappears instead of being overwritten by the new OCR. Sometimes I have to press the button several times until I succeed, sometimes it does not work at all. Any ideas what might have gone wrong? -- Jan Kameníček (talk) 09:27, 20 November 2023 (UTC)

I just tested with a handful of random pages and it worked as expected. Does the problem go away when you use the new OCR tool (the "Transcribe text" button) with "Google OCR" selected as the engine? Since the two use the same backend service, if one works and the other does not that tells us the problem is not on the backend. If you're comfortable with your web browser's JavaScript Console you may also want to check there for any relevant error messages when the problems occur (any relevant error messages should be recognizable as related to the google OCR gadget; there's often a lot of unrelated noise in the console that can get kinda confusing). Xover (talk) 13:30, 20 November 2023 (UTC)
@Xover: Unfortunately, the problem stays, no matter whether I use the old Google OCR button or whether I use the new OCR tool with Google OCR selected. The only difference is that with the old OCR button I receive the message: <error> undefined undefined, while with the new tool I receive the message: "Error from the OCR tool. The Google service returned an error. We can not access the URL currently. Please download the content and pass it in." I have already tried it on 3 different computers at 3 completely different and distant places, with the same problems. --Jan Kameníček (talk) 17:01, 20 November 2023 (UTC)
@Jan.Kamenicek: If both tools fail that tends to indicate a backend problem (as do the error message: both suggest that the backend service is returning an error). However, if so it is very strange that I cannot reproduce it (I just tested again and it worked fine for me). The other option is that it is somehow related to your user account. When next you see this problem, could you try the same page again from a private browser window or from a different web browser where you are not logged in? Xover (talk) 17:41, 20 November 2023 (UTC)
@Jan.Kamenicek: Nevermind, I was just able to reproduce this. It's an error somewhere in the backend. It looks like perhaps Google is having trouble downloading the page images from Commons, possibly due to rate-limiting or similar.
It seems to be at least somewhat intermittent though, since I had trouble reproducing the problem. It is possible that this is a transient error, or simply caused by higher than normal load (e.g. if a bot is hammering the service).
@Samwilson: Are you aware of any issues here? Xover (talk) 17:56, 20 November 2023 (UTC)
@Xover: It might be just coincidence, but the problems really seem to vanish when I log out… --Jan Kameníček (talk) 18:07, 20 November 2023 (UTC)
One more thing: it seems that the problems are not so big when I start working, but the longer I use the tool the worse it gets. Yesterday evening it finally stopped working completely. --Jan Kameníček (talk) 18:14, 20 November 2023 (UTC)
@Jan.Kamenicek, @Xover: That sounds very annoying, sorry to hear it! I'm working on a patch that will react to that error and retry the image via direct upload. I'm not sure if that's a great idea, but we'll see how it goes! As for it slowing down over time, does that correlate to later pages in a long work? Does it still slow down if you close the browser tab say every ten pages and the continue in a new tab? I'll see if I can dig into what is going on. It could be related to the way we send an OCR request for the next page when one is loaded (to make it quicker when you end up on that page). Sam Wilson 11:06, 21 November 2023 (UTC)
@Samwilson: Today I started using the tool at about 13.00 and the problem reappeared at the first two pages, but afterwards it seems to have vanished. I do not know if something has been changed or fixed meanwhile, but now it works very well again. --Jan Kameníček (talk) 15:38, 21 November 2023 (UTC)
@Jan.Kamenicek: Oh good, but yeah it sounds like it's down to the Google side being intermittently unable to get the images (either because of being rate limited or because the thumbnails don't generate quickly enough — although I still don't understand the latter because we're sending the same image URL that's displayed on the Page editing form). But yeah, hopefully we can improve it a bit, soon. Sam Wilson 01:10, 22 November 2023 (UTC)

Louisa May Alcott works rediscovered

Please see details at Author talk:Louisa May Alcott#Works rediscovered. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:22, 22 November 2023 (UTC)

FYI: Celebrating 20 years of Wikisource and 3,000+ years of history

https://diff.wikimedia.org/2023/11/23/celebrating-20-years-of-wikisource-and-3000-years-of-history/ —Justin (koavf)❤T☮C☺M☯ 10:11, 23 November 2023 (UTC)

Tech News: 2023-48

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

Changes later this week

  • The new version of MediaWiki will be on test wikis and MediaWiki.org from 28 November. It will be on non-Wikipedia wikis and some Wikipedias from 29 November. It will be on all wikis from 30 November (calendar). There is no new MediaWiki version next week. [18][19]
  • MediaWiki's JavaScript system will now allow async/await syntax in gadgets and user scripts. Gadget authors should remember that users' browsers may not support it, so it should be used appropriately. [20]
  • The deployment of "Add a link" announced last week was postponed. It will resume 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 23:08, 27 November 2023 (UTC)

Request to disable MediaWiki:Gadget-interwiki-transclusion

@Xover: per T351685 (I'm Sohom Datta on a different account cause my main one cannot login) SodiumDogFood (talk) 15:29, 24 November 2023 (UTC)

@SodiumDogFood: Done Xover (talk) 16:00, 24 November 2023 (UTC)
And I have now reenabled it since the issue has been resolved. Xover (talk) 13:49, 28 November 2023 (UTC)

Interviews: Tell us about your experiences using Wikidata in the Wikimedia sister projects

Hello, the Wikidata for Wikimedia Projects team at Wikimedia Deutschland is investigating the different ways Wikidata is being used in the Wikimedia projects. If you would like to speak with us about your experiences with integrating Wikidata in Wikimedia wikis, please sign up for an interview in this registration form. Please note that currently, we are only able to conduct interviews in English.

The front page of the form has more details about what the conversation will be like, including how we would compensate you for your time.

For more information about our team, visit our project page. If you would still like to share about your experiences but don't have time for an interview we welcome your feedback in written form on this wiki page. Thank you.--Danny Benjafield (WMDE) (talk) 10:32, 28 November 2023 (UTC)

Stale Requests for Comment

I see five Requests for Comment open right now. Here are the dates they were opened:

Shouldn't these have been closed and/or actioned by now? Arcorann (talk) 07:31, 28 November 2023 (UTC)

Some still have no consensus. Keep talking longer.--Jusjih (talk) 03:46, 4 December 2023 (UTC)
Retrieved from "https://en.wikisource.org/w/index.php?title=Wikisource:Scriptorium/Archives/2023-11&oldid=13764487"