Synchronized fields are not synchronized when creating a translation

I'm also having this problem and it's driving me nuts. My vocabularies have the multilingual options set to "localize terms", which seems to mean that entries in term_data are only in the default language, and the trid field is always 0, with terms being localized via i18nstrings.

Tracing through i18nsync_nodeapi and i18ntaxonomy_nodeapi shows me that when creating a translation $source->taxonomy is an array of term objects indexed by tid's, the same I see when doing print_r($node->taxonomy) in node.tpl.php. This seems to failing because it's searching for translations in the term_data table: i18ntaxonomy_term_get_translations() uses the following query:

SELECT t.* FROM {term_data} t INNER JOIN {term_data} i ON t.trid = i.trid WHERE i.tid = '%s' AND t.trid != 0

Since trid is always 0, this returns no rows, and i18ntaxonomy_translate_terms() returns an empty array when called in i18nsync_taxonomyfield().

As David mentioned, subsequent edits correctly sync the taxonomy terms. It seems that in these cases (hook_api called with op = 'update') $source->taxonomy is a simple array with one element per vid (indexed by vid), with each element either just a tid, or an array of tid's in the case of vocabularies which allow multiple selections. As a result i18ntaxonomy_translate_terms() simply returns the same array (since there is no language information associated with the term) and $node->taxonomy becomes just a copy of $source->taxonomy, meaning the taxonomy terms are in fact synchronized correctly.

The problem may be that in i18nsync_nodeapi() the switch() case 'insert' includes the code run in the case 'update', but $node->tnid is always empty at this point, so i18nsync_node_translation() is never run here.

After several painful hours tracing though these modules I've come up with a patch that works around this problem for me. I still don't really understand why this code was looking for translations in the term_data table at all. Is there just a lot of legacy code in here from older versions of the i18n API, or code which refers to the core translation.module data schema which ought to be overridden? I don't get it.

Anyways, I hope this is at least useful to other people with the same problem until such time as someone who understands how this is supposed to work comes along and explains it.

Yes, it was some flawed logic, that didn't recognize it was a translation when the node was being created. Fixed it a different way, it should be working now.

Thanks for the report.