Change 393289 abandoned by MarcoAurelio:
[WIP] puppet: redirect several wikis per LangCom decission

Reason:
Per T169450#3804370.

https://gerrit.wikimedia.org/r/393289

Can we get some more details on why such changes would not be desirable? As time passes, chances are that the list of required closures will get bigger.

They told me that we're leaving wikis in a weird state. That is, innacesible via web but still existing and leaving traces at CentralAuth, CentralNotice, etc. I am not sure if there are more concerns but those with knowledge might weight in/follow-up shortly.

MY personal choice would be to delete the projects that are no longer valid, and then setting redirects, but I don't take the decisions here ;-)

This is crazy. The whole reason this version of the task asks to set up with redirects is that we were told that it would be technically too problematic to delete the databases. Now they complain about this. The Board has approved the effective deletion of these projects. Figure out how to do it.

We're not saying we necessarily need to delete them. But there's certainly cleanup that would have to be done in one way or another

Basically, it's not just as simple as "redirect them"

Fine. What LangCom wants, and what the Board has approved, is for these projects to functionally disappear (to the public) in favor of their targets. It doesn't matter at all to us how you think you'd like to do it. We're not wedded to this task; we just want to get to that end.

@Reedy , I think that the most important is to know if the Ops team is actively working on a solution for this and if not, when does the team plan to allocate the time needed for it?

If the Board has approved the deletion of them, why don't we simply delete them the old way? Jesus... I feel this is going to be the easiest solution to this problem. After they are deleted we can set up redirects later from mo.* to ro.*.

MariaDB [centralauth_p]> SELECT COUNT(*) FROM localuser WHERE lu_wiki='mowiki';
+----------+
| COUNT(*) |
+----------+
|     2157 |
+----------+
1 row in set (0.01 sec)

MariaDB [centralauth_p]> SELECT COUNT(*) FROM localuser WHERE lu_wiki='mowiktionary';
+----------+
| COUNT(*) |
+----------+
|      401 |
+----------+
1 row in set (0.01 sec)

This is way below the limit set in the Wikitech guidelines. As for the extra good reason, the Board approves this, which its the ultimate manager of the Foundation and its projects, so can we just do this?

In T169450#3806675, @Strainu wrote:

@Reedy , I think that the most important is to know if the Ops team is actively working on a solution for this and if not, when does the team plan to allocate the time needed for it?

I'm pretty sure they're not, and I suspect they have no plans to allocate any time to do so.

Once again, let me emphasize what LangCom decided and the Board approved: We want the five redirects shown in the Description of this task to happen, so that the deleted projects no longer appear to the public. How that happens is pretty much unimportant.

As I am seeing the discussion roll on here, I'm noting:

• On one hand, deleting a database completely from all servers is a lot of work, and the developers are not very enthusiastic about that.
• On the other hand, the developers are also not enthusiastic about having the databases still exist, but having no pointers in the ordinary list of servers going to them.

So, put another way, the developers are disinclined to allow these projects to disappear. But since this is ultimately the Board's call, we need some kind of answer. If the developers don't like the two suggested above, do the developers have a different proposed approach?

Let me make a couple of different suggestions:

• Create some kind of new domain ... call it "wikimorgue.org", if you like. Let any databases marked for deletion become 01.wikimorgue.org, 02.wikimorgue.org, etc. Prevent them from being indexed by search engines, and leave them out of the public list of wikis. But then they still exist, and can still have a unique pointer within the system, at least on a private list of wikis. Then the requested redirects can be created.
• If nothing else works: Create a unique skin for these projects that has no navigation links whatsoever, and that hides the search bar. Mark every single page of each project as NOINDEX. Then turn the main page of these projects into soft redirects. There is still the possibility in these cases that someone could actually type in the proper name of a page, or even type in a search using a url (.../w/index.php?search=...). But that would make anything in these projects very hard for anyone to find unless s/he was working very hard to do so.

My own preference is still for the projects to be backed up to xml files and then deleted outright. But I think the most important thing is for them to disappear to the public.

