Community
Participate
Working Groups
The new Message extension for localization in Eclipse supports Locale changes at runtime. To have a clean overall solution, also the Application Model should support this. For as much encapsulation as possible for the necessary tasks, there should be a new service to change the Locale, and some enhancements to the application model. I have done the necessary modifications already and will contribute via Gerrit.
From Tom http://dev.eclipse.org/mhonarc/lists/e4-dev/msg08202.html First of all a big thank to Dirk for working through this rather complex topic which has been a lot of work! What makes me a bit proud is that the archtitecture we have in e4 allows to implement something like this with justifiable cost - imagine doing this Now let me elaborate bit what the changes are and how address them. I guess this should make it easier to understand the patch. a) The model changes -------------------- Until today the localization was done through EOperations (=Methods) defined in our Ecore model. We have changed that so that those are volatile, transient, derived, unchangeable EStructuralFeatures who from an API point of view are identical to the EOperations previously defined e.g. in MUILabel hence our API is not broken! The reason we change to EStructuralFeatures is that we can now send out Notifications about the changes who are then going directly through our Event-System. To mark EClasses who hold localizable informations and to inform them externally about a changed locale we introduced a new Mixin named Localizable who has a method named updateLocalization(). This allows use the generically search the model for model elements effected by a locale change and force them sending out updates. There's a very small potential that this breaks backwards compat if people have extended our Ecore in a way like this: MySpecialPart superTypes [*MySuperClass*, Part] so the generated java code will look like this: class MySpecialPartImpl extends MySuperClassImpl implements MPart { } I don't really think that we should bother with those who have extended our ecore because a similar source incompatible change was made with TrimElement - let me restate the breakage is ONLY for people who extended our Ecore (and even there those who did it in a sensible way would not be affected) b) Local change propagation --------------------------- The central point to switch the locale is ILocaleChangeService which is not implemented at the OSGi-Level but through a ContextFunction which is implemented in ui.workbench. It allows to switch the locale at the application, as well as the context level and the implemention does 2 things: - it will inform *all* model elements of an application who implement MLocalization about the change - posts an event on the event broker c) Local change consumption: ---------------------------- There are 3 ways one can get informed about a local change: - Through the event-broker by listening to the topic org/eclipse/e4/core/NLS/LOCALE_CHANGE - By using DI and make your bean get TranslationService.LOCALE injected => the new message system Dirk & me introduced does use this and you'll get an update Message-Instance injected! - Attaching to the model events listening to the LOCALIZED-Features we introduced instead of the EOperations from above => the renderers have to be modified to listen to the LOCALIZED- Features! I hope you followed along until this point but I felt you need to get some background on what Dirk did and why he did it this way. My plan is to get this in very early in the M5 cycle immediately after M4 has been declared unless someone speaks up. We have to file a CQ because of the size of the contribution. I guess I should go ahead with that once we managed to have consensus if this initial bits are ready to go in Like the split editors in the IDE world this has been the most requested feature in RCP applications I encountered in my past ~10 years of Eclipse RCP consulting. Tom
Changes: > https://git.eclipse.org/r/#/c/19743/ > https://git.eclipse.org/r/#/c/19746/
Released https://git.eclipse.org/r/#/c/19743/ as http://git.eclipse.org/c/platform/eclipse.platform.runtime.git/commit/?id=023fec35c544e5cab5aed48fdbd6281baf4c20da and updated @since http://git.eclipse.org/c/platform/eclipse.platform.runtime.git/commit/?id=e3a4a37de683c7917a8bf6cc60f6278892536d54 PW
Paul - Hudson fails for the https://git.eclipse.org/r/#/c/19746/ with very strange compiler errors. I'd really like to get this into M5 - if not everything, at least the model changes need to go in. I'm in a meeting all day but try to ping you some time in the afternoon so that we can get this fixed.
It looks like org.eclipse.e4.ui.tests needs to be updated (and run) for the model changes. PW
I've pushed the test updates as https://git.eclipse.org/r/#/c/20690/
I guess I have done something wrong because this should most likely get a new patchset at https://git.eclipse.org/r/#/c/19746/
The CQ is http://dev.eclipse.org/ipzilla/show_bug.cgi?id=7862
I'm not sure if this is still needed when we have the CLA but to make extra sure. Dirk can you: a) I've authored the code commited to the e(fx)clipse project 100% myself b) I have the right to conribute it c) I have contributed the content under the EPL
AFAIK with the signed CLA this is not necessary anymore. But to be sure a) I've authored the code committed 100% myself b) I have the right to conribute it c) I have contributed the content under the EPL
Released as http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=00ef1b00b3c680ff49720c442cbf117566d8d60b and http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=e0d7e6a9a396df1f0709de5ffd4e76617df90c03 We have an I build on Tuesday, at 08:00 EST. Can we confirm this is working they way we want after that? PW
(In reply to Paul Webster from comment #11) > Released as > http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/ > ?id=00ef1b00b3c680ff49720c442cbf117566d8d60b and > http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/ > ?id=e0d7e6a9a396df1f0709de5ffd4e76617df90c03 Dirk and Tom, thank you for this effort. It's been a long time since we've needed a CQ for a code contribution :-) PW
Now that the contributions are in, what's the state of this bug? PW
As the implementation is in the repository and the tests with the example applications are working fine, the state of this ticket is resolved. If any issues occur, there should be new tickets that point to this one.
In 4.4.0.I20140303-2000 Dirk, could you also confirm the build works the way you expect? PW
Downloaded and installed 4.4.0.I20140303-2000 Imported my projects from GitHub that are making use of the new features. Started the sample applications without any further modifications, and everything works as expected.
(In reply to Dirk Fauth from comment #16) > Downloaded and installed 4.4.0.I20140303-2000 > > Imported my projects from GitHub that are making use of the new features. > Started the sample applications without any further modifications, and > everything works as expected. Can you, for reference, at a link to the Github project?
New message extension and dynamic Locale change example: https://github.com/fipro78/e4translationexample Using class based ResourceBundles for the application model example: https://github.com/fipro78/e4classbasedtranslation
