Hatena::ブログ(Diary)

Webデザインの日々日記 RSSフィード

2016-08-07

作成したWordPressテーマの国際化(i18n)対応方法

もっとも簡単な方法をメモ

普通に調べるとコマンドラインがどうたらこうたらとか難しい話が出てきたり、Poeditのバージョンが上がってUIが少し変わっていて戸惑ったので忘れないようにメモ。

※以下、WordPressテーマは"ki-orion"という名称を例にしています。

国際化手順

0 Poeditのインストールとベースになるpotファイルのダウンロード

コマンドラインとかはまだ使えないんでGUIツールを使います。

Poeditのダウンロード

有料版の方がWordPress対応が優れているそうですが、手間をかければ無料版でも使えます。本記事は無料版での手順になります。

Poedit - Gettext Translations Editor

インストール手順は省きます。普通にやれば普通にインストールされますので。

WordPressのpotファイルのダウンロード

GitHub - fxbenard/Blank-WordPress-Pot: Blank-WordPress-Pot is the starter pot file to include in your language folder

緑の「clone or download」のボタンでzipファイルをダウンロード、ローカルで展開。

参考:WordPress プラグイン・テーマ翻訳: Poedit 無料版で新規 POT ファイルを作成する | ja.naoko.cc

1 テーマのフォルダに languages というフォルダを作り、potファイルを設置。
  1. 作成したテーマのテーマフォルダ直下に"languages"という名前のフォルダを作成。
  2. このフォルダに先ほどダウンロードした「Blank-WordPress.pot」ファイルを複製。
  3. 複製したBlank-WordPress.potの名前をテキストドメインの名前に変更。

今回のテーマの場合、Blank-WordPress.pot を ki-orion.pot に変更。

2 テーマのstyle.css/プラグインのコメントヘッダーにテキストドメインの情報を書く。

テーマの場合

Theme name: ki-orion
 (中略)
Text Domain: ki-orion

テキストドメインはテーマ名と同じにする方がよいらしいです。

また、テーマの名前は他の人が作って公開しているテーマと重複していないか、公式ディレクトリで検索して確認しておくことが必要。

3 テーマの日本語部分をすべて国際化関数に変更する。

Poeditは翻訳用コードを抽出して辞書ファイルを作るので、テーマやプラグインは翻訳以外は完成している必要があります。

国際化関数の書き方(テキストドメインがki-orionの場合を例に)

翻訳結果を出力する場合: <?php esc_html_e('words','ki-orion');?>

変数に入れる、関数内で使用する場合: <?php esc_html__('words','ki-orion');?>

※単に <?php _e('words','ki-orion');> や <?php __('words','ki-orion');> でもOKだが、セキュリティ強化のためエスケープをかけておく。

4 potファイルの設定変更

potファイルを開く。

f:id:k3akinori:20160806232440p:image

メニューの「カタログ」→「設定」を選択。

f:id:k3akinori:20160806232442p:image

「プロジェクト名とバージョン」、「翻訳チーム」、「翻訳チームのメールアドレス」を適宜変更。プロジェクト名はテーマのドメイン名(テーマ名)にする。

文字コードは「UTF-8」。これはデフォルトで選択されているはず。

「更新する」ボタンをクリック。

ソーステキストが検索され、表示される。

「保存」ボタンで保存。

5 jp.poファイルの作成

メニューの「ファイル」→「名前を付けて保存」をクリック。

保存画面でファイル名を「jp.po」に変更して保存。(ファイルの種類ではpotしか選択できないように見えるが無視する。)

6 jp.poファイルの編集

一旦Poeditを終了し、再度立ち上げ。

f:id:k3akinori:20160806232444p:image

「翻訳言語がソース言語と同一です。」のアラートが出るので、「言語を修正」ボタンをクリックして言語を「日本語」に修正する。

複数形の項目は「この言語のデフォルトルールを使う」を選択。

日本語はスクロールバーを一番下までもっていくと出てくる。

「OK」ボタンを押すと翻訳が可能になる。

f:id:k3akinori:20160806232446p:image

