@Aklapper , added the new project to the task.

If you do do this, it would be good to only remove the older runs results, but leave the most recent run result for each query, or as a less desirable alternative to keep those for only published queries (but I am one of the people who rarely publishes queries even when they are finished). My queries often refer to some article contest, or some on wiki investigation, or just a bit of curiosity that does make sense to be kept for many years and is sometimes linked with the assumption of some stability from on-wiki. Re-running queries every 90 days would be an unnecessary burden, might lead to corrupted results, such as a query that was used to determine a contest winner will no longer should that person as winner because of some things happening in between, and because of schema changes it might also be a maintenance burden (I still have a lot of query results active from the pre-multi-DB select cancellation times, or from the pre actor migration times) that either require a tweak or are even impossible to rewrite, but the results of their older runs are somewhat useful to this day.

It's not much more complex than commenting on a task. There are reasons why there is often more than one single catch-all task for each software project. :P

In T191156#10019825, @Ladsgroup wrote:

.mw-content-subtitle > .cdx-message :not(.mw-revision) {
  whatever you like;
}

I'm sorry but a wiki can't have consensus to revert a software patch as it impacts all wikis not just yours.

I'm sorry but a wiki can't have consensus to revert a software patch as it impacts all wikis not just yours.

Reopening, the details on this are sent in the "Votewiki setup for Wikimedia Ukraine AGM votes 2024 summer" thread.

As a reader, I want to use the same skin across all wikis so that my experience is cohesive

How many freeform javascripts do you get to install in your Facebook or Instagram page again?

Another additional work paid "improved" vector WMF staff is putting on unpaid projects' volunteers.

Allow the same list be included in different pages

As a random rant, perhaps it is my myopia speaking, but I would really love to have bigger default sizes across Wikipedias for the images. In fact it is in my todo list to propose increase for default Infobox sizes on Ukrainian Wikipedia, and come to think of it making default thumbnail sizes bigger would be a boon too. That said I feel like desktop "improvements" are a thing that is making this a thing that would likely want people to stick with those inadequately smaller images as now you have to work with so much less width available.

Now there is the only fast way to receive translated messages - through gerrit.

I see that there are also

{
    "propname": "translate-has-languages-tag"
},
{
    "propname": "translate-is-translation"
},

page props.

whether or not it makes sense to add Special:MyLanguage/ in front of it) via the API

I am confused what this task is about. Gadgets do support messages. It is possible to commit messages to Wikimedia-messages and use them from gadgets at any wiki.

But also more prone to vandalism than I18n in translatewiki

In a way this is a variation on security through obscurity. As in more people know how to edit Wikidata than how to edit TWN (or rather that TWN exists). Yes, TWN requires editors to be pre-approved, but this has never stopped low quality translations and vandalism (I mean it has surely stopped some, but it has also not stopped a lot other)

299 active users, 10 admins (including abuse filter). If not for an explicit decision to opt out it would still be a GS wiki. No need was demonstrated in the discussion. Definitely a no.

Interestingly even Cambridge's website seems to be using Wikipedia for example sentences, see for example https://dictionary.cambridge.org/dictionary/english/withal

The situation is kinda like one would not let the new staff into a store and then claim, that well, no one is in the store, so it should be closed. It does not make any sense. Any current or future Wikimania team should be able to access the wiki. Even if there is literally nothing useful there at the moment they might want to have a private wiki space for organisational purposes rather than rely on Google Docs or whatever else (which is also problematic from privacy perspective).

If the wiki is no longer in use

Well, in that case I would say that what this ticket requests is indeed needed. Besides it is not always that the message has to be deleted (e.g. a Sitenotice most of the time on most wikis would match the content from Translatewiki, but it should not be deleted), and it is a good idea to provide humans a way to easily spot such cases.

Perhaps it is better to use Wikidata items as the source of truth? They are more flexible than CLDR

+1, for Ukrainian Wikipedia should definitely be supported. While there is a Wikisource in Ukrainian (and a very active one too!), the kinds of texts it contains are often badly suitable for what Luthor is trying to achieve. For example many texts are entries from public domain encyclopaedias or dictionaries, or they are literature that uses orthographies different from the current one. Neither of those factors disqualifies sentences from being used as examples strictly speaking, but it makes them suboptimal for that. On the other hand I am sure that Ukrainian Wikipedia would contain many more sentences that are a better fit.

