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

[Sean Flanigan (JIRA)]

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

Sean Flanigan commented on JBIDE-2969:
--------------------------------------

Max, I wasn't assuming anything about when i18n might get into the source!  Although I see now that this issue has targeted Fix Versions, which should have been a clue for me...

Viacheslav, thanks for the reply.

Viacheslav Kabanovich (JIRA) wrote:
> 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.

I don't quite follow you, Viacheslav.  When you say 851 attribute names, are these the names of seam/hibernate/etc XML attributes which are generated by JBoss Tools?  Perhaps we should leave them entirely alone, like the list values you mention further down?  But I'll assume not, for now.

To get the 4400 attribute names, are you assuming that all "class" strings have the same meaning within all the .meta files in a plugin?  Or are you treating every single occurrence separately?

Ideally, we need to find the highest level of granularity such that all identical strings (eg "class") have the same meaning.  At the lowest level of granularity, every occurrence of every string is treated separately, but you have so many msgids (keys) that the L10n team's job is too big.  At the highest level of granularity, identical strings are assumed to have the same meaning across all .meta files in JBoss Tools, but translation becomes nearly impossible because the same string has different meanings in different places.

I suspect that the sweet spot is at the level of plugins.  All identical strings within a given plugin's .meta files are assumed to have the same meaning.  (In practical terms, each plugin would produce one POT file for translation, and each unique string would become a translation key (msgid).)  Is that what you were suggesting?

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

I'm not sure about this.  I'm not it would be very intuitive to offer keyboard shortcuts that don't correspond to what's visible in the GUI, only to the invisible English translation.  I suspect most users would prefer to be able to type part of the string they see.  Perhaps we need to support both types of user, with a configuration option to select which they want.

> Another example: attribute 'scope' in seam:component includes values
> 'stateless', 'STATELESS', etc. Can we translate that difference into
> Japanese and will it make sense?

Good point.  Distinguishing between 'stateless' and 'STATELESS' is already difficult enough in English!  If the list is there to select an exact value which is destined for an XML file, we should make that value available to the user.  Perhaps in brackets after the best-effort translation?  (Eg 	
ステートレス (stateless) and 	
ステートレス (STATELESS).

Some users might feel differently though.  Sometimes you use a UI because you don't know the syntax of the underlying file.  At some point, we might want to allow users to see their own language for simple things like boolean values.  I think that can wait until a later release though.

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

Makes sense to me.  At least for this release.

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

I gather this relates to the "nye..." versus "fal..." problem.  In other words, the new editor would let the user type "fal" (from the model) to select the "nyet" option (as displayed in the UI).  As I said above, I'm not sure most users would want that.  But there are various ways of implementing it.  Whatever makes most sense.
 
> 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.

Okay, but I think we could use the existing displayName as a lookup key if we want to.  Again, whatever makes most sense is fine.


> 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