Wikisource:Scriptorium

SpBot archives all sections tagged with {{section resolved|1=~~~~}} after 3 days and sections whose oldest comment is older than 30 days.

Bot approval requests

• See Wikisource:Bots for information about applying for a bot status
• See Wikisource:Bot requests if you require an existing bot to undertake a task

SodiumBot

I'd like to request community approval (bot permissions) for SodiumBot to continue Phebot's matchandsplit task (The server for using the match and split service is at matchandsplit.toolforge.org). I am aware that this is somewhat late since SodiumBot has already been doing this for a bit (since the last Wikimedia Hackathon), however, better late than never :) Sohom (talk) 14:11, 13 June 2024 (UTC)

What is the plan with respect to Phebot and this task? Is SodiumBot going to pass the task back to PheBot or will SodiumBot now take this on as a "permanent" task? Beeswaxcandle (talk) 20:08, 13 June 2024 (UTC)

@Xover might be able provide more context here about the plans regarding phebot, but my understanding is that this task is going to be hard to setup using Phebot's old architecture (because unlike wsstats a lot of the code depends very very heavily on the now deprecated grid engine). Sohom (talk) 20:39, 13 June 2024 (UTC)

My plan is to try to resurrect phetools at some point when I have the time for it, and at that point I will probably try to fix all of it (at which I may or may not succeed). The likelihood of my finding the time to work on it in any kind of reasonable time frame is very small, and the urgency of doing so is much much reduced now that we have an alternative for the Match&Split functionality in SodiumBot and toolforge:matchandsplit (not to mention the stats that Sohom has also set up). In other words, I wouldn't recommend holding your breath waiting for phe-bot to pick up this task again. Xover (talk) 07:37, 15 June 2024 (UTC)

In that case, let's treat this Bot Approval Request as a request to change the six-month flag to indefinite provided that SodiumBot remains doing just the Stats update and Match&Split. I'll keep the request open for a week to allow for community input. Beeswaxcandle (talk) 07:48, 15 June 2024 (UTC)

I agree. Permanent bot flag for the user account, plus authorization for the two specific tasks it is already performing.

@Sohom Datta: It is a bit overkill just now, but it's generally a good idea to document each distinct task the bot is authorized for on its user page, including linking to the discussion where that task was authorized, and to link to the documentation in the edit summary for edits the bot makes under that task. That way anyone that comes across an edit by the bot can easily find out a) what the bot is doing and why, and b) who authorized it to do so. It's convenient for other contributors and staves off unnecessary drama. Xover (talk) 08:05, 15 June 2024 (UTC)

Updated the userpage, I'll deploy a update for the match and split server to use better edit summaries in a bit. Sohom (talk) 14:40, 16 June 2024 (UTC)

