Dans le user la langue et le langage préféré sont bien Français partout. Cependant, l’utilisateur est quand même en anglais sur les boutons simplicité (Save, Save & Close etc…). L’utilisateur est obligé de changer sois même la langue en haut à droite.
Le pays est une simple donnée informative et n’entre pas en ligne de compte pour le choix de la langue UI.
Pour setter la langue il faut effectivement forcer la valeur des attributs usr_lang et usr_lang_pref.
Dans quel platform hook implémentez vous cela ?
En fonction de là où vous le faites il peut être aussi nécessaire de forcer la langue au niveau du grant déjà partiellement ou totalement chargé via setLang et setLangPreference (et aussi potentiellement setLanguages)
NB: Merci de systématiquement indiquer la version exacte que vous utilisez dans toutes vos demandes de support. On vous demande cela pour vérifier si vous êtes à jour ou au moins pour vérifier si dans les commits sur lesquels vous êtes en retard il n’y aurait pas des choses en lien avec votre demande. Pour rappel l’objectif est donc de ne pas perdre de temps à essayer de reproduire un pb qui n’existe peut être plus.
Vous pouvez tester via getGrant().getLang() la langue chargée dans la session, ou la modifier par code au postloadGrant via un setLang, mais cela ne supprimera pas la possibilité d’en changer sur la UI.
Les langues autorisées se paramètrent également au niveau des pages d’accueil de votre application si vous en avez paramétré. Simplicité fait l’intersection entre la langue courante (usr_lang) et celles implémentées par l’application (vue accueil), si rien est coché, Simplicité ne fait rien et laisse la langue courante.
Autre précision, en V5 pour changer la langue d’un utilisateur une fois connecté, il faut passer par la nouvelle méthode :
getGrant().changeLang(Globals.LANG_FRENCH, true);
Cela va modifier le usr_lang en base (et usr_lang_pref si le second paramètre est à true)
Et aussi recharger le cache de session du User
C’est la méthode invoquée en back lorsqu’on clique sur une autre langue en front dans le popup de sa session (second paramètre à false, on garde sa langue préférée, on change uniquement celle en cours).
A quel endroit dois-je forcer la langue donc ? Quoi qu’il en soit, je ne comprends pas pourquoi en base on a bien les bonnes valeurs et quand l’utilisateur se connecte c’est en anglais par défaut… Y’a pas de problème de cache à priori. J’ai fait le test suivant :
Je me connecte avec le user, je switch en français → OK, Je supprime ce user, il se recréé donc automatiquement à sa connexion suivante et l’anglais est de nouveau par défaut alors que les valeurs en base pour ce user sont correctes.
Donc votre code n’est pas au bon endroit, un autre traitement doit le forcer à ENU.
Les données de l’IdP (token, user-info…) sont également mappées par Simplicité, contiennent-elles la langue anglaise (locale, language…) qui expliquerait cette surcharge ?
Il y a également un paramètre système USER_SYNC_DEFAULTS qui fixe les valeurs par défaut du user lors d’un provisionning automatique, il contient un object Json de champ/valeur du User. Il y a peut être { "usr_lang": "ENU" } dedans. Je ne sais pas si vous passez par ce mécanisme.
Sinon comme indiqué, dans le PlatformHooks.postLoadGrant(Grant g), vous pouvez forcer la langue si jamais elle n’a pas été correctement positionnée avant.
// Force to FRA if not already set
if (!Globals.LANG_FRENCH.equals(g.getLang()))
g.changeLang(Globals.LANG_FRENCH, true);
Attention l’appel de cette méthode recharge les droits, donc si la langue est forcée à ENU par ailleurs, cela risque de partir en boucle, à vous de mettre le “if” qui évite cela en fonction du user non ADMIN.
Ca à l’aire de fonctionner en utilisant la valeur FRA, le paramètre n’était pas utilisé auparavant. Depuis l’IDP on ne passe pas de paramètre liés à la locale donc je pense pas que ce soit ça.
Et effectivement, avant cette réponse j’ai testé de forcer dans le postload sans protection ce qui a fortement destabilisé l’application.
