i18n issues i D6/UC2 for Multilingual sites

123 replies [Last post]

Submitted on Mon, 05/11/2009 - 15:02

Joined: 08/08/2007

Juice: 544

I'm looking at making a Multilingual Drupal-6/Ubercart-2 site for Europe and have hit a few problems in terms of how the i18n module does content translations (i.e. has a parallel node for each language):

1. i18n creates a new node for each language you translate of the product. You can use the i18n_sync to keep the basic product values in sync between the two translations (i.e. sell_price, SKU, image etc) but Attributes, Adjustments and Stock levels can't be sync'ed with this module. This becomes a major data entry problem as it leaves much room for error.

2. The i18n_sync modules allows you to create a list fields to sync by node type. Now if you create product Classes to group your attributes in this means you have to duplicate this array of basic variables for each dynamic product type. Workable if you only have a few types of products but painful. I have suggested a fix.

3. I haven't tried the 'node_import' for products yet but I assume there is no option to import content translations. What about things like stock_levels?

I have looked in these threads but found no solution:
http://www.ubercart.org/forum/internationalization/4246/multiple_languag...
http://www.ubercart.org/forum/support/4758/ubercart_multilingual_site_mu...
http://www.ubercart.org/forum/internationalization/29/translation
http://www.ubercart.org/forum/internationalization/8725/translating_prod...

One solution I was toying with but haven't investigated the feasibility of would be at the theme level have a list of fields to translate (instead of a list of what to synchronise) and then load the default language node, swap the fields to translate in the $content array and then render. I guess this would also require redirecting to the original node. If SKU were used as the ID for a product everywhere in UC and not Node ID then this would work as you'd just have the SKU passed to the 'Add to cart' function...?

Really all we want is to translate the product 'Title' and the 'Description' fields and we're forced to deal with this dreadnought of a translation nightmare. Perhaps I should hack together something that just translates these fields on the fly based on the Locate string. I mean, how hard can that be...? ("famous last words")

Uberdevelopment www.tsd.net.au/blog

#1 Submitted on Mon, 05/11/2009 - 15:31 Top View page

Docc

Joined: 07/03/2008

Juice: 163

Ran into this problem myself on my last project (7 languages in 12 different countries).
Decided togo with the flow and make the best with the node translation duplicates.

I made a sync for the different product elements (stock, ubercart core data, like price etc). After that i needed to run though ubercart and made different parts like product overview etc base there data on only the main tnid. Otherwise you get duplicate data all over the place. Also made sure cart products are always the main node (tnid)

All by all a pritty dirt job. My advise. Try to come up with a solution to translate the form elements you need to get translated (like title, description, path...) Seems faster and cleaner then my last approach. And yes...shouldn't be that hard....

#2 Submitted on Tue, 05/12/2009 - 03:47 Top View page

Docc

Joined: 07/03/2008

Juice: 163

Id really like a ubercart team member to reply on this. As this is a big issue. Are there any plans to take on the multilanguage problems?

#3 Submitted on Tue, 05/12/2009 - 15:17 Top View page

Ryan

Joined: 08/07/2007

Juice: 15375

Our goal for this stuff has always been to "keep it close to core." Multilingual problems aren't something we're generally equipped to solve, but there are a lot of other people in the community working on it. Ubercart does its part by using the core Drupal APIs for localization as they're intended, so any solution that works with core Drupal will work with Ubercart. I'm not sure what else we can really do at this point.

#4 Submitted on Wed, 05/13/2009 - 04:11 Top View page

Docc

Joined: 07/03/2008

Juice: 163

Yes and no.

Ubercart makes no distinction between normal nodes and translation nodes. So every node thats a translation is a product on its own for Ubercart.
Wich isnt the case. A node and its translations are 1 product. It would be more suitable to base it for example on the SKU or the tnid i reckon.

#5 Submitted on Wed, 05/13/2009 - 07:54 Top View page

CpILL

Joined: 08/08/2007

Juice: 544

Also,
a lot of what most people would consider core functionality like stock levels, attributes are not core to the product and so synchronising across multiple translations becomes a nightmare the more products you add.

Uberdevelopment www.tsd.net.au/blog

#6 Submitted on Wed, 05/13/2009 - 14:55 Top View page

Ryan

Joined: 08/07/2007

Juice: 15375

I dig. There's an idea moving forward to decentralize products from nodes and instead use the node form to create an attach new or existing products to a particular node for display of that product w/o the node itself representing the product. If this happens (it'd be 3.x) then we could have multiple nodes all displaying the same product info, which seems like it would then help you out with this module that creates duplicate nodes, right?

#7 Submitted on Thu, 05/14/2009 - 02:34 Top View page

CpILL

Joined: 08/08/2007

Juice: 544

Yes, that might help. I thought that a product could be like a CCK field in which you attach a price and SKU. I started designing something like that once but not in Drupal.

