Document - GUI development - added Localization requirements

[zz912]

I wrote a rule for localizing float numbers.
This rule is based on this:
#3494
#2966

[BsAtHome]

You may want to look at:

It's almost impossible to rewrite the entire LinuxCNC to work with decimal commas.
This resulted a mix of decimal points and decimal commas.

It seems to be grammatically incorrect and is rather confusing.

Maybe something in the line of:

It is almost impossible to rewrite large parts of the LinuxCNC code base to work
consistently with localized decimal commas. To allow points and commas to mean
different things is both hard to get right and confusing.

[Sigma1912]

string_to_float = string_to_float.replace(",", ".")

Note that this does not reliably handle localized float input.
For example this is a valid entry for de_DE localization:
1.000,23

using the suggested method will result in 1.000.23 which is not a valid float.

Use this instead:

float = locale.atof(localized_value)

[zz912]

What happens if you substitute:
1.54
1,54
into the atof function?
Does it work with both variants?

[Sigma1912]

Does it work with both variants?

If I'm not mistaken 1.58 in de_DE locale evaluates to 158.
Which may not be what the operator wants either.

[zz912]

I tried to solve this bug #2966 . Although I didn't solve it, I tested a lot of locale float and I concluded that "replace" is the lesser evil.

If you come up with something better, I'll use it.

In Czech, a space is used to separate thousands. In school, we learned that a dot is also possible. But I've never seen it in technical software.

In Czech localizations of CAD systems, I've seen:

1. use of a decimal point
2. possibility to switch to a decimal point (I've always used it)
3. decimal comma everywhere, but really everywhere

[BsAtHome]

A more harsh and brute force way is to translate all ',' at input to '.' and add a validity check at each character entered to prevent multiple decimal separators to be entered.
This method requires that a failure while entering an input-character should be, at least, visually indicated, f.ex. by flashing red, and preferably configurable with an additional audible indication of error.

The alternative is to adhere to the locale from the user's perspective. However, this must be 100% consistent. And that is the problem... consistency is paramount.

[zz912]

@hansu Have you ever seen format value 1.256.523,56 in technical software with DE localization?

[BsAtHome]

Have you ever seen format value 1.256.523,56 in technical software with DE localization?

Don't know about DE, but I've seen it in nl-NL and da-DK (some of my hairs on my head have been left behind in processing that kind of stuff). A mess to mess with the mess and no messing!

[hansu]

@hansu Have you ever seen format value 1.256.523,56 in technical software with DE localization?

No, this seems to me only common in a financial context

[hansu]

Have you ever seen format value 1.256.523,56 in technical software with DE localization?

Don't know about DE, but I've seen it in nl-NL and da-DK (some of my hairs on my head have been left behind in processing that kind of stuff). A mess to mess with the mess and no messing!

You are from Denmark, right?

Solidworks does it this way: It shows the locale format in the result (the dimension here), but in the entry it uses always dots, but you can enter dots or comma. If you mix it, it results in an error.

A more harsh and brute force way is to translate all ',' at input to '.' and add a validity check at each character entered to prevent multiple decimal separators to be entered.

I would go for this!

Currently in the calculator, when entering 1.23 with DE locales, it results in 123 which I would not expect.

[BsAtHome]

You are from Denmark, right?

Only partially ;-)

Solidworks does it this way: It shows the locale format in the result (the dimension here), but in the entry it uses always dots, but you can enter dots or comma. If you mix it, it results in an error.

That I've also seen multiple places. One problem is that it can be interpreted as being inconsistent.

That said, however, creating the drawing or using the drawings are generally performed by two different persons with different backgrounds. That means that there is a writer/reader disparity that needs to be considered when looking at consistency. One partial example is generally not enough to use as a rule.

A more harsh and brute force way is to translate all ',' at input to '.' and add a validity check at each character entered to prevent multiple decimal separators to be entered.

I would go for this!

That seems to be a common way to deal with the problem afaik. How it is displayed afterwards is not uniformly agreed upon. Some use locales and others just fix it to use one or the other. But, whatever you choose, the visual must be used consistently everywhere from that point on.

Currently in the calculator, when entering 1.23 with DE locales, it results in 123 which I would not expect.

Indeed, that would cause a lot of grief, being off by one or more orders of magnitude. But the same problem occurs if an operator enters 1.234,56 or 1,234.56, which also may be off by orders of magnitude and give spurious errors upon entry. That is why I mentioned the visual (and configurable audible) feedback that must be prominent to force the operator to think.

[zz912]

Thank you all for the comments. I'll try to draw a conclusion from this:

== Localization
=== Localization float numbers in inputs parts of GUI
Don't use the float number localization in inputs. (For example don´t use locale.atof(localized_value)) Some localizations use a decimal points for float numbers, others use a decimal commas. Decimal points in some localizations are grammatically incorrect, but commas cause a lot of problems.It is almost impossible to rewrite large parts of the LinuxCNC code base to work consistently with localized decimal commas. To allow points and commas to mean different things is both hard to get right and confusing.
It is advisable to use decimal commas acceptance in inputs. This can be implemented in Python as follows:
[source,python]

?????
It will be added later.
?????

=== Localization float numbers in visual parts of GUI
The default display of float numbers in the visual part should be decimal points. If you decide to display float numbers according to localization, it is necessary to ensure being inconsistent everywhere.
Common modules that are used in multiple GUIs should display float numbers with decimal points by default. Displaying float numbers according to localization should be activated in the module using a specific GUI.

Does that make sense?

Norbert doesn't want to display DRO with decimal comma in Gmoccapy. So it's simple here. Gmoccapy will display decimal point everywhere.

