As I see it is a rendering issue, and I am guessing something to do with ResourceLoader where the image is loading under the toolbar with a 15px height

I never looked at it. :-( @jayantanth ?

There is a note in Wikitech news this week about changes about ambox and mobile

English Wikisource no longer uses it as it caused other issues which were resolved by simply using <poem>. This shouldn't be an issue

Seems that it would be better to flag this for a linter fix, rather than an ugly hack of wikimedia. We have to learn to do things properly, and it isn't as though it is problematic to close <poem> on one page and reopen on the next.

@Xaosflux thanks. That is what I believe that I have been saying, or believed that I have been saying. And only where mediawiki namespace message has been customised, ie. is a local message.

This is clearly a case of minor modifications (using shipped translations is still okay). One would think that for languages where we have XX and XX-LL that we can stem and identify same language. This is quite problematic for English language wikis where any person is using en-gb, en-ca, etc.

@Tiven2240 looks good to me, I can see seven import sources in the dropdown. Presumably you will test it on something to confirm

I saw it there. Seems that we have whole word searching, not stem searching. That makes searching significantly less useful. :-/

In T188537#4046295, @Stashbot wrote:

Mentioned in SAL (#wikimedia-operations) [2018-03-13T12:04:07Z] <reedy@tin> Synchronized wmf-config/interwiki.php: T188537 (duration: 00m 57s)

waiting two weeks for a requested sync update? ouch! one would hope that these central and significant tasks could be done within a few days

Processed, though I think that they are losing their text layer
https://en.wikisource.org/w/index.php?title=Page:Gloucestershire_notes_and_queries,_volume_1.djvu/276&action=edit&redlink=1

@Tpt I can reproduce in "core" 2006 JavaScript editor, Manual:EditPage.php and I know that numbers of us dinosaurs still edit through this as it is simpler and more efficient for WS purposes, and the fact that it is easier to hack custom buttons for it

@Reedy still abnormally slow, start at https://commons.wikimedia.org/w/index.php?title=File%3AThe_New_Testament_of_Iesvs_Christ_faithfvlly_translated_into_English%2C_ovt_of_the_authentical_Latin%2C_diligently_conferred_with_the_Greek%2C_%26_other_Editions_in_diuers_languages.pdf and from the page dropdown on the right, pick any of the pages later in the work.

bah humbug, it seems that touch/purge in ywikibot needs either categories or transclusion; and I don't see that knWS uses index categorisation based on proofreading :-( I will have to purge all the pages and that will take a couple of hours. I have started it, though will have to look at it tomorrow to judge success.

In T188856#4021909, @Billinghurst wrote:

@jayantanth I am having to push through as billinghurst as the bot doesn't have sufficient privileges to pull enough pages through the API. You may wish to put through the knWS community a request for permissions for wikisource-bot so we can do these things more easily.

Touching the files seems to be working fine. Why they are needing to be touched is unknown to me.

@jayantanth I am having to push through as billinghurst as the bot doesn't have sufficient privileges to pull enough pages through the API. You may wish to put through the knWS community a request for permissions for wikisource-bot so we can do these things more easily.

I purged one, and it appeared in the list. Let me push Wikisource-bot through to see if touching the pages makes a difference, and if that doesn't then we can push a little harder.

In T152219#4021630, @Tgr wrote:

We should clean these up a bit so they can serve as a validation of new captcha types:

• differentiate between registrations which have Javascript and ones which don't (seems like ~90% of spambots do not have Javascript while most user do)
• also between ones that use the API vs. web interface, and mobile v. desktop (most spambots seem to be using desktop web)
• store username + captcha success rate in EventLogging so that it can be merged with block logs and editcounts later to get more accurate numbers for spambot vs. productive contributor captcha error rate then make the data easily available somewhere (grafana? ReportUpdater?)

@Ineuw can you please confirm that this is a proofread page issue (only happening in Page: ns) or a more general issue when editing in main ns. If just the first, then please add a tag for proofreadpage extension

It definitely works that way for description and aliases. Otherwise, I will have to dig through the free text fields to see where it happens as I come across them.

@Tiven2240 start the discussion, and after a couple of weeks simply point to it. With the small communities it is about providing the opportunity for any discussion, rather than requiring a groundswell of YES votes. Smaller communities are understood, and this is not going to break anything, and it isn't an unreasonable request to complete once the community has been given the opportunity.

Forgot about the magic word, probably what happens when labelled not enabled; not enabled on enWS as {{PAGESINNAMESPACE:106}} I see the redlink Template:PAGESINNAMESPACE:106

The request appears to be for a count for the number of pages in a specific namespace, which represents a count of the number of works that are being worked upon through proofreading process. Presumably having a direct count makes for easy statistical calculations as somewhat done at snapshot. It shouldn't be a difficult count, so it maybe depends on whether it is seen whether it is either

1. something system generated as required
2. generated by means of calculations, or
3. externally generated then added as daily count

Code maintained at mul.wikisource.org

(Asking for a friend) is the same logic also translatable to [[Special:log/block]]? or are we just pushing excreta up hill? Happy to do another ticket, though only if it is considered doable. (no point otherwise).

With this component it looks as though removing oneself, or removing someone else both utilise the same message.

In T181889#3805727, @MarcoAurelio wrote:

I'd say this might be https://phabricator.wikimedia.org/T112751 too? (private security ticket) Those with access, please check.

Put the NewUserMessage back as it is the prime reason that I started the message. I wrote above what I wished to be achieved please see suggestion a) or b) in original message. [I also had confirmed that two wikis which I mentioned as sending welcome messages were in init file.]

