On Sun, Apr 12, 2026 at 11:29:32AM +0100, Gavin Smith wrote:
> How are translators going to provide .po files for Serbian ("Ekavian
> pronunciation") in the Latin alphabet? Does it differ significantly
> in its written form from non-Ekavian pronunciation? Is there actually
> a demand from users to use or provide such translations?
I have no idea, but I think that we should provide a framework that
allows users to do it. I just used a random information on a variant
type in the language-subtag-registry, but the support for language
variants and scripts should be generic.
> In short, I propose we wait until specifying such a distinction is a
> real problem for users. I don't feel like we need to provide any more
> flexibility than is available with the language names used by gettext. If
> it hasn't been a problem with the gettext facility it is probably not a
> real problem, or if it is, it should be fixed with gettext as well.
I see no problem using a different system if there is a reason to, as
long as it can be mapped to gettext for the retrieval of translated
strings, possibly with a loss of specificity in the process.
> If Ekavian pronunciation of Serbian was really important to distinguish,
> I would expect this could be accommodated in the LL@VARIANT format, e.g.
> sr@latin-ekavsk.
I do not know how gettext-based system accomodate a script and variant
at the same time.
> > The aforementioned
> >
> > https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry
> > is a better source for that. For instance, there are the Occitan
> > variants there, which are not of that much importance for manuals, but
> > make more sense as languages definitions than oc_FR (which is probably
> > ok for most aspects of locales). They can be mapped to variants, though,
> > like oc@lengadoc (the occitan variant where I live).
>
> Note that I said languages that are likely to get a translation. The IANA
> subtag registry contains all kind of languages and dialects that are not
> likely to be used for formal writing.
But also some that can, since it is the best currently available
information on languages and variants.
> I feel that glibc locale names
> are more likely to reflect the existence of real user communities.
I don't think so. The IANA list seems to me to be a way better
researched list of languages. User communities are real even if they
are small. There are also languages and variants in the IANA list that
are irrelevant for manuals, such as old/extinct languages, probably
some languages that are not written, but it is not an issue not to warn
if such languages are used in documentlanguage. Not allowing manuals to
be written in some languages, however, is a real issue.
> For example, Scots (sco), which is listed with a variant, Ulster Scots
> (sco@ulster). English is my only language, so I can't speak definitively
> about other languages, but Scots as a language would fail to meet several
> criteria:
Maybe, be we can not say about all the languages in the IANA and we
should rely on the best information existing, which is this information.
For Occitan, which I know a bit about, the IANA is quite right, with the
main variants as would be expected today (lengadoc in the place I live).
There are written systems, lexics for computing related vocabulary. The
number of people speaking Occitan in general is decreasing, there are
probably not that many persons interested by Occitan for computer
related documentation and even less able to translate manuals and
strings, but still, deciding that Occitan variants cannot be used as
documentlanguage, while we have the information to do so seems wrong to
me.
--
Pat
