User talk:Xover

Policy reform proposals

I'm pretty tired of the vague and terribly written policies we have... Since I know you've voiced adamant concern as well, I wanted to bring it up with you. I want to know your opinion on how we should exactly start to make reforms. I can see a couple of issues.

1. The awful wording and lack of specificity of a lot of our existing policies, such as those at WS:WWI. Some of what's said here is said in a single sentence, with conditional platitudes, when really the exceptions should be extrapolated on. For example, we should elaborate on a consistent definition of "text" to use in our policies, because "text" has many different definitions. And "work", "text", and "edition" are often used interchangeably to one another in our discourse (which I admit to doing sometimes myself).
2. Our help pages, and other pages that aren't strictly policy, are often cited as if their policy, meaning that as I think you said something along the lines of before, the differences between our namespaces aren't quite clear and pronounced enough. Maybe we should consider merging some of our help pages into policy so that there are clearer expectations for users, and so we don't have to constantly forget whether something was a policy or just a bit of advice from the Help page. (And IMO, a lot of our help pages contain advices that really ought to be policy.)
3. Our community culture, being quite anarchical and individualistic in nature especially in terms of certain stylistic or structural preferences, encourages a laissez-faire approach to policy application. And while I do think this culture has some merits it also leads to people selectively caring about certain policies and not as much for others. I think we're all guilty of this to some degree to be honest... So how can we determine how far we want laissez-faire to go? It's not entirely clear... And here I am getting into disagreements still because of this very mentality being inconsistently applied.
4. I do believe that we should, at the end of the day, care far more about the integrity of the site than any of its policies, and should be able to override a policy on the fly if it means improving user experience in a meaningful way for example. So it might be beneficial to include something similar to Ignore all rules in our policy documentation.

These are just some casual brainstorms. I was wondering if you gave policy reform any thought recently, and I would be interested in collaborating with you on some proposals, and/or gathering together other collaborators on it. Maybe we can make a WikiProject out of it. SnowyCinema (talk) 01:24, 28 February 2024 (UTC)

Lurker butting in: I'm interested in improving this situation too, and would like to find a way that makes things better without being too jarring. Feel free to nudge me if you get something going. -Pete (talk) 07:09, 28 February 2024 (UTC)

Thanks Pete. Yeah, I agree with that: make things better without being too jarring. Xover (talk) 08:03, 3 March 2024 (UTC)

@SnowyCinema: Sorry for the tardy reply. IRL is kicking my behind lately so anything requiring sustained attention is challenging.

Yes, I agree with all your main points (but reserve the right to disagree on some particulars). We need to improve our policy game, and because we have a lot of years of relative neglect to compensate for, that's going to take time (marathon, not a sprint). And the biggest challenge is that the community is in general not that interested in policy work, and significant subsets view policies as inconveniences and with outright suspicion. No policy reform is going to be successful if we cannot engage the majority of the community in it, and in a way that they at least feel heard if they disagree with the majority opinion on some point. There is also a major major risk in that relative anarchy has reigned for decades, attracting contributors that may hold views of what the site should be that are diametrically opposed and on the extreme ends of whatever spectrum. The only way to satisfy both will be to make policy more general, not more specific, and being specific will have a high risk of driving one side of that issue away.

What I'm trying to say is this will need tact, diplomacy, respect for all viewpoints, and sustained effort over time. Xover (talk) 08:02, 3 March 2024 (UTC)

Using mw.language.fetchLanguageNames in Module:ISO 639

I've been considering making Module:ISO 639 get language names from mw.language.fetchLanguageNames where possible. Does that seem like a good idea to you, and does the implementation in Module:ISO 639/sandbox look like a reasonable way to do it? —CalendulaAsteraceae (talk • contribs) 02:54, 16 March 2024 (UTC)

@CalendulaAsteraceae: Why does Module:ISO 639/local contain north of 8k language mappings? How many of these are actually used here? How many are likely to ever be used? How many of these (micro)languages even have a written language? Remember that these all get loaded into the hard-limited memory for every invocation of the module, whether they are used or not. Why do we need language codes that MediaWiki doesn't support anyway? We can't get web font support for them, or other software features, so why jump through hoops to just recognize them only on enWS?

Why do we need separate data tables for "local" names and "override" names? Why not simply let local names override upstream names and solve both in one lookup table? That also makes the logic more explicit: right now an "override" is supposed to only override upstream names, but the implementation also overrides local names and local names override upstream names even though they're apparently not supposed to. Having only two sources would make this logic and the code clearer.

Why would you fetch all language names, copy them into a table in your heap, and then look up a single code in it; instead of just looking the code up directly with mw.language.fetchLanguageName(code, 'en')?

Why are you lazy-loading Module:Arguments only in p.ISO_639_name? You're loading 8k of config, so loading Module:Arguments doesn't even show up in the performance profile. And in general, this kind of thing is premature optimization absent a specific real case where it is needed. Just stuff module loads up top where they're expected and simplify the code further down.

You're using Module:Error to handle what is a completely normal and expected situation: a missing argument value. Module:Error throws a low-level exception and unconditionally puts the page into a platform-provided tracking category. Its useful role is to signal that something catastrophic and exceptional has happened and technical admins need to step in immediately. What you're actually dealing with there is a warning to the end user that they have failed to provide some input, and if they do not fix it they will probably not get the result they wanted. It's the difference between "FIRE!" and "Excuse me, sir, I'm sorry to bother you but…". For this use case use Module:Warning, with a tracking category the community can use to fix backlogs if needed, possibly supplemented with Module:If preview to give users an early heads-up before saving.

That all aside, the approach as such seems good, and a definite improvement over the current implementation. I don't have a lot of experience with the Scribunto Language library so I can't give you any specific advice on it, but in general terms it's always better to use upstream functionality wherever possible. Less work for us to maintain, and we can take advantage of upstream improvements, stuff that breaks can be fixed once for everyone that uses it, and so forth. Xover (talk) 09:07, 16 March 2024 (UTC)

