Я проверил GraphicsMagick (у меня под рукой оказалась версия 1.3.20 2014-08-16 Q8, не уверен, что это прям свежак), он подвержен как минимум чтению локальных файлов через label (CVE-2016-3717), правда, рендерится только первая строчка файла. Возможно, это как-то обходится, но суть в том, что пользователям GM всё-таки стоит начать беспокоиться. SSRF через url точно не работает.
> не будет необходимости считать сколько щас у нас/ у них времени
Вы и сейчас можете не считать, но только что вам это даст?
Идея в том, что куда бы ты ни приехал, ты уверен, что 8-9 часов утра — это светлое время суток, в которое начинают работу люди, открываются магазины, кафе и прочие заведения, а в где-то в 23 часа уже точно темно, и почти наверняка будут проблемы с поиском общественного транспорта. То есть, в основном, это разделение на светлое/тёмное время суток, понимание ключевых точек типа полдень/полночь.
Иными словами, вы смотрите с технической точки зрения, с единым временем действительно удобнее работать. Но с чисто человеческой — это ужас.
Ну, вообще, у нас не так много таких мест, где без хардкорных моков прям не обойтись, это крайние случаи (и случаи приступов лени). Мы стараемся избегать подобной фигни. Поэтому, думаю, вероятность не такая большая. Хотя это зависит от того, насколько новую версию PHP вы имеете в виду. Для PHP 8 наверняка придётся патчить. А так — норм.
А, сорри, это тот компонент, в репозитории которого написано "The replacement layer is limited to the locale "en". If you want to use other locales, you should install the intl PHP extension instead.", да?
Подождите, вы сейчас обсуждаете компонент, в репозитории которого написано "[DEPRECATED] This repository only exists for BC compatibility with old versions of Symfony. Recent versions comes with ICU data.", я правильно понимаю?
То, что я вижу по ссылке, — не полноценная локаль. Это только переводы. Как я писал, локаль, это ещё и порядок размещения даты и времени. Но это так, к слову. Само собой, эта либа к полноценной локализации не имеет отношения.
98% разрабочиков (включая меня) забили бы и пошли дальше.
Представьте, что вы заходите на сайт, а там даты типа «Февраль. 10» или «10-февраля,» или ещё что-то такое невразумительное. Это примерно так видят даты пользователи из других стран, когда вы для них плохо локализуете. Представили? Вот я постоянно заставляю себя это представлять, и это отлично помогает не забивать.
Блин, убедили. Если я окончательно сойду с ума, портирую всё это дело на PHP. После месяца исследований этой темы у меня оформилась аллергия на ICU и intl, так что это случится не скоро.
Хороший вопрос, на самом деле. Такой вариант я рассматривал как резервный. Так сложилось, что я ни в C++, ни в Java не умею на достаточном уровне. Честно говоря, я рассчитывал, что есть какая-то готовая утилита, которую можно было бы подёргать как раз для этих целей. Искал, не нашёл. Решил попробовать написать расширение. Случайно получилось, поэтому так.
Ну то есть, может я суперслоупок, но это точно не 3 часа для меня, даже не 3 дня. Возможно, кто-то мог бы взяться за это, было бы отлично. Но стоит помнить, что всё это нужно затем поддерживать в актуальном состоянии. Сейчас — обновили ICU, пересобрали PHP, и поехали дальше.
ICU портировать не надо, т.к. весь необходимый функционал для портирования одного класса уже есть: Locale и ResourceBundle.
А это потому, что Twitter сделал это по-человечески — на Javascript.
Это неправда. Достаточно посмотреть в исходный код ленты Твиттера: он приходит с отформатированными датами уже с сервера.
Тут вам и отсутствие необходимости знать часовой пояс клиента
Это вообще как так? Вероятно, вы имели в виду «нет необходимости хранить временную зону пользователя на сервере»? Допустим. Но локализовывать дату нужно не всегда на клиенте. Иногда, скажем, это дата в письме: «тогда-то случилось/случится то-то, приходите и будет круто». И тут без какого-либо знания временной зоны пользователя уже никак.
Кроме всего этого есть легаси код, есть технические требования, от которых не уйти.
ценность расширения только в поводе для неплохой статьи
Вот это сейчас обидно было. Статью я писал где-то 2-3 недели, искал готовые решения, спрашивал у разработчиков, изучал крупные кодовые базы, изучал ICU и код на C++, который использует ICU. Расширение написано исключительно как акт отчаяния.
делать надо было именно библиотекой
Как именно сделать это библиотекой? Написать пустую обёртку над классом расширения? Допустим. Но как это поможет пользователям? Собирать расширение всё равно нужно руками под свою систему. И так будет до тех пор, пока разработчики PHP не включат нечто подобное в intl.
Уже второй комментарий, намекающий, что лучше было бы это вообще на чистом PHP реализовать. И я начинаю задумываться: или же вы просто невнимательно прочитали пост, или, может быть, я что-то упускаю? В случае последнего искренне буду благодарен за пояснения. Потому что с моей точки зрения вы предлагаете портировать ICU на PHP и после поддерживать постоянно этого зверя.
Я проверил GraphicsMagick (у меня под рукой оказалась версия 1.3.20 2014-08-16 Q8, не уверен, что это прям свежак), он подвержен как минимум чтению локальных файлов через
label(CVE-2016-3717), правда, рендерится только первая строчка файла. Возможно, это как-то обходится, но суть в том, что пользователям GM всё-таки стоит начать беспокоиться. SSRF черезurlточно не работает.Вы и сейчас можете не считать, но только что вам это даст?
Идея в том, что куда бы ты ни приехал, ты уверен, что 8-9 часов утра — это светлое время суток, в которое начинают работу люди, открываются магазины, кафе и прочие заведения, а в где-то в 23 часа уже точно темно, и почти наверняка будут проблемы с поиском общественного транспорта. То есть, в основном, это разделение на светлое/тёмное время суток, понимание ключевых точек типа полдень/полночь.
Иными словами, вы смотрите с технической точки зрения, с единым временем действительно удобнее работать. Но с чисто человеческой — это ужас.
Представьте, что вы заходите на сайт, а там даты типа «Февраль. 10» или «10-февраля,» или ещё что-то такое невразумительное. Это примерно так видят даты пользователи из других стран, когда вы для них плохо локализуете. Представили? Вот я постоянно заставляю себя это представлять, и это отлично помогает не забивать.
Ну то есть, может я суперслоупок, но это точно не 3 часа для меня, даже не 3 дня. Возможно, кто-то мог бы взяться за это, было бы отлично. Но стоит помнить, что всё это нужно затем поддерживать в актуальном состоянии. Сейчас — обновили ICU, пересобрали PHP, и поехали дальше.
Можно чуть подробнее об этом?
Это неправда. Достаточно посмотреть в исходный код ленты Твиттера: он приходит с отформатированными датами уже с сервера.
Это вообще как так? Вероятно, вы имели в виду «нет необходимости хранить временную зону пользователя на сервере»? Допустим. Но локализовывать дату нужно не всегда на клиенте. Иногда, скажем, это дата в письме: «тогда-то случилось/случится то-то, приходите и будет круто». И тут без какого-либо знания временной зоны пользователя уже никак.
Кроме всего этого есть легаси код, есть технические требования, от которых не уйти.
Вот это сейчас обидно было. Статью я писал где-то 2-3 недели, искал готовые решения, спрашивал у разработчиков, изучал крупные кодовые базы, изучал ICU и код на C++, который использует ICU. Расширение написано исключительно как акт отчаяния.
Как именно сделать это библиотекой? Написать пустую обёртку над классом расширения? Допустим. Но как это поможет пользователям? Собирать расширение всё равно нужно руками под свою систему. И так будет до тех пор, пока разработчики PHP не включат нечто подобное в intl.
Уже второй комментарий, намекающий, что лучше было бы это вообще на чистом PHP реализовать. И я начинаю задумываться: или же вы просто невнимательно прочитали пост, или, может быть, я что-то упускаю? В случае последнего искренне буду благодарен за пояснения. Потому что с моей точки зрения вы предлагаете портировать ICU на PHP и после поддерживать постоянно этого зверя.