Was ich machen wollte

Bei der Unterstützung der Mehrsprachigkeit mit Spring-Boot ist ein unbeabsichtigtes Verhalten aufgetreten. Daher werde ich es hier beschreiben (wahrscheinlich dasselbe für Spring). Ich wollte die Sprachinformationen von außen abrufen und die Nachricht dieser Sprache anzeigen. Wenn es sich jedoch um eine nicht unterstützte Sprache handelt, zeigen Sie eine Standardnachricht an. Diese Standardmeldung wird jedoch möglicherweise nicht wie erwartet angezeigt.

Beispiel

Angenommen, Sie haben Eigenschaftendateien in englischer und japanischer Sprache, wie unten gezeigt.

`messages_en.properties`


key1=hoge
key2=fuga

`messages_ja.properties`


key1=Hoge
key2=Fuga

Was passiert zu diesem Zeitpunkt, wenn Sie versuchen, die Nachricht durch Angabe von Chinesisch mit der folgenden display () -Methode abzurufen?

    @Autowired
    private MessageSource messageSource;

    public void display() {
        System.out.println(getMessage1(Locale.CHINESE));
        System.out.println(getMessage2(Locale.CHINESE));
    }

    /**
     *Erhalten Sie mehrsprachige Nachrichten.
     * @param locale locale
     * @Mehrsprachige Nachricht zurückgeben
     */
    private String getMessage1(Locale locale) {
        return messageSource.getMessage("key1", null, locale);
    }

    /**
     *Erhalten Sie mehrsprachige Nachrichten.
     * @param locale locale
     * @Mehrsprachige Nachricht zurückgeben
     */
    private String getMessage1(Locale locale) {
        return messageSource.getMessage("key1", null, "Standardnachricht", locale);
    }

Soweit Sie dies sehen können, wirft getMessage1 NoSuchMessageException und getMessage2 Es scheint, als würde "Standardnachricht" angezeigt, aber in meiner Umgebung ist dies nicht geschehen. Beide kommen als "hoge" heraus.

Was schief gelaufen ist

Der obige Code ist nicht schlecht. Die Ursache war eine Eigenschaft von MessageSource. Beim Spring-Boot werden allgemeine Anwendungseigenschaften wie in [hier] gezeigt definiert (https://docs.spring.io/spring-boot/docs/current/reference/html/common-application-properties.html). Es gibt jedoch eine Eigenschaft namens ** spring.messages.fallback-to-system-locale **. In diesem Kommentar

Whether to fall back to the system Locale if no files for a specific Locale have been found.

Es gibt. Die Übersetzung ist

Gibt an, ob auf das Systemgebietsschema zurückgegriffen werden soll, wenn die Datei für das angegebene Gebietsschema nicht gefunden wird.

ist. Dies ist standardmäßig ** wahr ** (im Wesentlichen wenn nicht definiert). Das heißt, solange diese Eigenschaft wahr ist, löst getMessage1 keine NoSuchMessageException aus und getMessage2 gibt keine Standardnachricht zurück. Da die Sprache der Umgebung angezeigt wird, in der die Anwendung bereitgestellt wird, wurde in meiner Umgebung diesmal immer eine japanische Nachricht ausgegeben, wenn eine Sprache übergeben wurde, die nicht übereinstimmte.

Was ist zu tun

Es ist leicht zu beheben. Sie können die folgenden Eigenschaften in application.yml (oder application.properties) festlegen.

`application.yml`


spring.messages.fallback-to-system-locale: false

Wenn MessageSource auf der Java-Seite definiert wurde, kann es mit der folgenden Methode festgelegt werden.

messageSource.setFallbackToSystemLocale(false);

Am Ende

Es war schwierig, die Ursache zu finden. Und da es sich um eine Verhaltensänderung handelt, die je nach Umgebung festgestellt wird, kann es zu einem problematischen Problem werden, dass sie entdeckt wird, wenn Sie sie auf einem fremden Server bereitstellen. Seien Sie also vorsichtig.

[JAVA] Unerwartetes Verhalten der Standardnachricht in org.springframework.context.MessageSource.getMessage ()