simonpoole/OpeningHoursFragment

Digits change to Perso-Arabic form and cause error

Closed this issue · 7 comments

Device language: Persian
Android: 7.1.1
Vespucci: 14.1

Steps to reproduce:

Add an opening_hours tag:

Switch to properties tab, digits are in Perso-Arabic form:

by trying to add a new rule this error occurs:

Interesting. This is not something we are actively doing, and it is no surprise that it causes errors, because the actual values (as in those which are used in the tags vs what is displayed) should always be using Arabic numbers.

I'll try and find out what is going wrong.

Could you be any chance give me the original OH string that was used?

In any case it seems that what is causing problems is when a change is made directly to the OH string instead of via the form, parsing the perso-arabic digits fails (which is no surprise).

Right now I suspect that the problem is cause by using the default locale somewhere instead of forcing en-US.

Yes, I can confirm that when formating numbers we need to force Locale.US.

Right now I suspect that the problem is cause by using the default locale somewhere instead of forcing en-US.

That's right. you should have device language set to Persian.

Could you be any chance give me the original OH string that was used?

It was a random value selected from the menu, for example I also tried this one:
08:30-12:30,15:30-20:00

When I switch to the properties tab this value is present there:
۰۸:۳۰-۱۲:۳۰,۱۵:۳۰-۲۰:۰۰
Which uses Persian digits.

And when I try adding new rule an error occurs.

Without modifying value via properties tab, if I go back to the details tab, I see original value "08:30-12:30,15:30-20:00".

Fixed in simonpoole/OpeningHoursParser@57d8f32 Thanks for the report.

Just from a further i18n point of view:

  • currently the time selection sliders are not reversed in RTL mode, it is not quite clear if that is what would be expected.
  • would Perso-Arabic digits be expected on the sliders and other UI elements?
  1. Currently I see no problem with that being LTR.

  2. It depends. For example in the 3rd image above, the top bar contains English week names and Farsi digits. From my understanding, this row aims to directly display the value generated by ui in raw (?). So would be better to remain as the original value, i.e. English digits and English week names (because there is no approved localized version of OH). In other places such as lables on slider handles it could be localized version of digits.

I would review these on the next release of Vespucci, as I completed the Persian translation and the localized version may give a better point of view.

About first one, my opinion is same.

About the digits in UI, if there is no chance that a user need to interact with that number (e.g. copy-pasting, esp. here on small touch devices and small keyboard) there is no problem, but it could cause some difficulties the other way round, because many systems do not understand that ۱۲۳۴۵۶۷۸۹۰ and 1234567890 actually are the same digits. On toasts, notifications and similar situations they can be in Persian.