[
https://issues.apache.org/jira/browse/ISIS-903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14301271#comment-14301271
]
Jeroen van der Wal commented on ISIS-903:
-----------------------------------------
The argument that Java developers are more familiar with resource bundles is
true. However, I have not encountered a single developer yet who liked working
with it. Especially the fact that they have to maintain two code artefacts in a
non-typesafe manner is laborious and error prone.
My key principle is that a development team should *never* be bothered with the
translation of an application. They develop in the language that is ubiquitous
across the team, including the product owners. Translation is usually done
separately by translators who don't even have to be on the team.
A usual workflow could be:
1. Development team creates application in their "own" language. Additionally,
strings in code that end up in the UI are wrapped.
2. A maven command is used to extract all visibile text. From the metamodel it
will take it's name (eg. "New Todo"), the @Named override when applicable and
the @DescribedAs. From the source code it will parse the wrapped strings. The
result is a single .pot file for the translatable items.
3. The .pot file is translated into a localised .po file. This can be done
trough various tools, including online. The .po files are placed in the WEBINF
folder so they can be maintained independent from the application release cycle.
Another big advantage I see in this approach is the fact that also includes
Isis add-on modules will be included for translation without additional work.
Except for wrapping strings in code of course.
Introducing label identifiers would devaluate the power of developing in Isis
and is merely cutting corners.
>From a technical point both approaches are the same. The additional component
>in the GNU gettext approach is the the maven task to extract the metamodel
>items. Here we could extend Dan's work on the metamodel exporter.
> Improve i18n support (in NamedFacetDecorator etc) to honour client-side
> locale.
> -------------------------------------------------------------------------------
>
> Key: ISIS-903
> URL: https://issues.apache.org/jira/browse/ISIS-903
> Project: Isis
> Issue Type: Improvement
> Components: Core
> Affects Versions: core-1.6.0
> Reporter: Dan Haywood
> Assignee: Dan Haywood
> Priority: Minor
> Fix For: core-1.9.0
>
>
> from the mailing list: http://markmail.org/message/wifsrte2p2q6tces
> ok, here's the scoop.
> It *is* possible to add i18n for Isis apps, but the implementation we have
> reflects the locale of the server, rather than the client.
> If client-side i18n is what you require then it ought to be possible to
> implement a different implementation of I18nFacetDecoratorInstaller. You can
> get hold of the user's locale using:
> AuthenticatedWebSessionForIsis.get().getLocale()
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
