To not repeat the same words, I explained it in the patch comments: https://gerrit.wikimedia.org/r/#/c/328590/ see the zhwiki example.

That is probably https://commons.wikimedia.org/wiki/Module:Fallbacklist in most cases. It requires a local admin, not developers.

What happens to the new page patrol logs and patroller flag related user right log entries in case the task is resolved?

(I got it returned in

select CONCAT("[[:{{ns:",page_namespace,"}}:",page_title,"]]")
from metawiki_p.page
where metawiki_p.page.page_len = 0
and page_namespace = 4

along a valid empty ns4 page
)

There's a gadget in Wikidata that they use to tag items for deletion. I
shall have a look at it and see if its use could be extended to Meta. We'd
also need a bot to remove deleted items from such a page to avoid it to
become flooded.

Wouldn't it be an overkill? I mean is the traffic of those RfDs that big to
raise up all this infrastructure of scripts, bot and so on? Just to be clear,
I am not opposing, just making sure that it's really worth the effort.

Ah, no, my bad. I thought it is about names of all the wikis, like the ones used in Echo. Well but anyway bringing a l10n guy here is a good thing O:)

@Amire80 I think it is connected to that language conjugation stuff you were doing, is it not?

Ah I think I have skipped the last paragraph, sorry. Well, in that case the change of the label itself makes sense to me, though it is not important a change.

The three immediate examples I can think of are the "Welcome, USER!"

I do both know the problem but yet agree that the task as it is should be marked as Invalid. @MarcoAurelio what we need to do is to make it clear for people that they should put those templates e.g. on Translations talk pages. Or they can put them in units still and we just need to be sure to realise that it is a single unit to be deleted, not the whole translation page. @Nemo_bis use cases to mark units for deletions are numerous, it is not uncommon for people to either put some gibberish, put English text or put machine translation instead of proper translation; in case of qqq pseudolanguage people also mistakenly add comments or translations (especially was the case till tux supported edit summary but I am not sure if it isn't now) — some of those are detected by non-admins and they want to nominate those for deletion. I used to do it a couple of times on Meta before getting the rights too.

(just it is the other way round to be precise :) )

( The finished query just in case someone wonders is http://tinyurl.com/j9bnkto )

Aren't there several such gadgets available already?

• https://www.wikidata.org/wiki/User:Yair_rand/WikidataInfo.js
• https://uk.wikipedia.org/wiki/MediaWiki:Gadget-WikidataLink.js

Are the ones I know, I am pretty sure there must be some other similar too.

Is it better now? (If no, well, I tried)

Ah sorry, I am somewhat English noun in-line placement abuse prone person :) Let me try to rephrase a little bit.

As I understand that is an easier to implement substitution for T153862 for the time being?

Interesting considering that https://pt.wikipedia.org/w/index.php?title=Wikipédia:Página_de_testes/1&oldid=47526682&uselang=qqx shows that message name.

The current ways are just insane:

• in order to ask system administrators you have to
  1. know the venue's IP beforehand which is very often not the case untill the event or the day before
  2. have your event not around any major wikimedia conference or US holiday in time, as otherwise system administrators are virtually unreachable
• account creation is the way, but it is worse psychologically or whatever wise: you want people to remember that they attended the event and did everything there themselves, since registration and every single edit from then on, while "Oh Wikipedia, now that you mention it I attended their event in the past and some guy even created an account for me, I wonder what it was called" is definitely what you want not

The ways which somewhat work are:

