Small problems detected.

[meteos77]

price field

• the locale '.' and ',' as decimal separator on the field "price" has a defect
• in english the decimal separator is a point, in most european countries it is the comma.
  • import csv takes only the .
  • the display in book is a ,
  • the display in the table is a .

"condition field

• the sorting order (alphabetical) for the field "condition" is not optimal because in a language other than English, the translation changes and thus no more coherence suggestion : add 1, 2 3 in the label (sort from the best condition to the most degraded so all languages will be in the same order)

it also allows to charge a document if the borrower returns a book with 3 levels of difference between the condition at the time of the loan and the condition at the time of return

[meteos77]

I don't know how easy it is to do

take what is in monetary_unit is if €uros or Euros put € in UI table otherwise put nothing the europeans will be that it is their currency before the euros

[meteos77]

an example is more visible the first 3 books are bought with Francs (F) the 4th was in F/€ so I put euros

exemple-Francs_Euros.sqlite.tar.gz

[textbrowser]

I summarize what I have understood

* the import accepts the point and the comma (great)

* the import accepts the local currency symbol (linked to the principle import is equal to export)

so my question : I don't see why BQ put a € symbol in the UI table when the book is in Francs (old French currency), information provided in monetary_units.

1 €uros = 6,55959 Francs so no relation between the 2

That's QLocale.

[textbrowser]

Monetary Units and Price are totally separate. The price field in the UI may or may not contain a currency symbol; it depends upon QLocale. The Monetary Units value is a value which someone may or may not provide and if the unit differs from the currency symbol, BQ can do nothing about that.

[textbrowser]

For Example, I may have a Japanese title with a price in dollars but a monetary unit of Yen. Thinking about this, I will remove the currency symbol from the UI.

[textbrowser]

And display the value (without the symbol) in the locale.

[textbrowser]

Done and that's enough BQ for today!

[meteos77]

I agree with you; you have solved the problems presented well. Thanks for the progress.

[meteos77]

good end of day

[textbrowser]

Yes, go to bed!

[meteos77]

Summary of the "price" situation

• the French numeric keyboard has a key that makes a dot (European major)
• the fr_FR locale requires a comma in the price field. (display)
• the QDoubleSpinBox widget in the price field asks for a comma (input ui)
• biblioteq asks for a dot in the price field (database)

I found a site that tells a portuguese how to do it.

and french

if that gives you an idea.

Ideally, the dot on the numeric keypad should be accepted by the QDoubleSpinBox to fill the price (situation of all software (LibreOffice, Calculator). after BQ's internal cooking is not the user's concern :-) if BQ wants to have only points it doesn't bother us!

[textbrowser]

Can you pull and rebuild? Submitted a book test.

[meteos77]

the import works like a charm OK with 12,12 OK with 12,12 € OK with 12.12 OK with 12.12 €

KO with 12,12 $ (normal it's not the local)

[textbrowser]

And the book UI?

[meteos77]

the price field has always had a comma

[meteos77]

bookUI = the price field has always had a comma

[textbrowser]

You want a translation of the dot character? So if I press '.' in the widget, it should become a locale separator?

[meteos77]

currently the numeric keyboard works but the French keyboard card of the numeric keyboard is a .

in your case can you enter a price with decimal only with the numeric keyboard? we, we can not do it

[meteos77]

we must use the ? key, (see keyboard image above) which is not common in software that handles numbers opencalc, calculator because as the locale is , and the numeric keyboard is made to enter numbers, the softwares transform the . of the numeric keyboard into , (decimal separator)

[textbrowser]

Did you try enabling Num Lock?

[meteos77]

calculator tool in this tool, if I want to have a decimal number, I can using only the numeric keyboard (numlock activated of course)

[meteos77]

this is the problem explained in the 2 links provided today (Portuguese and French)

[textbrowser]

For me to intercept the key press and map it to another key:

1. Create a custom sub-class.
2. Place the class in all UI files.
3. Build the sub-class.

Or.

1. Create a special filter class.
2. Add the filter class everywhere where a price field exists.

This is a lot of work for a price field.

[textbrowser]

Since you can enter the price using the keyboard, the software works. Remember, BQ is not a point-of-sale application.

[meteos77]

no worries, look at the title (small problems)

don't forget that I never know if it's 1 line or three hours of work disturbing my requests.

[meteos77]

the import works with the comma that's the main thing

[textbrowser]

Must disagree that it's not a problem. An enhancement is an appropriate word.

[meteos77]

I would like to take into account the international context of use of the BiblioteQ software :-) which needs an improvement but whose development would require a time much too long for the immediate gain of the users. The users are waiting for other evolutions more necessary for their use of the software.

