If the decision here is to follow BCP 47 and use sh for the subdomain, T127680 should be rejected.

Dear @Nikki it is a pity to see this only now (accidentally) and a bit disappointed that you would not consult with me as initiator and/or the growing community of contributors to this project. The choice of HBS is not related only to language code standards *(or which one is more adequate for Wikimedia), but is also a social and political choice in the post-war/still-conflict-packed region of former SFR Yugoslavia. HBS is a spectrum and it could also explicitly include Montenegrin as part of Bosnian-Croatian-Montenegrin-Serbian (BCMS)...

If language committee or Wikimedia tech admins want to reduce this to tech-only and make decision separate of the community of contributors please state this now as we started the work under the premise of HBS approval and change could influence our ambitions over the creation of this new project effort. Our aspirations are not in following SH (former official standards), but accommodating full spectrum of those old + new standards and even keeping it flexible with deviations and hybrids *(as we think it is beneficial for Wikivoyage to be more flexible and less formal in following overly politicized new language standards in the region).

As a matter effect ideally I would not use as first option any of the technical language codes *(as for sure there is no perfect one, that leaves no one estranged in this region), but rather DobarPut.Wikivoyage.org as I elaborated on January 14th proposal. https://w.wiki/5$Fj

Best Z. Blace

I'm not really sure what I could consult you about - using hbs in HTML language tags isn't valid, regardless of how anyone feels about it, and MediaWiki's function for outputting valid BCP 47 language tags has a bug if it's outputting something which isn't a valid BCP 47 language tag.

Langcom revisiting their decision is one potential option, since not having a mismatch between the two codes would avoid the issue, but it's up to Langcom whether they want to do that. If they do, I would expect them to discuss it with the community before coming to a new decision.

OK - I do not understand all the technical options, but switching the sub-domain from HBS to SH would be undesirable. If this can be decoupled from HTML use of language code this could be a compromise on both ends.

It has been more than 3 months since this bug report was made and I tried to get feedback on my proposal and send reminders 5 times by email to get any feedback in past months. Initially I thought that it is a matter of the winter season slowing down for holidays, but now I see other issues are addressed and this is not. Is this issue a hot potato or something else is an issue? (I know language politics is hard to navigate with South Slavic languages, but ignoring it deteriorates our trust and commitment)

@Zblace Sorry for the lack of reply! I think the solution of using a different language tag in the HTML and for the subdomain should work, but there are a few technical hurdles in the way that I am not sure how to solve. I don't think there is any rush in fixing this for the time being though, it would be more of an issue once the Wikivoyage is approved.

In T320885#8415348, @Nikki wrote:

I'm not really sure what I could consult you about - using hbs in HTML language tags isn't valid, regardless of how anyone feels about it, and MediaWiki's function for outputting valid BCP 47 language tags has a bug if it's outputting something which isn't a valid BCP 47 language tag.

This specific issue of the hbs code being used in the lang attribute on Incubator is a feature of the WikimediaIncubator extension. It will output any two- or three-letter code used in a prefix without any further attempt at validation. The relevant code is https://github.com/wikimedia/mediawiki-extensions-WikimediaIncubator/blob/master/includes/WikimediaIncubator.php#L904-L910 . That should probably be improved.

@jhsoby thank you for reply. I hope that (internal) technical requirement and consistency will not force Wy HBS (wider spectrum) to fallback to SH (historic spectrum with Serbian and Croatian standards of pre-breakdown of Yugoslavia) as we do write it and want to accommodate widest spectrum possible (including new standards and local non-standard language use). It is essential for this project to try to have bottom up approach to language (politics) and not just perpetuate top-down language antagonisms in the region. I hope this is clear and acceptable, if not lets have a conversation on this now and not wait for the stress and shock as we try to leave the incubator. OK?

p.s.
I fear that Wikipedians have non-amazing history of having global aspirations and following formalism of 'authorities' even at the expanse of innovation and its own communities of contributors. It would be terrible to have that situation in this context as it would be against this effort.

In T320885#8411665, @Zblace wrote:

HBS could also explicitly include Montenegrin as part of Bosnian-Croatian-Montenegrin-Serbian (BCMS)...

sh in BCP 47 actually DID include all of Bosnian-Croatian-Montenegrin-Serbian languages:
https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry
(find "Macrolanguage: sh" and all 4 languages were included)

The deprecation in ISO 639-1 is only because the split, it did not related to the addition of language members in the macrolanguage. Montenegrin is still part of sh, at least in BCP 47.

Rv'ed unilateral changes to the original task.

There is an ongoing discussion related to moving Serbo-Croatian Wikivoyage to the sh language code. Feel free to participate.

I'm not so enthusiastic about adding yet another code.

As far as standards go, hbs is probably a bit more standard than sh, but it's weird that https://iso639-3.sil.org/code/hbs says that hbs is "equivalent" to sh, but sh is deprecated and hbs isn't.

Technically, it will be a big headache. Will we have a Wikipedia in sh, and a Wikivoyage in the same language, but called hbs? In 2022, I wrote: I'm fine with both codes. "hbs" is cleaner according to the standards, but requires a bit of work, although it's really tiny. Since then, however, I've been dealing a lot with cleaning up language codes, and I see that what I wrote then is a mistake, and it's not tiny at all. We're very far from being done with the backlog of cleaning them up, and there is no good reason to add even more to it.

So at this point, I would suggest to stick to sh.

Also, BCP 47 language subtags use a different standard than ISO 639, so the BCP 47 language subtag would be sh regardless of whether ISO 639 deprecated sh or not.

Thus, the current status is

• BCP 47 language subtag: sh (BCP 47 won't register hbs because already being registered under sh)
• ISO 639 language code: hbs (ISO 639 deprecated sh)

We should stick on BCP 47 language tags/subtags.

https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry

Per this discussion, Serbo-Croatian Wikivoyage is moved to sh language code (AN diff). As this was the preferred option, I'm closing this now. If you think there's anything else to do, feel free to reopen.