Product prices based on front-end language

[Genius WebDesign]

Hello,

I´ve been working and trying to figure out a way to use the multiple pricing system in Virtuemart to show prices that are specific according to the front-end language.

As it stands right now the only ways to differentiate prices, are by shopper groups, publishing date intervals and stock availability.
My initial thought was to use the shopper group system, but here we have a problem because guest users will always only have 1 specific default shopper group.
And the shopper group for the front-end user is stored in DB (if you are a logged user ofc..)  - not in session, so it´s basically only useful for registered users in regards to product price differentiation.

Virtuemart already have a good currency selector module that works fine for what it does. The problem here is that shop owners often want to be able to show "pretty" prices for their products, and with the currency converter you will always get a some what nasty looking number with decimals when converted.
Further more the order price will always be that of the shop default currency.

There are 2 obvious ways to fix this problem.

1. The core product pricing system is expanded with a select box where you choose front-end language for the price, here the first option should be "All languages".
Much the same way as with the shopper group select box that you see in the product price section.
So. if you for example create a new product price and select "da-DK" as front-end language for that price, the price should only be visible in front-end when the language is da-DK.
Ofc. you could make this as a multi select box, where you can select more than 1 language, which should then result in an array of data.
In any case you would need to modify the core calculation helper in order to integrate this functionality.
In other words, this feature will not be possible to achieve without hacking the core VM.

2. The shopper group system is modified in a way that guest users (non-logged users) can be assigned to a specific shopper group depending on the front-end language.
This would require that the shopper group information is stored solely in session and not i DB.
This feature will of course not be possible to achieve without hacking the core VM.

When all is said and done, what I´m (my client) is looking for is not possible in the current state of Virtuemart.
The question is, is this something the VM developers would consider implementing in a later version of VM?
If so, I would be more than happy to help out programming this feature.

[lindapowers]

A customer can be watching a website in their native language from a different location (something very common) so if you base prices on languages it does not make much sense.

Shopper groups for prices seems correct logic and languages for what they are meant to... displaying content seems quite "standard" logic.

What you call "show prices that are specific according to the front-end language." is too generic cause as mentioned front end language doesn't have to be directly related to the currency or bill to location.

Maybe Im not understanding your logic (or the one of your customer) completely but in general prices per front end language dont make much sense to me.

[Genius WebDesign]

What you call "show prices that are specific according to the front-end language." is too generic cause as mentioned front end language doesn't have to be directly related to the currency or shipping location.

I may have been unclear about what I meant by "front-end language".
By "front-end language" I mean the language that is loaded in the Joomla framework in front-end.
This is not necessarily the same language as that of the visitor´s browser.

[Genius WebDesign]

Regarding whether it makes sense or not, well in my client´s case it does make alot of sense.

He has a Danish webshop, and for all the danish customers he wants to show prices in Danish currency (DKK), and for all other customers he wants to show prices in EUR.
In front-end the customers can choose between 3 languages; Danish, German and English.

When the customer chooses either German or English, the prices should be shown in EUR, otherwise the prices should be shown in DKK.
Right now I have made a quick solution where I trigger form submission of a hidden instance of the currency module, according to what currency should be loaded for the current front-end language loaded in framework.
And this works well.
The problem is that my client wants to have complete control over the price that is being shown in both EUR and DKK.

Let´s say he has a product that costs 249,- DKK - this is a pretty number.
If you convert this number using the currency converter, it will result in something like, 33.49 EUR - this is not a pretty number.
In this case my client wants to manually create a price in EUR that is i.e. 34,- EUR, which is a prettier number.

So, in my client´s case it makes perfect sense if he could create a product price with currency EUR particularly for front-end language "en-GB" and "de-DE", and a product price in DKK for front-end language "da-DK".

[GJC Web Design]

he he .. probably not the discussion you wanted to start but i tend to agree with LP

As a native english speaker living in a small EU country but often shopping in the UK or Germany online I  don't want to be told what currency/language to browse in.
And when it does happen (UK sites redirected to French etc) it is only annoying - not helpful...

But I do follow your wish to have "nicely rounded" prices when currencies are changed ..

BTW it is possible to switch currencies on lang or geo choice as on https://www.quality-tuning.eu/gb/

[Genius WebDesign]

Please read my latest reply..

[GJC Web Design]

yes .. our posts crossed... 

but still think you would annoy me off as e.g. if i lived in DK .. resolutely refused to learn the language but want to browse and shop in Krone.. 
esp. if I couldn't get the combination i wanted

The assumption that as I don't choose DK means I'm not in Denmark etc. IMHO is less and less valid these days

but still see the idea of "nice rounding" as justified..  was a while ago but i did do something with the "Use the Rappenrundung for Swiss CHF" to provide rounded prices for a client wanting all xx.00 or xx.50

[lindapowers]

About the rounding I understand you, actually we started that way but it ended up being such a nightmare we surrender to decimals.

