How can the created nodes be assigned their correct language? (and other "core" fields...)

This is in the works: #632920: Inherit properties from parent feed node (taxonomy, author, OG, language)

it still doesnt work, with csv files.

I had the same issue. I solved it hacking the module as follows:

plugins/FeedsNodeProcessor.inc

getMappingTargets() : add language field to the $targets array

      'language' => array(
        'name' => t('Language'),
        'description' => t('The language of the node.'),
      ),

setTargetElement() : add reference to language field

// change this line
//elseif (in_array($target_element, array('title', 'status', 'created', 'nid', 'uid'))) {
// into
elseif (in_array($target_element, array('title', 'status', 'created', 'nid', 'uid', 'language'))) {

Actually, I don't understand why the module doesn't provide access to all fields of the node table by default. It has mappers for 'title', 'status', 'created', 'nid', 'uid', but I think this should be extended to the following too: 'changed', 'comment', 'promote', 'sticky', 'tnid', 'translate'.

What do you think? Should I provide a patch?

Changing attributes : this is a feature request and code issue.

Here is a patch allowing you to map feed items to following node parameters : language, comment, promote, sticky, tnid, translate.

Tested and working fine on my install (6.x). Could be ported to 7.x branch without any problem, I guess.

Looks like I forgot the language parameter in previous patch... X-D
Here is the complete version.

patch #6: should we add a module_exists() check if the i18n and/or comment module is enabled? Then we only provide these targets if available.

Good question actually. I think that would make sense indeed if these fields were depending on these modules, but comment, language, tnid and translate fields are provided by the node module, not i18n nor comment. I don't have good examples in mind, but I'm thinking maybe someone would like to alter the values of these fields without having i18n or comment activated?

You're right. I wasn't aware of that these fields are in the node table in every install. In that case it is an user experience request to hide these options. We also check in FeedsNodeProcessor.inc if the node type has a body field ( if ($type->has_body) {)
So, consequently we could check for these options as well.

Further I propose

+ 'name' => t('Language'),
+ 'description' => t('The language of the node.'),

to

+ 'name' => t('Language'),
+ 'description' => t('The two-digit language code of the node.'),

Allright. Here is the updated patch :

• comment will show up if Comment module is activated,
• language will show up if Locale module is activated,
• tnid and translate will show up if Translation module is activated.

Nice.

- language should work (there is a mapper defined in mappers/locale.inc)
- To stay consistent with the implementation of other mappers, comment, tnid and translate should be broken out into a mappers include file using the mapping API just like mappers/locale.inc.

Indeed the language works as designed. While having a closer look to mappers/locale.inc, I've found out that I couldn't see the "Language" target because multilingual support was not activated for my content type. Arg :-/

Thanks for pointing out the right direction. Here is a new patch creating two mappers include files (comment.inc, translation.inc).

(not sure, but maybe I should have filled a separate issue?)

Ouch, forgot "promote" and "sticky" in previous patch... :-|

This one provides :

• promote and sticky support (plugins/FeedsNodeProcessor.inc),
• comment support (mappers/comment.inc),
• tnid and translate support (mappers/translation.inc).

Not sure where to place this meta-concern.

I see there has been a massive effort to move architecture towards "inherit from the feed node" philosophy, but could an alternative be to inherit from a "template" node (of the same type as the destination nodes that will be created) instead of the feed node?

This seems better to me because:

• we could automatically handle many more cases that are non-core (like, workflow state of a node, default values for CCK fields, etc.) if an option could be to just "copy over" the entire $node object before mapping stuff into it.
• adding taxonomy and other values like OG group audience, language, etc. to the actual feed might not be desirable (because it could then show up in OGs, taxonomy/term/XX listings, etc.)
• we can do revisions, node access, etc. for the template node, which is cool =)

Thoughts welcome.

Didn't get a chance to test it out but looks good. A couple of things:

• FeedsImportBatch::feedNode is deprecated, use node_load($batch->feed_nid) instead.
• Should probably have tests.

subscribing

subscr

subscribing

I'm wondering, do this patch makes it possible to create a node with it's translation node of a multilingual feed..?

subscribing

subscribing

Subscribing, and marking #1041634: Include additional node properties (format, promote, sticky...) as targets in FeedsNodeProcessor as dupe.

If we are already adding support for these other core fields, can we also include format (selection of input format)?

Here is a patch for adding Input Format as a target, as well as allowing it to be inherited from the Feed Node. It does not include a mapper for mapping english input format names to numeric values. I wasn't sure if this should be its own issue or not. If so, please let me know.

Subscribe.

subscribe

seems that patch from #13 is exactly that i need to import feeds as node translations, can it be ported to d7 please?

+1 for porting #13 to D7 if it is working.
greetings,
Martijn

Should #1160182: Mapper for core Upload fields be rolled into this issue?

Hi Martijn,

I have added promote to frontpage for D7.

subscribe for porting #13 to D7

Hi, is there any plan to port #13 to D7? This is quite an important feature, thank you.

try the dev version of the module - it includes mappings for promote, sticky, language and comment properties of nodes.

A lot of work was done over at #1247536: Allow users to choose node import language, which I'm marking as a duplicate of this one.

Import from Issue http://drupal.org/node/1247536 from August 12, 2011:

Allow users to choose node import language
Where can I select the language of the new node before import?

Thanks in advance
Wusel

[update]
The entry "Language neutral" is not ok in serveral environments, e.g. to import events like "Events calendar feature" (http://drupal.org/project/events_calendar_feature)
[/update]

I find it strange, that I cannot define the language of an imported event (Events calendar feature - http://drupal.org/project/events_calendar_feature) - #1247536: Allow users to choose node import language
The language of my website is German, not English.

These Events are not shown yet...

This might get kicked out of the stable release list, but adding tag so that it can be reviewed.

An first patch you can find at http://drupal.org/node/1247536#comment-5053190 (Allow users to choose node import language) and in the newer replies.

I hope, this can help...

Hi all and thanks for all (works and other stuff) !

For me using the dev version as suggested at #33 work "quite" fine.
I'm building a commerce site with both english and french language.
I've created a Feeds importer for my admin products that works fine.
I've created another Feeds importer for my product display.
When I import my csv file for product display (it contains a column with the language "en") it works perfectly, nodes are created in english.
So I made a second file where I changed the language to "fr" for french and I was expecting that new nodes are created for my second language, but instead it update the node created in the first language (en) setting the original language (en) to the new one (fr)...
Someone has a suggestions ? Does the translated nodes could be linked together (flagged as translations for each other) ?
I'm not english spoken so sorry for bad words and sentences...

Thanks in advance

We have created and tested a recent patch allowing you to map feed items and their TNID.

http://drupal.org/files/TNIDparserAndMapperFix-1183440-64.patch

When the patch is applied to the latest dev version of feeds, TNID will show up as an optional mapper item only when the module "translation" is installed.

To test this patch, please follow these steps

Step 1) install and enable the Content Translation module (aka "translation")
Step 2) install and enable i18n , create a second language (french for this test)
Step 3) create a content type called individual with title, givenname, firstname (see atached (zip + csv))
Step 4) install and enable latest dev version of feeds
Step 5) apply this patch to feeds: http://drupal.org/files/TNIDparserAndMapperFix-1183440-64.patch
Step 6) create a mapper in feeds to map to the content type created in step 3 , map the fields described in the attached CSV file, make sure to map NID,TNID,givenname,lastname and title, and LANGUAGE column (in this example csv file: en for english and fr for french).
Step 7) import the attached (csv in the zip) file using feeds (as admin go to sitename/import)
Step 8) verify in the database that TNID is imported correctly for these nodes, looking at the node table