I must apologize in advance if my impression is not right, but I don't think being combative is helpful here @StevenJ81 (my personal feeling as non-native english speaker).

I think there's no doubt that the Board holds ultimate authority of course, and I think we all should rest assured that their decission will be acted upon. I did my entirely volunteer part already at T181923 and T181925 and its patches for review. I can do nothing more.

I think the easiest way to achieve, this, at least with mo.* is still having them deleted. But to do that we need (and let me emphasise that I'm just a volunteer and that I do not have a deep knowledge about all this) is to happen simultaneously the DB handling and after that, merging the patch which sets those databases as deleted. This requires, I think, that DBA and Ops arrange a window to do this and both teams have their work to do and their agendas not always match. Add that wiki creations, closures and deletions have never been top priority tasks. Not to talk that maybe DBAs want to backup the wiki DBs just in case. I don't know the whole internals of the process. Closing a wiki is more straightforward; deleting a wiki requires more steps.

In any case, I don't think anyone has forgotten about this task. I trust they will find time to do this once they have some spare time in their schedules. If however the Board or the LangCom would like to speed-up the process my suggestion is that they contact @VColeman or @Katherine-WMF.

Apologies for the lengthy post and if I got you wrong @StevenJ81; you know that I appreciate you and your work.

Best regards.

Just trying to understand the context - what the original ticket states is we need to redirect from those domains to others. So the expected result is that if I type 'mo.wikipedia.org' in my browser, I'm redirected to 'ro.wikipedia.org'. Correct?

That is accomplished with a redirect in the apache configuration of MediaWiki, which is managed by the operations team. Anything else that involves renaming wikis or deleting wiki databases is way more complex and AIUI not easily doable at the moment, without investing resources in making that process work. Just renaming/deleting the databases will break things, but that is not needed to obtain the desired result.

I think we could just stick to the letter of the ticket and implement the redirects. Or am I missing something?

(Also, adding the SRE tag so that this ticket gets noticed by us).

In T169450#3812405, @Joe wrote:

Just trying to understand the context - what the original ticket states is we need to redirect from those domains to others. So the expected result is that if I type 'mo.wikipedia.org' in my browser, I'm redirected to 'ro.wikipedia.org'. Correct?

Yes that's the idea, however:

That is accomplished with a redirect in the apache configuration of MediaWiki, which is managed by the operations team. Anything else that involves renaming wikis or deleting wiki databases is way more complex and AIUI not easily doable at the moment, without investing resources in making that process work. Just renaming/deleting the databases will break things, but that is not needed to obtain the desired result.

I prepared a patchset some time ago setting a rewrite for those projects but @Reedy told me that simply doing that would result in a phantom wiki existing but not accesible. Still it'd exist in, for example; CentralAuth and other places. Since I see you handle most of the puppet stuff, maybe you can also shed some light on what would be the effects of that?

Since we were told that "redirecting them was not enough" I've prepared a patch to get them deleted instead and thereafter create the redirects, so I abandoned it.

I guess what is really needed here is to decide the approach and then follow the steps to complete it. Currently we are blocked on not knowing which path we want to take I guess.

As far as I understand, the Board gave green light to get rid of mo.* and als.* sister projects.

I think we could just stick to the letter of the ticket and implement the redirects. Or am I missing something?

Probably that there's still no decission on how to implement this without causing unneeded alterations (either deleting or redirecting and leaving a phantom wiki).

(Also, adding the SRE tag so that this ticket gets noticed by us).

Thanks.

Well, that's why I suggested creating this "wikimorgue" (or whatever) name. This gives the phantom wikis names so that they can be accessed. But that name (whatever it ends up being) shouldn't be public, so that the "deleted" wikis can't (easily) be accessed publicly.

BTW, @MarcoAurelio, I didn't mean to come off as combative (and don't think my comment actually was, to a native speaker at least). But I apologize if I came off that way.

