[jbosstools-issues] [JBoss JIRA] Commented: (JBIDE-2969) i18n support in xmodel

[Viacheslav Kabanovich (JIRA)]

    [ https://jira.jboss.org/jira/browse/JBIDE-2969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12435554#action_12435554 ] 

Viacheslav Kabanovich commented on JBIDE-2969:
----------------------------------------------

First, some statistics.

Meta declares
   - 851 different attribute names;
   - 375 different values in lists (like 'yes', 'no', etc.);
   - 624 different menu item names.

However, it many cases equal names are declared in different modules by coincidence. For example, xml attribute "class" is declared in seam-components, seam-pages, hibernate, esb. Is it reasonable to have one key "class" and keep it at common plugin? If we choose more safe way of binding keys to objects, then we have 4400 attributes instead of 851.

Concerning list values, in most cases they are declared by xml schema, (i.e. 'true' and 'false' for attribute 'installed' in element seam:component). We do not hide xml sources, and user will know that on Source page he will find installed='true'. What he is supposed to see and input in drop-down in form editor? Let it be values 'ok' for 'true' and 'nyet' for 'false'. Maybe it is good to have them in drop-down, but we also allow to type value into the text field. So, is user supposed to start typing 'nye...' instead of 'fal...'? Will advanced user, who prefers typing, fill confident to type without looking into drop-down? Another example: attribute 'scope' in seam:component includes values 'stateless', 'STATELESS', etc. Can we translate that difference into Japanese and will it make sense?
Maybe we should limit internationalizing list values only to cases having only internal meaning,  (as 'Visual', 'Source' 'Visual/Source' case; or some yes/no cases when it is about some obvious preferences rather than values declared by schema).
I would not modify XAttributeConstraintAList, but rather add new implementation of drop-down field editor, that could find visual list values by 'model' list values; and assign that drop-down only to few relevant attributes, while most other attributes will have good old drop-down editor.

Concerning //@displayName. That should be ignored. It was designed to keep visual value hard-coded into .meta and cannot be internationalized. Now UI uses @displayName only for menu items, and we can replace that by generating for each action one more key in addition to wizard title key.


> i18n support in xmodel
> ----------------------
>
>                 Key: JBIDE-2969
>                 URL: https://jira.jboss.org/jira/browse/JBIDE-2969
>             Project: Tools (JBoss Tools)
>          Issue Type: Bug
>          Components: common
>            Reporter: Sean Flanigan
>            Assignee: Viacheslav Kabanovich
>             Fix For: 3.0.0.cr1, 3.0.0.GA
>
>
> Snjezana Peco wrote in <http://lists.jboss.org/pipermail/jbosstools-dev/2008-August/001811.html>:
> > I believe that xmodel will make a problem during the 
> > internationalization process because it contains hard-coded constants. I 
> > am not sure if there is any way to internationalize those constants (the 
> > org.jboss.tools.common.model/meta/studio_eclipse_option.meta file 
> > contains the Visual/Source, Source, Preview constants, for instance. I 
> > can't find a way to localize them).
> That's http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbosstools/trunk/common/plugins/org.jboss.tools.common.model/resources/meta/studio_eclipse_option.meta?view=markup
> I suggested merging a template with translated strings during the build process, but then Denis Golivin wrote:
> > IMO That can be fixed. Now names from .meta files are used during 
> > rendering trees, names from .meta files come straight to tree node 
> > label. They cannot be just translated because somewhere in the code name 
> > can be used to obtain object from model. That names are rather keys or 
> > IDs, that should be rendered right with i18n support.
> >
> > I CCed Viacheslav Kabanovich, he is the right guy to find the way to fix 
> > i18n problem in XModel.
> That file still appears to contain embedded English strings, so I don't think this problem has been solved yet.  I don't fully understand the details of the issue, but since I'm raising i18n jiras, I thought I'd better bring it up again.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira