Content fields that don't vary by culture (i.e. have the same value in all cultures)

[Piedone]

By @sebastienros : for some fields it makes sense to have the same value in all cultures of a content item. E.g. the price for an item would be the same regardless of the culture.

With today's localization feature we have a separate content item for each culture with their own independent content, so we should do something about this.

We could implement a solution by synchronizing such fields across cultures:

• Have a content type-level config for all fields like "Don't vary by culture".
• If the fields is configured as such then: 1) we display its editor only on the master content item and 2) when it's changed we overwrite its value under all attached localized items, syncing the values.

[Piedone]

We had something very similar implemented in Musqle @BenedekFarkas @alberthajdu @barthamark

[CSurieux]

Concerning the price exemple, we all see that you are not a sales guy :)

[Piedone]

I was thinking about a place like Quebec or Belgium where you have multiple languages but it's the same market with the same currency (and price) but I agree that there are different cases :-).

[CSurieux]

Yes each country has its own maket rules, see as exemple the pricings Microsoft apply in Europe regarding its pricings in the USA or Asia: it is not simply taking the exchange rate and applying it (the exchange rates vary each minute now), and not only taxes are different, even inside Europe. In the previous cms that I have been using there was only one content for all languages and the texts were adapted according the language with triggers in the sql DB. My intention coming on Orchard had been first to recreate a BodyExpart implementing the same process, it is easy to store one text for each language with a default language when there is no corresponding translation, but I am no more sure it is something compliant with internet url concept and I get used to orchard system and I don't see the exact advantage of one sole content.

[nduarte]

@CSurieux, i have to disagree with you, if you have an Ecommerce website, how are you going to deal with inventories and SKU´s, will they be different for each language? Would you have different inventories for each language? I think this feature is really needed!

[sebastienros]

The beauty of this feature is that if you disagree with it you don't have to use it, and keep translating all the fields.

[nduarte]

@sebastienros et voilá! that´s the vision we need in Orchard! is this feature planned for implementation?

[sebastienros]

Please work on it, it's open for grabs. Should be pretty easy to do.

[sebastienros]

Something that could be done too is to translate per main culture, not sub culture, like fr-FR and fr-CA would have the same value. Again, as an option, default is that all the content items get the same value.

[nduarte]

I´ll give it a shot. next week i´ll have some spare time and start working on that.

[CSurieux]

@nduarte sorry but yes the inventories are different in the reality, even the stock, ask the accounting and the sales guys.

[CSurieux]

In fact in CRMs we have different sales territories, not different countries, this is another full pocket of joins to do in DB.... This is also the reason we often need price lists by territory and time period.

[bleroy]

Right, so sales territory != culture, so how is this impacting the feature?

[CSurieux]

... but you still have to translate. There is a story about a Renault new car in the 80s, its global name was very nice in most countries but in one country it was a kind of insult.... And no problem to have this feature in Orchard

[bleroy]

Of course, but translations are per culture, whereas prices are per territory, no?

[CSurieux]

Prices yes, I would say they are by currencies which may depend of culture, but references, properties ??? the sku was an old notion, it could exist for the factory but became not obvious as a sole value for various populations of buyers ?

[CSurieux]

A car in Europe has not the same price in euro across all the Euro zone.

[bleroy]

So how does this affect the design of this feature?

[CSurieux]

It depends

[sebastienros]

I am sure we can think about the feature to have localization zoning to provide matching cultures. The "Culture" fencing would be one of the default implementations, so that the checkbox Common to all cultures, or continent could be another one so that if the checkbox Common per continent is checked then changing a value would change the same for the ones on the same continent, instead.

[nduarte]

I think that what we really need (for simple and not so simple scenarios) is the _possibility _ of having Content fields that don't vary by culture(if you don´t want, don´t use it). All other complex use cases that Christian is mentioning are done by big companies that usually have diferent regional websites or tenants that deal with all those requirements per region (amazon.co.uk, amazon.fr, pixmania.pt, pixmania.es, etc). I never bought something online on the same site (with several translations) that had different prices or characteristics according to the country you are in (only the taxes and shipping are calculated according to the country the customer is in) I think we should focus on the scope of this feature without over complicating.

[nduarte]

I also believe that "zoning" != translation, they should be separate matters.

[sebastienros]

Sometimes it's not much more complex to make things extensible, while providing the same set of features, just a way for users to implement different ways for things. This is also what makes Orchard great ... I am talking with the heart, you are answering with the mind of the dev who will have to implement this :smile:

[CSurieux]

You know, saleforces and ms crm online are 30$/months (50 in €) and provides all this, even for small companies and now they provide web extensions in their sdk to bring it frontside. In India Zoho is very costless and provides all this. This is real world.

[sebastienros]

Technically, when a field is updated, instead of looking for the other cultures by yourself, you just call another service that gives you what other content items need to be synced. You will provide the other ones from the same content type with this implementation, but @CSurieux could then decide to provide some other service for that. And module developers could come with reusable logics. Not much more complex IMHO.

[nduarte]

Yes! that´s a good aproach, and in the future if someone wants to add diferent logic, just needs to create their own implementation. Nice!

[CSurieux]

Agree. We speak of everything and nothing. Each kind of data could have a different process and links to its neighbors on the end user screen.

[sebastienros]

Just need a way for any component to tell you they are there, and a checkbox will appear for it. The default one being ContentTypeFieldSynchronization which itself will add a checkbox (the editor) using the field events. Don't try to encapsulate the editor yourself as they all could be different.

[nduarte]

Something like we have in the Orchard.Indexing, when you enable Indexing it puts a checkbox in fields definition, i believe we can use same logic implemented on Orchard.Indexing.Settings.EditorEvents

[jersiovic]

Reading the thread I see the solution you propose is to continue having multiple content items (one per culture). What I thing is that approach with multiple content items, multiple taxonomies, and multiple relations between them makes things more complex. Because it drives us to solutions based on syncing values with same content for different cultures/regions. Why multiculture support haven't been implemented per field instead of per content item?. I thing that at least it should exist the possibility of choosing a per field approach. As much as I work with multiculture contents more I think it will be more convenient. Multiple culture autoroute support + a translate token for your labels + taxonomies, with fields and elements with field setting to make them aware of the culture looks a simpler solution than duplicated content items, duplicated taxonomies and duplicated relations with a synchronization mechanism. Instead of duplicate entire content items you can choose which fields support multiple cultures, and all the info wit the different cultures is stored in the same record. What is what I don't see? Do you think this is a wrong way for some reason? Or maybe with current state of Orchard this is a sensible approach?