Showing results for 
Search instead for 
Did you mean: 

Localisation and Internationalisation request

Localisation and Internationalisation request

Feature request from mikebranderhorst, posted on GitHub Feb 13, 2013

Apple, Dell, Microsoft all do the same as Magento (or the other way around ;-). But did you ever experience how hard it is to order a product living in a country if you do not speak nor read the foreign language? Apple for example, if you live in the Netherlands but cannot read Dutch how do you order? It must go through which is Dutch. If you want to select English it is not possible to deliver to an address in The Netherlands. Now my feature request is to add an extra scope, named Language scope. If you add for example a product, translate it in multiple languages regardless of Store View scope. The Store View scope has a language and just picks the right translated product but a customer can stay on the Netherlands store but order everything in English or German or whatever.

Read my comments in this blog post.


We have a:

  • Store A (.nl) Netherlands (Dutch is main language, German and English)
  • Store B (.de) Germany (German is main language, Dutch and English)
  • Store C (.eu) Europe (English is main language, Dutch and German)

Future: .be, .it, .se etc.

All shops share the same products, different prices, different static content and ! 3 languages. Currently it is difficult to get a internationalisation scope in a localized store.

A German store != the store of Germany. The store in the Netherlands could also be translated in German but is not the same as the German text on the store of Germany.

How I see this in practice:

Product: When you add a product you have a Global scope product with multiple translations, not only text but also metadata, url, title pictures etc. Then when you add a product to a store view it gets automatically the language of that store view.

Static content: This could be Global text in multiple languages or Website scope text in multiple languages. For example a Contact of Return policy page could be translated in say three languages but is for Store A, B and C not the same. But other pages could be the same in all Store A, B, C.


(.nl) Store A - Netherlands - Dutch (main) Store A - Netherlands - German Store A - Netherlands - English

(.de) Store B - Germany - German (main) Store B - Germany - Dutch Store B - Germany - English

(.eu) Store C - Europe - English (main) Store C - Europe - Dutch Store C - Europe - German

Now, when I add a product, I should choose to make it global or assign it only to a country (website scope). I translate the product in multiple languages with English as fallback. When a customer visits the Store A but does not speaks Dutch and selects English he/she is still on Store A. Why not Store C? Store C has different content (maybe also theme) and different regulations (tax, law, delivery regulations, etc.)

New Member
Status changed to: Investigating
New Member

Comment from Vedrillan, posted on GitHub Feb 13, 2013

Store views can already be used that way x)

You can go like that:

  • Website Nederlands
    • store view NL
    • store view EN

Then select the right locale for each store.

Your products are link to websites, not stores. So you have the same catalog for the whole website but different languages depending of the store view.

In the end websites are country, stores are languages.

New Member

Comment from mikebranderhorst, posted on GitHub Feb 13, 2013

That is true, but if you have a textual change in for example Dutch you have to change it three ! times. For Netherlands, Germany and Europe. We actually have one more dimension, which means one Dutch change in a product or static page means nine ! of the exact same changes:

3 dimensions, 3 countries a dimension and 3 languages a country. In practice most of the products are the same for all 9 Website scopes (country level). Magento is build to have one default so we use English to default, but all other languages has to change 9 times every change. If you have one extra scope a Product/Content Language scope it is possible to assign the same lingual settings for each language. Optionally this could be overwritten by a Website scope or Store View scope. See our current configuration en try to understand what I mean:

( Dimension A - Netherlands - Dutch Dimension A - Netherlands - German Dimension A - Netherlands - English

( Dimension A - Germany - German Dimension A - Germany - Dutch Dimension A - Germany - English

( Dimension A - Europe - English Dimension A - Europe - Dutch Dimension A - Europe - German

( Dimension B - Netherlands - Dutch Dimension B - Netherlands - German Dimension B - Netherlands - English

( Dimension B - Germany - German Dimension B - Germany - Dutch Dimension B - Germany - English

( Dimension B - Europe - English Dimension B - Europe - Dutch Dimension B - Europe - German

( Dimension C - Netherlands - Dutch Dimension C - Netherlands - German Dimension C - Netherlands - English

( Dimension C - Germany - German Dimension C - Germany - Dutch Dimension C - Germany - English

( Dimension C - Europe - English Dimension C - Europe - Dutch Dimension C - Europe - German

New Member

Comment from paales, posted on GitHub Feb 14, 2013

I think the undertaking would be to large to add another level to the multistore setup for it to be included in the 2.0 upgrade. An alternative would be an option 'apply to all dutch storeviews' setting or something.

New Member

Comment from FiveDigital, posted on GitHub Feb 15, 2013

+1 for that! We often run into this problem too. Something like StoreView inheritance (for product data) could be an idea. Right now, every StoreView falls back to the default StoreView. In the example of @mikebranderhorst the StoreView "Dimension A - Germany - German" should fall back to "Dimension A - Netherlands - German" and so on. But this could also have side effects. Another idea is to have another option besides "use default" for the attributes: "use specific StoreView".

New Member

Comment from floplus, posted on GitHub Feb 15, 2013


New Member

Comment from mikebranderhorst, posted on GitHub Feb 15, 2013

A fallback method like @FiveDigital suggested could be a quick method but better is to do this for example when adding a product: When you add a product you should (on a multilingual site) add also extra translations for all ! fields including url and metadata. The translation of a product has at first nothing to do with a Website or Store View besides the language link. So for a new product I see the following flow:

  1. add a new product
  2. translate this product to multiple languages
  3. define the fallback language (default is the language at step 1)
  4. add the new product to a Dimension or Website (or optionally specific Store View) A Store View has a language, this language is used for the product and falls back to the fallback...
  5. optionally edit product fields for that specific store (like it is currently done in Magento)

As you can see the translation is done at product scope and not at website or store view scope. This is how it should be. The translation has nothing to do with the website or store regarding the language. But you could for example for a German Store View change the title or whatever like it is done now.

This product example could also be used for static cms pages. The translation is done at page scope not website or store view scope (again optionally you could).

What to think about emails? For example, all Dutch Order Confirmation emails are the same except maybe the color, logo, contact info etc. Again, here it would be nice: If you add an email template you also translate these but easily change this at Store View scope.

New Member

Comment from magento-team, posted on GitHub Feb 16, 2013

Hello. Thanks for the valuable feedback. The language management definitely could be improved and we want to take care of it but it is not on our short term roadmap. Sharing languages across stores or language inheritance would help a lot. That being said we encourage you to try to implement it - however it might get pretty big.

New Member

Comment from FiveDigital, posted on GitHub Feb 18, 2013

An approach may be to have the possibility to define an attribute as for instance "textual". Such textual attributes can be entered in every locale (used in the shop) in the default StoreView. Every attribute in the StoreView that uses the German locale and has "use default" checked would fall back to the default StoreView but to the value of the according locale.

New Member

Comment from verklov, posted on GitHub Jan 13, 2015

Thank you for this request! ID: MAGETWO-32658