•  Support, and thank you so much for doing this Sohom! Match&Split is an important tool for the community so your stepping up to the plate here is very very appreciated!
  I've checked some of the bot's recent edits and see no problems. This should also have pretty much the same risk profile as Match&Split in phetools, except that Sohom is actually around and responsive (which Phe hasn't been since 2016). --Xover (talk) 07:45, 15 June 2024 (UTC)

 Support Thanks for your efforts here! MarkLSteadman (talk) 18:24, 16 June 2024 (UTC)

Repairs (and moves)

Designated for requests related to the repair of works (and scans of works) presented on Wikisource

See also Wikisource:Scan lab

Other discussions

Match and split

I've managed to get a rudimentary version of the old code up and running at https://matchandsplit.toolforge.org :) Unlike the previous version, the bot is not omnipresent and jobs need to be manually submitted at the match endpoint and the the split endpoint respectively. The resulting edits will be made by SodiumBot.

Feel free to test the tool and let me know if there are any bugs/issues/crashes that you find. Once a significant amount of people have used the tool and confirmed that it is working as intended, I'll start the process of making the tool automatic (similar to how phetools worked) Sohom (talk) 11:54, 5 May 2024 (UTC)

omg I missed this but I'm going to test this so hard —Beleg Tâl (talk) 16:52, 31 May 2024 (UTC)

I'm not sure if I'm doing it wrong, but I submitted The Singing Bone (Freeman)/The Case of Oscar Brodski to the match endpoint and it said Response: {"status":"recieved"}, but nothing happened on the page and the task didn't show up at https://matchandsplit.toolforge.org/status either. —Beleg Tâl (talk) 17:18, 31 May 2024 (UTC)

Update: It's working now :) —Beleg Tâl (talk) 20:56, 12 June 2024 (UTC)

Manual aggregation of newspaper articles versus automatic aggregation

What is the advantage to switching from automatic aggregation of newspaper articles to manual aggregation? I see them being switched from time to time, but I can't fathom the reason. It just adds another layer of work and misses new articles unless someone remembers to add them. See for instance: San Francisco Call, the most recent one I noticed. See the edit history for before and after. The format is almost identical, other than one column versus multiple columns. Automatic aggregation has one more entry than the manual aggregation. RAN (talk) 00:39, 16 May 2024 (UTC)

In theory, the advantage is that manual aggregation can be better-organized and exclude redirects. —CalendulaAsteraceae (talk • contribs) 19:03, 17 May 2024 (UTC)

• Better is subjective, and missing articles from the index is more important than having one column versus three columns. We would probably be better of deleting unused redirects if they are cluttering the index. There are currently eight different formats for creating an index. We should standardize on one or allow an automatic and a manual aggregation, the way it is available at Wikimedia Commons. We can have Portal:Newspaper and Newspaper, with Portal:Newspaper (or the other way around) always automatic. --RAN (talk) 23:56, 17 May 2024 (UTC)
• Is anyone against me creating Portal:San Francisco Call so we can have both automatic aggregation there and manual aggregation at San Francisco Call (or the other way around) using one of the eight different formats in use throughout Wikisource. It would be the equivalent of Commons:Category:Abraham Lincoln (automatic and includes everything) and Commons:Abraham Lincoln (manual in any format you please). --RAN (talk) 02:20, 19 May 2024 (UTC)

why don't you seek a consensus about the arrangement of newspaper pages? the broken commons category process may not be the best model, rather you might want to look at the commons creator, or institution pages, or commons:Template:Wikidata_Infobox, that are wikidata generated. --Slowking4 ‽ digitaleffie's ghost 03:39, 21 May 2024 (UTC)

• @Slowking4: What do you mean by "broken commons category process", can you give examples of what you mean? --RAN (talk) 18:05, 7 June 2024 (UTC)

currently, Category:Category:Steamboat_Willie, Category:Film_characters_by_actors, and Category:Men of the <country> by name, where "the" isn't needed. apparently there is constant discussion about categories, to an uncertain purpose. it does not disseminate images. i would call that broken. you can hand curate a subject index, but what is your maintenance process? leveraging wikidata is a better method.--Slowking4 ‽ digitaleffie's ghost 19:04, 7 June 2024 (UTC)

and now an attempt at a problem statement RFC:_Automatic_categorisation_both_bane_and_gain;_work_needed_to_identify_source_of_categorisation apparently the editors think generating categories by infobox is "wrong", --Slowking4 ‽ digitaleffie's ghost 14:59, 9 June 2024 (UTC)

(the above link is broken, here's the correct one: c:COM:VP#RFC: Automatic categorisation both bane and gain; work needed to identify source of categorisation) — Alien333 (what I did & why I did it wrong) 16:07, 9 June 2024 (UTC)

The Kojiki is incomplete

The Kojiki (Horne) is incomplete here and has been so for over a decade. the full text is here can I just copy it to here? Immanuelle (talk) 21:04, 23 May 2024 (UTC)

The short answer is no, per the policy Wikisource:What Wikisource includes second hand transcriptions are no longer acceptable. One reason it leads to situations like here where a work might be edited or changed, for example, this version appears to be a complete version of a latter abridged / edited version (The Sacred Books and Early Literature of the East/Volume 13/Book 1), but it is missing the footnotes, so maybe it is actually an edited version published somewhere else without the footnotes (e.g. published on some other website someone copied...)? There was an effort that got 178 pages into transcribing the 1882 publication Index:Kojiki by Chamberlain.djvu, that anyone interested in can proofread against. Note the version from sacred-texts appears to be based on a scan of a 1970s reprint of a 1919 reprint. MarkLSteadman (talk) 00:16, 24 May 2024 (UTC)

There is a contradiction you seem to be missing here. With historical texts it can be impossible to obtain primary sources, and often secondary sources can have their own historical merit, especially in the case of translations, which this is. For *any* translation there is no primary source in the first place. Often having multiple reprints translations of a work is important to understanding it's context.

By all means mark a work as a degraded copy/translation/etc, but do not use that as an excuse to exclude important works. Just mark them appropriately. 216.67.62.63 20:00, 17 June 2024 (UTC)

I think you are confusing primary / secondary source with primary / secondary transcription. We accept copies of published editions, as long as the transcription is directly from that published edition or translation. What we do not accept is a copy-paste from an internet transcription such as Project Gutenberg or other websites. The transcription in that case is once removed from the published source. It is second-hand transcription; and that is what we do not allow. We need a scan of the publication or text being transcribed. It does not have to be a primary source; it simply cannot be second-hand. --EncycloPetey (talk) 20:19, 17 June 2024 (UTC)

• Immanuelle: The main reason that that would be a bad thing is because the copy at Kojiki (Horne) is the exact same as the copy at The Sacred Books and Early Literature of the East/Volume 13/Book 1, just with the footnotes removed. It is not, to my knowledge, an official later edition, just an on-line version of the text only. I’m working on the original version (which has more footnotes) right now at Index:Kojiki by Chamberlain.djvu, with another user helping with the Japanese text (which is very hard to read because of the scan quality). TE(æ)A,ea. (talk) 21:33, 29 May 2024 (UTC)

  @TE(æ)A,ea. I can try to help with the Japanese text. This is Immanuelle, I’m just logged out right now. Although it will probably take me a few weeks since I’m on a trip to Japan right now. 220.156.77.119 02:59, 30 May 2024 (UTC)

Table of Contents help

Can someone help me in the creation of Index:Indian Medicinal Plants (Text Part 1).djvu. We are working to complete the project. Can anyone extend your helping hand in completing the Table of Contents. Thanking you. Rajasekhar1961 (talk) 06:48, 24 May 2024 (UTC)

@Rajasekhar1961 Which pages are the table of contents on? Thanks, Cremastra (talk) 15:37, 25 May 2024 (UTC)

Page:Indian Medicinal Plants (Text Part 1).djvu/24 through 39. then transclude on the index page. --Slowking4 ‽ digitaleffie's ghost 19:02, 25 May 2024 (UTC)

I could help, though there's the question of how. I'm going to use {{TOC row 1-dot-1-1}}, instead of the {{dtpl}} used on the first page, due to the size of it. — Alien333 (what I did & why I did it wrong) 19:08, 25 May 2024 (UTC)

@Alien333 Given that Chrisguise's TOC had approx.~500 entries, and this looks to have over 1000, is either SimpleTOC or, dare I say it, not dot-leaders whatsoever, going to be required (given the number of phantoms that the SimpleTOC might need, unless there is a good way to embed SimpleTOC's in another table)? TeysaKarlov (talk) 00:53, 26 May 2024 (UTC)

Hmmm. It's true that the TOC row's may be excessive here, but embedding tables is definitely not the way to go to reduce post expand size. Transcluding the first two pages with {{TOC row 1-dot-1-1}} is already a third of the maximum expand size, so I'm going to try with {{TOC row 1-1-1-1}}. — Alien333 (what I did & why I did it wrong) 07:10, 26 May 2024 (UTC)

@Rajasekhar1961 It's done. — Alien333 (what I did & why I did it wrong) 18:29, 26 May 2024 (UTC) EDIT: Well, looks like it's not over after all. The TOC manages to transclude entirely, but the PD-US after breaks down. {{TOC row 1-1-1-1}} is as near a raw HTML table as I can think of, so I don't know how we'll do this. I also moved the preface to a subpage, but still. I think there's just no way of making it fit on one page. — Alien333 (what I did & why I did it wrong) 18:45, 26 May 2024 (UTC)

Took a quick look. The PD template looks like that because it is missing the CSS styling, possibly because of the "Unstrip post-expand size" exceeds 5MB warning. Someone with more experience of mediawiki internals might understand why that error blocks the loading of the styles from {{License/styles.css}}. MarkLSteadman (talk) 23:50, 26 May 2024 (UTC)

Possibly because each row gets set with the class attribute, where it might be more scalable to use page styles to define once per a column? MarkLSteadman (talk) 00:40, 27 May 2024 (UTC)

I'll try using a bare something like |- | {{{1|}}} || {{{2|}}} || {{{3|}}} || {{{4|}}}, removing the class in the template, and instead putting it in the {|, as classes like __toc_row_1-m-1-1 appear to be passed to child nodes. — Alien333 (what I did & why I did it wrong) 05:50, 27 May 2024 (UTC)

Well, that did it. Removing the row classes brought it from 6MB to 180KB. I put it in {{TOC row min-4}}. It's a good idea to remove the row classes, put the class of most lines in {{TOC begin}}'s class parameter and override for the few cases we need. — Alien333 (what I did & why I did it wrong) 06:57, 27 May 2024 (UTC)

Note that The Art of German Cooking and Baking and Statesman's Year-Book 1913 both have the same issue as well. MarkLSteadman (talk) 07:08, 27 May 2024 (UTC)

Done Fixed them with {{TOC row min-3}}. Their unstrip sizes are now respectively 800KB and 1MB. — Alien333 (what I did & why I did it wrong) 07:42, 27 May 2024 (UTC)

Every new generation of contributors invent new templates to produce toc tables, thinking surely, surely, there must be a better and easier way to do this. Slowly but surely, if they stick around, they discover all the problems with wrapping table syntax in templates; but the myriad overlapping and multiplying templates persist. Now we've gotten to the point where we have templates that literally just spit out…

|-
| {{{1|}}} 
| {{{2|}}} 
| {{{3|}}}

…instead of typing…

|-
| || Constitution and Government || 4

…and requires you to manually add another template to attach a stylesheet. That is, it is literally more complexity for less functionality than doing the same with normal table wikimarkup and Help:Page styles. I despair…

Pretty please with sugar on top, stop using templates for tables of contents and stop creating ever more templates to spit out some custom combination of template markup. Please? --Xover (talk) 13:50, 30 May 2024 (UTC)

I know that these templates seem a bit useless, but it's in case someone not familiar with table markup has a large TOC to deal with.

I don't think they really want to know that it works by removing the row classes and that therefore it's just simple table markup.

EDIT: The advantage is also that it's easier to integrate it with the other TOC row's.

The tables to be fixed with this are often started before the problem is recognised, and it's much easier to just to a search-and-replace from whatever there was before to another template name than having to painstakingly replace the template starts by |- | and some but not all |'s with ||.— Alien333 (what I did & why I did it wrong) 16:57, 30 May 2024 (UTC)

Don't take my ranting to heart; it's a long-standing and generalised frustration.

Yes, when creating a point solution to this one specific problem this was a rational approach. I'm saying that, in general, these templates by merely existing create the expectation that they should be used and is somehow better than plain table markup (and we keep amassing more and more of them). In reality they cause more problems than they solve, and contributors who struggle with the complexities of creating tables of contents have no easier time of it with the templates than they would with the table markup. Rajasekhar1961, for example, is a prolific and long-standing contributor whose strengths simply lie elsewhere than table of contents creation. No template we ever create is going to change that.

IMO, we should bulk deprecate all the toc templates and focus our efforts on documentation, how-tos, community assist, and maybe some tooling to make table wikimarkup + Page styles easier and more efficient to use. Xover (talk) 17:21, 30 May 2024 (UTC)

I agree about the whole documentation bit (I often grumble to myself about it), but I will stay a fervent defender of templates.

Template's primarily utility of factorizing formatting is indeed reduced when the template call is as long as the formatting, but they also factorize change.

If we make a decision, change our mind or just find a better way to do it, if it's a template we only have to fix one page, if it's direct formatting we have to fix all of them.

And specifically for the TOC templates, apart from the whole dot leader mess, they are I think simpler than table markup. Take for instance {{TOC row 3-1}}.

What's quicker, {{TOC row 3-1|a|b}} or |- |colspan=2 style="width:99%;text-align:left"|a |style="text-align:right"|b?

And that's excluding the other things like padding, vertical align or wrapping that make it nicer although they're not necessary — Alien333 (what I did & why I did it wrong) 17:41, 30 May 2024 (UTC)

See Help:Page_styles#Tables_of_contents. You can have just table markup and still get your fancy formatting in a more reusable way, no templates needed. You can do arbitrarily complex formatting that way without a proliferation of templates, but it really shines for the simpler more regular tables of contents. Xover (talk) 18:29, 30 May 2024 (UTC)

The only update you can do with table styles that will propagate is changing the classes, if any more significant changes are to be made they have to be made individually. As you said, it works best for simpler TOCs, and it's to be expected that we have many different templates when there are so many ways for a TOC to be different. — Alien333 (what I did & why I did it wrong) 18:44, 30 May 2024 (UTC)

We're getting far afield, but… You're trying to teach grand-pappy to suck eggs. Yes, in almost every case we should use template wrappers over raw formatting markup. But for tables the markup syntax is not suited to wrapping with a template and creates endless problems. And the use case (toc tables) in effect requires creating a completely new microsyntax to cover all the cases, at which point all you've done is make it less accessible because you can no longer rely on general knowledge of (and documentation and howtos for) tables and CSS. The important part of working with toc tables is describing the structure of the table; and changing the structure of the table is not something you can reliably do through the template abstraction. Any formatting and similar is more readily and reliably handled with page styles (or an approach like {{auxiliary toc styles}} in a pinch). Xover (talk) 06:18, 31 May 2024 (UTC)

Thank you everyone for the help. I do not know the technical aspects. Is it possible to link the subpages of the species to their corresponding pages.--Rajasekhar1961 (talk) 09:33, 29 May 2024 (UTC)

I'm not sure what you mean, can you clarify? — Alien333 (what I did & why I did it wrong) 09:35, 29 May 2024 (UTC)

See this page Indian Medicinal Plants/Natural Order Moringeæ; It has two plant species 336 and 337. Is there any necessity to link these individual species of plants from Table of Contents.--Rajasekhar1961 (talk) 11:32, 29 May 2024 (UTC)

No, there's no real necessity. On top of that, I fear that it would be too large if we add 1381 more links. — Alien333 (what I did & why I did it wrong) 11:37, 29 May 2024 (UTC)

You can add {{anchor+}} and then link via ChapterName#AnchorName if you really want to, but in general, there is no need and it makes the chapter divisions less clear. Other works with Chapter composed of many small sections we don't typically break up and link either. MarkLSteadman (talk) 12:53, 29 May 2024 (UTC)

Tech News: 2024-22

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

• Several bugs related to the latest updates to the UploadWizard on Wikimedia Commons have been fixed. For more information, see T365107 and T365119.
• In March 2024 a new addPortlet API was added to allow gadgets to create new portlets (menus) in the skin. In certain skins this can be used to create dropdowns. Gadget developers are invited to try it and give feedback.
• Some CSS in the Minerva skin has been removed to enable easier community configuration. Interface editors should check the rendering on mobile devices for aspects related to the classes: .collapsible, .multicol, .reflist, .coordinates, .topicon. Further details are available on replacement CSS if it is needed.

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 28 May. It will be on non-Wikipedia wikis and some Wikipedias from 29 May. It will be on all wikis from 30 May (calendar). [1][2]
• When you visit a wiki where you don't yet have a local account, local rules such as edit filters can sometimes prevent your account from being created. Starting this week, MediaWiki takes your global rights into account when evaluating whether you can override such local rules. [3]

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

MediaWiki message delivery 00:15, 28 May 2024 (UTC)

Template:EB9

This template now seems to be producing redundant information. It has always(?) included a linked statement in the 'notes' part of the header concerning the volume the article is from, but it now also includes a link to the same place (as a roman numeral only) as the first line of the transcluded article. The former seems to me to remain appropriate, the latter unnecessary. For an example see Encyclopædia Britannica, Ninth Edition/Turmeric. Chrisguise (talk) 10:14, 28 May 2024 (UTC)

Block center vs Center block

Can someone explain the difference between {{block center}} and {{center block}}? I haven't been able to figure out which one is preferred. Arcorann (talk) 00:12, 29 May 2024 (UTC)

The {{block center}} template has been around longer and is better maintained. --EncycloPetey (talk) 01:23, 29 May 2024 (UTC)

Block center is based on a div, while center block is based on span. So, it depends on the level you need to use them at. You can't wrap block center inside a template that is a span, but you can with center block. I usually put the "where on the page" outside the "what it looks like", so nearly always use block center. Beeswaxcandle (talk) 08:01, 29 May 2024 (UTC)

Both templates are div-based. —CalendulaAsteraceae (talk • contribs) 21:25, 29 May 2024 (UTC)

I personally prefer {{center block}} because it is more consistently named with other block templates ({{smaller block}}, {{italic block}}, etc.) However, I think {{block center}} is generally more popular. —Beleg Âlt ^BT (talk) 14:04, 30 May 2024 (UTC)

Also I think there used to be significant differences between them (one of them was table based I think?) but I'm pretty sure both are more or less equivalent now. —Beleg Âlt ^BT (talk) 14:10, 30 May 2024 (UTC)

No, there are significant differences in how they're implemented. One sets the display model of the div to be a faux table and uses positioning and other weirdness. The problem is they both have a gajillion options and are being used in weird ways that rely on undocumented quirks of how they're implemented, so any attempt at consolidating them is going to trigger mobs of villagers contributors with torches and pitchforks because you've changed alignment by a pixel in some pathological edge case that was never intended to work to begin with. It can be done but it's a lot of thankless work, and I am not at all certain we could get community consensus to do so. The community would have to accept that some stuff inevitably would break along the way, and given the pushback we've had on less intrusive changes I'm not sure the appetite is there. Xover (talk) 17:37, 30 May 2024 (UTC)

Oh yeah, I'm not going anywhere near any attempts to merge those templates :D —Beleg Âlt ^BT (talk) 17:45, 30 May 2024 (UTC)

Are you sure? I'd be prepared to offer 150% of your base admin hourly rate! :) Xover (talk) 18:37, 30 May 2024 (UTC)

Is there any difference between these that could not be effected by a single template with parameters added to toggle between specific functionalities? BD2412 T 01:38, 1 June 2024 (UTC)

I've done some work to bring the templates closer together (making sure they have the same gajillion options and simplifying the code somewhat). At this point, the differences in implementation are:

.wst-center-block {
	display:block;
	width:fit-content;
}
.wst-center-block-title {
	display:inline-block;
	width:100%;
}

.wst-block-center {
	display:table;
	width:auto;
}
.wst-block-center-title {
	display:table-caption;
}

I also added some tracking categories:

• Category:Pages using center block with title parameter
• Category:Pages using center block with style parameters
  • Category:Pages using center block with class parameter
  • Category:Pages using center block with height parameter
  • Category:Pages using center block with width parameter
  • Category:Pages using center block with max-width parameter
  • Category:Pages using center block with align parameter
  • Category:Pages using center block with style parameter

—CalendulaAsteraceae (talk • contribs) 03:44, 10 June 2024 (UTC)

I've discovered a practical difference in behaviour: {{center block}} will ignore a floated element in its margin, but {{block center}} will be shifted to the side and centered in the remaining space. See for example Page:The baby's opera - a book of old rhymes, with new dresses (IA babysoperabookof00cran).pdf/11. —Beleg Tâl (talk) 15:29, 12 June 2024 (UTC)

That's good to know about! Which behavior do you think is preferable? (I'd be inclined to say the template should account for the floated element, but I'm open to opposing arguments.) —CalendulaAsteraceae (talk • contribs) 17:25, 12 June 2024 (UTC)

Move Template:Dhr to TemplateStyles

I have tested this in the sandbox and it appears to work properly, but since it is such a fundamental template I want to get community consensus before migrating it. —Beleg Âlt ^BT (talk) 14:02, 30 May 2024 (UTC)

You'll find someone somewhere has been using it instead of em-dashes inside link markup, which means it'll break if you change it to use TemplateStyles. I still  Support doing so, of course, but we have way way too much baggage to imagine any such change to go without breaking something. Xover (talk) 17:41, 30 May 2024 (UTC)

Yeah, hacky stuff is guaranteed to break eventually, so I'm not worried if this is what does it :D —Beleg Âlt ^BT (talk) 17:42, 30 May 2024 (UTC)

I don't think I got it right, did you really mean someone used {{dhr}}, a spacing template, to replace an emdash? — Alien333 (what I did & why I did it wrong) 17:43, 30 May 2024 (UTC)

I think they just mean that there's a good chance that someone, somewhere, used {{dhr}} in a really weird and unpredictable way. —Beleg Âlt ^BT (talk) 17:44, 30 May 2024 (UTC)

I was thinking {{rule}} for some reason, but, yeah, as Beleg sussed I was speaking more in the general sense. Assume that someone has abused any template in ways horrifying to anyone technically inclined, and plan accordingly. Xover (talk) 18:32, 30 May 2024 (UTC)

+1  Support and good luck dealing with all the horrifying things you find along the way. —CalendulaAsteraceae (talk • contribs) 18:54, 30 May 2024 (UTC)

Where are the test cases and such for us to look at? Without that, it's hard to identify known edge cases, or even determine what situations were checked. --EncycloPetey (talk) 18:59, 30 May 2024 (UTC)

The test page for this template is located at Template:DoubleHeightRow/testcases (which is linked from the documentation page for Template:DoubleHeightRow) —Beleg Âlt ^BT (talk) 19:16, 30 May 2024 (UTC)

Granted, but where can we see the results of the sandbox testing you say you performed? That's what I'm asking. There is no proposed code linked, and no demonstration of how the proposed code will work.  Oppose the introduction of secret code tested without public access to the results. --EncycloPetey (talk) 19:39, 30 May 2024 (UTC)

Umm, not sure, but Template:DoubleHeightRow/sandbox contains code marked experimental and using Templatestyles, so I think this is it. — Alien333 (what I did & why I did it wrong) 19:41, 30 May 2024 (UTC)

The proposed changes, as I said, are in the sandbox (which is located at Template:DoubleHeightRow/sandbox) and the demonstration of how it works is in the test cases page (which is located at Template:DoubleHeightRow/testcases). —Beleg Âlt ^BT (talk) 19:42, 30 May 2024 (UTC)

Also, the code is hardly "secret", it's literally just copy-pasting some CSS from Template:DoubleHeightRow to Template:DoubleHeightRow/styles.css —Beleg Âlt ^BT (talk) 19:48, 30 May 2024 (UTC)

Saying "the" sandbox usually means Wikisource:Sandbox. Thank you for providing links. In any situation like this, please do provide links instead of expecting everyone to have to go track down the relevant pages themselves, especially when you are proposing a change. And you did not tell anyone at the outset what change you were proposing or where to find the code. Please do not expect your audience to be mind readers. --EncycloPetey (talk) 19:53, 30 May 2024 (UTC)

@EncycloPetey: In the context of a template "the sandbox" is usually going to mean the "/sandbox" sub-page. There's a common (cross-project) convention for templates that there are "/doc", "/testcases", and "/sandbox" sub-pages where these things live (and they're auto-linked from the documentation footer etc.). TemplateStyles stylesheets by convention live in "/styles.css", but the precise location should be manually documented (in /doc) using {{TemplateStyles|Template:Foo/styles.css}}. Similarly, any Scribunto (Lua) modules used should be documented with {{lua|Module:Foo}} (both create the visible banner in the top right area of the documentation page).

