We already have Norman under the (completely incorrect) code nrm and T25216 is asking for the existing Norman Wikipedia to be moved from that code to nrf. If that happens, I would expect Wikidata to also switch to using nrf for Norman. nrf explicitly covers both Jèrriais and Guernésiais and possibly applies to the other mutually intelligible varieties too (might be worth asking the ISO 639-3 RA for clarification). Either way, if you specifically want to say Guernésiais, I would suggest nrf-gg (i.e. including the country code for Guernsey) as a more appropriate code (and then Jèrriais would be nrf-je).

Hoi,
In this case I think the language committee wants to be involved. This is
one of the longstanding issues we face and we do not want to muddle the
waters even more. So in this case it is not ok to move forward imho.
Thanks,

GerardM

If I understand correctly, nrf is the standard code, and nrm is a de-facto code that is used in the current domain, and what's worse—in the HTML lang attribute. The domain should be renamed, but current it's technically blocked, but there is a things that can be done: Add it do getDeprecatedCodeMapping in LanguageCode.php, similarly to gsw -> als. This way nrf will be used in the lang attribute, and in most other places. It should also be fixed it in the langdb of jquery.uls.

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

I think T25216 also mentions that current nrmwiki includes languages not covered by nrf.

Independently of this, I think the suggestion by @Nikki to create nrf-gg (and nrf-je ) is a good one.

In T165648#3337826, @Esc3300 wrote:

I think T25216 also mentions that current nrmwiki includes languages not covered by nrf.

That wiki was created before the current language policy. These days it wouldn't be created without a standard code at all. nrf is close enough for practical purposes for now.

Independently of this, I think the suggestion by @Nikki to create nrf-gg (and nrf-je ) is a good one.

Fine with me if there are significant differences that justify subtags. If needed, they can also be in the ULS langdb, although I'd love to hear this from people who actually speak these languages and plan to edit in them (if such people already replied anywhere on this task, I probably missed it, and I apologize for this).

The purpose of this thread is to allow to define the language of geographic names used in Guernsey in Wikidata statements (with "monolingual text"-datatype properties). Please don't combine or confuse it with open issues already addressed in T25216.

The advantage of using subtags is that it allows to use "Jèrri" and "Jerri" on https://www.wikidata.org/wiki/Q785 and identify which one is actually used on Jersey.

In T165648#3337873, @Esc3300 wrote:

The purpose of this thread is to allow to define the language of geographic names used in Guernsey in Wikidata statements (with "monolingual text"-datatype properties). Please don't combine or confuse it with open issues already addressed in T25216.

I understand this. I am just trying to look at this in light of what I'm writing at T144272#3322282: I'd love to avoid having a lot of separate language code lists around MediaWiki and extensions and to treat these issues as generally as possible.

Wikidata tries to follow IETF language tags to provide the language of a specific string in a structured way. This independently from the existence of a MediaWiki GUI in that language or even a Wikipedia language edition.

Oddly this fairly simple approach seems needlessly time-consuming. Maybe we should move to items instead.

Hoi,
Given that there is a Wikipedia with the wrong code, it is not possible
imho to do justice to the language. WMF has never had a reason to sort it
out, now it has. Adding codes is not appropriate under these circumstances.
Thanks,

GerardM

Can you explain why the problem at WP should block identifying languages correctly at Wikidata? What would be the inconvenience?

