Describe the bug
When submitting a negative price impact on combination and save the product, everything works as it should. When you reload the page and go back to edit the product again, it will cause an error because of the negative price-impact.
I think it has something to do with decimals or the "minus"-character stored in DB after save.
To Reproduce
Steps to reproduce the behavior:
Screenshots
If applicable, add screenshots or screenrecords to help explain your problem.
Additionnal information
Tested on: PrestaShop version: 1.7.4.4 and 1.7.5.0
PHP version: 7.2
It will work if the javascript event change is fired for the input boxes of the price.
So if there is a negative value, the change event needs to fire for the product to be able to save.
Hi @joelprestaworks,
I did not manage to reproduce the issue with PS1.7.4.4 / PS1.7.5.0. PHP7.2.13.
I attached a video record.
https://drive.google.com/file/d/1FEywEvb1Y3pzgQ9UpuOznW9EDU_bos0f/view
Could you please provide us with more info? We need more details to understand how we can reproduce your issue:
Don't you know how to get this information? Please read the following article:
http://build.prestashop.com/howtos/misc/how-to-create-bug-report/
Thanks!
Hi Khouloud,
I think you did it wrong when watching your video, it's not necessary that you look in FO, the issue is only related in BO.
I forgot to mention that we're using Swedish as language in our environment, could it be something related to that?
You can see the error in this video:
https://www.useloom.com/share/05161efbbc1b4c8299cac8d1b19b2dc7
I can now confirm that this specific issue is related to languages!
I just changed the language for my employee-account to English and the error is gone!
Something is wrong with the Swedish language pack that is used in PS 1.7.x, it's the Swedish language who cause the issue!
More information;
We think that there is some issue in main--sv-SE--currencies generated under translations/cldr/ something is totally wrong and when looking in the compiled file above the chars does not get built the same as in e.g. main--en-US--numbers.
Probably the main issue is located under translations/datas/main/sv-SE/numbers.json
However we don't know exactly the issue, since this Swedish package is totally downloaded from PrestaShop translations server.
Hi @joelprestaworks,
Thanks for this clarifications.
I manage to reproduce the issue with PS1.7.5.0 / PS1.7.4.4 when I change the language of the employee to Swedish
https://drive.google.com/file/d/1rSPjxuWPIIgJiuifGum6f_NRlRoTTyxu/view
We will see how to fix it.
Thanks!
@khouloudbelguith
This seems random, I can reproduce it only once
https://drive.google.com/file/d/17UG9yIhnQ7ZnQ4XM6AoC3f-0rn0M2l0e/view?usp=sharing
Hi marionf,
You're not doing it correct. It will work as long as you do it the first time. After editing the product with negative price impact the first time, and then go back (reloading the page) to edit the product again, you will get error if you try to just save the product without doing any new changes to it.
We're pretty sure that there is errors in this file: translations/datas/main/sv-SE/numbers.json that generates: translations/cldr/main--sv-SE--numbers
Hi, can we please have someone try to fix this? currently it is not possible to save products that have combinations with a negative price impact in the BO for swedish users. It's not a minor issue, it's a major issue.
Hi @joelprestaworks,
This issue is added this to the debug roadmap so that it’s fixed. If you have already fixed it on your end or if you think you can do it, please do send us a pull request!
PrestaShop is an open source project, so it can be solved before if someone submits a pull request to solve it.
Thanks!
Hi Khouloud,
the issue is in the swedish translation pack.
there is a
−
instead of a
-
numbers.json
"minusSign": "−"
should be
"minusSign": "-"
I don't think that changing CLDR files would be the right way of fixing this bug. We should stop localizing numbers in form fields using CLDR because browsers have a very hard time handling different formats, this is only an example of that. Arabic numbers, different symbols for decimal and thousand grouping, minus and plus sign, it's a mess.
What do you think @colinegin ?
So while you wait for discussing the changes on the method, are you going to change the bad char in the file so it will atleast work in Sweden?
It's not a "bad character". Those files are based on the official CLDR data, which means that that character is the one the Unicode consortium understands as the standard negative character for negative numbers for the Swedish locale.
The actual problem here is not that sign, but using numbers formatted according to the current locale in form fields. While it _looks_ nice, it doesn't work because it would require being able to interpret them on interaction and when the form is saved, which is a whole different business than writing them.
My opinion is that we should stop formatting numbers in form fields, and we should use number formatting for display only, like in tables and in the front office.
Editing CLDR files is a Very Bad Idea. While it is a valid workaround in production shops, it will stop working once those files are updated in a later release of CLDR. The real fix will be done when the Product page is re-migrated in 1.7.7 or 1.7.8.
Also, be aware that CLDR files have been replaced by a newer version in 1.7.6, but it still uses the same negative sign character in SV.
Looks like with Estonian language there is same issue on 1.7.6.3. How it can be fixed?
@monas You can work around this problem by finding this file, then change the minus sign to this character: -
The product page is going to be reworked in 1.7.8, and among other things it will avoid formatting in form fields to prevent this kind of problems.
@eternoendless do I need to do some other actions after this change? It doesn't help. I have three languages enabled - ET, LT and RU. Made changes to ET and LT. RU version was with correct - sign but wit some extra options (<minusSign draft="contributed">-</minusSign>). I have cleared the cache but it didn't helped too. Maybe the problem is somewhere else? This is what debug profiles shows:
