Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NumberFormatting problems, avg. page generation time is displayed with two decimal points in German language #10596

Closed
OliverIost opened this issue Sep 29, 2016 · 23 comments

Comments

@OliverIost
Copy link

commented Sep 29, 2016

After moving to a new server (from Debian 7 with standard mysql and php5.6 via dotdeb to Debian 8 with mariadb and php7.0 via dotdeb) some problems occur.
With language set to german seconds are shown like 0..15 s and 0.2 s (where 0,15 s and 0,2 s would be correct).

To resolve the problem for me, I changed line 224 in NumberFormatter.php to:

if (!is_numeric($value) || is_float($value)) {

@mattab mattab added this to the 2.16.3 milestone Sep 29, 2016

@mattab mattab added the Bug label Sep 29, 2016

@mattab

This comment has been minimized.

Copy link
Member

commented Sep 30, 2016

Hi @OliverIost
Where in the reports do you see this displayed? I cannot reproduce on PHP 7.0.9 using German language, seconds are shown correctly for me.

I'm using the 2.16.3 RC which you can download from our "Beta" channel: http://piwik.org/faq/how-to-update/faq_159/

@mattab

This comment has been minimized.

Copy link
Member

commented Sep 30, 2016

Ok this bug was also reported here: #10594 by
@sesom42

"Action -> Page titles" shows the avg. page generation time. With language set to english the numbers are displayed correctly. With language german numbers are displayed with two decimal points.

piwik localization bug

Piwik 2.16.2, PHP 5.6.24

@sgiehl could you maybe take a look at this one?

@mattab

This comment has been minimized.

Copy link
Member

commented Sep 30, 2016

As @sesom42 is not using PHP7, this is not a PHP7 bug, so it must be caused by another configuration setting or so. Not yet able to reproduce it.

@mattab mattab changed the title NumberFormatting problem with php 7.0 / patch for solving it NumberFormatting problems, avg. page generation time is displayed with two decimal points Sep 30, 2016

@mattab mattab changed the title NumberFormatting problems, avg. page generation time is displayed with two decimal points NumberFormatting problems, avg. page generation time is displayed with two decimal points in German language Sep 30, 2016

@mattab

This comment has been minimized.

Copy link
Member

commented Oct 2, 2016

Can anyone else reproducing it? do you know how we could reproduce this issue?

Can you reproduce it on demo.piwik.org ?

@mattab mattab modified the milestones: 2.17.0, 2.16.3, 2.16.4 Oct 2, 2016

@sgiehl

This comment has been minimized.

Copy link
Member

commented Oct 3, 2016

For me it's displayed as expected like 1,3s. On my local install it's the same using PHP 5.6 or PHP 7.
@OliverIost which server locale have you set?

@mattab mattab modified the milestones: 2.17.0, 2.16.4 Oct 3, 2016

@OliverIost

This comment has been minimized.

Copy link
Author

commented Oct 4, 2016

I updated to 2.16.4 and the problem is back (cause my „patch“ is now missing).

locale shows the following:

LANG=de_DE.UTF-8
LANGUAGE=
LC_CTYPE="de_DE.UTF-8"
LC_NUMERIC="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_COLLATE="de_DE.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_MESSAGES="de_DE.UTF-8"
LC_PAPER="de_DE.UTF-8"
LC_NAME="de_DE.UTF-8"
LC_ADDRESS="de_DE.UTF-8"
LC_TELEPHONE="de_DE.UTF-8"
LC_MEASUREMENT="de_DE.UTF-8"
LC_IDENTIFICATION="de_DE.UTF-8"
LC_ALL=

Please remember: There shows up „0..37 s“ but „0.2 s“

@sesom42

This comment has been minimized.

Copy link

commented Oct 4, 2016

I have tracked it a little bit down. Tooltips in the page also shows the problem.
piwik pagetitles de numberformat
The numbers in the tooltip are formatted with method getPrettyTimeFromSeconds. If I append the unformated numbers to the tooltip (in plugins/Actions/Reports/Base.php) they are displayed correctly.

The problem only occurs with the German language setting. Other language settings show the numbers correctly (according to the respective country format).

Debian 8.6, Nginx 1.6.2, php-fpm 5.6.24 + php5-mysqlnd, MariaDB 10.0.27 (other server), system locale on webserver: LANG="de_DE.UTF-8", charset of db connection:

+--------------------------+----------------------------+
| Variable_name            | Value                      |
+--------------------------+----------------------------+
| character_set_client     | utf8                       |
| character_set_connection | utf8                       |
| character_set_database   | utf8                       |
| character_set_filesystem | binary                     |
| character_set_results    | utf8                       |
| character_set_server     | utf8                       |
| character_set_system     | utf8                       |
| character_sets_dir       | /usr/share/mysql/charsets/ |
+--------------------------+----------------------------+
8 rows in set (0.00 sec)

@mattab

This comment has been minimized.

Copy link
Member

commented Oct 17, 2016

@sgiehl did you have a chance to reproduce this issue? maybe it could be due to PHP locate configuration...

If anyone else has an idea let us know

@mattab

This comment has been minimized.

Copy link
Member

commented Oct 22, 2016

we haven't been able to reproduce so far so please send more info or help us reproduce. for now moving out of 2.17.0 / LTS

@mattab mattab modified the milestones: 2.17.0, 3.0.0 Oct 22, 2016

@OliverIost

This comment has been minimized.

Copy link
Author

commented Oct 22, 2016

Hmm, what about my „patch“: if it doesn't crash something in your installations – why not use it? For me with it everything is okay. Or what does happen in your installations then?

@mattab

This comment has been minimized.

Copy link
Member

commented Oct 22, 2016

@OliverIost I think your patch basically disables the formatter in some cases. feel free to create a pull request with the patch as it will run the whole thousands of automated tests and we can see what breaks

@OliverIost

This comment has been minimized.

Copy link
Author

commented Oct 22, 2016

That's right, it disables the formatter. It must be a kind of type problem which only occurs in some cases we all do not really understand. As long as I understand it, the formatter is only needed for numbers >=1000 (=> to format it like 1,000 or 1.000 - english / german) which are integers and for display numbers with %. But the %-numbers seem always to be rounded to integers before the formatter is called (otherwise my patch would make other problems). If these are the only cases where the formatter is needed, my patch should not make any problems.

As long as I do not oversee this – I do not want to make new problems ;)

