The translation process in drupal core means:
1. duplicating a node and assigning the desired language to it
2. linking that node to the original node (tnid)

Attributes are not copied from one node to the other but the user must translate them (for some exceptions, perhaps). This also applies to the image-Attribute of the image node provided by the image module. So, what does it mean to translate a picture? ;)

Instead, the image module must be able to copy the link to the picture when translating an image node, without copying the picture itself!

By translating an image node, I want to translate the image title and the image body, but not copy the image itself!

Comments

pepe roni’s picture

pepe roni commented

This could also be an issue of the drupal core module locale, as this module is in charge of node-translation as it is implemented (or is it internationalization? I don't know!).

I would have preferred an attribute-centric translation: translate title and body attribute, but don't touch the rest of the attributes (and also dependencies). See also #329868: node translation vs attribute translation

pkej’s picture

pkej commented

I'm subscribing to this, but I was just about to turn this over to the i18n module, specifically the synchronization module, which might be the right place for this behaviour. (Edit: On further research I see that one of the developers of i18n says that node translations are done by core, and thus should go where druppi have already created an issue).

I'll link to that request, unless my search finds a previous request for the same in the issue queue of said module.

pepe roni’s picture

pepe roni commented
Status: Active » Closed (works as designed)

I found the solution for this problem: imagefield. As image seems to become deprecated, imagefield seems to become the powerful successor.

What I did so far:

  • downloaded and installed imagefield and necessary modules (see homepage),
  • created a new node type and added a new field for images
  • activated translation for this new node type
  • created new content with this new node type, added a picture and set desired language
  • translated the node and voilá, the picture is also within this new node!

There is even no additional copy of the picture in the files folder, that means, all translations share the same image source. But when you change the picture of any of the nodes, the new picture is not shared (even if you change the picture in the source node).

pkej’s picture

pkej commented

Well, one problem, does img_assist work with imagefield? I have to check out, but I have this sinking feeling. Of course I will have to test it myself.

pepe roni’s picture

pepe roni commented
Status: Closed (works as designed) » Active

Well, all the nice modules image provides, do not work with imagefield :(
I have made very good experiences with image in single language site. So I was very disappointed to find out that image is not truly multi language enabled.And I dug into the database tables image creates.

What I did:

  • Installed and activated all necessary i18n modules to translate and sync translated content.
  • configured path prefixes for each language (en/de).
  • installed image and activated all image modules.
  • created an image (en) and translated this image into (de) without uploading another image. I ignored the error message about missing image.
  • in the image table in the database i duplicated the entries with nid = 1 (my en-image) and changed the nid to 2 (my de-image)

The result: The two nodes shared the same picture!. So, in my opinion, it must be possible, to automate this. On the other hand, there is another problem:

  • as the image module does not know anything about my trick, a deletion of any node will also remove the picture from the file system as it does good housekeeping (btw. imagefield does not good housekeeping as it does never delete the images in the file system). So there is still an orphaned image node without picture

To solve this,

  • image should read it's own table (image) for other references to the file before deleting it.
  • image should expose it's image field to i18n's Synchronize translations module, so the administrator can decide how to handle images in case of translations.
  • As a first workaround I would like to know, how to setup this in the settings.php as described in the readme of Synchronize translations

I very like the image module. But if I have to manually change database tables, I will not use it!

I have read somewhere that imagefield will be the successor of image as the development of image will be suspended soon. Is that true? Imagefield is far, far away from the funtionality of image (image_assist, image_gallery and other modules supporting the image module.

pkej’s picture

pkej commented

I checked an older site I made, http://www.samipath.com. It uses i18n 5.x something, and there the images are synched between languages.

I also found http://www.prosepoint.org which has a built in tinymce editor with linking to nodes with cck image fields :) Prosepoint is built on Drupal, but with some small changes. All modules I've tried have worked perfectly with it.

That is the only wysiwyg solution for inputting cck image fields, afaik, all the others work on image module nodes.

This bug is probably filed under the wrong project, it might be the synchronize module which should do this?

pkej’s picture

pkej commented
Version: 6.x-1.0-alpha3 » 6.x-1.x-dev
Category: bug » feature

To me this is a critical bug for using this module, but I'm changing to feature request at least, then a maintainer/developer can bump it up, or to the correct project.

I also d/l the latest dev release, in the hopes of seeing if it was working there. Unfortunately not.

pkej’s picture

pkej commented
Title: How to translate a picture? ;) » i18n/image: How to translate a picture? ;) i18nsync_fields_node_image not working
Project: Image » Internationalization
Component: image.module » Experimental modules
Category: feature » bug

@#5 the conf in settings:

$conf['i18nsync_fields_node'] = array(
  'new_file' => 'New file',
  'images' => 'Images',
  'image' => 'Image',
  'thumbnail' => 'Thumbnail',
);

does work, but the synching doesn't seem to happen. I've tried most of the combinations of the four above form fields for synching, w/o success.

If you try the alternative:

$conf['i18nsync_fields_node_image'] = array(
  'new_file' => 'New file',
  'images' => 'Images',
  'image' => 'Image',
  'thumbnail' => 'Thumbnail',
);

It is spectacularly unsuccessful as it gives me errors.

I'm transferring this issue to the i18n module. The issue is:

How do you configure the settings to synch image fields? Or is this something which has to be a special case for i18n synch? (a submodule)

pkej’s picture

pkej commented

BTW, t('') is not available in the settings.php file, the README.txt for i18nsync suggests using it.

jose reyero’s picture

jose reyero commented
Category: bug » support
Status: Active » Closed (won't fix)

Try cck imagefield.

The image module is still in alpha version so this won't fix for now.

pkej’s picture

pkej commented

Tnx Jose, but there is just the tiny little factoid that neither Image Browser nor Image Assist (and a few other like minded modules) only work with Image nodes.

I've tried to ask the authors of both the aforementioned modules to add image field support, but for now to no avail.

I think both Image Browser and Image Assist are the main reasons for people sticking with Image nodes. The latter even integrates with tokens to make some pretty powerful features.

To everyone chancing upon this thread I recommend the Prosepoint install profile, those guys have an image picker integrated with TinyMCE which works with image fields. That's my main reason for using prosepoint as the starting point of current projects.

I think the IMAGE module needs to be fixed because the GUI provided by Image Browser or Image Assist is what clients want, or else people need to move to Prosepoint for the only sensible working version of an image picker working with image fields.

That is the reason why druppi and I tried out the i18nsync_fields functionality, it seems for anyone wanting GUI and image field and internationalization there are big hurdles everywhere.

jose reyero’s picture

jose reyero commented
Category: support » feature
Status: Closed (won't fix) » Postponed

I've been giving a try to the current image 6.x, and seems there's no way to hook in there, so this will have to wait for: #360643: Allow sharing image files from different modules (image translations)

jose reyero’s picture

jose reyero commented
Status: Postponed » Active

Reopening as it seems the related patch got into image module.

jose reyero’s picture

jose reyero commented
Assigned: Unassigned » jose reyero
Priority: Normal » Critical

Added some changes, committed, though it needs proper testing yet. Feedback welcomed

(still needs image -dev version)

kbahey’s picture

kbahey commented

Jose

I am trying to test this on a site that has image nodes. So I upgraded i18n and image to the latest -dev of each module.

We still get prompted by "You must upload an image". I tried adding the settings.php conf in #8, but neither did help.

What else can I do to test this and bring it to closure?

prisonbreaker82’s picture

prisonbreaker82 commented
Component: Experimental modules » Taxonomy

Is there any solution for this?

pkej’s picture

pkej commented

Since I last tried out this with image-module there has been a bit of development of imagefield compatible modules, not least some very good wysiwyg related stuff. At this time I can wholeheartedly agree with Jose's sentiment that you should use imagefield instead of image.

detsky’s picture

detsky commented

All of this is very discouraging. Everything is working well with D5. I guess I will stick to D5 forever...

jose reyero’s picture

jose reyero commented
Status: Active » Closed (won't fix)

Cleaning up the issue tracker. Closing all issues that haven't got any follow up for the last year (and are not on RTBC state). Feel free to reopen if you're willing to (really) work on this.

(And consider upgrading to D7)