Thank you! I've adjusted the code to load Module:Arguments at the top, only load the specific MW language name needed, and use Module:Warning instead of Module:Error.

The reason Module:ISO 639/local contains 8k+ language mappings is that I was getting tired of adding mappings ad-hoc when works showed up in Category:Index pages of works originally in an unknown language. The memory issue is why there are separate "local" and "override" names (I've now made the code only load the local names if needed). I could be argued into merging Module:ISO 639/local and Module:ISO 639/overrides and only loading the names that are actually in use, but my main goal was to reduce maintenance. —CalendulaAsteraceae (talk • contribs) 02:11, 17 March 2024 (UTC)

@SnowyCinema, CalendulaAsteraceae: Try Module:ISO 639/sandbox (specifically 13974731). —Uzume (talk) 07:46, 17 March 2024 (UTC)

Thanks, but that's just the same as hard-coding "en". mw.language.getContentLanguage() returns the wiki's content language, which is hard-coded in LocalSettings.php as English. Xover (talk) 08:05, 17 March 2024 (UTC)

@CalendulaAsteraceae: Module:ISO 639 currently has three entry-points: ISO_639_name() for templates, _ISO_639_name() for other modules, and language_name(). But the latter is not designed as an entry-point in that it does no sanity checking of its inputs. In other words, it is designed as a private function that relies on its calling context to take care of sanity checking and error handling. When Module:Header calls language_name() it bypasses all of the error checking from _ISO_639_name().

In terms of API design, you want to reduce the number of entry points as much as possible so that you reduce the number of places you have to check inputs and to simplify the code in non-entry-point code. You also want to make private functions explicitly private so that clients can see clearly what functions they should not call directly. In a Scribunto context that means making private functions local and not part of the export table (p, the table you return at the end of the module). You can go further and name them with a _ prefix too, but that's not particularly common in Scribunto modules for whatever reason (I sometimes do that anyway, but it's not idiomatic).

If you want to make utility functions available for specialized cases you need to be very explicit about the contract: it is the client's responsibility to ensure valid arguments are passed in. You'll also need to start using stuff like pcall() and try/catch to avoid the standard libraries blowing up. And in this scenario, it also effectively means we'll have to include all the client modules (i.e. Module:Header and all its clients) in the testing matrix any time we make a change.

In this particular case I don't see why Module:Header can't call us through _ISO_639_name() so we can reduce the API surface in Module:ISO 639 to just ISO_639_name() and _ISO_639_name() (and isolate the error checking in the latter). In addition, at a quick glance it looks like while Module:Header calls Module:ISO 639 unconditionally, it is only {{translation header}} that actually uses the name. So we get the overhead for every single page that uses {{header}}, {{process header}}, etc. even if we don't need it there; and errors like this blow up the whole site instead of just a subset of pages isolated to one namespace. Xover (talk) 08:42, 17 March 2024 (UTC)

Pointers for CSS use

I randomly saw that you've been doing some work on https://en.wikisource.org/wiki/Index:Works_of_Sir_John_Suckling.djvu moving the TOC formatting to a stylesheet. I wonder if you have any tips on how I could do something similar for the index to The Strand Magazine? I haven't done anything with CSS for a while, and it would be good to move the formatting away from lots of repetition of the ts template. See Index:The Strand Magazine (Volume 3).djvu for my 'current' (i.e. 12 months ago!) style. Qq1122qq (talk) 13:43, 1 April 2024 (UTC)

@Qq1122qq: There are some tips / tutorial stuff in Help:Page styles. And feel free to ask for help here. It turns out a large proportion of tables of contents are remarkably regular so the reuse potential is pretty good. Xover (talk) 14:05, 1 April 2024 (UTC)

Thank you for the pointer - that looks like a very useful page. Qq1122qq (talk) 14:26, 1 April 2024 (UTC)

@Qq1122qq: Oh, one thing that might be worth keeping in mind… For a multi-volume work it's possible to create redirects from the style pages for vol. 2+ to the style page for vol. 1 so that you get consistent formatting throughout. This sadly requires admin permissions to set up, but do feel free to grab me if you need that. Xover (talk) 16:48, 1 April 2024 (UTC)

A loose end

Hi Xover, I just re-read your comment here, more closely than I did the first time. It seems like my comments came off as hostile or uncooperative, and I can see in hindsight how they would give that impression. I just want to assure you that wasn't my intent. I appreciate the efforts you make to keep things going here. In your comment, you stated that "process stuff matters." My purpose in each of the comments of the discussion was to learn the correct process. With your close, I did finally get the answer I had been seeking, and I specifically appreciate you spelling it out. I didn't intend to cause frustration, and I could have been clearer in my questions and comments. Sorry if I added stress. Pete (talk) 13:18, 2 April 2024 (UTC)

@Peteforsyth: You linked [[Special:Diff|here]], and not a specific diff. SnowyCinema (talk) 13:23, 2 April 2024 (UTC)

@SnowyCinema: Ugh. Fixed now, thanks. -Pete (talk) 13:26, 2 April 2024 (UTC)

@Peteforsyth: If you felt you needed to come here and apologise for something then the most reasonable explanation is that I've expressed myself poorly, given the wrong impression, it's my bad, and I am the one who should apologise. There may be issues on which you and I disagree to such a degree that the tearing out of one's own hair may be an apposite analogy, but I have yet to see any instance where you had any actual cause to apologise for anything. As for the specific comment you linked… Assume I was trying to apologise for dropping the ball on closing the referenced copyright discussion (this one), explaining ways you could nudge things along in such situations (never hesitate to ping me: if I've dropped the ball I appreciate reminders so I can fix it), and why I was being kinda bureaucratic on the process stuff. None of it was intended to express any form of critique, frustration, or similar. Quite the contrary. Xover (talk) 14:01, 2 April 2024 (UTC)

