Community
Participate
Working Groups
If I fire up eclipse with an invalid locale, I get these message repeatedly. To the point where opening the quick access dialog took 35 seconds. !ENTRY org.eclipse.e4.core.services 4 0 2014-04-30 13:55:06.296 !MESSAGE Invalid locale format: yxx - Default Locale will be used instead.
By only logging this problem once, it's definitely sped up: http://git.eclipse.org/c/platform/eclipse.platform.runtime.git/commit/?id=5e1a97ca6be3c968643d1ec7dc9115a54c134c21 But there are still lags when the translation service is called, since it repeatedly goes through code that tries to translate the bogus locale. I'll open another bug for that.
Hi Paul, I think for the startup with a wrong locale the default locale should be put to the context. It seems the invalid locale is put to the context, which is causing the repeatedly messages. I have a new notebook and not yet setup a workspace for Eclipse platform. So I'm not sure how fast I can have a look. But the correct fix should be easy: Check the startup locale using the helper class toLocale() Put the resulting locale as string to the context instead of the invalid startup value. Hope that helps!
Hi Paul, I looked into your solution, and it looks more like a workaround than the correct solution for the issue. As I said in the previous comment, a invalid Locale shouldn't get into the context. That is the real issue. For the ILocaleChangeService I pushed a fix to Gerrit: https://git.eclipse.org/r/#/c/25831/ I'm still searching for the place where the nl startup parameter is put into the context, so there the same logic can be applied. Greez, Dirk
It is a workaround. I wanted to fix the way we deal with the locale in Bug 433895 We can only make low risk changes now. Also, org.eclipse.e4.core.services.translation.TranslationService.LOCALE looks like it's an API constant. Was it introduced in Luna? Does it make sense to turn it into a Locale? PW
It is an API constant and I agree it should be a locale. But it exists since Juno I guess. That's why I didn't change it. Isn't my fix a low risk change? It just sets the string of the converted locale instead of the given locale string. Therefore only valid locale get in the context.
(In reply to Dirk Fauth from comment #5) > > Isn't my fix a low risk change? It just sets the string of the converted > locale instead of the given locale string. Therefore only valid locale get > in the context. Oh, you're right. You didn't change the type of the constant. PW
I'm fine with the change as well
The bogus locale string is set into the context in org.eclipse.e4.ui.internal.workbench.swt.E4Application.createDefaultContext() Then it's stored in the org.eclipse.e4.core.internal.services.BundleTranslationProvider (well its superclass, org.eclipse.e4.core.services.translation.TranslationService) when that's instantiated in an injected field. Then every call to org.eclipse.e4.core.internal.services.BundleTranslationProvider.translate(String, String) calls org.eclipse.e4.core.internal.services.ResourceBundleHelper.logInvalidFormat(String, LogService) which uses the workaround to not publish the bad messages. It never goes near the code change. Opening a menu is particularly painful. PW
The ILocaleChangeService is used for locale changes at runtime. So it is also important. For the startup locale it looks like there is a invalid default Locale set, which is then set a string to the context. The correct solution should be to avoid setting a invalid default Locale via nl argument. As small change workaround in E4Application we could take the default Locale string representation, transform it into a locale again and put that string representation to the context.
After digging into this I've found out that Locale.getDefault() returns an invalid Locale, therefore everything is messed up. I added ResourceBundleHelper#toLocale(String, Locale) to allow specifying a default Locale that should be used in case of a invalid Locale String and the method without default Locale parameter is calling that method with Locale.getDefault() https://git.eclipse.org/r/#/c/26310/ I modified E4Application#createDefaultContext() to call ResourceBundleHelper#toLocale(String, Locale) by using Locale.ENGLISH. So in case of a invalid default Locale, Locale.ENGLISH will be used. https://git.eclipse.org/r/#/c/25831/ With these two changes it shouldn't be possible to set a invalid Locale into the context using default mechanisms. If users/developers are setting invalid Locales into the context using other mechanisms, IMHO it is not a framework issue.
Released as http://git.eclipse.org/c/platform/eclipse.platform.runtime.git/commit/?id=a338f49fc1dc6912b38b92b7c4916a0b3ed1d3ae and http://git.eclipse.org/c/platform/eclipse.platform.ui.git PW
Dirk uploaded a new change to avoid that a wrong local is set into the context. https://git.eclipse.org/r/#/c/26366
(In reply to Lars Vogel from comment #12) > Dirk uploaded a new change to avoid that a wrong local is set into the > context. > > https://git.eclipse.org/r/#/c/26366 Please open a new bug and move the change over to that. It can then be addressed in 4.5 PW
Created Bug 434846 and commented on Bug 433895.
In 4.4.0.I20140522-1330
