Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 321568 - [ui] Preference for automatic-update-reminder doesn't work in multilanguage-environments
Summary: [ui] Preference for automatic-update-reminder doesn't work in multilanguage-e...
Status: RESOLVED FIXED
Alias: None
Product: Equinox
Classification: Eclipse Project
Component: p2 (show other bugs)
Version: unspecified   Edit
Hardware: PC Windows 7
: P3 normal (vote)
Target Milestone: 3.7 M3   Edit
Assignee: Susan McCourt CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-08-03 05:56 EDT by Johannes Michler CLA
Modified: 2010-10-27 15:12 EDT (History)
3 users (show)

See Also:


Attachments
Proposed Patch (8.12 KB, patch)
2010-08-05 04:49 EDT, Johannes Michler CLA
susan: iplog+
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Johannes Michler CLA 2010-08-03 05:56:41 EDT
Build Identifier: 20100617-1415

I the org.eclipse.equinox.p2.ui.sdk.scheduler-plugin there are preference-options for reminding the user of updates available:
org.eclipse.equinox.p2.ui.sdk.scheduler/remindOnSchedule=
org.eclipse.equinox.p2.ui.sdk.scheduler/remindElapsedTime=

The first one is fine accepting booleans. But for the second I have to specify a value as it is defined in the following array: org.eclipse.equinox.internal.p2.ui.sdk.scheduler.AutomaticUpdatesPopup.ELAPSED

This array is filled using the values AutomaticUpdateMessages.AutomaticUpdateScheduler_30Minutes and so on. These strings are internationalized, so in an english environment I get "30 minutes", whereas in germany I'm getting "30 Minuten". But when providing setting for these Preferences using plugin_customization.ini I have to write one value for this field.

I think we shouldn't store the localized strings in the preferences but instead use the same values for all languages. To prevent that this change breaks exisiting configurations, I'd suggest to use the old english Strings as the values.

This must be done for the preference-page-initialization in the initialize() and the performDefaults()-Method:
remindElapseCombo.setText(pref.getString(PreferenceConstants.PREF_REMIND_ELAPSED));
Forthermore the performOK()-Method there should be adapted:
pref.setValue(PreferenceConstants.PREF_REMIND_ELAPSED, remindElapseCombo.getText());

Furthermore the AutomaticUpdatePopup-Class must be updated. I think this is trivial there since we'd only have to replace the initialization of the ELAPSED-Array with some not-internationalized strings.

Am I missing something? If this is approved as a bug I could quickly write a patch to fix this issue...


Reproducible: Always

Steps to Reproduce:
1) startup your eclipse-application using english locale (e.g. with -nl en)
2) setup reminder in preference-page enabled and to remind every hour
3) startup eclipse with german locale (e.g. with -nl de) (the german p2-babel must be installed)
4) the reminder is no longer set correctly and it doesn't work any longer.
Comment 1 Ian Bull CLA 2010-08-04 17:04:44 EDT
I think you're right, we shouldn't store the translated strings but rather the normalized (usually English) Strings.  Johannes, if you could create a patch, that would be greatly appreciated.
Comment 2 Johannes Michler CLA 2010-08-05 04:49:35 EDT
Created attachment 175912 [details]
Proposed Patch

I changed the preference to store the english strings and only display the international ones in the preference page and in the UpdatePopup.

I think we should deliver this to maintenance 3.6 and to Head.
Comment 3 Susan McCourt CLA 2010-09-09 18:51:24 EDT
Thanks, Johannes, for the patch.
Fixed in HEAD >20100909.

I committed the patch with the following additional changes:
- I renamed the AutomaticUpdatesPopup static variables to be more explicit:
AutomaticUpdatesPopup.ELAPSED_VALUES
AutomaticUpdatesPopup.ELAPSED_LOCALIZED_STRINGS
- I added some preference migration code to handle the case where the previously stored value is the localized string in the current locale.  In this case, the value is reset to the english value.  Without doing this, we would have lost the previously stored preference when someone ran the new code.  So, for example, if the preference had previously been stored in German, and we run the new code, we'll catch that the previously stored string is in the localized strings array and map it to the english string.  Note that we won't catch a case where the previously stored string is in a different language than the current locale, but we never handled this properly anyway.
- added your name and bug number to the contributors list in the copyright
Comment 4 Susan McCourt CLA 2010-09-14 13:46:12 EDT
retargeting milestone.
These changes were released to HEAD for M2, but never tagged for the M2 I-builds.  Since we are already into the test pass, we will defer to M3.
Comment 5 Susan McCourt CLA 2010-10-27 15:12:26 EDT
Johannes, would you have time to verify that your original problem is fixed in M3?