Lava Behaves Differently In Different Cultures

[trydyingtolive]

Description

ASP.NET's internationalization seems to cause lava to behave in unpredictable ways. This is particularly problematic for our missionaries and ministry partners over seas. Because these have to do with dates and numbers, the importance of accuracy is imperative. Additionally, adding caching makes tracking down the actual cause more difficult.

en-GB (and other countries) use the date format 'day/month/year' which means two different people can parse the same string as a date different ways. As long as the date stays as a DateTime things are fine, but string are parsed by lava differently in different countries. This is nice for displaying appropriate text for the reader, but not for getting accurate data.

de-DE (and other countries) switch the use of periods and comas in numbers (1,000.5 vs 1.000,5) This means that the behaviour of non-integer numbers is different in different cultures. Even when the lava developer writes a non-integer (as opposed to a number in a string), the lava parser will interpret the number based on the users culture. This causes interesting and unexpected behaviours.

Steps to Reproduce

Set your browser to render webpages using en-GB (United Kingdom) for dates and de-DE (Germany) for numbers

{% assign testDate = '01/02/2020' %}
{{ testDate | Date:'MMM d' }}			Expected: Jan 2 en-GB: Feb 1

{% assign onepointfive = '1.5' %}
AsInteger: {{ onepointfive | AsInteger }}            Expected: 1 	de-DE: 15
AsDecimal: {{ onepointfive | AsDecimal }}            Expected: 1.5 	de-DE: 15
AsDouble: {{ onepointfive | AsDouble }}              Expected: 1.5 	de-DE: 15
Ceiling: {{ onepointfive | Ceiling  }}               Expected: 2 	de-DE: 15
Floor: {{ onepointfive | Floor  }}                   Expected: 1 	de-DE: 15
Times:  {{ onepointfive | Times:onepointfive  }}     Expected: 2.25 de-DE: 225
Times: {{ 1 | Times: '.1' }}                         Expected: 0.1 	de-DE:  Liquid error: Unable to cast object of type 'System.Int32' to type 'System.String'.
DividedBy: {{ onepointfive | DividedBy:1  }}         Expected: 1.5 	de-DE: 15
DividedBy: {{ 1 | DividedBy:onepointfive  }}         Expected: 0.67 de-DE: 0,07
Lava Parsing: {{ 1.5 | Plus: 1 }}                    Expected: 2.5 	de-DE: 16

I have tested this on all the environments I can get my hands on and confirmed the expected and incorrect values..

Versions

• Rock Version: All?
• Client Culture Setting: other than en-US

[cabal95]

Isn't Lava run on the server where it should just have the single culture defined? How would something that runs on the server be affected by a browser's culture setting? (not saying you are wrong, just not understanding how that could be happening)

[trydyingtolive]

You would think that would be the case. Here is a concise overview of what is happening: https://stackoverflow.com/a/8681657 Basically .NET Framework knows the client's culture and unless do your parsing and formatting with the Culture.Invariant flag its all done culturally. It's doubly difficult because sometimes you might want to parse according to the client's culture and other times you need to not.

[cabal95]

oh wow. That would explain some random culture issues in chat that we could never figure out.

[nairdo]

This is interesting because the meaning of the input data is drastically different from US to DE (for example) depending on whether you write "1.5" or "1,5".

In other words, if I correctly write the input as "1,5" (for de-DE) and then run the lava (using a browser culture settings of de-DE), the output is correct (Lava produces the expected result):

{% assign onepointfive = '1,5' %}
Times: {{ onepointfive | Times:onepointfive  }}   Results in the expected: 2,25

Same for these as well... The input data needs to match the culture/context:

Times: {{ 1 | Times: ',1' }}                      Results in the expected: 0,1
Lava Parsing: {{ 1,5 | Plus: 1 }}                 Results in the expected: 2,5

So, without changing the input data (the data being passed to Lava) we can't really say to much about Lava's responsibility... unless we're proposing that all Lava [text] input and output must be done in en-US formatting).

[Stevenlmiori]

Hello @nairdo - Any update here? We have a large Spanish congregation and it is causing major issues for them. We are charging $8.00 for an event, and it's changing to $8,00 (error).

[hendrixjt]

We're having this issue for our Spanish speaking people. Any advancements with the issue at this point or suggestions?

[nairdo]

We have not forgotten about this, but we have not been working on this recently as we've been working on other issues. As I eluded to above, there are a variety of situations involving Lava in many different cases. So I think it would be helpful if each of you would identify the exact situation and configuration** that is causing your particular issue.

_{**The more detail you can supply, the better it will be for us to try to identify a solution to each situation.}

[Stevenlmiori]

We have not forgotten about this, but we have not been working on this recently as we've been working on other issues. As I eluded to above, there are a variety of situations involving Lava in many different cases. So I think it would be helpful if each of you would identify the exact situation and configuration** that is causing your particular issue.

**The more detail you can supply, the better it will be for us to try to identify a solution to each situation.

Thanks @nairdo - The exact problem we are experiencing is not from using lava (I don't think). If you change your device's system language (I tried this on my mac), and go to our event registration: https://rock.cfbc.org/page/1218?RegistrationInstanceId=560&EventOccurrenceID=532 you'll see that the $8.00 is changed to $8,00 ..This makes it impossible to pay, and results in an error. This is pretty big problem for us because we have a large Spanish-speaking congregation. Any help you can give would be much appreciated.

[cfunkdev]

Hi Spark team, has there been any movement on this. We are in a season where we are doing several conferences for our Spanish speaking campuses and it is impacting their attenders ability to register for events pretty hard. Any update on the progress of this bug would be greatly appreciated and or a workaround would be greatly apprecatied.

So far we have tried wrapping the registration block in a div with a translation=no attribute but it is far from a good solution and we are still hearing of issues.

[nairdo]

Hi Spark team, has there been any movement on this.

The exact problem we are experiencing is not from using lava

@cfunkdev & @Stevenlmiori This one is a very non-trivial problem and there is no clear solution. But since you're describing a problem not with Lava but with something else, can you clarify?

For your situation, are you having an internationalization problem with payments and the Registration Entry block? If so, can you tell me if the problem occurs regardless of using the legacy Registration Entry (webforms) block or the Registration Entry 🎉 (Obsidian) block?

_{[screenshot shows Client Culture Setting: de-DE while using the webforms and Obsidian version of the Registration Entry block]}