Here's my situation:
I have a multi-lingual drupal6 site upgraded from drupal5. However, during the upgrade process, all translation link were lost, all contents became "language neutral".
So I need to connect them again, or I'll have to re-translate them. But there seems no such feature. Is there any solutions?

CommentFileSizeAuthor
#19 translate_existing.zip6.48 KBpkej
#17 modules.zip12.53 KBpkej
#14 translate_existing.zip6.79 KBpkej
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

GN’s picture

I guess the "Select node" option was removed from D6 in order to prevent some issues with ill-defined translation sets - see http://drupal.org/node/142280, http://drupal.org/node/287146.
Which I think is quite unfortunate.

A possible solution is manually editing the node.tnid field in the database.
('tnid' is the translation set id, which equals the node id of the source post.)
Node language is defined by the node.language field.

cpelham’s picture

You have GOT to be kidding. Everyone upgrading a multilingual site from Drupal 5 to Drupal 6 must edit their database manually, one node at a time, to reconnect translated content?! Whose bright idea was that? That's the most ridiculous upgrade path I've ever heard of. This is not a hack we're talking about bringing forward. This is a fundamental feature. Do we not want anyone to upgrade? Has anyone found a better solution?!

GN’s picture

No, fortunately it's not that bad -- when you upgrade from Drupal 5 to Drupal 6, connections between the translations should be preserved.
Manual editing of the database may be necessary if you have existing nodes that are not defined as translations of one another, and you want to connect them rather than copy content to newly created translations.

This exactly my case right now: I'm in the process of importing data from another CMS's database to Drupal 6 with node_import module, I get thousands of nodes in two languages, and I need to connect nodes in one language to their translations to the other language. I cannot do it with "select node" tool (which is not available in D6 - and even if it was, it would require long hours of tedious labor). So, I'm writing sql scripts that match the values in the tnid field according to some criteria.

GN’s picture

Fortunately it's not that bad -- when you upgrade from Drupal 5 to Drupal 6 and it goes as intended (which I'm afraid may not always be the case, as there are lots of modules besides i18n that may cause more or less serious problems with D5->D6 upgrade), I believe the language of each node and connections between the translations should be preserved.
Manual editing of the database may be necessary if you have existing nodes that are not defined as translations of one another, and you want to connect them rather than copy content to newly created translations.

This exactly my case right now: I'm in the process of importing data from another CMS's database to Drupal 6 with node_import module, I get thousands of nodes in two languages, and I need to connect nodes in one language to their translations to the other language. I cannot do it with "select node" tool (which is not available in D6 - and even if it was, it would require long hours of tedious labor). So, I'm writing sql scripts that match the values in the tnid field according to some criteria.

Jose Reyero’s picture

Title: How can I choose an existing node as a translation? » Choose an existing node as a translation
Version: 6.x-1.0-beta3 » 6.x-1.x-dev
Category: support » feature

Yes, I'm afraid this one was lost when replacing Drupal 5 i18n translation module by Drupal 6 core translation module.

So for the to-do list. if someone wants to port the code, patch is welcomed.

Manuel Garcia’s picture

Ah, finally found some information on this... was going insane here.

It is indeed a pity this feature was lost in the move towards D6... then again, so many changes i can only imagine how many headaches the devs must've gotten. I second the feature request here, this is a functionality which is even critical in multilingual sites. Specially new users who don't understand the system yet, they may create nodes not as translations and end up having to re-do them again.

In the case of webforms it's specially critical to be able to assign different webforms as translations of each other.

So I hope someone will take up the challenge!

p.s. for the time being i will manually edit our db for the few nodes we have disconnected. Thanks GN for the info on how to go about doing that :)

cpelham’s picture

I found that I didn't have to edit the database directly. What I did have to do was edit each node's path alias and remove, in my case, en/ or ja/, as this is now automagically provided. After doing that if I load, for example, site/drupal/users (which under Drupal 5 had the path site/drupal/en/users), that node loads, and then if I click our Japanese flag to switch to Japanese, Drupal will find the Japanese translation (which has the same path alias site/drupal/users and which under Drupal 5 had the path sites/drupal/ja/users). It just works.

Manuel Garcia’s picture

For the record, editing the database as suggested worked great in our case (not that many to edit).

Basicaly you have to set node.tnid as follows:

1. Go to the node table.
2. For the Source node set its tnid to its own nid.
3. For all the other translations, set their tnid to the source nid.

Thats it, should work fine.

tiago.gmarques’s picture

I subscribe #6.

This is indeed a very useful feature.

pkej’s picture

How should such an interface be? In its simplest form it is one text field for each language, + one drop down.

The text fields lets you insert the IDs of the existing nodes, and the drop down to define which language is the original.

