| Which EEnum field to use for i18n? [message #510060] |
Tue, 26 January 2010 07:39  |
Eclipse User |
|
|
|
I am not sure which field (if any at all) of an EEnum I could use for internationalization.
If I create an EEnum in an ecore file and generate the model, the EEnum toString method returns the literal field.
[QUOTE]
/**
* Returns the literal value of the enumerator, which is its string representation.
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated
*/
@Override
public String toString() {
return literal;
}
[UNQUOTE]
Generating an EMF editor shows the EEnum toString text in the properties view.
This made me believe the literal field would be appropriate to use for i18n as this is what a user would see.
However if I save the model using an XMIResource any element having an attribute referencing the EENum is also using the literal as value (not the name). I guess the toString method is used to get the value for the attribute. If I now use the literal field for i18n this would mean that there is a problem exporting to XMI using one locale and importing using another. The literal is here merely used as an id and importing the same XMI using another locale would not locate the item in the model.
Example:
I declare an enum in the ecore file:
<eClassifiers xsi:type="ecore:EEnum" name="InputType">
<eLiterals name="text" literal="Schrift"/>
<eLiterals name="number" value="1" literal="Zahl"/>
</eClassifiers>
In InputType.java I override the constructors to retrieve the literal according to locale:
TEXT(0, "text", Messages.getString("InputType.0"));
NUMBER(0, "number", Messages.getString("InputType.1"));
I use two message files:
message.properties
InputType.0=Text
InputType.1=Number
message_de.properties
InputType.0=Schrift
InputType.1=Zahl
With locale 'de' the generated EMF editor will show "Schrift" resp. "Zahl" but also the XMIResource will save any reference to this enum with the value "Schrift" or "Zahl". If I then open the XMIResource with the default locale ('en') there will be an attempt to locate an enum item "Zahl" where there is either "Text" or "Number". This does not seem correct to me.
Could someone help me resolve this uncertainty?
Thanks in advance
Bjoern
|
|
|
|
|
| Re: Which EEnum field to use for i18n? [message #510073 is a reply to message #510068] |
Tue, 26 January 2010 08:18  |
| Eclipse User |
|
|
|
Hi Ed,
Thanks for your answer. What a moron I am to have forgotten those properties! :-D
I had completely overseen them.
Cheers
Bjoern
"Ed Merks" <Ed.Merks@gmail.com> schrieb im Newsbeitrag news:hjmp4r$8q8$1@build.eclipse.org...
> Bjoern,
>
> Comments below.
>
> Bjoern Sundin wrote:
>> I am not sure which field (if any at all) of an EEnum I could use for internationalization.
> No, the enums themselves are not intended to be translated.
>>
>> If I create an EEnum in an ecore file and generate the model, the EEnum toString method returns the literal field.
>>
>> [QUOTE]
>> /**
>> * Returns the literal value of the enumerator, which is its string representation.
>> * <!-- begin-user-doc -->
>> * <!-- end-user-doc -->
>> * @generated
>> */
>> @Override
>> public String toString() {
>> return literal;
>> }
>> [UNQUOTE]
>>
>> Generating an EMF editor shows the EEnum toString text in the properties view.
>>
>> This made me believe the literal field would be appropriate to use for i18n as this is what a user would see.
>>
>> However if I save the model using an XMIResource any element having an attribute referencing the EENum is also using the literal
>> as value (not the name). I guess the toString method is used to get the value for the attribute. If I now use the literal field
>> for i18n this would mean that there is a problem exporting to XMI using one locale and importing using another. The literal is
>> here merely used as an id and importing the same XMI using another locale would not locate the item in the model.
>>
>> Example:
>>
>> I declare an enum in the ecore file:
>> <eClassifiers xsi:type="ecore:EEnum" name="InputType">
>> <eLiterals name="text" literal="Schrift"/>
>> <eLiterals name="number" value="1" literal="Zahl"/>
>> </eClassifiers>
>>
>> In InputType.java I override the constructors to retrieve the literal according to locale:
>> TEXT(0, "text", Messages.getString("InputType.0"));
>> NUMBER(0, "number", Messages.getString("InputType.1"));
>>
>> I use two message files:
>> message.properties
>> InputType.0=Text
>> InputType.1=Number
>>
>> message_de.properties
>> InputType.0=Schrift
>> InputType.1=Zahl
>>
>> With locale 'de' the generated EMF editor will show "Schrift" resp. "Zahl" but also the XMIResource will save any reference to
>> this enum with the value "Schrift" or "Zahl". If I then open the XMIResource with the default locale ('en') there will be an
>> attempt to locate an enum item "Zahl" where there is either "Text" or "Number". This does not seem correct to me.
>> Could someone help me resolve this uncertainty?
> Translation should be done as a separate mapping that's used when "visualizing" or present the values in the UI. If you look in
> the generated *.edit project's plugin.properties you'll see that's where the translations are for the enumerators and that's what
> the drop down combo box in the properties view will show the user.
>>
>> Thanks in advance
>> Bjoern
>>
|
|
|
| Re: Which EEnum field to use for i18n? [message #510074 is a reply to message #510067] |
Tue, 26 January 2010 08:19 |
| Eclipse User |
|
|
|
Hi Tom,
Thanks for the answer. Yes, this sounds true. As one can see in Eds answer I disregarded the obvious.
Cheers
Bjoern
"Tom Schindl" <tom.schindl@bestsolution.at> schrieb im Newsbeitrag news:hjmp39$f1j$1@build.eclipse.org...
> Hi,
>
> i18n is a *pure* UI-Feature IMHO and the translation happens in your
> VIEW (if we assume an MVC-Pattern) when the model gets rendered.
>
> If we futher assume you use JFace-Viewers for example the translation
> happens in your LabelProvider.
>
> Tom
>
> Am 26.01.10 13:39, schrieb Bjoern Sundin:
>> I am not sure which field (if any at all) of an EEnum I could use for
>> internationalization.
>>
>> If I create an EEnum in an ecore file and generate the model, the EEnum
>> toString method returns the literal field.
>>
>> [QUOTE]
>> /**
>> * Returns the literal value of the enumerator, which is its string
>> representation.
>> * <!-- begin-user-doc -->
>> * <!-- end-user-doc -->
>> * @generated
>> */
>> @Override
>> public String toString() {
>> return literal;
>> }
>> [UNQUOTE]
>>
>> Generating an EMF editor shows the EEnum toString text in the properties
>> view.
>>
>> This made me believe the literal field would be appropriate to use for
>> i18n as this is what a user would see.
>>
>> However if I save the model using an XMIResource any element having an
>> attribute referencing the EENum is also using the literal as value (not
>> the name). I guess the toString method is used to get the value for the
>> attribute. If I now use the literal field for i18n this would mean that
>> there is a problem exporting to XMI using one locale and importing using
>> another. The literal is here merely used as an id and importing the same
>> XMI using another locale would not locate the item in the model.
>>
>> Example:
>>
>> I declare an enum in the ecore file:
>> <eClassifiers xsi:type="ecore:EEnum" name="InputType">
>> <eLiterals name="text" literal="Schrift"/>
>> <eLiterals name="number" value="1" literal="Zahl"/>
>> </eClassifiers>
>>
>> In InputType.java I override the constructors to retrieve the literal
>> according to locale:
>> TEXT(0, "text", Messages.getString("InputType.0"));
>> NUMBER(0, "number", Messages.getString("InputType.1"));
>>
>> I use two message files:
>> message.properties
>> InputType.0=Text
>> InputType.1=Number
>>
>> message_de.properties
>> InputType.0=Schrift
>> InputType.1=Zahl
>>
>> With locale 'de' the generated EMF editor will show "Schrift" resp.
>> "Zahl" but also the XMIResource will save any reference to this enum
>> with the value "Schrift" or "Zahl". If I then open the XMIResource with
>> the default locale ('en') there will be an attempt to locate an enum
>> item "Zahl" where there is either "Text" or "Number". This does not seem
>> correct to me.
>> Could someone help me resolve this uncertainty?
>>
>> Thanks in advance
>> Bjoern
>>
>
|
|
|
Powered by
FUDForum. Page generated in 0.04599 seconds
Home