I imported the pages. Can you please run the scripts to update the statistics etc.?

I deliberately omitted those as they won't conflict with the import.

Sorry, I didn't see the wiki already exists. I deleted the few pages which still were in it now.

That works.

Langcom has reviewed the concerns and found them unfounded. So please continue with the creation of the wiki.

Thanks for this reply. I think that settles it.

On 5 July.

Does "I would rather get mediawiki handle its deleting and all the related checks to be honest." mean you would like to have a function in MediaWiki that can delete the wiki's database? Or just that the pages in the wiki should be deleted using the normal MediaWiki interface?

How can we solve this? As it works for non-Wikipedias, can't we create an exception for Wikipedias that will fix the link for them?

So is creation the redirection without deleting the databases a reasonable way forward?

How is this blocked on global preferences? I'd say the first step would be
having a preference for this at all, then it could at least be set
individually, e.g. after getting the first such notification.

It is reported to me that the VisualEditor and the "2017 wikitext editor" don't work on the wiki.

But that is irrelevant for the bug:

All pages have been deleted.

In T168764#3382535, @Luke081515 wrote:

We can add .* to the TBL after removed from closed lists to prevent new pages before import finished.

In T168764#3381334, @Urbanecm wrote:

In that case I think the requestor (or somebody else) should delete all pages and import new pages from incubator. I'll create a patch for reopening the wiki after it (or, if it should be reopened before deleting/importing, let me know). Is it okay for all?

Ok. Please answer my question in return.

Yes.

It still isnt possible to enter Rangi content in Wikidata. How long does it take for this change to go live?

On the other hand, srwiki is quite old, whereas atjwiki was recently
created.

Why would consensus be needed for this simple localisation?

Sysop requests can be posted on m:SRP after a local discussion happened.
Bureaucrat rights will not immediately be granted on new wikis.

In T166132#3286304, @Nikerabbit wrote:

I'll state the perhaps obvious, that the other option is to lower the export threshold for core even further. Like, if we really want to go to the way of encouraging translators, we could lower the export threshold to much smaller, and guard their visibility with $wgShowLanguagesWithMinimalLocalisation, disabled by default, but could be enabled for Incubator and so on.

Langcom has no problem with this; in fact Baba_Tabita is himself a member of Langcom.

This task is not stalled. It is invalid as long as the project isn't approved by Langcom anymore.

I see you are right.
I suggest so, but if it only concerns the main category page and is limited to editinterface people, it is basically a non-issue. You can close this if you want.

Please don't proceed with the creation of the wiki at the moment.
A more detailed explanation will be given soon.

In T160868#3117377, @Dereckson wrote:

@MF-Warburg Wikimedia language engineering isn't currently happy with translation progress: they would like 100 more messages translated, as requested here last year.

I asked on https://meta.wikimedia.org/wiki/Requests_for_new_languages/Wikipedia_Kabiye#Other_discussion

In T54971#3060413, @Candalua wrote:

The original request is that it should be possible to add sitelinks using any of the language codes that don't have a subdomain, which I guess is the difficult part. But can we just use one language code ("mul" seems a good candidate) to identify the Incubator / BetaVersity / MulSource projects, and add sitelinks using that code, and that code only? This should be easier to implement, I suppose. It would be much better than doing nothing, and it could be a first step towards the complete solution.

IIRC, Wikisources have the "Page", "Page talk", "Index", "Index talk" namespaces and the translation for those is usually given in the bug report to create the wiki, as they are not translatable on TWN. Correct?

Everything is already arranged about that.

Solution: It works correctly, except for the main category:
https://incubator.wikimedia.org/w/index.php?title=Category:Wp/olo&action=edit can be edited
https://incubator.wikimedia.org/w/index.php?title=Category:Wp/olo/Filosoufii&action=edit cannot be edited

Why is this even a separate bug?

In T151186#2814687, @Esc3300 wrote:

@MF-Warburg would you like to add something from the lang-co perspective?

In T149522#2755130, @Krenair wrote:

It doesn't look like this has language comittee approval

In T28725#2552717, @Liuxinyu970226 wrote:

Not sure if this is still needed or not, one user created Wp/syc on Incubator, which is probably planning to create a sycwiki

In T135452#2388513, @Glaisher wrote:

It is false because of the way it was originally set on wiki. It could also be modified on wiki to accurately be shown on that page. I think it has been like that always so I don't know whether it should be changed now on CA so that it is correct just there.

In T135452#2372417, @Glaisher wrote:

Exactly how does this change make it difficult to find a specific group's information? I agree that the page is now quite long on Wikimedia wikis but I don't understand how it's making it difficult to find a group information. If it does help, we could try to add a TOC so that it's easier to jump to a group.

Very strange. I don't remember on which page I noticed it yesterday (I deleted 3 ex-test-projects, in one of them I saw it). Restoring a page also can't reproduce it.
We can see whether it occurs again when a new subdomain is created.

Btw, there is also a bug: No distinction between opt-in and opt-out wikisets leads to "Set of wikis where this group is active: Opted-out of global sysop wikis".

Please revert this change. The page is now way too cluttered with the high number of global groups that exist. In the previous mode, it was way easier to find the group about which one wanted to find out something in the moment (I don't believe people often visit this page to read about all groups' rights at once).

I'm fine with requiring the namespace translations (is there no way anymore
to translate them through twn?), but the upload wizard is not required by
the Language proposal policy and should not hold up the creation of the
wiki.
Am 30.04.2016 18:08 schrieb "Dereckson" <no-reply@phabricator.wikimedia.org

:

What about setting wgUseSiteJs to true again? It's not like anyone who is not a steward could insert code to it.

For the record, it used the function of https://incubator.wikimedia.org/wiki/Special:SearchWiki.