Overriding JSF's default I18N handling

Question

Like the asker of the question here

Variable substitution JSF Resource Bundle property file

I'm slightly aghast at the inability to reference the value of other property keys in the message bundle.

Although I see how easy to write my own rubbish handler[0] that can do what I want in a custom component, that would leave expressions in templates calling the message bundle still using the default JSF implementation.

Is it possible to override the default JSF handling of the message bundle?

[0] Or better, to use code referenced in one of the answers to the above question https://code.google.com/p/reflectiveresourcebundle/

score 1 · Accepted Answer · edited May 23 '17 at 12:34

You can provide the fully qualified name of a concrete ResourceBundle implementation as "base name" instead of alone the path and filename of the properties files.

E.g.

public class YourCustomResourceBundle extends ResourceBundle {
    // ...
}

which can be registered as follows

<application>
    <resource-bundle>
        <base-name>com.example.YourCustomResourceBundle</base-name>
        <var>text</var>
    </resource-bundle>
</application>

or declared on a per-view/template basis as follows

<f:loadBundle baseName="com.example.YourCustomResourceBundle" var="text" />

Here are several related questions/answers which contain some concrete code which you could use as a kickoff example:

Thanks for the answer Balus and the useful follow up links – solidgoldpig Jul 16 '12 at 10:19 — solidgoldpig, Jul 16 '12 at 10:19

score 0 · Answer 2 · answered Jul 09 '12 at 17:02

Everything is possible for those who try. The question is not whether it is is possible but should you do it. And the answer to that question is: probably not.

Referencing other message in a message bundle means you want to build a compound message. So you can re-use part of the message many times just to save small fraction of the disk space or small fraction of development time.
If that is the case, I have a message for you. What you plan to do is called a concatenation and it is the second most common I18n defect. And its implications are as bad as those of hardcoded strings.

Why? Because target languages do not follow the English grammar rules. First, it is common need to re-order the sentence while translating. This might be easy to fix by using (numbered or named) placeholders. On the other hand though, the translation might differ depending on the context. That is, it might need to be translated in totally other way, or simply the word endings might need to be different depending on a grammar case, mood or gender.

My advice is, do not use such shortcuts, it will create more problems than it fixes.
Now you should know why "those stupid Romans" didn't implement it like this: it is against I18n best practices.

Thanks for your answer - I understand the shortcomings of aliasing, but I have never found it to be a problem in the real world either using gettext or more home-brewed solutions. — solidgoldpig, Jul 16 '12 at 10:21

Overriding JSF's default I18N handling

2 Answers2