Event Organiserプラグインの完全日本語化

より新しいver.3.1.7用日本語化ファイルを作成しました。
こちらからダウンロードして下さい。

Event Organiserプラグインの完全日本語化ver. 3.1.7に対応させました。
ver. 3.1.0 → ver. 3.1.7にアップしてます。 WordPressのイベント管理・イベントカ…


以下は旧記事です。

Event Organiser

WordPressの為のイベント管理・イベントカレンダー表示のプラグインとして定評の有る「Event Organiser」。

評判も良く、いろんなサイトで使われてますね。
よく使われるポイントの1つが日本語版が有る点です。
現行バージョンの3.1.0（2016-06-12現在）では、多言語化されている473カ所の内、351カ所が日本語化されています。
74.2%も日本語化されているので、通常使う分にはほとんど問題は無いのですが、あちこちの説明箇所や、メッセージ等が英文のままですし、ちょっと治したい部分なども有りましたので、残りの25.8%の日本語化と、気になる部分を手直ししてみました。

この日本語化ファイル（ウイルスチェック済み）をダウンロード出来る様にしましたので、必要な方はお使い下さい。
この日本語化ファイルは、当方の環境では問題は起きていませんが、使用環境の違いでトラブルが発生する事が有るかもしれません。万が一不具合等が発生しても当方では責任を負いかねますので容赦ください。使用に際しては自己責任でお願いします。

Event Organiserプラグイン完全日本語化ファイル使用方法

  1. 下のダウンローダーから、 ‘eventorganiser-ja.mo’ ファイルと ‘eventorganiser-ja.po’ ファイルをダウンロードします。
  2. 完全日本語化したいEvent Organiserプラグインのディレクトリ（WordPressサイトの ‘wp-content’ ディレクトリ > ‘plugins’ ディレクトリ > ‘event-organiser’ ディレクトリ）の ‘languages’ ディレクトリ内に有る’eventorganiser-ja.mo’ ファイルと ‘eventorganiser-ja.po’ ファイルを削除します。
  3. 同じ ‘languages’ ディレクトリに、ダウンロードした’eventorganiser-ja.mo’ ファイルと ‘eventorganiser-ja.po’ファイルをアップロードします。

以上で完了です。これだけでEvent Organiser関連の表示が完全版になります。（なぜか ダッシュボードの’設定’ > ‘Event Organiser’ > ‘イベントセッティング’ の、 ‘基本’ タブ内の ‘ライセンスキーを追加する’ の下の、 ‘You do not have any add-ons activated. You can view the available add-ons here.’だけは多言語化の対象にはなっていないので、英文のままですが。）

実際にWordPressが使うのは、’eventorganiser-ja.mo’ ファイルの方だけですが、これはバイナリーファイルなので、ファイルの内容を修正点が見つかった時、修正するのが難しいです。’eventorganiser-ja.po’ ファイルはテキストファイルなので、簡単に修正できるので、参考としてmoファイルとと同居させる事になっています。
poファイルはPoeditなどでコンパイルすればmoファイルとなります。

この完全日本語化ファイルは、実際にプラグインを使用しながら作成しましたが、表現がおかしかったり、今後のプラグインのバージョンアップによる内容変更の為に、オリジナルとは違う日本語訳となる可能性もあります。おかしな点・修正点など有りましたら、修正を加え精度の良いものにしていきたいと思いますので、是非ご連絡いただけたらと思っております。宜しくお願い致します。

コメントを残す

WordPresサイトの修理屋として思う事

ロコモコ堂通信社はWordPressサイトの改修・修理屋もややらせていただいておりますが、あちこちのサイトを拝見させていただいていて、常々思う事が有ります。

それは、WordPressのサイトに危ない状態のものが多いと言う事。
ビジネスに使っていらっしゃるサイトでも、何かのきっかけで崩れそうな危険なサイトがとても多いと言う事です。

どんな状態になっているかと言うと、こんな感じです。