ペインに表示される「翻訳の提案:」に適当なものがあればそれをクリック。

f:id:k3akinori:20160806232447p:image

無ければ「翻訳」欄に自分で入力する。

もしも「未確定」ボタンが有効になっていた場合、

f:id:k3akinori:20160806232448p:image

「未確定」ボタンを押して未確定状態を解除する。(翻訳が確定していないと反映されない)

7 jp.moファイルの作成

デフォルトの設定ならこのまま「保存」を押すとmoファイルが自動的に生成される。

メニューの「ファイル」→「MOにコンパイル」をクリックしても生成することができる。

参考URL,文献

2014年版: WordPress プラグイン・テーマの翻訳を始めてみよう | ja.naoko.cc

WordPress プラグイン・テーマ翻訳: Poedit 無料版で新規 POT ファイルを作成する | ja.naoko.cc

ふじこのプログラミング奮闘記 - Wordpressで翻訳が反映されない場合のチェックリスト

2016-07-23

Re:知らないと恥ずかしい。今さら聞けない、読みにくいタグ用語15選。

別に読めなくても恥ずかしくはない。

【HTML&CSS】知らないと恥ずかしい。今さら聞けない、読みにくいタグ用語15選。【プログラミング】 - いしだの話

どちらかというとタグではないものをタグと呼んでいるあたりが気になるかな。

あとどこから手に入れた知識かは知らないけど読み方は一部を除いてあまり気にする必要はないと思う。

a

アンカーは正式名称。普通はエーと呼んでいる。むしろアンカーでは通じないことが多いと思う。

href

これタグじゃなくて属性ね。

エイチレフ、なんでhだけ別なんだと言うけど、英語では最初の文字だけアルファベットで読むことはよくあること。

元になっているのはHypertext referenceだから、エイチレフと読む方が意味を忘れにくくなる。

ちなみにリンク先を指示する属性にはsrcもあり、ソースと呼ぶらしいが僕はエスアールシーと(心の中では)読んでいる。sorceから来ているから正しくはソースなのだが、タイプするときはエスアールシーと唱えている。

alt

だからそれは属性だと(ry

まあ、オルトだよね。キーボードのAltもオルトだし。オルタナティブ代替)だからオルトだ。imgタグにはaltを付けろ。中身が空でもaltを付けろ。付けないやつはアレだよアレ。

dir

これも属性(3度目)。


なんか元記事の人がごちゃまぜにしている感じがあるので念のため書いておくと、単にタグというと<>で示された文字列のことを指し、「何とかタグ」というときは通常「要素(要素名)」のことを指す(分かりやすい解説はこちら)。「pタグ(p要素)」、「divタグ(div要素)」ということはあっても、「altタグ」なんて言い方はしない。


dirは滅多に使わないので念のため調べてみたけど、要素としてのdirも、遠い昔には存在していたらしい。しかし今は非推奨要素なので使うべきではない(<DIR>?HTMLタグリファレンス)。

現在HTMLで使うdirは属性において使われているdirのことを指し、このdirはディレクトリ」ではない。directionalityのdirだ。(参照)

縦書きサイトやアラビア語など、文字の記述方向を制御する際に使う。

width, height

ウィドスと読む人も多いし日本じゃそれで通じるから気にすんな。ウィズやウィズスやウィスと読む人もいる。英語圏ではウィス(スは舌を噛む発音)とハイトでないと通じないので覚えておいて損はないはず。面倒なので幅と高さと言ったっていい。

i, p, q, u, em, HTML

全部普通にアルファベットで読め。 いちいち正式名称で読むな。これらを全部正式名称で読むやつに出会ったことはない。qをクォートと読んだら「<q>」ではなく「'」の方を思い浮かべる人の方が多くて誤解を招きかねないのでむしろ正式名称で読むべきではない。

別に読めなくても恥ずかしくはない。

大事なのはどうやってうまくコミュニケーションするかという問題であって、正しい読み方なんてのは些末なこと。「正しい」のを知っていても顧客が間違った読み方の方で覚えていたら、そっちに合わせた方がスムーズに話が進むし角が立たない。恥ずかしいのは「間違った読み方」をすることではなく、「通じない話し方」の方ではないだろうか。

