i18n support on node import

I've tried the patch with 5.x-1.2 and 5.x-1.6 of node_import, but did not get the "I18N: Language code" field shown in any of the steps of the import process. Any ideas what might be missing, or what version would you recommend this with?

I added a few stuff:

<?php

/**
 * Implementation of hook_node_import_fields().
 */
function i18n_node_import_fields($type) {
    return array(
      'language' => t('i18n: Language for node, supply iso code'),
    );
}

/**
 * Implementation of hook_node_import_prepare().
 */
function i18n_node_import_prepare(&$node, $preview = FALSE) {
  $errors = array();
  $list= i18n_language_list();
    if (empty($node->language)){// || $node->language) {
      unset($node->language);
    }
}

/**
 * Implementation of hook_node_import_global().
 */
function i18n_node_import_global($type, $global_values) {
  $list = i18n_language_list();
  $default= i18n_default_language();
  $form = array();
    $form['language'] = array(
      '#type' => 'select',
      '#title' => t('Language'),
      '#description' => t('Select the default values you want to assign to language fields unless specifically set otherwise in the CSV file'),
      '#options' => $list,
      '#default_value' => i18n_default_language()
    );
  return $form;
}

Code in comment #3 works like a charm - thank you!

Wanting to make this patch work for Drupal 6 I had to "get dirty" and fix the patch.
I wanted it to be even stronger, to have the ability to set the tnid, so the translation will really work.
My hack for now (I hope to get some ideas and think more about it myself) is to get the tnid from the CSV and use hook_node_import_postprocess to set it properly.

It seems to work, but I hope to make it smarter...

Comments are welcome,
Shushu

Attached a separated module i18nnodeimport, which adds the language/translation into node import.

Nice patch !

However would it be possible to set a temporary tnid in the csv file, and update it when the nodes are being saved?
So you don't have to know the actual nid when you are importing content.

Maybe I should make it more clear with an example :
in a csv-file i have
language;tnid;title;body
EN;1;Some title;Some text
NL;1;Some title;Some text

But the in the table 'nodes' I already have 10 nodes (5 original nodes with translation), so tnid '1' is already in use. So in this case, when importing the nodes, the tnid '1' should be replaced by the actual tnid '11' (assuming the nid of the first row would be '11').

I'm not that much of a php-guru myself, so I don't know if it's easy to implement such a solution.

in which step you get this ? I can't find it after uploading the patch D6

Que0x, its in Step: 4 of 8, where you can define the Language for the imported items and the column for the corresponding nid, as far as i understand it right.

shushu, do you have a solution for the case mentioned by kinsai, if the nid of the original source is not defined?

Best Regards
Sandro

Not sure if this is an acceptable solution, but I've modified the i18nnodeimport.module here to handle this situation as follows:

the import CVS file has lines like:
language;TNID-IMPORT;text;
EN;0;some English text;
NL;-1;Dutch text goes here;
FR;-2;French text goes here;

the code then calculates the tnid as follows:

if TNID-IMPORT = 0 then node->tnid = node->nid
if TNID-IMPORT < 0 then node->tnid = node->nid + TNID-IMPORT
if TNID-IMPORT > 0 then node->tnid = TNID-IMPORT (so you can set it to a specific node)

The caveat here is that it assumes nodes are created in order with no node creation in between due to another process. It would be nice to have a more robust mechanism, but that's beyond my Drupal skills.

I needed this for Drupal 5, so converted #3 into a proper patch file.

Hello,

I think that the right way to do this is by:

• importing the original nodes
• download the rows with no errors adding the new nodes id (Object identifier)
• import the translations nodes by language, one language at a time using the downloaded file from previous step, changing the language

And not all nodes with their translations at the same time. This way the module can be used in a more general way.

I´m using the module posted by shushu in comment #6 with a little change inspired by the previous post #10 by hepabolu, because I was experimenting problems with the language switcher:

/**
 * Implementation of hook_node_import_postprocess().
 */
