Move the Nourmande Wikipedia from nrm to nrf
Open, Stalled, LowestPublic

Description

Author: bugs

Description:
Please change the Nourmande Wikipedia's language code from "nrm" to "nrf". "nrm" is Narom, a language from Malaysia... It was

Back in 2008 Brion suggested that we use the generic Romance code with an extension tag, but in 2015 the new code nrf was approved, so we should use that.


Version: unspecified
Severity: enhancement
URL: http://thread.gmane.org/gmane.org.wikimedia.foundation/34563/focus=34691

Details

Reference
bz23216
bzimport raised the priority of this task from to Normal.
bzimport set Reference to bz23216.

I think "roa-x-nrm" or "roa-nrm" would be better to keep consistency with other codes with 3-letter extension tags like "be-x-old", "cbk-zam", "fiu-vro", "roa-rup", etc.

Even easier would be to close it, as it is inactive. Only bots, global maintenance scripts, vandalisms (and reverts of it), interwiki changes. No content progress.

Reedy added a comment.Mar 14 2013, 9:34 PM

(In reply to comment #2)

Even easier would be to close it, as it is inactive. Only bots, global
maintenance scripts, vandalisms (and reverts of it), interwiki changes. No
content progress.

Fancy putting the request in to do this, then we can easily close it?

millosh wrote:

Should be changed with a year of redirect for compatibility. At the other side, it's not likely that we'll get Narom Wikipedia during this decade.

then we can as well just redirect it forever. one year is just a random number and if we have to redirect anyways we just have to touch it twice to then remove that again

millosh wrote:

One year of permanent redirect would synchronize search engines. One year should be enough for that (or you could put any other reasonable time for synchronization). And it could happen that we get request for Narom Wikipedia at some moment of time.

RobH removed RobH as the assignee of this task.Dec 23 2014, 3:15 PM
RobH set Security to None.
Amire80 renamed this task from Move the Nourmande Wikipedia from nrm to roa-x-norman to Move the Nourmande Wikipedia from nrm to nrf.Jan 18 2015, 1:37 PM
Amire80 updated the task description. (Show Details)
Amire80 added a subscriber: Amire80.

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).

Meno25 added a subscriber: Meno25.Jul 11 2015, 8:09 AM
Restricted Application added a subscriber: Matanya. · View Herald TranscriptJul 11 2015, 8:09 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 19 2015, 8:14 PM
Koavf added a subscriber: Koavf.Aug 25 2015, 6:00 AM
Restricted Application added a subscriber: JEumerus. · View Herald TranscriptSep 3 2016, 2:59 AM
hashar lowered the priority of this task from Normal to Lowest.Sep 14 2016, 10:12 AM
Dzahn removed a subscriber: Dzahn.Sep 14 2016, 1:39 PM
Krinkle changed the task status from Open to Stalled.Apr 30 2017, 3:35 AM

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".

Liuxinyu970226 added a subscriber: Raymond.EditedMon, May 1, 1:26 PM

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 filesystel 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)