I updated the description to the newly approved code nrf. Congratulations to the people of Jersey and Guernsey :)

Bur nrf is just for Guernsey and Jersey (Norman with lots of changes borrowed from English, plus historic forms), not for continental Norman that has at least two major variants:

• Northern Continental Norman along the coast, up to Picardy and South-Eastern Belgium where there is an evident correlation with Picard (pcd), and
• Southern Continental Norman which has a continuity with other oil languages (including gallo in Britanny, or the historical "Parisian" French , in Ile-de-France campaigns (do not confuse it with today's Parisian Argot which is a mix of lots of languages, including occitan variants such as Auvergnat, but more popular and with significant differences with standard French).

The two major continental variants have also accumulated along time a lot of forms from today's standard French, that you won't find in Jersey and Guernsey Norman, i.e. "Anglo-Norman").

Norman is no longer a single language even if there are attempts to reunify it between France and Anglo-Norman islands (Anglo-Norman is also an old official language of the British Crown, and you can still find example in some legal British laws and mottos).

Today's British English results from a mix between Norman and Saxon languages (from Denmark) borrowed from Viking invasions, and some survaval of Celtic words (most Celtic people fled the Viking invasions to western Britain, Wales and Cornwall, others emigrated to today's Britanny in France, bringing there the Breton language, coexisting with oil languages notably Gallo, or to Ireland bringing some new dialects of today's Irish, and some went as far as to Galicia in today's Spain). Then the Breton language spread again all around Europe (up to Sweden), before it was annexed to France; for long Breton (in Britanny) and Cornic (in Cornwall) was almost the same language across the Channel and was used as a interlingua by fishers and seamen in general).