How would this affect product attributes? To say they should just be attached to the Node separately means you still have to track the SKUs of each. The main point of pain in UCs design seems to be that Products and Attributes are separate and the Product has to have 2 sets of behaviour depending on whether Attributes are present or not. I would think that one of the design goals of UC3 would be to simplify this into one Product behaviour.

Also, products as attachments to Nodes might make importing difficult as you'd need to specify Node ID(s) to attach the product info to?

So many balls to jungle with Drupal

Uberdevelopment www.tsd.net.au/blog

#8 Submitted on Thu, 05/14/2009 - 05:46 Top View page

Docc

Joined: 07/03/2008

Juice: 163

I think that would work yes. It would clear out the problem of duplicated product nodes
Only how would one go about translating the product form elements if its not a node?

#9 Submitted on Wed, 05/20/2009 - 08:35 Top View page

rudeboyal

Joined: 05/20/2009

Juice: 10

An interesting concept might be to get rid of the integration of i18n from the product for certain aspects such as product description etc.. but instead to have module that automatically detects the languages installed in drupal and create a field for each language for each field type (description, product name, etc...)
Then maybe to have the fields visible based on language?

It's the beginning of an idea. What do you think?

I'm already imagining some complications but I don't think it's impossible. And it would avoid the multi-product problem for each translation... 1 node for as many languages as you like. And those fields can also be assign on node_import.

#10 Submitted on Thu, 05/21/2009 - 06:14 Top View page

CpILL

Joined: 08/08/2007

Juice: 544

as noted by splash112 elsewhere, there seems to be a project in Beta that does just that:

http://drupal.org/project/LangsAtOnce

Uberdevelopment www.tsd.net.au/blog

#11 Submitted on Fri, 05/22/2009 - 10:45 Top View page

rudeboyal

Joined: 05/20/2009

Juice: 10

This module looks great.. I'm going to try it out.. hopefully it's just what I need!

#12 Submitted on Fri, 05/22/2009 - 11:55 Top View page

rudeboyal

Joined: 05/20/2009

Juice: 10

it's pretty good but it has a few things missing. It's great that you can change the title and body fields but what about the rest and what's more it doesn't work on the products content type!!!

#13 Submitted on Fri, 05/22/2009 - 13:46 Top View page

CpILL

Joined: 08/08/2007

Juice: 544

Haven't investigate it myself. i'll have a look now and see if it can be hacked. i don't see why it shouldn't work on the Product content types?

Perhaps it can be ~~hacked~~ improved...?

Uberdevelopment www.tsd.net.au/blog

#14 Submitted on Wed, 06/17/2009 - 15:54 Top View page

asak@drupal.org

Joined: 10/23/2008

Juice: 67

This is a serious issue.
It makes ubercart 2 nearly useless for multi-lingual shops.
I can't expect my clients to enter every product twice, and then get all stock and statistics messed up.

This is clearly an ubercart issue and not a drupal issue, since as mentioned the problematic issues are mostly attributes, stock level and the such.

I'm certain that the best practice would be to have the manager of the site only add ONE node for every product, and then have the system decide what's the correct way to display it. Fact is, the only thing that needs to be translated (mostly) is title & description. the whole idea is that everything else is probably the same (that's why it's just a translation and not another product). Other fields (CCK) can be easily translated if desired.

I'm now realizing that one of the biggest issues here is probably the path, and more specifically pathauto. for SEO sake, we really must accept the fact that every products must have it's own URL in it's own language. This could be done by hooking with pathauto, and manipulating paths by creating multiple paths to the same node, or by creating two nodes. If this problem is solved, without the need of 2 nodes, i think it makes much more sense to focus attention on getting a product to be one node for all languages.

Another factor is SKU, and more specifically the management of products through ubercart, including stock and statistics. If it's one node - we're good. If not - a possible change as suggested to make ubercart consider a SKU as a product, and not a node, would probably be the easiest - be would require the biggest change of ubercart core (i think...?).

I think the idea of decentralized products (as discussed in this thread) is a huge over-kill. It sounds to me a bit too complicated, which makes me believe that clients would find it extremely complicated. It may work well for other causes and solve other issues - but i doubt it will solve the multi-lingual issue, especially since it's complicated.

I will try the LangsAtOnce module and see how it works.
There is also http://drupal.org/project/ipetranslation
and i just noticed http://www.ubercart.org/contrib/8787 (i18n Synchronization)
These take the 2-or-more approach.

