In T268033#7314726, @Fomafix wrote:

Is it intended to have sh-Cyrl (Serbocroatian in Cyrillic script) and sh-Latn (Serbocroatian in Latin script) both as content language with automatic transliteration and as user interface language?

Well, if that's the usual terminology for the scripts in which the content is written (sh-cyrl and sh-latn are the two scripts of the Serbocroatian), then yes, those are to be the "content languages" for sh.wikipedia. The original (my) plan was to implement the same solution as for the sr (the mapping i.e. almost the whole code) and to have a similar two-way automatic transliteration (apart from the guessVariant function). After a bit of persuading from @Aca we concluded that a modified automatic transliteration similar to Tajik would suit better, a one-way transliterator, since the idea was to minimize the use of two scripts and in the long run have one script (Latin) but to have an option to read it in two. Second script (Cyrillic) would be allowed for content but if entered as content it would be gradually replaced by Latin. Actually, since Aca is doing all the necessary footwork for the converter stuff I should unassign this task from myself for him formally to take over.

Yes, and if you put sh-latn with either ijekavsk or ekavsk, it substitutes latn with cyrl in the error message.

Well, if sh can't do, there's hbs to go with. This, hbs code , should be still alive and kicking as seen from one of the ISO 639 Registration Authorities at their page here:

Identifier	Language Name(s)	Status	Code Sets	Equivalent(s)	Scope	Language Type	Denotations
hbs	Serbo-Croatian	Active	639-3	639-1: sh (deprecated)	Macrolanguage	Living	Ethnologue, Glottolog, Multitree, Wikipedia