In WD there was the following report by @NicoScribe

@Jalexander said in IRC that it was only log visibility. :-)

@Kbrown to note as it may come up in a forthcoming conversation

@Anomie: there is a suggestion that rMW467ee1e82f1526ba4671f52936fd279eb5cda4f6 may be in some way related. Were suppressed logs visible after that alteration? or are you aware of other changes in that space?

Personally I still don't understand why the Wikidata-query-service doesn't generate their own shortened urls and own the resolution. It shouldn't have external security issues, and less in the way of abuse. Magnus has done that with petscan. Waiting for the broader WMF to resolve this is where there is no evident poltical will or impetus is becomng ... <crickets>.

I would have thought that < and > were promising candidates though I hazard a guess that they are not standard on keyboards

In T144780#2993927, @Nikerabbit wrote:

This task is not currently classified as UBN!, and per Language-Team's repository maintenance list we only look at UBN!s for this extension. This task will be considered when there is a focus on maintenance.

mimicked the "AWB" tag at English Wikisource, so available for confirmation testing

In T111663#3914692, @Reedy wrote:

and

In T111663#3914693, @Reedy wrote:

If we wanted to do it with abusefilter (for example)... We'd have to do some sort of global rule... Which doesn't seem very performant friendly, never mind trying to work out if it's actually AWB, without depending on something like the edit summary (then we can't actually remove "using AWB" from it)

In T111663#3910098, @Reedy wrote:

In T111663#3910043, @Trizek-WMF wrote:

Thanks. How do you do this? I'm bad at tags, and I think I'm not the only one. ;)
Given the number of people who subscribed to that task, an how-to would be super helpful!

I'm surprised to only see one edit tagged (as I'm writing). Are there not more people using AWB?

There are, but it's not MW deciding the tag needs to be added, it's AWB telling MW to add that tag for the edits. So unless someone is building it from source themselves, they're not going to be running the latest code with that actual update in it to add the tags.

So a release is needed so that this code is rolled out to more people

And I didn't really need to do much more testing to know it's working.

Go to https://en.wikipedia.org/wiki/Special:Tags (or the local page thereof), as an administrator (or someone with the managechangetags right), and then in the box at the top, add "AWB" as the name, and a reason of something sane... Click create.

It'll be added to the table below.

https://en.wikipedia.org/wiki/MediaWiki:Tag-AWB and https://en.wikipedia.org/wiki/MediaWiki:Tag-AWB-description then want defining to make something useful (you'll see redlink edit links against the AWB tag in the table int he meantime). The first being a wikilink back to the softwares local description page, or if there isn't one, to enwiki. The second one then being something describing what the tag defines, in this case "edits made with AWB"