I'm guessing BT didn't specify tests and demonstrations etc. because moving it to use TemplateStyles should have literally zero visible effect (but for that massively annoying bug that the WMF seems to have no plan to ever fix, sigh): it is in itself a purely technical change that makes it easier to maintain. That they are asking for consensus here is because… well, first because, unlike me, BT is a super-nice person, of course :)… but also because technical contributors have been getting a lot of grief lately, and being tediously fastidious about getting community support first is a way to ameliorate that. Xover (talk) 05:50, 31 May 2024 (UTC)

If it takes two paragraphs to explain something after the fact, then that explanation should have been provided at the outset. It should not be assumed that all members of the community know arcane technical details that specialists "just know". And providing links to locations for relevant viewing is always a courtesy, regardless of the kind of conversation happening. --EncycloPetey (talk) 14:20, 31 May 2024 (UTC)

Proposal to merge replace one of the following with a redirect to the other: Template:Hidden text and Template:Phantom

These two templates are literally identical, can we please merge them before scope creep causes them to diverge? —Beleg Âlt ^BT (talk) 19:28, 30 May 2024 (UTC)

 Support —CalendulaAsteraceae (talk • contribs) 20:04, 30 May 2024 (UTC)

 Support (and this should not be controversial). Xover (talk) 05:22, 31 May 2024 (UTC)

 Comment What would be the point of merging the two templates? Why not just pick one to be replaced by a redirect to the other? --EncycloPetey (talk) 14:57, 31 May 2024 (UTC)