Template Rationalisations

These were some temporary migrations - https://en.wikisource.org/w/index.php?title=Special:WhatLinksHere/Template:Table_class/import&limit=500 , Ultimately this template should be removed entirely, as should {{numbered div}} and related. ShakespeareFan00 (talk) 10:08, 3 April 2024 (UTC)

Thanks for letting me know. Yes, {{table class/import}} in its current form should probably not be used. It's possible some ideas from it can be reused for some other use cases though, it depends on what needs are discovered when the more straightforward cases are dealt with. I'll keep it in mind. Xover (talk) 10:11, 3 April 2024 (UTC)

I've been workiing on deprecating valign but I need to take a break. ShakespeareFan00 (talk) 20:31, 3 April 2024 (UTC)

Unclosed DIV's

Any chance of clearing up some of these?

https://en.wikisource.org/wiki/Special:LintErrors/missing-end-tag?wpNamespaceRestrictions=8&titlecategorysearch=&exactmatch=1&tag=all&template=all

https://en.wikisource.org/wiki/Special:LintErrors/missing-end-tag?wpNamespaceRestrictions=1%0D%0A4%0D%0A5%0D%0A6%0D%0A7%0D%0A0%0D%0A10%0D%0A11%0D%0A12%0D%0A13%0D%0A14%0D%0A15%0D%0A100%0D%0A101%0D%0A102%0D%0A103%0D%0A106%0D%0A107%0D%0A114%0D%0A115%0D%0A710%0D%0A711%0D%0A828%0D%0A829%0D%0A104%0D%0A105&titlecategorysearch=&exactmatch=1&tag=div&template=all

I lack the clout/bits to resolve these ( some of which it might not be possible to repair.) ShakespeareFan00 (talk) 10:42, 5 April 2024 (UTC)

Unclosed span

https://en.wikisource.org/w/index.php?title=Wikisource:Scriptorium/Archives/2020-12&action=edit&lintid=1610524

Typo? ShakespeareFan00 (talk) 10:51, 5 April 2024 (UTC)

Probably. I just threw a /span in there in any case. Xover (talk) 12:01, 5 April 2024 (UTC)

Style rationalisations?

https://en.wikisource.org/w/index.php?search=insource%3A%2Fheadertemplate%2F&title=Special:Search&profile=advanced&fulltext=1&ns0=1&ns1=1&ns2=1&ns3=1&ns4=1&ns5=1&ns6=1&ns7=1&ns8=1&ns9=1&ns10=1&ns11=1&ns12=1&ns13=1&ns14=1&ns15=1&ns100=1&ns101=1&ns102=1&ns103=1&ns104=1&ns105=1&ns106=1&ns107=1&ns114=1&ns115=1&ns710=1&ns711=1&ns828=1&ns829=1&searchToken=5szr1s6lvq2qxyqc6iupa06jh

I've cleared some of the backlog but wanted someone to review..}ShakespeareFan00 (talk) 17:45, 6 April 2024 (UTC)

@ShakespeareFan00: I appreciate your willingness to help, but you've got to stop diving in immediately. I am still working on this, the template isn't done yet, and it's still not certain that it's a workable solution. The effect of you jumping in now—even though that was obviously not your intent—is that my job becomes much more difficult. I get edit conflicts because you've changed pages while I was working on them, trying to get the template to support that use case. You've changed a lot of pages that I otherwise had in my todo list to check for whether the template could work for them, and now I have to find a different way to identify them. And since the reason I hadn't converted them yet was that I wasn't sure yet that it would work there, it means I have to go back and check the pages you edited too.

Please don't take this the wrong way: I very much appreciate all your efforts in general, and your willingness to help out with projects like this. But please don't just jump in to these projects like this. Stop to think about whether you helping out in a given case might end up being a "bull in a china shop" type situation. If you're not sure, it's never wrong to ask before you go wading in. One person working on something alone can keep track of things on their own; but the second you have two or more people involved it is necessary to coordinate.

So, please don't do anything else related to this just now (most especially do not start reverting any of your changes!). Once I am confident this template can be used reliably, if there is still more work to do, I will let you know and tell you what would be most helpful. Xover (talk) 19:07, 6 April 2024 (UTC)

I have other projects so I should not conflict with your efforts now you have asked me not to.

Is the intent to clean out relevant Site.CSS entirely? ShakespeareFan00 (talk) 19:19, 6 April 2024 (UTC)

@ShakespeareFan00: Not completely empty, no. But I want to pare down the number of default Gadgets (each one adds to the size of the startup manifest), and I want to reduce the size of each default Gadget as much as possible, because we pay the cost of these on every single page load. And as it happens this coincides well with the need to find better solutions for some things that are currently global CSS classes. Xover (talk) 19:23, 6 April 2024 (UTC)

Redirected Stylesheet...

A_Dictionary_of_Music_and_Musicians/Lord_of_the_Isles,_The

Did someone forget to change the content model back? ShakespeareFan00 (talk) 20:04, 6 April 2024 (UTC)

@ShakespeareFan00: No, just a race condition: the page was reparsed into cache in the middle of setting up the stylesheet redirects, and hadn't been updated after. A null edit or page purge should fix it. Xover (talk) 20:15, 6 April 2024 (UTC)

Delinting - A strategy..

I'm currently working to remove unmatched <I> in Page: namespace typically resulting from OCR. The objective is to eventually allow for automated conversion of <I>...</I> to '' ... '' or some equivalent {{italic}} template, where needed ShakespeareFan00 (talk) 10:34, 7 April 2024 (UTC) Would you be willing to consider semi-automated conversion of <U>...</U><B>...</B><I>...</I> and <HR>...</HR> tags in content namespaces, once the effort to contain the mismatched ones is completed? ShakespeareFan00 (talk) 10:34, 7 April 2024 (UTC)