I support this suggested change.

has the functionality here been added to an FAQ or help pages on Wikidata and/or Meta?

thanks for the pointer
{{done}} enwikisource

In T165112#3874915, @Esanders wrote:

Many of these are used in the wild by user scripts, so I've re-added them as aliases. We should do an mwgrep after this has been deployed so they can eventually be killed off.

I am wishing for meta's global title blacklist to be regex-checked. It has been indicated to me that the gerrit here may be part of the solution. Are we able to see whether that is the case, and if it is, are we able to look to implement this fix. Thanks.

In T183341#3851222, @jcrespo wrote:

@Billinghurst I was actually praising you for the report, for taking the time, and saying sorry it happened :-)

fwiw the phabricator ticket came on the seventh fail in however many minutes. 3 using tool, then 2 using create item; ask in IRC, get response try again through special item on 2 PCs, so call that at least 10-15 minute period of occurrence, and that would only be minimum if I started in coincidence with it starting.

if this is something that may recur, may I ask for the coordination of a more informative error message, or something that tells me to stop and come back soon?

after a big gap in RecentChanges there is a trickle of item creations now occurring.

tried a separate PC and got same resulting failure

Ouch everyone. Merry Christmas to you all.

@Vladis13 @Ratte from the index: page you are looking for the icon

In T139152#3842130, @Billinghurst wrote:

@Noe You have just changed the context of the request and I believe that it no longer reflects the initial desire. One would hope that the best solution is directly link and the text as it is at the wiki, ie. a translcusion, or transclusion-like.

If this is a new community desire, then it would be worthwhile linking to that change, as it seems to be your wish rather than the community's.

@Noe You have just changed the context of the request and I believe that it no longer reflects the initial desire. One would hope that the best solution is directly link and the text as it is at the wiki, ie. a translcusion, or transclusion-like.

I have the global sysop right.

I don't see that the <pagelist /> is mentioned in our template: or mediawiki ns: pages at enWS, and it is so long since I have dug into those files, I would have to go back to first principles to see and remember what to do. I even think that there has been some diversification in how the wikis do some of this, with frWS having a module.

In T181698#3800268, @matmarex wrote:

@Base @Billinghurst I am sorry about the broken links, that's my mistake. I didn't realize formatting was allowed in the headings of gadgets' sections (there isn't any on the wikis I regularly use). I'll get it fixed today. (I think that is the only place where this occurs?)

We use the 50em width for all OOUI forms, it usually works well to prevent things like dropdowns and text fields from being insanely wide, although perhaps it's disputable whether it helps in the "Gadgets" sections of preferences (I think it looks just fine in all other ones), it looks especially silly because the into text of that sections is not wrapped for some reason. Can you file another task about this? (So that we can pretend the angry comments from everyone on this task did not happen…)

that was edit conflict

Now I am confused, I pasted an image of English Wikisource broken links above. Subject headers used within Gadgets page. The Special:Gadgets page shows proper links, previously the Special:Preferences gadgets provided proper links, since the update to Oojs there are these broken links. [Apologies for not pasting the actual url, it was a dash out the door job.]

and some wikilinks are broken in heading lines

As javascripts / gadgets can be competing, has the user gone back to defaults, or used the quick means to neutralise gadgets and personalisation (and I cannot remember off the top of my head the quick means to do that).

In T154371#3780281, @Bawolff wrote:

.

Some thoughts for the developers

• that the skin should be clearly identified as beta in the preferences, with a help link, and a feedback link

That sounds reasonable. Id have to look in to how changable the special:preferences layout is. Im not sure off the top of my head. (I suppose if worst came to worse we could use js but thats really ugly)

However, Id be opposed to using the "beta features" tab for this, as i dont think it makes sense to have an off by default preference controlling weather a second off by default preference exists.

@Iniquity here is an alternative point of view.

I believe that this is used by ia-upload on tools.wmflabs to create djvu files as part of its machinations for PDF files from archive.org since they stopped generating djvu files
@Samwilson ?