... that's just the same thing with different wording —Beleg Tâl (talk) 15:26, 31 May 2024 (UTC)

No, it isn't. Merging is deletion of one item, moving the other to its location, deleting, then undeleting so that the edit histories are merged. Merging includes the merging of edit histories, not the simple deletion/replacement of one item. --EncycloPetey (talk) 15:44, 31 May 2024 (UTC)

Oh, lol. To clarify: I am proposing to merge the functionality of these templates via redirecting one to the other so that they are both the same template. I do not remotely care at all whether their edit histories are also merged. —Beleg Tâl (talk) 16:55, 31 May 2024 (UTC)

Then this isn't a proposed merge. It's a proposal to replace one of two items with a redirect, without telling us which one will be replaced with a redirect and which one will be kept. Nothing is actually being merged.

Your statement "I do not remotely care at all whether their edit histories are also merged" is very troubling, as it shows a blatant disregard for copyright attribution requirements central to all Wikimedia projects. I suggest reading up on w:Wikipedia:Merging before proceeding. --EncycloPetey (talk) 17:53, 31 May 2024 (UTC)

I would assume that the edit history would be maintained under whichever title is redirected to the other. Not to be pedantic, but copyright is inapplicable to functional elements presented in their simplest expression. I don't think there is anything at all that could be subject to copyright protection here. BD2412 T 02:08, 1 June 2024 (UTC)

Yeah, otherwise the implication is that any replacement of a page with a redirect is a copyright violation, it would seem —Beleg Tâl (talk) 15:24, 10 June 2024 (UTC)

 Support merge/redirect to Template:Hidden text. Even under the hood, these are functionally exactly the same thing. As to the merge target, I prefer the name that offers the more straightforward description. BD2412 T 01:36, 1 June 2024 (UTC)

Yes, I agree that {{Hidden text}} is the better name. —Beleg Tâl (talk) 15:23, 10 June 2024 (UTC)

 Support: seems like the sensible thing to do. Cremastra (talk) 18:23, 19 June 2024 (UTC)

Well, it's been a week since last comment now, and no one appears to have a problem with it, so I suggest we do it. Any objections? If not, I guess I'll just go ahead with it. — Alien333 (what I did & why I did it wrong) 09:03, 19 June 2024 (UTC)

Done: redirected {{Phantom}} to {{Hidden text}}. — Alien333 (what I did & why I did it wrong) 12:37, 20 June 2024 (UTC)

Badge edit error on Wikidata

Tracked in PhabricatorTask T366236