Payments fees, shipping costs, product prices, custom fields with additional costs etc etc it was simply impossible to keep those "nice" rounded numbers in all situations.

And about your main issue sorry but I agree with GJC in his example...

[Genius WebDesign]

but still think you would annoy me off as e.g. if i lived in DK .. resolutely refused to learn the language but want to browse and shop in Krone.. 
esp. if I couldn't get the combination i wanted

The assumption that as I don't choose DK means I'm not in Denmark etc. IMHO is less and less valid these days

but still see the idea of "nice rounding" as justified..  was a while ago but i did do something with the "Use the Rappenrundung for Swiss CHF" to provide rounded prices for a client wanting all xx.00 or xx.50

Yes, I understand your point, and technically you are correct, at least to a degree.
In some rare cases you will have visitors that only understand English or German but for some reason want prices shown in DKK.
However, I would argue that this only apply to a very small percentage of the total visitors.
In the end it is technically valid and legal for a shop-owner to "decide" for the visitor which currency is shown for which language.

[Genius WebDesign]

About the rounding I understand you, actually we started that way but it ended up being such a nightmare we surrender to decimals.

Payments fees, shipping costs, product prices, custom fields with additional costs etc etc it was simply impossible to keep those "nice" rounded numbers in all situations.

And about your main issue sorry but I agree with GJC in his example...

I would imagine
The thing is, this is not something that would be solved simply by some rounding rule.
The goal for my client is to have full control over product prices.

Say we have a product price in DKK that is 129,-
In EUR this would become close to: 17,35 EUR by conversion.
Now, I think most shop owners would agree that 17,35 is not a pretty number.
The problem is that the definition of a pretty number may vary from shop-owner to shop-owner.
One shop-owner may think that 17,- EUR would be "prettiest" for this product, while another would say that 19,- EUR is prettier.
Deciding what price is most "sales-friendly" in a particular currency is more often than not a political decision. It is not just a matter of raw price value conversion.
That is my argument for even considering the need for having more specific product prices.

[lindapowers]

About the rounding I understand you, actually we started that way but it ended up being such a nightmare we surrender to decimals.

Payments fees, shipping costs, product prices, custom fields with additional costs etc etc it was simply impossible to keep those "nice" rounded numbers in all situations.

And about your main issue sorry but I agree with GJC in his example...

I would imagine
The thing is, this is not something that would be solved simply by some rounding rule.
The goal for my client is to have full control over product prices.

Say we have a product price in DKK that is 129,-
In EUR this would become close to: 17,35 EUR by conversion.
Now, I think most shop owners would agree that 17,35 is not a pretty number.
The problem is that the definition of a pretty number may vary from shop-owner to shop-owner.
One shop-owner may think that 17,- EUR would be "prettiest" for this product, while another would say that 19,- EUR is prettier.
Deciding what price is most "sales-friendly" in a particular currency is more often than not a political decision. It is not just a matter of raw price value conversion.
That is my argument for even considering the need for having more specific product prices.

I change my mind over the years, I was "obsessed" to use rounded "pretty" numbers and nowadays 2 decimals seems pretty nice number to me and you avoid a lot of headaches and work.
Even in legal terms I consider it much safer.

[Genius WebDesign]

I change my mind over the years, I was "obsessed" to use rounded "pretty" numbers and nowadays 2 decimals seems pretty nice number to me and you avoid a lot of headaches and work.
Even in legal terms I consider it much safer.

Yes, I understand where you´re coming from.
I feel the same way, and if it were up to me (from a purely professional viewpoint) I would prefer to just use the currency converter.
However, as it is with most development project, we are bound to the needs and demands of our clients.

[Milbo]

You should use the product prices per currency and use the hidden config to use the price of the selected currency. Then the prices are used by the currency, which is imoh what you really need.

You can then set the currency automatically by using for example our localiser http://extensions.virtuemart.net/shopper-order/orders/vm-localise-detail

The currency part is not really written yet, the problem is the config, but it is easy to add it. There is already a commented example inside.

[Genius WebDesign]

You should use the product prices per currency and use the hidden config to use the price of the selected currency. Then the prices are used by the currency, which is imoh what you really need.

You can then set the currency automatically by using for example our localiser http://extensions.virtuemart.net/shopper-order/orders/vm-localise-detail

The currency part is not really written yet, the problem is the config, but it is easy to add it. There is already a commented example inside.

Milbo to the rescue!!!

Are you telling me that it´s actually possible to set price per currency as a configuration to a product price?
I don´t know how I missed it...

Can you show me where I enable this in VM administration?
Do I need to hack the core..?

In this particular project it is important that we at all times have the latest version of VM and Joomla installed, so core hacking is not an option.

[Milbo]

https://docs.virtuemart.net/manual/general-concepts/206-hidden-configurations.html

param name pricesbyCurrency