jte has no built-in keywords for localization. Instead, it provides a flexible interface so that you can easily use the same localization mechanism you're used to in your project. This has several advantages:
- No need to learn yet another way to localize things
- No need to reverse engineer another opinionated localization implementation
- Your users receive the exact localization through jte as they do from the rest of your application
gg.jte.support.LocalizationSupport. There's only one method to implement:
Now, you can create a
JteLocalizer whenever you render a page and pass it to the page template:
Why is the
gg.jte.support.LocalizationSupport interface even needed? It mainly helps with proper output escaping in HTML mode. Localized texts are considered safe and are not output escaped, but all user-provided parameters are! Here are some good examples in the form of unit tests.
This works fine, but passing a parameter to every template might feel repetitive. If it does, you could use a
java.lang.ThreadLocal, filled with the required information before rendering a page and destroyed afterwards.
And the, when rendering the page:
Localization in the template is now possible with a simple static method call:
Whether you prefer a parameter or a static method call is a matter of taste. The nice thing about both ways is that everything is under your control, and if you want to know what happens under the hood, that is just a click away in your IDE.