The correct solution would probably be to upgrade the version of bootstrap and bootstrap-datepicker that we use
My understandng of the bug is:
* bootstrap-datepicker finds the first ancestor whose z-index isn’t auto, and sets its own z-index to the found elemenents z-index + 10.
* On Firefox and Chrome, the modal element is returned (its z-index is 1050)
* On Safari, the modal-dialog element is found. Its z-index is auto, but Safari reports this as '0', which makes the z-index of the datepicker 10.
Translations with a comma in the key are rewritten to be on a single
line.
But this failed when the comma was just preceded by a dot (like in
`etc.,`).
Fix the script so that it works even in those cases.
Now the bahavior matches the comments in config.php:
// Fully qualified domain name of your webserver.
// If this is unset or empty, the servername is determined automatically.
// You *have to set this* if you are running Framadate behind a reverse proxy.
// const APP_URL = '<www.mydomain.fr>';
This commit adds a script to check all keys from translation files to
make sure no missing keys / no translation files are incorrect.
Even if missing keys should not happen (because we use a script to add
keys automatically) this script made helped to understand that all
three `ar`, `eo` and `fr_FR` translation files were completly off
compared to the `en.json` file.
I believe we can safely delete `ar`, `eo` and `fr_FR` locales from
Zanata (because those languages are not set in the ALLOWED_LANGUAGES
config array). ⚠️ this needs to be check in the production `config.php`
file ⚠️.
Deleting the `fr_FR` locale file should solve both !358 and #395
closes !358#395
When exporting a poll to CSV, no BOM character is written. Most applications can
properly detect the required encoding, but some do not, and might find it
helpful to be able to read a BOM character.
--
Comment added 2019-04-16, nico@bou.io:
The issue is specifically with Excel that assumes Latin-1 by default, but switches to utf-8 if a BOM is present. On the other hand, LibreOffice and other apps seem to behave correctly with a BOM.
The current `html2text` function from the PHPMailer library strips all
html tags and only keeps the inner html.
In the case of <a> tags we need to share the `href` attribute to the
user when he reads his mail in plain text format.
Fixes #419
msgHTML builds the text/plain part by converting the passed html to text in the current CharSet; the default Charset being iso-8859-1, most non-ascii characters are lost.
fixes #416