Does anyone here know why badge editing on Wikidata is currently not displaying the image or name of the badge to be selected? Currently I'm only getting the badge's item number when editing. Sample image shown at right. --EncycloPetey (talk) 17:45, 31 May 2024 (UTC)

I can confirm this is happening to me too, so unlikely to be client-side. Phabricator appears to be down atm but I think this should be raised there. —Beleg Tâl (talk) 17:53, 31 May 2024 (UTC)

This is most likely due to T366236, and I'm guessing the fix for it will go out in this week's deployment train (in which case it should hit some time today). --Xover (talk) 09:21, 3 June 2024 (UTC)

Announcing the first Universal Code of Conduct Coordinating Committee

You can find this message translated into additional languages on Meta-wiki. Please help translate to your language

Hello,

The scrutineers have finished reviewing the vote results. We are following up with the results of the first Universal Code of Conduct Coordinating Committee (U4C) election.

We are pleased to announce the following individuals as regional members of the U4C, who will fulfill a two-year term:

• North America (USA and Canada)
  • –
• Northern and Western Europe
  • Ghilt
• Latin America and Caribbean
  • –
• Central and East Europe (CEE)
  • —
• Sub-Saharan Africa
  • –
• Middle East and North Africa
  • Ibrahim.ID
• East, South East Asia and Pacific (ESEAP)
  • 0xDeadbeef
• South Asia
  • –

The following individuals are elected to be community-at-large members of the U4C, fulfilling a one-year term:

• Barkeep49
• Superpes15
• Civvì
• Luke081515
• –
• –
• –
• –

Thank you again to everyone who participated in this process and much appreciation to the candidates for your leadership and dedication to the Wikimedia movement and community.

Over the next few weeks, the U4C will begin meeting and planning the 2024-25 year in supporting the implementation and review of the UCoC and Enforcement Guidelines. Follow their work on Meta-wiki.

On behalf of the UCoC project team,

RamzyM (WMF) 08:15, 3 June 2024 (UTC)

PDF Page:s not loading

I’ve been having this problem on-and-off over the past week or so, and it doesn’t seem to be limited to one computer (I’ve tried other public computers). The Page:s of an Index:….pdf will sometimes load, but then sometimes won’t load, and when they don’t load the “Image” tab will give a “Too Many Requests” error. The actual PDF (on Commons) loads fine. This happens with multiple PDFs. TE(æ)A,ea. (talk) 22:21, 3 June 2024 (UTC)

I am having the same issue, although it seemed better this morning. MarkLSteadman (talk) 23:19, 3 June 2024 (UTC)

• It’s started up for me again yesterday and to-day. I don’t know how to submit technical tickets, but basically trying to load a PDF page in Page: doesn’t work (for a very long time), and fails similarly when viewing the PDF as a File: page-by-page. (Note, however, that the whole PDF loads in fine, without any error.) Trying to look at the resolution-specified pages in File: or the “Image” tab in Page: throws a 429 error. This is the eventual cause; but the error is obvious nonsense, so I’m not sure what’s actually going on behind the scenes. TE(æ)A,ea. (talk) 12:16, 24 June 2024 (UTC)

  Does this happen solely with PDFs? — Alien333 (what I did & why I did it wrong) 12:38, 24 June 2024 (UTC)

  Solely for PDFs for me. Sometimes the zoom or rotate cause the preview image to appear. I also have issues where sometimes the image can not be found for the tesseract OCR even while the page is present in the preview page. MarkLSteadman (talk) 16:30, 24 June 2024 (UTC)

  • Alien333: It’s only PDFs, not DJVUs: so Index:Kojiki by Chamberlain.djvu and Index:Book of St Albans.djvu always work, but Index:Starz Entertainment v. MGM Domestic Television Distribution.pdf and Index:Modern Japanese Stories.pdf suffer. TE(æ)A,ea. (talk) 17:49, 24 June 2024 (UTC)

Tech News: 2024-23

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

Recent changes

• It is now possible for local administrators to add new links to the bottom of the site Tools menu without JavaScript. Documentation is available. [4]
• The message name for the definition of the tracking category of WikiHiero has changed from "MediaWiki:Wikhiero-usage-tracking-category" to "MediaWiki:Wikihiero-usage-tracking-category". [5]
• One new wiki has been created: a Wikipedia in Kadazandusun (w:dtp:) [6]

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 4 June. It will be on non-Wikipedia wikis and some Wikipedias from 5 June. It will be on all wikis from 6 June (calendar). [7][8]

Future changes

• Next week, on wikis with the Vector 2022 skin as the default, logged-out desktop users will be able to choose between different font sizes. The default font size will also be increased for them. This is to make Wikimedia projects easier to read. Learn more.

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

MediaWiki message delivery 22:34, 3 June 2024 (UTC)

Index CSS applying to mediawiki layout

In Index:Eggless recipe book for cakes, cookies, muffins, and desserts.djvu, a table { width:100%; } is causing the index info table to take full width and wrap around.

I think that index CSS should not change the way the site displays, only the content, but is that possible?

For width, it's not that bad, but if someone had something like td { background-color:red; }, it would be a bit more problematic. — Alien333 (what I did & why I did it wrong) 06:39, 8 June 2024 (UTC)

This appears to only apply to ProofreadPage layout, not Mediawiki.

Also, I guess we could just use classes for that instead of targeting elements. — Alien333 (what I did & why I did it wrong) 10:07, 8 June 2024 (UTC)