The request is not for adding codes that are already standard according to
BCP 47 where nrf-GG and nrf-JE arr oerfectly valid and confirming. But what
is still blocking is that "nrm" in Wikimedia has ALWAYS been valid in BCP47
but incorrectly assigned for another unrelated language. To add nrf-GG and
nrf-JE, we still need that Wikimedia renames its existing and incorrect use
of nrm to nrf. This done, we still need the two variants for Jériais and
Guernesiais and notably the first one which has official status in Jersey.
For now there's still no ISO639-3 code assigned for the two languages
(Jersiais is not locally considered as a "variant" of Norman as it has its
own official status, its own nornative dictionary. But nrf-JE and nrf-GG
are still valid and conforming substitutes, even if BCP 47 now prefers, but
does not require, using a single ISO 639 code instead of using region codes
from ISO 3166 or UN-M49.
Many but not all legacy BCP 47 codes using region codes are now replaced by
single codes from ISO 639-3 but none if these legacy codes are made invalid.
For now there's not even any pending request to split code "nrf" as a
macrolanguage for its 3 variants encoded separately (continental, Jériais
and Guernésiais) so "nrf" is still a simple language encompadding its 3main
variants so we still need to add region codes (fr, gg, je) where
distinctions are needed.

The situation however is more complex because continental norman has at
least 3 known variants and guernesiais has also a known variant for Sark.
Thrse dialectal variants are not encoded in ISO 639 so if we need them in
BCP 47 the region codes will not be enough and we would need to use variant
codes instead that have to be registered in the IANA dabase of language
subtags. As long this is not done we can still use private use extension to
the main "nrf" langiage code to conform to BCP47.

In all these cases we must NOT use "nrm".

So once again rename nrm to nrf as it was requested so many years ago !
This should not need any discussion and all users want that, including
those that want to develop content in Narom and that are blocked by
Wikimedia failure on using "nrm" for Norman.

Le 11 juin 2017 15:52, "GerardM" <[email protected]> a
écrit :

Given that there is a Wikipedia with the wrong code, it is not possible
imho to do justice to the language. WMF has never had a reason to sort it
out, now it has. Adding codes is not appropriate under these circumstances.

And it is not the question of "adding" new codes, but using the correct ones, i.e. the single code "nrf" everyone uses, even if we still need subtags for regions and/or variants (because "nrf" is still not encoded as a macrolanguage in the ISO 639 standard and in the IANA database for BCP47 , as it probably should at least for Jersiais which has a formal standard).

It seems that there are many good reasons to sort out T25216, but I don't want to go into that.

It seems that we agree that having codes nrf-gg and nrf-je for monolingual strings at Wikidata is the way to go.

The question is probably now on a technical level: is there any negative impact if we create these now.

Hoi,
No you get it backward. At this time for this language we (WMF) identify
incorrectly. We should not make the mess even bigger.
Thanks,

GerardM

Hoi,
As mentioned elsewhere and not only by me, it is not.
Thanks,

GerardM

@GerardM I don't take it backward. This is perfectly correct, there's no mess at all except in your mind:

• NOWHERE it was proposed to add nrm-je or nrm-gg (if that's what you are still reading incorrectly, and that neither me wrote, nor what @Esc3300 asked for): the mess is in Wikimedia everywhere in its wikis with its incorrect use of "nrm" that should have been renamed since long.
• But nrf-je and nrf-gg (also nrf-fr) are perfectly correct, and FULLY conforming to the BCP 47 standard (and "nrf" is still wanted for Norman and asked for since years)

@GerardM if you are are saying nrf-gg/nrf-je incorrectly identifies Guernésiais and Jèrriais, please provide a reference for your statement.

@Esc3300: Guernésiais and Jérriais still have no separate ISO 639 code. "nrf" is encoding Norman as a whole (i.e. a single language) encompassing all its regional or dialectal variants, and still not as a macrolanguage (see ISO 639-3 for reference).
But for BCP47 "nrf" is fully conforming, just like "nrf-JE", "nrf-GG", "nrf-FR" (it uses regions subtags registered in IANA and inherited from ISO 3166-1, which have NO restriction for specific language). This is for now the only way to represent them in BCP 47.

There's still no separate codes in ISO 639-3 (so there's also no primary language subtag in BCP47) for Jérriais and Guernésiais as single languages, which are still considered by ISO 639 (and BCP 47) as variants of "nrf". The only existing standard way to represent them is then to use region subtags after "nrf". This is perfectly valid in BCP 47 (using region subtags is deprecated but not invalid for languages that have been separately encoded in ISO 639-3 and then added to the IANA database for language subtags). There's no ambiguity at all in this case (this explains why no ISO 639-3 codes were even requested for Jerriais and Guernésiais as there was no demonstation they were ambiguous using region subtags and no demonstration that "nrf" should then become a macrolanguage).

There's only one missing case, for Sark (which uses a documented variant for Guernésiais), for which there's NO standard way to represent it (except by using an addition private use, given that Sark has NO region subtags for itself: it would then be "nrf-GG-x-sark" to conform to the BCP47 standard, or possibly just "nrf-x-sark")

Final note: language tags in BCP47 are not case-sensitive, and using dashes ("-") or underscores ("_") is equivalent in BCP47. So "nrf-GG" or "nrf-gg" or "nrg_gg" are equivalent. Wikimedia just prefers using lowercase only and dashes as separators.

Hoi,
The code NRM is used incorrectly .. as you know.
Thanks,

GerardM

@GerardM: what do you read ? We all know that, but you are still pretending that the request above by @Esc3300 is invalid, when it is in fact perfectly correct. You are the only one to read it incorrectly.

Hoi,
The issue is that the proposed code is a subset. The main item is
problematic and therefore this code is problematic.
Thanks,

GerardM

In T165648#3337981, @Verdy_p wrote:

To add nrf-GG and
nrf-JE, we still need that Wikimedia renames its existing and incorrect use
of nrm to nrf.

Why do we need nrm to be renamed first? We have ike-cans and ike-latn even though we don't have ike, so I don't see what would prevent nrf-gg and nrf-je from being added before we deal with renaming nrm to nrf.

In T165648#3338078, @Verdy_p wrote:

@Esc3300: Guernésiais and Jérriais still have no separate ISO 639 code. "nrf" is encoding Norman as a whole (i.e. a single language) encompassing all its regional or dialectal variants, and still not as a macrolanguage (see ISO 639-3 for reference).
But for BCP47 "nrf" is fully conforming, just like "nrf-JE", "nrf-GG", "nrf-FR" (it uses regions subtags registered in IANA and inherited from ISO 3166-1, which have NO restriction for specific language). This is for now the only way to represent them in BCP 47.

http://www-01.sil.org/iso639-3/documentation.asp?id=nrf only lists Jèrriais and Guernésiais. It was originally requested as Jèrriais with the code jrs. The ISO 639-3 RA investigated it and concluded that Jèrriais and Guernésiais are mutually intelligible and therefore created a code which covers both (see the comments on the original request). They didn't include Norman as a name, nor is there any mention of the continental variants, so it is unclear to me whether they intended nrf to cover all of Norman or only the variants from the Channel Islands. That's why I suggested it might be worth contacting them.

Actually ISO 639 also references The Ethnologue entry that lists:
Andorra and France https://www.ethnologue.com/map/ADFR
Ireland and United Kingdom https://www.ethnologue.com/map/IEGB

The Normand variants on the continent are effectively those in region
Normandie, but there are historic Norman people also in Andorra and
elsewhere in the British isles.

For French variants mostly those in Normandie, there's a legacy (but
incorrect) assumption that it is a variant of French. It's true that it is
one of the Oil languages from which French was created ininitially in the
Val de Loire region, where the initial kingdom of France was located, then
later to Île de France when the kingdom was established in Paris (later in
Versailles): the language of the rulers were stil lthe Oil variant from the
Loire valley, but French was in fact normalized and became the official
language of the kingdom only after the creation of the French Academy, that
proposed to unify various oil languages in a new lingua franca, as well as
several Oc languages (Occitan, Catalan, Provençal). Old French is another
history, it was in fact not the result of this merge, but just the historic
vernacular Oil variant spoken in the Loire Valley, which was still distinct
from the Parisian Oil variant. The Parisian Oil variant survived for long
even after normative French was created (and it is still distinct from the
various modern "Parisian French" argots which are found in popular Paris
suburbs, made with more terms from foreign origins, notably from Berber and
Arabic, mixed with more terms from English, but also from other "Parisian
French" spoken by regional community in Paris, notably from some past
corporations occupying people from Southern France, notably from Auvergne:
this "Parisian French" is in fact of variant of Auvergnat, and more related
to Provençal and Oc languages).