そもそも多くのウェブデザイナー・コーダーは正しい読み方なんてちゃんと習わずにやってきた。大事なのは正しく使うことであって正しく読むことではない。

2016-07-06

Windows游ゴシックがかすれる問題対策

少し前に話題になったWindowsの游ゴシック、游明朝が汚い(かすれる)という問題について、表示をまともにするための方法を検討することにしました。

これまでの経緯

Windowsで游ゴシックが汚いのは、どう考えてもWebデザイナーが悪い? | Cherry Pie Web

Windows で游ゴシックが細字になってしまう件は誰が悪いのかについて CSS 仕様から考えてみる | WWW WATCH

Re : Windowsで游ゴシックが汚いのは、どう考えてもWebデザイナーが悪い! - to-R

表示検証

環境

今回は游ゴシック体のみで確認。

OSWindows10

font-family: "游ゴシック", "Yu Gothic", YuGothic, "ヒラギノ角ゴ Pro W3", "Hiragino Kaku Gothic Pro", "MS Pゴシック", "MS PGothic", sans-serif;

font-size: 16px;

結果

ブラウザは左からchrome, Firefox, Edge, IE11

※コメントからの指摘で気づきましたが、以下のスクリーンショットではchromeの欧文書体が游ゴシック以外のものになってます。指摘後、"游ゴシック"のみの指定して、また元に戻したら欧文フォントも游ゴシックになったので何でこんなことになったのかさっぱり分かりません。スクリーンショット撮り直すのも面倒なんでこのままにしときます。

1.特に何も指定しない場合

f:id:k3akinori:20160706181734p:image

2.font-weight: 500; を適用した場合

f:id:k3akinori:20160706181735p:image

chromeの表示がましになる一方、他のブラウザのフォントも濃くなりました。

3.font-weight: normal; color: #000; text-shadow: 0px 0px 0px #000; を指定した場合

f:id:k3akinori:20160706181736p:image

chromeは細さそのままで色が濃くなり、Firefoxはfont-weight: 500;とほぼ変わらず。Edge, IE11ではジャギーが発生して汚くなりました。(Wの斜め線で顕著にみられます)

4.font-weight: normal; color: #333; text-shadow: 0px 0px 0px #666; を指定。IEのジャギーがごまかせないか試してみました。

f:id:k3akinori:20160706181737p:image

成果はあまり芳しくありません。

結論

今回の問題は、Windowsの問題という面もありますが、それ以上にChromeのレンダリングが下手くそという面も大きいのではないかと思います。Chromeがノーマルで游ゴシックLightを使う問題(バグ?)ということかと思います。(コメントを受け修正)

text-shadowで濃くするのも一定の効果はありますが、今度はIEがshadowのレンダリングが苦手、ということが分かりました。

すべての条件下できれいに描画したのはFirefoxで、さすが、Mosaicの系譜といったところでしょうか。

追記:現時点の対策法

問題がWindows chromeに限定されていて、それはfont-weight: 500;で解消されることまでは間違いないので、JavaScriptを使ってUAを判別し、chrome専用のCSSを読み込ませて解決することにしました。

<head>内に以下を記述

<script>
 var ua = window.navigator.userAgent.toLowerCase();
 if (ua.indexOf("chrome") != -1){
    document.write('<link rel="stylesheet" type="text/css" href="chrome.css" />');
 }
</script>

chrome.cssに以下を記述

html {
	font-weight: 500;
}

2016-07-02

主要なCSSプロパティを5つ紹介するよ!

ここ数日なんか流行っているので悪乗りしてしまおうという魂胆。

主要なプログラミング言語 5種類を徹底解説! - Programming share

主要なプログラミング言語8種をざっくり解説 - shi3zの長文日記

主要でもないプログラミング言語200種を一行で解説 - Qiita

文系のおっさんが主要なプログラミング言語8種をざっくり解説 - だるろぐ