If you see the correct TNID from the attached (zip with a CSV) file in your node table for the two imported nodes, then it works. Once your site has a language switcher(too long to describe how), the appropriate translation will be loaded automatically depending on the language selection.

I have more or less the same set up, but instead of using the field "nid" as a Drupal nid, I use a "NewsId" as GUID. My nid is generated automatically.

Now the question is, how can I create my French nodes, linked automatically to an english "NewsID" ?

EDIT: Never mind, it actually works like that already ! Thank you !!

mzwyssig

how can I create my French nodes, linked automatically to an english

That is why we created a patch for TNID

EDIT: Never mind, it actually works like that already ! Thank you !!

Are you using my patch for this? Can you tell me if your TNID column on french nodes in your database is pointing to the english nodes? Curious as to if you have used this http://drupal.org/files/TNIDparserAndMapperFix-1183440-64.patch

Please confirm.

Another solution: http://drupal.org/node/1819720

I have tested http://drupal.org/files/TNIDparserAndMapperFix-1183440-64.patch which is a nice step.

Thanks to joseph.olstad which have done a nice job. It works !
Do you think, it works for user and taxo import ?

Here, nid and tnid are set by the cvs import data. May be this could has some issues :
- nid are to be set by Drupal and we have to check that imported nid aren't already used by existing nodes
- after the import, how Drupal will know to not use these nids ?