[textbrowser]

This quirky request is specific to your input device. Your input device represents a period. Why should the software translate a period into a comma?

[textbrowser]

There are numerous keyboards without numeric pads. I don't have numeric pads on most of my keyboards. Laptops do not generally include numeric pads.

[textbrowser]

Besides, the appropriate solution should be optional. Like, "Translate Numeric Pad Period".

[textbrowser]

The calculator application has separate aspects. It's made for computing values so a bit of translating of a single character in a single location is natural. For BQ, it's not natural.

[meteos77]

because we are French sir :-) if you are ill-equipped :-) I have a laptop with numeric keypad.

in English you don't have accented letters like in many languages for example é è ê â ô ö ç ù for French so you don't need less keys, or we should have shortcuts without direct access to these characters

[textbrowser]

There's a comma on your keyboard.

[meteos77]

you are right, I will note the applications that make the difference

libreoffice -> coma

calculator -> coma gimp -> dot scribus -> dot thunderbird -> point firefox -> point

[textbrowser]

you are right, I will note the applications that make the difference

libreoffice -> coma

calculator -> coma gimp -> dot scribus -> dot thunderbird -> point firefox -> point

For numeric pad only, yes?

[textbrowser]

Now, for the applications which are translating the dot to a comma on the numeric pad, which ones have this translation as an option? Also, what happens if you copy a value such as 55.55 and paste it into those applications? Do they translate the period into a comma?

[meteos77]

options in libreoffice

[meteos77]

no, it stays in point it does not allow to make calculation with it is a text field in librecalc

[meteos77]

the good programs respect the language, the others are based on the Anglo-Saxon system.

[textbrowser]

BQ respects the language. The request is asking BQ to disrespect the input device in favor of locale quirkiness.

[textbrowser]

Like, if I see a key and I press the key I expect one of two things: the key is not understood because of some quirky application specifics or the key is understood and its interpretation is displayed. I don't expect a translation unless the application has made me aware of the translation or I programmed my keyboard to translate or I modified the software to do so.

If I sit at a computer and type, I expect my key presses to be interpreted correctly regardless of what I'm typing into. Different expectations for POS machines, but even those have non-quirky behavior because they have to be? Correct!

[meteos77]

my thought would be to align on a single system, the . or the comma but that the 5 continents agree on a way and everyone applies the same rule. this would avoid many unnecessary complications.

ditto for marc21 and unimarc

[meteos77]

the weirdness concerns other countries (maybe even the majority of the world)

the question of Portuguese (Brazil) in the 1st link

the keyboard manufacturers do not respect the local weirdness as you say. the point for the end of a sentence but as soon as it's decimal it's a comma so the numeric keyboard of Europeans should have a comma instead of a point, that would be more logical.

thanks for this discovery :-)

[textbrowser]

Are you familiar with bc?

Terminal:

bc

bc 1.07.1
Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006, 2008, 2012-2017 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'. 
55.55*2.0
111.10
55,55*2,0
(standard_in) 2: syntax error
(standard_in) 2: syntax error```

[textbrowser]

Does bc translate the dot from the numeric pad into a comma? If it does, that's bad.

[meteos77]

bc only takes the point

[textbrowser]

Which is the proper action.

[textbrowser]

Aha, you're asking for context-sensitive translations which are annoying. If you're in this mode, the period is a comma. But what if you really want a period? Like, suppose you're in a numeric field and you want 55,000,000.55. And imagine you paste that. The application has to understand exactly what you want.

[meteos77]

in the English context 55,000,000.55 does not exist in French it is 55,000,000.55 or 55000000.55 the translator turns periods into commas and commas into points, he does his job well 55.000.000,55 or 55000000,55