Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://phabricator.wikimedia.org/p/Xover/ below:

♟ Xover

Now that async/await is finally available (T381537) I'll be starting work on replacing the above referenced Gadget that prompted this task. Async/await makes it possible to rewrite it, but it'll still contain a lot of boilerplate API calls with iffy semantics to figure out where it is in the subpage hierarchy. Having API like that described in this task could make that Gadget actually somewhat elegant and maintainable.

And per the use case described in T358660 having parity with the Lua library would be really helpful and avoid a lot of boilerplate calls to the Action API. As a first "MVP", having .exists for the current page (with its parent pages if the current page is a subpage). But long term also for arbitrary pages.

Note that this raises thorny issues of cross-project policy, permissions (e.g. filemover on Commons vs. move permissions on Wikisource), and what happens when the same file on Commons is used by multiple Wikisourcen (e.g. a book transcribed on one of the Indic Wikisourcen and translated on enWS). Files being renamed on Commons without the Wikisource community being aware of it (before someone notices the broken transcription) causes quite a few problems already, and if renaming a file on Commons suddenly triggered mass moves on Wikisource that's likely to get even worse.

Hello folks - this tool has a cache directory (/data/project/phetools/cache) that's over 100G in size. Is that in use or could we reclaim that disk space?

But do remove all vestiges of the "account reputation" term first, it's almost guaranteed to lead a subset of the contributor community down rabbit holes that do not reflect the intent of this work.

Yeah, I agree with that. In terms of the proposals for the user-facing feature, I think we've done that, but if you think we should adjust any other wording, please let us know.

… But we also saw that there are many useful data points that are helpful to quickly surface to moderators, …

"User Info Card", as used in the title is fine and dandy, but further down in the task description (and subtasks) the term starts morphing into "Account Reputation" at which point the immediate connotation is "Social Credit Score". I think the "account reputation" term needs to excised anywhere it appears.

I'm not familiar enough with wikisource and ProofreadPage to know what effects this has on the wiki itself.

Potential subtask: T351035

google fonts api returns woff2 for Windows, but returns woff for macOS
This apparently has to do with issues like https://github.com/google/fonts/issues/2602

Still that means that if we have like 2 buckets, we'll probably cover the most significant browser support for that ppl will actually need.

Hmm. Did anybody check the intersection of browsers that do not support async/await and those that do support CSS Variables (which are required by Codex, and Night Mode, and…)?

I've not looked into this deeply yet, but it appears it may be related to the Toolforge proxy. The app is sending Content-Length correctly on my local Apache:

Remove myself as assignee on this task since I won't have time to work on it any time soon (and @Aklapper keeps nagging me :)). I still plan to get back to it eventually, but this better reflects the real staus just now.

… the specs allow [Retry-After] for 200 responses too, I can't find it in RFC 7231 though, I will check but I'm sure we checked the specs …

·

,

,

,

,

,

,

,

,

,

https://www.mediawiki.org/wiki/Manual:Maxlag_parameter says that you can add e.g. &maxlag=5 to all of your requests, and retry if they fail with the maxlag error code. You don't need a separate request to fetch the current maxlag value. And you can read the suggested delay to wait before retrying from the Retry-After HTTP response header.

We could add something making use of that to mw.Api. It could be similar to how postWithToken() already works (that method implements retrying on specific failures).

·

,

,

,

,

,

,

,

,

,

·

,

,

,

,

,

,

,

,

,

I recommend that between each request, the tool should wait as long as max lag which is between 0.1s to 0.5s in normal times. That would automatically makes it back off during stress.

·

,

,

,

,

,

,

,

,

,

Random note: The gadget currently waits 1 second before next edit, I think it's fine to lower it to 500ms.

·

,

,

,

,

,

,

,

,

,

❯ pipx install pywikibot-9.4.0.dev1-py3-none-any.whl
  installed package pywikibot 9.4.0.dev1, installed using Python 3.12.5
  These apps are now globally available
    - pwb
done! ✨ 🌟 ✨
❯ pipx inject pywikibot requests_oauthlib                            
  injected package requests-oauthlib into venv pywikibot
done! ✨ 🌟 ✨
❯ pipx inject pywikibot_scripts-9.4.0-py3-none-any.whl 
Error: 'pywikibot_scripts-9.4.0-py3-none-any.whl' looks like a path. Expected the name of an installed package.
❯ pipx install pywikibot_scripts-9.4.0-py3-none-any.whl

… there are other issues which might be more important.

I don't particularly care how the various bits of the distro is broken into pieces, but for anyone who primarily wants to use the finished scripts the PyPI package is a bit useless right now. Installing the pywikibot package and then having to do a git checkout of it too in order to use it is… well, let's call it "not optimal" and leave it at that.

On English Wikisource the limitations and problems with the poem extension led to the development of {{ppoem}}. It's not universally used and some contributors still prefer the tradeoffs of the poem extension tag, but the approach taken by the template might be a good reference for this task.

If this is due to T294397, then as a result if it getting rolled back in T371977 the problem should now be gone. @BD2412 could you retest and report results here?