By the way, the next step will be to import translations and map it with nodes already created. What about the way the interface translations are done ? You export nodes in csv format, selecting a language, one makes translation in csv file adding as many rows as languages needed, and you import the result. The importer has to detect existing nodes (based on title or more) and remenber associated language. Each following lines with different language is considered as translation to map...

@joseph.olstad
I'm using your patch. Can't check the database, but the references are correct when I check the translations tab on the node.

BertrandL - I have tested http://drupal.org/files/TNIDparserAndMapperFix-1183440-64.patch which is a nice step.

Thanks to joseph.olstad which have done a nice job. It works !

Here, nid and tnid are set by the cvs import data. May be this could has some issues :
- nid are to be set by Drupal and we have to check that imported nid aren't already used by existing nodes
- after the import, how Drupal will know to not use these nids ?

Thanks for confirming the performance of our patch.
To answer your question, if you're upgrading from D6 to D7 like I am and you're bringing content in from D6 to D7, then your data export will have the correct NID's and correct TNID's provided you've exported them correctly as I have (to a CSV, or whatever).

However if you do not have NID's in your dataset, then do not select NID or TNID, there's other posts related to that use case (see http://drupal.org/node/1183440#comment-6319962 is an example )

mzwyssig I'm using your patch. Can't check the database, but the references are correct when I check the translations tab on the node.

Hi Mzwyssig, thanks for confirming that our patch works as designed.

It basically works and it saved me A LOT of time, thanks!

Problem: content is not showing when editing the node. All the fields are empty in the edit screens but the content is showing on the website.

I found out that values for the language field are incorrect in the database. It applies to a bunch of fields but for this example I tried changing "field_data_body" in phpMyAdmin. I changed "und" for the corresponding language and content reappears in the edit screens.

How can I set that language using Feeds for each field? I know the Feeds Entity Translation module but it's not working for me, it creates the same problem.

Edit: I could temporarily replace the value directly in the database but it's not pratical for everyday maintenance.

Horroshow It basically works and it saved me A LOT of time, thanks!

Problem: content is not showing when editing the node. All the fields are empty in the edit screens but the content is showing on the website.

Hi Horroshow, I am mapping language (from the csv I provide) to Language (in the content type)
as well as nid to nid and tnid to tnid because my dataset comes from D6 and I'm bringing it into D7 using feeds node mapping.

I'm using the feeds "Mapping for node processor"
, I'm assuming this means that all fields for each node are in one language, each node is assigned a language by the Language field (provided you have the translation module enabled).

If you want field level processing, you'll have to ask someone else, I'm using node level processing.

The reason we use node level processing is for compatibility reasons (with contributed modules). This may change at some point in our organization, but for now we use node.

Very understandable, I will wait until this patch is completed > http://drupal.org/node/1183440#comment-6530976

Thanks for your work! I really appreciate what you've done with your TNID patch.

Hi everybody. I've also tested patch http://drupal.org/files/TNIDparserAndMapperFix-1183440-64.patch and it works very well. Thanks!

Hi,
Can anyone scetch the process how to handle the nodes with terms in a certain language using this patch?
Thanks a lot in advance for your attempt!
I have difficulties getting it to work. I had a patch which adds a language column to the feed import screen, but this patch seems to need a field for language in the data itself?
Greetiings,
Martijn

I have a problem with this patch actually. I didn't come back earlier because I didn't see the error when importing 5 nodes, but then I imported about 1000 nodes and the nodes that where created before this have their translations mappings broken.

Basically, I had a dozen basic pages for each language (French, English), and after the import, on the translate tabs of those basic pages were 2 newly imported news displayed. No reference to the other basic page. When I go to this basic page in English and click on the French link in the language selector block, I get to the news node.

Any idea ?

Alright, I just saw that the imported nodes don't have a "source language" on the default tab. Am I doing something wrong or is this the case for everybody ?

Hi joseph.olstad - I too used your patch and it works beautifully for maintaining the translations when migration a multilingual site from D6 to D7. Thank you!

However as Horroshow and #8 Unkn0wn said http://drupal.org/node/1062260#comment-6124254 - in D7 the language id gets added to the new node but the field_data_body for that node is set to UND! So that means you need to manually change each field_data_body field to have the correct lange, en, fr etc. And this is the case in D7 - even if you aren't doing field translation - only the node translation.

I wonder if another patch cold be made that does what you did with TNID - and makes sure it adds the language ID to the field_data_body as well as node for each node as it is saved?

I did try setting up entity translation as well hoping this solution http://drupal.org/project/feeds_et would work for me - but it didn't work and I don't really need the added complexity of entity translation for this current site.

Hey mzwyssig - did you figure out what happened? Mine has source defined. I made sure to map the language as well in the short form: en,fr ect.

Yes in addition to the TNID you'll need to map language as well.

Step 6) create a mapper in feeds to map to the content type created in step 3 , map the fields described in the attached CSV file, make sure to map NID,TNID,givenname,lastname and title and LANGUAGE