てかプログラミング言語って200以上もあるんだ……

プログラミング言語はよく知らないのでCSSでいってみよー!

max-width

レスポンシブデザインが主流になってからものすごく出番が増えたプロパティ。

img {
 max-width: 100%;
 width: auto;
 height: auto;
}

ってやると、元画像サイズよりもウィンドウ幅が小さくなったら自動的に縮んでくれます。

たまにレスポンシブ対応を謳っているのにwidth:100%;だけでサイズ指定していて、大画面だと画像が引き延ばされてボヤァ〜ってなっちゃう残念なテンプレートがあったりして悲しくなることもありますね。

display

あらゆる要素の特性を変えてくれたり存在そのものを消去してしまう魔法のプロパティ。

使う値はblock, inline-block, table, table-cell, none, flex が多いですね。

たとえば

a {
 display: block;
 width: 100%;
 height: 100%;
}

って指定すると親要素全体がクリック可能なリンクボタンに化けてくれます。スマートフォンでタップしやすいリンクボタンを作るのに大変重宝します。

また、

td {
 display: block;
}

なんてやると、テーブルを崩して横に並んでいるセルを縦並びにしてしまうことができます。パソコンモニタのサイズでは普通の表を、スマートフォンでは縦に並べたい、なんてときに使えますね。

table-cellはtableと組み合わせて、横並びのナビゲーションメニューや文字の上下左右の中央揃えに活用することが多いですね。

さらに、要素ごとなかったことにしたい場合は、display: none; を使うことがあります。

こいつはなかなか凶悪な魔法でして、コードには残って見えるけど、ブラウザ検索エンジン、スクリーンリーダーなどは完全に無視するようになります。display:none; 内にあるJavaScriptも動かなくなります。

ハンバーガーメニューやタブなど、普段は隠していてクリックしたら表示する、という動作をさせたいときに display: none; を使うのは避けましょう。

デフォルトで非表示のコンテンツは無いものと認識され、インデックスされない恐れがあります。またスクリーンリーダーユーザーにとっては最悪UXになりますので、まともなCSSコーダーは本当に限られた場所でしか使いません。

規約に書いてないのに勝手に広告を挿入されてせっかくのデザインを壊される、なんて場合につかうとよいと思います。

最近はflexが注目株となっています。関連プロパティと値と挙動を覚えるのが大変ですが頑張りましょう。

margin

グリッドレイアウトを作る際、これがないといろいろ大変なことになります。何が?って人は、bootstrapのrowに当てられているCSSを読んでください。幅をちょっと広めにして、そのちょっと広めた分をネガティブマージンでずらすだけで、グリッドを幅ぴったりに合わせてくれるんですよ! 最高じゃないですか。

float

いくらdisplay: flex; が有用だからと言ってfloatの出番がなくなるわけではありません。用途が違う用途が。

画像にfloat: left; とか適用する場合、親要素がその画像の高さを無視してしまうためデザインが崩れることがあります。親要素にはclearfixを適用することを忘れずに。

box-sizing

border-box最高です。デザインが堅牢になります。あまりに使い勝手が良いのでユニバーサルポインタにborder-box適用したりしてます。

position

かけだしCSSコーダーが恐れる超強力魔法の一つ。うっかり使うとすさまじい勢いでサイトデザインが崩壊します。そして「absoluteこわいabsoluteこわい…」とうわごとを繰り返すほどのダメージ受けてしまいます。

とはいえ関連ルールさえちゃんと把握しておけばデザインの自由度を大きく広げてくれるプロパティです。少し頑張ればレスポンシブのクリッカブルマップだって作れます。

overflow

ハンバーガーメニューを実装する際、親要素に hidden の値を設定しておき、デフォルトではメニューの要素を親要素の外に出しておくと、メニューの出し入れを制御することができます。隠し要素扱いされないようにマウスオーバーやフォーカスで表示するとよいかと思います。ただ、hoverで制御するとiOSSafariで動いてくれないことがあるので、今のところJavaScriptで制御することが多いです。新しいOSでは解消されてるんでしょうか。

そんなこんなで