That's a limitation of the TemplateStyles extension, that the CSS will affect anything in the article (and the index info table is part of the index's article text), which is why one should always give elements one wants to style a class (see guidance at Help:Page styles#Classes_and_IDs). Arcorann (talk) 11:53, 8 June 2024 (UTC)

Yes, I know. (I didn't do that index, just stumbled on it). — Alien333 (what I did & why I did it wrong) 11:55, 8 June 2024 (UTC)

File:Original recipes of good things to eat.djvu

On Commons File:Original recipes of good things to eat.djvu shows as 2,038 × 3,125, 200 pages (16.89 MB) on Commons, but Wikisource shows as 0 × 0 (16.89 MB). I am wondering what is the issue. Xeverything11 (talk) 18:22, 9 June 2024 (UTC)

It's a problem we often have these days, you have to purge it on commons (there's a purge clock gadget to do it).

I did it, it should work now.— Alien333 (what I did & why I did it wrong) 18:47, 9 June 2024 (UTC)

Tech News: 2024-24

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

Recent changes

• The software used to render SVG files has been updated to a new version, fixing many longstanding bugs in SVG rendering. [9]
• The HTML used to render all headings is being changed to improve accessibility. It was changed last week in some skins (Vector legacy and Minerva). Please test gadgets on your wiki on these skins and report any related problems so that they can be resolved before this change is made in Vector-2022. The developers are still considering the introduction of a Gadget API for adding buttons to section titles if that would be helpful to tool creators, and would appreciate any input you have on that.
• The HTML markup used for citations by Parsoid changed last week. In places where Parsoid previously added the mw-reference-text class, Parsoid now also adds the reference-text class for better compatibility with the legacy parser. More details are available. [10]

Problems

• There was a bug with the Content Translation interface that caused the tools menus to appear in the wrong location. This has now been fixed. [11]

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 11 June. It will be on non-Wikipedia wikis and some Wikipedias from 12 June. It will be on all wikis from 13 June (calendar). [12][13]
• The new version of MediaWiki includes another change to the HTML markup used for citations: Parsoid will now generate a <span class="mw-cite-backlink"> wrapper for both named and unnamed references for better compatibility with the legacy parser. Interface administrators should verify that gadgets that interact with citations are compatible with the new markup. More details are available. [14]
• On multilingual wikis that use the <translate> system, there is a feature that shows potentially-outdated translations with a pink background until they are updated or confirmed. From this week, confirming translations will be logged, and there is a new user-right that can be required for confirming translations if the community requests it. [15]

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

MediaWiki message delivery 20:20, 10 June 2024 (UTC)

The final text of the Wikimedia Movement Charter is now on Meta

You can find this message translated into additional languages on Meta-wiki. Please help translate to your language

Hi everyone,

The final text of the Wikimedia Movement Charter is now up on Meta in more than 20 languages for your reading.

What is the Wikimedia Movement Charter?

The Wikimedia Movement Charter is a proposed document to define roles and responsibilities for all the members and entities of the Wikimedia movement, including the creation of a new body – the Global Council – for movement governance.

Join the Wikimedia Movement Charter “Launch Party”

Join the “Launch Party” on June 20, 2024 at 14.00-15.00 UTC (your local time). During this call, we will celebrate the release of the final Charter and present the content of the Charter. Join and learn about the Charter before casting your vote.

Movement Charter ratification vote

Voting will commence on SecurePoll on June 25, 2024 at 00:01 UTC and will conclude on July 9, 2024 at 23:59 UTC. You can read more about the voting process, eligibility criteria, and other details on Meta.

If you have any questions, please leave a comment on the Meta talk page or email the MCDC at mcdc@wikimedia.org.

On behalf of the MCDC,

RamzyM (WMF) 08:45, 11 June 2024 (UTC)

Page status selection fails on change

If I need to change the page status without saving it fails as follows:

Changing Non-proofread to Proofread and then to Problematic or, vice versa, cannot be a simple change. I have to save, close and retry again.

I tried the same steps in fr.Wikisource where it works as it should. I am using Firefox only for such tests. — ineuw (talk) 21:59, 12 June 2024 (UTC)

I'm not sure I understand what your problem is, can you detail, please? — Alien333 (what I did & why I did it wrong) 11:32, 16 June 2024 (UTC)

On changing the page status to Proofread, I preview the results. On seeing an error, I want it to problematic, but the change is not accepted. I must save it as is (Proofread), then reopen it and change it to Problematic. — ineuw (talk) 02:49, 17 June 2024 (UTC)

I am almost sure this is a Firefox browser issue. Don't waste your time on it. I know what to look for it happens again. — ineuw (talk) 04:53, 17 June 2024 (UTC)

Also on Firefox, not having this issue. What OS are you on? — Alien333 (what I did & why I did it wrong) 08:04, 17 June 2024 (UTC)

I am using Linux Mint, but I know the reason. I emptied the formhistory.sqlite and the problem was solved. — ineuw (talk) 08:20, 17 June 2024 (UTC)

Files missing machine-readable data

Hi all,

The categories…

• Category:Files with no machine-readable description (739)
• Category:Files with no machine-readable author (530)

…have a bit of a backlog that it would be nice if the community helped out with. The two overlap so it's not quite as bad as at first glance (889 + 675), but it's still enough that it's a "dip in, do a few" kind of task that's easy work if enough people help out. Xover (talk) 08:47, 16 June 2024 (UTC)

105 of the Files with no machine-readable author are volumes of Blackwood's Magazine. What do we even put as an Author for such volumes? --EncycloPetey (talk) 21:29, 16 June 2024 (UTC)

I would probably simply put "multiple". Or...?

PS. if there are a hundred of them that should all get the same value it's probably better to have a bot add it. Xover (talk) 21:44, 16 June 2024 (UTC)

The same 105 files are also in the other category. Someone who knows what data to add, and can run a bot, could clear those 105 files from both ctageories quickly. --EncycloPetey (talk) 22:45, 16 June 2024 (UTC)

Ok, all the Blackwood's Magazine volumes have now been cleared out of those categories. Xover (talk) 05:29, 17 June 2024 (UTC)

@TE(æ)A,ea., do you still need the images in Category:Millions of Cats images? —CalendulaAsteraceae (talk • contribs) 20:25, 17 June 2024 (UTC)

• CalendulaAsteraceae: Why did you create the category? If none are in use, then no, I believe that they’ve all been extracted. TE(æ)A,ea. (talk) 23:11, 17 June 2024 (UTC)

  @TE(æ)A,ea., thanks for confirming! Unless you object, I'll go ahead and delete the images in Category:Millions of Cats images, since commons:Category:Millions of Cats has cleaner versions. (I created the category because the images all had it anyway, and creating the category makes it easier to process them.) —CalendulaAsteraceae (talk • contribs) 17:41, 18 June 2024 (UTC)

Another sizeable set of images that could be handled by bot are the illustrations to "The House at Pooh Corner (1961)", and whose filenames start with that phrase. The illustrator (author) for these images is E. H. Shepard. --EncycloPetey (talk) 21:31, 17 June 2024 (UTC)

One more bot-suitable task would be setting the author to "multiple" for the DJVUs in Special:PrefixIndex/File:The_Strand_Magazine_(Volume. (The illustrations often have signatures and so should be handled manually.) —CalendulaAsteraceae (talk • contribs) 21:02, 18 June 2024 (UTC)

I've done few, and I thought we could make the Maintenance of the Month for July, since it's easy to step in and fix two or three. Cremastra (talk) 11:55, 20 June 2024 (UTC)

Policy on adding illustrations?

I think I know the answer to this, but since I've had trouble finding an explicit statement anywhere, I thought I might ask. Is it acceptable to add one or more pictures representing a topic to an otherwise unillustrated text? Many texts, especially short ones such as stand-alone poems or newspaper articles, look like they would benefit from an illustration or two, but have none. For instance, an article about an event, or a prominent person who has just died, or some noteworthy achievement. If an appropriate picture or even a range of pictures depicting the person or thing exists on Wikimedia Commons, is it ever appropriate to add such pictures to transcriptions here? Would it make any difference if the caption or alternate text clearly indicated that the illustration was not part of the original text?

I suspect that the answer is probably "no, we don't do that here", although I certainly think it would be desirable for there to be some circumstance in which adding pictures would be acceptable. Obviously this practice is typical in Wikipedia, but also sometimes on Wiktionary, and usually on Wikiquote; author listings on Wikisource usually take a portrait from Wikidata, and there would probably be no objection to additional pictures in long entries, since author listings are understood not to be transcribed texts themselves. So, is my first impression correct, or is there a firm policy on this issue? P Aculeius (talk) 11:01, 17 June 2024 (UTC)

As you suspect, adding illustrations to texts is not permitted. Specifically, the policy WS:ANN states: "The following are currently banned on Wikisource: [...] Purely decorative illustrations and images. (Known as grangerisation or extra-illustration)".

What I would recommend, where possible and if you are willing, is to try and find an illustrated published edition of the text you are interested in, which you can then upload along with the illustrations that were originally published with it. This would be especially helpful for texts that are not currently backed by a scan. —Beleg Tâl (talk) 13:21, 17 June 2024 (UTC)

I also want to add that this applies to transcribed works themselves. As you have noted, images are routinely added to Author and Portal pages. I also personally like to add images to Versions and Translations pages where applicable. —Beleg Tâl (talk) 13:24, 17 June 2024 (UTC)

What images of the original text should be uploaded for a newspaper article?

So I'd like to transcribe some old articles from newspapers—say the New York Times. I see a variety of different methods being employed, from whole issues apparently being available to transcriptions not backed up with any images. Suppose I just want to transcribe one article appearing on one page, or perhaps across two pages. What is the best procedure to follow? Should I: A) upload the entire issue of the Times (234 pages) to Commons, B) upload just the section in which the article occurs (12 pages), C) upload just the page(s) containing the article, D) upload just images of the article text, cropped from the rest of the items, or E) something else?

I note that the full issue is available at Internet Archive, but our help page on Internet Archive speaks of uploading .djvu files, which it also says are no longer being produced by IA—I don't see a clear explanation of what to do for materials for which there is no djvu file. And lastly, the images are from a microfilm, in negative. I know how to process images myself to create a positive, but I don't want to download a high resolution scan of 234 newspaper pages just to transcribe one article! For text it may not matter that the image is a negative, but when pictures are included a positive would be greatly preferable. P Aculeius (talk) 15:48, 17 June 2024 (UTC)

A). We prefer having whole works than only parts of them (and regarding not backed up texts, we tend to not avoid these nowadays).

You'll rarely, if ever, find a djvu file on IA, but there is nearly always a PDF, and there are many tools, of which I think this is the best, to convert PDF files to DjVu. — Alien333 (what I did & why I did it wrong) 15:56, 17 June 2024 (UTC)

The main page for The New York Times says, "Most of the work on The New York Times is on individual articles", and I can see why. Formatting and transcribing the column I wanted to make available took around half an hour. Downloading the whole issue from Internet Archive took an hour and fifteen minutes, and the resulting PDF file was 872.9 MB, far larger than any file I would have chosen to download. Uploading the file to PDF2DJVU only took thirty-six minutes, and it began converting automatically. But nearly five hours later, it's still not done, and I've never received any update on its progress, or whether it's actually doing anything. I'm afraid to do anything that might interrupt it, in case it ever finishes.

If it does, then the best result I can hope for will still be a negative. I was unable to invert the pdf file before uploading to PDF2DJVU, though inverting individual pages might have worked if they'd been separate. But I don't want to spend all evening inverting 234 pages and then trying to combine them back into a single document—something I doubt I would be able to do easily. And if I successfully uploaded the finished document, it'd be suboptimal in appearance, noticeably different from all other media of its kind, and virtually none of it would ever be transcribed—most other issues that have been partly uploaded have only a handful of articles transcribed, and nothing else. Few have index pages, and those that do show almost nothing proofread or validated.

I considered trying to upload the PDF to Wikimedia Commons, on the understanding that files bigger than 1 GB are hosted, though it says that at 1 GB PDF's can start to cause issues. 872.9 MB might have squeezed in under the limit. But all of the other issues uploaded were on the order of 1/10 that size; some of that might be the .djvu format, but at the same time almost all of them are from 1900, and state in the masthead that the issue is "sixteen pages" (plus magazine, in some instances). At this point it seems unrealistic to upload the issue in question, at 234 pages, even if I can ever get a finished djvu from PDF2DJVU, which seems unlikely. The time and effort involved just for the sake of transcribing a single column probably explains why we have relatively little content from The New York Times. P Aculeius (talk) 01:15, 18 June 2024 (UTC)

• P Aculeius: Our general practice is to have an entire published unit—a whole book, or a volume or an issue of a periodical—for various reasons which generally relate to cataloging and copyright principles. Newspapers, however, are a major problem in this regard, as there is often a great amount of content unrelated to the actually valuable portion. As an example, I have been working recently on scan-backing a collection of the works of Louisa May Alcott which were recently discovered. Several of these were from newspapers; in all cases I have obtained the entire issue. For just one issue of a magazine—eight pages only—and ignoring most of the advertisements—it took me four months of on-and-off work to finish. Of the different options you listed above, (A) is technically correct, though rarely actually employed (e.g. here and others listed therein, and another of my works here), but (D) is the most common (e.g., here) and (E) is common historically (although now officially disfavored) (e.g., here). Another practice, of which I do not personally approve, is to upload a scan with each column as a separate page—although this is also usually done at the issue level (e.g., here). As for conversions, it is probably best to either use the PDF without DJVU conversion or to download DjVuLibre and run the conversions locally. TE(æ)A,ea. (talk) 02:22, 18 June 2024 (UTC)

  It looks as though the size of the file was the issue. Most other sites promising the conversion of PDF to djvu indicated that files should be smaller than 50, 100, or 200 MB; some suggested that larger files could be converted with a paid subscription. PDF2DJVU did not mention a size limit, but it did not seem to be able to finish the process on a second attempt either. Finally I found this site, and was encouraged by the presence of a "donate" button, suggesting that it was non-commercial, and no size limit was mentioned. It worked! I just had to wade through a couple of dozen others before finding it. So the issue is now uploaded to Commons, though I don't think I'll be adding any more Sunday editions in the near future...

  I should probably make an index page, though the prospect of naming the pages of the different sections of a newspaper seems daunting. Before I was able to produce a djvu, I did upload and add a positive scan of the specific article from a different source (where I could not have obtained the full issue as a single document), though I didn't create an index page for it, as I thought the whole issue might still be possible (and it was). Should it also have an index page? P Aculeius (talk) 14:06, 18 June 2024 (UTC)

  • P Aculeius: You should probably have the old file deleted, now that you have the entire issue available. TE(æ)A,ea. (talk) 14:57, 18 June 2024 (UTC)

Tech News: 2024-25

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

Recent changes

• People who attempt to add an external link in the visual editor will now receive immediate feedback if they attempt to link to a domain that a project has decided to block. Please see Edit check for more details. [16]
• The new Community Configuration extension is available on Test Wikipedia. This extension allows communities to customize specific features to meet their local needs. Currently only Growth features are configurable, but the extension will support other Community Configuration use cases in the future. [17][18]
• The dark mode beta feature is now available on category and help pages, as well as more special pages. There may be contrast issues. Please report bugs on the project talk page. [19]

Problems

• Cloud Services tools were not available for 25 minutes last week. This was caused by a faulty hardware cable in the data center. [20]
• Last week, styling updates were made to the Vector 2022 skin. This caused unforeseen issues with templates, hatnotes, and images. Changes to templates and hatnotes were reverted. Most issues with images were fixed. If you still see any, report them here. [21]

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 18 June. It will be on non-Wikipedia wikis and some Wikipedias from 19 June. It will be on all wikis from 20 June (calendar). [22][23]
• Starting June 18, the Reference Edit Check will be deployed to a new set of Wikipedias. This feature is intended to help newcomers and to assist edit-patrollers by inviting people who are adding new content to a Wikipedia article to add a citation when they do not do so themselves. During a test at 11 wikis, the number of citations added more than doubled when Reference Check was shown to people. Reference Check is community configurable. [24]
• Mailing lists will be unavailable for roughly two hours on Tuesday 10:00–12:00 UTC. This is to enable migration to a new server and upgrade its software. [25]

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

MediaWiki message delivery 23:48, 17 June 2024 (UTC)

"Invalid interval" error on creating page index; unable to create pagelist for the source file

I've tried to create indexes for two works, carefully following all of the instructions, but I keep getting these errors that prevent me from working on either of them. I did find the explanation on the help page that said that the "invalid interval" error has been happening since earlier this year. It mentions a workaround: purging the caches for the source files on Wikimedia Commons. But I've done that multiple times, and nothing has changed. The index pages I created also show a prominent warning about the need to creating a pagelist, but despite following the instructions to the best of my ability, and following the examples in other, working index pages, nothing changes. I can see a list of other works that have the same problem, at least one of which has been in index purgatory since February. I can't see anything wrong with its pagelist, either. What am I doing wrong? Is there a solution? I can't express how frustrating it is to have to abandon projects almost as soon as they're begun. P Aculeius (talk) 03:10, 19 June 2024 (UTC)

You need to purge the file at commons (simplest way is with one of the gadgets that do that, such as the purge clock).

Sometimes, you may also need to purge the index here after purging the file.

Since the server switch a few months ago, it happens sometimes.

Note that we're not sure that purging the file works, it did in most cases but maybe not always.

I purged the two files you worked on most recently, they work now.

As for the "need to create a pagelist" warnings, you need to remove them manually by changing in the index page to "to be proofread" once you've got a pagelist. — Alien333 (what I did & why I did it wrong) 07:14, 19 June 2024 (UTC)

Thank you for fixing the two "invalid interval" errors for me. Purging the files here or on Wikimedia Commons did not work for me. Could that indicate that the method of purging is involved? I have an older computer with an older browser that can no longer be updated. In any case, I was able to fix the pagelist issue thanks to your explanation. Thank you again! P Aculeius (talk) 12:42, 19 June 2024 (UTC)

For purging (the cache), you can either go to https://commons.wikimedia.org/w/index.php?title=(filename)&action=purge, or use one of the gadgets that provide a quick link to that from the file page. If it did not work for you, it might have been because you did not purge the index after, as it needs to be updated too. — Alien333 (what I did & why I did it wrong) 13:43, 19 June 2024 (UTC)

King James Version of the Bible

I saw this page: Bible (King James Version, 1611). I believe the King James Version of the Bible is in the public domain, so it can be freely shared on Wikisource. Why are so many books of the Bible missing (red links)? The Bible is probably the most widely read book in world history and I believe the KJV is the best known English translation. It seems like these could just be copied from some other online source. 2601:644:907E:A450:DC8E:E069:FAA3:40C5 17:48, 20 June 2024 (UTC)

This is just one of the editions of the KJV bible, another one, Bible (King James), is finished, although not sourced, so no one gave time to do another edition.

Also, we could copy it from other sources, but here we try to stick as close to the source text as possible, meaning not modernizing spelling and other things.

This means that we do not take second-hand transcriptions anymore, such as from Project Gutenberg, because they often make changes to the text. — Alien333 (what I did & why I did it wrong) 20:23, 20 June 2024 (UTC)

older books don't work well with OCR, has woodcuts, and are not a priority. although as OCR improves it is easier. we don't add any value by copy pasting websites. the value is transcribing and linking to ground truth scans. --Slowking4 ‽ digitaleffie's ghost 23:36, 21 June 2024 (UTC)

Community collaboration

Hey Oh! (Yup, I'm still here kind of, dropped by and decided to poke around and do a couple things, maybe I'll stay a while <shrug>)

A couple issues seem to be converging here.

1. Wikisource:Community collaboration is kind of dead. Nobody has commented (until me today) since January 2021. The last substantive change to the collab posted to Template:CotW was in March 2021 to put Portal:Eminent Women Series back up again, which was first put up in 2017 and replaced with three other projects for less than a year each.

2. Coincidentally, in May 2021, the community collaboration was removed from Template:Collaboration and replaced with Monthly challenge, apparently due to a misunderstanding of what CotW was for (it's neither a Collaboration/Challenge of the Week nor of the Month). This occurred with no apparent discussion.

I say coincidentally, because, the Community Collaboration is now really only advertised in Welcome messages. Community Collaboration was always intended for long term projects involving a lot of research and other work. I think it should go back into Template:Collaboration so that it shows up on the main page. I could easily fix this; however, there is no recent nor meaningful discussion as to what should be on it now. Also, there is a cumbersome process of updating templates that are included in other templates that seems less than ideal. We should have a way for the template to grab the source without having to edit multiple templates. Additionally, Template:Collaboration/COTW is protected with hardcoded text about it being for proofreading a text, which is never what the community collaboration was for. Template:CotW/base contradicts this but is only slightly better, it is protected and hardcoded for collecting works related to the project. The latter is more likely to be true to the purpose of Community Collaboration but not entirely.

So, I ask that

a) Template:Collaboration/COTW be unprotected, it's not even currently used and I'd like to do some interim tweaks to it with an eye towards at least restoring it to the main page. Done

b) Template:CotW/base be unprotected, it's used in a template that is barely used and I'd like to tweak it further. Done