On the other hand, I don't want to prohibit float numbers according to localization in other GUIs. But it will be a lot of work to unify everything.
That's why I created these rules like this.

[BsAtHome]

The gist of it is fine. It needs a bit more work on grammar, formatting and finally a native English speaker check (not me...):

• don't should be do not IMO because this is a "formal" description of how things should be.
• others use a decimal commas. should remove the plural 's' in commas.
• localized_value)) Some missing period after parentheses.
• problems.It missing space after full stop.
• Do not use == header without body text followed by a === header.
• I think a header should be fine with == Localization of float numbers in GUIs and address both input and output behaviour.
• default display of float numbers --> default display format of float numbers
• to ensure being inconsistent probably should be "to ensure consistent formatting"
• You need to elaborate on the last sentence. What exactly do you mean? What is "activating" and who (user?, developer?) has the responsibility of what module in which GUI?

[hansu]

You are from Denmark, right?

Only partially ;-)

That needs now some further explanation ;-)

Indeed, that would cause a lot of grief, being off by one or more orders of magnitude. But the same problem occurs if an operator enters 1.234,56 or 1,234.56, which also may be off by orders of magnitude and give spurious errors upon entry. That is why I mentioned the visual (and configurable audible) feedback that must be prominent to force the operator to think.

I can't image that one operator enters a number like this. In this case I would just throw en error or just didn't accept the input.

[zz912]

My English is very bad, so I use google translator.

== Localization of float numbers in GUIs
It is necessary to deal with decimal point and decimal comma in float numbers. Underestimating this issue leads to a program crash at best, or to incorrect reading of the number, which may differ by orders of magnitude from the entered number.

=== Localization float numbers in inputs parts of GUI
Do not use the float number localization in inputs. (For example don´t use locale.atof(localized_value)). Some localizations use a decimal point for float numbers, others use a decimal comma. Decimal point in some localizations are grammatically incorrect, but comma cause a lot of problems. It is almost impossible to rewrite large parts of the LinuxCNC code base to work consistently with localized decimal comma. To allow points and commas to mean different things is both hard to get right and confusing.
It is advisable to use decimal commas acceptance in inputs. This can be implemented in Python as follows:
[source,python]

?????
It will be added later.
?????

=== Localization float numbers in visual parts of GUI
The default display format of float numbers in the visual part should be decimal points. If you decide to display float numbers according to localization, it is necessary to ensure consistent formatting everywhere.
Common modules that are used in multiple GUIs should display float numbers with decimal points by default. ......

[BsAtHome]

You need to elaborate on the last sentence. What exactly do you mean? What is "activating" and who (user?, developer?) has the responsibility of what module in which GUI?

I think that no one will want to create a GUI where float numbers will be displayed according to localization. It's a lot of work.
But I don't want to prohibit it, so I wrote down the rules:

1. it must be the same everywhere
2. There are common modules: DRO, Offset page, Tool page .... Their modification must not cancel the uniformity that is already in the original GUI.
   I don't want to define how the activation should take place. It can be a value in the initialization function, or some parameter, or some signal, or ...
   Switching between "dot float" and "localize float" can be automatic, or an option with some check button. I don't want to define it.

If someone creates a GUI where float numbers will be displayed according to localization. It will be necessary to make rules from this GUI. But I would do them retroactively.

[BsAtHome]

I don't think you should use (sub)headers (===). The text is too short to allow for such fine-grained subdivision and one == header is just fine. There is no point in having an almost one-liner with a separate header.

You should review your text again and add the/your (compact and short) rationale to it, just like you did just now. That will explain to the reader why the rules are setup as they are. But remember, rules are there to limit expression. You must be very careful not to limit one thing and then, via a backdoor, allow it again, which can easily happen when you "don't want to define" something.

[c-morley]

I think you don't want to get too specific unless required:

Decimal localization is difficult.
If you do decimal localization then:

1. must be consistent in the whole screen.
2. if you allow 3rd party embedding keep in mind how they may handle localization (if possible)
3. either allow '.' or allow ',' as a decimal indicator. Numbers with both '.' and ',' are not allowed.
4. localization should be user selectable

etc don't add code examples unless required.

[andypugh]

The British Standard for technical drawings is decimal commas. (BS8888 - https://roymech.org/Useful_Tables/Drawing.html )
Nobody in Britain ever uses decimal commas. And I have never seen them in drawings (but then I don't look at drawings very often). Not relevant here, just a point of interest.

[zz912]

Decimal comma is used often in Czech drawings. However, I have never seen a drawing where some values ​​had commas and others dots. In Creo we used decimal dots, but we had a font set where the dot looked like something between a dot and a comma. The advantage of comma is that it is more readable on dirty printed paper drawings.

Here, Sigma is working on a fix for the localization of the calculator widget:
#3500
Based on this widget, I would like to complete this PR. So I am waiting now.

[andypugh]

When I was at school we were taught to use https://en.wikipedia.org/wiki/Interpunct
(But according to that article this was a purely British thing)
And given that it is not available on keyboards, I don't think mandating it's use in LinuxCNC would be wise.

[andypugh]

Might I suggest:

Different locales use different decimal separators and thousands separators. Locale-specific string-to-float functions should be avoided as they may give unexpected results. (For example the text string "1.58" in de_DE will be converted to 158 by atof()). The following guidelines (based on avoiding ambiguity rather than on "correctness" in any specific locale) are suggested if parsing float to string and vice-versa:

1. In the case of input allow either comma (,) or point(.) as a decimal separator, but reject any input that has more than one of either. Space should be accepted but not required as a thousands separator.
2. In the case of display either use point (.) consistently or use the current localisation format consistently. The emphasis here being on "consistently".

[zz912]

Thank you Andy. I used your text.