I plan to look at those eventually, mainly due to raw HR being problematic. Whether we actually want to convert B and I is less certain. It depends on how and where they are used. These two are somewhat special and it is entirely possible that we may end up just letting them stay, or possibly make some guidelines for when it is appropriate to use them. Xover (talk) 10:38, 7 April 2024 (UTC)

For some simple unmatched examples of <I> in raw:-

• https://public-paws.wmcloud.org/4407/i_pair
• https://public-paws.wmcloud.org/4407/i_space

ShakespeareFan00 (talk) 12:27, 7 April 2024 (UTC)

More stylesheets

There is a lot of rant about my stylesheets becoming "unhooked" from the text I was working on before I was finished.

There is less but more intense rants about basic templates not working, meaning in this case, not displaying for me.

There is a way in my browser that I can see that I have never visited the stylesheet page, but I don't want it to "get fixed" because appearances are deceiving.

Now all of my scripting is doing the exact same thing. The debugging output file stops updating.

Sorry about the rant; but the problems are problems.

Having style problems when I log into worldcat also, but that should not be ranted about here, I suppose.

thoughts about stylesheet migration

The SFan table style guru needs to make canned styles of common combinations, like do-re-mi when they see it on the page. If the table styled page has a three note call that gets used in all of tables for one magazine style then put them together and call it {{ss:do-re-mi}} which then can be expanded and moved (backwards, as it is) into the Main as {{ss:doe-sun-myself}} only using css names not musical theater names, or a be predetermined style collection whose structure is to be considered and determined later.

Build backward. Get another issue of the Journal of Optical and release the tables from the styles used by moving them to the style sheets with the same notation. Get a three note band together for making tables. The Kinks only used two notes very often!! The multi-personalitied SFan is the King of tables here. That two key shorthand for style is very very appealing. Builders and typists. Let the typists build backwards, it is easy, they can do it. The builders show them how to do it and they reassemble backwards built parts into good order; assuring the typists that it will still be the same amount of fun to use.

This should be fun and right now is not fun for me. The not completing things because weird and wrong software problems are occurring is more not fun than discovering the weird and wrong software problems.

final rant

Leave atlantic monthly alone for me to finish. Please. None of that moving the pages around crap like got done at Rackhams ring volume two. Yes, I know I hacked around Billinghursts bf deleter in an audacious way, but I should have been allowed the second volume without that page switching crap. I have done my time with that stuff. No more NNNNNNNNNNNNNNNNNNcu at IA, also. Honestly, those magazines set up will be great to just drop in and do an article with. I was looking forward to meeting up with where it started. So, let me build the magazine backward and you all start to work on table styles to sheets.--RaboKarbakian (talk) 13:58, 7 April 2024 (UTC)

@RaboKarbakian: I have no idea what you're talking about, sorry. If I've stepped on one of your projects then I apologise. If you explain which and how I'd appreciate it.

The only changes I have made to Atlantic Monthly are replacing old auxiliary contents with something new, and only because the old approach is going to stop working. I have no plans to move any pages around. Xover (talk) 15:43, 7 April 2024 (UTC)

I'm no expert on tables or on stylesheets. In checking back I can only find some repairs to italics, (and possibly the addition of a basic TOC) in a single volume of The Atlantic Monthly, which I can't (at present) find changes I've made to stylesheets. Can you clarify which styles have become 'detached'? Can you also provide a list of what you had as 'projects' so that any current delinting efforts aren't duplicated. ShakespeareFan00 (talk) 16:40, 7 April 2024 (UTC)

ShakespeareFan00 all of the color stuff, with the exception of the patent: The Ridgeway book, the Munsell articles. The stylesheet here says it is unvisited by me. Then it quits working, changes don't happen to the text. It seems detatched from the page. Unhooked from each other or the stylesheet being edited by me is not the stylesheet that the page is using, all of a sudden. Page: and styles.css.

In volume 6, {{bc}} did not display. Another one also, I forget which. bc is like a base template here and very useful. No complaint, no red Lua errors, nothing, including text, centered or not. Then I broke the tables there, because I was frustrated. I did not think it would break it, I thought that it would fix it and maybe the style sheet also. And it didn't fix it. I had to settle down to think about it. So, now, I can fix it in like 30 seconds, but there is still that "what happened to the style sheet" part. Sorry.--RaboKarbakian (talk) 20:53, 7 April 2024 (UTC)

Template:AuxBox

I'd used this for Transcription or usernotes. It was forked due to the different use case. If you want to rationalise, I have no objections. ShakespeareFan00 (talk) 21:14, 7 April 2024 (UTC)

Bulk upload request

In the process of scan-backing "Fragment of a Greek Tragedy", I ended up extracting a lot of back issues of The Bromsgrovian from https://www.bromsgrove-schoolarchive.co.uk (file URLs like https://www.bromsgrove-schoolarchive.co.uk/Filename.ashx?tableName=ta_publications&columnName=filename&recordId=112 and they go in order). I don't plan to transcribe them, and I don't really feel like going through the 138 issues published between 1904 and 1928 to check author death years and determine suitability for Commons, but I would like to upload them somewhere so they're more accessible to anyone who does want to work on transcribing them.

If I email you the files, could you use a bot to upload them to Wikisource? The file names follow the pattern The Bromsgrovian, [date], New Series, Volume [volume], Number [number].pdf and if possible I'd like the summaries to be

