User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030708 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030708 I have some notes on each contacts of my adress book in outlook 2000 The First problem is that Mozilla don't import the Notes automatically So I exported my adress book in csv format (with comma) But when importing the csv it is not readed correctly by mozilla because of comma, tab and return to line contained in the "Notes" Field. I'm was able to read correctly the same csv file with python 2.3 (module csv) and MS Excel Reproducible: Always Steps to Reproduce: 1.create more than 1 contact in outlook 2000 with comma and tab and return the description field 2.export a csv file 3.try to import it in mozilla Actual Results: doesn't work Expected Results: read correctly the csv file My group want to migrate from outlook to mozilla, so without this bug fixed, it will be hard to convince people to leave outlook...
Sorry the good value for User-Agent and Build Identifier are : User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:1.6) Gecko/20040113 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:1.6) Gecko/20040113
This has been an issue for a LONG time and is in a duplicate of 117846 I believe.
(In reply to comment #2) > This has been an issue for a LONG time and is in a duplicate of > 117846 I believe. This is still a bug. I tried to import a csv, then, thinking the commas were a problem, a TAB delimited file of about 50 address records. Lots if weird bugs occurred, including one where the data is all imported, but in some sort of corrupted way, so that viewing the contents of the address book show entries with no first and last names for records which, when you look at the detailed view,. do actually have first and last name fields data.
(In reply to comment #3) The first try to import a csv went well in so far I could see the correct column headers of the csv (which is really a ssv, a semicolon separated values file) and associate them to thunderbird data field names. Alas, there where a lot left, which were then filled up by the conversion routine with names and emailadresses of other people, instead of nothing, which would have been correct for line with only 5 or so fields. So I deleted this adress book. The next try was even worse, and the following ones tended to be like the second: the column headers of the csv weren't resolved , but all perceived as one giant, semicolons-containing "datum", i.e. "first name". So I had no chance.
Adding qawanted keyword. We need to confirm that this is still the same in the latest trunk (I made some changes to import a while ago, but I think they won't have fixed this), a testcase for this (example csv, exported from outlook). If anyone can confirm & add a testcase that would be very useful.
This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/
This bug has been automatically resolved after a period of inactivity (see above comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → EXPIRED
Could import OE Address Book correctly as well as OE exported CSV _after replacing all semicolons by commata_. Problems occur only with semicolon separated values like those created by OE when one tries to use them as they are. Possible feature in later versions: allow for choice of separation character in data sets. version 1.5 Beta 1 (20050908)
You need to log in before you can comment on or make changes to this bug.