Closed Bug 33980 Opened 20 years ago Closed 20 years ago
'Collected Addresses' being corrupted when saved to prefs
0. Using NT4 JA & the JA 0330 seamonkey build 1. Launch Seamonkey, create a new profile, and open the address book. 2. Relaunch Seamonkey, using the same profile. 3. Open the address book component. Notice that the JA 'Collected Addresses' string has been corrupted. 4. Compare the value of the 'Collected Addresses' variable "ldap_2.servers.history.description" as defined in defaults/pref/all.js and how it now appears in users50/<profilename>/prefs.js. They're different. My 2c theory is that the wrong charset is being used when saving out the variable to prefs.js
Adding bobj to the cclist.
This should go to hangas. Non-ascii names of address book folders need to be saved into UTF-8 as required by prefs.js. THe Personal Address Book and other newly created Adress Books seem to be OK. QA contact to marina.
Assignee: ftang → hangas
Product: Browser → MailNews
QA Contact: teruko → marina
Candice can you take a look at this?
Assignee: hangas → chuang
Marking M16 (not M15 stopper)
Target Milestone: --- → M16
Not M16 stopper, marking M17.
Target Milestone: M16 → M17
nominating for beta2
Putting on [nsbeta2+] radar.
Please re-verify this bug. "Collected Addresses" and "Personal Address Book" are saved in mailnews.js as default value, not in all.js. If "Personal Address Book" works, "Collected Addresses" should work too.
re-assigned QA contact to momoi, thanks, Kat.
QA Contact: marina → momoi
In PR1, we localized these names in mailnews.js into Japanese. Yes, 'Personal Address Book" and "Collected Addresses" were in mailnews.js. And yes, only the translation for "Collected Addresses" wwas displayed wrong in PR1. Currently, there is a plan to move these localizable items from the "defaults" directory (pref files) to more localization-friendly area. At this point, localizing these items have no effect -- they show as English instead. This could be another bug but let's wait until Tao moves these into L10n area and check again. My guess is that the original problem might have something to do with not being able to deal with specific characters involved. We have seen something similar with other CJK characters when some layout tags like <DIV ..> was used in .xul files. Let's keep this bug under observation and when Tao completes his work, we will visit the issue. Tao, please publish the info on where you have moved pref items.
Does the feature still work? If autocomplete still works against the collected addresses and addresses still get put into the collected addresses then I think this can wait until beta3.
The feature still works, but that is not the point. If you go by that criteria, no menus need to be localized as long as the feature represented by the menus work. That clearly is not the criteria we should be using. We need to have all strings to be localizable. The Collected Address Book is one of the neatest features touted in both PR1 and PR2. The name has to be localizable for it to make sense in other languages. The pref location move apparently will not occur for this item and the dependency on Bug 39790 is not there. Here's the ipdated status of this bug as of 7/3/2000. The current problem seems to be slightly different from what was reported in PR1 for this bug. With the 7/3 build, I cannot localize either "Personal Address Book" nor " Collected Address Book" in the build. They simply show up in English and stay in English. So as Candace predicted in her 6/1 comment, neither of these 2 Address Book names are localizable. I'm raising the severity to critical since these 2 items need to be localizable for PR2.
Severity: major → critical
Candice, Alec mentioned today that there's a GetLocalizedPref function that can be used to point to a properties file that will contain the localized version of the pref.
*** Bug 34090 has been marked as a duplicate of this bug. ***
The criteria that we have been using for this class of bugs is that if they are high profile problems (e.g. appearing in top-level app windows like Nav, Mail, or IM) then they're beta 2 stoppers. I don't believe that this fits that criteria. Clearing nsbeta2+ for reconsideration.
Well, this partiular feature, i.e. Collected Addresses, has been written about in magazine articles and journals in Japan. I don't think it is a good idea to leave this untranslated for Beta 2. There needs to be a bit more fine-grained criteria as to what items can be left out of translation than just a blanket criterion like "top-level" items. This is a highly visible item in the Address Book and it needs to be translated.
this is SO easy to fix. I estimate roughtly 3 lines of code will change per string - one line in mailnews.js, one line in addressbook.properties, and one line in the address book JS file. Instead of debating about it, let's just fix it.
I backed off on my desire to cut this bug when Kat wrote that the Personal Address Book didn't show up either. If it's as easy to fix as Alec suggests, then it would be worth taking this fix to make our two default AB's viewable in other languages.
Putting on [nsbeta2+] radar for beta2 fix.
Alec, please post the patch. I understand the first two fixes in the mailnews.js and properties file, but not the one for address book js file. Thanks.
I don't have a patch. all you have to do is change prefs.CopyCharPref() to prefs.getLocalizedPref()
The function should be getLocalizedUnicharPref(), not getLocalizedPref(). Since address book gets all address books description in one C++ function. I need to investigate more to make sure it gets the default names and the user defined names correctly.
Tao has used it all over the tree: http://lxr.mozilla.org/seamonkey/search?string=getlocalizedunicharpref I made it so that it handles defaults as expected, and allows you to override the default by using SetUnicharPref().. it should just be a search-and-replace.
Fix checked in. "Personal Address Book"(pref "ldap_2.servers.pab.description") and "Collected Addresses" (pref "ldap_2.servers.history.description") are in addressbook.properties now.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
** Checked with 8/1/2000 Win32 build with a JPN lang pack ** Following the steps described by the original poster of this bug, it is no longer possible to re-create this problem. Marking it verified as fixed.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.