Пакет-географ или библиотека, которая прекрасно знает географию и говорит на разных языках

    Во многих из проектов, в которых я участвовал, была необходимость использовать географические данные в том или ином виде. Даже самые простые сайты, как правило, имеют список стран или городов на какой-нибудь из своих страниц – магазины хотят знать, куда доставлять товары; социальные сети хотят знать, откуда пользователь; и так далее.

    Что далеко ходить – вот даже здесь на Хабре есть выпадающие списки стран, штатов и городов:

    image


    Мне (как, наверняка, и вам) много раз приходилось хранить подобные данные (скажем, список стран) и в массивах, и в базах данных, и в файлах конфигурации. Потом нудно добавлять варианты на других языках, когда у проекта появляется альтернативная языковая версия.

    Я вижу сразу несколько проблем и буду только рад если кто-то оспорит этот список:

    • Добавление географических данных и переводов засоряет рабочий проект, его хранилище данных. Не хочу лишних таблиц, не имеющих отношения к основному бизнесу!
    • Географические данные в проекте – это постоянное повторение, изобретение велосипеда заново. Набор стран и городов на планете меняется крайне редко, зачем же тогда отводить этим данным тёплое место в приложении?
    • Если в команде нет лингвистов и полиглотов, то в списки городов и стран могут запросто пробраться ошибки. Сколько русских до сих пор пишет «Таиланд» с и кратким?


    Географические данные – идеальный кандидат для отдельного пакета. Хочу ввести одну команду в любимом менеджере пакетов (будь то composer, npm или CocoaPods) и сразу получить возможность работать с географическими наименованиями. Хочу иметь что-то вроде модного http://momentjs.com/, но про географию. Поставил один пакет – закрыл эту страницу, так сказать.

    Удивительно, но таких пакетов пока не существует, поэтому я начал работу над своим. Для начала – версия на PHP. Эта статья является описанием моего подхода, а основными целями публикации можно считать сбор мнений от других разработчиков; оценку необходимости, актуальности пакета.

    Предлагаемая реализация


    Вот таким мне представляется оптимальный API для PHP на текущий момент:

    // Точка входа в пакет – класс планеты
    // В будущем надо добавить возможность создавать объект страны или города без родителя
    $planet = new Planet();
    
    // Планета, дай мне все свои страны, и на выходе преобразуй в массив
    $planet->getCountries()->toArray();
    
    // Хочу, чтобы имена стран были короткими по возможности – к примеру, США вместо Соединённых Штатов Америки
    $planet->getCountries()->useShortNames()->toArray();
    
    // Дайте мне все области Таиланда
    $countries = $planet->getCountries();
    $thailand = $countries->find(['code' => 'TH']);
    $thailand->getStates()->toArray();
    
    // Хочу теперь их на русском
    $thailand->getStates()->setLanguage('ru')->toArray();
    
    // Хочу теперь и в другой форме (к примеру, "в Таиланде" вместо "Таиланд")
    $thailand->getStates()->setLanguage('ru')->inflict('in')->toArray();
    
    // А где там у нас столица? Есть ли код geonames? А координаты точные?
    $capital = $thailand->getCapital();
    $capital->getGeonamesId();
    $capital->getLatitude();
    $capital->getLongitude();
    


    Этого уже достаточно чтобы очень быстро добавить списки из первого изображения на свой сайт.

    Для полного счастья хотелось бы ещё:
    // Поиск городов конкретной страны по почтовым индексам
    $russia->find(['zip' => '626430']);
    
    // Глобальный поиск по почтовым индексам
    $planet->find(['zip' => 'EC3R 6DN']);
    
    // Глобальный поиск по координатам
    $planet->find([
        'latitude' => 51.5078788,
        'longitude' => -0.0899208
    ]);
    


    Мне важно мнение людей на Хабре, но не стану кривить душой – я начал уже писать пакет для PHP не дожидаясь реакции публики. Пилотная версия есть на GitHub, и где-нибудь через месяц в ней появятся 3-4 первых языка и весь базовый функционал. Если кто-то хочет поучаствовать в разработке (особенно интересуют пакеты для других языков – JavaScript, Ruby, et cetera), то буду очень рад получить от вас личное сообщение.

    Связь с моделями приложения


    Предвижу вопросы вроде «но как же тогда запоминать город пользователя?», и ответ тут достаточно прост – в своей БД (или куда вы там записываете данные) используйте стандартные идентификаторы, такие как коды ISO 3166-1 для стран, коды GeoNames для городов и штатов. Проблем сопоставить код с его содержанием и переводом не будет, и привязаны к этому конкретному пакету вы не станете.

    Вопрос


    Главный вопрос, он же – цель этой статьи: пользовались ли бы вы таким пакетом в своих приложениях? Или предпочли бы и дальше сами хранить географические данные?
    Поделиться публикацией
    Реклама помогает поддерживать и развивать наши сервисы

    Подробнее
    Реклама
    Комментарии 49
    • +1
      коды GeoNames для городов и штатов

      А почему именно GeoNames? Это, вроде, не стандарт. Для "штатов" (административного деления) есть тот же ISO 3166-2.

      • –1
        Потому что есть ещё города, а для них нет никаких стандартных кодов, насколько я знаю. Штатам, скорее всего, полезно будет всё, что имеется – GeoNames, ISO 3166-2, FIPS. Таким образом будет делом разработчика – к чему привязаться.

        Ещё один плюс GeoNames – идентификаторы уникальны для всей планеты. Необязательно хранить код страны рядом с кодом области.
        • +1
          Потому что есть ещё города, а для них нет никаких стандартных кодов, насколько я знаю

          Так чем GeoNames лучше любой другой системы идентификации, хотя бы и собственной?

          • 0
            Модный на сегодня ответ – абстракцией. Уменьшением зависимостей, или то что в английском называется 'decoupling'.

            Если у меня имеется 5 приложений и всем нужны географические данные, мне проще на всех 5 использовать идентификаторы GeoNames, чем 1) использовать 5 разных наборов 2) придумывать свою конвенцию.

            А если выбирать не из своих систем – я не смог ничего глобального найти кроме GeoNames. Если есть что-то еще – то надо будет просто добавить эту систему в пакет, разработчик сможет выбрать, чему он больше доверяет в долгосрочной перспективе :)
            • +1
              Уменьшением зависимостей, или то что в английском называется 'decoupling'.

              Ровно наоборот, вы не уменьшили зависимости, а добавили еще одну — от GeoNames.

              • +1
                Если приложений было 5 – вы заменили 5 зависимостей всего одной.

                Если приложение было одно – вы заменили собственную кустарную (живущую в адресном пространстве конкретного приложения) зависимость – глобальной, стандартизированной, проверенной годами. Что не так уж и плохо само по себе! ;-)
                • 0
                  Если приложений было 5 – вы заменили 5 зависимостей всего одной.

                  Нет, потому что
                  (а) зависимости считаются для каждого приложения отдельно и
                  (б) собственный код не является зависимостью.


                  вы заменили собственную кустарную (живущую в адресном пространстве конкретного приложения) зависимость

                  Собственный классификатор не является зависимостью.


                  глобальной, стандартизированной, проверенной годами

                  GeoNames разве стандарт?

                  • 0
                    Хорошо, согласен про зависимости. Но все еще настаиваю на том, что работать в будущем (то, что называют термином 'maintainability') будет проще с приложением, использующим известные, документированные API и конвенции. В данном случае использовать GeoNames вместо специфичных для конкретного приложения идентификаторов – это как раз переход на API, на конвенцию, которую кто-то уже написал за нас.

                    Лично мне было бы удобно, что во всех моих приложениях код города 15 – это город X, и при этом мне не надо самому ничего документировать.

                    GeoNames – это, как говорится, не идеально, но лучшее, что у нас сегодня есть.
                    • 0
                      Но все еще настаиваю на том, что работать в будущем (то, что называют термином 'maintainability') будет проще с приложением, использующим известные, документированные API и конвенции.

                      Только в том случае, если эта конвенция (а) удобна для приложения (а не надо ее натягивать специально) и (б) известно, что она не изменится.


                      GeoNames – это, как говорится, не идеально, но лучшее, что у нас сегодня есть.

                      Кстати, что произойдет в GeoNames, если какой-то город переименуют? Или, что хуже, произойдет административная реорганизация?

                      • 0
                        У них есть поле – альтернативные названия города. Подозреваю, что старое название уйдет туда ;-) ID не сменится
                        • +1

                          … и что случится в этот момент в вашем интерфейсе в поле "пользователь родился в"?


                          И это только переименование. А представьте себе, что город удалили (или он разделился на две части). Или представьте себе, что пользователь хочет зачекиниться в городе, которого нет в GeoNames.

                          • 0
                            Вообще, все нормально будет — скажем, до 1991-ого года пользователь имел «родился в Ленинграде», после 91-ого «родился в Санкт-Петербурге» (что абсолютно верно). Ничего не меняя в базе или коде.

                            Пропадать города будут очень, очень редко. Не уверен, как GeoNames поступают в таких случаях. Если просто удаляют из базы навсегда — то да, надо думать как такие случаи обрабатывать.

                            В GeoNames есть все города с населением выше 1000 людей — этого достаточно должно быть большинству приложений.

                            Facebook, к примеру, имея миллиарды капитала, не может до сих пор многие ошибки в географии исправить. Подозреваю, что качество данных было бы выше, если бы любой пользователь мог исправлять ошибки (а в случае пакета на GitHub так и будет)
                            • 0
                              Вообще, все нормально будет — скажем, до 1991-ого года пользователь имел «родился в Ленинграде», после 91-ого «родился в Санкт-Петербурге» (что абсолютно верно)

                              Это с вашей точки зрения верно, а с его — не обязательно.


                              В GeoNames есть все города с населением выше 1000 людей — этого достаточно должно быть большинству приложений.

                              Что делать тем, которым недостаточно?


                              Подозреваю, что качество данных было бы выше, если бы любой пользователь мог исправлять ошибки (а в случае пакета на GitHub так и будет)

                              Вы совершенно зря так подозреваете. Даже GeoNames для предоставления более достоверных данных использует ручное курирование.


                              А главное, что делать, когда интересы пользователей конфликтуют? Например, для одного приложения нужно, чтобы Крым и Севастополь были частью Российской Федерации, для другого — чтобы нет. Как вы будете нормализовать иерархию в этом случае?

                              • 0
                                Ну, пограничные случаи всегда будут.

                                Если мой пакет будет полезен даже для 50% приложений – это уже будет прекрасный результат.

                                А использование собственной разработки или доработки, когда общедоступные реализации немного не подходят – это совершенно нормальное явление, его мы наблюдаем ежедневно. Всем не угодить, задача угодить многим :)

                                Про оспариваемые территории я пока еще думаю над решением :)
                                • 0

                                  Речь не о пакете. Речь о предлагаемом подходе


                                  Предвижу вопросы вроде «но как же тогда запоминать город пользователя?», и ответ тут достаточно прост – в своей БД (или куда вы там записываете данные) используйте стандартные идентификаторы, такие как коды ISO 3166-1 для стран, коды GeoNames для городов и штатов.

                                  Особенно неприятно будет, если мы сначала на него обопремся, а потом через год выяснится, что нам нужно использовать значение, отличное от "стандартного идентификатора".

                            • 0
                              Переименован — выводим новое имя.
                              Расформирован в связи с реорганизацией (удален, разделен, присоединен) — флаг депрекейтед. В зависимости от задачи — или не давать новым указывать, но старых оставлять или давать, но рекомендовать не использовать и т.п.
                              Неизвестный город? Тут или ручной ввод разрешать или выбирать более общий вариант — область, район, штат, страна…
                              • +1
                                Переименован — выводим новое имя.

                                Это не всегда верно.


                                Неизвестный город? Тут или ручной ввод разрешать

                                Как только вы разрешаете ручной ввод, вы теряете возможность использовать внешние коды как собственные первичные идентификаторы.

                                • 0
                                  GUID в рамках всей базы и галочка «не нормализован» для ручного ввода, с последующей заменой на нормализованное значение когда админ до этого доберется. Но именно поэтому я больше сторонник решения с деградацией до страны, чем ручным вводом.

                                  А вообще у каждого своя задача, но некоторый меинстрим существует, и под некритичные задачи что-то универсальное сделать можно. А дальше форкать…
                                  О том, что в магазине нужно давать человеку максимальную свободу я с Вами согласен полностью.
                                  • 0
                                    GUID в рамках всей базы и галочка «не нормализован» для ручного ввода, с последующей заменой на нормализованное значение когда админ до этого доберется.

                                    Вот именно поэтому и не надо использовать значения из GeoNames в качестве внутренних идентификаторов.


                                    Но именно поэтому я больше сторонник решения с деградацией до страны, чем ручным вводом.

                                    А так вы теряете пользовательские данные.

                                    • 0
                                      Ну это от задачи зависит.
                                      Если это форум/социалка и т.п., то указание населенного пункта с точностью до ближайшего пгт (а 1к+ в основном в базе есть) будет вполне себе нормальным вариантом.
                                      Да, согласен с Вами что такая библиотека не будет такой функциональной как момент, и надо будет пилить под задачу, но в качестве дефолтной фишки вполне себе хорошо было бы иметь.
                                      • 0
                                        Ну это от задачи зависит.

                                        Вот я и написал: в зависимости от задачи формат хранения отличается — но при этом видно, что задач, где можно использовать сторонний идентификатор как основной, не так уж и много.


                                        но в качестве дефолтной фишки вполне себе хорошо было бы иметь.

                                        Хорошо иметь сервис, который умеет отвечать на геозапросы (причем совершенно разных видов), но вот откуда для него брать данные — мне не очень понятно. Предложенная ниже идея аггрегации выглядит наиболее интересной, но это большая задача.

        • 0
          Даже самые простые сайты, как правило, имеют список стран или городов на какой-нибудь из своих страниц – магазины хотят знать, куда доставлять товары; социальные сети хотят знать, откуда пользователь; и так далее.

          Надо заметить, кстати, что в зависимости от задачи формат хранения — разный. Там где соцсеть может себе позволить делать любую нормализацию (потому что эти данные нужны ей и только ей самой), магазин — и вообще любая доставка — должны позволять пользователю ввести адрес так, как тот считает нужным. Да, с подсказками и предложениями исправить предположительно неправильное название, но без иллюзий о том, что магазин лучше знает, как выглядит нужный пользователю адрес.

          • 0
            Ну, выбор страны как правило – все-таки выпадающий список, даже если все остальное в свободном формате вводится. Это по моему опыту онлайн-шоппинга :)

            А тут в Австралии так вообще — любят принудительное распознавание адреса. Если сайт не смог распознать (интерпретировать) адрес — пользователь не может продолжить. Таким образом, можно использовать подобный пакет без проблем (точнее даже — он уменьшит количество проблем :)
            • 0
              Ну, выбор страны как правило

              Выбор страны можно сделать и по ISO.


              А тут в Австралии так вообще — любят принудительное распознавание адреса. Если сайт не смог распознать (интерпретировать) адрес — пользователь не может продолжить.

              Сочувствую. Фишка, однако же, в том, что Австралией мир не ограничивается.

              • 0
                Выбор – можно по ISO, а как пользователю отображать? :) А если сайт на 15 языках?

                Про Австралию согласен, это так – пример. Про адреса в свободной форме, мне кажется, было бы полезным какой-то умный парсер адресов сделать, который умеет приводить адреса вроде «УЛ НИКИТИНА МОСКВА» в «ул. Никитина, Москва, 125000 Россия». Точно знаю, что некоторым проектам это нужно
                • 0
                  Выбор – можно по ISO, а как пользователю отображать?

                  Речь в этой ветке идет о формате хранения, а не отображения.


                  Про адреса в свободной форме, мне кажется, было бы полезным какой-то умный парсер адресов сделать, который умеет приводить адреса вроде «УЛ НИКИТИНА МОСКВА» в «ул. Никитина, Москва, 125000 Россия». Точно знаю, что некоторым проектам это нужно

                  Некоторым, но не всем. Именно поэтому я и говорю, что реальный формат хранения сильно зависит от задачи.


                  А парсеры такие есть, и на хабре их уже неоднократно упоминали (по крайней мере, в части России), но они, очевидно, языкоспецифичны.

                  • 0
                    Речь в этой ветке идет о формате хранения, а не отображения.
                    Нормализация представления нужна.
                    В 1С есть такой парсер адресов, и работает примерно так:
                    * Нормализует введённую строку (по классификатору адресов),
                    * в базу записывает 3 значения: Код по классификатору, нормализованная строка, строка «как есть» от пользователя (кстати, данные в КЛАДР хранятся в очень понятном формате ключ-значение).
                    Я эту сохранялку адресов пару раз подгонял под новые стандарты компании, потому знаю, как оно внутри устроено.
                    • 0
                      Нормализация представления нужна.

                      Всем и всегда?

                      • 0
                        Мне, как программисту — нужна. Почте России тоже нужна, у них нормализованные адреса на конверте писать надо. Налоговой тоже нужен нормализованный адрес. Так что, нормализация нужна часто.
                        • 0
                          Мне, как программисту — нужна.

                          Ну, будем честными, пользователя это не очень волнует.


                          Почте России тоже нужна, у них нормализованные адреса на конверте писать надо.

                          Эээ, правда? Я несколько лет шлю по России открытки с адресами в формате "как сегодня проснулся", еще и латиницей часто — и ничего, доходит.

                  • 0
                    Это умеет dadata.ru
            • +2
              Перемудрили с API, на мой взгляд. И почему Planet а не Earth? Планет то много, а земля одна, родная.
              • 0
                Planet — это класс, а Earth — это конкретный объект, одна из планет :)

                Старался сделать все максимально рационально.

                Объект Planet всегда один и тот же, и это всегда Земля:

                    /**
                     * @return string
                     */
                    public function getShortName()
                    {
                        return 'Earth';
                    }
                
                    /**
                     * @return string
                     */
                    public function getLongName()
                    {
                        return 'The Blue Marble';
                    }
                
                • +1
                  Тогда логичнее было бы делать интерфейс планеты, и класс Земли который его имплементирует. Потому что обращаясь к Planet мы не выбираем Землю как планету, то есть это даже не фабрика, а просто Земля, которая названа Planet.
                  • 0
                    Да, я уже понял ошибку — неудачно выбрано название.

                    Как минимум, в примере надо сделать имя переменной $earth, чтобы логика соблюдалась :) И объявить, что другие планеты создавать (как перевести instantiate?) пока нельзя

                    Насчет интерфейсов — я пока склоняюсь (на GitHub код уже видно) к абстрактному классу для всех видов делений вместо интерфейсов для разных уровней делений. Есть класс Divisible (делимый), и пока что логика планеты, стран и штатов почти полностью совпадает — это решение пока похоже на оптимальное.
                    • 0
                      Впадать в ООП безумие мне кажется не стоит. Убрать планету вообще, назвать только входной класс Землей, без стандартных методов, типа имени и расположения. Это конечно забавно, но практического смысла не имеет.

                      А вот что реально было бы хорошо иметь, это разные источники данных, база/файлы/пусть даже интернет. Плюс сделать возможность кеширования тех данных что ты вытаскиваешь.

                      Поиск по координатам, как я понял устроен топорно и просто сравнивает значения? Это плохо. В некоторых базах есть возможность искать координату приблизительно, да и алгоритмы для поиска есть. Это конечно в пределах пхп работать будет не очень быстро, но хотя бы честно.

                      Вещи типа useShortNames не совсем понимаю зачем? Если можно возвращать в том же массиве оба варианта. Метод inflict мне тоже не понятен, почему это должна делать библиотека, которая используется как база данных?

                      В общем, проще засунуть эти данные в монгу, взять какой-нибудь ODM, и будет так же хорошо, и даже намного лучше, ибо сложные запросы, поиск по координатам и т.д.
                      • +1
                        А вот что реально было бы хорошо иметь, это разные источники данных, база/файлы/пусть даже интернет. Плюс сделать возможность кеширования тех данных что ты вытаскиваешь.


                        Про это я уже думаю :)

                        Поиск по координатам, как я понял устроен топорно и просто сравнивает значения? Это плохо. В некоторых базах есть возможность искать координату приблизительно, да и алгоритмы для поиска есть. Это конечно в пределах пхп работать будет не очень быстро, но хотя бы честно.


                        Поиска пока нет вообще – он просто показан в примере. В современных БД есть гео-индексы. Как поступить тут и сохранить при этом маленький размер – я ещё думаю.

                        Вещи типа useShortNames не совсем понимаю зачем? Если можно возвращать в том же массиве оба варианта. Метод inflict мне тоже не понятен, почему это должна делать библиотека, которая используется как база данных?


                        Сначала так и было – два варианта. Ход мыслей дальше был такой: длинный (полный) вариант есть всегда, короткий иногда. Если возвращать оба поля и одно из них может быть пустым – разработчику придется на своей стороне (приложения) делать условия, а условия уже давно никто не любит.

                        То есть, если я могу попросить useShortNames(), то после этого я могу просто отображать одно поле, а пакет его выбирает по принципу best effort (старались как могли).

                        Inflict() – потому что больше половины сайтов до сих пор не умеют правильно склонять слова русского языка. Скажем, у нас есть какая-то лента или стена, и там есть подписи вроде: «Написал Иван 5 минут назад из Владивостока». Где хранить правильную форму имени города?

                        В общем, проще засунуть эти данные в монгу, взять какой-нибудь ODM, и будет так же хорошо, и даже намного лучше, ибо сложные запросы, поиск по координатам и т.д.


                        Так все и делают, включая меня – и это занимает много времени, требует установки дополнительных сервисов и так далее. Было бы очень классно иметь легкую, независимую (от внешних демонов) библиотеку, которая покрывает хотя бы все базовые требования.
              • +1
                Страны на разных языках есть из коробки в php-intl, хоть и с мудреным апи.
                А в Symfony Intl есть удобная абстракция над большинством справочных материалов intl, причем все с использованием iso, а не велосипедия.
                • 0
                  Спасибо — посмотрел и то, и другое. Но, IMHO, не хватает падежей (хотя это, конечно, только для русского языка актуально) и возможности выбрать менее формальное название. Причем, они это никогда не добавят, потому что в рамках их библиотек это лишнее.

                  Если сайт на, скажем, английском, и нужен просто список стран — то можно intl использовать.
                • +1
                  Идея геопакета хороша, но мне кажется основная проблема здесь не как назвать классы и методы, а как максимально автоматично заскриптовать сбор данных и обновления для обновления этого пактета. Понятно, что список стран и крупных городов будет относительно статичным, но все что ниже обновляется очень активно, тем более в масштабах планеты.
                  Есть много много разных БД, и для разных целей и разных местностей подходят разные базы. Например для России есть регулярно обновляемый КЛАДР, но в нем только адреса, нет геокоординат, нет возможности искать по запросам типа «Кафе у Ашота», и она не переведена на другие языки. У других стран есть свои подобные базы, есть базы OpenStreet, но у всех чего-то не хватает.
                  В общем, было бы хорошо иметь такую аггрегированную базу всего, и пакет, который бы к с ней работал, но подозреваю, что в итоге получится что-то типа геосервисов Гугла или Яндекса, который одному человеку не потянуть.
                  • +1
                    Ага. Шаг первый — стандарт базы.
                    Шаг второй — реализации (данные) поверх стандарта.
                    Шаг третий — библиотеки поверх данных (например, города России на русском, штаты на английском, города мира на русском, города мира на всех языках, все города на всех языках в конце концов).
                  • 0
                    пользовались ли бы вы таким пакетом в своих приложениях? Или предпочли бы и дальше сами хранить географические данные?

                    Однозначно, да!
                    Тривиальная задача, особенно актуальна для разработки сайтов (небольших проектов), т.к. надоедает просто копировать дамп базы из проекта в проект, при этом нужно поддерживать актуальность списка стран, регионов/штатов, городов.
                    Так же надо учитывать тот факт, что в бд может хранится ненужные геоданные, например, про Африку, что не совсем нужно, когда проект не ориентирован на ее жителей.
                    • 0
                      Не смотрели в сторону Geocoder? Мне думается, он мог бы помочь в реализации вашего пакета.
                      • 0
                        Посмотрел только что — мне кажется это больше в сторону трансляции координат в адрес и наоборот, не увидел ничего про локализацию там (а у меня это основная цель).
                    • 0
                      Не мешало бы сразу предусмотреть некое деление данных на части. Я о том, что если мой магазин работает только с могилевской областью Беларуси, то мне не хотелось бы в своей БД хранить данные об остальных областях, не говоря уже о всех населенных пунктах, областях, регионах, округах,… более чем двух сотен стран мира.

                      То же касается и языков. Далеко не каждому сайту нужно более 3-4 языков. Имхо.
                      • 0
                        Да — я сразу это во внимание беру

                        1) Сами данные будут подгружаться в режиме ленивой загрузи
                        2) Если базы станут большими, я думаю детализированные базы по странам можно будет выделить в отдельные репозитории. Тогда в начале разработчику просто 2+ пакета надо будет устанавливать — основной и необходимая база, набор языков
                      • 0
                        Очень хорошее начинание, имхо.
                        • 0
                          Очень интересная идея. Я сам на днях думал о чём-то похожем. Но думал больше с точки зрения того, где брать сами данные? Вот где взять в удобном формате список стран (ну это легко)? А может для какого-то проекта потребуется список всех фильмов, музыкальных исполнителей и т.п. Хотелось бы найти такой ресурс, где всё это доступно в открытом виде и машиночитаемом формате. Есть ли нечто подобное?

                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.