WordPressサイトの危ない状態

  1. 完成時のサイトのコピーを残していない。
  2. 定期的なバックアップをしていない。
  3. WordPressのバージョンアップもプラグインのバージョンアップもしていない。
  4. 修正・変更・追加が制作時のルールとは違う独自のやり方でされていて、内部はカオス状態。
  5. プラグインのカスタマイズは、変更箇所を外部ファイルにしてrequire_onceするのでなく、直接プラグインファイルに修正・削除を加えている。
  6. Akismetプラグインが有効化されていない。
  7. WordPressのバージョン情報がheader内に書き出されている。
  8. ログインユーザー名がサイトのタイトルなどから容易に連想される。
  9. パスワードが英文字4文字で、数字も記号も使っていない。又は数字のみの4文字。
  10. wp-config.phpなどの重要なphpファイルのパーミッションが、400になっていない。

これがなぜ危ないのか？というと。

1. 完成時のサイトのコピーを残していない。

これ、結構有ります。Webサイトを最初の状態に戻してたくても戻せなくなります。
作成した業者に聞いても、「データは残していないので、サイトが壊れたら、もう一度制作する事になる。」と言わたりします。
サイトのキャプチャー画像も無ければ、修理屋も元の状態に再現出来ないので、かなり困った事になります。
これは定期的なバックアップを取る事で、解決できるんですが。

2. 定期的なバックアップをしていない。

WordPressは情報をデータベースで管理しています。このデータベースがまれに壊れる事が有ります。このデータベースが壊れた場合、修理し手元の状態に戻すのが難しい。確実なのはバックアップから復旧させるのが確実です。
またサイトがウイルスやトロイの木馬などに侵されたしまった場合、感染前のバックアプデータが有れば、全消去し、ウイルスを駆除し、その後感染前のバックアップをサイトにコピーすれば、感染前の状態に戻せますが、無ければどうしようもない状態になってしまいます。
さらに間違ってファイルを削除してしまったり、上書きしてしまった場合にもバックアップからコピーすれば元の状態に戻せます。
バックアップ作業はサーバに負担をかけるので、バックアップ中のサイトへのアクセスはレスポンスが下がります。あまり頻繁には行わない方が良いとは思いま。ですが最後のバックアップを行ってから後のデータはバックアップに残されていないので復旧できません。出来るだけそれを減らす為に、適度にバックアップの間隔を短くして、こまめにバックアップを残しておいた方が良いでしょう。

3. WordPressのバージョンアップもプラグインのバージョンアップもしていない。

WordPressはセキュリティーホールを潰したり、内部で使っているコードにある古い関数などのPHP非推奨の箇所を新しい推奨のものに変えるため為、常にバージョンアップしています。
WordPressのバージョンが古いとハッキングによってサイトに侵入されたり、プログラムコードに使えない古い関数が入っている事でエラーを起こし、最悪サイトが動かなくなってしまいます。
プラグインのバージョンアップも同様です。バージョンアップしていないとセキュリティホールが残ったままになったり、使用できなくなったコードやタグの為、動作がおかしくなったりします。

4. 修正・変更・追加が制作時のルールとは違う独自のやり方でされていて、内部はカオス状態。

htmlやcss、phpの記述の仕方についての事なので、通常サイトを見る時は判らない部分ですが、てんでバラバラのいろんなルールで書かれていると、コードの内容が判りにくく、コードの修正・変更・追加時に間違いを起こし易くなります。
例えばこんなのがあります。

  • １つのhtmlタグのスタイルをhtmlのstyle属性とcssの両方で設定している。
  • cssに同じ内容のものが複数有る。
  • cssでサイズの単位がpx、en、rem、%などがバラバラに使われている。
  • htmlで空行を作る為に<p style=”margin-top: 20px;”></p>や<div style=”heignt: 10px;”></div>がはめ込まれている。
  • floatプロパティーの解除に２重・３重にclearfixがかけられている。
  • かと思いきや、floatプロパティーの解除がされていない。
  • htmlで閉じタグを使っていない。

あ、ルール以前の事も入ってるな。
違うクラスだから影響無いだろうと思ってcssを変更したら、あちこちの表示がおかしくなるなんて事もざらにあります。
解析に時間がかかるし、トラブルの原因になるし、ルールに一貫性を持たせないと危ないです。

5. プラグインのカスタマイズは、変更箇所を外部ファイルにしてrequire_onceするのでなく、直接プラグインファイルに修正・削除を加えている。