in step 6 you'll need to map the language field as well assuming your dataset has the correct abbreviation (en for english and fr for french is the default). I'll edit my previous post #40 to describe this.

Does this help?

hi @joseph.olstad

Did you see this question?

I wonder if another patch cold be made that does what you did with TNID - and makes sure it adds the language ID to the field_data_body as well as node for each node as it is saved?

thanks for everything you've done so far.

For those who want to import bilingual or multilingual data using feeds and you do not want to supply a tnid in your dataset (ie; have this code create one during import) you will want to see this post:
https://drupal.org/node/1183440#comment-7478058

Is it possible to get this patch updated for latest dev version? I get 1 of 2 hunks failed

I need current information for importing with feeds (8.x-3.0-alpha10) with parser feeds_ex (8.x-1.0-alpha4) and use JsonPath with content translation for 2 json files. one for each language.

I still could not import without warnings/errors on the 2. language (german was imported before):

GERMAN:

The inhalt Testprodukt SINGLE IMPORT failed to validate with the following errors:
Title (title): Title: Dieses Feld kann nicht mehr als 1 Werte aufnehmen.
Testprodukt Artikelnummer (field_testprodukt_artikelnummer): Testprodukt Artikelnummer: Dieses Feld kann nicht mehr als 1 Werte aufnehmen.

Please check your mappings.

Error:
Fehlermeldung Testprodukt JSON Feed 1 en: Import fehlgeschlagen 1 Testprodukt.

ENGLISH:

The content test product SINGLE IMPORT failed to validate with the following errors:
Title (title): Title: This field cannot hold more than 1 value.
Testprodukt Artikelnummer (field_testprodukt_artikelnummer): Testprodukt Artikelnummer: This field cannot hold more than 1 values.

Please check your mappings.

Error:
Error message Testprodukt JSON feed 1 en: Import failed 1 Testprodukt.