• Having people register beforehand (but sometimes you don't have a way to reach them or that is too difficult for them)
• Using random Central Auth wikis for different people, but for some the concept of going to another wiki is another piece of information they have to stack on the huge heap they are already expected to learn, besides just few wikis use the same language which is a problem for monolingual people.

But none is good enough to be satisfying.

I think both ways are desirable. Quarry-like interface for WDQS is already tasked at T104762. Quarry is exteremely useful in lots of ways. The easy typo fixing or code commenting without URL change as mentioned, being able to promise someone to write a query and provide a link there beforehand (much like with "red" pages, you can say "hey, look here tomorrow, there'll be something really cool"), being able to reuse old URLs which you needed only to show some number in a chat which noone would care about in 5 minutes and lots of other stuff.

I have zero clue about wikimetrics but quarry seems to support tcywiki_p at the moment, at least

use tcywiki_p;
show tables;

did return the table list.

@Smalyshev why do we have to stick to URL and its requirements. RDF seems to be all about IRI rather than URL, and those I believe allow Unicode.

For a brief span of time Russian name of pages like Special:Watchlist were the main ones. At least people were linking to those while discussing the fact itself, those I am sure I have seen. At worst there is high probability that there were normal usage links to them. Well, a fulltext search for most popular ones should be run. It is not worth speculating theoretically unless we are speaking about some third party sites (but I doubt there are a lot big Mediawiki instalations with Ukrainian as the main language in this world at all).

They were used a tiny bit when they were translated into Russian the very first time so that Ukrainian translators who consciously didn't want to translate them were caught up by surprise. Well and later when Russians were faster for a couple of days they were used too. At least usages being fruits of the first situation I am sure I have seen.
But I second Piramidion on the need to either deprioritize Russian aliases in search prompts or perfectly remove them from there at all.

Firefox for Android 49.0.2

@Nemo_bis, why have you created a category named in Russian in Ukrainian language Wikipedia? There's a separate Wikipedia, ru.wikipedia.org, for pages in that language.

(Oh I just noticed a ukwiki discussion mentioning all of this already. It would be nice if you mention related discussions, kinda saves the time)

(We even have an article https://en.wikipedia.org/wiki/List_of_tz_database_time_zones and @Sanya3 has already renamed entry for Zaporizhzhia there :) Too bad it is not that easy to change the actual thing :( )

I was going to report it upstream via php.net but found similar previous bug report in which it is said that PHP in its own turn uses names from IANA rather than defines them on its own: https://bugs.php.net/bug.php?id=70840

I took a closer look, it appears that [[ https://phabricator.wikimedia.org/diffusion/MW/browse/master/languages/classes/LanguageUk.php | LanguageUk.php ]] already has some default conjugation rules for some grammar cases. I did some test (archived version, for the sake of observing when software behavior changes are made) and confirmed that it was able to conjugate "Дурнопедія" (some theoretical Stupidpedia) into correct genitive form of "Дурнопедії" even though there is no explicit genitive case definition for "Дурнопедія" in WikimediaGrammarForms.php (and thanks Gods that there isn't :) ).
I guess thus it is absolutely possible to extend LanguageUk.php's convertGrammar function with default behavior for locative case then.

@Nemo_bis is it possible to make the default locative for GRAMAR:locative|{{SITENAME}} to be "у {{SITENAME}}" (with prepended preposition у) Mediawiki wide for Ukrainian?
That indeed should be done not in WikimediaMessages but in some upstream file.

Oh I see, I mixed some words in my comment which has probably rendered it virtually unreadible, it should now be better.

@Piramidion I think it is either that my reply wasn't clear enough or you did not read it completely, as not only it contains confirmation that I understand the current state of affairs but it also illustrates the downside of your proposal, and that is why I call it evil even if lesser one, but also there is alternate solution to the problem I propose which allows to get rid of both the downside I mention (inability to use different pronouns on per Sitename basis in your solution) and of downside you mention (my solution does not require an update of the translations which assumed GRAMMAR:locative working as it is now, though this one I as a bot master do not deem a major one).
As to your private conversation with @Ata on this matter that is not exactly what is usually deemed a community discussion here, I was conversing with her on this matter in the past too but I do not consider it anything more than a private conversation between two users. I do not have reliable means of communication with her as of now to boot, but that is irrelevant here. Anyway considering that only about 4 users have over 5k translations on twn for Ukrainian and not much more would understand what the issue in question is (you even doubted me, I in my turn allow myself to doubt many other users) that is not a big deal, e.g. I would more likely notice a task here as I did than a discussion on Ukrainian portal on TWN.

@Piramidion btw are you sure the по form is locative? I am no linguist to know for sure. I just noticed that it would be [пошук] по Вікістолу, while на Вікістолі — the noun form changes. I think it is rather dative or genitive in this use case.
I also see that you too mention на but I do not see how your solution which removes per wiki customisation of the pronoun (well if we do not consider those wikis creating local Mediawiki messages for all GRAMMAR:locative containing translations) solves it.

Locative is a full scale grammar case of Ukrainian language along with 6 others. Україна — в Україні: it is not always preposition + nominative case spelling.
The problem here is that though for current Wikimedia projects the preposition is always у, there might occur cases when it would be e.g. на. E.g. if Wikimedia Commons in Ukrainian were called not Вікісховище, but Вікісклад, as in Russian, then the correct locative form would be на Вікіскладі (since it is склад — на складі normally) and not у Вікіскладі. As I said it is not a problem with Wikimedia projects now but it might be in the future, also if we translate with assumption that there is no preposition in grammar form, thus by putting у, it would become impossible for e.g. third parties wikis to use correct preposition (i.e. if they just put it in the similar file they will get something like «у на Вікістолі» for some theoretical third party Wikitable project instead of desired «на Вікістолі».)
What is the real problem for translators now that while for Wikimedia wikis there are those forms with preposition defined, for default case they are not (which is not just third parties but e.g. chapters wikis or Meta) thus both using preposition and not using if before Grammar:locative is a bad idea (you might get two preposition together or vice versa not agreeed sentence). I rather agree though that between the two evils the proposed one perhaps is smaller, but @Piramidion, which discussion are you referring to?
@Nemo_bis, what I personally now see as a possible better solution is, if it is possible altogether, but I am rather sure it is, to set default locative form for any sitename. Thus making it «у {{SITENAME}}» for default case with then leaving room for overriding this value with concrete per name values. This default should be Mediawiki wide not just Wikimedia bounded otherwise it does not solve anything for translators. What do you think? I am not sure if I'd better put make it a separate task or we consider it as an alternate solution of this one.

Looking at this username is it really space and not & what is causing the problem?

{{int:something}} should be in user interface language. This is how it works everywhere and how is expected to work and should be. Is this about this kind of messages?

@Yurik, I must note that Graph is super uber mega ultra difficult as it is, with very poor documentation. It would become worse if you couldn't even use Jsons taken from upstream docs and examples. It is not the case for stuff like upload wizard campaigns where syntax is our own to take care of, so we can change it to whatever we want, but such things must be considered.

Autoimport of what? Without the context it is difficult to understand what exactly is the task about

I am pretty sure it was reported before, besides I am not sure anyone is gonna work on fixing a deprecated extension bug.

Isn't this a task which in the end with subsequent ones (versioning etc.) done results in more easy admission of non-TechCom members to the server? That thing would be very desired because there's clearly a manpower problem with all of the tasks.

Naming decision was made by the community. Lots more people than few doing it here.

Do I get it right that now a query cannot be longer than URL length limit? How much exactly is that number? I wonder if there were cases of people needing to run longer queries. Is this investigable somehow?

@Antanana perhaps you can add some description to the task? I feel very confusing looking at it now. I cannot even understand which wiki's page is it about.

Any chance of this getting done? Now each and every bot or Module or script working with something related to the wiki in context of WD has to have some ridiculous workarounds because of this. Like in my CEE Spring statistics bot I have to have lines like

Don't know if it's worth mentioning but took a look at the design suggested and thought about it: start and end date/time are not always in the same timezone. Like CEE Spring in Ukraine this year started by EET (UTC+2) and finished by EEST (UTC+3) due to DST. So perhaps hidden by default but there should be a separate timezone field for the end point accessible too.

I think Jean-Frédéric has done it

In T131132#2569951, @Liuxinyu970226 wrote:

First, hot do you think the "save" you seen, could also be an opposite of "Ctrl/Commond+S"? At least by clicking such keys, on either WikiEditor or VisualEditor, I've got a "save as..." popup, instead of action=submit, isn't this works not for you?

About the same would be on Google Docs, but I am pretty sure that users are capable of distinguishing saving changes (which on that platform is done automatically as the notice there says) and saving web-page of the web-service. At least those users who know about Ctrl+S/Menu-Save feature of the browser itself. The meaning of the word here is just the same so my point is unshaken, the different here is the context, what you apply the word to.

Sidebar? What if the code is being added in current edit?

In T131132#2425757, @Liuxinyu970226 wrote:

But save could also be something in the bank, or a thing that must do after earthquake/flood/tsunami... therefore I can't agree with him.

A person has to have really low IQ or other mental problems to not understand which of homonyms with completely different meanings is to be applied in current situation.
On the other hand both meanings of publish are applicable to the button and it is very likely that large part of the audience will get it wrong which is contrary to what is desired.

In T29987#2548573, @kaldari wrote:

@Base: Why would you want to catch "1488"?

Got tired reading all the comments. Does this task mean that if one would like to e.g. catch 1488 with a filter they would need to write L488 now or whatever?

@Nemo_bis please note that this is not a task about improving English Wikipedia content.

@Danny_B don't subsribtion and project field act differently? I am not sure what @Ahonc needed, but from my POV l, and I am a member of wlmuammxv team too, subscribtion does make sense.

[[MediaWiki:Parsermigration-new/uk]] New what?

I think a notice in other places like the mailing list and Facebook group should be left. People might have what to finalise there and need a poke for it in more watched place than the wiki itself.

What? Why should WMF staff care about it? Shared accounts are not even prohibited in all the projects. E.g. on Commons there is no rule I know which prohibits them. And in the projects where shared accounts are prohibited it is clearly the jurisdiction of local admins to deal with. In case if you are actually right and the staffers are indeed hunting such accs it looks like a serious issue to deal with.

Can someone do T137673, T137674, T137675, please? There is little sense in updating the stats if they are not being reflected. The tasks should be done regularly too, view top-10 in small projects isn't that stalled as in WP :) Probably portals not mentioned by me need to be taken care of too.

Oh he hasn't joined phab

Why do you guys not add @Amakuha also?

I do not think that e.g. TemplateData or Flow translation is what small wikis really need first of all. Just completing core MediaWiki and some more grounded extensions like AbuseFilter is of more import for those wikis, IMHO.

@Aklapper what do you suggest if people are more comfortable with tracking local stuff related to international project in their native language?

Would be nice to have something besides the most loved by WMF extensions.