Comments 40
Шел 2016 год, мы писали расширения для php на PHPCPP/C/C++ и похоже это не перевод.
https://packagist.org/search/?q=icu
Не уверен что по ссылке выше есть именно нужный вам компонент, но в случае если вы хотите написать какой то класс/пакет которым будет пользоваться современный разработчик то вам стоит узнать о composer https://getcomposer.org/ (судя по php расширению вы о нем знаете)
https://packagist.org/search/?q=icu
Не уверен что по ссылке выше есть именно нужный вам компонент, но в случае если вы хотите написать какой то класс/пакет которым будет пользоваться современный разработчик то вам стоит узнать о composer https://getcomposer.org/ (судя по php расширению вы о нем знаете)
Шел 2016 год, мы писали расширения для php на PHPCPP/C/C++ и похоже это не перевод.
Эээ, простите, а на чём ещё писать расширения, требующие работы с библиотеками на C/C++? Я понимаю, есть всякие модные Зефиры, но они, кажется, совсем не для этого.
Не уверен что по ссылке выше есть именно нужный вам компонент
А я уверен, что нет.
судя по php расширению вы о нем знаете
Очень хочется съязвить, но постараюсь ответить по делу. Попытался понять, как вы сделали такой вывод, но безуспешно. Поэтому попрошу уточнения — с чего вы взяли?
Composer — это менеджер зависимостей, там расширение PHP я могу лишь указать в требованиях к пакету, мол, пакет X требует расширение phpx или либу lib-x. Как через него распространять само расширение, расскажите.
В общем, я не понял, что вы хотели сказать.
А я уверен, что нет
Вы действительно уверены что это не то?
http://symfony.com/blog/new-in-symfony-2-6-farewell-to-icu-component
вместо того чтобы тащить системную библиотеку, проще притащить php библиотеку per project.
это частичная реимплементация того функционала, который уже есть в php из коробки. Цель: отвязаться от версии icu, установленной в системе.
Именно к тому, что есть из коробки и написано расширение. Так что это действительно не то.
Именно к тому, что есть из коробки и написано расширение. Так что это действительно не то.
К тому что из коробки написано то что не из коробки, следовательно все плюсы теряются. Вместо того чтобы допилить то что более портабельно, ставить system-wide костыли.
навскидку там процентов 20 функционала реализовано. плюс читать с файловой системы мегабайты данных в разрозненных файлах не есть то же, что пользоваться скомпилированной либой.
Конечно портабельность была бы изумительна, но не в этом случае.
Конечно портабельность была бы изумительна, но не в этом случае.
Подождите, вы сейчас обсуждаете компонент, в репозитории которого написано "[DEPRECATED] This repository only exists for BC compatibility with old versions of Symfony. Recent versions comes with ICU data.", я правильно понимаю?
лично я не очень понял ваш коммент. phpcpp плохо? причем тут композер, если человек написал расширение для php, а не php-библиотеку? Или вы хотите сказать, что лучше бы он написал бибилиотеку, чем расширение?
PS По ссылке как раз одни обертки над intl.
PPS выше уже автор задал похожие вопросы.
PS По ссылке как раз одни обертки над intl.
PPS выше уже автор задал похожие вопросы.
вообще одно понятно: делать надо было именно библиотекой, т.к. ценность расширения только в поводе для неплохой статьи. "Аудитория" расширения против библиотеки будет отличаться в десятки раз.
ценность расширения только в поводе для неплохой статьи
Вот это сейчас обидно было. Статью я писал где-то 2-3 недели, искал готовые решения, спрашивал у разработчиков, изучал крупные кодовые базы, изучал ICU и код на C++, который использует ICU. Расширение написано исключительно как акт отчаяния.
делать надо было именно библиотекой
Как именно сделать это библиотекой? Написать пустую обёртку над классом расширения? Допустим. Но как это поможет пользователям? Собирать расширение всё равно нужно руками под свою систему. И так будет до тех пор, пока разработчики PHP не включат нечто подобное в intl.
Уже второй комментарий, намекающий, что лучше было бы это вообще на чистом PHP реализовать. И я начинаю задумываться: или же вы просто невнимательно прочитали пост, или, может быть, я что-то упускаю? В случае последнего искренне буду благодарен за пояснения. Потому что с моей точки зрения вы предлагаете портировать ICU на PHP и после поддерживать постоянно этого зверя.
нет-нет, я про варианты, когда портируют password api или datetimeimmutable в php 5.5- — полное мимикрирование апи.
Вы упускаете то, что внутри генератора достаточно тривиальная логика работы с локалью и ресурсами. Берем реализацию icu на java, ищем генератор, тратим часа 3 на переписывание класса из 1500 строк на php.
ICU портировать не надо, т.к. весь необходимый функционал для портирования одного класса уже есть: Locale и ResourceBundle.
Вы упускаете то, что внутри генератора достаточно тривиальная логика работы с локалью и ресурсами. Берем реализацию icu на java, ищем генератор, тратим часа 3 на переписывание класса из 1500 строк на php.
ICU портировать не надо, т.к. весь необходимый функционал для портирования одного класса уже есть: Locale и ResourceBundle.
Я глянул в http://source.icu-project.org/repos/icu/icu4j/trunk/main/classes/core/src/com/ibm/icu/text/DateTimePatternGenerator.java, и один только список импортов (не включая структуры данных, части которых нет в PHP) приводит в ужас
Ну то есть, может я суперслоупок, но это точно не 3 часа для меня, даже не 3 дня. Возможно, кто-то мог бы взяться за это, было бы отлично. Но стоит помнить, что всё это нужно затем поддерживать в актуальном состоянии. Сейчас — обновили ICU, пересобрали PHP, и поехали дальше.
Можно чуть подробнее об этом?
import com.ibm.icu.impl.ICUCache;
import com.ibm.icu.impl.ICUResourceBundle;
import com.ibm.icu.impl.PatternTokenizer;
import com.ibm.icu.impl.SimpleCache;
import com.ibm.icu.impl.SimpleFormatterImpl;
import com.ibm.icu.impl.Utility;
import com.ibm.icu.util.Calendar;
import com.ibm.icu.util.Freezable;
import com.ibm.icu.util.ICUCloneNotSupportedException;
import com.ibm.icu.util.ULocale;
import com.ibm.icu.util.ULocale.Category;
import com.ibm.icu.util.UResourceBundle;
import com.ibm.icu.util.UResourceBundleIterator;Ну то есть, может я суперслоупок, но это точно не 3 часа для меня, даже не 3 дня. Возможно, кто-то мог бы взяться за это, было бы отлично. Но стоит помнить, что всё это нужно затем поддерживать в актуальном состоянии. Сейчас — обновили ICU, пересобрали PHP, и поехали дальше.
ICU портировать не надо, т.к. весь необходимый функционал для портирования одного класса уже есть: Locale и ResourceBundle.
Можно чуть подробнее об этом?
один только список импортов (не включая структуры данных, части которых нет в PHP) приводит в ужас
особо ничего не вижу. Calendar, Locale, ResourceBundle есть. Остальное, судя по названиям, инфраструктурные плюшки, типа итераторов и токенайзеров.
В то же время конечно я могу быть не прав, но беглый взгляд на код опасений не подтвердил.
Ну то есть, может я суперслоупок, но это точно не 3 часа для меня, даже не 3 дня. Возможно, кто-то мог бы взяться за это, было бы отлично. Но стоит помнить, что всё это нужно затем поддерживать в актуальном состоянии. Сейчас — обновили ICU, пересобрали PHP, и поехали дальше.да не нужно ничего тут поддерживать. ICU — это api для работы с cldr. Портируя один класс из java-имплементации, вы просто делаете свой бэкенд над cldr, но пользуясь уже готовым api intl. intl особо не поддерживается — раз написано и все. только с каждой новой версией фич больше становится (то есть расширяется апи работы с cldr).
Можно чуть подробнее об этом?Locale — понятно, ResourceBundle — способ низкоуровнево запрашивать инфу из cldr. Именно это все и юзается в паттерн генераторе.
Отличную работу в этом направлении провел наш дорогой SamDark
slides.rmcreative.ru/2015/webconf-i18n-l10n/# на ютубе наверное видео есть
github.com/samdark/intl-icu-data-tables
Блин, убедили. Если я окончательно сойду с ума, портирую всё это дело на PHP. После месяца исследований этой темы у меня оформилась аллергия на ICU и intl, так что это случится не скоро.
icu и intl — это очень сложно, но очень гибко.
На всякий случай для не разобравшихся в мешанине терминов поясню:
есть каталог различной локализационной информации — cldr. Существует библиотека ICU, которая включает в себя cldr и предлагает некое api для работы с этими данными (реализации на c и java). есть расширение php intl, являющееся бэкендом к сишному icu.
Я предлагаю реализовать нереализованный в php intl класс DatePatternGenerator, взяв его реализацию из java icu, воспользовавшись уже реализованными классами php intl.
На всякий случай для не разобравшихся в мешанине терминов поясню:
есть каталог различной локализационной информации — cldr. Существует библиотека ICU, которая включает в себя cldr и предлагает некое api для работы с этими данными (реализации на c и java). есть расширение php intl, являющееся бэкендом к сишному icu.
Я предлагаю реализовать нереализованный в php intl класс DatePatternGenerator, взяв его реализацию из java icu, воспользовавшись уже реализованными классами php intl.
3ч? Если вы правда способны реализовать это за 3-4ч, то я согласен (на шару с несколькими людьми (т.к. за один месяц оплату московского прогера я не потяну), например MaxxArts, я думаю должен поддержать) завести feature request на каком-нить bountysource и оплатить Вам 3-4ч работы за реализацию.
2-3 недели дату форматировать??? 98% разрабочиков (включая меня) забили бы и пошли дальше.
Но тема интересная и слог у вас отличный. Пишите еще.
Но тема интересная и слог у вас отличный. Пишите еще.
98% разрабочиков (включая меня) забили бы и пошли дальше.
Представьте, что вы заходите на сайт, а там даты типа «Февраль. 10» или «10-февраля,» или ещё что-то такое невразумительное. Это примерно так видят даты пользователи из других стран, когда вы для них плохо локализуете. Представили? Вот я постоянно заставляю себя это представлять, и это отлично помогает не забивать.
Я бы начал изучать именно с того, как делает Twitter ;)
Не знал, что Твиттер написан на PHP, да ещё и выложен в открытый доступ. Пошёл изучать!
А это потому, что Twitter сделал это по-человечески — на Javascript.
Тут вам и отсутствие необходимости знать часовой пояс клиента, тут и динамическое отображение (25 минут назад) и пр.
Тут вам и отсутствие необходимости знать часовой пояс клиента, тут и динамическое отображение (25 минут назад) и пр.
А как на Javascript можно по-человечески, легко и просто получить локализованную дату без года?
Я бы начал отсюда
А это потому, что Twitter сделал это по-человечески — на Javascript.
Это неправда. Достаточно посмотреть в исходный код ленты Твиттера: он приходит с отформатированными датами уже с сервера.
Тут вам и отсутствие необходимости знать часовой пояс клиента
Это вообще как так? Вероятно, вы имели в виду «нет необходимости хранить временную зону пользователя на сервере»? Допустим. Но локализовывать дату нужно не всегда на клиенте. Иногда, скажем, это дата в письме: «тогда-то случилось/случится то-то, приходите и будет круто». И тут без какого-либо знания временной зоны пользователя уже никак.
Кроме всего этого есть легаси код, есть технические требования, от которых не уйти.
Javascript. Даты. По-человечески. Это в языке, где штатные даты самые смехотворные на свете, где месяцы нумеруют от нуля, а дни от единицы.
https://twitter.com/recursecenter/status/704429884374958080
https://twitter.com/recursecenter/status/704429884374958080
Возможно, глупый вопрос, но зачем было писать конфиг руками?
Ведь можно было бы взять тот же С++ или Java, и с помощью getBestPattern() сгенерить сразу правильный конфиг для всех-всех локалей в мире. Это конечно костыль, но менее костыльный, чем ручная правка строк форматирования.
Ведь можно было бы взять тот же С++ или Java, и с помощью getBestPattern() сгенерить сразу правильный конфиг для всех-всех локалей в мире. Это конечно костыль, но менее костыльный, чем ручная правка строк форматирования.
Хороший вопрос, на самом деле. Такой вариант я рассматривал как резервный. Так сложилось, что я ни в C++, ни в Java не умею на достаточном уровне. Честно говоря, я рассчитывал, что есть какая-то готовая утилита, которую можно было бы подёргать как раз для этих целей. Искал, не нашёл. Решил попробовать написать расширение. Случайно получилось, поэтому так.
На стороне клиента можно использовать http://momentjs.com
А вот реализация на PHP https://github.com/fightbulc/moment.php
это все понятно. но cldr — обширный кладезь любой информации, связанной с интернационализацией, и время это только небольшая часть. ICU — стандарт де-факто.
И между прочим и в браузерах уже началась появляться поддержка icu в js (https://habrahabr.ru/post/218481/), поэтому все либы типа momentjs умрут. Глупо юзать свой велосипед, писать к нему ручками двадцать-тридцать локалей (https://github.com/fightbulc/moment.php/tree/master/src/Locales), если у тебя есть обширное апи для работы с любыми локалями и доступ к самой полной информации в мире.
Поэтому лучший вариант не делать с нуля поделку, а дописать функциональность.
И между прочим и в браузерах уже началась появляться поддержка icu в js (https://habrahabr.ru/post/218481/), поэтому все либы типа momentjs умрут. Глупо юзать свой велосипед, писать к нему ручками двадцать-тридцать локалей (https://github.com/fightbulc/moment.php/tree/master/src/Locales), если у тебя есть обширное апи для работы с любыми локалями и доступ к самой полной информации в мире.
Поэтому лучший вариант не делать с нуля поделку, а дописать функциональность.
https://github.com/2amigos/transliteration-helper/tree/master/src/dosamigos/yii/helpers/data
аналогичная ситуация — для транслитерации используются какие-то таблицы. Вариант транслитерации один для всех языков и неизвестно откуда взят (тут проблема в различном подходе к транслитерации в разных языках).
Intl позволяет транслитерировать в зависимости от локали, внутри локали можно выбрать разные способы (типа iso, рекомендация такого института итд), можно переопределить, добавить свои дополнительные правила, а также доп. фильтры типа нормализации юникода итд.
аналогичная ситуация — для транслитерации используются какие-то таблицы. Вариант транслитерации один для всех языков и неизвестно откуда взят (тут проблема в различном подходе к транслитерации в разных языках).
Intl позволяет транслитерировать в зависимости от локали, внутри локали можно выбрать разные способы (типа iso, рекомендация такого института итд), можно переопределить, добавить свои дополнительные правила, а также доп. фильтры типа нормализации юникода итд.
Нет поддержки всех локалей (ru_RU например)
А там просто
Sign up to leave a comment.
Долгая история про локализацию даты без года в PHP