However, Norman in France is much more endangered than Breton (Gallo in Britanny is also endangered of extinction: the Gallo area is overwheled by French-only speakers and there's no active support for it, unlike Breton). Gallo cannot be really helped by Norman (may be this will change next year with the reunification of "Normandie" as a single region in France).

Really this is the most urgent renaming task, because we pollute the translatewiki database for an unrelated language for which it is impossible to create translated resources (except by adding custom suffixes).

This is more than just MediaWiki. I even think that the first thing to do would be to ask translatewiki to force a migration of all "nrm"-tagged resources to "nrf", even if Wikimedia sites still have domains and interwikis using "nrm": Wikimedia sites will import the "nrf" translated resources to its existing local "nrm" database (which will still be pending a renaming).

For the other codes, for now there's no conflict, they are just legacy codes that are still valid in BCP47 even if they are deprecated they were not removed but only aliased or their usage discouraged (e.g. "sh", also equivalent to "hbs", that new applications could ignore).

For other specific codes that are not BCP47 compliant (in their syntax such as "simple") also there's no conflict even if the BCP47 code would be something else ("simple" in Wikimedia would normally be "en-x-simple" in standard BCP47 ; or "en-simple" with "simple" replaced by a IANA-registered variant in the "en" language scope, so that "en-Latn-simple" would also be valid, just like "en-Dsrt-simple"); same remark about the non-conforming "zh-classical" code that does not conflict even if should be "lzh".

Wondering if we can do these things instead or not, to avoid the de-facto untouchable URL changing? (Because, I'm not sure if waiting how many years for Narom people to start the real nrm.wikipedia in their Narom language):

1. Directly create a "standalone" nrf.wikipedia.org (add this entry to InitialiseSettings.php, interwiki.php, necessary dblists, RESTBase, scap/vars.yaml, wikiversions.json...) but temporarily allow transwiki importing (from nrmwiki) and only allow stewards to edit (and warn stewards to also not edit nrfwiki).
2. Transwiki importing from nrmwiki to nrfwiki.
3. For i18n files, may be two ways, depend on your choice @Verdy_p: either copy-pasting or renaming nrm->nrf in Names.php, langs.tmpl, and langlist, do it too for MessageNrm.php -> MessageNrf.php everywhere (can @Raymond help you?)
4. (wondering if just changing "nrmwiki(something).png" logos to "nrf..." are also allowed in static/images/project-logos/ or nope?!)
5. Re-open nrfwiki; empty nrmwiki and add it to closed.dblist (Good bye, old nrmwiki), so creation of Wp/nrm on Incubator is also allowed
6. Let Narom users start new nrmwiki

copying the content is in my opinion the bad thing to do. It would be simpler to first create a CNAME alias redirection of the subdomain and giving some time to update various tools and nav templates or modules to use the new URL, and then map liases in interwiki prefixes.
The actual migration of database (renaming its filesystem store) can be delayed by creating aliases also in the filesystem with hard links or softlink

@Verdy_p:

It would be simpler to first create a CNAME alias redirection of the subdomain

Are you absolutely sure that non of our Wikimedians have knowledge of Narom?

The actual migration of database (renaming its filesystel store) can be delayed by creating aliases also in the filesystem with hard links or softlink

mysqldump -u -p -h nrmwiki > nrmwiki_dump.SQL then mysql -u -p -h -e “CREATE DATABASE nrfwiki” and then mysql -u -p -h nrfwiki < nrmwiki_dump.SQL but still keep nrmwiki

There's more than a dump import to do. Many pages will need to be updated
when they use direct links. Duplicating the database would not help to the
cleanup task. It's far better to start by creating an alias and update the
interwiki prefixes too so that nrm still works.
The internal name of the database is not so important if it stays "nrmwiki"
(very few users have SQL access, those users know technically what they are
doing for maintenance tasks). But most of the cleanup task can then be made
by users without privileges. And all other existing wikis can have their
pages fixed, and bots can also help this migration work.
At one time (later, we'll be able to stop the aliasing.
And to renampe a SQL database you don't need to reimport it, just just
ALTER DATABASE...
An SQL database can also have their aliases, just like tables, columns,
indexes, constraints, users... without actually dropping the orignal name
and you can then remove one of these names No import is needed, no shutdown.
Just one thing you cannot do online is to rename their datastore on the
filesystem (I don't know have these data stores are actually named and on
which devices or mountpoints on Linux/*nix servers, but this is invisible
and most probably it is a shared storage space used by multiple databases
given we can see that multiple wikis are grouped in server groups.
Anyway the existing "nrm" database is probably very small compared to the
other wikis.

Such renaming however is independant of the name used to refer to the
language in translate.org (that manages many other projects than just
mediawiki): here we should not pollute other projects with broken language
codes. And it should already be possible to create a localisation project
for Narom, and experiment with it on community wikis (e.g. on Wikia) to
help defend their local projects, even if later they may get a Wikipedia
and Wikitionnary. There are also other non-wiki projects that would need
localisation hosted on translate.org, just like other languages they
already support, such as microfinance applications, social apps, blog
apps...

Really Wikimedia should consider it is a priority to stop polluting other
projects with incorrect codes that block other projects and communities.
Refusing to do so is an hostile attitude gainst them, even if the Narom
community is very small (but the fact it is small is another excellent
reason we should not help them develop their project and defend their
language).

Renaming "nrm" is a pritority. It should have occured since long (even if
it was to some "fr-x-nrm" before Norman was finally allocated to "nrf") and
not lasted so many years.

Bad language codes was a reason for the creation of the Language Commity at
Wikimedia, but who honored what they strongly recommanded ? This is the
only language in Wikiemdia that blocks another language from developing
with its own standard code

There are other languages to rename but this is not really blocking, and
not all of them are even non-conforming to BCP47: e.g. "sh" is dropped from
ISO 639 but NOT from BCP47 where it is still valid even if it's no longer
recommanded, and NOT aliased to another remmanded code, but renaming "sh"
to the 3-letter code would have no effect at all on conformance: the
3-letter code was also dropped from 639, but was NOT valid in BCP47 as it
was not registered in the IANA database, and it's impossible to alias it to
another language: it remains now as a "macrolanguage" grouping several
individual languages, just like "zh" is a macrolanguage (grouping Mandarin,
Cantonese.) but "eh" is special because it has an implicit default to mean
Mandarin in BCP47 (reflecting the old practice in ISO 639 before the major
revision of ISO 639-2 that added ~7000 languages)

Change 358231 had a related patch set uploaded (by Amire80; owner: Amire80):
[mediawiki/core@master] Define nrm as a deprecated language code redirecting to nrf

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

In T25216#3226963, @Liuxinyu970226 wrote:

@Verdy_p:

It would be simpler to first create a CNAME alias redirection of the subdomain

Are you absolutely sure that non of our Wikimedians have knowledge of Narom?

Currently no, given that the expected users that would use it, i.e. native Narom users, are simply blocked from using Wikimedia in their language. And all others seem to assume (incorrectly) that nrm refers to Norman (a large majority of them also don't know what is Norman).
So the current issue does not serve any one, not those Norman and Narom users or none of other users which have some knowledge or expertise of either languages.
The "nrm" code is bad for everyone.

I only suggested creating a CNAME domain name alias as a helper for a transition period (that should not exceed one year). During that time we'll fix all the remaining items using "nrm" to replace them with "nrf". Bots can also help fixing various things, including in interwiki links found in pages or in Wikidata. The rest is only fixing a few templates manually. Then some consilidation to check if there are remaining items.
Wikimedia can monitor the usage of links using the old "nrm" subdomain in interwikis (it can monitor referers, get some statistics over a monthly period, and maintain a list of what has been found). Bots can also help fixing translations found in Wiktionnary using incorrect codes.

Some templates will need some temporary fixes to support the transition, these may be complex in some tricky templates (or modules) but there should not be a lot.

Another task to perform will be to use a bot to rename codes in User babel boxes, after the Babel templates have been fixed (if needed to support both codes with "nrf" becoming the prefered default form).

A final monitoring should look for remaining accesses (webserver access logs) to see if they are refered from Wikimedia sites or some wellknown sites (including translatewiki.net) that could be fixed to use the new domain name. We can ignore small external websites (personal pages or blogs). But we can contact maintainers of wellknown community pages on social networks (Facebook, Twitter,...) to inform them of the new site to use.

The old "nrm" wikis being accessible from "nrf" could also display a notice on their home page about the transition. Users registered on "nrm" and having some admin privileges shoudl also be informed by a notification to their talk page.

After that time, we can discard the "nrm" aliases in CNAME domain names and start removing the old "nrm" aliases kept in templates/modules but keep "nrf" there.

Note that translatewiki.net is about to rename "nrm" to "nrf": wikimedia will need to change the translation source for its "nrm" wikis.

This should also be announced in community portals of international wikis (Commons, Wikidata, Meta) where their local admins will take in charge the conversion of templates/modules (first the compatiblity transition by making "nrm" an alias of "nrf" now prefered, then later the removal of the old aliases).

At that point "nrm" will be useless and can be cleared. Narom suers can then request the addition of "nrm" for their language. A new wiki will be created for them, the new wiki will start with a homepage saying that the Norman wikis have been moved elsewhere. After about one year, that notice will be droppable.

In T25216#3340841, @Verdy_p wrote:

In T25216#3226963, @Liuxinyu970226 wrote:

@Verdy_p:

It would be simpler to first create a CNAME alias redirection of the subdomain

Are you absolutely sure that non of our Wikimedians have knowledge of Narom?

Currently no, given that the expected users that would use it, i.e. native Narom users, are simply blocked from using Wikimedia in their language. And all others seem to assume (incorrectly) that nrm refers to Norman (a large majority of them also don't know what is Norman).
So the current issue does not serve any one, not those Norman and Narom users or none of other users which have some knowledge or expertise of either languages.
The "nrm" code is bad for everyone.

"native Narom users, are simply blocked from using Wikimedia in their language" Malaysia has GFW? For other sentences, I need time to research.
But even the Norman language is also not having a good status (per Ethnologue: Jèrriais language status: 8a (Moribund), while Guernsey status: 8b (Nearly extinct), although in "Mainland" France status: 6a (Vigorous)).

I only suggested creating a CNAME domain name alias as a helper for a transition period (that should not exceed one year). During that time we'll fix all the remaining items using "nrm" to replace them with "nrf". Bots can also help fixing various things, including in interwiki links found in pages or in Wikidata. The rest is only fixing a few templates manually. Then some consilidation to check if there are remaining items.
Wikimedia can monitor the usage of links using the old "nrm" subdomain in interwikis (it can monitor referers, get some statistics over a monthly period, and maintain a list of what has been found). Bots can also help fixing translations found in Wiktionnary using incorrect codes.

Due to T133548, do you still believe that redirects that even only about CNAMEs are easy? Changing href of "nrm:" Interwiki links are also not easy, see https://gerrit.wikimedia.org/r/#/c/236966/ .

Some templates will need some temporary fixes to support the transition, these may be complex in some tricky templates (or modules) but there should not be a lot.

Just change them to query either Q33850, or when possible, the CLDR nrf locale name entry.

Another task to perform will be to use a bot to rename codes in User babel boxes, after the Babel templates have been fixed (if needed to support both codes with "nrf" becoming the prefered default form).

For those who are using {{#babel:nrm}}, T101086, then just wait for the patch that T25216#3337767 mentioned to be merged (or are you asking that we must also add nrm to $wgDummyLanguageCodes?). Local Babel templates can just be editable by you!

A final monitoring should look for remaining accesses (webserver access logs) to see if they are refered from Wikimedia sites or some wellknown sites (including translatewiki.net) that could be fixed to use the new domain name. We can ignore small external websites (personal pages or blogs). But we can contact maintainers of wellknown community pages on social networks (Facebook, Twitter,...) to inform them of the new site to use.

+1

The old "nrm" wikis being accessible from "nrf" could also display a notice on their home page about the transition. Users registered on "nrm" and having some admin privileges shoudl also be informed by a notification to their talk page.

Just mention this task in Tech news (User-notice) is already enough (I really don't know why it's important that a MassMessage is needed for this single task).

After that time, we can discard the "nrm" aliases in CNAME domain names and start removing the old "nrm" aliases kept in templates/modules but keep "nrf" there.

See a.2, not very easy.

Note that translatewiki.net is about to rename "nrm" to "nrf": wikimedia will need to change the translation source for its "nrm" wikis.

Yes, TWN should rename codes that i18n files are using first.

This should also be announced in community portals of international wikis (Commons, Wikidata, Meta) where their local admins will take in charge the conversion of templates/modules (first the compatiblity transition by making "nrm" an alias of "nrf" now prefered, then later the removal of the old aliases).

a.6, and what else should be renamed? In ContentTranslation? (maybe T112285, T129470) "nrm XXXX" part of Wikidata items links? (T112647) pywikibot.Link? (T113461 or ask zhuyifei1999 if more help needed) SiteMatrix? (a bit hard, see T111876 and T134348, maybe several decades later as per a.2)

At that point "nrm" will be useless and can be cleared. Narom suers can then request the addition of "nrm" for their language. A new wiki will be created for them, the new wiki will start with a homepage saying that the Norman wikis have been moved elsewhere. After about one year, that notice will be droppable.

Changing 'nrm' => 'Nouormand', # Norman -- not a valid code, for compatibility. See nrf. to 'nrm' => 'Narom', # Was assigned to Norman for compatibility in early years, See nrf. isn't enough?

Change 468050 had a related patch set uploaded (by Fomafix; owner: Fomafix):
[mediawiki/core@master] Step 1 of renaming the language code for Norman from nrm to nrf

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

Change 468050 had a related patch set uploaded (by Fomafix; owner: Fomafix):
[mediawiki/core@master] Step 1 of renaming the language code for Norman from nrm to nrf

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

Change 358231 had a related patch set uploaded (by Fomafix; owner: Amire80):
[mediawiki/core@master] Define nrm as a deprecated language code redirecting to nrf

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

Change 527908 had a related patch set uploaded (by Fomafix; owner: Fomafix):
[operations/dns@master] Add 'nrf' as alias for 'nrm'

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

Change 527909 had a related patch set uploaded (by Fomafix; owner: Fomafix):
[operations/puppet@production] Add 'nrf' as alias for 'nrm'

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

Change 358231 abandoned by Amire80:
[mediawiki/core@master] Define nrm as a deprecated language code redirecting to nrf

Reason:

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

Change 358231 restored by Fomafix:

[mediawiki/core@master] Define nrm as a deprecated language code redirecting to nrf

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

Change 468050 merged by jenkins-bot:

[mediawiki/core@master] Step 1 of renaming the language code for Norman from nrm to nrf

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

Change 527908 merged by Dzahn:

[operations/dns@master] Add 'nrf' as alias for 'nrm'

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

valid code per https://iso639-3.sil.org/code/nrf

nrf.wikipedia.org has been added to DNS

nrf.wikipedia.org is an alias for dyna.wikimedia.org.

Change 876420 had a related patch set uploaded (by Winston Sung; author: Winston Sung):

[mediawiki/core@master] Add nrf (nrm, Norman) to Names.php

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

Change 876420 abandoned by Winston Sung:

[mediawiki/core@master] Add nrf (nrm, Norman) to Names.php

Reason:

Replaced-by Ib8d3c344ebe082e4d3e5ec12b3815c5845f4797e

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

Change #1031874 had a related patch set uploaded (by Clément Goubert; author: Clément Goubert):

[operations/puppet@production] httpbb: Add tests for new redirects

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

Change #1031874 merged by Clément Goubert:

[operations/puppet@production] httpbb: Add tests for new redirects

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

Mentioned in SAL (#wikimedia-operations) [2024-05-16T10:02:17Z] <claime> cumin 'A:all-mw' "disable-puppet 'New redirects T25216 T204830 T31186 - cgoubert'"

Change #527909 merged by Clément Goubert:

[operations/puppet@production] Add 'nrf' as alias for 'nrm'

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

Mentioned in SAL (#wikimedia-operations) [2024-05-16T10:21:12Z] <claime> New redirects ok on mwdebug - T25216 T204830 T31186

Mentioned in SAL (#wikimedia-operations) [2024-05-16T10:22:16Z] <cgoubert@deploy1002> Started scap: Deploy new redirects to mw-on-k8s - T25216 T204830 T31186

Mentioned in SAL (#wikimedia-operations) [2024-05-16T10:29:59Z] <cgoubert@deploy1002> Finished scap: Deploy new redirects to mw-on-k8s - T25216 T204830 T31186 (duration: 08m 06s)

Mentioned in SAL (#wikimedia-operations) [2024-05-16T10:31:53Z] <claime> cumin 'A:all-mw' "enable-puppet 'New redirects T25216 T204830 T31186 - cgoubert'"

Mentioned in SAL (#wikimedia-operations) [2024-05-16T10:32:44Z] <claime> cumin 'A:all-mw' -b30 "run-puppet-agent -q" - T25216 T204830 T31186

The redirect from nrf.wikipedia.org to nrm.wikipedia.org is operational.

Mentioned in SAL (#wikimedia-operations) [2024-05-16T10:43:53Z] <claime> New redirects for T25216 T204830 T31186 operational

I don't think this ticket is resolved. It was asking for https://nrf.wikipedia.org to be moved to https://nrm.wikipedia.org. Which is a non-trivial undertaking, and is why this remained open for 13 years.

What you seem to have done is redirect nrf.wikipedia.org -> nrm.wikipedia.org, which is useful but not what this ticket asked for.