User talk:Xover

Header updates

I've taken another stab at updating {{Header}}. Does Module:Header/sandbox look like it's making a reasonable amount of changes? —CalendulaAsteraceae (talk • contribs) 04:13, 9 February 2024 (UTC)

@CalendulaAsteraceae: I would have split that up into maybe 3-5 steps, but it looks within reasonable limits, yes. Xover (talk) 10:14, 9 February 2024 (UTC)

Great! Could I ask you to review my changes and merge them into the main template? —CalendulaAsteraceae (talk • contribs) 17:30, 9 February 2024 (UTC)

@CalendulaAsteraceae: That requires available brain cycles and sustained attention, so as things look now that could maybe happen around Easter. How about I drop the protection and you can have at it yourself? Xover (talk) 08:58, 10 February 2024 (UTC)

Sure, sounds great to me! —CalendulaAsteraceae (talk • contribs) 20:57, 10 February 2024 (UTC)

@CalendulaAsteraceae: Done. Module, template, and main stylesheet can now be edited by autopatrolled users. Please let me know if I missed anything; and when you're all done so I can jack the protection back up to +sysadmin. Xover (talk) 21:15, 10 February 2024 (UTC)

@Xover: Will do! —CalendulaAsteraceae (talk • contribs) 21:16, 10 February 2024 (UTC)

Could you also drop the protection for Module:Portal header, Template:Portal header, Module:Author and Template:Author? (I'll make sure to give you a full list of pages when I'm done). —CalendulaAsteraceae (talk • contribs) 00:15, 12 February 2024 (UTC)

@CalendulaAsteraceae: Done Xover (talk) 06:14, 12 February 2024 (UTC)

Another unprotection request: Template:Translation header. —CalendulaAsteraceae (talk • contribs) 21:06, 12 February 2024 (UTC)

@CalendulaAsteraceae: Done Xover (talk) 06:42, 13 February 2024 (UTC)

Index:Brain Volume 31 Index.pdf/styles.css

This page was associated with an index page that you deleted - I assume that the styles page should be deleted too. -- Beardo (talk) 17:52, 12 February 2024 (UTC)

@Beardo: Indeed. Thanks for the heads-up. Xover (talk) 06:41, 13 February 2024 (UTC)

Module_talk:Author/testcases

I think the word here is, "Why?" . This isn't the first 'glitch' I've noted from all the header changes, including a very obvious typo, that a slower approach would have caught quite quickly ShakespeareFan00 (talk) 15:26, 15 February 2024 (UTC)

Our Poets DjVu

Would you please be kind enough to prepare a DjVu from (external scan)? There are enough irregularities in the listing that I do not trust IA's PDF, and this work is nominated for deletion, but it's contents cover many 19th/20th century poets from whom we have little or no sources about their work. --EncycloPetey (talk) 19:48, 17 February 2024 (UTC)

@EncycloPetey: Index:Our Poets of Today (1918).djvu. I did a quick pass on missing pages, page order, etc. and it looked good. Xover (talk) 11:20, 18 February 2024 (UTC)

Thanks! --EncycloPetey (talk) 19:29, 18 February 2024 (UTC)

Removal of 'by' from transclusions using override_author

Hi. I note you have been removing the manually-entered 'by' where 'override_author' is used, and am wondering why. I took up the practice, having seen it done elsewhere, as it makes the presentation consistent with pages which only use 'author', where the 'by' is automatically included. Regards, Chrisguise (talk) 00:15, 23 February 2024 (UTC)

@Chrisguise: The edit summary should have contained a link to the relevant discussion, but in any case the removal of the manual "by" is so that {{header}} can start automatically adding "by" without creating "by by". Xover (talk) 06:32, 23 February 2024 (UTC)

OK Chrisguise (talk) 07:37, 23 February 2024 (UTC)

Page:Tristimulus specification of the Munsell book of color from spectrophotometric measurements (IA jresv31n1p55).pdf/23

I get a 'too-small' to be usable edit space for this. The only possible thing I can think of something that changed in recently, because it wasn't doing this until toady.

I appreciate your efforts in trying to clean out cruft, but something broke here.

And before you ask I did try viewing/editing without being logged in and got the same behaviour.

Also I've not had the ability to resize it for an EXTENDED period.

I am suspecting some kind of obscure interaction, but if there isn't a soloution I am reconsidering if I want to contribute on a project that's actively "broken".

ShakespeareFan00 (talk) 22:34, 24 February 2024 (UTC)

