タグ別アーカイブ: ディレクターさんへ

6/11からグーグルマップの料金体系が変わるよ。クレジット登録してね。[Action Required] Changes to your Google Maps APIs account

Published / by hihihi / Leave a Comment

またgoogleさんから英語のお手紙きた

早朝から対処する必要があるとか言われてビビってみた。

googleさん改定多いね

(さらに…)

GDPRまわりでいろんなサービスの規約が変わるよ

Published / by hihihi / Leave a Comment

GDPR

「一般データ保護規則(General Data Protection Regulation:GDPR)」

ざっくりいうとヨーロッパでの個人情報データの保護に関する法律が5月から適用される。
それにあたり、全世界的に個人情報データの取扱に関しての規約を変更(追記)される流れがある。

よく英語のお知らせメールでで「件のGDPRの影響で。。。。」「GDPR対応のため。。。。」という本文を見かけるのはこのため。

これから増えそうなのでメモっとく。

日本企業も大きな影響を受ける「GDPR」–まずは「対象か」の確認を – ZDNet Japan
https://japan.zdnet.com/article/35110326/

EU一般データ保護規則(GDPR)の概要(前編) | NTTデータ先端技術株式会社
http://www.intellilink.co.jp/article/column/security-gdpr01.html

EU一般データ保護規則 – Wikipedia
https://ja.wikipedia.org/wiki/EU%E4%B8%80%E8%88%AC%E3%83%87%E3%83%BC%E3%82%BF%E4%BF%9D%E8%AD%B7%E8%A6%8F%E5%89%87

先週googleさんからActionRequiredってメール突然英語で来てびびったけど

Published / by hihihi / Leave a Comment

翻訳しながら見たらダイジョブだった。
わかんない人もいるかもだから忘却録がてら記事書こうと思ってスクショまで取ったのに忘れてた。
そしたら日本語でもいちど一昨日メールが再度来てたので思い出した。
分かりづらかったんだ〜やっぱブログ書いときゃよかった〜もう他の人が記事書いてるだろうけど〜〜
などと思ったのでいちおう書いとく。 (さらに…)

多言語対応サイトでは訪問時にどうサイトを表示させるのが良いだろう?

Published / by hihihi / Leave a Comment

タイトルまんま。

ええっと、表示方法や出し分け方法っていろいろ手法があるんやんな、どれがえんやっけ。今まで悩んだこと無いの、なんでやっけ。

サイトで多言語対応するにあたっての、ブラウザ言語設定での切り替え・出し分け・ローカライズ(?)に関する考察。

ユーザーにとってほんとに良いのはどういう挙動だろう?

これの最適解まとめたのってあんま見たことないなぁ〜と思ったので、時間出来たので調べてみました。そして調べる最中頭こんがらかったり、情報整理する必要が出たりしと挫折しそうになったので、同志のために記事にまとめました。あかんところあったらゆーて下さい。

頭に浮かんだ手法羅列

  • いったんデフォルト言語で出してユーザーが必要に応じてボタンなどから切り替え
  • URLのクエリで言語設定して該当言語のコンテンツをPHPでインクルード
  • ブラウザ言語設定を参照して該当言語のコンテンツを格納したページへリダイレクト
  • ブラウザ言語設定を参照してajaxでコンテンツをページ内で出し分け
  • PHPロケール情報から判定
  • 各言語ページの一個上の階層に親ページを用意して選択
  • 文字サイズボタンみたいにcookieで記憶させといて2回目以降訪問時に出し分け
    「コンテンツの表示の仕方」と「ユーザー言語の判定の仕方」と「ディレクトリ(URL)の作成方法」の問題が全部ごっちゃになってますが、いったん羅列、です。

結論

訪問時は特に出し分けはしない、もしくはサイトTOPへの初回訪問時のみブラウザ言語設定の言語のコンテンツを表示させるなどする(手法はJSでもPHPでも。)

サイト内に言語の切り替えボタンは必須。そこからユーザーの意志で各言語に行き来出来るようにする

最終で見ていた言語をcookieで保持しておいて次回訪問時にコンテンツをajaxで出し分け、とかもできればしない。(ユーザーが意図せぬ挙動となる可能性・検索結果が最適化されない問題)

ディレクトリ等コンテンツ自体を各言語で作成し、URLさえ叩けば目的言語のコンテンツに行けるようにするのが吉。

以上。一般的にはこうかと。もちろんコンテンツの内容や構成、目的によって例外もあり。理由は次項「理由」にて。

ex)
日本語
https://example.com/
https://example.com/about/
↑↓(※共通パーツとして各言語間を行き来出来るボタンをサイト内の目立つ位置に置く)↑↓
英語
https://example.com/en/
https://example.com/en/about/

一番単純なのが吉ってことですね。

今まで悩んだこと無いのは最適と思われる形が単純なものだったからか。

出し分けの具体的な手法メモったのは下の方に移動しました。ほんとは真っ先に調べたんだけど。
記事書いていろいろ情報をたどる間にいろいろ変にいじんないほうが良さそうだなーってなったので。

理由

サイトの情報を利用するのはエンドユーザーだけではないから。検索エンジンのクローラーに正しい情報を提供する→エンドユーザーを適切なコンテンツへ導く手助けにもなるよねって話。

(さらに…)

インスタAPI連携をPHP使わずJSだけで実装する危険性について

Published / by hihihi / Leave a Comment

JSのみで実装してしまうことの危険性

以前JSのみで実装をしていた人にアカウントに紐づく普段は見れない情報を平文で書いてしまうなんて。。。という話をしていたのですが、なぜだめなのかをうまく説明できなかったのでまとめを探した。

アクセストークンを平文で書いてしまうことの危険性

http://guisekit.com/web/instafeedjs/
http://guisekit.com/web/instagram/

https://syncer.jp/instagram-api-matome#sec-14

(さらに…)

俺が考えるレスポンシブ対応最新のブレイクポイント 2017

Published / by hihihi / Leave a Comment

max750pxブレークでサイトを作ることが多かったのですが

タブレット対応のお話をしていて、ふとそういや最新ってこれでほんとにこれのままじゃろか。えんじゃろか。と、調べ直したのでメモ。
お客さんに多分これじゃね〜?とか言えないもの…!言えないもの…!

レスポンシブの現状最新のブレイクポイントってどないなっとんぞ

iPhoneXの投入による変更などは特に無かったようですし、
余裕があれば下記のようにするのでしょうが…

(さらに…)