(This bug imported from BugSplat, Netscape's internal bugsystem. It was known there as bug #333020 http://scopus.netscape.com/bugsplat/show_bug.cgi?id=333020 Imported into Bugzilla on 02/04/99 18:03) ** Observed with 10/20/98 Win32 4.5 RTM version ** After conversing with Tony Robinson and Rich Pizzaro, I thought it might be a good idea to raise this question. We have localized the dialogs in the Palm Pilot-NS AdBook synch into Japanese. Our findings indicate that local address book folder entries are exchanged correctly. Our default charset IDs for local AdBook folders would generally match that of localized Palm Pilot and this is good. Good news is that this first case would at this point constitute a huge percentage of cases. It seems, however, that off-line Directory Server folder entries will *probably* not work for 8-bit data without some conversion since our DS data will be in UTF-8. A good strategy here would be to assume that the target charset is the same as the local AdBook CSID and do UTF-8 to LocalCSID and the reverse as data are exchanged between Communicator and Palm Pilot. (Scott, please confirm that we are using the DS folder data as is when synching with Palm Pilot.) Fortunatley I think the latter case should account for a small percentage of users only at this time. Per conversation with Rich and Tony, I'm filing this as a request for enhancement in the next release. This will be a good enhancement for enterprise market where DS use is/will be most prevalent.

I think this will be part of the 5.0 effort. Scott, does this look reasonable for us to do a conversion for offlined databases? - rhp

Rich, when your APIs ask for data from the offline database, I convert the UTF-8 data into the character set of your context (in this case the context you use to create an AB_Pane). One fast solution is to make sure the win_csid for the context is say the system default (or whatever csid we need to be in synch with the palm pilot). Then any time you ask for data, I will automatically handle the conversion.... The longer term solution is to look into expanding your calls into abcom.h to require the caller to pass in a csid.

Oh, so maybe my context is just not setup correctly. I will look at the context that I use to create the AB_Pane. I think I just create a "dummy" context and use that, so the question is how I set the csid for my dummy context? - rhp

context->win_csid is the field you want to make sure is set in the context you pass to the AB_Pane on create. I'm not sure what csid we want to assume your palm pilot is in though....hmmm. Are there specs about this issue and the pilot?

I think we should assume is that the default character set for the desktop is the one we will use for the Pilot. I don't know of anything we can check in the pilot to verify what they are using. - rhp

Scott and I were looking at this problem and we have a question: - should we assume that the Pilot's character set is the system default or the Communicator Global Default? - rhp

I think the former (system default) would be better. The user won't be using this synch feature unless he/she can view the entries in the off-line UTF-8 DS folder in Japanese. People who want to view Japanese entries are generally using Japanese Windows. Likewise for Chinese, Korean, etc. I know this means that we will be slighting those people who might be using PalmSynch in Japanese but Communicator under English Windows, but that would be acceptable. In the best possible scenario, we could include an option to ask the following question: "What language is your PalmPilot in?" then set the charset accordingly based on the user input.

I'm going to arbitrarily set TFV to be M7. By then we should have some story on this from rhp. Right, Rich?

Putting Mr. Ray on this bug and taking myself off.

Sounds reasonable to me...the world is a different one from the time of this bug so this is something we have to keep on the radar screen, but when we get to the point of thinking about building this functionality, then we need to keep this on the radar screen. - rhp

Since this has to do w/MAPI, phil suggested I cc: cwhite7@uswest.net.

It turns out that under 5.0, all Address Book data - whether they are from LDAP or personal Address folders - are stored in UTF-8. This means we need to do the UTF-8 to local charset conversion for personal AdBook folder synching as well. Should we file another bug for that or should we subsume that under this one and correct the Summary line? Related question is: we need to find out if there has been or will be any change in the data charset architecture for (recent) localized versions of Palm Pilot. Does anyone have a contact at 3 Com's Palm Pilot division?

This will be a bug that I track for whoever does the hotsync work. - rhp

Palm sync and LDAP replication are both "out" for Seamonkey, so moving this to the helpwanted list.

Moving target milestone to "future" to be reviewed at a later time

QA contact to marina when/if this gets worked on.

has anything happened on this since then? (bug cleaning)

(In reply to comment #17) > has anything happened on this since then? (bug cleaning) INVALID (obsolete, per bienvenu "refers to stuff we did in 4.x")