I have a node type with imagefields that are synchronized across languages.
I can translate the title and alt fields without any problem, but when I re-edit the source node (English) the values of the title and alt field are reset to their English values in the translated versions.
When I re-edit the node I do not change the imagefields.

These imagefields are multivalue fields with an unlimited number.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

tomsm’s picture

Another strange thing is that is does not happen every time.
Sometimes after re-editing the source node, the translations remain intact.

MyXelf’s picture

Version: 6.x-1.3 » 6.x-1.4

I'm having a similar issue.

I'm developing a site in four languages (es / en / fr / de). My problem is with the alt attribute of the Image field type. The behaviour of the sync process is extremely weird. After several attempts, I was not able to define a pattern to reproduce the bug. As stated by tomsm, this does not happen every time.

Usually other "random" nodes within the translation set, gets the value of the last-saved node. But it also had happened that the value of the other nodes, updates to the value of any other node within the tset (not the last-saved one) e.g. Saving the node in en, the values of the fr and de nodes updates to the value of the es node.

Please feel free to ask for any information or tests you may consider necessary. I don't have time to track this down (i18n is a very valuable module, but also a very complex one) but I would like to help solving this out.

Thanks in advance

MyXelf

PS: Moving this to version 6.x-1.4 (haven't test with the current dev version)

tomsm’s picture

Indeed, this issue also occurs with version 1.4.
I am glad that I am not the only one having this strange synchronizing behavior.

MyXelf’s picture

So, any word from someone trying to figure this out. Or at least trying to guide us to a possible solution?

Thanks in advance

MyXelf

tomsm’s picture

Version: 6.x-1.4 » 6.x-1.5

The title of the images is sometimes reset to the source title. This also happens with version 1.5.

When I open each translation before editing the source node, the translated titles remain intact.
If I do not open the translations before editing, the titles of the imagefields are often reset to the source title.

Somehow viewing all translation before editing, prevents that this title synchronization problem occurs.

PS: When I edit the source node, I never change the image or its title. I change the body or another cck field.

GiorgosK’s picture

here is how one can reproduce this error

1.
in admin/content/node-type/page
(or the content type that includes imagefield)
under multilingual options > Synchronize translations
enable at least one synch field (not the imagefield field)

2.
create node1 (source)
put alt and title as "node1" for the imagefield
save

3.
create translation node2
put alt and title as "node2" for the imagefield
save

4.
edit node1
put alt and title as "node11" for the imagefield
save

NOW
edit node2 and you will see
imagefield has alt and title as "node11"

BUT
if you edit node2 (the translation)
and change alt and title to "node22"
node1 (the source) is not affected

I traced the problem to

line 265
function i18nsync_node_translation($node, $translation, $fields, $op) {
  // Load full node, we need all data here.
  $translation = node_load($translation->nid, NULL, TRUE);

when saving the source (node1) the node_load loads the source's
imagefield (instead of the translation's - node2) in order to create the "translation"
make the synchronizations and save

Could it be that imagefield is not properly i18nlized ?

I have the feeling the the problem lies in the implementation of imagefield/
in "content_field_photos" considering "field_photos_fid " as unique which
is not in the case of translated nodes with imagefields

if this makes sense should we move this to imagefield ? for i18nization ?

deverman’s picture

We are experiencing this issue though it is hard to replicate.

sitiveni’s picture

Project: Internationalization » FileField
Version: 6.x-1.5 » 6.x-3.0-rc1
Component: Synchronization » Code

As far as i can tell, this problem is caused by the file caching. When a node with translation is modified and saved, the function field_file_load gets variable $files from the cache (via function _field_file_cache) when saving the translation.

This file already exists though in the cache from saving the original node. As the files cache checks only on fid (which is not unique when using multilanguage), the file data returned by the filefield module is the one from the originally edited node.

I've noticed that this not only happen when editing a node, but also when viewing.

I figured out that by switching the order when merging the arrays $file and $item in function filefield_field_load, the text of the cached file data is overwritten with the desired language (has already been grabbed via node_load). See PHP's array_merge for the weight of the position ("If the input arrays have the same string keys, then the later value for that key will overwrite the previous one.").

/**
 * Implementation of CCK's hook_field($op = 'load').
 */
function filefield_field_load($node, $field, &$items, $teaser, $page) {
if (empty($items)) {
    return array();
  }
  foreach ($items as $delta => $item) {
    // Despite hook_content_is_empty(), CCK still doesn't filter out
    // empty items from $op = 'load', so we need to do that ourselves.
    if (empty($item['fid']) || !($file = field_file_load($item['fid']))) {
      $items[$delta] = NULL;
    }
    else {
    	$item['data'] = unserialize($item['data']);
      // Temporary fix to unserialize data serialized multiple times.
      // See the FileField issue http://drupal.org/node/402860.
      // And the CCK issue http://drupal.org/node/407446.
      while (!empty($item['data']) && is_string($item['data'])) {
        $item['data'] = unserialize($item['data']);
      }
      $items[$delta] = array_merge($file, $item);   // instead of: $items[$delta] = array_merge($item, $file);
    }
  }
  return array($field['field_name'] => $items);
}
sitiveni’s picture

Version: 6.x-3.0-rc1 » 6.x-3.7
Status: Active » Needs review
FileSize
1.3 KB

Here's a patch for ImageField-6.x-3.7.

It includes not only the switching of the arrays in array_merge for function filefield_field_load but also for filefield_field_sanitize.

tomsm’s picture

I have applied the patch and my first tests are ok.

... so far, so good ...

deverman’s picture

We have been using it on testing and now live server for a few days and haven't had reports of the problem anymore.

gaele’s picture

Status: Needs review » Reviewed & tested by the community
tomsm’s picture

I have updated many nodes...everything is ok!

maijs’s picture

Patch in #9 just saved me another days trying to solve this problem. Works like a charm!

quicksketch’s picture

Status: Reviewed & tested by the community » Fixed

Thanks sitiveni for the patch and everyone for confirming the fix. The reason for the array_merge() being in the current order is because I wanted contributed modules to be able to override what FileField normally stores in $file['data'] array. Ironically the use-case I was thinking of was for translation of description, alt, and title text, but it looks like this approach actually prevented that from happening in the "normal" way. Considering my reason for having the arguments in the current order was purely theoretical and this patch obviously fixes some practical problems, I've committed #9. It'll be in the 3.8 version that I'll put out later this week. Thanks everyone!

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.