c) We toss around some suggestions on a better way of getting data from the various "of the month" type collabs to the main page other than a series of 3 or 4 nested templates.

d) We have a discussion about the future of Community Collaboration. I think it has value, but it has to be advertised and considered in its context.

I'm willing to do some basic maintenance on these to get them into shape and participate in discussions on concept/content, but I will need help from someone with a bit. Honestly, there's a ton of restructuring we might consider (like community collab should be a kind of portal with several subpages/links to all the collabs) but I think we need to start small with just a few fixes and I can come back with some more suggestions later. If y'all want to dive into a big rethink of the structure of all this now, I probably don't have time for that and y'all can have fun. DeirdreAnne^{(talk • contribs)} 19:56, 23 June 2024 (UTC)

I've unprotected the two templates for you to tweak. Let me know when to re-protect them. Beeswaxcandle (talk) 22:07, 23 June 2024 (UTC)

Thanks! DeirdreAnne^{(talk • contribs)} 23:22, 23 June 2024 (UTC)

Beeswaxcandle, could you also unprotect Wikisource_talk:Community_collaboration/2007 please, there's an unarchived discussion on Wikisource_talk:Community_collaboration from that year for some reason and I can't archive it.--DeirdreAnne^{(talk • contribs)} 01:43, 24 June 2024 (UTC)