Now in Andorra (and in surrounding areas in the French Pyrénées mountains),
that Norman variant is inherited from the former occupation of Southwestern
France by Englo-Normans, i.e. the British Crown hold by the Normans since
their invasion of Britain (and later Ireland). Some minor Norman dialects
can be found as well all around the Mediterranean sea, and up to the Baltic
sea when Normans were ruling the seas.: you can find extinct Norman
variants in Sicilia, Sardinia, and on the Italian peninsula, or in Malta
and Greece and some harbors in North Africa. The Norman troups ceased to
exist as such when Normans lost all their territories in France. But the
vernacular Norman has still persisted in France, and developed
independantly of the Channel Islands. English itself incorporates many
Norman terms, historically more than those borrowed later from French
(which appeared much later and is a real language only since the 19th
century, and became standard only after World War I when French people from
various regions were largely mixed together and used a lingua franca, and
enforced with the mandatory techning of "standard French" in schools since
Jules Ferry).

The regional Norman language is now being renewed in Normandy, but with no
state support (it is culturally supported only by regions in Normandie,
created serparately just after WW2, incorporated separately only in the
early 1980's, but reunified only in 2015). There's no doubt it is
completely related to the Norman languages in Jersey and Guernsey (which
also have cultural "embassies" in France, in Normandie, and with active
cultural cooperation with the two Normandie regions (merged into a single
one in 2015). There are "pan-Norman" cultural events that occur every year
alternatively in Jersey, Guernsey and in French Normandie (but there is
also some association with Norman cultural minorities in Northern Spain and
Italy). There's still an ongoing effort to create a dictionnary for Norman
in French Normandie (jsut like there's another one in Guernsey: that work
is almost complete in Jersey where it is now recognized officially with
English and even with today's French, due to the many relations that the
Anglo-Norman islands share with Normandie and Bretagne regions in France
and the fact that there's now a significant French community living in
those islands, even if they don't speak the French-Norman regional
"dialects" or one of the Channel Islands Norman variants)

For now ISO 639 considered all regional Oil languages to be "French" even
if they were not standard : they are in fact sufficiently different to be
distinguished. French people will easily say you that Norman "'dialects"
are difficult to understand, just like other Oil regional languages : some
of them are encoded in ISO 639 (notably Picard and Walloon), some are not
like Gallo (spoken in Eastern Britanny and recognized officially by the
Bretagne region and Ille-et-Vilaine), or Poitevin/Maraichin, Angevin,
Champenois... The problem being that France itself does not recognize any
other language than standard French and offers no help to support regional
languages in schools and adminsitration: this support is only offered at
cultural levels in regions and smaller collectivities, and in some regional
universities in their linguistic departments.

So yes it is not clear if "nrf" represents the continental variants used in
France. But anyway "nrf" is now widely used also for France and there's no
problem of ambiguity for the use standardized in Jersey and Guernsey. If
there's such a problem, a sistinction is stiull possible with "nrf-FR". For
now the various dialectal variants of continental Norman in France are not
encoded, just like those in Andorra, or elsewhere in the British isles, or
extinct minorities elsewhere in Europe, North Africa, or even in North
America (I was told that Canadian French and Cajun in US are still
containing a "large" Norman substrate, but they are now encoded separately.
Canadian French is corectly represented in BCP 47 as "fr-CA" using region
codes, but the same can be made for distinguishing Norman in Jersey,
Guernsey, and Normandie in France using the same country codes as region
subtags: this is generally sufficient, but "fr-x-norman" "suggested" by old
BCP 47 when ISO 639-3 still did not exist, is probably wrong: "nrf-FR" is
much better.

So let's also go with "nrf-JE" and "nrf-GG" which are equally valid and may
be used when one wants a ditinction; if there are terms kept locally in
other regions, notably in the toponymy, we could as well have "nrf-CA",
"nrf-US", "nrf-IT", "nrf-GR", "nrf-MT", "nrf-SV", all perfectly valid in
BCP 47...).

Note: this discussion is not about adding new wikis for Norman: the
existing "nrm" wikis just need to be renamed "nrf" and we're done: the
existing Wikipedia and Wiktionnary wikis in Norman are already mixing all
the variants. But nothing prevents them to use subtags when needed in some
sections for language tagging of the content or categories, even if they
are all in the same "nrm" -> "nrf" wiki. And for wikidata, proper language
identification should allow any valid and standard BCP47 tag, without being
limited to those that have a wiki edition in Wikimedia or those that
currently have a supported translation for Mediawiki or other softwares
supported by translatewiki.net:

Even if Wikimedia rejects it for its own wikis, MediaWiki itself will need
to be more liberal when people will want to create their own wikis they'll
support themselves, but will still want to have accurate translations.
Immediately we need to rename "nrm" to "nrf" to allow any other software to
be created locally for the Narom language, even if there's still no wiki
supported by Wikimedia for Narom. We should not block that last language
from getting the basic support it deserves. Even if Wikimedia refuses to do
it for now, "translatewiki.net" may add it at any time and will need to
rename "nrm" to "nrf" in its own database (Wikimedia will need to adapt its
source for its own bad "nrm" wikis).

This is most interesting, but the thread here is merely to create monolingual string properties with "nrf-gg" or "nrf-je". Can we try to focus on the few remaining points?

The main question that remains is if nrmwiki needs to be renamed to make it technically possibly to create these codes. Experience with other languages at Wikidata suggests that these codes can be created. @Lydia_Pintscher is there a technical problem ?

Domains, sadly, cannot be renamed at least until T112909 is resolved, but to the best of my understanding renaming the domain is not required for resolving this bug.

Hoi,
Because they are a subset of nrf.
Thanks,

GerardM

Thanks? I don't understand. Can you explain what the technical impact is? Which Wikidata function(s) would be impacted?

In T165648#3338804, @Esc3300 wrote:

Thanks? I don't understand. Can you explain what the technical impact is? Which Wikidata function(s) would be impacted?

I was suggested T25216#3224949, but verdy_p doesn't agree with that.

I don't think this impacts the creation of "nrf-gg" (nrf-je) for monolingual strings at Wikidata.

In T165648#3339030, @Liuxinyu970226 wrote:

In T165648#3338804, @Esc3300 wrote:

Thanks? I don't understand. Can you explain what the technical impact is? Which Wikidata function(s) would be impacted?

I was suggested T25216#3224949, but verdy_p doesn't agree with that.

Thanks, but I don't think this impacts the creation of "nrf-gg" (nrf-je) for monolingual strings at Wikidata. The scope of monolingual strings is fairly limited: you can't even use it "nrf-gg" for labels and descriptions. https://www.wikidata.org/wiki/Help:Monolingual_text_languages outlines it.

As @Esc3300 says this is only about monolingual text values on Wikidata - nothing else. I am losing overview in this discussion. Is there anything that prevents us from doing it? Is anything bad going to happen if we add it now and later rename the Wikipedia? They are completely independent as far as I can tell.

Hoi,
Yes. There is a system in codes. When you have a subset that is not
associated with the superset, you destroy the credibility of the language
codes.

There is an outstanding request to rename wikipedias for this reason. We
should not make the current situation worse.
Thanks,

GerardM

The current situation is not made worse by adding these. There is clear and uncontroversial consensus to transition nrm to nrf, and the actual execution is only blocked by technical issues.

if there are no specific problems that can be identified with having these two codes, I suggest we move ahead.

The issue i see is that to add a name in a given language, it must still be supported in the Universal langauge selector or by using "?uselang=" parameter, so that we can give it a label.
We annot add any label in Wikidata in a language that is not selectable as the user language, so a minimal support for MediaWiki localisation is needed so that the language becomes "supported" and not just "valid" (accorrding to BCP47 rules, as currently implemetned with ICU's library used to check it). It seems that the languages Lua module to implement and check validity is not used there and there's no workaround for missing locales in MediaWiki "support".
IOdeally Wikidata should not depend on this MediaWiki support because we actually don't need this supprot for creating a MediaWiki UI, but only to enter labels for Wikidata. This is a limitation of the Wikidata UI which incorrectly assumes such Mediawiki support is needed: there's no way to add an additional "custom" (but valid) BCP47 locale code to associate a label to a Qnnn entry: the "more" languages buttons requires us to select a supported locale so that the input form will propose a field to fill in. Probably we could still add it in Wikidata, but not with the current Wikidata UI, only via its API (this would require some privilege to submit data via the API and bypass the validation currently performed by Wikidata's UI).

@Verdy_p This about making it possible to create a monolingual string in the requested languages. Labels aren't monolingual strings and are not in scope for the request.

Hoi,
the specific problem is that there is clear and uncontroversial consensus
to transition nrm to nrf, and the actual execution is only blocked by
technical issues. Issues that are only pushed forward because it is not
deemed to be relevant enough.

The problem is that we do not conform to standards and we make it worse.
Thanks,

GerardM

In T165648#3349574, @GerardM wrote:

Hoi,
the specific problem is that there is clear and uncontroversial consensus
to transition nrm to nrf, and the actual execution is only blocked by
technical issues. Issues that are only pushed forward because it is not
deemed to be relevant enough.

The problem is that we do not conform to standards and we make it worse.

This may be relevant to the other thread, but here it seems to be a minority view. The consensus seems to be that this isn't relevant to this request for monolingual string language codes.

@Mbch331 "Labels aren't monolingual strings". Of course they are (or should be) monoligual as we request users to provide monolingual translations for them.
There are a few exceptions with some *official* toponyms that are multinguals, or trademarks, but verncular toponyms are monoligual or should be (it just happens that some verncular toponyms have synonyms with orthographic/dialectal variants, but for that we have "aliases" in labels, and if we want to distinguish dialectsal/orthographic differences, we should be able to do that also by adding separate monolingual labels using more specific BCP47 locale tags (a non-specific locale tags will use the most common form but should be monolingual).

Note that official toponyms are just like trademarks: they are untranslatable or exist only in a few selected languages (which is a restricted set, not extensible, unless these translations are officially sourced by a national authrority, but not by a foreign authority or by some old dictorionaries). In Spain for example, officiual toponyms can be the concatenation of two toponyms in different languages, and this concatenated form is the legal one for Spanish and the specific regional language with which it is associated.

Official names are separate properties. This also applies to other official terminologies (such as species, chemical names...): "official" means that these names MUST be sourced by associating them with the standard that defines them (an "official name" may give multiple names depending on a restricted set of languages, but they should be *qualified* in Wikidata with an "according to" qualifier, whose value would be a reference to a terminologic standard body or one of its standards for specific uses).

On contrast, the "labels" for Wikidata should still be monologual and should all translatable as precisely as as possible (as much as what we can do in Wiktionnary to create lexical entries, and also to disambiguate separate the homographs) to any humane language or dialect or script convention, using valid and conforming standard BCP47 locale tags.

In T165648#3349731, @Verdy_p wrote:

@Mbch331 "Labels aren't monolingual strings". Of course they are (or should be) monoligual as we request users to provide monolingual translations for them.

I think you've misunderstood what Mbch331 is trying to say. The request here is for codes for use with properties which have the "monolingual text" data type, e.g. https://www.wikidata.org/wiki/Property:P1684 and https://www.wikidata.org/wiki/Property:P1705. Labels are completely separate and do not use properties of any type. It is possible to add languages for both labels and monolingual text properties, or only for monolingual text properties. This request is for the latter.

Hoi,
I know very well what this is about. As a member of the language committee
I made the arrangements for other languages then the codes accepted for
localisation to be accepted for monolingual texts. You can ask Lydia if you
do not believe this.

It is with this background that I am making my point.
Thanks,

GerardM

Please create a separate request for labels/descriptions.

@Lydia_Pintscher can you move ahead with this?

I've tried to make sense of the discussion and for all I can tell the objections are unrelated to adding the codes to the list of allowed monolingual text languages on Wikidata. So let's do it now.

Hoi,
The language committee is responsible for the use of the codes used. As it is, multiple members have indicated that it is wrong to add these codes. Please desist.
Thanks,

GerardM

@Lydia_Pintscher Considering GerardM's last comment is this still a go or is it now a no go? Just want to be sure, before I start making a patch with the result it will never be merged.

@Mbch331:

@Lydia_Pintscher Considering GerardM's last comment is this still a go or is it now a no go? Just want to be sure, before I start making a patch with the result it will never be merged.

just reject

In all these cases we must NOT use "nrm".

Oppose, we can use that to mark Narom texts.

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

It's two years now.

Hello all,
Reviving this old ticket, I wanted to ask if there are still objections to move forward with implementing nrf-gg and nrf-je codes for monolingual text. @Amire80, @GerardM, @jhsoby could you have a look and let us know what you think?
This code could be used for example in this case.
The recent request comes from here.

From the Wikidata development team, there is no technical issue that could get in the way of implementing these two codes.

No comment has been added, we can move forward with this and enable nrf-gg and nrf-je.

Change 579376 had a related patch set uploaded (by Mbch331; owner: Mbch331):
[mediawiki/extensions/Wikibase@master] Add monolingual codes nrf-gg (for Guernésiais), nrf-je (for Jèrriais)

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

Thank you :)

In T165648#5965537, @Lydia_Pintscher wrote:

Thank you :)

You're welcome. These are excellent issues for volunteer programmers like me.

Change 579376 merged by jenkins-bot:
[mediawiki/extensions/Wikibase@master] Add monolingual codes nrf-gg (for Guernésiais), nrf-je (for Jèrriais)

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

Change 579595 had a related patch set uploaded (by Raimond Spekking; owner: Raimond Spekking):
[mediawiki/extensions/cldr@master] Add nrf-gg (for Guernésiais), nrf-je (for Jèrriais)

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

Change 579595 merged by jenkins-bot:
[mediawiki/extensions/cldr@master] Add nrf-gg (for Guernésiais), nrf-je (for Jèrriais)

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

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