release 0.7.5 and Thunderbird Google address sync

0.7.5 is a bugfix release.

Before work starts on the next release we’re inviting feedback from Gmail users on a question that often gets asked:

why doesn’t the addon sync Thunderbird postal addresses with Google?

There’s a reason why Thunderbird and Google postal addresses don’t sync.

Google Thunderbird Postal Address sync

Google and Thunderbird use different fields for postal addresses:

  • Google
  • Address
  • Thunderbird:
  • Address Line 1
  • Address Line 2
  • City
  • State
  • Zip/Postcode
  • Country

The addon doesn’t sync postal addresses because there is no reliable bi-directional mapping between Google and Thunderbird postal address fields.

Despite this impediment, here is a suggestion from a Zindus user (thanks AA) :

I would take a “compromise” approach. Map each Thunderbird field to a line within the Google Address field, prefixed by the field name. For example:

Google Address field:
[ZindusStreetLine1] Via Manzoni 12345
[ZIndusCity] Milan
[ZindusZip] 20100
[ZindusCountry] Italy

This implies that:
a) You can sync from Thunderbird to Google without losing information.
b) You can sync from Google to Thunderbird if the user collaborates in adopting the syntax above when editing Google contacts.

This should add something without losing the current freedom.

The spirit is: given that comprehensive synchronization is impossible, please give me a way to see the addresses of my Thunderbird contact list in Gmail.

I think this could satisfy the basic needs of many users. Again, better than nothing…

To summarize: Thunderbird postal addresses get synced with Google. If Google has text in the postal address field it isn’t synced - unless it is all prefixed with [Zindus*] labels.

What do people think about this proposal?

One sticking point is that if Google contacts get synced with some other device, like a mobile phone, the phone’s contacts are populated with these labels. That’s not ideal.

Another sticking point is that it doesn’t translate very well. English-language labels like [ZindusStreetLine1] make sense to an English speaker, but to give English-speakers a feel for the translation issues, let’s imagine the labels are in French:

[ZindusRueLigne1] Via Manzoni 123456
[ZIndusVille] Milan
[ZindusCodePostal] 20100
[ZindusPays] Italy

The French labels are less clear but the meaning can still be made out. But imagine what these labels would look like to an Arabic, Chinese or Japanese speaker!

We really want to keep the addon configuration simple, so any feature for the next release that supports postal address sync isn’t going to have an on/off switch. If the feature can’t apply to everyone it won’t get implemented. This stance might weaken over time if there’s enough interest in addresses but there is already a selectable option planned for a future release and we are determined to avoid complexity.

Can this idea (or something like it) be made to work for everyone? What about speakers of non-Latin languages? What about the [Zindus*] labels getting carried along via Google into other devices?

Any other ideas?

Update on 2008-05-15: the current proposal.

Tags:

If you liked this Blog, share the love :                    