A more advanced one would let you pop up a view to select a node for each text field.

For me that would be enough, and also probably a managable system.

And from this thread it seems that all which is needed is updating the rows in the node table something like

('UPDATE {node} SET tnid=%d, language=%s WHERE nid=%d', $original_nid, $this_nodes_language, $this_nodes_nid);

This suggested module would have just an admin interface, and seems to be only for users well versed in drupal. There is a status field "translate" in the node table as well, which complicates the process, as I don't know exactly what it is supposed to do.

Next step would be to try to intergrate it with the translate tab on nodes.

Anyone have input on this? I think I could manage to make something like this, I need it myself, but I'm also very overworked at the moment.

Manuel Garcia’s picture

Thanks pkej for taking the initiative!

I think it should be integrated in the translate tab from the begining.

Perhaps just adding a link to 'Choose existing translation' next to 'Add translation', which would take you to a page with the list of nodes existing in that language which haven't been assigned as a translation for another node already. Then the user would just have to choose one and hit submit.

I think this way we wouldn't clutter the translate tab page also.

Jose Reyero’s picture

Hi, just some tips for anyone willing to work on a patch

- The translation tab is now entirely provided by i18n so we can add any code there.
- The kind of code we need for the autocomplete can be found in CCK's nodereference module

I would be great if we can replace the node titles (on the translation tab) by autocomplete fields so they can be edited right there.

pkej’s picture

Well, my reasons for making it just an admin page first is:

1. It is faster, nobody has to wait longer than neccessary for the most basic functionality.
2. I hardly know how to make an admin page, much less how to modify forms which are already there ;)

You are thinking exactly along the same lines as me when it comes to the translation tab, just another link on the page to assign a translation. I just don't know how to do that (yet), I'm sure there is a hook somewhere to achieve this.

I will also have to look at views to see how one can use the translation set functionality to filter out nodes which are part of a translation set already. My first naïve thought was to create a view where you can select the language you're searching for a node. Again for simplicity, but if one is inside the form and know the language being looked for, then the javascript calling the view can add the language code as an argument to the view.

Sheesh, I haven't even made a working javascript in my life, but it is just a language, I'm sure it can be grokked, even by me.

Don't expect too much in the first iteration, it is better to have a few simple working functions than a scaffolding for something that is never completed. I usually end up with the latter.

pkej’s picture

FileSize
6.79 KB

I've been working on this, and it will be as #11 wished, but with a completly different tab. The translation tab is controlled by the core module translation and I don't know how to change it.

I agree with Jose in #12, using an autocomplete inline would be neat, but I don't know how to code that yet. I'm almost finished with my WTM (works through magic (and stealing)) version of my code. I just need to be able to understand wild card replacement in menu items.

For now I get up a new tab on the node page, a new action ('find node'), which takes the user to a filtered page (filter is broken, code stolen from node module), which has replaced the "edit" action with 'use as translation', which takes you to a confirmation page, which is were I'm stuck.

First iteration provided here, so you can all gloat at how ugly it all is ;) No comments, no support.

pkej’s picture

As you can see from the code I have ended up with problems trying to do the callback for my menu item 'node/%node/translate_existing/%/%/confirm'. Any tips would be apprecieated. I'm off to read code from other modules until I find someone doing exactly what I'm doing and pass the data as arguments.

That part should do a callback to translate_existing_node_confirm( $tnid, $nid, $language) (which it does), and inside there the two missing sql queries should be:

// ('UPDATE {node} SET tnid=%d, language=%s WHERE nid=%d', $tnid, $language, $nid);
// ('UPDATE {node} SET tnid=%d WHERE nid=%d', $tnid, $tnid);

Next step is trying to integrate a autocomplete field at 'node/%node/translate_existing' and finally get rid of 'node/%node/translate_existing' and integrate the code into 'node/%node/translate, somehow...

pkej’s picture

DOH, the arg() function gives me the arguments inside the callback. I think I will have something working soon. Need to add some fault tolerance first. If someone can find out why the filter isn't working, I would be grateful.

Furtermore, perhaps using hook_menu_alter could let me overwrite the existing translate tab? It works, but it won't let me use the exact same path again. Looking good though.

pkej’s picture

Status: Active » Needs work
FileSize
12.53 KB

A working like crap, needs testing, version:

I need to find out how to send error messages, how to go via a confirmation page, and how to get the filters to work.

You will know that a translation has been connected wthen you see "here we need to ask for confirmation".

It works on my little test site.

All hands are welcome with updates and patches.

Next step is to learn how to add autocomplete fields to get rid of a lot of stuff.

QUESTION:

1. Should a translation be of the exact same node type as the original? (I think so.)

pkej’s picture

