Geographerパッケージ-最初の作業バージョン

まず、 以前の投稿の結果に基づいて、Habrの読者が私にくれたGitHubの80以上の星に感謝します。 これは、 リポジトリがほとんど空であり、リンクが明らかではなかったという事実にもかかわらずです。 このパッケージの有用性に直面して!







最初の投稿を逃した人のために、小さな繰り返し。 次のようなものがある場合:









またはそのようなもの(VKは南メルボルンをまったく翻訳できませんでした):









次に会う(ドラムがノックしている)-GeographerライブラリはPHPバージョンで利用可能です。 この記事では、自分のサイトの例を使用して、新しいパッケージに切り替えることの利点を示します。 実際、アイデアはライブラリを作成するために思いつきました-私はしばしば異なるアプリケーションで同じ機能を繰り返し始め、開発者の世界で今日繰り返し始めることに気付きました-まあ、それはどういうわけか流行りません。







設置



パッケージはPackagistで公開されているため、1つのコマンドでインストールできます。







composer require menarasolutions/geographer
      
      





依存関係はありません-これは現時点での開発の主要な原則の1つです。 パッケージのユーザーに追加のソフトウェアまたは他のパッケージのインストールを義務付けたくありません。 それでも、オプションの統合-Memcached、MongoDBを追加する予定です。







例1:国の簡単なリスト



最も一般的な例は、膨大な数のサイトで見られます。 開発者は、世界各国のドロップダウンリストを表示する必要があり、おそらく異なる言語をサポートしています。







私のアプリケーションにあったように:







  public static function getCountryNameByCode($countryCode, $language) { return Config::get('texts.countries')[$language][$countryCode]; }
      
      





ここではすべてがかなり平凡です-Configクラスファサードはテキストファイルに示された配列へのアクセスを提供し、言語と国コードキーを使用して必要な翻訳を取得します。 多くの人がそうであったように、どこも簡単ではありません。







このアプローチの短所:

-これらの翻訳をアプリケーション内に保持する必要がありましたが、ビジネスロジックとは直接関係がありません。 -最初は、すべての翻訳を手動で追加する必要があります。 私はただ新しい言語を取り入れて仕事を始めることはできません。

-コードを読むことは可能ですが、あまり直感的ではありません。







地理的ライブラリに切り替えると、次のようになりました。







  public static function getCountryNameByCode($countryCode, $language) { return Geographer::findOneByCode($countryCode) ->setLanguage($language) ->getName(); }
      
      





見つかった利点:

-現在、翻訳はアプリケーションの外部にあり、時々それ自体が更新および改善されています。

-すぐに使用できる多くの一般的な言語。

-コードがより直感的で読みやすくなりました。

-特定の段階で適切な例外をスローすることが可能です-国が見つかりません、言語が見つかりません。







例2:正しい形式のアイテムの名前



しかし、これはすでにより複雑であり、ここで別のライブラリに切り替えることの利点ははるかに顕著です。 私は同様のリンクを持つサイト上のページを持っています:









または、SEO向けに最適化されたコメントを使用して:









最も単純で最も一般的なソリューションは、各単語形式に対して、アプリケーションにさらにいくつかの配列または参照を追加することです。 したがって、数百または数千の翻訳がすでに表示されており、それらの多くは手動で追加または編集する必要があります-Geonamesのようなほとんどのディレクトリは、偏位を提供しません。







次のような結果になることがあります。







  public static function getCountryNameByCode($countryCode, $language, $form = 'default') { return Config::get('texts.countries')[$language][$countryCode][$form]; }
      
      





しかし、時には必要な形式がなく、いくつかの条件を追加したい場合があります。たとえば、「from」という正しい形式がない場合は、「from」という前置詞と標準形式を導出します。 そして、メソッドは徐々に条件の多いモンスターに変わるか、新しいクラスを追加する必要があります-そして、アプリケーションは完全に異なるものに焦点を当てる必要があります。







しかし、それだけではありません-私たちのほとんどはWebサイトでテンプレートとテキストファイルを使用します。国(または都市)のディレクトリまたはテンプレート文字列で、口実をどこに保存するかという疑問が生じます。 つまり、「イベント:都市」または「イベント:都市」のようなテンプレートを作成します。 最初のケースでは、「in France」など、優れた前置詞が必要な名前のニュアンスがあります。 第二に、辞書には膨大な数の繰り返しがあり、コードには追加のロジックがあります。







