Closed Bug 373787 Opened 14 years ago Closed 14 years ago
Cannot select dictionary with the same name as locale
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; cs; rv:188.8.131.52) Gecko/20070219 Firefox/184.108.40.206 Build Identifier: 2.0pre (20070312) Latest TB 2.0 CZ, clean profile. Reproducible: Always Steps to Reproduce: 1. Install Czech dictionaries from https://addons.mozilla.org/firefox/3394/. 2. Try in Preferences dialog select dictionary "Čeština". 3. Close dialog. Actual Results: Selected option isn't saved. I look at where is a problem and I think that TB doesn't save preference "spellchecker.dictionary" when selected dictionary contains diacritical char.
This seems not to be related to the non ascii chars in the dic name. The dictionary pack works on the finish builds. Renaming the dic to cz.dic and changing the string cz=Čeština in the languageNames.properties makes the selection to work. Removing the cs=Čeština string from the languageNames.properties it shows cs entry in the language menu and it does not work again
Status: UNCONFIRMED → NEW
Ever confirmed: true
any errors in the JS console when you dismiss the options dialog?
Same problem in Slovak locale and slovak dictionary included into TB installer Used latest sk nightly of TB 2.0 BuildID = "2007031203"
Same problem in PL - the dictionary selector is "empty" after restart, but the selected dictionary works properly (i.e. misspelled words are underlined). PL dictionary is called "Polski" with just plain ASCII letters (no diacritics whatsoever). This is a 20070308 nightly build on Vista.
(In reply to comment #2) > any errors in the JS console when you dismiss the options dialog? No error messages.
Renaming the Polish dictionary pl.dic in PL build to cs.dic shows Czeski and it works. Using this pl.dic in CS build shows Polština and it also works. The reported working Finish/Czech dictionaries on FI build were on Linux.
Summary: Cannot select dictionary with diacritical char in its name → Cannot select dictionary with the same name as locale
When I installed this dictionary: https://addons.mozilla.org/firefox/3394/ into an en-US build, I got two entries: Czech and Cestina is that right?
I got the following error when I accepted Cestina as my dictionary and hit ok on the options dialog: *** Failed to get string cestina in bundle: chrome://global/locale/languageNames .properties
The error I was seeing was happening when we build the menu list. We end up using the name "Cestina" as the label in the menu item because we can't get a language string out of languageNames.properties: http://mxr.mozilla.org/mozilla/source/mail/components/preferences/compose.js#363 I don't think that error is causing a problem. Ok, now on to the pref not being saved. Using an en-US build, I installed the czech dictionary and re-started Thunderbird. I'll keep poking. Note: this was on an existing profile not a new one. 1) I first opened up about:config and looked up spellchecker.dictionary. It currently has a value of en-US. I left this window open so I could track changes to the pref. 2) I then went to the compose pref panel and changed the dictionary from English to Cestina and hit the ok button. 3) For me, the value of spellchecker.dictionary properly changed to Cestina in the about:config dialog I had open. 4) I tried changing to Czech and hit ok, and the change to the pref was made correctly as well.
Is the problem being reported here that the menu list doesn't load a default value? Or that there's a problem when you select a value and then hit ok, you aren't seeing that value getting written into the spellchecker.dictionary pref?
Scott, "Steps to Reproduce" which you can see above, are a bit obsolete now. If you want to reproduce this bug, you must install Czech dictionary (cs.aff and cs.dic) to build with same locale (cs at this point). So, steps to reproduce: 1) Download http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-mozilla1.8-l10n/thunderbird-2.0pre.cs.win32.zip 2) Install Czech dictionaries from https://addons.mozilla.org/firefox/3394/ 3) Try to select "Čestina" from list of dictionaries. Result: Selected dictinary isn't saved.
Or you can install sk locale with slovak dictionary included in installer. There is no selected dictionary in preferences dialog after first start (only "thin" combobox without value is shown). Now you should select installed dictionary, close dialog and reopen it - nothing is show in combo again.
This patch fixes the problem for me for locales that set a default value for spellchecker.dictionary in all-l10n.js. The menulist now selects the correct dictionary based on the default value of spellchecker.dictionary (in this case, cs) when you first open the options dialog. And if you change the dictionary, the value is saved correctly. However, this fix is incomplete. It says the spellchecker.dictionary pref is supposed to a string and not a wstring. But if I look at every other place where we access spellchecker.dictionary, we treat it as a wide string: http://mxr.mozilla.org/seamonkey/search?string=spellchecker.dictionary&luckytricky=1 We might need to fix up all the callers. Furthermore, is it possible to have a value for spellcheck.dictionary that is a wide string? It's not a wstring by default for the following locales that set it: http://mxr.mozilla.org/l10n-mozilla1.8/search?string=spellchecker.dictionary But the backend dictionary code things it's a unicode string and could give us a wstring value. Yuck.
Not sure what is the exact difference between string and wstring (is this the chrome://myext/locale/defaults.properties magic?) but it looks for me that the right way would be to fix the setComplexValue() to save correctly the string 'cs' under the cs locale.
(In reply to comment #13) Yes, if your patch is applied, it fixes the bug. Tested in SK nightly.
Actually I was a little hasty. http://www.xulplanet.com/references/elemref/ref_preference.html says that type wstring on a preference element means the pref is localized and coming from a .properties file. unichar is the right value to use for a pref element that is unicode string specified in a prefs file. This patch does two things: 1) Use unichar instead of wstring on the preference element for spellchecker.dictionary. 2) en-US builds ship with the en-US dictionary out of the box, but we don't set the dictionary by default so the first time you open the dialog, nothing is selected. We should catch up with the rest of the l10n locales that are shipping dictionaries and set spellchecker.dictionary to en-US in all-l10n.js.
Attachment #258474 - Attachment is obsolete: true
Attachment #258483 - Flags: superreview?(bienvenu) → superreview+
Comment on attachment 258483 [details] [diff] [review] the fix Axel, do you think it's ok to make this change to all-l10n.js for en-US? This forces the en-US dictionary to be selected by default for the en-US locale. This catches en-US up with other locales that use a dictionary: http://mxr.mozilla.org/l10n-mozilla1.8/search?string=spellchecker.dictionary
Attachment #258483 - Flags: review?(l10n)
Do I understand this correctly, that you want set en-US as default dictionary for sk, pl, ru, etc. locales? Why? They are shipping with own dictionaries, not with en-US.
(In reply to comment #18) > Do I understand this correctly, No you don't ;) See the patch ... /cvsroot/mozilla/mail/locales/en-US/all-l10n.js
Oups, sorry, now I know what Scott meant, thx Pawell. Filename all-l10n.js confused me a little bit :)
Comment on attachment 258483 [details] [diff] [review] the fix Is all-l10n.js loaded after all-thunderbird.js? We're unsetting that pref there, http://mxr.mozilla.org/mozilla1.8/source/mail/app/profile/all-thunderbird.js#347 Under the assumption that it works for the localizations and thus should work for en-US, r=me
Attachment #258483 - Flags: review?(l10n) → review+
Yeah, all-l10n.js gets loaded after. Fixed on the branch and the trunk. Thanks everyone.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
I don't think that it is fixed. A lot of language packs ships all-l10n.js files which defines spellchecker.dictionary but those files are not read at all at runtime. Only the %progdir%/defaults/pref/all-l10n.js is read at runtime which sets the spellchecker to en-US by default. Am I wrong?
(In reply to Ozan Caglayan from comment #23) > I don't think that it is fixed. A lot of language packs ships all-l10n.js > files which defines spellchecker.dictionary but those files are not read at > all at runtime. Only the %progdir%/defaults/pref/all-l10n.js is read at > runtime which sets the spellchecker to en-US by default. > > Am I wrong? This bug was fixed in the Thunderbird 2 timeframe, I highly doubt it wasn't fixed correctly at the time, but I suspect yours is more likely a regression somewhere.
Yes possible and I've found the culprit. The current build system puts the all-l10n.js files in defaults/pref for each language pack. When I rename the directory from pref to preferences, each language pack selects the correct spell checking dictionary (at lease in the preferences UI). And also the all-l10n.js files are excluded when generating XPI archives from language packs during build which seemed wrong to me too.
Ozan: please file a new bug with that info! This one is closed.
You need to log in before you can comment on or make changes to this bug.