Note that "nan" is already defined in https://gerrit.wikimedia.org/r/#/c/285085/1/templates/helpers/langs.tmpl
However it still does not resolve on the DNS this means that we cannot easily create links to existing contents in Han Min Nan, when using the standard code, and external sites or templates still need to add a special case to convert "nan" to "zh-min-nan" when linking to Wikimedia sites.

Mediawiki already has resources using "nan", and TranslateWiki should be able to deprecate the old code "zh-min-nan" (even it is still valid for BCP47, it is no longer recommanded since it was reformedn several years ago when ISO 639-3 was published and its RFCs were largely rewritten with more precise terms).

We are in the same case as "zh-yue" deprecated in favor of the now prefered code "yue".

This is not the same case in "zh-classical" used specifically in Wikimedia wikis and that has never been conforming to BCP47 or ISO 639, where both finally defined only "lzh". Handling "zh-classical" is much more important for conformance (and notably web conformance with HTML, SVG, XML, system or library locales for C/C++ and many other programming languages, , etc., all of them using BCP47 normatively, and not even ISO 639 which is only kept informatively for backtracking one of its sources that are not automatically fully imported to the normative IANA database)

@Verdy_p isn't this domain already redirected for years? In redirects.conf:

...
ServerAlias minnan.wikipedia.org
ServerAlias nan.wikipedia.org
...
  # rewrite  zh-cfr.wikipedia.org  //zh-min-nan.wikipedia.org
  RewriteCond %{HTTP_HOST} =zh-cfr.wikipedia.org
  RewriteRule ^[^\x00-\x1F]* %{ENV:RW_PROTO}://zh-min-nan.wikipedia.org$0 [R=301,L,NE]
  # rewrite  minnan.wikipedia.org  //zh-min-nan.wikipedia.org
  RewriteCond %{HTTP_HOST} =minnan.wikipedia.org
  RewriteRule ^[^\x00-\x1F]* %{ENV:RW_PROTO}://zh-min-nan.wikipedia.org$0 [R=301,L,NE]
  # rewrite  nan.wikipedia.org  //zh-min-nan.wikipedia.org
  RewriteCond %{HTTP_HOST} =nan.wikipedia.org
  RewriteRule ^[^\x00-\x1F]* %{ENV:RW_PROTO}://zh-min-nan.wikipedia.org$0 [R=301,L,NE]
...

And in redirects.dat:

...
rewrite  zh-cfr.wikipedia.org  //zh-min-nan.wikipedia.org
rewrite  minnan.wikipedia.org  //zh-min-nan.wikipedia.org
rewrite  nan.wikipedia.org  //zh-min-nan.wikipedia.org
...

I did '''not''' made that request, it was there since years but not triaged like other pending renames all related to the Chinese language variants.
server-side redirects (for website URLs) are not the same thing as renaming wikis which includes several other operations.

Recently a grand-parent (stalled) task was triaged and marked as closed (without any resolution) by someone else by moving all of them on a new project backlog, but with different untriaged subprojects. That's all I did.

There are a few other rediurect requests like this one, which is one of the steps needed first before actual (stalled) renamings are performed.

Of course these server-side redirects will then need to be inversed by another backward redirection once the wikis are renamed.

So all I did was to not forget related operations that were listed in a (now closed) grand-parent tracking task. If you think this specific renaming is done, you can close it (this has been done for several other similar redirect requests needed only for transition time), but I have not reopened this issue which was still open (and still needing triage).

OK, but in any case, if you're asking nan.wikipedia.org, that's already redirected and this task should be invalid. Or if you want nan.wiktionary/wikibooks/wikiquote/wikisource.org to do so? If yes, this task is valid, but you should modify this task to reflect it.

All this was caused by changes in dependencies in a parent task that was closed by moving it elsewhere without fixing what was in it.
It's true that this did not concern only Wikipedia (and that's why the task was already open and kept stalled bfore being closed prematurely... and forgotten in dependencies between tasks and project boards where they were also kept untriaged since long)

I cannot check if everything has been done, but there was no signal before that the requests were done when they were already marked as "open" but "stalled".

See T10217 for the reason and look at its own history of dependencies (notably the last changes by user Krinkle that moved two dozens of related tasks in row before immediately unsubscribing to all of them and to the task he closed that contained and tracked them).

There are probably additional "m." domain names for mobile versions of these wikis in Han Min Nan, plus a few other related stalled or untriages bug reports/tasks related, that I found in several boards where other "zh-*" languages are already listed for their wikis (that still have interwiki linking problems).

Change 529418 had a related patch set uploaded (by Fomafix; owner: Fomafix):
[operations/puppet@production] Add redirects for https://nan.wik{tionary,iquote,ibooks,isource}.org

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

The swap of Traffic for Traffic-Icebox in this ticket's set of tags was based on a bulk action for all such tickets that haven't been updated in 6 months or more. This does not imply any human judgement about the validity or importance of the task, and is simply the first step in a larger task cleanup effort. Further manual triage and/or requests for updates will happen this month for all such tickets. For more detail, have a look at the extended explanation on the main page of Traffic-Icebox . Thank you!

Change 529418 merged by BCornwall:

[operations/puppet@production] Add nan to zh-min-nan redirects

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