Комментарии 42
В принципе, вполне годная для использования библиотека, код вполне качественный, да и использовать удобно. Но возникло, как говориться одно «но»:
да, php 5.5 сейчас уже вышел из «active support» и перешел в «security updates only», но некоторые твердолобые до сих пор его используют и объяснить им что срочно необходимо обновляться до 5.6/7.0 проблематично. Есть ли возможность ввести поддержку 5.5?
Еще 1 вопрос о поддержке laravel/lumen — может стоит оформить отдельным пакетом, а базовый выделить как «standalone» и его уже использовать в require для пакета laravel/lumen?
"php": ">=5.6.0"
да, php 5.5 сейчас уже вышел из «active support» и перешел в «security updates only», но некоторые твердолобые до сих пор его используют и объяснить им что срочно необходимо обновляться до 5.6/7.0 проблематично. Есть ли возможность ввести поддержку 5.5?
Еще 1 вопрос о поддержке laravel/lumen — может стоит оформить отдельным пакетом, а базовый выделить как «standalone» и его уже использовать в require для пакета laravel/lumen?
Ох, я сходу уже не помню – там что-то требовало 5.6. У меня изначально стояло 5.5, пока не наткнулся :) Я проверю в общем!
Про Laravel/Lumen — да, вероятно вы правы. Кроме того, там настолько простая интеграция — её чуть ли не проще в документации описать :)
Про Laravel/Lumen — да, вероятно вы правы. Кроме того, там настолько простая интеграция — её чуть ли не проще в документации описать :)
Я смотрел, правда очень бегло, но не нашел массового использования основных «фишек» 5.6 — плавающего кол-ва параметров аргументов фу-ии или использования «default», отлова «несуществующих» каллбэков тоже вроде не заметил через try-catch над object, deprecated function вам вовсе рано использовать, так что вам думаю видней в чем там загвоздка была.
Вспомнил — у меня тесты все в Travis запускаются. И изначально там 5.5 стояло в том числе — оно фейлилось как раз. Сейчас верну в Travis 5.5 и увижу :)
Нашел — это PhpUnit 5-ый не поддерживает 5.5. Сейчас попробую в 'require' сделать 5.5, а в 'require-dev' 5.6.
В общем, я уже закомиттил и пометил
В общем, я уже закомиттил и пометил
Нашлась-таки одна мелочь, не поддерживаемая в 5.5 – в static properties нельзя было использовать оператор конкатенации (.).
Теперь проходят тесты на 5.5
Теперь проходят тесты на 5.5
Вот бы ещё интеграцию с КЛАДР/ФИАС! Но боюсь, что проще будет запилить отдельную библиотеку…
Подозреваю, что это настолько массивная задача, что должна быть Git под-модулем. Вообще, всё, что не глобальное — должно быть опциональным, а не входить в основной пакет
Достаточно в вашем пакете выделить логику чтения и преобразования исходных данных о странах/регионах/городах в интерфейсы, и пользователи сами припишут нужные адаптеры для чтения данных из КЛАДР, а не из массивов.
Или, как вариант, из базы, доступные редактированию пользователям.
Базы и так доступны к редактированию :) Выбран формат JSON специально, чтобы было удобно редактировать прямо через web-интерфейс GitHub:
https://github.com/MenaraSolutions/geographer/blob/master/resources/translations/country/ru.json
Долгосрочный план — что пользователи из разных стран сами будут постепенно улучшать базу
Но скорее всего базы надо вынести в отдельные репозитории, чтобы отделить возможные библиотеки на других языках от контента
https://github.com/MenaraSolutions/geographer/blob/master/resources/translations/country/ru.json
Долгосрочный план — что пользователи из разных стран сами будут постепенно улучшать базу
Но скорее всего базы надо вынести в отдельные репозитории, чтобы отделить возможные библиотеки на других языках от контента
там же в КЛАДР, насколько я понимаю, глубже иерархия — улицы и дома.
про интерфейсы Вы правы, спасибо за замечание
про интерфейсы Вы правы, спасибо за замечание
Честно говоря хотелось бы немного покритиковать API.
В примерах меня сильно удивило следующее:
return Geographer::findOneByCode($countryCode)
->setLanguage($language)
->getName();
Если Geographier::findOneByCode() возвращает объект страны то метод setLanguage вызывает попаболь.
Любой человек подумает что вы меняете язык у страны, а не локализацию строк. Но даже setLocale/getLocale вызвало бы одно недоумение.
Имхо более разумный подход с локалями:
Geographer::setDefaultLocale = 'ru'
…
Geographer::Country::findByCode($countryCode)
->getName($locale);
В примерах меня сильно удивило следующее:
return Geographer::findOneByCode($countryCode)
->setLanguage($language)
->getName();
Если Geographier::findOneByCode() возвращает объект страны то метод setLanguage вызывает попаболь.
Любой человек подумает что вы меняете язык у страны, а не локализацию строк. Но даже setLocale/getLocale вызвало бы одно недоумение.
Имхо более разумный подход с локалями:
Geographer::setDefaultLocale = 'ru'
…
Geographer::Country::findByCode($countryCode)
->getName($locale);
Это дело вкуса, я думаю. Очевидно же, что язык, на котором говорят люди в стране, нельзя поменять методом в ООП :)
Насчет второго замечания — это и так возможно: Geographer::setLanguage('ru')
Так как это singleton во фреймворках (Laravel и др), то изменение настроек отразится на всех последующих вызовах
Я еще подумаю насчет language vs locale, спасибо за мысль!
Насчет второго замечания — это и так возможно: Geographer::setLanguage('ru')
Так как это singleton во фреймворках (Laravel и др), то изменение настроек отразится на всех последующих вызовах
Я еще подумаю насчет language vs locale, спасибо за мысль!
C точки зрения API Язык в стране можно поменять — это всего лишь данные.
Но если есть setLanguage, то я так понимаю getLanguage присутствует тоже, верно? А вот тут уже начинает один сплошной конфуз.
ИМХО все таки локалализация строк в результатах методов не должна быть свойством объекта.
Но если есть setLanguage, то я так понимаю getLanguage присутствует тоже, верно? А вот тут уже начинает один сплошной конфуз.
ИМХО все таки локалализация строк в результатах методов не должна быть свойством объекта.
Хм, Вы правы — конфуз есть ;-) getLanguage() есть только у страны, но тем не менее.
На объектах городов-областей-стран этот метод для удобства, он в нем не реализован. Идея в том, чтобы можно было на любой стадии «исправить» положение. Это достаточно распространенная практика
На объектах городов-областей-стран этот метод для удобства, он в нем не реализован. Идея в том, чтобы можно было на любой стадии «исправить» положение. Это достаточно распространенная практика
Если смотреть по use-кейсам то получается что в большинстве случаев локаль достаточно установить один раз за запрос. Исключение — получение нативного имени, однако тут лучше сделать отдельный метод getNativeName().
Russia (Россия)
Japan (日本)
Russia (Россия)
Japan (日本)
В большинстве случаев — да
Что если надо вывести названия одной и той же страны на разных языках? :) (не только на текущем и нативном)
Я, кстати, не спорю. Я с этой целью и публиковал статью, чтобы ценные рекомендации получать :)
Что если надо вывести названия одной и той же страны на разных языках? :) (не только на текущем и нативном)
Я, кстати, не спорю. Я с этой целью и публиковал статью, чтобы ценные рекомендации получать :)
Если надо вывести название страны в произвольной локали — то есть опциональный параметр метода, например getName($locale = NULL), что я и пропагандирую :)
Предлагаю взглянуть на аналоги:
https://github.com/hexorx/countries
Предлагаю взглянуть на аналоги:
https://github.com/hexorx/countries
Да, логично. Возможно, на этом и остановлюсь! :)
Когда я начинал делать библиотеку, я даже не знал — будут ли еще какие-то куски информации переводимыми. Поэтому я последовал старому правилу «не оптимизируй заранее»
А сейчас все похоже на то, что только имена и переводятся. Вполне логично туда локаль (язык) и вставить
Когда я начинал делать библиотеку, я даже не знал — будут ли еще какие-то куски информации переводимыми. Поэтому я последовал старому правилу «не оптимизируй заранее»
А сейчас все похоже на то, что только имена и переводятся. Вполне логично туда локаль (язык) и вставить
Вы конечно молодцы, и выпустили удобный продукт… Но давайте класс Earth отправим на глубокий рефактор.
Есть список макрорегионов (https://ru.wikipedia.org/wiki/Макрорегионы_мира_(ООН)), на основе которого и надо именовать методы.
Регионов дефакто немного больше, они немного по другому разбиты. И Micro — это микронезия, не надо ее обижать.
PS: Связь стран и макрорегионов можно взять из экспорта http://data.esosedi.org/
Есть список макрорегионов (https://ru.wikipedia.org/wiki/Макрорегионы_мира_(ООН)), на основе которого и надо именовать методы.
Регионов дефакто немного больше, они немного по другому разбиты. И Micro — это микронезия, не надо ее обижать.
PS: Связь стран и макрорегионов можно взять из экспорта http://data.esosedi.org/
Сейчас есть только континенты в Earth, и они определены международным обществом :)
Не уверен, что кому-то пригодится вывести список стран макрорегиона? Если честно, даже и про континент не уверен – просто это было в исходной базе Geonames, не стал убирать.
Вы можете привести пример, когда будет полезно вывести список стран макрорегиона?
По поводу семантики в случае с 'micro' — мне самому вариант не понравился, но ничего лучше не нашел. Мысль такая, что большинству разработчиков в большинстве случаев не нужны крохотные страны с крохотным населением. Искал термин для таких стран (а ля Гибралтар) — не нашел. Но префикс «микро» иногда используется: https://en.wikipedia.org/wiki/European_microstates
Не уверен, что кому-то пригодится вывести список стран макрорегиона? Если честно, даже и про континент не уверен – просто это было в исходной базе Geonames, не стал убирать.
Вы можете привести пример, когда будет полезно вывести список стран макрорегиона?
По поводу семантики в случае с 'micro' — мне самому вариант не понравился, но ничего лучше не нашел. Мысль такая, что большинству разработчиков в большинстве случаев не нужны крохотные страны с крохотным населением. Искал термин для таких стран (а ля Гибралтар) — не нашел. Но префикс «микро» иногда используется: https://en.wikipedia.org/wiki/European_microstates
1) подозреваю, что коды стран все-таки по ISO 3166, а не по ISO 3611
2) хотелось бы поддержки кодов стран по ISO 3166 numeric, а не только ISO 3166-1 alpha-2 и ISO 3166-1 alpha-3
2) хотелось бы поддержки кодов стран по ISO 3166 numeric, а не только ISO 3166-1 alpha-2 и ISO 3166-1 alpha-3
Интересное решение, спасибо!
Есть два предложения:
1) Отделить библиотеку от ресурсов (т.е. другой репозиторий для ресурсов), чтобы можно было делать другие реализации, например, на другом языке программирования, и
2) (Попробовать) использовать для перевода формат gettext — в нем сразу содержится и оригинал и перевод, что на мой взгляд гораздо удобнее для поддержки переводов, чем возня с цифровыми кодами.
Есть два предложения:
1) Отделить библиотеку от ресурсов (т.е. другой репозиторий для ресурсов), чтобы можно было делать другие реализации, например, на другом языке программирования, и
2) (Попробовать) использовать для перевода формат gettext — в нем сразу содержится и оригинал и перевод, что на мой взгляд гораздо удобнее для поддержки переводов, чем возня с цифровыми кодами.
А где вы берете данные?
Geonames, Wikipedia и бесплатные онлайн-словари
При достижении достаточной популярности, можно ожидать от пользователей разных стран внесения поправок в переводы через pull-запросы – справочники будут сами постоянно улучшаться, подобно wiki.
Не пробовали osm? Пользователи разных стран уже вносят туда правки ежедневно. Все данные доступны для экспорта. Есть переводы городов на множество языков. Есть координаты городов, что даёт возможность создать геоиндекс, о котором вы писали в статье.
Я изначально тоже собирал из Geonames, Wikipedia и других источников, но как всё это потом обновлять и поддерживать в актуальном состоянии? В тоже время сообщество osm достаточно активное, т.о. можно не дублировать работу по актуализации данных.
Немного порылся и пока не нашел источников у OSM :(
Координаты у меня уже есть, они все в базе. Алгоритм простой для геоиндексации тоже придумал
Координаты у меня уже есть, они все в базе. Алгоритм простой для геоиндексации тоже придумал
Например, можно выкачать данные здесь: http://planet.openstreetmap.org/
А с помощью osmosis можно извлекать только те данные, которые нужны http://wiki.openstreetmap.org/wiki/RU:Osmosis
А с помощью osmosis можно извлекать только те данные, которые нужны http://wiki.openstreetmap.org/wiki/RU:Osmosis
Догадываюсь, что у них нет склонений — им они не нужны?
Как обстоят дела с областями — есть ли все области всех стран мира? У Geonames с этим туго, сейчас приходится с Wikipedia скрейпить
Как обстоят дела с областями — есть ли все области всех стран мира? У Geonames с этим туго, сейчас приходится с Wikipedia скрейпить
Догадываюсь, что у них нет склонений — им они не нужны?
Да и не во всех языках они есть. Но у меня нет под руками данных, чтобы посмотреть, есть ли они в базе.
Как обстоят дела с областями
С этим у них гораздо лучше, чем у других гео-проектов. У них есть не только области, у них есть все точки их границ. Есть границы городов и их районов. В городах есть остановки и даже просто лавочки.
Это большое сообщество как википедия и оно вносит каждый день огромное число данных.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Пакет-географ – первая рабочая версия