Open anarchivist opened 4 years ago
Another potential option is to copy the content of the default script (e.g. either sr-Latn
or sr-Cyrl
) as the content for the "basic" version of the language (sr
).
This is arguably a less elegant fallback solution, which has a small maintenance risk (in case the variant is updated then one shouldn't forget to update the basic version). But it doesn't need any new technical development, which is a big benefit.
Also it may provide more flexibility to translators. I.e. if someone does want to mix Cyrillic and Latin for a "basic" version in Serbian, then they can do it. Forcing sr
to redirect either to sr-Latn
or sr-Cyrl
wouldn't allow this. (NB: I'm not saying that this wouldn't be manageable with a technical development. But we need not to enforce the "default" behaviour by always having a redirection to a variant).
Another potential option is to copy the content of the default script (e.g. either sr-Latn or sr-Cyrl) as the content for the "basic" version of the language (sr).
Instead of copying, you could also just provide Serbian in the Latin alphabet as sr
and then add any additional scripts using a suffix. Requests for sr-Latn
should then default to sr
.
We have a case where we will now ned to support (identical) translations in a single language expressed in multiple scripts. The near term priority is Serbian (
sr
), given the current languages in the translation queue.We know that we can qualify the BCP47 language tag with a script suffix (e.g.
sr-Latn
for Serbian in the Latin alphabet, andsr-Cyrl
for Serbian in the Cyrillic alphabet). However, we need to have a configurable option that allows us to define the "default" script if the rights application receives a request for the translation unqualified by script code (e.g. justsr
).Potential options include setting this in the application's configuration file.