function i18nnodeimport_node_import_postprocess($type, $values, $options, $preview) {

	if (!$preview && isset($values['nid']) &&
	   ($node_type = node_import_type_is_node($type)) !== FALSE //&& 
	) {
		$node = node_load($values['nid']);
/************** CHANGE HERE ************************************/
    if ($values['tnid'] > 0) {
      $node->tnid = $values['tnid'];
    } else {
      $node->tnid = $values['nid'];
		}
/****************************************/
		node_save($node);
		watchdog('i18n import', 'New node %nid is set as translation of node %tnid', array('%nid' => $values['nid'], '%tnid' => $values['tnid']));
	} else {
		watchdog('i18n import', 'Translation is not created, %nid, %tnid', array('%nid' => $values['nid'], '%tnid' => $values['tnid']));

	}
}

Now is working fine for me. Thank you all for this work and for sharing it.

I needed a slightly different version of this than some other posters on this issue: I wanted to preserve the node language field for a content type which is not translatable, and I wanted users to be able to specify language by ISO code, name in English, native name, or name in the current language (for example, "de", "German", "Deutsch", "alemán", or "allemand"). I also preferred to use only the core locale module.

Ultimately it would be nice to import translations of a node as part of a translation workflow, which I think would best be done by allowing the module to update existing nodes (cf. #422282: Update existing nodes on import) because of course there can be only one translation into a given language for a given node, but that's well beyond the needs of my current site so I can't contribute to that effort right now. However, I hope someone finds this patch helpful.

Indeed I found the above patch very useful so I backported to rc4.

Although the #13 patch works even for rc4 it has some small hitches:

--------------------------
|--- node.inc.orig      2009-09-01 16:12:03.000000000 -0400
|+++ node.inc.lang      2009-09-01 16:27:10.000000000 -0400
--------------------------
File to patch: node.inc
patching file node.inc
Hunk #1 succeeded at 158 (offset 18 lines).
Hunk #2 succeeded at 208 (offset 18 lines).
Hunk #3 succeeded at 253 (offset 18 lines).
Hunk #4 succeeded at 351 with fuzz 1 (offset 18 lines).

Solved with the attached patch.

+1 vote for the #13 suggestion. Along the lines of the update concept and dealing with nid/tnid unknowns, it'd be nice to specify a key field to use for the translation import so you don't have to know the nid or tnid for the original node.

For instance, be able to specify a node by SKU for an Ubercart product translation import as suggested in #422282: Update existing nodes on import for update imports. Doing the same thing to reference a node to be translated would be key for non-technical staff who might be trying to import data...

EmanueleQuinto, arpieb: I'm glad this patch worked for you. Would you consider marking this RTBC?

As for dealing with importing a set of translations, I think it makes sense to wait until node_import supports updating existing nodes. Also, keep in mind that in D7 translations will not be separate nodes, thanks to getting fields in core, so those will become entirely separate issues.

No issues so far with the patch. I tested in various site and it works. So +1 to RTBC

Subscribing.

I know I'm not supposed to mark my own patch RTBC but it seems EmanueleQuinto considers it ready so I'm going to flag it.

One remark I have so far regarding the patch: the language chosen from the drop down does not seem to be remembered when switching between the different steps in the wizard with the "Previous" and "Next" buttons.

I agree that the patch in #13 it is RTBC. #20 may have a good point, but I'm not sure if other portions of Node Import do that very well either, in my experience.

subscribe

subscribe

Tried patch in #14 and it works like a charm against rc-4.
Thanx for sharing!

The remark in #13 to be able to import nodes as a translations sounds brilliant. I have a store with over a 1000 products and can import the products in the default language but then have to add translations (in 8 languages) by hand.... what a b&%#h!

Also thought of creating a custom module to link imported nodes as eachother's translations based on a cck field like SKU in uc_product for instance. But importing translations as mention in #13 might be a way cleaner method.

Is there a feature request for this already?!

Cheers

Hi can anyone tell me how to apply this patch #14??

patch #14 giving error

patching file node.inc
Hunk #1 FAILED at 158.
Hunk #2 FAILED at 199.
Hunk #3 FAILED at 209.
Hunk #4 FAILED at 293.
4 out of 4 hunks FAILED -- saving rejects to file node.inc.rej

Committed patch of #13 with following changes:

• Created separete locale.inc file (no need for if module_exists),
• Save filled in default value (comment #20),
• Added tips,
• Added error if non-existing language was entered,
• Case insensitive match of code, name or native,
• Any field with input_format = language will be handled,
• Only make field available if the content type is configured to support languages,
• Removed values_alter - can be done in check_language.

Fixed in 6.x-1.x-dev. Will be included in 6.x-1.1 release. Thanks mvc!