Done Beeswaxcandle (talk) 06:38, 24 June 2024 (UTC)

(Interesting, it looks like the last time I posted on Scriptorium was December, 2013! DeirdreAnne^{(talk • contribs)} 20:01, 23 June 2024 (UTC))

Question from someone who wasn't around last time this was active: Are you sure it's not a proofreading issue? I mean, the page does say Projects typically involve [...] finding and adding relevant texts. What does that mean if not proofreading, and more generally, what would you make of it? — Alien333 (what I did & why I did it wrong) 09:53, 24 June 2024 (UTC)

• DeirdreAnne: By the way, your signature is broken: it looks for contributions by Deirdreanne. TE(æ)A,ea. (talk) 12:11, 24 June 2024 (UTC)

Tech News: 2024-26

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

Recent changes

• Editors will notice that there have been some changes to the background color of text in the diff view, and the color of the byte-change numbers, last week. These changes are intended to make text more readable in both light mode and dark mode, and are part of a larger effort to increase accessibility. You can share your comments or questions on the project talkpage. [26]
• The text colors that are used for visited-links, hovered-links, and active-links, were also slightly changed last week to improve their accessibility in both light mode and dark mode. [27]

Problems

• You can copy permanent links to talk page comments by clicking on a comment's timestamp. This feature did not always work when the topic title was very long and the link was used as a wikitext link. This has been fixed. Thanks to Lofhi for submitting the bug. [28]

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 25 June. It will be on non-Wikipedia wikis and some Wikipedias from 26 June. It will be on all wikis from 27 June (calendar). [29][30]
• Starting 26 June, all talk pages messages' timestamps will become a link at English Wikipedia, making this feature available for you to use at all wikis. This link is a permanent link to the comment. It allows users to find the comment they were linked to, even if this comment has since been moved elsewhere. You can read more about this feature on Diff or on Mediawiki.org. [31]

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

MediaWiki message delivery 22:32, 24 June 2024 (UTC)

Voting to ratify the Wikimedia Movement Charter is now open – cast your vote

You can find this message translated into additional languages on Meta-wiki. Please help translate to your language

Hello everyone,

The voting to ratify the Wikimedia Movement Charter is now open. The Wikimedia Movement Charter is a document to define roles and responsibilities for all the members and entities of the Wikimedia movement, including the creation of a new body – the Global Council – for movement governance.

The final version of the Wikimedia Movement Charter is available on Meta in different languages and attached here in PDF format for your reading.

Voting commenced on SecurePoll on June 25, 2024 at 00:01 UTC and will conclude on July 9, 2024 at 23:59 UTC. Please read more on the voter information and eligibility details.

After reading the Charter, please vote here and share this note further.

If you have any questions about the ratification vote, please contact the Charter Electoral Commission at cec@wikimedia.org.

On behalf of the CEC,

RamzyM (WMF) 10:52, 25 June 2024 (UTC)

Invitation to join June Wikisource Community Meeting

Hello fellow Wikisource enthusiasts!

We're excited to announce our upcoming Wikisource Community meeting, scheduled for 29 June 2024, 7 AM UTC (check your local time). As always, your participation is crucial to the success of our community discussions.

Similar to previous meetings, the agenda will be split into two segments. The first half will cover non-technical updates, such as events, conferences, proofread-a-thons, and collaborations. In the second half, we'll dive into technical updates and discussions, addressing key challenges faced by Wikisource communities.

Simply follow the link below to secure your spot and engage with fellow Wikisource enthusiasts:

Event Registration Page

Agenda Suggestions: Your input matters! Feel free to suggest any additional topics you'd like to see included in the agenda.

If you have any suggestions or would just prefer being added to the meeting the old way, simply drop a message on sgill@wikimedia.org.

Thank you for your continued dedication to Wikisource. We look forward to your active participation in our upcoming meeting.

Regards,

KLawal-WMF, Sam Wilson (WMF), and Satdeep Gill (WMF)

Sent using MediaWiki message delivery (talk) 17:17, 26 June 2024 (UTC)