{{Book
 |Author           =
 |Translator       =
 |Editor           =
 |Illustrator      =
 |Title            =The Bromsgrovian
 |Subtitle         =
 |Series title     =New Series
 |Volume           =Volume [volume], Number [number]
 |Edition          =
 |Publisher        =
 |Printer          =
 |Publication date =[date]
 |City             =Bromsgrove
 |Language         =en
 |Description      ={{en|1=Magazine of Bromsgrove School}}
 |Source           =https://www.bromsgrove-schoolarchive.co.uk
 |Permission       =
 |Image            =
 |Image page       =
 |Pageoverview     =
 |Wikisource       =
 |Homecat          =
 |Other_versions   =
 |ISBN             =
 |LCCN             =
 |OCLC             =
 |References       =
 |Linkback         =
 |Wikidata         =
}}
[[Category:The Bromsgrovian]]

—CalendulaAsteraceae (talk • contribs) 04:04, 12 April 2024 (UTC)

I… don't actually know. I've never done any bulk uploads like that, and thus haven't really looked at what ready-made plumbing there is. I can take a look at some point when I've spare cycles for it. How many uploads are we talking about total? Xover (talk) 12:28, 12 April 2024 (UTC)

138. More than I want to do by hand, but hopefully not too many if there is ready-made plumbing. —CalendulaAsteraceae (talk • contribs) 19:51, 12 April 2024 (UTC)

@CalendulaAsteraceae: Just to give you a status update on this... I've found ready-made plumbing to bulk upload the files, but only with identical file description pages. I've not yet found any sane way to individualize them either at upload or in a batch after the fact. I'll keep looking as time allows. Xover (talk) 08:52, 15 April 2024 (UTC)

@Xover: Thank you! If it looks like it would be too difficult to customize the file description pages, you could skip the volume and date (the data's in the filenames, so it wouldn't be too hard for later users to add that info). —CalendulaAsteraceae (talk • contribs) 15:32, 15 April 2024 (UTC)

It's late for me, so this might be a bad idea, but what about setting |Volume = {{subst:ROOTPAGENAME}} and |Publication date = {{subst:ROOTPAGENAME}} and then running a replacement script to change |Volume = The Bromsgrovian, [date], New Series, Volume [volume], Number [number].pdf to |Volume = Volume [volume], Number [number], and likewise |Publication date = The Bromsgrovian, [date], New Series, Volume [volume], Number [number].pdf to |Publication date = [date]? —CalendulaAsteraceae (talk • contribs) 04:45, 19 April 2024 (UTC)

@CalendulaAsteraceae: Ooooh! Now there's an excellent idea! I'll see if I can make that approach work and let you know. Xover (talk) 05:29, 19 April 2024 (UTC)

Chekhov DjVu

Could you please generate a DjVu file from this IA scan? It will allow me to start scan-backing our translations of his plays. --EncycloPetey (talk) 02:54, 19 April 2024 (UTC)

@EncycloPetey: Index:Plays (1916).djvu. Basic quality control, but nothing in-depth. Xover (talk) 06:42, 20 April 2024 (UTC)

Thanks! --EncycloPetey (talk) 15:33, 20 April 2024 (UTC)

Although IA gives the title as "Plays", the Library of Congress titles it "Plays by Anton Tchekhoff", so I am going with that title. --EncycloPetey (talk) 15:38, 20 April 2024 (UTC)

Not sure I agree with the LoC on that call, but whatever you prefer is fine by me. :) Xover (talk) 16:43, 20 April 2024 (UTC)

Withdrawals

Hey, I just wanted to thank you for your patience explaining best practices around withdrawing a proposal (or not). I feel like I've been taking up a lot of "space" on the boards the last few months, so when something gets resolved I prefer not to take up more of people's time/attention than necessary. But what you said makes sense, I think I've finally got it. In place of a "withdrawal" on the most recent one, I simply added a "keep" !vote. -Pete (talk) 16:27, 19 April 2024 (UTC)

Don't worry about "taking up space". That's rarely an issue at all, and in your case it certainly doesn't apply. If you knew quite how batty I drove the old-timers here when I first became active you definitely wouldn't be worried about stretching my patience. :) The sentiment is appreciated, but you're doing entirely fine. And your willingness to help out with all this maintenance puts you well ahead by any yardstick you care to apply. Xover (talk) 17:17, 19 April 2024 (UTC)

Special:Diff/14135949

Should have left an edit-summary!, The change here was because apparently border-spacing: <non-zero> does nothing unless border-collapse:separate is also set. The difference isn't structural, but you might want to check if the border spacing specified is actually being applied. This non-application of border-spacing<>0 might also be happpening in other templates. ShakespeareFan00 (talk) 09:35, 27 April 2024 (UTC)

The above was noted when looking into how to migrate away from deprecated table attributes, something that is progressing well. Although I can pause that effort if you have concerns.

ShakespeareFan00 (talk) 09:35, 27 April 2024 (UTC)

These are only used for layout tables, so the correct fix is generally to move away from the table rather than faffing with the detailed CSS. But, anyway, yes, please do always leave an edit summary that explains what you're doing and why you're doing it. Having to guess from the diff is unnecessarily hard. Xover (talk) 09:54, 27 April 2024 (UTC)

Erm. Hang on. You do know the default value for border-collapse is "separate", right? Xover (talk) 09:56, 27 April 2024 (UTC)

Okay , I clearly don't understand something then. ShakespeareFan00 (talk) 09:58, 27 April 2024 (UTC)

I've now reverted a lot my 'modernisation' efforts because I've lost confidence in the edits. Perhaps someone else like yourself can figure out how to modernise the releavant pages to ONE consistent format or class, so other contributors like me are not thrashing around trying to get things consistent? ShakespeareFan00 (talk) 11:28, 27 April 2024 (UTC)

I think the problem is that you're "thrashing around trying to get things consistent". In carpentry the rule to live by is "measure twice, cut once". I think that's probably a good rule of thumb for mass changes here too. And it's usually best to know that there is an actual tangible problem, that is well understood, before trying to implement a "fix". Xover (talk) 11:46, 27 April 2024 (UTC)

Page:EB1922_-_Volume_32.djvu/255