これは何が怖いって、プラグインをバージョンアップすると、変更部分が跡形もなく全て消えてしまって変更前のディフォルト状態になる事です。
バックアップが残っていれば、それから復元できるんですが、バックアップも無い場合、時間とお金をかけて一から変更部分を開発し直さないといけなくなります。
血が凍りそうな程恐ろしい話です。

6. Akismetプラグインが有効化されていない。

Akismetプラグインは、記事に投稿されたコメントを自動的に分類し、スパムコメントをスパムフォルダに移し、決められた時間が過ぎるとそのスパムコメントを削除するプラグインです。
スパムコメントには悪意のこもったものも多く、ワームやトロイの木馬入りのものも有ります。Akismetプラグインを有効化して、サイトの入り口で排除する様にしておかないと危ないです。
以前、管理していたWordPressサイトでAkismetを無効化した時、1日に1000件近いスパムコメントが送られてきた事が有りました。あの時程Akismetプラグインの有り難みを感じた事は有りません。

7. WordPressのバージョン情報がheader内に書き出されている。

現在WordPressサイトは最も多く使われているCMSなんじゃないでしょうか？
多く使われていると言う事は、そのセキュリティーホール情報などを手に入れれば効率良く多くのサイトをハッキングできるわけで、実際WordPressサイトをターゲットにした攻撃が多いです。
サイトのheader情報などGoogleのでベロッパーツールやSafariのインスペクターで簡単に見られたりするわけで、情報は簡単に集められます。WordPressのバージョン情報がheader内に書き出されていると、そのバージョン特有のセキュリティーホールを突いて攻撃される心配が出てくるのです。
表示させない様にするには、使っているテーマのfunctions.phpに

を書き込むだけで良いので、やるべきです。

8. ログインユーザー名がサイトのタイトルなどから容易に連想される。

一番驚くのがこれで、ユーザー名がサイト名をアルファベットにしただけとか、サイト名を数字などの語呂合わせにしたものなど、簡単に推測できるものが多いんです。

9. パスワードが英文字4文字で、数字も記号も使っていない。又は数字のみの4文字。

パスワードは4桁程度だと1秒程度で解析されてしまうと言う話も有ります。10桁になればそれが数時間かかるとも言われています。
WordPressのログインパスワードは、英数文字だけでなく何種類もの記号も使えるので、出来るだけ複雑で、長いパスワードを使うべきです。

パスワードの最大解読時間測定 【暗号強度別】 – dit

10. wp-config.phpなどの重要なphpファイルのパーミッションが、400になっていない。

wp-config.phpはWordPressの基本設定ファイルみたいなもので、データベースのホスト名やデータベース名、パスワード迄書かれています。悪意の第三者がこのファイルから情報を得れば、とても危険な事になります。
WordPressが置かれているサーバでは、ファイルやディレクトリをパーミッションというアクセス権を設定する事で、ファイルを不正に使用されたり、改竄されたりできない様にしています。読み取り・書き込み・実行出来る権利を、アクセスする者を管理者・グループ・一般に分け、設定するのです。
設定は数字又はr・w・xのアルファベットを使って行いますが、400と言うのはグループ、一般とも全くアクセスできず、管理者も読み取りだけで書き換えも実行も出来ないと言うという、改竄防止にはかなり強力な設定です。
WordPress Codexでも推奨されている事なのですが、一般も読み取りできる644と言う設定になっているところが多いんです。
400に設定すべきです。

WordPress の安全性を高める – WordPress Codex

円滑にメンテナンスと適時システムの修正・変更が行える
仕組みとルールを作りましょう

内部は継ぎはぎだらけのパッチワーク状態で整合性が取れていず、さらに重要なセキュリティー対策もほとんど取られていないところが予想以上に多いです。
サイトを製作した業者は制作のみの請け負だと、予算と時間との兼ね合いから、運営時のセキュリティーとメンテナンス性の確保にあまり手間をかけられないのですよね。
また修正・変更・追加を請け負う業者やフリーランスのWebデザイナー・エンジニアも、請け負う費用の為にあまり作業に時間をかけられないし、時間をかけてサイトの構造を調べられない分、他人の作った未知のサイトをいじると何が起るか判らない恐怖心から、書き込まれているコードには出来るだけ手を加えない様にしてしまうんですよね。
その為にパッチワークはどんどん増え、セキュリティーの確保からも取り残されていくんですね。

