Adding a new language to jakarta.faces.Messages internationalizations

Question

In jakarta.faces these are the only Messages translations available (Messages shown are taken from this jar jakarta.faces-4.1.1 located at jakarta.faces.Messages):

I need to add a Messages_it.properties to manage errors on the web page for an Italian website (for form validation errors).

What I have done is:

1. copied all these properties under my own resources folder under the package jakarta.faces
2. added a file "Messages_it.properties" with the required translations in the same directory

But it seems that it isn't being loaded when running the code because I always get the english translations (so basically it automatically switches to the default ones).

I should mention that I can perfectly see the other languages (en, fr, de, es) if I switch from a language to another. But I can't load the new one (it lang).

I tried adding it to my faces-config.xml as resource-bundle or message-bundle, but again without success.

<application>
   <message-bundle>jakarta.faces.Messages</message-bundle>
</application>

Probably I'm missing some basic configuration.

Answer 1

copied all these properties under my own resources folder under the package jakarta.faces

That's unnecessary. Unless you want to override one of the default translations. You can safely remove all of the unmodified resource bundle files already provided by Jakarta Faces and keep only your own custom Messages_it.properties file.

added a file "Messages_it.properties" with the required translations in the same directory

That should work. There's however ambiguity in where exactly the resources folder is located, and how exactly the path to the jakarta.faces package is created. It's unclear which build tool you're using, but based on your previously asked questions you appear to be using Maven. In that case, the Messages_it.properties has ultimately to end up in the exact disk file system path src/main/resources/jakarta/faces/Messages_it.properties.

From your screenshot it's not exactly clear where the resources folder itself is located. In a Maven project structure for a WAR application there are 2 options: src/main/resources and src/webapp/resources. Only the former is correct because it will end up in the runtime classpath and the resource bundle files need to be loaded via the class loader. The latter only exposes the files into the public web via a HTTP server. See also Maven and JSF webapp structure, where exactly to put JSF resources.

It's also not exactly clear whether you created a resources/jakarta/faces path with doubly nested subfolders, or a resources/jakarta.faces path with a single nested subfolder which is literally named jakarta.faces. Only the former is correct, like as in case of normal Java packages/classes. Confirm with your OS native disk file system explorer rather than via the IDE.

I tried adding it to my faces-config.xml as resource-bundle or message-bundle, but again without success.

That's unnecessary. The <resource-bundle> isn't used by Jakarta Faces built-in application messages and the <message-bundle> already has a default value of jakarta.faces.Messages which is correct. It's only needed when you have placed all your own translations in a different location. See also Internationalization in JSF, when to use message-bundle and resource-bundle?

The only thing which you need to make sure is that the it locale is among the explicitly configured <supported-locale>s of the <application><locale-config> in your webapp's faces-config.xml, otherwise it will be plain ignored.

E.g.

<application>
    <locale-config>
        <default-locale>en</default-locale>
        <supported-locale>de</supported-locale>
        <supported-locale>es</supported-locale>
        <supported-locale>fr</supported-locale>
        <supported-locale>it</supported-locale>
        ...
    </locale-config>
</application>

Just to reconfirm, the <f:view locale="#{...}"> must also explicitly refer the it locale. See also Localization in JSF, how to remember selected locale per session instead of per request/view.