I'll test it on a backup of a live site I have where a lot of translations got lost.

pkej’s picture

FileSize
6.48 KB

Added some sanity checks and error messages. I still don't know how to redirect out of function translate_existing_node_confirm. No more updates from me today. This is what I managed to do in between the breaking news today.

pkej’s picture

OK, when I did the original work on this "module" I copied a lot of code from existing modules. Unfortunately that makes the whole thing britle. Also, if I used an autocomplete field in there, I could probably make a callback which a) returns only untranslated nodes and nodes of the language you are translating to and b) removes a lot of code which I barely understand how is working (mostly because of laziness).

Unfortunately I am not that good with ajax, it is a weakness I need to address.

I guess I need a menu for the callback of the autocomplete, that menu needs to serialize the return values from my query. Any input would be appreciated.

shushu’s picture

This feature, and in addition an ability to set translations via node_import module, is very critical for a site I create nowadays.
pkej - I tried to work with the last zip you uploaded on Drupal 6.9, but except then seeing the "add translation|find nodes", and being able to select a translation node from the list, it didn't actually work...
Do you have a different/working version ?
Do you plan to make a "real" module out of it ?

pkej’s picture

I haven't done any proper work on this. I should look into how to do it with a nodereference field. One of the uploads I did earlier actually did the sql call, but didn't return you to the proper place afterwards.

This really needs some love, I agree. Personally I use Sequel Pro to connect to my databases to update the translations.

I'm really not that well versed in Drupal, I couldn't get the filter in the copied code to work ;)

shushu’s picture

Since my main need for it is related to node import, I implemented this on another way.
You might be interested in it.
http://drupal.org/node/267555#comment-1316200

EgbertB’s picture

Hi GN,

Could you show me an example of the sql script mentioned in #3.
I'm importing a huge non normalized external database into drupal 6 cck types, but trying to define the translation sets messes the whole site up, so I must be doing something wrong.

Egbert

Vacilando’s picture

Subscribing. I am also stuck with nodes of different languages that need re-connecting. An 'add existing translation' feature would be lovely, thanks for working so hard on this.

Jose Reyero’s picture

Status: Needs work » Fixed

Done.

And a new permission to use it 'administer translations'.

momper’s picture

hello

is it in the actual .dev or what means "done"? this would be great ...

thanks momper

mediamash’s picture

check node/[NID]/translate for overview
hurray for jose!

mianwo’s picture

This post was almost a year ago...

My recent experience shows that upgrading from multi-lingual drupal 5 site to drupal 6 have no problem at all. Translations are still there.

Status: Fixed » Closed (fixed)

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

momper’s picture

so it's a normal functionality now to choose an existing node as a translation like in 5?
beside import or upgrade stuff?

thanks momper

momper’s picture

is there any progress or should i open a new issue?

Manuel Garcia’s picture

This is already fixed in i18n module. The functionality is there, when you create a translation, you get to choose an already existing node if you so wish.

ericclaeren’s picture

I have that option in the node translation page, but it does not show any results.
- Oops, found out I made a mistake :) -

drurian’s picture

I don't see this option. Is there some special setting for that?

radiobuzzer’s picture

Version: 6.x-1.x-dev » 7.x-1.7
Status: Closed (fixed) » Active
Jose Reyero’s picture

Status: Active » Closed (fixed)

Please provide some explanation if you want to reopen an old issue like this.

kingandy’s picture

This feature seems to have fallen off the D7 version?

radiobuzzer’s picture

Status: Closed (fixed) » Active

This feature has fallen off the D7 version

Jose Reyero’s picture

Status: Active » Closed (cannot reproduce)

Nope, it is still there.

Thought it may be some other module replacing the node 'Translation' tab (ET, etc..)

richardp’s picture

Title: Choose an existing node as a translation » SOLVED: Choose an existing node as a translation
Issue summary: View changes

*** SOLUTION ***

For those that might have missed it or gotten confused by all the comments, in D7, you need to enable the "Multilingual Content" module, included with i18n module. When you do, you will see a new form on the node's "translate" tab. Here you can set existing nodes to translations.

pixelpreview@gmail.com’s picture

please explain ... I have the module actived and I don't have a form to link another node to a translation of the node that I edit ? Do I have missed something ?

pixelpreview@gmail.com’s picture

Status: Closed (cannot reproduce) » Needs review
portulaca’s picture

I have the module "Translation overview" enabled which changed the form on the Translate tab, it removed the part where you can enter info about the existing but unconnected translated node. After I disabled that module the form parts reappeared.

Work is being done on the "Translation overview" to resolve the conflict of overriding the form on the Translate tab: No way to assign existing nodes as translations with i18n_node

elegance46’s picture

#44
portulaca

Thanks a lot!