(Though perhaps it would be problematic in case of OC wiki, WMF staff wikis, etc; Perhaps something can be done about this Wikimania wiki specifically though. Of course perfectly it should be a responsibility of WM organisers to pass the access, this is no different from how Arbcoms do pass access one tenure to another well enough)

But that is not an active wiki anymore. This one is used for Wikimania planing: https://wikimania.wikimedia.org/wiki/2023:Wikimania

So perhaps Special:GoToLinkedPage can be extended to accept browser accept languages in addition to URL slugs?

As far as I remember I wanted to do something before I declare this ticket resolved, the problem is that I remember badly what it was by this time, perhaps I will manage to remember later

@DannyS712, who and when executes that script?

Perhaps the notification special page should support aggregation groups? The banners already produce a group each, so it should be relatively straightforward from then on, at least for less complex banners (that do not reuse messages from other banners that accordingly perfectly need to be added to the to-translate notification as well)

I see that https://www.elastic.co/guide/en/elasticsearch/reference/current/analysis-lang-analyzer.html does not contain Hebrew in its list. Is this what it is about? The links from 2013 do not make much sense a decade after.

Sounds like something that should eventually be implemented through Lexemes usage. It would be PITA to implement it as is. The task description is forgetting that adjectives can be gendered and declined in many languages, and thus the thing proposed would solve only a very small subset of the thing it is attempting to be about.

I am confused, locked accounts cannot login, how can they try to edit as that account? The only action that they can try to attempt other than login that I can think of is probably to reset their password (and I am not sure if that is allowed and whether it should be allowed). Is there something else? Perhaps someone can tell more from actually reading the code.

The links in the description are broken, but as far as I can see for example https://tls.theaterwissenschaft.ch/index.php?search=%C2%AB+Inhalte+%C2%BB&title=Spezial%3ASuche&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 still yields no results, while https://tls.theaterwissenschaft.ch/index.php?search=%22Inhalte%22&title=Spezial%3ASuche&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 does yield results.

I am not sure what the current consensus on this is, I will try to inquire with other community members. What I can say for sure is that we (as in the majority of ukwiki community) are annoyed at VE inserting <nowiki/> to separate «» quotation marks from the link. It should be handled by the parser this or that way, not by code artifacts.

Perhaps the signup page can contain some small "Advanced data" or "More data" or something along those lines spoiler title that will open up more fields, but would get unnoticed by most users. I mean that would virtually guarantee that most people would miss it anyway and keep the process as simple as possible for them, but some would have a chance to stumble upon this setting.

I guess structured data would eventually make categories useless anyway, but perhaps this can at least be implemented as a script that people can use. I think the main issue though is not so much the display, but rather the possibility to input category names in languages other than English and Binomial Latin. I constantly encounter en-0 Ukrainians attempting to use Ukrainian category names, for example, and some on the fly conversion would be helpful even if it would require enabling a script.

I guess according to https://stackoverflow.com/questions/8892238/detect-keyboard-layout-with-javascript it should be possible to come up with some logic to detect the layout (such as by comparing what character the key that corresponds to q on qwerty has produced). Not that it helps anyone as no one seems to be interested in implementing this (unless it is already implemented)

such titles can be *restricted* to accounts with a certain user right and a warning can be displayed to someone who is doing it.

In my patch I think I've fixed it for the top-10, but not for the bookshelves.

I see that helpers.formatNumber already has number.toLocaleString(); added by @codebug but it does not look like it picks the locale from accept language. And perhaps it shouldn't as while in the bottom table all the numbers should be using proper for Farsi numerals, as far as I understand also the number next to Farsi Wikipedia in the top part should be converted, and that should be happening independently of what user's accept language is (as it should follow whatever local the word "articles" is coming from).

Please next time allow the designated time of at least two weeks

As far as I'm aware, there's no precedent for Wikimedia staff to design or implement content pages to be used on the wikis

This may be different form an admin workflow where they may look for all languages where the translations is not complete (i.e., scanning through symbols first), for example.

It is empty for me (among other users). I am using Firefox for Android 120.0 (Build #2015986298), 039de7ef85+
GV: 120.0-20231116134553
AS: 120.0.1

Well, it is only true if there are namespace dupes :)

@Pginer-WMF, well, I use them in at least 3 scenarious:

The editor part does work, though I would still prefer a message that explains what those json configured thing actually expects. But I have stumpled upon a related bug, when I now opened the link to edit from my phone, mobile frontend version loaded. It shows an erroneous message saying that the editor will now load. Upon clicking the link there the second page opens which does have the error message.

NamespaceDupes.php is currently disabled

For the English Wikinews I see only one affected page,

{
    "pageid": 160790,
    "ns": 0,
    "title": "BBC: Ethiopian famine aid 'siphoned off' to buy weapons according to rebels, report"
},

but it would be a good idea to run the script in every single wiki as I assume there would be more wikis affected.

The same problem was in ukwiki, there were two pages with BBC:, I have just moved them manually via API (BBC: Дикі Кариби, and BBC: Life).

The deployments on ukwn and ukwq, as well as on Meta are still not undone. Opening the task back.

If possible, have a sense of quality: how many of the translations get reverted, percentage of modifications from the original suggestion, or similar.

@ovasileva, if you lack people in your team who are familiar with community processes I suggest you post a job posting for Wikimedians to apply as consultants. I am not sure why volunteers should be spending their valuable time to facilitate you in your paid work comprising pushing an unwanted product to the communities.

it is possible to add a comment without changing task status

As the other ticket was merged in I will also copy my comment from there,

I found that there was a notification on https://meta.wikimedia.org/wiki/Meta:Babel#The_Vector_2022_skin_as_the_default_in_two_weeks?_ . That is no place for such major sitewide change, it should have been an RFC instead. Babel is saturated with all different kinds of newsletters and nobody discusses important configuration changes there. Here is an example of RfC to introduce a configuration change: https://meta.wikimedia.org/wiki/Meta:Requests_for_comment/Adding_a_local_rollbacker_flag_or_alternatives . It would have been highly inappropriate to just write "we are having this change done in two weeks unless anyone notices this discussion and says no" on Babel. Please stop disregarding community processes and undeploy the change.

I insist on having the deployment rolled back from Ukrainian Wikiquote and Wikinews where I am an (interface) admin. There was an explicit NO to the proposal https://uk.wikinews.org/wiki/Вікіновини:Майдан#The_Vector_2022_skin_as_the_default_in_two_weeks?_ , https://uk.wikiquote.org/wiki/Вікіцитати:Кнайпа/Архів/2022#The_Vector_2022_skin_as_the_default_in_two_weeks?_ in both cases, nothing has changed since the previous proposal, but unfortunately what you, WMF guys, decided to do is to go ad nauseam and use attrition against the community: you posted the same wall of English text to the wiki where only few people understand English again and used no reply to it as an excuse to deploy this. If this is not rolled back I intent to use my Interface admin rights to roll back the changes with a hack, as as it is mentioned neither I nor other community members have the capacity to deal with all the changes that need to be done to adapt to the new skin.

There was no community consensus for this configuration change, why was it done?

resulting in «About half articles from CX2 have been reviewed as "Bad quality translation"». We analyzed the data further finding the deletion deletion rates for translations in the current (9.5%) or past year (6%) for Japanese Wikipedia were not matching the community perception

What can be more encouraging than to have your ticket closed as a duplicate of a bug from 14 years ago :)

Passer by comment, the paste name does not turn to a link for me so I assume it is private enough at least for that

The distinction is local rights are done via code, and global rights are done on-wiki. Yes, this is bizarre

Well, the premise of translate adminship was always that people need to go through a process to get those rights, such as to confirm and demonstrate that they are familiar with the relevant documentation. In some wikis admins can self-assign the rights, but I do not see why this should extend to global sysops, it is unlikely that a vandal would happen to be a translate admin and thus a translatable page would need to be deleted for CVN reasons.

Isn't "user profile" the most appropriate tab for something like this out of the existing ones?

I am getting tired being bullied by paid staff. I will reply when I have time, that might be in 5 years.

Hmm, that method signature would not get worse from getting another flag if that is what it is all about. (I mean not for me to criticise the code in the language I don't even know, but wtf those flags 😅...)

NoP is a global policy. Unless there is a global RfC to make an exeption, this should be declined. Boldly closing.

In enwiki only Create pages in the main namespace is restricted AFAIK, what is proposed here, at least the way the task is worded, seems to be several orders of magnitute more harsh.

What is a section?