主要なというか、自分がよく使うプロパティでした。レスポンシブデザインが主流になってからこれらを使う機会が増えてる気がします。

2016-06-19

CSSのネーミングでもう悩まない! BEM+OOCSSのネーミングルール

BEMの利点と落とし穴

BEMは使用箇所が明確で、何に使っているのかがすぐ分かって、関連するほかのクラスもすぐに見つけられて、そのため保守性が高い。

見た目は確かに醜いけれど、それ以上に利点が大きい。使わない手はない。


とはいえ、それなりに経験を積まないとちゃんとしたネーミングができない問題がある。

よくある間違いが、HTMLの構造の通りにCSSにネーミングしてしまうこと。そこまでいかなくても、ネストが深くなりやすい。

Sassなどを使っていればコードを書く負荷は下がるけど、出力されるCSSは肥大化するし、CSSの可読性が大幅に下がる。HTMLもクラス名のせいで読みにくくなる。一回これをやらかした。


本当にこれでいいのか?


よくないに決まっている。そこで一旦BEMから離れた。しかしこれが強力な手法であることに間違いはない。

なぜ正しくないアプローチをしてしまったのか?

BEMは、Block, Element, Modifierの順で名づけを行う。デザインをモジュールで把握して、「Block__Element--Modifier」の順で名前を付ける。

日本語で書くなら、「箱__箱--装飾・状態」である。

さらにBlock用のModifierとElement用のModifierを作ることができてそれらを1つの要素に詰め込むことができる。


これだけでも結構ややこしくなる。

BlockとElementをどこで判別するのか。これはElementだけれども、見方によってはBlockになる、どうすればいい?

また、ウェブページはBlockの入れ子構造になっている。関係性を明確にするのであれば、どのBlockまでさかのぼってネーミングすべきだろうか?


もう一つ。BEMではBlock, Element, Modifierのそれぞれで、ハイフンやアンダースコアを使って単語をいくつも結合できるようになっている。

制限がないので、詳しく書ける。そうすればあとから読む人がすぐに意味を把握できる。もとよりBEMはそこを重視している。

ここに落とし穴があった。


自由度が高すぎるのだ。多すぎる選択肢で悩む。

また、長く、複雑すると名前の重複を避けることができる。利点である一方、同じスタイルを別の名前で再生産するリスクも増える。ページの追加が多いサイトなら、条件次第ではCSSが膨大になる。

これではいけない。何か制限するものが必要である。より良い方法を見つけるための他のCSS設計を調べることにした。

OOCSS、SMACSS、FLOCSS…

プログラミングになじみがないため、オブジェクト指向やプロジェクト、クラスといった用語に戸惑ったが、サイトの構造やモジュールの性質を分類・理解するための助けになった。


ネーミングについては、レイアウトにはl-接頭辞を、モジュールにはm-接頭辞を、などというのはあるのだけど(SMACCS)、微妙に両方の性質を持っているモジュールがあったりして、こちらはむしろ悩みが増えることに。

救世主はBootstrap

今まで使わない機能が9割だったので、グリッドシステムやセマンティックなネーミングを取り入れるだけだったのだけどこれが「これならいけるんじゃね?」という答えをくれた。

col-sm-6

グリッドの列分割で、スモールサイズ以上の画面幅では、6グリッド。


「…なんかこれ、BEMっぽくね?」


なんというか、旅をして帰ってきたら青い鳥がそこにいました的な。

「機能」−「適用場所」−「詳細」

なんかこれがすべてのモジュールに適用できそうな気がした。レスポンシブデザインに最適じゃないか。

実際に検討してみたらそう簡単でもなかったのだけど、以下のように整理することができた。

「役割」−「使用場所または担当範囲」−「詳細」

これを適用すると、

col-sm-6
gnav-item
btn-card-submit

てな形になる。


自由度をなくすために、単語はハイフン一つで結合し、アンダースコアやキャメルケースは禁止。これで名前が冗長にならないようにできる。(ハイフン一つの縛りはWordPressコーディング基準と互換性を持たせるためでもある)