Am I hitting a CSS specficity issue? It's working on ALL the other cells. ShakespeareFan00 (talk) 14:56, 27 April 2024 (UTC)

Which cell? What is the effect you're trying to achieve? What is actually happening instead of what you wanted? Xover (talk) 14:59, 27 April 2024 (UTC)

I was not seeing a bottom border on a cell in the last row. I had another look at the layout and seemingly resolved it. ShakespeareFan00 (talk) 15:05, 27 April 2024 (UTC)

I was trying to replace "rules=cols" with a tablestyle. The table here should also have right aligned figures, but I wasn't sure at present how to implement that in a maintainable way.. ShakespeareFan00 (talk) 15:05, 27 April 2024 (UTC)

I don't have a ready-to-go design for that, but I would have started by trying to add text-align:right for :nth-child columns 2-, and then override the alignment for the header cells. Xover (talk) 15:09, 27 April 2024 (UTC)

The eventual goal is to chip away at - https://en.wikisource.org/w/index.php?title=Special:Search&limit=500&offset=1000&ns0=1&ns1=1&ns4=1&ns5=1&ns6=1&ns7=1&ns10=1&ns11=1&ns12=1&ns13=1&ns14=1&ns15=1&ns100=1&ns101=1&ns102=1&ns103=1&ns104=1&ns105=1&ns106=1&ns107=1&ns114=1&ns115=1&ns710=1&ns711=1&search=insource%3A%2F%28R%7Cr%29%28U%7Cu%29%28L%7Cl%29%28E%7Ce%29%28S%7Cs%29%5C%3D%5C%22cols%2F

So that deprecated table elements are eventually removed. If you have other classes to do it, feel free. ShakespeareFan00 (talk) 15:08, 27 April 2024 (UTC)

border= behaviour for TABLE..

Am I just being intensely dense? According to some information I have seen border should be 0 or 1. However, on English Wikisource im seeing border<>0 values. A quick check seems to suggest that border<>1 and border<>0 values means that 1px borders exist for the cells, BUT it is only the outer border to which the non 1 value is applied?

Can you please document somewhere what the EXACT conversions into CSS are before I change anything else the wrong way? Thanks. ShakespeareFan00 (talk) 15:53, 27 April 2024 (UTC)

It would also be appreciated if someone could check back on my recent conversions and make sure I am actually converting what I think I am converting. :( ShakespeareFan00 (talk) 16:35, 27 April 2024 (UTC)

border= takes an integer and is treated as a pixel value (the npx is implied). But since the attribute is old and deprecated its rendering is browser-specific and does not correspond directly to the CSS table model. Are you sure you're not over-complicating whatever problem it is you're working on? Xover (talk) 18:28, 27 April 2024 (UTC)

I'm not over complicating, It's about making the right conversions. The border=npx seems to only apply the large value to the outside border, not the indvidual cells. This is an important consideration when converting to use CSS because I need to know what value to set up in a selector for a td or th field? ShakespeareFan00 (talk) 18:32, 27 April 2024 (UTC)

Ok, let me simplify: you cannot convert 1:1 from border=1 to CSS. This is why border= is deprecated. Its behaviour is browser-dependant. In order to remove uses of it you will need to look at the relevant table and figure out what it should be, and then style it like that with CSS. Xover (talk) 18:44, 27 April 2024 (UTC)

That's what I figured as well. Hmm.. I'll try and approximate then. ShakespeareFan00 (talk) 18:47, 27 April 2024 (UTC)

Remaining rules=all usages..

https://en.wikisource.org/w/index.php?search=insource%3A%2Frules%5C%3D%5C%22all%2Fi&title=Special:Search&profile=advanced&fulltext=1&ns1=1&ns4=1&ns5=1&ns6=1&ns7=1&ns10=1&ns11=1&ns12=1&ns13=1&ns14=1&ns15=1&ns100=1&ns101=1&ns102=1&ns103=1&ns104=1&ns105=1&ns106=1&ns107=1&ns114=1&ns115=1&ns710=1&ns711=1&ns828=1&ns829=1

3 remaining uses.. Much appreciated if you could took a look at some point, as these are trickey to convert to something sane, by modern CSS standards:) ShakespeareFan00 (talk) 18:52, 30 April 2024 (UTC)

I don't think these are worth it to do anything about (well, except the translation). Xover (talk) 19:04, 30 April 2024 (UTC)

Template:Header, but in idwikisource

So basically, I'm updating the header templates on idwikisource, based on this wiki. There's a problem, and that is the header's position isn't on top. It's only happened in the main namespace, such as id:Undang-Undang Republik Indonesia Nomor 12 Tahun 1956 and id:Amerta: Berkala Arkeologi 3/Bab 1. Weird enough, it's fine on the template namespace itself (id:Templat:Header). How can I fix it? Thanks. Mnam23 (talk) 14:18, 1 May 2024 (UTC)

@Mnam23: My apologies. This came in while I was travelling, and when I got back there was a myriad little crisis that distracted me. I did see your message here when you posted, but I just plain forgot about. My apologies; that was lame of me!

Visiting the two pages you link to do not make it obvious to me what the problem you are describing is. Did you manage to resolve it on your own in the interim? If not then I'll need some more details to be able to make any useful suggestions.

In general though, the {{header}} template on enWS is automatically moved by a default (on for everyone) Gadget (see Help:Layout) that as a side-effect will move the header template to the top of the page if it was not already there. Xover (talk) 06:26, 11 May 2024 (UTC)

