Remove 'sh' (Serbo-Croatian) language ?

sh has been removed from supported languages of MantisBT.

Nike (talk)07:54, 15 March 2023

And the "sh" language should not be deleted (it is still valid in BCP47 even if it has been retired ONLY from ISO 639-1) but ideally moved to "hbs" (still valid in ISO 639-2 and ISO 639-3, also valid in BCP47). Wikimedia wiksi however don't need to be renamed (in BCP 47, both "hr" and "hbs" are equivalent).

Other non Wikimedia projects may opt to not support that language, but it has to remain for Wikimedia, until Wikimedia choose to deprecate it as a selectable user language (in the ULS), even if the "sh.*" wikis are kept (and the "sh:" interwiki code also remains valid to point to these wikis, just like possibly the "hbs:" interwiki prefix which should be the new standard/canonical form).

For translations of labels in Wikidata item, "sh" should probably be deprecated in favor of "hbs", though both codes (in both scripts) may only remain used as a common fallback, when individual codes for Serbian (both Latin and Cyrillic scripts), Bosnian (both scripts), Croatian, Montegrin are not used.

As well their legacy variants subtags (with "-ec" and "-el" instead of "-cyrl" and "-latn") should remain only for Wikimedia wikis doman names and interwikis. All other projects (as well as support for lang="*" attributes in HTML, or xml:lang="*" pseudo-attributes in XML or SVG, or "lang(*)" selectors in CSS) should always use the standard subtags from ISO 15924. And in my opinion, even on this wiki, all translations should be done here using the standard subtags. Wikimedia wiki domain names and interwikis however should support the aliases using standard tags.

Those legacy codes cause problems and cause unnecessary complex maintenance: everything should work everywhere using only standard BCP47 codes.

Aliased codes are not exceptional and not a problem: Wikimedia has aliases for example between the legacy "zh-clasical" code and "lzh", or betwen "zh-yue" and "yue". (it's just a long time to define which alias will be the standard/canonical form): these aliases can persist for long and the migration to standard BCP47 can be planned over long periods and implemented step by step, making sure that nothing is broken long after the transition (it may be up to a decennial, there's no emergency to drop these.


The same cannot be said about serious conformance issues like "nrm" that should be fixed in priority, properly announced, involving the community to allow them to make the work needed in many spreaded pages): the first step is then to create all needed aliases from "nrm" to "nrf", and migrate the internal database names. Then the community can work on converting wiki pages, Wikidata items. Here we can then rename all "nrm" resources to use "nrf" instead. Then we need a transition period not lasting more than 1 year (time sufficient to perform full scans an existing data and plan all corrections needed, in pages, templates, Lua modules, external Wikimedia tools and bots) before we drop the aliases on "nrm", keeping only "nrf": the use of "nrm" should be monitored with tracking logs as much as possible for that period, until these logs become almost empty (logs should try to identify the internal or external source of these legacy usages; trackign external sources can be only managed by Wikimedia admins if this requires parsing server access logs, but Wikimedia admins can run a parser that will analayse and detected when can be publicly reported: the community can then work on these external sources, if they are accessible or can be contacted). The one year delay should allow most external seach engines to fix their indexes, notably for the domain names used in URLs.

After that period, "nrm" is closed, deleted, a new wiki is created for Narom which can be requested. Once such Narom wiki is created, the initial homepage should contain a notice saying that it ois no longer about Norman that can be found elsewhere. Some similar banners may also added in Categories or some new "conflicting" pages created in Narom (such creations of pages in Narom will likely be very slow, and conflicts of page names will not occur in many pages as the Norman and Narom languages are very different, but will occur for example if both languages use the same proper names or borrow the same English terms. There will be no surprise for rare users that may have followed links from old pages or other old sites or documents. Those banners may then be removed after about 3 years (but there will be some community information pages about the wiki were we can trace its history and indicate what was migrated and where. Such public history is important to keep for extremely long periods, just like ISO itself also maintains a public history).

Verdy p (talk)11:38, 15 March 2023
 
sh has been removed from supported languages of MantisBT.

Thanks for this !

I noticed today that the strings_sh.txt file is still present in the repository, meaning whatever was done is apparently not cascading as part of the translation updates.

Can I simply and safely remove the file in the repository ?

-- Damien08:42, 29 August 2023
Can I simply and safely remove the file in the repository ?

Ping...

-- Damien14:19, 15 October 2023

Sorry, I missed the notification for this. Yes you can safely remove it.

Nike (talk)11:21, 16 October 2023

Thanks!

-- Damien06:08, 17 October 2023