This one: http://drupal.org/project/language_sections
Goes for one-node-for-all - but stumbled into the paths issues (http://drupal.org/node/313770#comment-1162730)

Ubercart still needs some internationalization attention - i hope we can get it working smoothly.
I have no plans on waiting for D7/U3 - we're making hot D6/U2 shop and will get them multilingual this way or another

This seems like the most active i18n+ubercart thread so i'll keep it updated with results - but if anyone knows of any active discussion about this stuff please update.

#15 Submitted on Thu, 06/18/2009 - 07:07 Top View page

Docc

Joined: 07/03/2008

Juice: 163

Well, we cant change the way drupal threats multi language.
Wich i think is not the best way to go but lets not go there.

But i dont think we should be looking for modules that take a different approach to multilanguage (form element translation anybody?) we should stick to ubercart core.

So we have to face the fact that a node creates translation nodes. Wich leave us with the following options.

one. Let ubercart base on the SKU (or mayby the tnid instead of the nid?) instead of the node/nid.
two. seperate the product from the node. Attach a product to a node

For my last project i patched ubercart to base itself on the SKU/tnid and made a sync for a lot of the product fields.

Wish i could be more helpfull here but the ball is with the developers. Wich i really hope will be picking this up.

#16 Submitted on Thu, 06/18/2009 - 08:17 Top View page

asak@drupal.org

Joined: 10/23/2008

Juice: 67

If we agree that a translation is another node, then i would vote for option one - let's teach ubercart to treat every SKU as a product and not every node. tnid is an option, but my opinion is that ubercart should be treating products by SKU regardless of translation issues. it makes it possible to have 2 nodes, of the same product, described differently (SEO/campaigns/...) which are still one product in the system.

I would really like this to work with one node, since it solves the attributes and stock problem, but it's problematic with the path aliases and workflow in general. I must confess that this is driving me practically nuts and i must solve this ASAP.

I think the solution really is to manipulate ubercart to use SKU's and not NID's for it's products. Besides that, we'll still have an issue with attributes.

Docc - could i inquire about how much work was involved for patching ubercart to work with SKU's? did you find a solution for attributes sync? did you hit any walls in the way?

#17 Submitted on Thu, 06/18/2009 - 09:44 Top View page

Docc

Joined: 07/03/2008

Juice: 163

First i made a sync for product form elements including attributes. So if a product node got changed all the translations got updated aswell. (i can imagine this could be done easier with replacing the node values with the tnid values on the node load)

Next i rewrote the mysql queries for the shop parts my customer has access too. Like reports, product overview etc. I made the queries look for the SKU instead of the nid.

Also i had to hook into the cart for the correct translations when someone switches languages and has products in the cart.

Really ugly but it had to be done at the time.

#18 Submitted on Mon, 06/22/2009 - 10:36 Top View page

CpILL

Joined: 08/08/2007

Juice: 544

@Docc, sounds like you started to re-write the core UC system! Perhaps a branch from the main UC2 code would be a good idea to follow this train of thought? Lyle, Ryan?

Uberdevelopment www.tsd.net.au/blog

#19 Submitted on Wed, 06/24/2009 - 13:10 Top View page

Ryan

Joined: 08/07/2007

Juice: 15375

Yeah, sounds like quite a bit of change. I'm not sure where this is headed or how it compares with discussion in the battle plans thread regarding the similar idea: make products first class citizens attached to nodes, such that a product is a SKU/price and the node (or nodes) is a display of a particular product. Regarding the reports and everything else, those sound like similar necessary changes. Perhaps Docc's experience can inform the 3.x battle plans thread?

#20 Submitted on Thu, 06/25/2009 - 17:12 Top View page

asak@drupal.org

Joined: 10/23/2008

Juice: 67

I've noticed the battle plan does not have the attention i was hoping for in regards to multilingual(izing) UC.
It's a show stopper for savvy e-commerce and a global market.

I went over the battle plan and tried to figure out how the products-attached-to-nodes concept will look like from a site's operator point of view. I'm not sure i understand.

Will this require the user to first add a product, and only then attach it to a node, or could the user create the product (sku+price combo(?)) on-the-file? is it a two-step process or one-step?

Why is the price part of the product? why not just unique sku? could this scenario be possible: a user creates a node to display a product he's selling on the site, and sets a price for it. while running on online campaign, he adds another node, for the same product (mainly stock and reports wise), with a cheaper price for a limited time?
if users visit the "main product page" they see regular price, but if they land on the "promotion special page" they get to buy the same product for a different price?

If that's possible - i see the multilingual part mainly solved. attributes still puzzle me in this set-up. they would still need to be translated, as they are part of a product. attributes, and especially attributes combos, are non-trivial to deal with when only using 1 language - so multilingual(izing) makes this a waky situation

I'm still not certain that drifting away from the Drupal way of multilingual websites, which is far from perfect, is a good idea. operators of ubercart shops are operating a drupal website as well. if they'd need to learn two methods of translation of their site it could make things a bit difficult (again - since the drupal way is more then enough trouble for them...).

I'm in touch with several developers, seeking a way to solve this for D6. I doubt that our solution would be upgrade compatible. I think one aspect which isn't discussed much is the SEO aspect. There has been discussion around the concept of one node for all languages - but a unique (multilingual) path is a must, and that buries that idea. I did notice that this is a feature which is lacking in all e-shops i investigated, which could be a HUGE bonus for ubercart!

Bottom line:

Quote:

I'm not sure where this is headed or how it compares with discussion in the battle plans thread regarding the similar idea

I really want to solve this, and have a feeling it will take a while before UC3 could be used for some mission-critical(?) e-shops. If we could find a way to solve this for U2 - and stay compatible with the ideas for U3 - that would be the best. If not - i think a U2 solution would have to be found, for i have no doubt that multilingual support is becoming a greater and greater factor in choosing an e-commerce solution. we don't want to loose folks for that

Keep up the excellent work - we're on-board!

#21 Submitted on Mon, 08/09/2010 - 10:37 Top View page

duarte.garin

Joined: 07/01/2010

Juice: 19

Hello,
I am trying to rewrite the SQL queries in order to reflect products by SKU instead of nid in reports (at the moment since each translation is a product it tells me I sold 1 portuguese ring for example, and 2 english rings when I wanted to show that I sold 3 rings)

I am looking at the current queries and to get SKU i have to join orders_products with products and it sems a bit of a performance hit.

Can you point me in the right direction?

Thanks in advance,

Duarte

#22 Submitted on Fri, 07/03/2009 - 17:25 Top View page

univac

Joined: 06/10/2009

Juice: 18

Hi CpILL,

I am setting up a site with D6.x + i18n + U.
As far as I saw, i18n is the most sophisticated module to support internationalization. Most of the multi-language sites are adopting i18n today. Adopting a different solution you would end up developing a similar module. Also Multi-language users may be discouraged in adopting Ubercart if i18n support is missing.

I have realized that Ubercart Developers are not yet multi-language oriented. See for example the number of reply I got with this support request http://www.ubercart.org/issue/11437/paypal_login_page_language.
This is a major weakness in the project, which would have great potentials in the Europe market, but miss this internationalization boost. And without it, we will not see support for european payment and shipping services and so on.

I do not have an in-deep knowledge in D/i18n development, but I believe a solution exists. i18n is rather flexible: you can have blocks in different languages in the same page, fields which are translated or not at your choice (look at http://www.ubercart.org/contrib/8319).
Finally, have you tried to get in touch with the i18n group of discussion? I saw several post concerning i18n_sync with related patches, which might have been committed already in the latest version.

Hope this might help.

#23 Submitted on Mon, 07/06/2009 - 17:50 Top View page

cha0s

Joined: 08/22/2008

Juice: 416

Heya guys, looks like you aren't getting too much love here about this issue.

Tell me, is this patch something you could use? Does it create more problems? Try it and lemme know, k?

Peace.

EDIT: The patch looks like it contains some of the attribute cleanup patch I posted on d.o. Not sure if/when that's gonna get pushed in, but if this works, you'll be happy, right??

Attachment	Size
translation.w00t.2.x.patch	30.17 KB

Try FreeBASIC!
My game Lynn's Legacy

#24 Submitted on Tue, 07/07/2009 - 02:18 Top View page

asak@drupal.org

Joined: 10/23/2008

Juice: 67

Hey cha0s - thank you so much!

I'll be testing this out and will be back with the results. I quickly went over the patch and it seems like it should do something useful

Back in a bit - and thanks again for jumping in!

#25 Submitted on Tue, 07/07/2009 - 09:08 Top View page

CpILL

Joined: 08/08/2007

Juice: 544

@univac

I have tried to give some input to the i18n-sync module: http://drupal.org/node/456358

But not sure how to use the solution they have come up with

Uberdevelopment www.tsd.net.au/blog

#26 Submitted on Thu, 07/09/2009 - 12:25 Top View page

firewing1

Joined: 07/07/2009

Juice: 54

After reading the bug report (http://drupal.org/node/456358) and taking a look at the i18nsync (Drupal, not UC) module I managed to sync the product data but not attributes or options:

Enable the i18nsync ("Synchronize Translations") module
Create a custom module to hook into i18nsync:
1. Create directory sites/all/modules/custommod
2. Paste into sites/all/modules/custommod/custommod.info:
  
  name = Custom module description = Custom module to synchronize Ubercart product data across translated nodes core = 6.x
3. Paste into sites/all/modules/custommod/custommod.module:
  
  <?php /** * Implementation of hook_i18nsync_fields_alter(). */ function custommod_i18nsync_fields_alter($fields, $type) { $fields['uc_products']['#title'] = 'Products'; // These values were found by doing a print_r($node) in node-product.tpl.php $fields['uc_products']['#options'] = array ( 'model' => 'SKU', 'list_price' => 'List Price', 'cost' => 'Cost', 'sell_price' => 'Sell Price', 'weight' => 'Weight', 'weight_units' => 'Weight Units', 'length' => 'Length', 'width' => 'Width', 'height' => 'Height', 'length_units' => 'Length Units', 'pkg_qty' => 'Quantity', 'default_qty' => 'Default quantity to add to cart' ); } ?>
Go to the module list and enable "Custom module"
Go to Content management > Content types and edit the "Product" content type

Under Workflow Settings > Synchronize translations, select all applicable fields
Repeat for any additional product classes/content types

That's all! If you edit a node in one language, you should see the updated product data in all other languages as well.

#27 Submitted on Fri, 07/10/2009 - 06:51 Top View page

xacobe

Joined: 06/16/2009

Juice: 46

I follow firewing instructions and its working to me. Thanks so much. Im building a five languageÂ´s site with Ubercart and I was a bit scare about multilingual problems but you are getting it right.
Ubercart rocks!

#28 Submitted on Wed, 07/08/2009 - 08:34 Top View page

tbee

Joined: 07/08/2009

Juice: 2

So I'm checking off a requirements list for a to-be-build international webshop. Drupal came out as the #1 candidate above Joomla (less flexible) and the OSCommerce derivates (bad code), but this definitely would be a showstopper. I must say that I'm amazed that multilinguality was not taking into account in a 2.x release. I can understand that a 1.x release may have had different priorities, but...

Anyhow. The only thing that would allow me to still use Drupal is the fact that the product data comes from an ERP, so I can hopefully easily resync all nodes.

#29 Submitted on Thu, 07/09/2009 - 08:55 Top View page

GiorgosK

Joined: 07/05/2009

Juice: 31

My 2 cent with an easy temporary solution

modified uc_i18n_sync.module (found here http://www.ubercart.org/contrib/8787)

added two more synchronization sql queries for uc_product_attributes and uc_product_options

solution is not completely automated since I don't know what function to override
(where to hook the attribute/option synch sql queries) does anybody know ?

Thus one has to edit/save the product in order for attributes/options to get synched across other translations

-----------------------
Maybe I missed the point of previous discussions but couldn't this be a workable solution for uberacart2/drupal6 ?
(Other ubercart/product variables can get synched the same way I assume right ?)

Attachment	Size
uc_i18n_sync.zip	1.21 KB

------
GiorgosK
Geoland Web development / web marketing
Media Temple Special Offer Codes

#30 Submitted on Thu, 07/09/2009 - 11:44 Top View page

Docc

Joined: 07/03/2008

Juice: 163

Well syncing things is the easy part. The problem is that ubercart expects a product to be 1 node.
Lets say you have a node/product in 5 languages, so 1 product translated in 5 languages.

Ubercart will think you have 5 different products (5 different nodes) because it doesn't know about translation nodes.
And will treat them as different products all over the system (cart, reports, product overview etc)

#31 Submitted on Fri, 07/10/2009 - 20:42 Top View page

GiorgosK

Joined: 07/05/2009

Juice: 31

Docc wrote:

Well syncing things is the easy part. The problem is that ubercart expects a product to be 1 node.
Lets say you have a node/product in 5 languages, so 1 product translated in 5 languages.

I understand this part Docc,
Provided that one does not care about the reports being representing each product with two instances (in a two-language site) then syncing is a viable solution ...

my last upload uc_i18n_sync.module creates empty attributes if there is no attributes to be copied over and empty attributes appear on the product ... thus should be avoided.

here is a new version I am using

Syncing happens on "node view" only if the user has "update products" access.
Attributes and options are also updated. Also added a simple "prepare translation"
handler that copies over appropriate fields.

It works for me but any comments are appreciated

Attachment	Size
uc_i18n_sync_on_node_view.zip	1.44 KB

------
GiorgosK
Geoland Web development / web marketing
Media Temple Special Offer Codes

#32 Submitted on Mon, 07/13/2009 - 06:03 Top View page

Docc

Joined: 07/03/2008

Juice: 163

Yeah im still looking for that total solution.
Anyhows, remember you also have to address the cart. If someone switches language while having a product in the cart i will not be replaced by its translation node.

Probaply will look something like this

/*
*  Replace products in cart with current language
*/
function uc_boumy_cart_item($op, &$item) {
  switch ($op) {
    case 'load':
	global $language;
	$node = node_load($item->nid);
	$translations = translation_node_get_translations($node->tnid);	
	if($translations[$language->language]){
	  $item->nid = $translations[$language->language]->nid;
	  $item->title = $translations[$language->language]->title;
	}
      break;
  }
}

#33 Submitted on Mon, 07/13/2009 - 17:34 Top View page

firewing1

Joined: 07/07/2009

Juice: 54

Thanks Docc, that code works perfectly!

My last major issue with setting up a multilingual Ubercart store is that translated product nodes appear as separate products in the reports area... I'll post code back here if I find a way to workaround this.

#34 Submitted on Tue, 07/14/2009 - 03:43 Top View page

Docc

Joined: 07/03/2008

Juice: 163

workaround = rewriting the sql queries

#35 Submitted on Fri, 07/17/2009 - 04:07 Top View page

mrsimonelliott

Joined: 07/17/2009

Juice: 10

It's only six weeks until DrupalCon Paris. How many of you guys would be interested in getting together to discuss and work through some of the UC multilingual issues face to face?
If there is any interest in this idea then I'll get it organised.

Slightly off topic, in Europe Multilingual sites also have multiple VAT tax issues, there is a group working on this, it may be a good idea if they got involved too.

Regards
Simon Elliott
(Drupalcon Paris 'little helper')

#36 Submitted on Wed, 07/29/2009 - 04:44 Top View page

anschinsan

Joined: 07/29/2009

Juice: 5

As reply to #34

I'm sure we'll meet in Paris

#37 Submitted on Sun, 08/30/2009 - 04:14 Top View page

PACraddock

Joined: 08/21/2009

Juice: 23

Thanks to all who have contributed bits and pieces (thanks to firewing1 in particular for putting a step-by-step procedure combining these bits of information on his website!).

One issue seems to remain: despite the fact that the contents of the cart are translated: if a user puts item A in the shopping cart, then switches to a second language, he/she can add item A again, though this will appear as a second item in the cart (basically you'll see "1x A, 1x A" instead of "2x A". Is it possible to fix this easily?

#38 Submitted on Tue, 09/08/2009 - 04:42 Top View page

selinav

Joined: 08/17/2009

Juice: 120

Hello

I'm french and have the same problem.
My english is not very good.
Please, Can you do a summary of the main points to do a translation of products nodes and attributes (patch or module to apply)

Thanks

#39 Submitted on Tue, 09/08/2009 - 05:29 Top View page

xacobe

Joined: 06/16/2009

Juice: 46

Follow the instructions on firewing1Â´s blog http://www.firewing1.com/node/27

#40 Submitted on Wed, 09/09/2009 - 04:12 Top View page

selinav

Joined: 08/17/2009

Juice: 120

Thank for the link, it well works for taxonomy and CCK Field.

But, how I can get the stock and the attributes?

Many thanks

#41 Submitted on Fri, 09/11/2009 - 09:50 Top View page

CpILL

Joined: 08/08/2007

Juice: 544

Ya,
thats the main problem with Products: attributes/stock. There needs to be some core changes to make this clean. Perhaps a new Product type all together, but this would require a definate Product/Cart API definition. Perhaps someone will come up with a hack. I think I'll need to translate into German and Chinese in the near future...

Uberdevelopment www.tsd.net.au/blog

#42 Submitted on Sun, 09/20/2009 - 16:04 Top View page

drupalina

Joined: 09/20/2009

Juice: 5

Hello,
I'm not a coder, but I've been using Drupal for 2.5 years and I'm new to the Ubercart community! My friend has asked me to create an e-commerce site with 6 languages, so this is my first Ubercart project.

After reading this whole discussion thoroughly, I still think that "1product=1node" is the optimal principle when looking for solutions. Because it's clean! Even if the SKU is given priority over NID in Ubercart architecture, 1product=1node is still the most sensible way to go about it (if you think in terms of not only stock and product management through UC interfaces, but also Drupal's own database). A solution for multiple nodes that can later be syncronised is not only inefficient and user-unfriendly, but also prone to bugs and problems.

But with 1node=1product product related fields and attributes stay the same across languages. We only need to change Name and Description to appear as per that language. How hard can that be?

So... what could be a good work-around?
I tried modules like http://drupal.org/project/LangsAtOnce and http://drupal.org/project/ipetranslation
Their principle of creating multiple per-language Title and Body fields is good, but these 2 modules end up creating separate nodes. NOT good! But we need to take the principle of its simplicity and move in that direction...

BUT... if there was such a module "CCK_i18n_fields" that would be a perfect solution for this Ubercart problem and numerous other similar problems among Drupal sites. What if there was a CCK-related module which would create separate CCK fields (Title, Body, URL) for different i18n languages and then display that field in the language in which the node is being viewed.

Think of it as a reverse of what i18n_sync does: instead of sychronysing nodes, it would simply select which language field to display. Result: 1 node=1 product with multiple language descriptions, titles and URLs.

For example, Wordpress has such a simple solution with qTranslate plugin http://wordpress.org/extend/plugins/qtranslate/screenshots/

(And with CCK fieldgroups and Tabs these new multilingual fields could be nicely stacked together, to make it very easy for the end-users. )

What about the URLs? well /en/product/42 and /it/product/42 are distinct URLs, are they not? If not, then this hypothetical CCK_i18n_field module could add an additional URL field below each Body field and thus if a node is available in 6 languages, then it would have 6 url path aliases too.

Does anyone know if such a CCK module exist??? If not, is any coding drupal guru up for writing such a CCK module?

-----
PS: where I'm still confused is how to translate the taxonomy terms in Catalog block. Taxonomy terms in Ubercart don't seem to pass through t(). Can someone please paste the code replacements?
Please don't tell me to use the conventional i18n_taxonomy syncronization method, because, unless I overlooked something, it totally doesn't work. In this case it's better if they pass through t() and then get translated, so that term/12 is term/12 and not term/12=term/28

#43 Submitted on Mon, 09/21/2009 - 13:23 Top View page

CpILL

Joined: 08/08/2007

Juice: 544

The thing is that SKU can have more than one Node ID. What you really want is a further seperation of the Product from the Node so you can take advantage of Drupals existing translation system. The Node part of the Product is just for show, display purposes and has no functional part Shopping Cart system (or at least it shouldn't, Lyle), which is all SKU based. For displaying whats in the cart cart the product should just hand over an SKU and the appropriate translation Node should be handed back.

Attributes should be all using the t() interface. Perhaps this shouldn't be that hard. UC just need to make sure its using SKU internally instead of Node ID and just have a lookup table for Node ID.

It would be nice if the Product images where also associated with the SKU so you'd get the size/colour you added to your shopping cart. Perhaps if Images where Nodes unto themselves then they could also have different language versions.

Anyway the solution seems to be finally coming out of the mist here. Put a SKU-to-Node-ID table in there and keep the two systems as separate as possible. This would work for Single Product to SKU and the one Product to many SKUs of the attributes.

Sweet!

Uberdevelopment www.tsd.net.au/blog

#44 Submitted on Tue, 09/29/2009 - 12:23 Top View page

jorditr

Joined: 10/31/2007

Juice: 255

Hi Drupalina,

if you ask where you could hack code to show catalog categories tanslated maybe you could look at uc_catalog.module and lok at the lines market JTR:

<?php
function uc_catalog_get_page($tid) {
  $catalog = new stdClass();
  $vid = variable_get('uc_catalog_vid', 0);
  if ($tid) {
    $term = taxonomy_get_term($tid);
    $name = $term->name;
    $description = $term->description;
  }
  else {
    $tid = 0;
    $name = t(variable_get('uc_catalog_name', 'Catalog')); // JTR
    $description = variable_get('uc_catalog_description', '');
  }
  $catalog->tid = $tid;
  $catalog->vid = $vid;
  $catalog->name = t($name); // JTR
  $catalog->description = t($description); // JTR
?>

That way, every time the catalog first shows a category you will find it tranlatable at locale.module.

Maybe you would also the word "Catalog" translated on the breadcrumb:

<?php
function uc_catalog_set_breadcrumb($tid) {
  static $breadcrumbs = array();
  static $terms = array();
  if (variable_get('uc_catalog_breadcrumb', TRUE)) {
    if (empty($breadcrumbs)) {
      if (variable_get('site_frontpage', 'node') != 'catalog') {
        $breadcrumbs[] = l(t('Home'), '');
      }
      if ($tid != 0) {
        $breadcrumbs[] = l(t(variable_get('uc_catalog_name', 'Catalog')), 'catalog'); // JTR
      }
    }
?>

You see, oh my, you see, how difficult would be in code to have catalog name, catalog categories and breadcrumb translated...

#45 Submitted on Tue, 09/29/2009 - 12:50 Top View page

jorditr

Joined: 10/31/2007

Juice: 255

Hi again, I've wanted to separate my last comments on different entries. Now I would like to comment that Drupalina entry.

I fully agree that such a i18n module would save us the day on multilingual shops,... and on many other types of sites

For been able to use it on node titles we should hide the node title (with excellent auto_nodetitle.module), and the use that field on views-like lists. But on Ã¼bercart we'll have to hack the code on many places, because the title appearing on many lists as catalog, cart, order or checkout are not on "theme-like" funtions, but on many "core-like" Ã¼bercart functions.

Having to hack Ãœbercart code anyway, maybe one approach could be one that I've used on my last Ãœbercart shop. I've created an alternative CCK plain-text-field called "field_spanish_title" that we can access at "content_field_spanish_title" table, a CCK field independent table because I've shared that field among all the product-node-type classes. Then the code on uc_cart.module is (you'll see all my hacked code between "// JTR" tags):

<?php
function uc_cart_view_form($form_state, $items = NULL) {
  $form['items'] = array(
    '#type' => 'tapir_table',
    '#tree' => TRUE,
  );
  $context = array(
    'revision' => 'themed-original',
    'location' => 'cart-subtotal',
  );
  $i = 0;
  foreach ($items as $item) {
    $display_item = module_invoke($item->module, 'cart_display', $item);
    if (!empty($display_item)) {
      $form['items'][$i] = $display_item;
      $form['items'][$i]['image']['#value'] = uc_product_get_picture($display_item['nid']['#value'], 'cart');
      // JTR - adding spannish name if required
      $nom_spannish = db_result(db_query('SELECT field_spanish_title_value
                    FROM {content_field_spanish_title}
                    WHERE nid = %d', $display_item['nid']['#value']));
      global $language;
      if ($language->language == 'en') {
        $nom_prod = $display_item['title']['#value'];
      } elseif ($language->language == 'es' AND $nom_spannish ) {
        $nom_prod = $nom_spannish ;
      } else {
        $nom_prod = $display_item['title']['#value'];
      }
      $description = $nom_prod . $display_item['description']['#value']; // JTR
      $form['items'][$i]['desc']['#value'] = $description;
      $form['items'][$i]['title']['#type'] = 'value';
      $form['items'][$i]['description']['#type'] = 'value';
      if (empty($display_item['qty'])) {
        $form['items'][$i]['qty'] = array(
          '#value' => '',
        );
      }
      $form['items'][$i]['total'] = array(
        '#value' => uc_price($display_item['#total'], $context),
        '#theme' => 'uc_cart_view_price',
      );
      $i++;
    }
  }
?>

I don't know if that's the best way to approach that issue, but, at least, it works to me. I've prefered to display the code better that the patch to allow you to see the code solution. That means that for Ãœbercart wouldn't be difficult at all to create an internal translation and loop through all the languages, saving, whay not, on a proper "uc_product_name_translation" table.

Well, at least, it's already working on my last Drupal/Ãœbercart implementation. BTW, you'll also have to hack also "uc_cart_checkout_pane.inc" in order to swap node title with CCK translation node-title-like field on cart table.

#46 Submitted on Mon, 07/20/2009 - 03:51 Top View page

splash112@drupal.org

Joined: 04/01/2008

Juice: 398

Ok guys,

Seems that the whole syncing business is the way to go? I hate to spoil my database with heaps of useless data, but ok, will do.

Or, as it seems so simple, could we only use the main language product data? Use that nice product switching trick all over?

Thanks
Mark

Ubercart for wholesale

#47 Submitted on Tue, 07/28/2009 - 03:34 Top View page

firewing1

Joined: 07/07/2009

Juice: 54

splash112@drupal.org wrote:

Ok guys,

Seems that the whole syncing business is the way to go? I hate to spoil my database with heaps of useless data, but ok, will do.

Or, as it seems so simple, could we only use the main language product data? Use that nice product switching trick all over?

Thanks
Mark

That's an interesting point, I think uc_product_node_info might be the right function for this...

#48 Submitted on Tue, 07/28/2009 - 15:24 Top View page

firewing1

Joined: 07/07/2009

Juice: 54

It turns out hook_nodeapi is what we are looking for... This sample works for displaying the nodes:

<?php
/**
 * Implementation of hook_nodeapi().
 */
function custommod_nodeapi(&$node, $op, $a3 = NULL, $a4 = NULL) {
  switch ($op) {
    case 'load':
      $translations = translation_node_get_translations($node->nid);
      $language = language_default();
      $sourcenode = $translations[$language->language];
      $items = db_fetch_object(db_query('SELECT model, list_price, cost, sell_price, weight, weight_units, length, width, height, length_units, pkg_qty, default_qty, unique_hash, ordering, shippable FROM {uc_products} WHERE vid = %d', $sourcenode->nid));
      if($items) {
        foreach($items as $field => $value) {
          $node->$field = $value;
        }
      }
      break;
  }
}
?>

Description of the code: First, it looks up all translations for the node being loaded, which includes the original language, and then determines the site's default language. It then uses the same query that uc_product.module performs to retrieve product data, but uses the node ID of the node in site's default language and overrides the current node's ubercart product values with those from the source node.

It works well, however there are three problems:

Editing a translated product will load the correct values, but clicking "Save" will still store the redundant data.
Adding to this function to also handle the update and insert events (so it only saves product info non-redundantly in the source node) will mean that if a node is deleted, all translated nodes must be deleted with it (as their product data would have gone missing, rendering them useless).
If all the above is done it's pretty much the same thing as i18n sync, so may as well use that. As a bonus i18n sync also handles the CCK fields of your choice, which this method cannot do. It would have to use either all CCK fields, or use manually-programmed queries and either of these choices are not very useful.

#49 Submitted on Tue, 08/04/2009 - 14:46 Top View page

CpILL

Joined: 08/08/2007

Juice: 544

Having multipule copys of the same data is ugly. The translations are just for display purposes really so keeping and sync'ing all that redundant data is going to error prone and worse will be hard to upgrade and maintain in the future.

If I were forced to do a multi-lingual shop right now I'd have a separate shop for each language with separate DBs and use Google Analytics to do the reporting. Keep it clean until a good solution comes about.

The ideal solution would be to just translate the strings before they are displayed and provide a simple interface which just lists the strings and their equivalents (filtering by language). I guess attributes and options aren't going to change much so the t() function could be used on them all. Perhaps it could be used for everything...?

Why aren't all the reports using SKU instead of NID? This would then fix the multi-node problem, no?

I'd like to get over to Paris (I'm in Berlin). The trip isn't a problem but hotel for 4 nights will be too pricey

Uberdevelopment www.tsd.net.au/blog

#50 Submitted on Tue, 08/18/2009 - 15:51 Top View page

Jurgen8e

Joined: 10/02/2008

Juice: 81

Hi,

In this thread I read about product translations.
But what about orders, an order is made in a language. The aftersale-mails must also be in that specific 'order made'-language.

For multi domain support I added a column to the 'order'-table to know where the order is placed.
IÂ´m thinking to also do this for the language of an order.

Just want to notice this.

Jurgen
www.cardKeyfinder.com

	User login
	Log in using OpenID: What is OpenID? Username or e-mail: * Password: * Remember me Log in using OpenID Cancel OpenID login Create new account Request new password

Ubercart

i18n issues i D6/UC2 for Multilingual sites

Navigation

User login