サイトは大事なビジネスの道具なのですし、情報漏洩にもつながりかねません。きちんとしたメンテナンスで、堅牢なサイトにしていくべきだと思うんですが。

それにはサイトの作成時から、メンテナンスと適時システムの修正・変更が行える仕組みとルールを作り、サイトを作成した業者か、サイトの仕様を理解している業者に管理をる様にしないといけないですね。

Webサイトは道具ですが、壊れたら元に戻せない道具です。
くれぐれもメンテナンスは怠らない様、ご注意下さい。

2件の返信

WordPressのローカライズ、つまり日本語化 – その3　poとmo

「WordPressのローカライズ、つまり日本語化」は3部に分けて書いています。
WordPressのローカライズ、つまり日本語化 – その1 _関数と_e関数
WordPressのローカライズ、つまり日本語化 – その2 gettextとPoeditとpot

今回は「WordPressのローカライズ、つまり日本語化 – その3 poとmo」です。

POは、原文の文字列を抜き出したカタログファイルのPOTに、抜き出した文字列それぞれに対応する翻訳文字列を付け加えたものです。
POTもPOもテキストデータですから、ファイルはテキストエディタで開いて見る事が出来ます。

POT（wp-slimstat.pot）

PO（wp-slimstat-ja.po）

これは WP SiteManager のPOTとPOの一部です。
#: ../admin/config/index.php:48 は、（wp-content > plugins に有る） wp-sitemanagerディレクトリの admin > config の index.php の48行目の意味。
msgid の後に、その上の行に書き込まれている翻訳するファイルの目的の行の、翻訳する文字列。
msgstr の後に、翻訳した他言語（この場合は日本語）が入ります。
POTはこの msgstr が空欄のままで、POでは翻訳された文字列が入っています。

この

が1組となり、ファイル内の全翻訳元文字列の位置する行・翻訳する文字列・翻訳した文字列の一覧が作成されています。
POTのmsgstr 欄に、翻訳された文字列を入れて行く事がPO作成になります。

MOはPOをバイナリにしたものですから、
MOを0xEDで見る
となり、修正にはバイナリエディタなどが必要です。

POならPoeditなどの言語ファイル用エディターで簡単に編集出来るし、msgid と msgstr の関係が判っていれば、テキストエディターでも編集できます。
実際にWordPressが使うのはMOファイルだけですが、編集・修正をし易い様に、POとMOをセットでプラグインの languagesディレクトリに置く事になっています。

PoeditでのPOTからPOを作成するのは簡単です。
まずPoeditを立ち上げ、メニューバーの ファイル > POT ファイルを元に更新… を選択し、表れたメニューウインドウから編集したいPOTファイルを選択してやります。

POTをPoeditでみる
PoeditでPOTファイルの翻訳させたい部分が一覧となって表示されます。
そのウインドウ下部の「新しい翻訳を作成」ボタンをクリックすると、「翻訳の言語」ダイアログが表示されるので、「日本語（日本）」を選択し、「OK」ボタンをクリックします。
翻訳の言語

すると、このPOTファイルを元に翻訳した文字列を書き込んだPOファイルを作成出来る様になります。

Poeditで翻訳文字列を書き込む

上部の「ソーステキスト  – 英語」内の翻訳する元の文字列を選択すると、その下の「ソーステキスト：」に選択した文字列が表示されます。
その文字列の翻訳（日本語訳）文字列を、さらに下の「翻訳：」に書き込みます。

これをメニューバーの ファイル > 保存 を選択し、「ドメイン名-ja.po」としてPOファイルを保存してやります。
そしてさらにメニューバーの ファイル > MO にコンパイル…を選択すると保存ウインドウが表示され、ファイル名も自動的に「ドメイン名-ja.mo」になるので、そのまま保存します。
（フランス語に翻訳したものは -ja の代わりに -fr_FR、イタリア語なら -it_IT、ロシア語なら -ru_RU、中国語は -zh_CNとなります。）

多言語化を考慮されていないプラグインのPOTやPO、MOを作成する場合、プラグインのスクリプト（プラグインディレクトリ名が your-plugin なら your-plugin.php）で load_plugin_textdomain()関数を使ってドメイン名と翻訳ファイルを格納するディレクトリを設定するので、その第1引数を見れば、ドメイン名がわかります。

