Issue 311: Numbers internationalization #576
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- Yearly costs
- Add an option to display all the data.
- Add translation
- Update template pot file
…ds' dropdown lists
…nd' into wip_stockholm
…' into wip_stockholm
…nto wip_stockholm
- Rename Object class in source code
- Rename files
- Follow-up
This reverts commit 3229d41.
organizations/install/upgrade_koral_vendors.sql was not properly renamed to be processed by the installer, leading to a missing ilsID field, which allows to jump back to the ILS when a Coral and ILS vendor are linked.
Remove SUSHI COUNTER 3 support
Remove COUNTER 3 from SUSHI settings
Currently, all numbers in Coral are in the default format:
- en_US
- 2 decimals
This patchs allows to define how numbers should be parsed and displayed in Coral.
The configuration takes place in common/configuration.ini, as such:
[settings]
number_locale = "fr_FR"
number_decimals = 2
number_decimal_separator = ","
If number_locale is omitted, it will be defaulted to en_US
If number_decimals is omitted, it will be defaulted to 2
If number_decimal_separator is ommited, it will be defaulted to '.'
Please note that is PR includes and obsoletes:
- PR 575: Allow to define SQL number format in common/configuration.ini
- PR 418: Cost history numeric error
This PR currently affects every part of the resources module using
cost_to_integer and integer_to_cost function:
- new resource, api, api_client, imports, summary and cost history.
Special sql processing has been made to exports and dashboards.
Special javascript processing has been made to cost history.
Test plan:
1) Change the default values (as provided in the example above, for instance)
2) Check that resource exports and dashboards show the correct number formatting
3) Check that cost history fields correctly parses the numbers according to the
locale when calculating priceTaxIncluded
4) Check that cost history correctly displays the numbers according to the
locale when calculating priceTaxIncluded
5) Check that the numbers are correctly stored to and fetched from the database
according to the locale in cost history
6) Check that the import tool correctly parses the numbers according to the locale
7) Check that it also works the default values or no values at all
- use parseFloatI18n instead of a regex - use NumberFormatter::TYPE_DOUBLE explicitely
|
I tried testing this PR but couldn't get it to work properly. In the dashboard and on exports, it works well, but the Resource Acquisitions tab shows a blank page whenever there are any actual costs (with no cost history, it displays fine). It looks like this:
I don't know if this is an issue with my test environment, or if anyone else can reproduce this? |
|
Any error in the logs ? |
|
[php7:error] [pid 4155] [client 130.237.153.122:54600] PHP Fatal error: Uncaught Error: Class 'NumberFormatter' not found in /var/www/html/coral/resources/directory.php:34\nStack trace:\n#0 /var/www/html/coral/resources/ajax_htmldata/getAcquisitionsDetails.php(144): integer_to_cost(NULL)\n#1 /var/www/html/coral/resources/ajax_htmldata.php(24): include('/var/www/html/c...')\n#2 {main}\n thrown in /var/www/html/coral/resources/directory.php on line 34, referer: /coral/resources/resource.php?resourceID=5808 |
…-bugs SirsiDynix: Additional Datepicker fixes
SirsiDynix: Improved selective joins
Currently, all numbers in Coral are in the default format:
- en_US
- 2 decimals
This patchs allows to define how numbers should be parsed and displayed in Coral.
The configuration takes place in common/configuration.ini, as such:
[settings]
number_locale = "fr_FR"
number_decimals = 2
number_decimal_separator = ","
If number_locale is omitted, it will be defaulted to en_US
If number_decimals is omitted, it will be defaulted to 2
If number_decimal_separator is ommited, it will be defaulted to '.'
Please note that is PR includes and obsoletes:
- PR 575: Allow to define SQL number format in common/configuration.ini
- PR 418: Cost history numeric error
This PR currently affects every part of the resources module using
cost_to_integer and integer_to_cost function:
- new resource, api, api_client, imports, summary and cost history.
Special sql processing has been made to exports and dashboards.
Special javascript processing has been made to cost history.
Test plan:
1) Change the default values (as provided in the example above, for instance)
2) Check that resource exports and dashboards show the correct number formatting
3) Check that cost history fields correctly parses the numbers according to the
locale when calculating priceTaxIncluded
4) Check that cost history correctly displays the numbers according to the
locale when calculating priceTaxIncluded
5) Check that the numbers are correctly stored to and fetched from the database
according to the locale in cost history
6) Check that the import tool correctly parses the numbers according to the locale
7) Check that it also works the default values or no values at all
- use parseFloatI18n instead of a regex - use NumberFormatter::TYPE_DOUBLE explicitely
- Use fixed number of decimals
- Fix error messages with price tax included and price tax excluded - Add more explicit message for error on payment
- Add more strict control on amount input
- Remove console.log
- Remove the need for number_decimal_separator
- Fix javascript void() calls - Use the selected locale in isAmount function
- Remove whitespaces upon form submission
- Use ParseFloatI18n on cost form submission, since it is already what has been used to validate the data.
- Remove whitespaces in amount when parsing it.
- Warn the user if php-intl is not enabled, instead of silently crashing.
- Fix dashboard merge
…ub.com/biblibre/Coral into Issue_311_Numbers_internationalization
- Add compatibility for dashboards recent developments
- Optimization
|
Ok, just rebased this to development branch. |
|
Tested against the development branch, and works as intended. Good work @veggiematts! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Background & discussion, see Issue #311
Currently, all numbers in Coral are in the default format:
This patchs allows to define how numbers should be parsed and displayed in Coral.
First of all, install the
php-intlpackage.The configuration takes place in
common/configuration.ini, as such:If number_locale is omitted, it will be defaulted to en_US
If number_decimals is omitted, it will be defaulted to 2
Please note that is PR includes and obsoletes:
This PR currently affects every part of the resources module using
cost_to_integer and integer_to_cost function:
Special sql processing has been made to exports and dashboards.
Special javascript processing has been made to cost history.
Test plan:
locale when calculating priceTaxIncluded
locale when calculating priceTaxIncluded
according to the locale in cost history