When you're developping Web applications, you often ask yourself
what does your beautiful design will look like if your users enter a
very long text. Or you may want to prototype a new screen based on
an existing one, I came around a quick hack using HTML5 goodness:
content editable
!
On the page you want to edit, open your JavaScript console
(Cmd+Alt+I on Chrome Mac), and enter the following
document.body.contentEditable=true;
Now you can freely edit the text on your page, once you're done, you
can switch off the content editable mode setting the property to
false !
At SRMvision, we develop with
localization in mind. We don't have any user visible text that is
not in fact tied to a java property file. Quickly, the problem that
we faced was the difficulty to keep every language file in sync (and
to tidy things up). We developed a small Maven plugin allowing us to
ensure that our two main problems are now gone :
merge-properties-maven-plugin.
Quick example
I think the easiest way to understand how it works is to explain it
with a real use case. Let's say we have a module named
Zones in our application, it will lead to create four files
(if we are localized in two different languages) :
l10n/Zones_en.properties
l10n/Zones_fr.properties
help/Zones_en.properties
help/Zones_fr.properties
As you might have guessed, we have got two different categories of
target files, one for the application's localization, and the other
one for the application's help. There is only one rule when it comes
to filling these files, the property keys must begin with the name
of the file, otherwise the build would fail. In this example, every
key must begin with the prefix "Zones.".
At the end, we want to get two resource bundles, so we set up the
build to do so :
By reading this configuration section you can view almost every
single option available in the plugin. You can exclude files from
automatic key checking : in the example the files
Global_*.properties will not be checked. It allows us to group
commonly used keys without needing them to begin with the correct
prefix (it also eases migration for legacy code, breaking the build
would be too intrusive).
You can also notice that we use a Maven property to enable the fail
on count mismatch functionality of the plugin, with the help of
Maven profiles, we can set it to false for development and to true
for continuous integration and translation team. When this
configuration is used you will get an output like the following in
your Maven build :
If the build should check consistency in merged files and if it does
not match, it will output blank keys as well as lonely keys in order
for your translator to fix it easily.
Bonus feature
We use Java's MessageFormat to format our translated string, one of
the thing we tend to forget is to escape the single quotes in our
translations. The plugin does this magic for us, it automatically
adds the missing single quotes in every messages.
I was having a strange issue with localization in a Play Framework
application. I followed the
simple steps
detailed on the official documentation but with no luck.
When experimenting, I figured out that the locale used is the
default locale of the JVM. In my case, my default locale is French
so I only had French in my application. But on Heroku, the default
locale is English and thus the application was only working in
English.
The trick consists in adding an implicit lang to your template
views. In fact, Scala import an implicit lang with the lowest
priority being the one coming from the JVM, if you want to get the
language parsed from the Accept-Languages http header, you need to
add an implicit as below :
@(title:String)(content:Html)(implicitlang:Lang)
With this little trick, your calls to localization will use the
locale extracted from the http request as expected.