@peterbo

This comment has been minimized.

Copy link
Contributor

commented Mar 30, 2017

@sesom42 @OliverIost Perhaps I have an idea, what's happening here. Do you have the php5-intl extension installed?

@sesom42

This comment has been minimized.

Copy link

commented Mar 31, 2017

@peterbo php5-intl was installed. After uninstalling php5-intl the problem remains unfortunately.

@OliverIost

This comment has been minimized.

Copy link
Author

commented Mar 31, 2017

@peterbo php5-intl was installed. After upgrading to php7.0 (with php7.0-intl) the problem remains.

@peterbo

This comment has been minimized.

Copy link
Contributor

commented Mar 31, 2017

@sesom42 @OliverIost what is the output of "locale -a" on your server?

@OliverIost

This comment has been minimized.

Copy link
Author

commented Mar 31, 2017

C
C.UTF-8
de_DE
de_DE@euro
de_DE.iso88591
de_DE.iso885915@euro
de_DE.utf8
deutsch
german
POSIX

@peterbo

This comment has been minimized.

Copy link
Contributor

commented Mar 31, 2017

I think there is the problem. We try to set setlocale(LC_NUMERIC, array('en_US.UTF-8', 'en-US')); for juggling with unified types of float values. In this case, setlocale fails, because "en_US.UTF-8" is not installed on the server. PHP casts back the float values to be comma separated on every operation and so, the format logic fails.

Can we check if this is the case?
Console: cat /usr/share/i18n/SUPPORTED - if this list contains "en_US.UTF-8", please try to install it if possible: sudo locale-gen en_US.UTF-8

When we know that this was the reason, we can think of a possible fix.

@OliverIost

This comment has been minimized.

Copy link
Author

commented Mar 31, 2017

I had to use „dpkg-reconfigure locales“ to add en_US.utf8 ( sudo locale-gen en_US.UTF-8 generates the locales as they were – but did not add the new one)

After adding as described „locale -a“ shows

C
C.UTF-8
de_DE
de_DE@euro
de_DE.iso88591
de_DE.iso885915@euro
de_DE.utf8
deutsch
en_US.utf8
german
POSIX

And now – after restarting apache – it works! Thank you @peterbo !

@peterbo

This comment has been minimized.

Copy link
Contributor

commented Mar 31, 2017

@OliverIost thanks for testing, then I probably know how to fix this.

@OliverIost

This comment has been minimized.

Copy link
Author

commented Mar 31, 2017

👍

@sesom42

This comment has been minimized.

Copy link

commented Mar 31, 2017

Works here too! Thank you @peterbo

@peterbo

This comment has been minimized.

Copy link
Contributor

commented Mar 31, 2017

Sorry... pull request went to my own fork at first.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.