Icinga
CSV export should not be language-dependent
Hello :) Not sure if this is a bug or more a feature request:
Currently behavior when creating a CSV export of a report it has the SLA values comma-separated if the web interface is in German and point-separated if the web interface is in English. IMO the CSV export should always have the point-separated values (i.e. disregard the web interface language/localization), because the CSV files get created with a comma as column separator.
Alternatively an option to specify what column separator is to be used.
I can't reproduce this. Neither with host sla reports nor with service sla reports. Not even with a breakdown set.
On which platform with which php version does this happen? Which Icinga Web 2 version? Have you just configured de_DE (I assume that's the language) in the preferences or are there any LC_* env vars for the webserver process set?
# cat /etc/os-release
NAME="Red Hat Enterprise Linux Server"
VERSION="7.7 (Maipo)"
# php -v
PHP 5.4.16 (cli) (built: Oct 29 2019 10:01:20)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies
# locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
are there any
LC_*env vars for the webserver process set?
no, only env var having something to do with languages would be LANG=en_US.UTF-8
idoreports | 0.9.1 reporting | 0.10.0
For me this only happens when manually downloading the reports in CSV format via the webinterface. Regardless of setting the language to de_DE by myself or using the browsers setting.
Character set for the DB resource is also set to utf8mb4 as per the docs, but I just realised that an ä comes out as ä in all the reports (regardless of the webinterface language).
Scheduled reports have the "correct" point-separated representation and letters :)
Reproduced it. This isn't an issue since PHP 8. Only lower versions are affected.