Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » [EMF Edit] Browser/Session dependent localization
[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/
|
|
| | |
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/
|
|
| |
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.
|
|
| | | | | | |
Goto Forum:
Current Time: Mon Sep 23 16:45:56 GMT 2024
Powered by FUDForum. Page generated in 0.04239 seconds
|