however, AutoWikiBrowser (AWB) also checks writeapi.

Eh… looking closer, it seems to check the writeapi right, not the siteinfo response member. So it’s not gonna be directly broken in the same way, I guess. Let’s untag them again.

This seems to be zhWS-specific, so removing the (somewhat confusingly named and conceived) "All-and-every-Wikisource" tag.

Wikieditor now provides a decent(ish) API for adding new groups, sections, and buttons; which is documented(ish) with examples at mw:WikiEditor/Toolbar_customization. It also provides the mw.hook() event wikiEditor.toolbarReady and wikiEditor-toolbar-doneInitialSections (documented on the same page). The API for removing things and modifying things is certainly not great, but it exists and is documented (ditto).

This 2012 bug (imported from Bugzilla) is about UI that has seen major revamps at least twice since the bug was reported (both in ways that would directly affect the subject of this bug report), and the user reporting the bug is no longer active on Wikimedia projects (they have like ~10 edits the last five years, the last one a year and a half ago). I am therefore going to close this as "Invalid".

This is unrelated to the 2010 Wikieditor; the horizontal/vertical switch and the sizing of the text boxes is controlled by ProofreadPage.

Should this be closed? It's ~9 months old and only reported once on a beta instance (which I guess is "production", but…). It seems odd to clutter up, e.g., the WikiEditor (2010) workboard with this.

Also reported at enWS here.

Getting away from solution-ing. It seems like the general issue here is the idea that indicators should be included some how in the header component rather than occupy the space between the article and Article/Talk/Tools bar - am I understanding that correct?

Could we please make sure this component is accessible for people using screen readers like JAWS, NVDA, ZoomText, and Speechify?

Deprecated: strlen(): Passing null to parameter #1 ($string) of type string is deprecated in /var/www/html/mediawiki/thumb.php on line 362

Does someone want to have a go at updating the description and re-tagging to make this clearer?

There's a /looong/ standing issue to *add* section tags to HTML output, which I can't find at the moment but it's like a 4 digit bug number. Also T300467: Expose section identifier in HTML output -- so I'm also hoping <section> tags make the cut.

Possibly of relevance here: book2scroll.

Like I get the desire, but you also have to look at the impact of that desire for others.

@Jdlrobson While there is certainly some overlap (no pun intended), I'm not convinced this task and T358081 are about the same issue or have the same solution. For T358081 at the very least the issue is exacerbated by Wikisource tending to have much longer (wider) page titles (due to extensive use of subpages), and by the "Wikisource" extension (why is there no Phab tag for that extension?) putting that giant blue "Download" button in the indicators area. We also have the unique-to-Wikisource issue of the "proofreading status" progress bar (as seen in the screenshot in T358081, added by ProofreadPage).

@Theklan Not sure whether this is relevant or helps at all (not really sure what the goal of this task is), but the English Wikisource main page has been based on CSS Grid since the Mobile Frontend changes in 2020. It's simple (bordering on primitive), but does the job fairly well.

• Have LinkHolderArray take an option to unstrip general markers when replacing the link holders, and use that option from Parser::internalParseHalfParsed().

I guess this would be the least risky of the three options.

Maybe, but i would argue a new task would be better, when and if that happens.

Like we are talking about transitioning to something that doesn't exist yet.

My point was that those volunteers should be appropriately informed, with links to this ticket for background. But fair enough with marking this as resolved.

And now I just got a resend of a different email to a different user, originally sent on April 11. That’s something like two out of three emails I’ve sent using «Email this user» the last month+ that are getting resent.

… #iferror from Extension:ParserFunctions is supposed to find things with class="error" so it should catch such things but it should be noted that ‎PagesTagParser.render where the error is thrown from is for <pages/> not for <pagelist/> so you are wrapping the wrong thing to catch the error.

The patch should make any errors more verbose so that we can collect more information about these failures.

But now I haven't gotten any more copies since April 5, so whatever it was seems to have cleared for now. It's probably still a good idea to dig through the logs to get an idea what caused this since it could very well happen again and at larger scale.

I think it is generally a bad idea to bulk-write OCR to Page: namespace pages. It tends to create huge backlogs of very poor quality text that discourages many contributors from working on a text (enWS has a million-page backlog there, and the number is not decreasing). The text saved also becomes quickly out of date when newer models or OCR engines become available.

A digression for the specific scope of this task, but mentioning it here in case it can inform direction / the discussion:

… it floods my alerts in the Wikimedia projects.

@Xover if you could paste the headers of two of the messages that would help, the whole raw text would be the best however. I am curious how identical the emails are, as that would help indicate where they are being duplicated.

And now another two ticked in.

@Xover I created https://phabricator.wikimedia.org/P59624 that is restricted to WMF-NDA members and the subscribers of the paste (currently you), which should be secure to put the full headers

I'm not sure grouping them by Wikisource domain is a good idea. For one thing, these do not map cleanly to languages (enWS includes "ang"; Spanish is a relevant language for multiple Wikisourcen; Norwegian has a politically-decided split between no-nb and no-nn; etc.), and for another we have Multilingual Wikisource where all languages are in scope. Latin is laWS, but also mulWS, and occurs in many in-scope works on enWS (just as quotations and such). Multilingual works. Etc. etc.

Sigh. Please don't use tricks like combining margin-top and padding-bottom. You're doing it to defeat margin collapsing, which is how the CSS box model is supposed to work. This patch makes Vector legacy and Vector 2022 behave very differently for certain inputs, mainly due to p-wrapping (T253072), and it's going to be a massive pain to work around from templates and TemplateStyles.

@Soda Since you wrote the patch for T358437, perhaps we could prevail on you to do the same for this bit too? It's just cleanup of old config, so no particular rush.

I think the problem here is that this varies per page and not per wiki or per user. This is one main reason why enWS (and frWS and some others) have implemented a "Dynamic Layouts" system: basically a Gadget that applies different styles based on user preference with a default provided by the presence of e.g. {{default layout|Layout 2}} (Layout 2 being the main width-constrained layout on enWS).

I was inspecting the epub, and I noticed that it sets:

style="width:480; height:717; "

I'll just note that, as all elements on a page, any css can be overridden and changed. So even if you don't want to use the skin frame, that is possible via Common.css, template styles etc etc.

I'm not entirely sure I'm following the problem you're seeing, but...

Indeed. The workaround from enWS was linked here for the benefit of other projects until the problem can be fixed in WS Export. We can't carry manually added and manually updated custom CSS for this on 100+ Wikisourcen indefinitely.

An intent to roll out Vector 2022 to enWS in the very near future has been announced so this issue just became a lot more pressing.

Hello, Is this related to the wikisource statistics
https://phetools.toolforge.org/statistics.php getting out of service quite simultaneously to this purging. These categories feed the statistics. Or is this an accidental coincidence?

I am still planning to migrate this tool, IRL is just being recalcitrant about giving me sustained time slots to work on it.

renamed

from

to

.

Matt hasn't edited since 2019 and no longer works for the WMF so is unlikely to show up and fix the tool. But if anybody feels up for usurping it, the code is at

I can reproduce this in Safari on macOS (latest release). There is nothing obvious in the console, nor does inspecting #wpTextBox1 reveal anything obvious. The fact that you can delete text but not type normally suggests something is hijacking keyDown events rather than having disabled the textfield. Running Balinese palmleaf model did not seem to trigger this, but both handwritten and typewritten Ukranian models did. I didn't try any others because Transcribus is sloooow.

I think (fwiw) async/await is the standout feature here, with everything else being possible to work around in various ways (transpiling, polyfills, do-it-the-old-way, etc.). I wouldn't want to argue in favour of raising browser requirements for that other stuff, and I wouldn't want to argue for generally raising it (with all that implies) for just the one language feature.

Please disable and undeploy Extension:Collection from English Wikisource.

(other language Wikisourcen may want to consider requesting the same)

IMHO this combination of sentences implies that you’re requesting this on behalf of English Wikisource, but AFAICT you never discussed it on wiki?

Just as a curio, I had the same problem with the editing toolbar in the 2010 wikieditor and fixed it by sticking the following in my common.css:

@Xover which project are you referring to? To be clear the change has only occurred so far on the following wikis where impact is expected to be minimal:

• All projects where Vector legacy is the default skin
• Wikivoyage
• Wikibooks

Please also see the user notice from a year ago: T331679 - I am sorry if you missed that announcement.

Erm. Are you trying to say that this change has already happened for the wikis listed as "Wikis impacted", or that these will be impacted when the change is made at some as yet undetermined point in the future?

Erm. Are you trying to say that this change has already happened for the wikis listed as "Wikis impacted", or that these will be impacted when the change is made at some as yet undetermined point in the future?

Based on looking at the code, and playing around with the buildpacks/the jobs framework, I'm a bit pessimistic that we will be able to migrate everything (especially the custom jobs mess) to the newer framework in a reasonable amount of time, …

I'm looking into migrating some of the usable aspects (statistics and match + split) of phetools into seperate standalone tools. This might take a while however, so I'd like to request that the tool be kept running after the Feb 14th shutdown deadline.

The lack of accessibility for even colour blind people got to me, so I hacked up a local gadget to at least provide a tooltip with the text. I think that's probably the absolute minimum we should do while we wait for inspiration to strike regarding a long-term solution.

Erm. No use case for checking whether a page exists? That seems improbable.

We have a rather big document about follow, but as said above this was mostly wrong: https://docs.google.com/document/d/1n_V91k2s7ULVf2vBMEjbC-nMT6ma6UIsmYSoQJE4Oy4

I can't speak to the practical accessibility of this in screen readers (which should be checked in JAWS, NVDA, etc. too), but from a general perspective I don't think it makes sense to mark this up as a list, or to mark it up as a list and then change its display model to flexbox. My suggestion would be to use div + span; and possibly also to find some sensible content to put inside the elements instead of visually styling empty elements (think of it like alternative text, either percentages or absolute numbers).

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4