26 Responses to “release 0.7.5 and Thunderbird Google address sync”

  1. Markus Says:

    If you do sync addresses with Google you’ll have to make it an option - there’s no general answer to this problem that’ll work for everyone.

    If you do make it an option - please default it to OFF.

  2. Nick C Says:

    Agree with Marcus - there’s no elegant solution to this, and Google ought perhaps to have provided more detailed address fields (I imagine they balked when they found out how many ways there are of handling addresses in different countries).

    It would indeed be nice not to loose any info, and the method above seems acceptable, but I would definitely make it optional and default it to ‘Off’.

    Finally, does anyone else think it’s strange not to provide a ‘url’ field of some sort? They are a web company after all…

  3. Jay Armstrong Says:

    Perhaps using commas to separate lines would work? I imagine that’s how Google envisions their single-line addresses, so that they can be plugged directly into a google maps search field. Using commas would be fast and language-neutral as well. As long as there’s clear instructions, I don’t think people would get confused. Zindus would have to count backwards from the state, zip code, or country to determine if there’s an address line 2, and maybe have to take a best guess at times. Alternatively, users always entered a postal code or country, then that should remove any guesswork. Either way, it’s a very acceptable solution to Google’s lack of contact fields.

    Thanks for building this. Synching with Google’s contacts is the next big thing (again).

  4. leni Says:

    @Nick: Like you said, there are a *lot* of ways of handling addresses, here’s a flavour: http://bitboost.com/ref/international-address-formats.html

    @Jay: Nice idea but I don’t think it’s a goer. With comma-separated the meaning of the field is implicit in the ordering. ie #2 == [Address Line 2]. Thunderbird 3 will change the address format and then when you want to sync with Gmail from both an old and new Thunderbird version you’re stuck. Explicit labels have the advantage of insulating the Gmail postal address content against changes in the Thunderbird format.

  5. TS Says:

    With the info above in mind, I would find the following useful:

    For each contact …
    … If Gmail has ANY address data, do nothing.
    … If Gmail has NO address data, put the Thunderbird address info into Gmail in some fashion — don’t worry about it being formatted just right if there are ambiguities

    This would allow one to enter address data in Thunderbird, and then have the address data in Gmail for times when one is away from one’s computer on which Thunderbird is installed.

  6. David L Says:

    IMHO the most straight forward method would be to just map each line in the Gmail address field to the next field in the Thunderbird address tab. So
    line1=address1
    line2-address2
    line3=city
    line4=state
    line5=zip
    line6=country
    line7=web page
    When I tried this in Gmail, the address field does maintain the extra line ending carriage returns. This method avoids the extra field prefixing and problems with extra data when syncing with other devices.

  7. Brian P Says:

    I agree with the above suggestion by David L; it is straightforward and intuitive. To handle errors, if Zindus detects some sort of anomoly in a specific address - mismatched numbers of lines, or maybe even a specific line that doesn’t match an expected format (like zip code, state or webpage) - then Zindus can alert the user and present a number of options to correct the problem.

    There is another completely separate alternative. I don’t know how much you can do with an add-on, but couldn’t you change the format of the address tab, when someone selects Google (vs. Zimbra) as the provider? Just make it identical to Google’s address format?

  8. julien23 Says:

    What about :

    THUNDERBIRD to GMAIL :
    write TH[Address Line 1 , Address Line 2 , City , State , Zip/Postcode , Country] properly into GM[Address]
    anyway conflict is resolved in favour of Thunderbird.

    GMAIL to THUNDERBIRD :
    write GM[Address] into TH[NOTE]

    ps: have a look to noksync addon
    https://addons.mozilla.org/fr/thunderbird/addon/4075

  9. julien23 Says:

    oups… all GM[Address] will end in GM[Note] if I do nothing!

    …then in my specific case (GMail priority, offline access, mémo printting & mobile sync), just map GM[Address] with TH[Note].

  10. Robert Says:

    For now, just make syncing address information a one way street. Sync addresses to Gmail but not the opposite.

  11. Gotisch Says:

    I agree with the intuitive map each line (without tags) approach. if the Google address field consists of exactly 6 lines try to synch it, if not user has to fix it :) or ignore it

  12. nygamma Says:

    This is not so much about Zindus, but about Thunderbird: why doesn’t TB support address fields without lines, i.e. like Google? Wouldn’t this be simpler for everyone? There are many different ways you can structure address information for different places, and when syncing from one application to another many fields are never correctly mapped. I think simple address fields (like the Notes field), are the best compromise, unless you have a specific reason for different line fields (tied, I suppose, to certain applications).

  13. leni Says:

    @DavidL - encoding the fields 1,2,3 makes the format brittle - there are new Thunderbird 3 address fields in planning.

    @julien23 - I don’t have a nokia phone so I couldn’t test the extension you pointed to. From browsing the source code it doesn’t look like it tackles this address-mapping issue?

    @nygamma - Thunderbird came first, Google came later, so the mismatch isn’t necessarily Thunderbird’s fault. Here is my take on the tradeoffs:

    Single fields (Google):
    - easy to capture (copy and paste)
    - easy to localize

    Differentiated fields (Thunderbird, Outlook, Yahoo):
    - fine-grain management
    - better data exchange with apps that expect differentiated fields

    Looking back over the suggestions around encoding format (including the original posting), there is a theme of trying to balance making the format both “machine readable” and “human friendly”. To the extent that these are competing purposes, I now think a sync engine has to prioritize “machine readable”. With that in mind, here is something that might be workable:

    Encode the thunderbird address as XML in the Google address field.

    Adapted from the Docbook address element.

    <address xmlns=’http://schemas.zindus.com/thunderbird/address/2008-05′>
    <street linenumber=”1″>Via Manzoni 12345</street>
    <city>Milan</city>
    <postcode>20100</postcode>
    <country>Italy</country>
    </address>

    Human-readability for English speakers isn’t great, but it’s legible to tech folks. To make it better, someone could write a greasemonkey script to twiddle Gmail’s web interface to replace the single address field with differentiated fields (when that field contains XML). Localization could be handled there too. There is already a greasemonkey API and scripts for use with Gmail.

    Assuming the feedback is positive, the plan is to roll this out as an “experimental” feature in the release after next. Enabling it will involve setting a preference in the same way that a small number of people like to twiddle the sync frequency. Eventually there might be an “advanced” button for this stuff.

    Thoughts?

  14. GmailとThunderbirdのアドレス帳を同期する | ふじゅんブログ Says:

    [...] Thunderbirdのzindusというアドオンを利用すると,Thunderbirdのアドレス帳とGmailのアドレス帳を同期すること賀できます. [...]

  15. Eric Says:

    Shoot hit return too soon!

    Why not encode in the comment field what the format used for the address field was? This works fine as long as Google isn’t the source of the info. So for standard US addresses, you might have

    1234 Main St.
    Shipping Dept.
    Anywhere, FL 123456

    and in the comment field something like this

    Work Address: %A1 %N A%2 %N %CITY, %STATE %POSTAL (%N marks the new lines)

  16. Zindus » Blog Archive » Thunderbird Google Postal Address sync - Part Two Says:

    [...] earlier blog entry on postal addresses began by noting the underlying difficulty of syncing Thunderbird and Google [...]

  17. Ivan Lujan Says:

    Hello,

    I am very interested in syncing my Live Mail account with ThunderBird. Thank you for all your tech support.

    Be Well,
    Ivan Lujan

  18. Alf Says:

    First, thanks for your work.
    I agree with DavidL and Julien23.
    I precise that Google Sync application on Blackberry smartphone use exactly this rule (one line for each field in Gmail contact postal adress).
    When I synchronize Gmail with my phone, the fields are filled correctly if I respect this simple rule exactly like describ by DavidL !
    Why does not simply to propose this option ?
    Best regards
    Alain LE FLOCH

  19. mfc Says:

    I realize this is sometime after the discussion above,
    but just had an interesting experience:

    I just exported a .csv of my contacts and imported into google contacts.
    Each address field in Tb because a new address line in the Google Contacts address field - perfect.

    I then exported a csv from Google contacts into the Outlook csv format (no Tb format provided).
    Google did an excellent job of separating the address lines into the correct Tb address fields.
    Of 467 contacts, only one v minor misplacement.

    The output fields created were:
    . Business Street might have multiple lines but correct
    . Business Street 2 unused
    . Business Street 3 unused
    . Business City correct
    . Business State correct
    . Business Postal Code correct
    . Business Country correct

    Given that there were multiple countries, with multiple address formats (US, HK, Japan, China, Aust, Sng, UK,…)
    with many missing fields, it was remarkable, suggesting either a truly remarkable algorithm,
    or Google internally keeps multiple address fields but displays as one field.

    So my base suggestion would be similar to David L’s:
    Tb -> Google: combine the Tb address lines into separate lines in the Google address field.
    Where a Tb address field is empty, create an empty line (or a line with say a “.”) in the google address field.
    Given that most people using Tb would be using it as the main address book, this is probably acceptable.

    But I would add that, given the above, it might also be possible to do the reverse.
    Google somehow do it when creating the csv.
    However I would not regard this as critical.

    I think the downsides of the [zindus] tag or xml tag approach in the top comment are too serious,
    esp having these tags appear on my android phone.

  20. mfc Says:

    spellcheck apology: 4th text line: “because” should be “became”.

  21. leni Says:

    @mfc, thanks for the feedback! Couple of comments:
    1. agree that the downsides of the xml tag approach are pretty serious
    2. as you point out, inferring semantics from position can work most of the time - 1 glitch out of 467 ain’t bad. But if every time someone had a problem, they made a request for support (because one of their contacts postal addresses got mangled), that translates to a 0.5% increase in addon support, which means that as the user-base scales, the addon becomes unsustainable. If there was a revenue model for the addon, it’d be possible to absorb an increase in support costs. But as things stand, there’s not one feature in the addon that doesn’t/shouldn’t work 100% of the time and until there’s a revenue model for the addon that’s unlikely to change.
    3. also as you point out, google has a bunch of smarts around this, and last year committed to exposing these smarts via API. They still haven’t implemented to follow through on their commitment, but neither have they withdrawn their commitment. So the plan for the addon is to use that API for postal addresses when it comes available. Follow the comments in this post to track any change in status:
    http://www.zindus.com/blog/2008/06/17/thunderbird-google-postal-address-sync-part-two

  22. mfc Says:

    Thanks very much for the response.

    1. After file comparison I found the 1 error was in fact in my input data.
    So given this and the fields created in the exported csv,
    my assumption is that google is maintaining this internally
    but just not yet exposing these fields via api.
    I certainly agree that it would be bootless to try and infer semantics
    and you should wait until google exposes the fields.

    2. One other benefit to wait for:
    when I import a .csv into google, it also keeps fields such as custom1 to custom4
    and I can see them on the webpage.
    So I would hope these might be exposed soon also so they can be synced.
    —————————–

    Testing for the last 2 days has led me to two feature requests.
    I hope this is the right place to put them - if not let me know.

    1. Same as David L’s.
    Tb -> Google: combine the separate Tb address lines into the single line in the Google address field.
    No need to sync back to Tb if a change is made in G: Tb always overwrites G
    (unless the Tb field is empty, in which case it does not overwrite G)..
    This seems easy and a no-brainer.

    Why Important:
    when you are on the road, one of the key pieces of info you need is the address of someone you are meeting.
    If you have added the address in G, it will be there.
    But if you have added the address in Tb, you suddenly find yourself stuck on the road with no address.

    2. Feedback
    ie how many records have been added / altered.

    Why Important:
    Knowing this is very important to knowing if something has gone wrong.
    While testing I discovered (by detailed inspection) almost all records got altered on 1 sync.
    Sometimes on syncs, the unexpected happens, and you need to know asap.
    One should be able to see this after it has happened.

    Maybe something in the status bar like:
    Tb: 6/3 G: 2/1
    meaning
    for Tb 6 altered 2 added, Google 2 altered, one added on last sync.

    Hope this is helpful.
    mc

  23. leni Says:

    @mfc re: your two feature requests above:
    on 1, I think it makes sense to wait until the Google postal feature goes into production then see how the two-way sync works. If it works fine then there’d be no point in a semi-one-way sync feature.
    on 2, that’s a great idea, will file a feature request for it.

  24. mfc Says:

    Leni, thanks.

    For me no one way sync is fine. But for your consideration let me make the argument why some care about it a lot. The problems is syncs are risky. No matter what you are syncing, every now and then, someting goes wrong. And the less you understand the details of what is happening, the more likely you are to have problems, and the harder it is to recover. With very large addressbooks, this can be serious. The solution for many people is simple: one-way sync. The advantage for you of course is: the less that can go wrong, the lower the support burden.

    Anyway, just something to think about. Either way it makes sense to do nothing until the interface has re-settled.

  25. vieteetly Says:

    Cialis Info Alpha Blockers Propecia Online Prescriptions Pharmacy Hydroxyzine No Rx Overnight No Prescription Bui Tenormin. Coreg How Will It Work Cialis Side Effects Eyes Drug Prozac Parkinson’s Buy Amoxicillin For Pet Minus Prescription . Does Always Viagra Doesn T Work Tramadol And Diarrhea Pain . Tuf 20 Tadalafil Erectile Dysfunction Viagra 1 Cialis Ultram Adderall Online Xanax Spoilers Anastrozole Arimidex Versus Tamoxifen Amoxicillin Interface Flagyl For Dogs Overdose

  26. pornstar savannah stern Says:

    Ηοwԁу. I ωаs contеmplating adding а baсκlіnk
    baсk to your website ѕince bоth of our sites are based around thе ѕame topic.
    Would you prefeг I lіnk to уοu using youг
    ѕite aԁdress: http://ωww.zinԁuѕ.
    com/blog/2008/04/30/гelеase-075-and-thunԁerbird-gοogle-aԁdreѕs-synс/
    or website tіtle: Zinԁus Βlοg Archivе rеlеase 0.
    7.5 and Τhundeгbirԁ Google аdԁreѕѕ sync.
    Bе surе tο let me knoω at уour earliеst conveniеnce.
    Thanκs!

Leave a Reply