@ShakespeareFan00: The lack of resizing is annoying, but they dropped the ability during a modernization of the code because they didn't find a clean way to implement it. The cramped editing interface for scans that are in landscape orientation is simply a bug. You can temporarily work around it with:

.prp-page-container {
	min-height: 80vh;
}
.prp-page-image-openseadragon-vertical {
	height: 100% !important;
}

This behaviour is a tradeoff: almost all scan pages are in portrait orientation and the current behaviour works very well with those (compared with the old code), but it fails pretty miserably with landscape pages and there's no obvious robust fix for it. Longer term I'm hoping we get a full-screen editing interface (for other reasons) that would also fix this problem in most cases. Xover (talk) 10:03, 25 February 2024 (UTC)

I asked someone that worked on Proofread page to consider integrating Inductiveload's Minipane style UI. It's not something that is a high priority though obviously. ShakespeareFan00 (talk) 09:45, 26 February 2024 (UTC)

Colors...

Hi.. How quickly could you come up with a Lua Module to generate colors based on a blend of RGB triplets by percentage? ShakespeareFan00 (talk) 00:24, 26 February 2024 (UTC) (I needed a way to generate HTML hex colors for Ridgway's 1912 book, based on his methodology.) ShakespeareFan00 (talk) 00:24, 26 February 2024 (UTC)

@ShakespeareFan00: If I understand the calculation and the usage context, probably not that long. If it's taking a triplet of percentage values (0–100%) in and spitting them out converted to a triplet of hexadecimal values in a 0–255 space, then that should be fairly easy. If you need fancier conversion or other special behaviour it might be trickier. Xover (talk) 06:23, 26 February 2024 (UTC)

Ridgway, uses a series of pure hues, (he gives wavelengths) , blended in a percentage to give a full spectrum of colors. Colors from that spectrum are then blended with various levels of whit or black (there is a table) in the book to give an initial series.

All the colors in the first series are then blended with various amounts of neutral grey ( I took this to mean a 50% grey (or N/5 level on Munsell's scale.)

Breaking this down the first function in the module would take the sRGB values for pure hues, and 'blend' them on the basis of percentages, returning an HTML style value for use in a style statement.

The second function would take the value of the first and blend it with white or black percentages, again returning an HTML color value for the blended tone or shade.

The third function would take an html hex value from the previous 2 functions and blend it with a specified percentage of neutral gray.

If it's possible to combine all these into one ultimate ridgway color generator, based on the tables provided in the book, even better.

BTW if writing a color module, I would strongly suggest making it flexiblbe enough that it could also do RGB->HSL and other color space conversions in the future.

Additional functions could be for conversion of xyY or XYZ specified colors to clamped sRGB. This transformation has a specific matrix for doing so, (albiet in respect of certain data it would need to be able to accomodate adjusting the putput for different illuminat conditions. (In some of the JOSA published MUnsell data for example it's using Illuminat C whereas sRGB is Illuminant D65.).

The reason I am wanting a module to do this (based on established methodology) is that I couldn't be sure the color plates in some works had not faded compared to original publication. ShakespeareFan00 (talk) 09:44, 26 February 2024 (UTC)

@ShakespeareFan00: What you're describing here is something completely different than converting one way to specify a color in a given color space to another. What you're describing here is about converting between colour spaces, and that's pretty advanced stuff (read: not something I'm going to tackle any time soon). The best I can offer is to suggest you take a look at w:Module:Color to see whether it does any of what you need. I'll also note that the values provided by the early pioneers in now-PD (i.e. old) books does not necessarily match seemingly similar values in what are the current standards a hundred years later. Figuring out this stuff requires domain-expertise in colour theory that at least I do not have. Xover (talk) 10:04, 26 February 2024 (UTC)

Module:Color doesn't convert xyY or XYZ (yet). But it does have a useufl mixer function that would be useful. Can we put it on the import list at some point? ShakespeareFan00 (talk) 14:08, 26 February 2024 (UTC)

Gadget transclusion-check question

Hello, Xover, I am from Ukrainian wikisource, we would like to use same approach as you utilized in transclusion-check gadget, thanks for creating it.

https://en.wikisource.org/wiki/MediaWiki:Gadget-transclusion-check.js

But while I was reviewing your code for a gadget, I noticed that line 185 has namespace ids of 0 and 114, though in eng wikisource you don't have this ids, see here: https://wikisource.org/wiki/Wikisource:Namespaces

Also, on page https://en.wikisource.org/wiki/MediaWiki:Gadgets-definition you have an attribute namespaces=106, as I understand it forces gadget to work only inside that namespace, witch makes my question about 0 and 114 even more open. Could you please take a look there? It looks like 0 and 114 are from some obsolete revision. We are curious, what ids should be used (should it be for Index or some others)? Thank you. Maxbgn (talk) 21:21, 26 February 2024 (UTC)

@Maxbgn: ns:106 on enWS is the Index: namespace. The Gadget is limited to only execute there because its purpose is to mark the page numbers in the pagelist on an Index:. When it runs it queries the MediaWiki API for information about those Page:-namespace wikipages, and among the information it requests is what other wikipages they are transcluded in. The namespace numbers you see in line 185 are for mainspace and the Translation: namespace. They're being used to filter the API response so that it only returns information about transclusions in those namespaces (and not in, for example, a sandbox in the User: namespace).

The link you give is for Multilingual Wikisource (aka. mul:Wikisource:Namespaces). English Wikisource's namespaces are at Help:Namespaces. It's easy to get us mixed up since mulWS also has a lot of project pages in English (and no other Wikimedia project has a separate Multilingual variant).

Incidentally, I am very to happy to see that my contributions can be of some use on other Wikisourcen. Please do not hesitate to reach out if there's anything I can help with. I'd also appreciate feedback about what you had to change or what made adopting it difficult, so that I can perhaps make that easier for the other Wikisourcen that want to use it. Xover (talk) 22:34, 26 February 2024 (UTC)

Thank you again for your response and gadget, we have successfully launched it in Ukrainian wikisource. Now this page Help:Gadget-transclusion-check is available in Ukrainian language also, where I translated your documentation and added some tech details, related to our wiki. I've also credited your original page in the end. Maxbgn (talk) 12:55, 28 February 2024 (UTC)

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)

{{plainlist/m}} spanning pages?

Should spanning with this template also be abandoned as in I did with spanning tables? I am asking because there are an unknown number of pages are spanned before you made me aware of the issue. I am referring to these pages Page:History of Woman Suffrage Volume 4.djvu/1217 — ineuw (talk) 06:45, 1 March 2024 (UTC)

@Ineuw: I am not sure I understand the question, so I am going to try to answer with a little guessing and a little generalisation and then you can hopefully adjust my understanding so I can give a more specific answer.

I never use the dedicated "middle" templates like {{plainlist/m}}, because I have yet to run into a situation where that is actually needed. In all actual cases I have run across it is enough to use the "start" template (i.e. {{plainlist/s}}) in the header. That will sometimes give small divergences in formatting in the Page: namespace, but looks as intended in mainspace when transcluded. Having small formatting glitches in the Page: namespace is ok: it is our internal workbench namespace and what counts is how it looks when transcluded for presentation.

I also do not normally use {{plainlist}} for use cases like your typical book index. For one thing, HTML / wiki list markup across Page: pages is technically very finicky and challenging for the software, and hence for the humans using it. But for another your typical book index neither needs list markup nor is semantically best expressed that way. So my usual approach is to separate each line of the index with one blank line, and each letter group with two blank lines (if the book has extra spaces between the letter groups). If there are hanging indents and similar in play I use those formatting templates in the header/body/footer as required, because those are simple div tags and not list or table markup (lists and tables are html constructs that are very finicky). This will sometimes give a presentation that is not pixel-perfect, but I've yet to find a case where it doesn't give results that are good enough for the purpose. So for all the typical book indexes, which is what your example page looks like, I quite strongly recommend not using any list markup at all. Some blank lines, a {{nop}} here and there, and maybe {{hi/s}}/{{hi/e}} in the header/footer is all you need.

The only time I use {{plainlist}} or other list templates is for something that is very obviously a list in the source. The book's index is arguably a list, but not obviously one, if I can put it that way.

Hopefully that was of some kind of use. Xover (talk) 07:26, 1 March 2024 (UTC)

Thanks for the reply. My concern was in general. I know that tables spanning pages slow down the server. I imagine that this also apply to the plainlist template. I am just curious. — ineuw (talk) 09:35, 2 March 2024 (UTC)

They don't inherently slow down the server, but some of the templates we use for them do cause all sorts of performance problems. And tables and lists in the way they are technically defined (both in HTML and MediaWiki wikimarkup) make them very fragile and finicky when we break them up across pages. For short lists or tables (like a two or three page table of contents) we can usually make it work, but for a potentially multiple many page book's index it is most definitely better to avoid those constructs if at all possible. Xover (talk) 10:15, 2 March 2024 (UTC)

Initially, my concern was how a table broken into two consecutive pages appear in the main namespace, but they match seamlessly and appear continuous. I check the main namespace looking for errors. — ineuw (talk) 10:26, 2 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)

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)