There’s a special edition DVD of Monty Python and the Holy Grail that has a clip from the movie first dubbed into Japanese, and then subtitled with an English translation of the Japanese dubbed dialogue: not surprisingly, the English subtitles don’t quite match the original English dialogue. The result is hilarious.
During a sync, when structured information (see Syncing structured information) moves from one program to another similar-but-not-quite-identical program, the same kind of thing can happen: contact info may come back missing pieces, or with items mislabeled, or calendar events may be set for a different time zone. However, hilarity (usually) doesn’t ensue—not, at least, if it’s your data.
Address Book and iCal are the programs most prone to this problem, and for at least one good reason: iSync is all about exchanging Address Book contacts and iCal calendars with handheld devices and each of the many dozens of different handheld devices that iSync syncs with has its own phone book and calendar function, each with its own ways of storing and labeling contact and calendar information.
But it’s not just iSync alone that can lose things in translation: now that Tiger has made it possible for other applications to use the sync engine, your data can just as easily experience lost-in-translation issues when syncing between two different programs on your Mac (see Entourage calendar syncing quirks for an example).
Although you can’t always completely avoid this annoyance, you can develop strategies to work around it. At the very least, you can figure out what kinds of information get lost or changed and avoid surprises.
The following sections use contact managers and calendar programs as examples because you’re most likely to encounter the problem when using them, but the strategies I describe should be applicable to most other programs that might lose things in translation.
Tiger’s sync engine allows software that syncs to use and to provide schemas that describe the shape, if you will, of structured information that applications sync. The truth database (see Apple’s Syncing Model) contains each application’s information exactly as the schema describes it. An application pulling information from the truth database that a different application has put there must figure out from the schema how to handle the information that the truth database provides—how to change the shape of that information into something it can store.
Here are the things that applications tend to do when dealing with information of a different shape:
Sync equivalent information: For example, nearly all calendar programs can handle events that have a date and a starting time, so that data usually survives a sync between different devices and programs unmodified. Similarly, most contact managers have no problem syncing the basic items that all contact managers handle, like names, street addresses, and telephone numbers.
Translate losslessly: This happens when the programs involved represent the same data in conceptually different ways, but the sync process can translate between the differing representations without any loss of information. For example, one contact manager might store a phone number’s area code as a separate item, and another might store it as part of the number surrounded by parentheses: a bit of text manipulation can convert one into the other.
Take the “lowest common denominator” approach: When one calendar program can’t quite represent a calendar item from another program, that item may be converted to a form that less exactly, but still adequately, represents the information. My phone calendar, for instance, can’t handle iCal’s all-day events: iSync converts such events on my phone calendar into read-only appointments that last from 12 AM to 11:59 PM. Similarly, a hand-held device’s contact manager may have to truncate a long contact name from Address Book to fit into the more limited space that the device’s software allows for contact names.
Ignore the information: When all else fails, the application punts. iCal does not support event categories like Entourage does, for example, so Entourage events simply don’t display category information when you see them in iCal. Such ignored information, however, need not be stripped off by the syncing process: you can change the date or time of an Entourage-created event in iCal, and when you sync again, the event in Entourage has the new date or time you assigned to it in iCal but retains the category you had previously assigned to it in Entourage.
How do you find out what will happen to your calendar and contact information when you sync it between various programs? Unfortunately, the unsatisfying answer is trial and error: you have to try syncing and see what happens.
You can throw caution to the wind and just sync with all your actual information to see which items survived unscathed and which ones suffered a sea change. But if you care about your information you can take a more cautious and scientific approach. I tend to favor the cautious and scientific approach, myself.
Back up first!
On those rare occasions when I do throw caution to the wind, I first make backups.
iCal makes backing up calendar info easy: choose File > Backup Database to save your iCal calendars’ contents in a backup file. Later, after you finish the experiment, you can choose File > Revert to Database Backup and restore your calendars from your saved backup.
Address Book offers File > Backup Address Book and File > Revert to Address Book Backup to protect your valuable contact info while you monkey around.
The scientific approach means testing a sync under controlled circumstances to see what happens when information travels from one program to another, such as contacts coming from Entourage into Address Book, and what happens when the information travels the other way.
When I do this kind of experimenting, I usually create a new, temporary, user account on my Mac and sync some sample information; see Create a new account. I usually give this account an obvious name, like Test Account. For example I might use iCal running in my Test Account to see what happens when I move events to the calendar function of a mobile phone that I’m testing. That way, I don’t risk polluting either iCal or the other phone’s software with more than a small, controlled sample of easily deleted information.
Tip
When testing syncs, make sure you don’t inadvertently mess up other information—be sure to turn off syncing for other information types:
If, for instance, if you’re testing calendar syncs with a handheld device, turn off contact syncing before you run your experiments. In iSync, the device’s configuration pane controls this (see Sync a Handheld Device with iSync).
With .Mac syncing, turn off all syncing but the syncing that you’re testing.
If you use a separate user account for your tests like I do, don’t forget to turn off .Mac syncing completely in your regular account. Yes, that’s right: although the .Mac Preferences are found in System Preferences, the settings in its Sync tab are not system-wide settings, but apply to each user account individually.
Let’s take a brief look at how I might put iCal and Address Book through a few short tests.
To test information coming into iCal, I start with an empty version of iCal in my Test Account. If I’m starting with a new device or calendar program, I’ll use it to create sample calendar information that matches the kind of calendar information I normally use: for example, a few one-time events, some recurring events, and a couple of all-day events. Next, I’ll do a sync and compare what iCal shows with what appears in the other calendar software that I’m testing.
To test data coming out of iCal, I again start with an empty iCal. In iCal, I create a few samples of the kinds of real events I actually use. I also create some to do items like the ones I normally use. Then I sync with the software or device I’m testing and compare.
This two-way testing doesn’t catch all possible issues that might later arise, but it does tend to catch the ones that will affect me most.
To test information coming into Address Book, I start with an empty version of Address Book in my Test Account. If I’m starting with a new device or contact program, I’ll use it to create sample contacts information that match the ones I normally have: for example, some personal friends, some business contacts, a store, a restaurant, and the like. Next, I’ll perform a sync and compare what Address Book contains with what I originally entered in the program I’m testing.
To test information coming out of Address Book, I again start with an empty Address Book, and then I create a few samples of the kinds of real contacts I normally record. Then I sync and compare what’s in Address Book with what’s in the program or device I’m testing.
As with the iCal testing strategy, the testing doesn’t catch all translation problems, but does catch the ones that would likely happen to my contacts.
So what do you do after you’ve tested your syncs and discovered problem areas? The answer is similar to the old vaudeville joke: “Doctor, it hurts when I do that!” “So don’t do that!” You have some choices to make:
Avoid using the contact and calendar features that cause problems. As the vaudeville doctor understands, you won’t feel the pain if you don’t do the thing that causes the pain.
Look for alternative ways of accomplishing the same purpose. For example, if your device doesn’t have a Nickname field like Address Book does, but it does have a Notes field, you may decide that putting the contact’s nickname in the Notes field will suit your needs.
Live with the problem. This isn’t as pessimistic as it sounds: in most cases, info gets dropped or changed in only one direction—such as from Address Book to a mobile phone, or from Entourage to iCal. If, for example, you lose nicknames when you sync from Address Book to your phone, you’ll still have the nicknames in Address Book: you’ll only lose a nickname if you change it on your phone and then sync back. In such cases, you may wish to simply modify your behavior to fit the problem.