[jira] [Commented] (ISIS-903) Improve i18n support (in NamedFacetDecorator etc) to honour client-side locale.

["Martin Grigorov (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/ISIS-903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14300202#comment-14300202 ] 

Martin Grigorov commented on ISIS-903:
--------------------------------------

There is a discussion in private between Oscar Bou, Dan Haywod, Jeroen van der Wal and Martin Grigorov.

Jeroen suggested that Isis may use Gettext for i18n:
[1] http://en.wikipedia.org/wiki/Gettext
[2] http://www.gnu.org/software/gettext/manual/gettext.html#Overview
[3] http://blogs.igalia.com/dpino/2009/08/21/i18n-with-gnu-gettext-utilities/
[4] http://blogs.igalia.com/dpino/2009/08/30/setting-up-gettext-commons-for-i18n-java-files/
[5] http://translatehouse.org/products.html

At the moment Oscar and me are in favour of Java resource bundles because Java developers are more familiar with it.

Additionally Jeroen said that "One of the key principles of Naked object is that the domain is reflected in the user interface". I.e. the domain service class name (or action method name) should be used for UI labels.
This is OK for application supporting a single locale.
But sometimes it is needed to use a character which is not allowed to be used as Java identifier. In this case 
{code}
@DomainServiceLayout(named = "...")
{code}
can be used.
But again this is not enough for multilingual application.

One solution is to add yet another optional attribute to DomainServiceLayout/ActionLayout/ParameterLayout that should be used as a key for i18n. For example:
{code}
@DomainServiceLayout(i18n = "some.key")
{code}

Isis would do:
- if there is a key check whether there is a value for the current client locale for this key
- if there is on value or if there is no "i18n" key then use "named" attribute
- if there is no "named" attribute then fallback to the class/method name

This would work for "static" stuff but won't work for special methods like "disabled()" and "hide()". For those we can provide a service, e.g.:
{code}
public String disabledSomeAction(...) { 
  if (condition) { return i18nService.localize("some.key")}
  return null;
} 
{code}


> 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)