また、既にPOTやPOが生成されている場合、プラグインのスクリプト（wp-slimstatならwp-slimstat.php）のヘッダー部分の Text Domain に記述されている事が多いです。

それが見当たらない場合は、コード内を「__(」や「_e(」で検索し、見つかったものの第2引数にドメイン名が記載されています。

最後に、POファイルとMOファイルをWordPressサイトにアップロードします。

wp-contents > pluginsにある日本語化するプラグインディレクトリにアップロードするのですが、プラグインスクリプト（プラグインディレクトリが your-plugin なら、プラグインスクリプトは your-plugin.php）に load_plugin_textdomain()関数を使ってドメイン名やPOファイルとMOファイルを格納するディレクトリを設定した場合、サイトにあるプラグインスクリプトをこのスクリプトに置き換えます。
そしてPOファイルとMOファイルを格納した languagesディレクトリを、そのプラグインディレクトリにアップロードします。

既にサイトのプラグインディレクトリに languagesディレクトリとPOファイル・MOファイルが有る場合は、修正したものに入れ替えるだけです。

今までプラグインの日本語化を説明してきましたが、テーマの日本語化も同様な手順で行えます。
load_plugin_textdomain()関数の代わりに load_theme_textdomain()関数を使う点などは違いますが、日本語化ファイルのPOとMOを作成し、そのテーマディレクトリにある languagesディレクトリにアップロードするだけです。

作成したテーマやプラグインの国際化も結構簡単に出来ますね。

コメントを残す

WordPressのローカライズ、つまり日本語化 – その2　gettextとPoeditとpot

「WordPressのローカライズ、つまり日本語化」は3部に分けて書いています。
WordPressのローカライズ、つまり日本語化 – その1 _関数と_e関数
WordPressのローカライズ、つまり日本語化 – その3 poとmo

「WordPressのプラグインのローカライズ、つまり日本語化 – その2」です。

このローカライズはプラグインに限らず、テーマにも応用出来ます。

前回（WordPressのローカライズ、つまり日本語化 – その1 _関数と_e関数）は__関数と_e関数についてでしたが、今回は言語ファイルの作り方について。

gettextでは__関数や_e関数にラップされた文字列を、翻訳された文字列に置き換える仕組みを持っていますが、置き換える文字列は元の文字列と対で登録してある言語ファイルから呼び込まれます。

言語ファイルは「mo（Machine Object）」ファイルです。

言語ファイルはPoeditなどの言語ファイル用エディターを使って作成し、制作過程で「pot」「po」「mo」の各ファイルを生成します。（それぞれ拡張子が「.pot」「.po」「.mo」になります。）

  • POT（Potable Object Template） – ソースから翻訳する文字列を抜き出したファイル　カタログファイル。（text）
  • PO （Portable Object） – POTファイルに翻訳を付け加えたファイル。（text）
  • MO （Machine Object） – POファイルをバイナリー化したファイル。Poeditで作成するとpoと同時に生成される。（binary）

gettextでプラグインの多言語化する手順

多言語化の全行程をみてもらう為に、一番面倒な多言語化を想定されていないプラグインで手順んを説明します。

① まず言語ファイルを格納する language ディレクトリを、そのプラグインディレクトリの直下に作成します。

② プラグインディレクトリの直下のプラグインスクリプトに、翻訳ファイルの場所を設定するコードを書き加えます。
プラグインスクリプト名はプラグインディレクトリ名が your-plugin なら、your-plugin.phpとなっています。

そのスクリプトに load_plugin_textdomain() を使って、ドメイン名と言語ファイルを格納する為に作成したlanguagesディレクトリへのパスを設定してやります。

具体的にはスクリプトの、コメントアウトされたヘッダー以降に

の様に記述してやります。
dirname( plugin_basename( __FILE__ ) )でyour-pluginディレクトリのパスを取得させています。

③ プラグインスクリプト内の翻訳する文字列を__関数や_e関数で囲い、

を

の‘Read access: username not found’ の様に__関数でラップし、さらに__関数の第2引数にドメイン（この場合‘your-plugin’）を設定します。

__関数や_e関数は、

の様にフォーマット文字列やhtmlのタグを含んだ文字列も扱えます。

④ 次に翻訳用テンプレートになるPOTを作成します。
作成には

があります。

⑤ POTからPOとMOを作成します。
実際に使われるのはMOだけですが、MOはバイナリーの為、テキストエディターで編集出来るPOも一緒に置いておきます。

⑥ サイトに日本語化ファイルをアップロードする場合は、作成したPOとMOを、そのサイトの wp-contents > pluginsにある目的のプラグインディレクトリ内の、languagesディレクトリに、MOとPOをアップロードします。

あらかじめ多言語化対応として作られたプラグインの場合、すでに生成されたPOTやPOファイルが有りますから、①②③④の行程を省いてPoeditなどの言語ファイル用エディターを使って日本語訳文字列を打ち込み、簡単に日本語化MOファイルを作れます。

そうでない場合は、面倒ですが①②③④の作業も必要になります。

コマンドラインからi18n toolsを使う方法

ターミナルなどコマンドの扱えるツールでPOTを作成する方法です。
PHPが使える様にパスが通してある必要が有りますが、コマンドラインが苦手でなければ、わりと簡単に作成出来ます。

（詳細は18n for WordPress Developersの下の方のi18n toolsを参照）

まず、ターミナルを起動し、cdで作業するディレクトリに移動します。

そこでSubversionのチェックアウトコマンドを使って、http://develop.svn.wordpress.org/trunk/を移動したディレクトリにダウンロードします。

lsコマンドでカレントディレクトリ内を表示すると、

すると

trunkがダウンロードされているのが確認出来ます。

次に多言語化したいプラグインのディレクトリのシンボルリンクを、trunk/src/wp-content/plugins/にその多言語化したいプラグインのディレクトリと同名のディレクトリを作ってやります。

例えば多言語化したいプラグインのディレクトリがwp-multibyte-patchなら、trunk/src/wp-content/plugins/wp-multibyte-patchとします。
以下、多言語化したいプラグインのディレクトリをyour-plugin-directoryとします。
新しく作るディレクトリをsymbol-directoryとします。

your-plugin-directoryにlanguagesディレクトリを作成します。

cdでtrunk/src/wp-content/pluginsに移動します。

makepot.phpをwp-plugで実行します。
最初のオプションはさっき作成したsymbol-directoryのパスです。
2つ目のオプションはsymbol-directoryのパス/languages/your-plugin-directory名.potです。your-plugin-directory名がwp-multibyte-patchなら、wp-multibyte-patch.potとなります。

するとyour-plugin-directory内にlanguages/your-plugin-directory名.potが生成されます。

因にテーマを日本語化する場合は、wp-pluginの代わりにwp-themeを使い、

の様にします。

Blank-WordPress.potをPoeditで編集して作成する方法

こちらはコマンドラインを使う方法ではなく、Blank WordPress PotのBlank-WordPress.potというPOTのテンプレートをPoeditで編集して作成する方法です。
感覚的には、こちらの方が馴染み易いかもしれません。

  1. まずBlank WordPress Potをダウンロードします。Blank-WordPress-Pot

2. ダウンロードしたBlank-WordPress-Pot-master.zipを解凍します。

3. 多言語化したいプラグインのディレクトリにあるlanguagesディレクトリ（無かったら作成）に、解凍して出来たBlank-WordPress-Pot-masterフォルダ内のBlank-WordPress.potを移動します。

4. Poeditをダウンロード＆インストールし、Poeditを起動します。
poedit

5. Poeditで、プラグインのディレクトリ/languages/Blank-WordPress.potを開きます。
（Macの場合、メニューバーのファイル > POTファイルを元に更新… を選択します。）

すると
poedit_1とウインドウが出るので、とりあえず上部の「翻訳の言語」は「日本語（日本）」で「OK」をクリック。
そして下部の「ソースから抽出」をクリックします。

6. 次のモーダルウィンドウが表示されるので、「翻訳の設定」ボタンをクリックします。
poedit_2

7. 「翻訳の設定」で、「プロジェクト名とバージョン」にプラグイン名とバージョンを入れます。
「翻訳チーム」と「翻訳チームのメールアドレス」は必要に応じて入れておきます。
poedit_3

8. 「ソース中のキーワード」ボタンを押して表示されるキーワードは、みっちり入っていますから、このままで大丈夫です。
下部の「OK」ボタンをクリックすると、ここに登録されているキーワード・関数でラップされた文字列が抽出されます。
poedit_4

9. カタログファイルが作成されました。これをメニューバーの ファイル > 保存 を選択して上書き保存します。
poedit_5

これでPOTが出来上がりました。

次回はPOとMOについてです。
WordPressのローカライズ、つまり日本語化 – その3 poとmo

コメントを残す

Twenty Twelve・Twenty FourteenのGlobal_menuで小文字が大文字になってしまう件の修正

現象

このサイトはWordPressのデフォルトテーマだった「Twenty Twelve」の子テーマを作りカスタマイズしています。

「Twenty Twelve」をベースにして、基本部分で「Twenty Twelve」のレイアウトを引き継ぎながら、子テーマのstyle.cssで新たなデザインと機能を付け加えています。
子テーマにする事で「Twenty Twelve」のバージョンアップで修正部分を書き換えられる事も無いので、この形で使い続けているわけですが、「Twenty Twelve」の癖と言うか設定で、Global_navに表示する英文字が強制的に大文字に変換されるのが、どうも気になってしまい、今更ながらに修正したくなったわけです。

「Twenty Fourteen」もGlobal_navで項目が大文字に変換されます。

メニューが勝手に大文字に01_2

メニューが勝手に大文字に02_2
英文字が強制的に大文字に変換されるのは「Twenty Twelve」と「Twenty Fourteen」だけの仕様で、

  • 「Twenty ten」
  • 「Twenty Eleven」
  • 「Twenty Thirteen」
  • 「Twenty Fifteen」
  • 「Twenty Sixteen」

では変換は行われず、大文字は大文字で、小文字は小文字で表示されます。

 

原理と修正

全て大文字になるのは、CSSでGlobal_navの各項目の「a」要素の「text-transform」プロパティーを「uppercase」に設定して大文字にしているからです。
ここを編集するだけなので、らくちんです。

Twenty Twelve　（1533行目）

 

Twenty Fourteen　（957行目）

text-transform: uppercase;
を
text-transform: none;
にすれば、大文字は大文字に．小文字は小文字として表示されます。

しかし、直接「Twenty Twelve」（又は「Twenty Fourteen」）のstyle.cssを修正すると、テーマをバージョンアップした時にまた前の状態に戻るので、そうならない様に「Twenty Twelve」（又は「Twenty Fourteen」）の子テーマを作り、その子テーマのstyle.cssに、

Twenty Twelve

 

Twenty Fourteen

を加えてやります。

子テーマを作るには、まずFTPクライアント（FileZillaやFFFTP、Cyberduckなど）でサイトを置いているサーバに接続します。

そしてサイトのWordPressのディレクトリ内の、「wp-content」内の「themes」に、子テーマのディレクトリを作り、子テーマ名を付けます（好きな名前でOK）。

その子テーマ内に「style.css」を作成し、

の様に子テーマ名・親テーマ名をコメントで宣言し、親テーマのstyle.cssをインポートしてやります。
（親テーマのstyle.cssへのパスは、親テーマ・子テーマとも同じ「Themes」ディレクトリに有るなら「../twentytwelve/style.css」となります。
これは”子テーマのstyle.cssのあるディレクトリ[ 子テーマのディレクトリ ]の一つ上のディレクトリ[ 「Themes」ディレクトリ ]にある「twentytwelve」ディレクトリ内のstyle.css”と指示しています。）

子テーマを作る時、最低限必要ものはstyle.cssです。これに上記の形で子テーマ名と親テーマ名が宣言されていれば、他のファイルが無くてもWordPressはその子テーマを認識し、ダッシュボード > 外観 > テーマ で、この子テーマを選択出来る様になります。

そして、先程の修正部分の

Twenty Twelveの子テーマの場合

 

Twenty Fourteenの子テーマの場合

を @import url(“../○●/style.css”); の次の行以後に付け加えてやります。
そして文字コードを「UTF-8のBOM無し」として保存します。（WebではBOMはトラブルの元）

すると、

メニューが勝手に大文字に03_2

と大文字は大文字で、小文字は小文字で表示されます。

コメントを残す