[Pkg-roundcube-maintainers] Packaging an extra locale in Roundcube

[Richard Laager]

[This is really not Roundcube-specific, but I'm not sure where this
conversation would better fit. I'm not sure if this is worth bringing up
on debian-devel, or if there is some sort of i18n list for Debian, or if
this should be discussed with the gettext folks.]

On 11/22/19 11:21 AM, Louis-Philippe Véronneau wrote:
> The 'FEM' comes from the French word for "Gender Neutral" (féminisée). I
> guess if it was more common to have gender neutral translations, having
> something like xx_GN wouldn't be a bad idea, but I haven't seen that
> kind of stuff elsewhere.

xx_GN would conflict with a GN country code, and also implies that it
_is_ for a GN country. The pattern is xx_YY, where xx is a language code
and YY is a country code. (I'm sure you know this, but I'm mentioning it
for clarity for the record and for the flow of this email.)

There is also a pattern of xx_YY at zz. I had written some examples, but
then I found this more authoritative document, so I'll just quote it
instead:

"Some locale names use ‘ll_CC at variant’ instead of ‘ll_CC’. The
‘@variant’ can denote any kind of characteristics that is not already
implied by the language ll and the country CC. It can denote a
particular monetary unit. For example, on glibc systems, ‘de_DE at euro’
denotes the locale that uses the Euro currency, in contrast to the older
locale ‘de_DE’ which implies the use of the currency before 2002. It can
also denote a dialect of the language, or the script used to write text
(for example, ‘sr_RS at latin’ uses the Latin script, whereas ‘sr_RS’ uses
the Cyrillic script to write Serbian), or the orthography rules, or
similar."

https://www.gnu.org/software/gettext/manual/html_node/Locale-Names.html

Based on that, perhaps fr_XX at FEM would be better.

It may be nice if there was a convention of some particular @variant to
indicate a gender-neutral version of the language/translation, rather
than having each language create their own. That might argue for
xx_YY at GN, e.g. fr_CA at GN. GN here would be based on the English phrase
"gender neutral", which is English-privileged, but it's the reality that
the ISO codes are English-based, for better or worse.

On the other hand, finding some ideal way to name this should not hold
up the creation of translations that people want to use. So we should be
careful about bikeshedding here. And doubly so for me, since I don't
speak French or have any interest in using this particular translation.
So please take my thoughts here as some input to help you find a
solution, and nothing more.

> I don't think adding an "N" at the end of an existing locale would
> really make tons of sense, since there are very little difference
> between French locales when doing technical translations (I speak
> "fr_CA" myself).

Having a single French gender neutral translation means that you're not
allowing for regional/dialect differences. Perhaps that makes sense in
this case, but that feels like a bold claim and I'm personally skeptical.

I don't speak French, so I can't really engage in a productive
conversation about the differences between fr_CA and fr_FR. From what I
read, they are quite significant to at least some people. Now, you've
qualified this with "technical", so perhaps that limits the differences.

But I don't think that really matters. Almost _any_ difference is enough
justification for _allowing_ for separate translations. We could use the
example of en_CA vs en_US. There aren't really that many differences,
and the differences aren't particularly critical to understanding. We
can have both, so we can each spell colour/color the way we expect. That
difference is not gender-related and thus would not go away in English
gender-neutral translations. There is no reason to impose en_US "color"
on Canada or en_CA "colour" on the U.S. just because we're trying to
create a gender neutral English translation. And again, this is about
naming the translations with a pattern that _allows_ for these
regional/dialectic differences to exist, not a requirement that you
personally create both fr_FR at GN and fr_CA at GN or whatever they're called.

Also, if things are mostly the same, the common strings can be copied
from fr_FR to fr_CA or vice versa. So having two (or more) translations
isn't necessary double the work.

-- 
Richard