biblioteq
biblioteq copied to clipboard
textbrowser
Small problems detected.
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
Condition: the values in the UI are translatable. The translation needs to occur before the table is populated.
the list in English has a logic (alphabetical order) the list in French has no logic
Are you requesting that the values in the combination box be ordered? Or to change the sort logic of the table?
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
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.
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
*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 :-)
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
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.
Condition values are now sorted. :) Please test. I'd like to bundle the releases soon.
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
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 ?
$> 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
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
as you like to laugh a little video : https://www.youtube.com/watch?v=JeiihmJ1VEk
I thought about your request during a dream. Yup, BQ can translate the price from a locale-specific string to a double (real).
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
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
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?
principle export = import are not respected if export csv, the field price contains the currency symbol €.
if monetary units are different from €, the display in the table in the price column is always €?
I can provide you with the French translation, the translatable texts will not change anymore?
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
sorry translation (2 word in french , 1 word in english) table (sql) = table (in french table) table view = table (in frenc tableau)