Eclipse Community Forums: EMF "Technology" (Ecore Tools, EMFatic, etc) » [EMF Edit] Browser/Session dependent localization

Help

Home

Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » [EMF Edit] Browser/Session dependent localization

Show: Today's Messages :: Show Polls :: Message Navigator

[EMF Edit] Browser/Session dependent localization [message #1693676]

Mon, 27 April 2015 12:32

Matthias Juchmes

Messages: 22
Registered: March 2015

Junior Member

Hello,

We have a model that is edited using Vaadin (ecp-vaadin). We provide localization for our edit bundles for different languages.

Because the editing is done in a browser, we need to use the same locale that is used for the rest of the UI, which is the locale of the current browser/session. However, when the ItemPropertyDescriptors are generated using ItemProviderAdapter.getString(), the locale always falls back to the server locale, meaning that we will have the wrong translation for the strings from the edit bundles, while our other localizations work fine.

We didn't find a way to provide a locale at this point.
We have set the property eclipse.registry.MultiLanguage=true, to enable basic MultiLanguage support, but what's missing seems to be a way to provide the users locale to get the correct translation. How can we solve this?

Greetings,

Matthias

[Updated on: Mon, 27 April 2015 12:59]

Report message to a moderator

Re: [EMF Edit] [message #1693800 is a reply to message #1693676]

Tue, 28 April 2015 11:52

Jonas Helming

Messages: 699
Registered: July 2009

Senior Member

Hi,

which version of EMF Forms are you using?

Best regards

Jonas

Am 27.04.2015 um 14:32 schrieb Matthias Juchmes:
> Hello,
>
> We have a model that is edited using Vaadin
> (http://eclipsesource.com/blogs/tutorials/emf-forms-renderer/#vaadin).
> We provide localization for our edit bundles for different languages.
>
> Because the editing is done in a browser, we need to use the same locale
> that is used for the rest of the UI, which is the locale of the current
> browser/session. However, when the ItemPropertyDescriptors are generated
> using ItemProviderAdapter.getString(), the locale always falls back to
> the server locale, meaning that we will have the wrong translation for
> the strings from the edit bundles, while our other localizations work fine.
>
> We didn't find a way to provide a locale at this point. We have set the
> property eclipse.registry.MultiLanguage=true, to enable basic
> MultiLanguage support, but what's missing seems to be a way to provide
> the users locale to get the correct translation. How can we solve this?
>
> Greetings,
>
> Matthias

--
Get professional Eclipse developer support:
http://eclipsesource.com/en/services/developer-support/

Report message to a moderator

Re: [EMF Edit] [message #1693804 is a reply to message #1693800]

Tue, 28 April 2015 12:17

Matthias Juchmes

Messages: 22
Registered: March 2015

Junior Member

Hi,

we are using 1.5.1.

Greetings

Matthias

Report message to a moderator

Re: [EMF Edit] [message #1693827 is a reply to message #1693804]

Tue, 28 April 2015 14:53

Matthias Juchmes

Messages: 22
Registered: March 2015

Junior Member

We also have a similar problem with float numbers in error tooltips.

Our model has a float attribute. It can be edited using a textfield that handles conversion from String to float and back. The conversion is locale aware, meaning if you have a german locale something like "1,5" is fine, "1.5" is not, other locales work accordingly.

The attribute has a minInclusive 1 extendedMetadata for validation. If I enter "0", I get the following tooltip: "Der Wert '0.0' muss größer-gleich '1.0' sein" ("The value '0.0' must be >= '1.0'") - the text is always german according to the behaviour described above (server is german), but the generated value representation is always "x.y", the output of Float.toString(). This would also be better with the browser locale, as the tooltips should represent the expected input format.

Is there any way to achieve this?

Report message to a moderator

Re: [EMF Edit] [message #1693970 is a reply to message #1693827]

Wed, 29 April 2015 16:13

Eugen Neufeld

Messages: 63
Registered: March 2012

Member

Hi Matthias,
When generating a model and the corresponding model.edit bundle with EMF, there will be a plugin.properties file in the model.edit bundle. This file is generated by EMF and contains the default texts for everything EMF generated. By providing a language specific plugin.properties like plugin_de.properties, you can easily localize your model texts.
As long as the locale you want to have for the texts of your model is the same as the one delivered by Locale.getDefault() you are done.
If you want to have a different Locale than the one provided by Locale.getDefault() as it is the case for RAP most of the time, you will need to change some code.
Besides all the ItemProviders EMF also generates an EditPlugin class. By default EMF names this class with the package-name and postfixes it with EditPlugin. So if your package name is "task" then the class will be "TaskEditPlugin".
In order to change the locale used by EMF you have to override the getPluginResourceLocator method in this class.
You can pretty much copy the code from "EMFPlugin.InternalHelper" . You only need to override the getString(String key, boolean translate) method and provide your locale there.

This way you can get localized texts for EMF, but this texts will still be static as EMF caches all those values in member variables.

In order to support dynamic locale switching EMFForms 1.6 doesn't use the EMF mechanics for reading the display name (label) and description texts from the edit bundle, but does it itself.
By using the new EMFFormsLabelProvider OSGi Service you will get an IObservableValue with with you can bind your Label to the correct text. When the locale switches, this text will be updated automatically to the new localized text.
In order to easily provide a way of customizing how the current locale is retrieved, EMFForms provides an EMFFormsLocaleProvider. However, the current Vaadin renderer does not yet support this.

For the Validation Messages goes the same as for the normal texts from EMF you can provide an own implementation of an ResourceLocator and EcoreResourceLocator. The methods must be overriden in the model bundle, there in the util package you will find a class like TaskValidator, so again the name of the package postfixed with Validator.

Cheers,
Eugen
--
Get professional Eclipse developer support:
http://eclipsesource.com/en/services/developer-support/

Report message to a moderator

Re: [EMF Edit] [message #1697796 is a reply to message #1693970]

Mon, 08 June 2015 14:11

Matthias Juchmes

Messages: 22
Registered: March 2015

Junior Member

Hi Eugen,

Thank you for your answers.

I finally got around to start updating the Vaadin renderer to EMFForms 1.6. I'm using a custom EMFFormsLocaleProvider which works fine for labels and descriptions.

However, I am not sure how I should request the label for enum literals. I looked at the EnumComboViewerSWTRenderer which uses the following way to get the display text:

@Override
	public String getText(Object element) {
		return getEMFFormsEditSupport()
			.getText(getVElement().getDomainModelReference(), getViewModelContext().getDomainModel(), element);
	}

This uses the default locale. Are there plans to change the EMFFormsEditSupport to also use the EMFFormsLocaleProvider, or is there another way to achieve this?

Greetings

Matthias

Report message to a moderator

Re: [EMF Edit] [message #1697803 is a reply to message #1697796]

Mon, 08 June 2015 14:32

Matthias Juchmes

Messages: 22
Registered: March 2015

Junior Member

Another thing that I noticed is that if there is no plugin_[...].propierties file for the locale returned by the EMFFormsLocaleProvider, the fallback is again the default locale. Instead, I would expect the messages to be taken from the default plugin.properties file, which can be different from the default locale.

Example: All thelocalization properties are in such away that the default properties file is in english, while other languages are denoted by a shortcut. The default locale is german, provided by the browser, the browser locale is italian, for which there are no properties files. That means, that in the generated UI, the messages fall back to german, while the rest of the application falls back to english. I don't know what happens if there are no properties files for the default locale, I could imagine that in this case the default properties file is used, but I did not test this.

Report message to a moderator

Re: [EMF Edit] [message #1697869 is a reply to message #1697803]

Tue, 09 June 2015 08:36

Eugen Neufeld

Messages: 174
Registered: May 2015

Senior Member

Hi Matthias,
can you please open a BugReport for the EnumComboViewerSWTRenderer ?

When loading localized properties we rely on this class: org.eclipse.osgi.service.localization.BundleLocalization.
If you look into the code there is on place where the ResourceBundle is loaded and it has a fallback to try to load the properties of the default locales first. Here is the relevant code from the org.eclipse.osgi.storage.ManifestLocalization:
ResourceBundle getResourceBundle(String localeString, boolean isDefaultLocale) {
BundleResourceBundle resourceBundle = lookupResourceBundle(localeString);
if (isDefaultLocale)
return (ResourceBundle) resourceBundle;
// need to determine if this is resource bundle is an empty stem
// if it is then the default locale should be used
if (resourceBundle == null || resourceBundle.isStemEmpty())
return (ResourceBundle) lookupResourceBundle(Locale.getDefault().toString());
return (ResourceBundle) resourceBundle;
}

EMF uses the Platform.getResourceBundle method to load the properties. This method just tries to load the properties for a specific locale and falls back to the file withe a suffix.

If all your default strings are English, then your default language should also be English. You can start your eclipse application with a specific language passing in the nl parameter. By default the run config contains this: -nl ${target.nl} just change it to -nl en

I hope this helps.

Cheers,
Eugen

--
Eugen Neufeld

Get professional Eclipse developer support:
http://eclipsesource.com/en/services/developer-support/

Report message to a moderator

Re: [EMF Edit] [message #1697989 is a reply to message #1697869]

Wed, 10 June 2015 07:18

Matthias Juchmes

Messages: 22
Registered: March 2015

Junior Member

Hi Eugen,

thanks again for your answers.
As you saw, I opened a BugReport: https://bugs.eclipse.org/bugs/show_bug.cgi?id=469705
Changing the default locale works fine.

I'm still trying to override the generated Validator and run into Problems. I create a TaskValidatorCustom to override TaskValidator, but the custom class is not used correctly in the generated code. The INSTANCE is still defined as:

public static final TaskValidator INSTANCE = new TaskValidator();

I would expect it to be something like:

public static final TaskValidator INSTANCE = new TaskValidatorCustom();

However, in other places in the code, for example in TaskPackage, the Custom class is used to access static fields:

EValidator.Registry.INSTANCE.put
			(theTaskPackage, 
			 new EValidator.Descriptor()
			 {
				 public EValidator getEValidator()
				 {
					 return TaskValidatorCustom.INSTANCE;
				 }
			 });

Is there anything I need to change so that the custom validator is used correctly?

Greetings

Matthias

Report message to a moderator

Re: [EMF Edit] [message #1697999 is a reply to message #1697989]

Wed, 10 June 2015 08:46

Eugen Neufeld

Messages: 174
Registered: May 2015

Senior Member

Hi Matthias,
thank you for creating the bug report.

In order to let EMF generate the validator you would create custom datatypes with annotations. This will let EMF generate a Validator. See ht tp://eclipsesource.com/blogs/2014/08/26/emf-validation-for-datatype-constraints/ .
So did you add the validator per hand or was it generated?

If you added it by hand, could you provide the model bundle so that I can take a look at it?

Cheers,
Eugen

--
Eugen Neufeld

Get professional Eclipse developer support:
http://eclipsesource.com/en/services/developer-support/

Report message to a moderator

Re: [EMF Edit] [message #1698046 is a reply to message #1697999]

Wed, 10 June 2015 15:31

Matthias Juchmes

Messages: 22
Registered: March 2015

Junior Member

Hi Eugen,

the TaskValidator is generated using annotations. Then, I manually implemented a TaskValidatorCustom to override getResourceLocator(), the same way you would create a TaskFactoryImplCustom to override TaskFactoryImpl. Maybe this is not the right way?

Greetings,

Matthias

Report message to a moderator

Re: [EMF Edit] [message #1698089 is a reply to message #1698046]

Thu, 11 June 2015 07:02

Eugen Neufeld

Messages: 174
Registered: May 2015

Senior Member

Hi Matthias,
I would override everything you need directly in the generated TaskValidator. In the end it is already a "custom" file as it is model specific.

Cheers,
Eugen

--
Eugen Neufeld

Get professional Eclipse developer support:
http://eclipsesource.com/en/services/developer-support/

Report message to a moderator

Re: [EMF Edit] [message #1698428 is a reply to message #1698089]

Mon, 15 June 2015 15:07

Matthias Juchmes

Messages: 22
Registered: March 2015

Junior Member

Thanks Eugen,

at the moment I'm not getting around to fix the validators, but I will try again when I can.

Concerning ECP-Vaadin, we updated to EMFForms 1.6.0 and provide an implementation for the EMFFormsLocaleProvider which returns the locale of the current vaadin UI, falling back to the default. We also use the VElement-label for the View Model localization. I think the only thing that's not working yet is the EnumComboBox-renderer, we will have to change that once the ticket is fixed.

Greetings,

Matthias

Report message to a moderator

Previous Topic:	[EMF Forms] How to programmatically access widget's properties
Next Topic:	[EMF Forms] Custom table control

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Fri Apr 19 19:33:36 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter