Bonjour,
Je constate des erreurs avec le module de prise en charge des traductions. Par exemple, lorsque la langue par défaut est EN, sur la page de login le champs “Password” à un placeholder avec un texte en français. De même pour le bouton de connexion qui a le texte “Se connecter”. Après vérification, les entrée FR et EN existent bien pour les clés “Log in” et “Password”.
Merci pour votre aide
Bonsoir,
Il me semble que la page de login est traduite en fonction de la langue du navigateur web.
Cordialement
Bonjour,
Dans la page login.jsp du DEV-KIT/axelor-web on trouve le code:
Function<String, String> T = new Function<String, String>() {
public String apply(String t) {
try {
return I18n.get(t);
} catch (Exception e) {
return t;
}
}
};
String loginSubmit = T.apply("Log in");
String loginUserName = T.apply("Username");
String loginPassword = T.apply("Password");
qui démontre que les placeholder et libellés sont bien traduits. Néanmoins, si vous utiliser une fresh install vous constaterez une erreur sur la traduction. Ce qui est étrange c’est que la traduction existe bien, donc je n’ai pas encore réussi à trouver l’origine du problème.
Rien de bien méchant car j’ai au final hardcodé le libellé mais ce n’est pas très propre.
Cdlt
Bonsoir,
La récupération de la langue est la suivante :
public static Locale getLocale() {
User user = AuthUtils.getUser();
if (user != null && user.getLanguage() != null) {
return new Locale(user.getLanguage());
}
if (user != null && APP_LOCALE != null) {
return APP_LOCALE;
}
if (LANGUAGE.get() == null) {
return Locale.getDefault();
}
return LANGUAGE.get();
}
Donc on récupère la langue de l’utilisateur, si l’utilisateur n’a pas de langue, on récupère celle du fichier application.properties, si pas d’utilisateur ou si la variable “application.locale” n’est pas définie, alors on prend la langue du navigateur et si elle n’est pas disponible alors on prend celle par défaut de la JVM.
Sur la page de login, n’ayant pas accès à l’utilisateur, on prend donc la langue du navigateur ou à defaut celle de la JVM.
Cordialement
Bonjour,
Je vous confirme que dans le fichier application.properties la valeur application.locale=en est bien présente, donc la langue par défaut est bien définie. Néanmoins, le placeholder du login est bien en anglais mais celui du password est en français, de même pour le bouton de connexion qui est lui aussi en français.
Je n’ai pas trop le temps de trouver l’origine du problème donc pour le moment je reste sur du hardcode.
Cdlt
Bonjour,
Étant donné l’extrait de code, la locale d’application.properties n’est jamais utilisée sur la page du login puisqu’elle n’est active que s’il y a un utilisateur connecté. LANGUAGE est la langue du navigateur
Log In est en anglais car il n’est pas traduit dans les fichiers de ressources (ça manque peut être non ?). Donc je pense que vous accédez tout simplement à l’application avec un navigateur configuré pour prioriser le français
Cordialement,
Bonjour,
Je confirme que la langue du navigateur est bien en français mais la langue par défaut “en” est bien prise en compte puisque le champs “login” est bien en anglais.
Dans la classe I18n du SDK, fonction getBundle(), l’appel à AppFilter.getLocale() permet de voir que le paramètre dans application.properties est bien pris en charge au lancement de l’app.
@Override
public void init(FilterConfig filterConfig) throws ServletException {
try {
final String appLocale = AppSettings.get().get("application.locale", null);
APP_LOCALE = appLocale == null ? null : new Locale(appLocale);
} catch (Exception e) {
}
}
Certes aucune trace ou log pour catcher l’exception donc je vais juste voir en mode débug si cette dernière fonction est bien appelée au moins une fois ou si APP_LOCALE = null.
Cdlt
Re,
APP_LOCALE peut être null ou pas, aucune importance elle n’est pas utilisée en l’absence d’utilisateur (cf l’extrait posté par @gdu-axelor)
Elle n’est pas prise en compte, Log In ne dispose pas de traduction dans les fichiers ressource, il restera donc toujours à Log In.
C’est la locale du navigateur qui s’applique sur la page de login.
Cordialement,
Bonjour,
Mon point de vue diffère concernant la gestion du langage lorsque l’utilisateur n’est pas connecté. Je considère, peut-être à tord pour vous, que lorsque le paramètre application.locale est renseigné il doit être prioritaire sur la langue du navigateur. Si, le paramètre application.locale n’est pas renseigné alors l’utilisation de la langue du navigateur prend tout son sens, mais dans le cas contraire il n’y a aucune raison de l’ignorer. Si je suis votre logique, au final ce paramètre n’est utilisé que si le langage de l’utilisateur n’a pas été choisi lors de sa création.
Cela donne :
public static Locale getLocale() {
User user = AuthUtils.getUser();
if (user != null) {
if (user.getLanguage() != null) return new Locale(user.getLanguage());
if (APP_LOCALE != null) return APP_LOCALE;
}
else {
if (APP_LOCALE != null) return APP_LOCALE;
}
if (LANGUAGE.get() == null) return Locale.getDefault();
return LANGUAGE.get();
}
En entreprise on tente le plus possible de normaliser les interfaces pour simplifier le travail de l’équipe support, du coup cette approche permet à l’administrateur système de choisir d’appliquer une langue par défaut s’il le souhaite. On pourrait aussi même imaginer pour accélérer le traitement des prédicats que lors de la création d’un utilisateur ce soit la langue par défaut qui est automatiquement sélectionnée.
Par ailleurs, il serait bien d’ajouter les traductions manquantes dans la prochaine release pour la page de connexion car si vous souhaitez conserver votre approche alors autant éviter avec un navigateur FR d’avoir la page de connexion à moitié en français et en anglais. Merci
Bien à vous