@Xover: I think this image would explain. (It has header, but the position isn't there). Mnam23 (talk) 12:07, 11 May 2024 (UTC)

@Mnam23: s:id:Perdjoangan Kita di Lapangan Perburuhan has a header as expected for me, as has s:id:User:Xover/sandbox. Judging by the screenshot you linked you are not seeing that on these pages. I recommend you try viewing these pages while logged out, and if the header shows up then it is almost certainly caused by one of your user scripts or styles. My suggestion would be to try emptying out s:id:Mnam23/vector.css (completely empty) to see if that fixes it. If so then it is something in that stylesheet that is causing the problem. The most likely culprit is one of the selectors that have a display: none; rule. Xover (talk) 16:44, 11 May 2024 (UTC)

@Xover: Nope. It's still happen to me. Check this image. Mnam23 (talk) 07:40, 24 May 2024 (UTC)

Unpaired P tags...

Example:- https://en.wikisource.org/w/index.php?title=Wikisource:Scriptorium/Archives/2017-01&action=edit&lintid=2541493

There has over the lifetime of English Wikisource been what I would term a "convenient misuse" of unpaired P tags as a line-break., or as in the above as a paragraph break in list item (apparently due to mediawiki limitations, The use of multiple colons to thread discussions, whilst not strictly a correct usage, is now endemic wiki usage, and customary practice.). In order to further reduce the amount of missing-tag LintErrrors, can you longer term look into developing a migration approach that is "appropriate" across all namespaces? Various approaches exist, such as replacing them with fully formed <P>...</P> across list/discussion items {{pbr}} {{pbri}}, or simply blank <P>...</P> constructions instead of a single <P>. This needs an administrator to implement in a calm manner, as most of the unpaired P tags are not in "content" namespaces. ShakespeareFan00 (talk) 10:24, 2 May 2024 (UTC)

(Aside: It would also be nice if the remaining High Priority Lint Errors were also resolved, The vast majority of the remaining ones being in User: space as far as I can tell, which I was strongly advised not to attempt 'amatuear' repairs on.)

ShakespeareFan00 (talk) 10:24, 2 May 2024 (UTC)

@Xover: Following on your comments elsewhere - https://en.wikisource.org/wiki/Special:LintErrors/missing-end-tag?wpNamespaceRestrictions=1%0D%0A4%0D%0A5%0D%0A6%0D%0A7%0D%0A9%0D%0A10%0D%0A11%0D%0A12%0D%0A13%0D%0A14%0D%0A15%0D%0A100%0D%0A101%0D%0A102%0D%0A103%0D%0A710%0D%0A711%0D%0A828%0D%0A829&titlecategorysearch=&exactmatch=&tag=div&template=all

Seems to be the bulk of non content namespace lints with any potential rendering impact. I'm not even going to suggest any fixes.. ShakespeareFan00 (talk) 13:41, 6 May 2024 (UTC)

Reminder to vote now to select members of the first U4C

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

Dear Wikimedian,

You are receiving this message because you previously participated in the UCoC process.

This is a reminder that the voting period for the Universal Code of Conduct Coordinating Committee (U4C) ends on May 9, 2024. Read the information on the voting page on Meta-wiki to learn more about voting and voter eligibility.

The Universal Code of Conduct Coordinating Committee (U4C) is a global group dedicated to providing an equitable and consistent implementation of the UCoC. Community members were invited to submit their applications for the U4C. For more information and the responsibilities of the U4C, please review the U4C Charter.

Please share this message with members of your community so they can participate as well.

On behalf of the UCoC project team,

RamzyM (WMF) 23:10, 2 May 2024 (UTC)

Pellucidar

The publication year is 1962, but the copyright year is 1915. The license is correctly PD-US with the death year of the author, but the revised templates interpret the publication year as the year for copyright, and I have no idea whether there is any way to correct the issue without revising template code. --EncycloPetey (talk) 05:19, 24 May 2024 (UTC)

@EncycloPetey: In the context of the license template, the year argument is the year of first publication because that's what affects the copyright. The year of subsequent editions only becomes relevant if there is copyrightable new matter, in which case the year argument should be the year of first publication for the last published of any copyrightable matter.

This is not a very intuitive usage, but I think with copyright law being what it is there is little alternative. Xover (talk) 05:53, 24 May 2024 (UTC)

That presents a problem if we have multiple editions. But in this case, it's an edition published by Ace Books. Claiming a publication year of 1915 would be nonsensical here because (a) 1915 was the year of first publication, when the story was serialized, in pulp magazines, and (b) Ace Books did not exist in 1915. We need a means to distinguish year of publication from year relevant for copyright. --EncycloPetey (talk) 06:03, 24 May 2024 (UTC)

Maybe just rephrase "because it was published before January 1, 1929" to specify that we're talking about the (latest) year of first publication? —CalendulaAsteraceae (talk • contribs) 04:58, 25 May 2024 (UTC)

@EncycloPetey: I am (as usual) being slow and failing to see the problem. Sorry. Why does using year of first publication create a problem when we have multiple editions? Why is it a problem that the license tag, way down at the bottom of the page, references the date that's relevant for copyright purposes (the {{header}} contains the date relevant for bibliographic purposes)?

Would simply changing the wording that is displayed for these cases to be specifically about first publication (along the lines Calendula suggests) resolve the issue? Xover (talk) 08:22, 25 May 2024 (UTC)

If we use the date of first publication, then all editions have the same date, even if the specific copy was issued decades or centuries later. This will create a lot of confusion for readers looking at versions pages, where all the dates are now the same for all the versions. It will also create a problem for disambiguating versions by maninspace name where the key difference is the date the edition was issued; resulting in editions with one date in the page title (for disambiguation) that is different from the date in the header. How many years of future explanations and minor edit warring would this lead to? --EncycloPetey (talk) 17:24, 25 May 2024 (UTC)

@EncycloPetey: If I've suggested that then I am most definitely confused. Sorry!

What I mean is that in the {{header}}, in the wikipage name, and on versions pages, we use the actual year of publication for the edition of the text we are reproducing. But in the licensing template—because it expresses copyright status and copyright cares about a) the abstract work more than the concrete edition, and b) the year of first publication—we use the year relevant for copyright, which is the year of first publication.

