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

[Louis-Philippe Véronneau]

On 19-11-25 01 h 00, Richard Laager wrote:
> [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.
> 

Thanks a lot for the input, I find it very helpful.

I've opened an issue upstream [1], but at the moment, it seems the main
problem is Transifex not supporting anything else than a fixed list of
~290 locales.

[1]: https://github.com/roundcube/roundcubemail/issues/7065

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   pollo at debian.org / veronneau.org
  ⠈⠳⣄

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-roundcube-maintainers/attachments/20191125/e941ec35/attachment.sig>