J'ai rencontré un comportement involontaire lors de la prise en charge de la multilinguisme avec spring-boot, donc je vais le décrire ici (probablement la même chose pour le printemps). Ce que je voulais faire était d'obtenir les informations sur la langue de l'extérieur et d'afficher le message de cette langue, mais s'il s'agit d'une langue non prise en charge, affichez un message par défaut. Toutefois, ce message par défaut peut ne pas apparaître comme prévu.
Supposons que vous ayez des fichiers de propriétés de langue anglais et japonais comme indiqué ci-dessous.
messages_en.properties
key1=hoge
key2=fuga
messages_ja.properties
key1=Hoge
key2=Fuga
À ce stade, que se passe-t-il si vous essayez d'obtenir le message en spécifiant le chinois avec la méthode display () suivante?
@Autowired
private MessageSource messageSource;
public void display() {
System.out.println(getMessage1(Locale.CHINESE));
System.out.println(getMessage2(Locale.CHINESE));
}
/**
*Recevez des messages multilingues.
* @paramètre locale locale
* @retourner un message multilingue
*/
private String getMessage1(Locale locale) {
return messageSource.getMessage("key1", null, locale);
}
/**
*Recevez des messages multilingues.
* @paramètre locale locale
* @retourner un message multilingue
*/
private String getMessage1(Locale locale) {
return messageSource.getMessage("key1", null, "Message par défaut", locale);
}
Pour autant que vous puissiez voir ceci Javadoc, getMessage1 lance NoSuchMessageException et getMessage2 Il semble que "message par défaut" soit affiché, mais cela ne s'est pas produit dans mon environnement. Les deux sortent comme "hoge".
Le code ci-dessus n'est pas mauvais. La cause était une propriété de MessageSource. Dans spring-boot, les propriétés d'application courantes sont définies comme indiqué dans here. Cependant, il contient une propriété appelée ** spring.messages.fallback-to-system-locale **. Dans ce commentaire
Whether to fall back to the system Locale if no files for a specific Locale have been found.
Il y a. La traduction est
S'il faut revenir aux paramètres régionaux du système si le fichier correspondant aux paramètres régionaux spécifiés n'est pas trouvé.
est. C'est ** vrai ** par défaut (essentiellement si non défini). Autrement dit, tant que cette propriété est vraie, getMessage1 ne lèvera pas d'exception NoSuchMessageException et getMessage2 ne retournera pas de message par défaut. Puisque la langue de l'environnement dans lequel l'application est déployée est affichée, dans le cas de mon environnement cette fois, un message japonais était toujours émis lorsqu'une langue qui ne correspondait pas était passée.
C'est facile à réparer. Vous pouvez définir les propriétés suivantes dans application.yml (ou application.properties).
application.yml
spring.messages.fallback-to-system-locale: false
Si MessageSource a été défini du côté Java, il peut être défini avec la méthode suivante.
messageSource.setFallbackToSystemLocale(false);
Il était difficile de trouver la cause. Et comme il s'agit d'un changement de comportement qui est détecté en fonction de l'environnement, même s'il n'y a pas de problème de test dans votre propre pays, cela peut devenir un problème gênant qu'il soit découvert si vous le déployez sur un serveur étranger, alors soyez prudent.
Recommended Posts