I'm just an ordinary wiki user (not an admin, steward, sysadmin, developer, etc.). My home wiki is the English Wikipedia, but I have accounts on almost every Wikimedia wiki, with e-mail notifications turned on.
Sat, Oct 19
Thanks. Looks like that did the trick (AFAICT).
Fri, Oct 18
Just a heads-up: The last wiki created, banwiki, has had issues with imported pages not showing up in categories. A null edit fixes the problem for each affected page. This seems to suggest that importing was done before the wiki was properly configured to recognize the local prefix "Kategori:" as equivalent to "Category:". If this is the case, we should be careful to prevent this from happening again with monwiki (and in the future).
Tue, Oct 8
The short answer is: any use case that requires knowing and understanding the article count of a wiki.
Sat, Oct 5
@MF-Warburg and @jhsoby: another week has passed and nothing has been imported beyond a test page by Jon. Is there some other reason for the delay besides T233365, which was resolved? Was some problem revealed when the test page was imported?
Fri, Oct 4
Thu, Sep 26
Wed, Sep 25
Thanks. (Yeah, forgot to tag site-requests and remind to recount afterwards.)
Tue, Sep 24
Sep 18 2019
Sep 17 2019
Uh… so now there are no per-wiki settings in InitialiseSettings.php at all! What is going on? (T233069)
Let me ask this explicitly: How do I find the settings for a specific wiki as a "normal user" (not a sysadmin), now that InitialiseSettings.php is devoid of per-wiki settings and VariantSettings.php apparently is not to be trusted?
Change was made by @Jdforrester-WMF (pinging).
Sep 16 2019
Another FWIW: I checked the last wiki to be created before this one (Western Armenian Wikipedia, which also had problems during its creation—see, e.g., T212597#5065429), and the content-page count over there (7,478) is entirely reasonable given the count of non-redirects in the main namespace (7,626) and the apparent level of linking seen in its articles (30 out of 30 randomly chosen main-namespace pages contained wikilinks).
OBTW, FWIW, on Sep 9 (I think it was), I went through and null-edited every page in napwikisource's main namespace. It didn't seem to have any immediate effect on the content-page count, but I mention it here in case its effect was only seen when the wiki was recounted just now. (I don't know how likely that is, but it doesn't look to me like the increase in count from Sep 1 to today can be explained solely based on on-wiki editing activity. I could be wrong, though.)
I hate to butt in here (OK, not really), but could the problems being discussed here possibly explain (and maybe ultimately lead to a fix of) the weirdness that is being seen in the content-page count of napwikisource, as discussed at T231770?
FYI, the wiki was just recounted again (on September 15th), and it again gave an impossible number. So, the situation has not improved. In fact, the count seems to be diverging even farther away from the correct count.
Sep 11 2019
Note that this continues to confuse MediaWiki users.
Sep 10 2019
Are people actually reading this thread, or are they just skimming and trying to get the gist of what is being said?
Sep 9 2019
…Or am I just misunderstanding and this (@Zoranzoki21's suggestion) is not being proposed as a "permanent fix" to the problem?
OK, it's fine to seek consensus about this change, but why is this the proposed solution to the reported problem? This is not trying to fix the underlying issue (whatever it may be), just trying to avoid it — and doing so in a way that presumably will not be acceptable to at least some wikis that may encounter the same problem in the future (so this cannot be used as a general workaround).
Sep 8 2019
Sep 6 2019
OBTW (again), I guess I should have also pointed out that the total number of pages in the main namespace (including redirects and the Main Page) is now 206 (would have been 205 on Sep 2).
BTW, I already acknowledged the 'link' counting method was being used in the task description. My point about "non-redirects in the main namespace" is that the count given by 'link' should not be higher than the highest possible count 'any' could give, which in this case is (or was) 183.
Sep 5 2019
I can't really help with this, since I don't know which configuration allows for the kind of automatic translation you're talking about (I'm not a sysadmin or developer).
The kind of configuration quoted in the description seems to be the standard way of handling the "Author" namespace.
Sep 3 2019
Sep 2 2019
For what it's worth (which may well be nothing), I think changes such as replacing:
Aug 13 2019
Jun 27 2019
Also, for the record, the output from "first namespaceDupes.php (without --add-prefix, ran on all wikis)" is at: P8676
Was the processing of hewiki completed? I see an error message in that part of the P8677 output.
I have no objections (FWIW).
Jun 4 2019
May 29 2019
@Urbanecm I see you ran namespaceDupes.php on urwiktionary (twice) and aswikisource, but did you run it for urwikibooks (I guess so, given your last comment above) and urwikiquote?
May 25 2019
@Tulsi_Bhagat please note that @Urbanecm has submitted a patch similar, but not identical, to yours in response to T223039: Project pages inaccessible on several projects because of spaces in wgMetaNamespace(Talk):
@Urbanecm please note that @Tulsi_Bhagat has submitted a patch similar, but not identical, to yours in response to T223964: Change spaces to underscores in values of $wgMetaNamespace for urwiktionary, urwikibooks and urwikiquote (which I opened on May 21 because I wasn't sure the change would actually fix the problem being discussed here -- plus, no one seemed to be doing anything in repsonse to this task):
May 22 2019
May 21 2019
The changes requested in this task seem to have been incorrectly implemented, as discussed at T223039#5186164. I have opened a new task, T223964, to fix the problem. (Sorry if I should have just reopened this task. I have been criticized in the past when I tried to fix incorrectly resolved tasks by reopening them.)
May 16 2019
OK, wait a minute. I think I might know what the problem is.
Renamed this to reflect the actual problem currently being observed.
May 14 2019
I think the task title still does not reflect the real nature of the problem. Here's what I am seeing...
May 9 2019
May 8 2019
@kerberizer: "on the right track" towards what? Having the request fulfilled or declined? I don't underdstand what you mean.
May 7 2019
Oh. Thanks for linking to the relevant task.
Apr 27 2019
Apr 16 2019
Note, by the way, that this wiki was presumably due to be counted in the morning of April 15th, anyway, as part of the regularly scheduled semimonthly recount of all Wikimedia wikis (T59788).
Apr 14 2019
Mar 19 2019
Sorry, but I just have to point out (as a "lurker" with no power to make or implement any decisions here):
Mar 18 2019
In a modern web-browser, you get a regular looking wiki page with a sitenotice and deletion notice, as discussed above.
Mar 3 2019
(For future reference, @Leaderboard, you shouldn't rely solely on the task title to communicate what is being requested, since the title can be changed at any time. I took the liberty of copying the title into the task description.)
Mar 1 2019
I know very little about the possible ways this could be done, but off the top of my head:
Feb 7 2019
Forgive the intrusion, but… why can't things like this be discussed on the wiki itself?
Dec 27 2018
This might only be a problem with lists. I'm not sure. Also, I don't know if it depends on the formatting used in the lists (i.e., multiple lines not formatted in any particular way vs. lines prefixed by "-" markup vs. lines prefixed by "*" bullet points).
To explain what is seen in the diffs, and what I'm objecting to:
(I assume this is not the first request of this kind, but I couldn't find a similar task in a search. Please close this as a duplicate, if necessary.)
Dec 26 2018
Also known as 2019-01-10. [grin]
Dec 5 2018
I believe it's still just twice a month, on the 1st and 15th. Next recount should therefore happen in 10 days (Dec 15th).
Nov 29 2018
Sep 27 2018
@Urbanecm, sorry for bugging you Yet Again, but could you please see the latest comments (made on "2018年9月26日") at v:zh:Wikiversity:互助客栈#School,_Portal,_Subject_namespaces, and comment there?
Sep 24 2018
So you're suggesting that, apart from using the jobqueue, the maintenance script would do the exaclty same thing(s) with broken redirects (not duoble redirects) that redirect.py currently does? Or would it handle redirects it cannot "fix" differently? (Just wanted to clarify the request — it's not like I can actually help write the script.)
Sep 22 2018
The following PrefixIndex searches in the "Talk:" namepsace still bring up page titles with the prefixes "School:" and "Subject:", but clicking on any of them (that I checked, anyway) results in a "Bad title" error:
Sep 7 2018
Oh. In that case, @Urbanecm, have you checked what I said at v:zh:Wikiversity:互助客栈#School,_Portal,_Subject_namespaces to make sure it matches what you are planning to do?