Negative values have the minus sign to the right of the value in RTL languages

[jessegreenberg]

The problem was originally noticed in phetsims/trig-tour#149.

It should read "rads -0.524"

The fix was to wrap the value with StringUtils.wrapLTR.

In phetsims/qa#1212, QA confirmed that it is a general problem and we likely need a general solution.

[marlitas]

JO: Perhaps we should be wrapping all numbers in pattern strings with StringUtils.wrapLTR
MK: I feel like RTL testing should be more robust to catch this type of thing earlier.
MS: It would be nice if this was something we could test for in the dev process as well.
JG: Is this a more general issue than just PhET? Should we be reaching out to browsers about this?
JB: I don't think this is dependent on the browser.
JO: We should use localization dependent formatting for this issue. There is a broader conversation here about number formatting in general. API example
MK: This seems related to work that JO and I are currently on: phetsims/chipper#1332

MS: This feels like a larger conversation that would be helpful to split off into a subgroup.

More discussion and investigation is needed before we can move forward on an implementation strategy and have an estimate on dev effort.

[jonathanolson]

Also an issue in FAMB Motion screen, locale ar_MA.

[jonathanolson]

Also Hookes' Law

[jbphet]

Also the currently live version of Greenhouse Effect (v1.3.5) (locale = ar_SA):

[jbphet]

This is also seen in the currently live version of Number Line: Operations (v1.1.6, locale = ar_SA):

[jbphet]

I had a conversation with ChatGPT about this, because I wanted to make sure that our assumption that the minus sign should be shown on the left is correct. Long story short: Yes, the minus sign should be on the left. I wanted to note a couple of things about this conversation though.

I asked it to correctly render the phrase "The value = -5.432" in Arabic. It said a number of things, but this was its conclusion:

Notice that is says the minus sign should be on the left, but it rendered it on the right. Clearly it's challenging to get this right. When I pointed this out, it acknowledged the mistake, and said it was a problem with the rendering environment. It said to get it right in our code, we might have to create LTR "islands", which is essentially what we've done. It then gave me this little bit of HTML:

<span dir="rtl">النتيجة = <span dir="ltr">-5.432</span></span>

When I put this in an HTML document, I see this:

Overall I think this bolsters the case for embedding our numbers in LTR "islands".

[jbphet]

In essence, what @jonathanolson and I have done here is:

• In PatternStringProperty, if a supplied value is a number (determined by typeof), wrap it in LTR embedding marks when converting it to a string
• Add a function to StringUtils called toFixedSafe that embeds the string for a number in LTR for cases where the sim code does the number-to-string conversion