Afaiui nobody cares about the database still existing but nothing pointing to it. I read it as all the worries expressed being about different places in mediawiki (!= database) linking to a site that doesn't exist. For example we wouldn't want the site matrix to link to mowiki, and clicking that link taking me to a page that just redirects to rowiki, which is an example for what a was called a 'phantom wiki'. So as Reedy said there is some cleanup needed here and it's more work than just creating a link in the apache config. But I don't think someone actually said that it'd be necessary to delete the database from the mysql servers.

After reading to the whole of this discussion, I still don't get what's wrong with following https://wikitech.wikimedia.org/wiki/Delete_a_wiki . That page has no note about deleting the actual database (well it actually has, in a sentence the gist of which is "we don't do that"). It's all about config changes and how to do the cleanup necessary for things like centralauth, global image links, jobqueue, etc.

@StevenJ81 Sorry then for getting you wrong.

@EddieGP Yes, I think we should not try to make exotic solutions for this case; that's why I propose to follow the standard wiki deletion process and then having an apache redirect created. Is it possible to avoid a "phantom wiki" and not messing with the database? That I don't know, but in case of doubt I think we should do it the old way since we know all the potential problems that can appear.

Thanks.

In T169450#3815834, @MarcoAurelio wrote:

@EddieGP Is it possible to avoid a "phantom wiki" and not messing with the database?

Depends on your definition of "phantom wiki" and "messing with the database". If "messing with the database" means "deleting the database for that wiki" then yes, it's possible.

There's three things involved in a request for the a wiki, let's name it "foowiki":

• Apache, which has to be configured to point foo.wikipedia.org to mediawiki
• Mediawiki, which has to be configured to use the "foowiki" database for requests to foo.wikipedia.org
• The database "foowiki" on the database host

Now the thing is, you can make mediawiki do things to the "foowiki" while your browser is at meta.wikipedia.org (e.g. change userrights by appending @foowiki).

So, to remove a wiki:

1. tell apache to redirect foo.wikipedia.org to bar.wikipedia.org
2. remove mediawikis knowledge of "foowiki"
3. drop the database "foowiki"

If you just do the first, you'll get a phantom wiki: Creating a redirect will tell apache not to point foo.wikipedia.org to mediawiki any more, but instead redirect them. However mediawiki will still treat the wiki as existing when asked for it through e.g. meta.wikimedia.org, for example by CentralAuth or SiteMatrix. This weird state is what we called "phantom wiki".

If you just the second, you'll get weird errors when accessing foo.wikipedia.org because apache tries to hand the request over to mediawiki, which doesn't know about that URI.

If you do both 1 & 2, the URI is redirected and mediawiki doesn't know about foowiki any more, so it'll never connect to the database "foowiki" (obviously, it can't connect to something it doesn't know about). So we need to do both of these to remove the user-facing part of a wiki completely. What you, @MarcoAurelio did, was solving the first point. What https://wikitech.wikimedia.org/wiki/Delete_a_wiki documents is how to do the second, but there is no guarantee that documentation is complete, so we might will (Murphy) run into weird things when doing the second thing (we'll have it do it anyways). And doing the second includes some database queries, for example to the centralauth db. It does not require dropping the actual database though.

Do we really need to do the third point? Well, after doing 1 & 2 we've come to the point when nothing knows about that database any more and nothing connects to it any more. So you can drop it and that's fine, or you can leave it there by itself and forget about it, that's fine too. Now, the DBA said dropping it is a PITA, so why should we do it? It doesn't have any user-impact anyways.

@EddieGP I guess 1 was https://gerrit.wikimedia.org/r/#/c/393289/ and 2 is https://gerrit.wikimedia.org/r/#/c/394846/ ; if 3 can be avoided then okay.

@MarcoAurelio
You're right about 1 at least. As far as I see we won't need any other Apache change (the virtualhost uses a wildcard ServerAlias, so nothing to remove there).
About 2, I'd like to avoid a possible misunderstanding: "2 is https://gerrit.wikimedia.org/r/#/c/394846/" is true if you mean that the patch is part of the second step. It is wrong if you mean that the patch is all of what is needed in the second step. Looking at https://wikitech.wikimedia.org/wiki/Delete_a_wiki and comparing to what was done in your patch:

Remove the wiki from wikimedia's wiki configuration:

• Remove the wiki from all.dblist and any other dblists it exists in
• Add the wiki to deleted.dblist
• Remove all other references from CommonSettings and InitialiseSettings etc.
• Remove the logo from w/static/images/project-logos

We can only do that "Remove the wiki from wikimedia's wiki configuration" in a patch, the other parts need manual intervention from SRE, as these steps need prod access to the database hosts (centralauth and globalimagelinks cleanup, removing replica views, remove private data from some tables) and the maintenance script host (for clearing the jobqueue for that wiki).

Can we swap the order on these changes? First, redirect the domains to the proper wikis (leaving the wikis in an invisible state temporarily), and if that goes well, we can then slowly drop the invisible databases without it holding up the Board/LangCom request.

Note that 1 is abandoned as I was not able to run the ruby script to convert the dat to conf or vice versa. Given that rOPUP is fast-forward only, I'd rather create a new patch than to potentially mess with a manual rebase.

@Legoktm Looks good to me.

In T169450#3825066, @Legoktm wrote:

Can we swap the order on these changes? First, redirect the domains to the proper wikis (leaving the wikis in an invisible state temporarily), and if that goes well, we can then slowly drop the invisible databases without it holding up the Board/LangCom request.

How is that swapping the order of the changes? I might not get what you're refering to, but what I named as #1 is creating the redirect in apache (which indeed is "redirect the domains to the proper wikis"). Besides of that, yes, I think this is the best way forward.

Change 393289 restored by MarcoAurelio:
[WIP] puppet: redirect several wikis per LangCom decission

Reason:
Second try.

https://gerrit.wikimedia.org/r/393289

I hate this script:

/modules/mediawiki/files/apache/sites/redirects (review/marcoaurelio/T169450)
$ ruby compile_redirects.rb
compile_redirects.rb:1: syntax error, unexpected ..
../../../../lib/puppet/parser/fu
  ^
compile_redirects.rb:1: unknown regexp options - lb

Well. The redirects apache config is done. Can we deploy this now (next puppet swat window) or do we have to do something else first?

In T169450#3826244, @MarcoAurelio wrote:

Well. The redirects apache config is done. Can we deploy this now (next puppet swat window) or do we have to do something else first?

Well yeah, we can deploy this now. I'm not sure whether they're going to do an apache change in puppet swat or want some specific opsen to do it- ops are understandably careful especially about apache & varnish changes (it's probably one of the easiest ways to break the site). I'd say the best way to find that out is to try and let them tell you though ;-) If possible I'm going to try to be around during the window. :)

@Dzahn (not sure if you handle this stuff): can you please coordinate with @greg in finding a date to merge the redirecting patch? Thanks.

In T169450#3827175, @MarcoAurelio wrote:

@Dzahn (not sure if you handle this stuff):

Sorry, i don't.

@Joe As you've already commented here, could you help with deployment of https://gerrit.wikimedia.org/r/#/c/393289/ ?

Change 393289 merged by Giuseppe Lavagetto:
[operations/puppet@production] apache: redirect several wikis per Board of Trustees and LangCom request

https://gerrit.wikimedia.org/r/393289

Change 397793 had a related patch set uploaded (by Giuseppe Lavagetto; owner: Giuseppe Lavagetto):
[operations/puppet@production] mediawiki: use utf-8 encoded redirects for mowiki

https://gerrit.wikimedia.org/r/397793

Change 397793 merged by Giuseppe Lavagetto:
[operations/puppet@production] mediawiki: use utf-8 encoded redirects for mowiki

https://gerrit.wikimedia.org/r/397793

With my latest patch, all redirects (including the mowiki and mowiktionary ones) work as expected. It will take some time for the infrastructure to catch up, but probably not too long. The code can be tested with X-Wikimedia-Debug set to mwdebug1001.

@MarcoAurelio in my tests the redirects all work now, can you confirm they're ok? If so, should we close this ticket or wait for someone to fix the mediawiki config as well?

I can confirm the redirects work as intended.

Sorry for the late reply and thanks @Strainu for testing, @EddieGP for your guidance during the process and @Joe for merging the patch and fixing the later issue :)

Moldavian: about the renaming/redirect from "mo.wiki(pedia|dictionary).org" to "ro.wiki(pedia|dictionary).org", this should not alter the pagename (the path)

But the redirect could pass a parameter instructing to use the cyrillic script ("mo" is just "ro" transliterated from Latin to Cyrillic).

But I don't know if the transliterator works as expected (in both directions) and if there's an active support for "ro-Latn" and "ro-Cyrl" variants like there's one working for Chinese between "zh-hans" and "zh-hant". If it does work, the redirect could set a "?uselang=ro-cyrl" parameter (or append a "&uselang=ro-cyrl" if there are other parameters), but not change any parameter that if there's already an existing "uselang=*" parameter. Note also that a parameter "uselang=mo" (deprecated) is equivalent to "uselang=ro-cyrl".

The transliterator is not active on the Romanian projects.

Note also that "uselang=mo" really displays a Romanian-Cyrillic UI, but "uselang=ro-latn" just renders as an English UI !!! This is still a bug as we should at least see the UI in Romanian as a fallback, possibly via the transliterator to Cyrillic.
The internationalization libraries should be updated, and existing Moldavian translations in translatewiki.net (with "mo" should be reimported there to "ro-latn" and possibly reviewed).

@Verdy_p , where is ro-latn defined and why do you expect it to work?

