Hi,

The answer is ... no. Prices depend on markets, not language branches. Except when your markets match with your language branches, there is no easy way to do this.

Regards.

/Q

Hi

This can be achieved by providing your own implementation for the Commerce Interface, ICurrentMarket.

In your implementation of ICurrentMarket, lookup the currently active Content Language and use its value to select a suitable market from the list of declared Commerce Markets.

This will ensure that when any Prices are searched for then the returned Price(s) selection is influenced by (or linked to) the current active Content Language.

Hope this helps.

M

I'm sorry to say I cannot recommend Martin's approach. Please note that many parts of ECF system rely on ICurrentMarket to know what's the current market, so determine current market by current active content language might cause those parts to be un-predictable.

The custom implemetation of this interface should only customize the way you want to set/get the current market (profile, cookie,...).

Regards.

/Q

@Quan

We are in violent agreement, I think and sincerely hope  :}

ICurrentMarket is there to allow an Implementer to encode business rules as to which Market is current, whether that be via a selector on the Visitor Website as per the Commerce Sample Site, or something else that is reliably determinable, e.g. cookie, host header. I think we both agree on that.

If the business rule is "when the requested content language for the Visitor is German, use the Market place with MarketId == 'german'" then that ought to be possible and appropriate to enact the rule via the implementation of ICurrentMarket. It is precisley because the rest of ECF uses ICurrentMarket to discover what the desired Current Market is, which makes ICurrentMarket useful, significant and relevant. Of course it is true to say that other aspects need to be addressed in terms of the Visitor experience to ensure that a business rule couched in such terms is itself reliable, predictable and understandable; but that was not the question that was asked.

Or, are you saying that the determination of the Current Active Content Language via the EPiServer Globalization Framework is unreliable in the context of all possible clients/callers of ICurrentMarket?

If you are, I would be very interested to know which parts of the EPiServer Commerce Framework cannot or do not reliably interact with EPiServer Globalization support.

Hi,

Let's consider a simple situation. Both market A and B has language L as default language. Then what should be the current market if user has content language as L? Note that different market then cause different availabilities, prices, promotions and so on.

I'm not saying your approach is wrong. It might be helpful in a very specific case. But from framework's perspective, we always encorage partners to use well-defined, recommeded approach, which should fit on majority of cases. That's why I cannot recommend that approach to another partner, as it's far from what ICurrentMarket intended to be.

Besides of that, we always welcome feedbacks and suggestions, with the hope of building better EPiServer Products. But once again, the suggestions should fit for a Framework and benefit a majority of customers.

Best regards.

/Q

@Quan

Thank you for the qualification. We are, as I hoped and suspected, both in agreement.

@Aliaksandr Bialinski:

Having prices by language is an unusual request, and we would recommend to avoid it. Our suggestion is to utilize the market system, which provide great flexibilities and customazion for EPiServer Commerce.

But, if, for some reasons, you MUST use language to determine prices, then here some of my personal suggestions:

- If you have a well-defined, conflict-free sets of languages and markets, or you do not use market concept at all, you can create markets with the marketid is the language codes. Then after that, you can use this (pseudo-code)

var marketService = ServiceLocator.Current.GetInstance<IMarketService>() 

var market = marketService.GetMarket(language.Name); //language.Name should be something "en", and you have a market with marketid is "en"

//get price by market

- Another approach is to use SaleCode. You can set price by sale code, specified by language code.

Either way is nature to EPiServer Commerce and I would like to re-emphasize that you should use the market system other than any of above approach.

Regards.

/Q