i18n thoughts/needs
Just want to start a thread around i18n and multilingual sites. Ubercart has a number of issues around this and I want to do what I can to help Drupal Commerce (DC) avoid these :)
I saw a white board picture showing some of the brainstorming for DC and was very happy to see that i18n was on it.
So for now I guess two questions:
1- Is i18n being kept in mind as the core systems are developed for DC?
2- What can I (we) as users/developers contribute in terms of brainstorming/requests to help make DC fully multilingual capable?
Jc
PS If this is not the right place for this just let me know and I'll post/comment/contribute in the appropriate location
Comments
This is the perfect place to
This is the perfect place to post. : )
One thing I'd point you to is the snippet on i18n / l10n in the current development standards. It'd be great to see what you might add there as things to keep in mind during early development.
Also, we'll want to revamp the way we're handling countries and addresses. That brainstorming hasn't gone on in detail here yet, although I think Mike might have been working on something to that end. I'll ping him to see if he has anything to add here.
Thanks Ryan. I had a look at
Thanks Ryan.
I had a look at the part 7 of the standards but that's not exactly what I had in mind.
I'm more worried about the translability(?) of products, catalogs, and not having any issues with stock or display if a user switches languages while browsing, adding/removing from cart and then placing an order. As has been discussed before, the 1 SKU = 1 product issue. Since that is not the case in Ubercart trying to translate products causes problems.
Some of the issues are:
1- stock
2- catalog/taxonomy
3- switching languages while viewing a catalog
4- adding products in one language then switching to another
Hmm, so tease this out for
Hmm, so tease this out for me, but if we're decoupling products from product display... i.e. having a new product type that is displayed on nodes through a product display field... then translation issues should be nullified as long as the various language versions preserve the same field settings. The only thing I can imagine we'll need to consider is making sure our product entities have translatable titles. SKUs should stay the same.
Also, if items in the cart are simply a reference to a product in the database with a translatable title, I don't see why they shouldn't get the appropriate translation. I suppose I'm not experienced enough in multi-lingual Drupal to have a great handle on the issues here.
Tease it out for you? Could
Tease it out for you? Could be painful ... :)
First I want to point out two things that make it difficult for me to accurately reply:
1- I'm not expert enough in Drupal/Ubercart/i18n so I don't fully understand what is the cause for the various issue with UC and i18n
2- I don't know enough about D7 and Drupal Commerce to foresee if many of these issues will just go away by themselves.
That being said I'll give it my best shot.
1- If products are decoupled from display then yes, most i18n issues *related to products only* should go away.
2- Stock: I assume that stock tracking issues should also go away.
3- Catalog issues: my understanding is that the catalog is built using Taxonomy. Issues with trying to have a bilingual Catalog won't go away just by fixing the Product. (My understanding here is limited)
4- Language switching while viewing the catalog. Not sure if this is directly related to UC/DC but there are issue with the link that the language switcher creates. Basically the language switcher seems to have trouble creating the proper taxonomy/catalog links.
For more details see the UC bug here (http://www.ubercart.org/forum/internationalization/10878/i18n_issues_i_d...)
Something that just came to mind:
- Emails (invoices, etc.) seem to be sent to the user using the language that was used at the time the order was submitted. Could we add a setting for that. I.e., what if I want to only send out correspondence one language even if my site is multilingual?
Hope that helps?
Catalog is changing
Regarding the catalog, I hope that it will move to views (which most of us do anyway).
Yeah, DC itself won't have a
Yeah, DC itself won't have a Catalog module like Ubercart does; if anything, there will be a module that simply defines a default View. I can see that getting developed as a Features module and/or bundled into an Installation Profile.
Emails releated to profile
- Emails (invoices, etc.) seem to be sent to the user using the language that was used at the time the order was submitted. Could we add a setting for that. I.e., what if I want to only send out correspondence one language even if my site is multilingual?
With e-mails. I would think it would be best that the messages are sent in the language that the user checks-out in. Now one thing to think about here is when the Admin sends updates to the user (order status change and such), can the admin select that users checkout language? This could be solved on a site that makes them sign up for a profile and has them pick their base language, but on a site that lets people checkout w/out a profile creation, this might be hard. If not in core, I could see an i18n module that creates this option based on a hidden value that gets entered based on the check-out language at the time of check-out.
I think it's important that we try to think about the admin point of view when using the site to manage the orders and users, that his language might not be the same as his customers language, and then from the customer point of view, this being the higher factor because in the end, the customer should not have to work as hard as the site admin.
An easy solution might be to just display the language that was used to checkout, and then give the admin the option to pick which template he uses to update the status. Now as to what language you use for the template of the email, that should be easy as you can just make your own templates.
-Shaun
Some more issues
I would also like to bring up some other issues when it comes to i18n. I have sent these issues to Ryan through email, but I think it would be good to have them here for anyone to look at and get their input.
-Settings-the ability to have settings different based on the sites language is huge, but the major problem now is that the only option for this in 2.0 was to install a module, then once this module was installed, in the settings you need to switch to that language. What might be nice would be tabs or a drop-down (or some other solution) for each language installed which gives you options for that language, but not change your base language. There are many people that run sites in more than one language that do not themselves have the ability to function in that language or they are developing the cart to work for that language.
-Address/Names and the order of other fields-this should be adjustable on a per-language ability. Inside of Japan and a lot of Asian countries, if you display customer info in the Roman character format, then it will display in the western way and that is the correct way, but if you switch the language, then you need to display this in that languages format. So for example,
Japanese:
Roman View:
Company Name
First Name Last Name
Address 1
Address2
City, Prefecture, Postal Code
Japanese View:
Postal Code
Prefecture
Address1
Address2
Company Name
Last Name First name GREET
Also note the ability to add a Greet, this is so important in Japan and other Asian countries. You can’t just print a customer’s name without addressing them right.
The input for fields in forms should also be set per-language.
-Totals/Tax- Some countries make you display the price of products with Tax included by law. This is the law in Japan. If you display a product you must display it with tax included, then you display a smaller price that is without tax. Shipping would not include any tax. I do believe that there are some countries where tax needs to include the price of shipping. Giving more power to order totals, product totals and display would be great power.
-Shaun
Finding the right model for internationalization
I have commented on this in various forums, and hope that my experience can be useful here as well.
The current implementation of translation is simply wrong in D6, and by extension UC (where it exists at all in that module).
A translated node is not a distinct node. This is the fundamental problem with D6, and causes all sorts of problems. A newspaper story about a boat sinking is a newspaper story about a boat sinking in any language. It's not a separate story. The facts are the same, thought the text is different.
The same is true for web sites. A translation is a separate view of the exact same data.
Creating a second product instance in UC, as happens now for a translation, creates havoc with reports, etc. UC correctly links products to SKUs (that's how it works in the retail world in brick and mortar stores), but the system breaks down when you create a second product for the French translation of the description, as now the system doesn't know how to handle the second instance's SKU.
The only correct way to handle this is to create translation tables connected to a single product instance. When I want to see an Italian translation, that text gets loaded up. But everything else, of course, stays the same. I can't think of a use case where the price of a product changes according to user language.
I hope this new module, which is a very exciting development, will get internationalization right, and doing so, inspire a new model for D7 itself.
I think Drupal Commerce may
I think Drupal Commerce may get it right by virtue of the fact that we're using a Product Reference fields to display products for sale through nodes. In other words, no matter how many separate nodes are created as translations of a single node, the reference field will still point to the same product in the product database. We've separated the product data from the display using a separate product entity and will be putting products into Add to Cart forms through this new reference field. No matter what language you view it at, the same product should get added to the cart.
The question to resolve now centers around what text / images should be used to display the product in the cart. Should we pull the translated display node title and an image from the node to display in the cart? Should we enable translation on product titles and always use the product title? Tricky questions...
It's a relief to hear that
It's a relief to hear that separation between data and views have gone into the new system. Great!
Yes, there will be some tricky bits in dealing with individual points, such as default strings, etc. But if we start with a proper model to begin with, we should find that less hoops need jumping through as things develop.
For instance, for your specific questions, the strings (and eventually images?) used to display items will depend on:
- does more than one translation exist?
- does a translation exist in the current user's language?
- is there a default fallback string to display in absence of the above?
But these are already handled by Drupal fairly well.
Aaron, from what you've
Aaron, from what you've posted, it sounds translations still aren't going to be done right, even in D7?
Unless they've changed from
Unless they've changed from the way D6 works, no, they haven't fixed it.
It is a symptom of the broken system that depending on what I want to translate I have to use a different interface, for example.
If I want to translate a node, I need to make a copy of the node and change the values.
If I want to translate a taxonomy name, I have to search for it and translate it in the Translate Interface page.
If I want to translate the strings in a module, I have to make a .po file.
It is unnecessarily difficult and work-intensive to translate for Drupal, and I believe the main culprit is the poor model we've got to deal with. If the model were simply that objects are objects, some of which have properties which may be translated, we'd have a cleaner system framework upon which to build.
Another point is i18n from
Another point is i18n from user input perspective. i18n is mostly discussed from a webapp output perspective. But what about user input ? if we're on a multilingual website when a Japanese person is in-checkout do we store billing information in Japanese ? or do we force it to the default website language ?
I don't think this is an
I don't think this is an issue at all. Drupal/DC will store the user's input as-is.
Even if I am on an English site, if I enter my name in Japanese as 'エンボ', that's what is stored.
Unless I misunderstood what you meant, this is a non-issue :)
You are may be right as i
You are may be right as i have no experience in browsing the web in languages other that the "Latin based ones".
I was just thinking of an example like, when you buy a product from say a website in France, and you enter your billing info in Japenese...site owners might have problems following up on the sale...
Just a thought though !
italian and polish translation
me and my girlfriend, we are italian and polish motherlanguage and we purpose for italian and polish translation
indonesian
I can do Indonesian translation. I'll look into it.