The mailing list for users of the eduroam Configuration Assistant Tool (CAT)

[Tomasz Wolniewicz <twoln AT umk.pl>]

Should we really go that far? I can see problems with automatic language
matching but also with polluting the language selection with 5 versions
of French - this I would consider not very user-friendly. I would
suggest that we do not do language variants and assume that people will
understand and accept possible small differences. We used to have
Portuguese in PT and BR variants but somehow gave up on that.
Tomasz


W dniu 11.10.2018 o 09:15, Stefan Winter pisze:
> Hi again,
>
> even though we were talking about fr_FR and fr_CA all the time: this is
> by no means meant to discriminate fr_BE, fr_CH, fr_LU or fr_MC.
> Translations for all variants are always welcome :-)
>
> Stefan
>
> Am 11.10.18 um 08:36 schrieb Stefan Winter:
>> Hello,
>>
>>> I’m logged into transifex and see the strings available for translation
>>> for ‘fr’,’fr_FR’, and ‘fr_CA’)
>> In Transifex, we usually define language in their per-country
>> specificity - just in case later on another variant is also requested.
>> That way, we can add a second without introducing an ambiguity of
>> whether fr (general) is "better" than fr_CA.
>>
>> In the case of French, indeed we started with fr_FR and then - on your
>> request - added fr_CA for those little variances between the two countries.
>>
>> Actually, I don't see "fr" (general) in Transifex at all? And that's the
>> way it should be.
>>
>> I'm looking at https://www.transifex.com/eduroam_devel/cat/languages/
>>
>>> The most furthest along are contributions to fr_FR.
>> Indeed fr_FR was a complete translation in CAT 1.0.something and
>> throughout CAT 1.1.x. For CAT 2.0 unfortunately the French team did not
>> update any translations and as a result there's now 45% untranslated
>> strings. We can't ship the language like that.
>>
>>> Stefan and dev team, when ‘French’ is shown on the user interface,
>>> should we consolidate these or maybe seed the ‘fr’ translation into one
>>> set?  There may be some deviations from fr_FR and fr_CA but I have to
>>> believe they are minor at best.
>> Right now French isn't shown because none of the two variants has a
>> complete translation at least for the end-user visible part.
>>
>> As soon as one variant finishes, we'll add "French" for it (ignorantly
>> taking any variant as a "better than nothing and the other countries
>> will certainly understand, right" :-) ).
>>
>> In case both complete finish their translations, we'll make that "French
>> (France)" and "French (Canada)" as a distinct option in the UI.
>>
>>> What I don’t know much about are the fall back positions on LOCALE for
>>> these.  I would think that we(as in cat.eduroam.org) would desire to see
>>> all strings in ‘fr’ as the default French LOCALE and if absent, it falls
>>> back to ‘en’. Is this how the dev teams sees the LOCALE detection/usage
>>> working?
>> The master config file defines which locale exactly is used. You can
>> look at the current status quo in Git:
>>
>> https://github.com/GEANT/CAT/blob/release_2_0/config/config-master-template.php
>>
>> As you see there is a language index "fr" mapping to locale "fr_FR" -
>> but is commented out as the translation is not complete.
>>
>> Unless a langauge is clicked explicitly and/or in the current session
>> cookie, the locale is chosen based on the "Accept-Languages" header sent
>> by the browser (the optional priority weights in that header with the
>> q=0.x parameter are ignored). If there's a match in the list of
>> languages, that one is taken.
>>
>> If the browser sets a preference to either fr_FR or fr_CA then
>> a) if we have both, the exact variant is chosen
>> b) if we only have one, fr_"whatever we have" is chosen
>>
>> If no match is found, there is indeed a default, and that is English
>> (which is en_GB actually, as we never had a en_US translation).
>>
>> Note that we never actually had the case where we had two different
>> language variants all completely translated. So while I think the code
>> does what I write above, we'll have a nice round of verification once we
>> have both language variants in our hand.
>>
>>> Insight to helping the French translation along in the most constructive
>>> way is welcome as we would like to contribute to it in the right spot.
>> I like pragmatic approaches: right now the number of French translations
>> is 0. Getting it to 1 is priority; getting it to 2 is somewhat nice to
>> have. Which variant it is, I don't care much.
>>
>> So you could either work with the fr_FR team to get their translation up
>> to speed for inclusion, or you could work on fr_CA and complete that
>> one. If you want to do that, I can also copy the existing fr_FR
>> fragments to fr_CA to give you a jumpstart (which you then still need to
>> review for their possible non-Canadianness).
>>
>> So long as whatever path you chose is the only path that is being taken,
>> it does not matter at all whether the locale is called fr_CA or fr_FR -
>> if we only have one French at our disposal, that's the one we will use,
>> and we will label it "French". Only source code and product config files
>> will reveal the difference.
>>
>> Greetings,
>>
>> Stefan Winter
>>
>

-- 
Tomasz Wolniewicz    
          twoln AT umk.pl        http://www.home.umk.pl/~twoln

Uczelniane Centrum Informatyczne   Information&Communication Technology Centre
Uniwersytet Mikolaja Kopernika     Nicolaus Copernicus University,
pl. Rapackiego 1, Torun               pl. Rapackiego 1, Torun, Poland
tel: +48-56-611-2750     fax: +48-56-622-1850       tel kom.: +48-693-032-576

Attachment: smime.p7s
Description: Kryptograficzna sygnatura S/MIME