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]

importationBQ-Price-Decimal-TEST.csv.tar.gz

[textbrowser]

I committed a change for the table price.

[textbrowser]

Condition: the values in the UI are translatable. The translation needs to occur before the table is populated.

[meteos77]

the list in English has a logic (alphabetical order) the list in French has no logic

[textbrowser]

Are you requesting that the values in the combination box be ordered? Or to change the sort logic of the table?

[meteos77]

rather the logic of the table from best condition to worst condition 1 - As New 2 - Very Good 3 - Good 4 - Fine 5 - Fair 6 - Poor 7 - Binding Copy 8 - Ex-Library 9 - Book Club

[textbrowser]

Indeed. Perhaps the translated values should be saved.

[textbrowser]

Price locale import: the price must be enclosed by double quotes. This allows the regular expression to retain the commas in a quoted field. Similar to other fields. The export from BQ does enclose fields by double quotes if the values in those fields contain commas.

[textbrowser]

Here's an image of a translated Condition entry in the main table. The translation occurs before the book entry is saved and therefore the text in the SQLite database is the translated text.

sqlite> select condition from book; Comme neuf As New As New As New As New As New As New As New As New

[meteos77]

*condition field : sorry I did the translation backwards EN-> FR and I was not clear.

when creating a book, you can specify its physical status (fields: condition in the database) by the pop-up

the pop-up proposed by BQ if the interface is configured in English, the pop-up list is presented in alphabetical order.

in another language like French, the beginning of the words changes and so the alphabetical list in English, becomes a list without particular sorting order in French. this forces the French user to browse the whole list to be able to find the chosen state for the document

in English for the state "poor" you go directly to the bottom of the alphabetical list because it starts with "P".

in French for the state "Bon" you expect to find it in 1st position at the top of the list if sorted alphabetically while it arrives in 7th position (Good in English)

my suggestion was to sort them in order of quality by adding a number in front of it, because in English or French, we will always use Arabic numbers :-)

[meteos77]

for the import with price I had tested with and without double quotes but it did not change anything.

I will test again as soon as possible and keep you informed

[textbrowser]

The expectation that the import tool should consider locale-specific data is quite high (almost absurd). A double is represented by a sequence of decimal digits and a single separator (the dot). The value 5.55 is locale-agnostic while the value 5,55 is not. BQ cannot detect the locale from a CSV file. Price values are recorded as double (real) values, not strings. Displayed values versus representations are different.

[textbrowser]

Condition values are now sorted. :) Please test. I'd like to bundle the releases soon.

[meteos77]

sorry the earth is not converted to the us system :-) it's the same thing with unimarc and marc21 but more universal

the dot "." is for Anglo-Saxons the comma "," is for Europeans

Decimal separator

BiblioteQ in Europe should recognize the comma because the common use of the dot is the separator of thousands. All our tools (libreoffice, calculator ... put a comma when you type the point on the numeric keyboard)

in the import tool a simple transformation in the price field from comma to point should be ok for BQ ?

[meteos77]

$> env LC_NUMERIC=en_US.UTF8 printf '%f\n' 1233.14 1233.140000 $> env LC_NUMERIC=fr_FR.UTF8 printf '%f\n' 1233.14 1233,140000

[meteos77]

The book condition part is ok, thanks for the evolution

[meteos77]

remark: in the interface of the books, I can not put the price with a decimal number by the numeric keyboard the key ".suppr" is not taken into account. I have to use the ",?" key to put the comma and continue the input on the cents

[meteos77]

as you like to laugh a little video : https://www.youtube.com/watch?v=JeiihmJ1VEk

[textbrowser]

I thought about your request during a dream. Yup, BQ can translate the price from a locale-specific string to a double (real).

[textbrowser]

OK, uploaded!

[meteos77]

super ! it works well for me, the import is OK on the other hand I discovered a lot of small inconsistencies between price and monetary units

do you want to see them before the release of the package or do you prefer to focus on this one ?

you make beautiful dreams :-) for me it's more like : unreal

[textbrowser]

sorry the earth is not converted to the us system :-) it's the same thing with unimarc and marc21 but more universal

the dot "." is for Anglo-Saxons the comma "," is for Europeans

Decimal separator

BiblioteQ in Europe should recognize the comma because the common use of the dot is the separator of thousands. All our tools (libreoffice, calculator ... put a comma when you type the point on the numeric keyboard)

in the import tool a simple transformation in the price field from comma to point should be ok for BQ ?

The metric system is the best. A comma replacing the decimal point... not so much. And in French, 100,000.00 is not 100,000,00. Right?

[textbrowser]

How did you test it so quickly?

[meteos77]

in french 100.000.00 does not exist 10.000.000 or 10.000.000,00

[meteos77]

git pull make -j8 nouvelle base de données import csv

[meteos77]

principle export = import are not respected if export csv, the field price contains the currency symbol €.

[meteos77]

if monetary units are different from €, the display in the table in the price column is always €?

