Multi-culture admin number format issue when switching language

7 meses atrás
Hello, I encountered the following issue.
Steps to reproduce:
- NopCommerce 4.40.3 (but I think 4.40.4 too, since no mentions in release notes).
- Configure 2 languages with different number format, for example, US English and Italian: the first one use a dot as decimal separator, the second one use comma.
- Set the Admin language to Italian.
- Edit a product and set its price to 25,99.
- Leaving the edit page open, go to the public product page (you can do it by clicking Preview button).
- From the public product page switch the language to English, through the Language Selector.
- Go back to the edit page you left open.
- Click "Save" without altering anything.
- Now the price is 2599!!

This happens not only to the price, but to any number with decimals.
This happens because switching language in the public store, makes the language switch on the admin too. When you click "Save", even if you still see the form in Italian (with commas), the language of the current user is English, therefore the admin tries to grab the inputs in English (with dots).
N.B. In the public store of the example, the language is specified in the route (/it/prodotto-1 or /en/product-1), so just navigating to an URL could change admin language unexpectly.

I think Kendo UI localization is a great feature, but it now leads to this kind of problem. Before updating to 4.40, I was using 4.20 and the issue was not present, since the Admin UI culture was always in en-us and it wasn't a big deal since the clients got used to it.

I know that switching between languages might sound weird, but when you edit the description of a product (especially if the description is long and with complex html), you need to be sure that the look and feel is ok for every language, so it's common to switch between languages in public product page to see the result of the edits.


I can see 2 possible solutions:
1) Separate Admin language from public store language, so I can use a different language for each (e.g. admin in Italian and public store in English), so that switching language in public store doesn't affect current language in admin. Or, at least, offer the chance to set a unique culture for the Admin like it was before.
2) Include the current culture as an hidden field of the forms and use it in ModelBinding (maybe more invasive, but more effective).

Thank you all for the long reading!
7 meses atrás
Different language for Admin area is a long running conversation in nopCommerce!
Thanks for pick it up again, hope nopCommerce team will check it.
https://www.nopcommerce.com/en/boards/topic/66117/suggestion-different-language-for-admin-area#235745
matteo.melli wrote:
1) Separate Admin language from public store language, so I can use a different language for each (e.g. admin in Italian and public store in English), so that switching language in public store doesn't affect current language in admin. Or, at least, offer the chance to set a unique culture for the Admin like it was before.

This is a nice suggestion, if you want you may try this until nopCommerce come up with solution. https://www.nopcommerce.com/en/boards/topic/17562/multi-language-admin-area#243246
7 meses atrás
I see, but before 4.40 it was only a little more than a hassle.
Now it can leads to unexpected behavior, so it's more than that.
It can change prices, weights or other data without even be aware of it.

I told my clients to use different accounts, in different browser sessions, for the admin panel and for testing the page, but it can be annoying since the previous version did not have this need and I have to justify to them.
7 meses atrás
This has already been discussed (here is a work item). We've decided not to implement this functionality out of the box. You can add your comments to this issue, perhaps we'll reopen it.
3 meses atrás
Hello Romanov,

has this issue been addressed in the latest releases?

I mean,  the chance to have different language for Admin and Public store is only a suggestion, but I don't really need it for its own sake.

The real issue is the misinterpretation of the numbers in the Admin panel,  so if it has been addresses in some other way it's ok.

Thank you.