This obviously isn't ideal because you have to use different dates in the header and in the license template, but it is sort of necessary since they express different things (copyright vs. bibliographic domains, essentially).

Did that make more sense, or am I still confused? Xover (talk) 18:44, 25 May 2024 (UTC)

Understood, but in this case, the License template compared itself automagically with the header date, and decided there was an error. And the header documentation offers no explanation of what's going on. Now, I have since determined that PD-US has options for coding that will solve the issue, but other licensing templates, such as PD-old do not. Until the license and header templates are coordinated and co-documented, we're going to get errors generated by template magic. --EncycloPetey (talk) 19:18, 25 May 2024 (UTC)

Oh. Hmm, I think it's beginning to dawn on me. {{PD-US}} is probably not looking at what's been put in {{header}} but rather is pulling the year of publication from the attached Wikidata item when one isn't provided as an argument to the template. I'd need to check the code to be sure, but that seems a likely explanation. I wasn't aware it did that, hence my confusion.

That will, as you say, tend to cause some confusion. I am not entirely sure we can safely use publication dates from Wikidata for license templates, since at least most what is there today are bibliographic dates and not copyright dates. We'd either have to walk up the tree to the work level item to get the date there, or look for a Wikidata property that specifically is for copyright. But then we get into the different licensing policies between projects and other weirdness. Maybe it would be best to just not try to automatically get the date, making specifying one manually mandatory? It may be the data we need is reliably(ish) available at Wikidata, but I'd need to do some digging to be confident about that. @CalendulaAsteraceae: Have you done any research into that when you worked on {{PD-US}}? Xover (talk) 20:08, 25 May 2024 (UTC)

My recent experience is that a lot of our new copies are attached (incorrectly) to work data items instead of edition data items. And Wikidata currently does not distinguish publication date from print date from copyright date. --EncycloPetey (talk) 01:03, 26 May 2024 (UTC)

Indeed, {{PD-US}} is referring to Wikidata, not the header (and I'm not actually sure how it could refer to the header). The relevant code is in Module:License Wikidata.

Wikidata technically has a copyright property, but it's inconsistently applied, doesn't always include the reasoning/jurisdiction, and is IMO generally less useful than just getting the year. (I added an example at Last Poems in case you're curious.) Probably walking up the tree to the work level (if needed) is the way to go. —CalendulaAsteraceae (talk • contribs) 04:22, 26 May 2024 (UTC)

I added code to Module:License Wikidata to get the date from the parent work item if available. I think this should make the dates reliable enough for copyright purposes, given that we can override as needed. I will also say that I've found the automatic year determination and addition to Category:Possible copyright violations helpful for catching cases like The Crane is My Neighbour, which was inappropriately tagged as PD-US even though it was published in 1938. —CalendulaAsteraceae (talk • contribs) 04:45, 27 May 2024 (UTC)

@CalendulaAsteraceae: Awesome. Thanks!

@EncycloPetey: Could you have a look at various cases and see if the behaviour is now more in line with expectations? We'll need to watch this and see if further tweaks are needed. Xover (talk) 05:39, 27 May 2024 (UTC)

If it's pulling the date now from the work data item, then what happens for translations of classical Greek and Latin texts, where the relevant date is the modern date of publication and/or the date of death for the translator? --EncycloPetey (talk) 15:45, 27 May 2024 (UTC)

@EncycloPetey: I'll check. Could you point me to an example where the translator died less than 100 years ago? —CalendulaAsteraceae (talk • contribs) 02:24, 28 May 2024 (UTC)

Examples: The Antigone of Sophocles (1911); Trojan Women (Murray 1905); Sophocles' King Oedipus. --EncycloPetey (talk) 04:30, 28 May 2024 (UTC)

Hmm, interesting. Translations are somewhat unique in the context of copyright since translating something inherently creates a new copyright, unlike most new editions of an extant work. Wikidata's current model doesn't distinguish between a translation and any other form of edition, so we can't detect translations and apply special logic to those.

I am increasingly sceptical that we should be pulling years from Wikidata for the license templates. We want people to actively assess the copyright, not just slap something on there, and autofilling from Wikidata somewhat undermines that. When in addition most of our translations are going to get very incorrect years and we can't even detect that it's happening, I think we may be at a point when the problems outweigh the usefulness.

Or does anybody see any brilliant solutions to this that I'm missing?

What we could consider, is pulling the "copyright status" from Wikidata if not explicitly given. "Copyright status" is a derived property, so it means someone has at some point made some kind of assessment (unlike calculating it from a raw datum like a year). It is also specifically about copyright rather than the year of first publication (bibliographic) so we wouldn't be repurposing data from one domain to another.

Given the poor state of this data on Wikidata I'm not at all sure it'd be worth it, though. Xover (talk) 05:10, 28 May 2024 (UTC)

It would mean pulling multiple copyright status values and combining them to get the right template. And it would still require applying the correct death year based on the latest date from among the author, translator, illustrator, possibly editor, and possibly someone else, and any of those could have multiple persons listed. --EncycloPetey (talk) 14:04, 28 May 2024 (UTC)

No, I don't think it would work to grab all years and try to figure out the right one. If we went down that path it'd have to be trusting the copyright-specific properties already set at Wikidata and then just applying that license directly. See d:Q19092354, where there are two statements for copyright status (P6216). One that says in the jurisdiction United States of America (Q30) the status is public domain (Q19652) as determined by published more than 95 years ago (Q47246828). And one that says that in the jurisdiction countries with 80 years pma or shorter (Q61830521) the status is public domain (Q19652) as determined by 80 years or more after author(s) death (Q29940641).

I am not at all sure this would be a good idea, mind, but that's the approach I see having some chance at having any kind of reasonable accuracy. For items when nobody has set the copyright related properties we should probably just emit an error message asking the user to supply them. Xover (talk) 18:49, 30 May 2024 (UTC)