私のライブラリを使用する場合:







  public static function getCountryNameByCode($countryCode, $language, $form = 'default') { return Geographer::findOneByCode($countryCode) ->inflict($form) ->setLanguage($language) ->getName(); }
      
      





事前配置は、 includePrepositions()



およびexcludePrepositions()



メソッドを使用してオンとオフをincludePrepositions()



ことができます。これにより、任意のテンプレートでライブラリを使用できます。 どの口実が正しいかを考える必要はありません。 現在の言語が国の名前をどのように傾けているか、前置詞がこれから変わるかどうかに注意する必要はありません。







APIの概要



収集方法



部門の配列(国、地域、都市)は、今日の人気のあるコレクション(Fluent APIをサポートするスマートアレイ)を通じて実装されます。







 $states->sortBy('name'); //     $states->setLanguage('ru')->sortBy('name'); //    $states->find(['code' => 472039]); //      $states->findOne(['code' => 472039]); //     $states->findOneByCode(472039); //    
      
      





一般的な方法



すべての部門クラスは1つのクラスの子孫であり、共通のメソッドがあります。







 $object->toArray(); //      $object->parent(); //   (  ,   ) $object->getCode(); //  ID $object->getShortName(); //     $object->getLongName(); // ,  
      
      





ユニットに関するすべてのデータは、さまざまな方法で取得できます。







 $object->getName(); //   (   ) $object->name; //   $object['name']; //     $object->toArray()['name']; //     
      
      





惑星クラス



 $earth->getAfrica(); //   $earth->getEurope(); //   $earth->getNorthAmerica(); //      $earth->getSouthAmerica(); $earth->getAsia(); $earth->getOceania(); $earth->getCountries(); //    $earth->withoutMicro(); //      100,000
      
      





ライブラリとアプリケーションの関係



地理的単位のすべてのデータを別のライブラリに入れると、アレイ(またはデータベースなど)を安全にクリーニングできますが、特定の都市(または国または地域)間の接続を何らかの方法で修正する必要があります)データベース内のレコードとライブラリ内のレコード。







ライブラリの長期的なポリシーは、開発者自身がキャッチするものを選択できるように、できるだけ多くの一意の識別子を開発者に提供することです(おそらく、データベースに新しいフィールドを追加する必要さえありません)。







現在、国にはISO 3611-2、ISO 3611-3、およびGeonamesのコードがあります。 エリアには、ISO 3166、FIPS、およびGeonamesコードがあります。 都市にはGeonamesコードのみがあります-これは最も柔軟性のない場所です。







したがって、たとえば、サイトにユーザーの都市を表示するために、ユーザーテーブルにgeonames_id



し、そこからオブジェクトを復元できます。







 $city = City::build($geonames_id);
      
      





最新のフレームワークのほとんどは、この変換を自動的に行うこともできます。 さまざまな国際識別システムを具体的に選択しました。開発者と彼のアプリケーションは、Geographerライブラリーに結び付けられるべきではありません。 拒否するには、使用を開始するのと同じくらい簡単にする必要があります。







今日のカバレッジ



データベースには、人口5万人を超える世界のすべての都市、すべての地域および国が含まれています。







各国にはデータがあります:









都市と地域には名前と一意の識別子があります。







名前は言語に翻訳されます:ロシア語、英語、スペイン語、イタリア語、フランス語、中国語(Putonghua)。

国については、地域や都市については100%のカバレッジです-少ないですが、常に更新されます。 翻訳されていない都市については、単純な音訳の可能性を追加することが提案されています。







すべての国は正しく傾向があります-オンラインスペルチェック辞書で確認します。







今後の計画



  1. 座標を使用して最も近い集落を取得できるように、プリミティブジオインデックスを追加する予定です。







  2. 開発者が不要なJSONディレクトリをダウンロードする必要がないように、異なる言語は別々のリポジトリに分散される可能性が最も高くなります。 さらに、JSONディレクトリはクライアントライブラリから独立し、将来のPythonおよびRubyクライアントに関連付けることができます。


ミッションはシンプルです-Web開発者の標準ジオライブラリになること。 十分な人気が得られると、さまざまな国のユーザーからプルリクエストを介して翻訳を修正することを期待できます。ディレクトリは、Wikiのように常に改善されます。







APIに関するコメントや提案を聞いて非常にうれしいです!








All Articles