上記の命名ルールを英単語に置き換えると、

Role-Position-Detail

となる。頭文字を拾うとRPD。ほかの設計概念より無味乾燥な感じだけど、強引に「ラピッド」と呼ぶことにした。「RPD-CSSNamig」さっさと決めようクラス名。

さらにOOCSSの概念を導入

実はこれだけではネーミングはできても、サイトは構築できない。

Detailのところに装飾を担わせると、単語数が不足するのである。装飾のバリエーションは広いので1単語では足りない。


とはいえ、ネーミングの問題を検討していた当初から機能と装飾は完全に分離した方がよいと考えていた。

そもそもこの「ネーミングどうすべ?」問題、CSSフレームワークを自作するときに生じたもの。--Modifierでわずかに違うだけの同じスタイルを繰り返し使うと、CSSファイルが肥大化する。Sassを使えば管理は楽だが、Sassを使っていないコーダーがいる場合、編集されるのはCSSの方になる。そうすると同じスタイルが繰り返し出てくると保守性が下がる。

そのためこのフレームワークは主に構造あるいは機能に絞り、装飾は最小限にとどめるようにしていた。スタイルを上書きではなく追記することで、多くのサイトに使いまわせるようにという魂胆である。


当初はフレームワークのクラスに追記すればいいかな?と思っていたが、OOCSSのおかげで装飾専用のクラスを作る方が合理的だと考えなおした。

装飾専用のクラスを作り、モジュールとセットで運用する。


これを「従属セレクタ」と呼ぶことにした。単体ではスタイルを持たず、他のモジュールと組み合わせた時に、その装飾部分のスタイルを担当させるのである。

これなら、HTMLとCSSのどちら側でも装飾の修正や追記を簡単に行える。

また、従属セレクタの名前は、他のモジュールにも使いまわすことができる。


従属セレクタは運用が特殊になるため、他のモジュールとは明確に区別する必要がある。そこで従属セレクタにはdep-(depend)という接頭辞を付けることにした。

モジュールとセットで運用する場面があるのはJavaScriptのセレクタも同様である。そこでこれも従属セレクタとし、接頭辞js-を付けることにした。IDセレクタを使う場合はjs-は要らない。


いずれも接頭辞のあとはRPDのルールを適用する。(とはいえほとんどの場合、役割名だけで済むだろう)

Baseの概念も入れておく

ここまで検討してきたのはすべて何らかの機能を持ったモジュールに関するものになる。

実際にはHTML要素のリセットや、mt-10(margin-top:10px;)などのような微調整用のセレクタも必要になる。FLOCSSでいえばFoundationやUtilityにあたる。

大概1単語で片が付くし、ネーミングは大概決まっているためここまでの検討対象に入れていなかった。

全ページ共通で使いまわすため、これらをBaseとして分類することにした。

おおむね出来上がったので

GitHubにまとめておいた。

ネーミングに使える単語数が制限されているので、モジュールは小さいものから大きいものへとやっていくのがコツではないかと思う。親モジュールに振り回されないため、再利用性は上がるはず。

RPD-CSSNaming

一応、このアイデアはHTML/CSSコーダーにとってはとっつきやすいのではないかと思う。覚える・理解することも少なめで意思統一コストは低いのではないかと。

ただ、BEMの持つ親Blockとの強力なつながりが、RPDでは見えなくなるという欠点がある。モジュールは構造のみを担い、他のBlockでも使える(そのBlock独特の装飾部分は従属セレクタが担うはずである)ので大きな問題ではないと思うが、これはどういうプロパティを従属セレクタに任せるかの判断が重要になってくる。下手に組むと使いにくくなるだろう。


RPD-CSSNamingのアイデアは、プロジェクトによっていろいろカスタマイズできると思う。小規模なサイトであれば装飾セレクタを使わずBEM的なつくりの方が効率的に組めるのではないかと思うし、関わる人が多くて大規模になるのならSMACSSやFLOCSSのルールの方に寄せていった方が管理しやすいと思う。

これでCSSのネーミングに悩む人が減ったらよいなと思う。