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

Mon Dec 16 21:19:05 GMT 2019

On 19-11-25 17 h 06, Louis-Philippe Véronneau wrote:
> 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
> 

Well, it seems unlikely this will be done upstream, as Transifex will
not support adding new locales and upstream would have to replace the
current French locale by the gender-neutral one I wrote.

Richard mentioned the possibility of doing this in Debian by adding a
new tarball or by creating a patch.

I'm not incredibly familiar with packages having multiple tarballs, but
it seems this would be the cleanest way to make this happen. With a
little mentoring, I'd be happy to make this happen.

Any thoughts on this? I guess I could submit a Merge Request on Salsa
and see what happens, but it would be nice to have feedback before doing
a bunch of work :)

[Please don't forget to keep me in CC].

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  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/20191216/8be48d3b/attachment.sig>