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

[Stefan Winter <address@concealed>]

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
> 


-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
2, avenue de l'Université
L-4365 Esch-sur-Alzette

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
recipient's key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66

Attachment: 0xC0DE6A358A39DC66.asc
Description: application/pgp-keys

Attachment: signature.asc
Description: OpenPGP digital signature