So now with the redirect being active, you've dropped completely the capability of contributing and displaying the UI in Cyrillic. This should be restored at least with an active transliterator.
Without it, I'm sure that Moldavian users are really unhappy (some of them possibly furious) as we force them to have the UI completely written in English Latin.
Also the previous Moldavian site should still be accessible in readonly mode (notably user pages so that users can retrieve their profiles and setup their new user page on the Romanian site.
the previous content "mo.*.org" should remain accessible via "mo-x-old.*.org" and the Moldavian databases '''not''' deleted but only made readonly.

You seem to be behind on the news: the language committee has decided that mo.wp should be deleted, not just closed, following the RfC at https://meta.wikimedia.org/wiki/Proposals_for_closing_projects/Deletion_of_Moldovan_Wikipedia_2

The transliterator is strictly a local decision that should be taken on the Romanian Wikipedia, but no-one cared enough to open a discussion there. Until this happens, the changes you propose remain strictly theoretical.

"ro-latn" and "ro" are the same.

I don't want this addition as a separate locale (these can be simply aliases), but "ro-cyrl" is still needed and should get the UI translations that were used in "mo".

A transliterator could be setup and activated for reading articles at least (with the variant selector tab like in the Chinese wikipedia), and optionally for writing articles (but only on demand as we don't want to have some text fragments actually in Russian or Bulgarian to be transliterated automatically by the wiki editor to Latin)

The comity can decide what they want. It was NOT requested to *delete* Moldavian but merge it to Romanian. Dropping all Moldavian user contents is very unfriendly and Romanian users should not have any problem if they see the addition of a variant selector in their wiki (and especially for user pages and user talk pages, which is NOT in scope of decision of this VERY SMALL comity which did almost no contributions to these wikis !)

Blocking all access to Moldavian user contents is extremely damaging (that why I ask for keeping it accessible in read-only mode via an alternate subdomain like "mo-x-old"). The user pages and talk pages in this wiki may eventually remain writable by their existing users only, no new users could register there, no new user page could be created, but these users can still perform some cleanup or tests there, before reimporting selected parts of their choice to their new user pages on the Romanian sites.

In T169450#3836899, @Verdy_p wrote:

The comity can decide what they want. It was NOT requested to *delete* Moldavian but merge it to Romanian. Dropping all Moldavian user contents is very unfriendly and Romanian users should not have any problem if they see the addition of a variant selector in their wiki (and especially for user pages and user talk pages, which is NOT in scope of decision of this VERY SMALL comity which did almost no contributions to these wikis !)

Please read the RfCs (plural) regarding mo.wp before making such claims. Currently you're just expressing your wishes, which happen to go against the existing consensus.

The consensus was only to join the two communities so they create a joint content without dividing it, Blocking all accesses to past users contents is simply against all existing Wikimedia policies. The existing Moldavian was licenced correctly and not supposed to disappear completely and suddenly.

Look at what happened to "sh" after the split to "sr", "hr", and "bs": "sh" is still live (and not even in readonly mode) and this does not create any problem to the 3 wikis (and actually "sr" still has a Latin<>Cyrillic transliterator just like a few other languages: do they complain about this presence? No, it is seen as bonus which reinforces their cohesion on the same joint project just like it happens with Chinese)

I stroingly support the merging of efforts, not the exclusion of one community by another.

In T169450#3836846, @Verdy_p wrote:

Moldavian: about the renaming/redirect from "mo.wiki(pedia|dictionary).org" to "ro.wiki(pedia|dictionary).org", this should not alter the pagename (the path)

I mentioned the possibility of this on the patch, and I'm quite sure some gave an reason why we should use funnel and not rewrite, but unfortunately I can't find it anymore (neither in the task nor in gerrit, maybe it was on IRC).
The question here is: If an Article with the title "Foo" (take this as a placeholder, I can't write cyrillic to demonstrate what I mean) existed on mo., will the same page (the same topic) also be named "Foo" on ro? If yes, then it'd be a good idea to redirect https://mo.wikipedia.org/wiki/Foo to https://ro.wikipedia.org/wiki/Foo, but I suspect otherwise: If they use different dialects and different alphabets (one cyrillic, one latin), it likely is the case that a page named "Foo" on mo. will be named "Bar" on ro. "Foo" and "Bar" may be logically the same word, but they aren't equivalent to the software if they are written in different alphabets. So in that case it'd be better to redirect to the main page instead of to the page "Foo", which would just show the generic message of "this page does not exist". If I'm wrong with my impression and indeed "Foo" would be a valid page title on ro, we should indeed change the redirect from "funnel" to "rewrite" (don't change the path). That's definitely something on-topic for this task and something we can discuss here.

So now with the redirect being active, you've dropped completely the capability of contributing and displaying the UI in Cyrillic.

uselang=mo works for me on rowiki

"ro-cyrl" is still needed and should get the UI translations that were used in "mo"

If you want ro-cyrl to be an alias for "mo", you should create a new task requesting exactly that. It's out of topic for this very task though.

This should be restored at least with an active transliterator.

If you want the transliterator to be activated on rowiki, get community consensus and file a request afterwards. What I said above applies here too: That's nothing we can resolve in this very task.

I don't want to add too much to the rest of the discussion. Just the small note:

• If the content is meant to stay accessable but uneditable, that's what we call a closed wiki. A closed wiki stays at mo.wikipedia.org and is just made uneditable. mo. must not be redirected anywhere in that case.
• If the content is meant to completely disappear and be inaccessable by the public, that's that we call deleting a wiki. This includes redirecting the mo. site somewhere else.

Both of these are valid options from a developers perspective - which one should be done isn't up to us. If the language commitee decides and the board of trustees approves the decision to delete the wiki, that's what we do. If you think they made the wrong decision, reach out to them.

About redirects keeping the title name: as the moldavian past page is most probably written in Cyrillic, forwarding to the same page name in Romanian will likely fail (especially in Wikipedia, but less in Romanian Wiktionary which should have separate pages for titles in Cyrillic, possibly listing about the same words written in other languages like Russian with definitions given in Romanian, and less for user pages as most users should have SUL enabled already).
So I suggest redirecting user pages and Wiktionary without change of tiltle, and redirect other pages through the search tool in Romanian. The Romanian search tool should be able to find matching articles (and talk pages) using the original Cyrillic name (if it exists) or the alternate page title written in Latin.
Now there remains work to do on the Romanian sites so that they behave correctly with Cyrillic written page titles (also add mappings to their namespace names in Cyrillic to match those that were in Moldavian sites), and yes the Latin<>Cyrillic transliterator support should be added there.

But making the Moldavian content now invisible and inacessible is against the Wikimedia policy and licences granted by Moldavian users and the valuable work they may have done there which should not be simply lost (I think it is insulting for from and not respectuous). These users were NOT consulted correctly when the very small Language Comity took its internal decision.

Please contact the Language Committee when it comes to potential improvements in communication and/or process, and provide references/links for statements like "against the Wikimedia policy" so everyone can make sure that they same things are being discussed.
This task is not the best venue for that. Thanks for your understanding.

In T169450#3837101, @Verdy_p wrote:

So I suggest redirecting user pages and Wiktionary without change of tiltle, and redirect other pages through the search tool in Romanian. The Romanian search tool should be able to find matching articles (and talk pages) using the original Cyrillic name (if it exists) or the alternate page title written in Latin.

What we can easily do is to rewrite Wiktionary instead of redirecting all of it to the main page. But to be honest I'd like to here more than one opinion on that before we do any changes to the redirects.
However splitting Wikipedia into "user pages" and "other pages" is more complicated, as is redirecting into the search page.

Besides that, I concur with Andre.

It's not complicate to add "mo-x-old" to direct to the readonly archive of the "mo" wiki, now that "mo" redirects to "ro". At least the previous content remains accessible by their initial users

@EddieGP, we're taking of about 400 pages on Wikipedia and a few dozen on wiktionary. I'm 99% sure that the ro.wiktionary does not have *any* Romanian words with Cyrillic spelling. IMO it's not worth the effort of redirecting articles to same-title articles on the Romanian projects.

As LangCom clerk, I think before this goes much further I should step in and make a couple of things clear.

1. mo.wikipedia was frozen in 2006 or 2007, formally closed in 2010, the deletion discussion was started in 2014 and just completed now because I'm pushing to clear out long-open requests. mo.wiktionary is not all that different. So we're talking here about projects that haven't had content added in over ten years. I don't really think you need to worry about redirecting anything specific; redirect everything (in both projects) to the respective main pages. (And for what it's worth, the Wikipedia project was copied over to Wikia in 2014.)
2. The Republic of Moldova uses ro-Latn, not ro-Cyrl. The only place that really continues to use ro-Cyrl is Transnistria. The political agendas around the Transnistrian conflict heavily influence the various communities' policies concerning ro and mo wikis.
3. From my perspective as clerk of LangCom, it seems to me that it is within the purview of WMF and the developers to continue to support interface in ro-Cyrl (if it is sufficiently available and translated). You do not have to, but you certainly can. As far as I can tell, it is not within your remit (or LangCom's) to decide about a transliteration capability within the ro projects; those communities must decide for themselves. (Personally, I wish those communities would allow a transliteration tool. But they've been adamant about not allowing it. And since even mainstream Moldovans don't need it, nobody has tried to push too hard.)
4. Accordingly, it seems to me that the appropriate actions at this point are
   1. First, make sure there are .xml archives available if someone ever wants them. Clearly there was one for Wikipedia, since the Wikia project was created with it. Just make sure there is one out there for the Wiktionary. (@MF-Warburg?) (We can upload it into the file namespace at Incubator if there is no other good place for it.)
   2. As noted above, let any address inside these projects redirect to the corresponding main page.
   3. Then it will be safe to delete the wikis.

@Verdy_p, I truly appreciate your concern about blocking access to the content "forever". But the Wikipedia content is available at Wikia, the Wiktionary content is minimal, and the decisions about access to content were taken a good ten years ago. This is really just about cleaning up after a decision that was taken long ago.

All projects are dumped at https://dumps.wikimedia.org/backup-index.html

Thanks for that.