webair 178 Опубликовано: 31 октября 2019 Рассказать Опубликовано: 31 октября 2019 <?xml version="1.0" encoding="utf-8"?> <dleplugin> <name>float bug</name> <description></description> <icon></icon> <version>1.0</version> <dleversion></dleversion> <versioncompare>less</versioncompare> <upgradeurl></upgradeurl> <filedelete>0</filedelete> <needplugin></needplugin> <mnotice>1</mnotice> <mysqlinstall><![CDATA[]]></mysqlinstall> <mysqlupgrade><![CDATA[]]></mysqlupgrade> <mysqlenable><![CDATA[]]></mysqlenable> <mysqldisable><![CDATA[]]></mysqldisable> <mysqldelete><![CDATA[]]></mysqldelete> <phpinstall><![CDATA[]]></phpinstall> <phpupgrade><![CDATA[]]></phpupgrade> <phpenable><![CDATA[]]></phpenable> <phpdisable><![CDATA[]]></phpdisable> <phpdelete><![CDATA[]]></phpdelete> <notice><![CDATA[Результат смотреть /engine/ajax/controller.php?mod=test]]></notice> <file name="engine/ajax/test.php"> <operation action="create"> <replacecode><![CDATA[<?php ini_set('error_reporting', E_ALL); ini_set('display_errors', 1); ini_set('display_startup_errors', 1); if(!defined('DATALIFEENGINE')) { header( "HTTP/1.1 403 Forbidden" ); header ( 'Location: ../../' ); die( "Hacking attempt!" ); } function vardump($var) { echo '<pre>'; var_dump($var); echo '</pre>'; } $pi = 3.14; vardump($pi);]]></replacecode> </operation> </file> </dleplugin> Почему при обращении к /engine/ajax/controller.php?mod=test я получу float(3,14) а если просто создать test,php в корне сайта (не подключая к DLE) получу float(3.14) То есть, у меня сервер настроен правильно, а DLE изменяет настройки локали, касающиеся точки/запятой. Общепринято использовать точку. А ведь вы предлагаете не только русскую версию, но и англоязычную. Иностранные разработчики не поймут такой юмор. И кажется, это в последних версиях появилось, раньше такого не замечал. Выявил, когда хотел в базу записать дробное значение, тип float, а записалась только целочисленная часть. Костыль - в начале нужного файла указать setlocale(LC_NUMERIC, 'C'); Возможно, DLE не использует дробные числа и вам нормально. Но думайте и о сторонних разработчиках, которым работать с вашим продуктом. Цитата Ссылка на сообщение Поделиться на других сайтах
germanydletest 457 Опубликовано: 31 октября 2019 Рассказать Опубликовано: 31 октября 2019 @webair,открой /language/Russian/website.lng, там в конце есть строчка @setlocale(LC_ALL, array("ru_RU.UTF-8", "ru_RU.UTF8")); В англоязычной версии её нет, так что для иностранных разработчиков таких "сюрпризов" не будет. @celsoft уже как-то объяснял, зачем они меняют настройки локали, так как не все шаредхостинги настроены нормально. 1 Цитата Ссылка на сообщение Поделиться на других сайтах
webair 178 Опубликовано: 31 октября 2019 Рассказать Опубликовано: 31 октября 2019 (изменено) Автор 17 минут назад, germanydletest сказал: уже как-то объяснял, зачем они меняют настройки локали, так как не все шаредхостинги настроены нормально Спасибо! Сам бы я это долго искал... Даже не знаю, зачем устанавливать ru_RU.UTF-8? Для вывода дат на русском? Для этого нужно ломать числа и совместимость модулей между русской и английской версией, если модуль использует не только целые числа? Можно же было локализовать только то что нужно. Цитата LC_ALL - все нижеперечисленное LC_COLLATE - функции сравнения строк, см. strcoll() LC_CTYPE - функции преобразования и классификации строк, например strtoupper() LC_MONETARY - для функции localeconv() LC_NUMERIC - задает символ десятичного разделения (см. также localeconv()) LC_TIME - форматирование даты/времени функцией strftime() LC_MESSAGES - для системных сообщений (доступна, если PHP был скомпилирован с поддержкой libintl) UPD. Посмотрел lng файл, там есть массивы с русскоязычными названиями дат. Тогда я не понимаю смысл) Изменено 31 октября 2019 пользователем webair Цитата Ссылка на сообщение Поделиться на других сайтах
Gameer 311 Опубликовано: 31 октября 2019 Рассказать Опубликовано: 31 октября 2019 36 минут назад, webair сказал: Но думайте и о сторонних разработчиках, которым работать с вашим продуктом. С чего бы DLE беспокоиться за сторонних разработчиков? Они поддерживают движок в первую очередь для клиентов и получения с этого прибыли. То что кто-то что-то будет писать под/для DLE никак не относиться к разработчикам продукта. 1 1 Цитата Ссылка на сообщение Поделиться на других сайтах
germanydletest 457 Опубликовано: 31 октября 2019 Рассказать Опубликовано: 31 октября 2019 24 минуты назад, webair сказал: Тогда я не понимаю смысл) celsoft придёт и в очередной раз (возможно), объяснит смысл))) Цитата Ссылка на сообщение Поделиться на других сайтах
webair 178 Опубликовано: 31 октября 2019 Рассказать Опубликовано: 31 октября 2019 Автор 8 минут назад, germanydletest сказал: celsoft придёт и в очередной раз (возможно), объяснит смысл))) @celsoft, сбрасывать локали для английского языка не надо, а для русского надо? Иностранные сервера настроены всегда правильно? Что плохого бы случилось, если сбрасывали так? setlocale(LC_ALL, "C"); Цитата Ссылка на сообщение Поделиться на других сайтах
proba 57 Опубликовано: 31 октября 2019 Рассказать Опубликовано: 31 октября 2019 в presta вместо LC_ALL используют (необходимые для них) LC_COLLATE, LC_CTYPE, LC_TIME, LC_NUMERIC по причине этого: http://www.php.net/manual/fr/function.setlocale.php#25041 Цитата Ссылка на сообщение Поделиться на других сайтах
celsoft 6 088 Опубликовано: 31 октября 2019 Рассказать Опубликовано: 31 октября 2019 5 часов назад, webair сказал: Даже не знаю, зачем устанавливать ru_RU.UTF-8? Для вывода дат на русском? Нет. Для корректной работы с русским языком, по всем аспектам это и файловая система и ЧПУ и тексты и много много где. Некорректная локаль приводит к потере символов в строках. Прочитайте разные темы на форуме где пользователи не понимают почему вдруг из текста пропадает какая либо буква. Это из за локалей происходит. Локаль ставится согласно используемому языку в DLE. 6 часов назад, webair сказал: Общепринято использовать точку. Кем принято? В русском языке принята именно запятая а не точка и арифметические операции производятся также корректно. В других языках принята точка. Это зависит от языка, поэтому устанавливается также в языковых файлах. Цитата Ссылка на сообщение Поделиться на других сайтах
webair 178 Опубликовано: 31 октября 2019 Рассказать Опубликовано: 31 октября 2019 Автор 1 час назад, celsoft сказал: Кем принято? В русском языке принята именно запятая а не точка и арифметические операции производятся также корректно. В других языках принята точка. Это зависит от языка, поэтому устанавливается также в языковых файлах. Попробуйте с запятой число вставить в mysql. Выдаст ошибку или вставится только целочисленная часть. Все mysql сервера по умолчанию в float используют точку, вы это знаете. Ладно, для себя я решил проблему, вырезав эту строку) Цитата Ссылка на сообщение Поделиться на других сайтах
celsoft 6 088 Опубликовано: 31 октября 2019 Рассказать Опубликовано: 31 октября 2019 3 часа назад, webair сказал: Ладно, для себя я решил проблему, вырезав эту строку) Классное решение, а что вы будете делать если эта настройка будет прописана в настройках сервера? Ведь любую локаль можно прописать именно в настройках сервера. Может нужно писать более правильный и независимый код, и проводить корректные преобразования данных специально предусмотренными для этого средствами? Не думали об этом? Какими именно? Пожалуйста https://www.php.net/manual/ru/function.number-format.php Цитата Ссылка на сообщение Поделиться на других сайтах
webair 178 Опубликовано: 31 октября 2019 Рассказать Опубликовано: 31 октября 2019 Автор 2 часа назад, celsoft сказал: Классное решение, а что вы будете делать если эта настройка будет прописана в настройках сервера? Ведь любую локаль можно прописать именно в настройках сервера. Может нужно писать более правильный и независимый код, и проводить корректные преобразования данных специально предусмотренными для этого средствами? Не думали об этом? Какими именно? Пожалуйста https://www.php.net/manual/ru/function.number-format.php У меня сервер изначально корректно настроен на setlocale(LC_ALL, "C"), проблем с путями и названиями файлов нет. Главное, выяснили, что это не баг, а фича оказывается. Которая мне (моему клиенту) не нужна 1 Цитата Ссылка на сообщение Поделиться на других сайтах
celsoft 6 088 Опубликовано: 31 октября 2019 Рассказать Опубликовано: 31 октября 2019 5 часов назад, webair сказал: У меня сервер изначально корректно настроен на setlocale(LC_ALL, "C"), проблем с путями и названиями файлов нет. Корректно, это когда локаль полностью соответствует языку сайта. У вас он на русском, т.к. русский языковый пакет. Поэтому при корректной настройке была бы запятая Так что "корректно" понятие растяжимое, правильнее написать как меня устраивает. Это во первых. Во вторых вы не знаете где они возникают, поэтому не можете утверждать что у вас нет проблем. Проблемы далеко не всегда видимы и далеко не со всеми именами проявляются. Я не собираюсь вас ни в чем переубеждать, но возникающие вопросы нужно решать корректно, а не через "костыли", а корректным является написание кода, которое не зависит ни от чего, ни от локалей самого сервера, ни от того что прописано в DLE. И как это сделать я написал выше. А пользоваться советом или нет ваше право. Я бы тоже удовольствием отказался бы от локалей в DLE, но там к сожалению не получится, т.к. работа завязана на стандартные функции PHP, а они в свою очередь на локали и это другим способом не обойти. Цитата Ссылка на сообщение Поделиться на других сайтах
Рекомендованные сообщения
Присоединяйтесь к обсуждению
Вы можете опубликовать сообщение сейчас, а зарегистрироваться позже. Если у вас есть аккаунт, войдите в него для написания от своего имени.