[meteos77]

I can provide you with the French translation, the translatable texts will not change anymore?

[textbrowser]

if monetary units are different from €, the display in the table in the price column is always €?

The price in the database is represented by a NUMERIC(10, 2) value. The text in the main table will now contain the currency. Therefore, yes. If you export the main table, the exported text will contain the currency symbol. If you import it, the currency symbol is removed by QLocale::toDouble() and the numeric is recorded in the database.

https://github.com/textbrowser/biblioteq/blob/master/SQL/postgresql_create_schema.sql

[meteos77]

sorry translation (2 word in french , 1 word in english) table (sql) = table (in french table) table view = table (in frenc tableau)

[textbrowser]

sorry translation (2 word in french , 1 word in english) table (sql) = table (in french table) table view = table (in frenc tableau)

The UI table contains currency symbols. The database table does not contain currency symbols as it only contains double (real / numeric) values. The currency symbols are added to the UI table by QLocale.

During an import, QLocale is utilized for converting the text in the CSV (which may contain currency symbols) to numeric values (assuming a failure does not occur). The numeric values are stored in the database.

[textbrowser]

I can provide you with the French translation, the translatable texts will not change anymore?

Sure. If I have additional changes, I'll let you know.

Release notes and visible text remain for you to translate.

[meteos77]

As usual, Europeans have a problem :-) before 2002, each european country had its own monney

in France, a document before 2002 was in "Francs" currency in Germany, a document dated before 2002 was in "Mark" currency in Spain a document before 2002 was in "Peseta" currency ... so BQ can't automatically put the € currency unit symbol because if a book is from before 2002, it's anything but €

the monetary units field allows you to specify the currency

that said, I think it's great to have the money symbol in the UI table!

[meteos77]

for me the import can not contain a currency symbol otherwise the import does not take the amount importationBQ-Price-Decimal-TEST.csv.tar.gz example 3 and 4 field separator is equal to %.

[textbrowser]

Let me see.

[meteos77]

enumeration database pop-up (see condition field pop-up (alphabetical sorting))

we have the same "problem" with the sorting on the enumeration database pop-up. the order in french doesn't correspond to anything.

[textbrowser]

Yup. This is relevant everywhere where fixed lists are located. There is nothing automatic that is available. All of the logic must be developed. It's expensive software.

[meteos77]

I'm doing my (French) user feedback :-), on this point, the previous version we didn't have this pop-up option. As the title of the ticket says, these are "small problems", we can use the software as it is. Your precious time is for me more useful in the new features.

[meteos77]

ask Qt something like "locales.sort.popup" :-)

[textbrowser]

It's a frustration instead of a time-sensitive problem. I see it as a problem that some people will face if they believe that a list should be sorted. I sort it in English because it's a preference. These details are very expensive because nothing is automatic. For traditional tables and lists, Qt provides a means of sorting entries so one does not have to provide new instructions.

[textbrowser]

OK, the currency symbol must be removed from the string before the locale-specific value is converted into a double. QLocale does not remove the currency symbol automatically. Test now.

[textbrowser]

enumeration database pop-up (see condition field pop-up (alphabetical sorting))

we have the same "problem" with the sorting on the enumeration database pop-up. the order in french doesn't correspond to anything.

This is more problematic because sorting the entries in the combination box requires that the widget portions also be sorted. That is, the location of the widgets must be dynamic.

[meteos77]

In my 4 tests

line 1 price = 20.12 OK (point and without symbol) line 2 price = 20,34 OK ( coma and without symbol) line 3 price = 20.56 $ KO (point and with a $) line 4 price = 20.78 € OK (coma and with a €)

as far as I understand, it only removes the symbol defined with the locale and not all the currency symbols.

[meteos77]

for me the problem was rather in the other direction

import without symbol => OK because monetary_unit defines the currency export -> add a symbol which can be wrong (€ instead of $ or especially € instead of Fr for Francs)

[textbrowser]

In my 4 tests

line 1 price = 20.12 OK (point and without symbol) line 2 price = 20,34 OK ( coma and without symbol) line 3 price = 20.56 $ KO (point and with a $) line 4 price = 20.78 € OK (coma and with a €)

as far as I understand, it only removes the symbol defined with the locale and not all the currency symbols.

For sure. I suppose you want it to pick out the price from an infinite list of possibilities? Like, "$$$ 30 . ab25".

[textbrowser]

The export cannot be wrong unless your locale is wrong. The export is of the things you see in the main UI table. If you see currency symbols, they'll be exported. If any text contains a comma, it will be encased by double quotes.

[textbrowser]

The export does not add any characters save for double quotes.

[meteos77]

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

[meteos77]

example : 9782878332278 in zone 20 $c unimarc 35 FRF (French Francs)

all books sold in France before 2002 will be like that with FRF

in 2002 the European Union created a common currency the €uros

[meteos77]

a quick extract of the books published before 2002 in my library: about 30% of documents concerned by a purchase in FRF