On Sat, Apr 11, 2026 at 05:02:52PM +0300, Eli Zaretskii wrote:
> > Date: Sat, 11 Apr 2026 15:53:54 +0200
> > From: Patrice Dumas <[email protected]>
> > Cc: [email protected], [email protected]
> > 
> > > > @documentscript latin
> > > 
> > > Script and language are not the same.  There are scripts which support
> > > many languages (the most obvious example is the latin script).
> > 
> > Indeed.  @documentscript would only be for the script, and should only
> > be needed if there are multiple scripts.  For example
> > 
> > @documentlanguage sr
> > @documentscript Latn
> 
> That's so rare I doubt a general-purpose facility is justified.  There
> are maybe half a dozen languages in the whole world that can be
> written with more than one script.  So using modifiers here is much
> more reasonable, IMO.
> 
> Your call, of course.

I tend to agree.  (I know I already changed my mind on this.)  It seems
simple enough to say that the argument to @documentlanguage follows the
same format as the language specification for a po file: LL_CC@VARIANT.
We already have code to strip off a _CC suffix so it would probably be
easy enough to deal with an @VARIANT suffix similarly.

As discussed, texi2any could transform the @VARIANT to an appropriate
form for HTML, LaTeX, DocBook or other, if we know how to do this.

One question remains, and that is what to do with the contradictory
alphabets used for the current Serbian translations.  As po/sr.po and
po_document/sr.po are currently Cyrillic, and those files are more updated
(due to being translated through the Translation Project), I would guess
that if we had to choose, that "@documentlanguage sr" should use the
Cyrillic alphabet, and "@documentlanguage sr@latin" should use the Latin
alphabet.  So perhaps txi-sr.tex should be renamed [email protected].

This directory in the glibc sources appears to show the names of many
of the languages used in glibc locales:

https://sourceware.org/cgit/glibc/tree/localedata/locales

Ignoring the @euro variants, it gives an idea how many languages are likely
to get translations in multiple alphabets.  The number of languages with
user communities who are likely to produce translations is likely smaller
still.

Reply via email to