タグ: 日本語

段落の最初の行頭の字下げ

WordPress, ことば, , , コメントを残す

WordPress.org の日本語フォーラムでの「日本語字下げをいつまで無視し続けるのか」という投稿に答えるなかで改めて調べてみて、いくつかを知ることになったのでここに記しておく。

多くの言語で使われることが想定される WordPress に、日本語の一つのスタイルである「全角アキ」を実装するよう求めるのは現実的ではない。利用者(サイト運営者)が style.css なりカスタマイズの「追加CSS」で対応するしかないだろうと思う。もっとも英語使用者にも似たような要望を持つ人はいるようで、たとえば英語のフォーラムにも Indent first line of most paragraphs, not all のトピックがあるし、そこからたどってみると #37462 の要望も出されている。

まず、英語をはじめとする多くの欧文で、段落整形は

  • 段落間は大きくあけず、段落の最初の行頭を字下げする
  • 字下げせず、段落間の行間をあける

のどちらかである。それぞれ「インデントスタイル」「ブロックスタイル」のように呼ばれるようだ。どうやら前者は伝統的なスタイルで、後者はウェブページなど電子テキストに多く見られる。

日本語の横書きもこれに準じる。ただし欧文の場合に字下げ幅が3–5文字であるのに対し、日本語の場合は全角アキである。

スタイルシート

私自身も、まとまった文章では伝統的な「インデントスタイル」が望ましいと考えているので、このサイトではスタイルシートで次のように設定している。

.entry-content p {
  margin-bottom:.25em;
  text-indent:1em
}

つまり、段落ブロックの下のアキは少しだけにして、最初の行頭の字下げ幅は 1em にしている。

見出し直後の段落

「インデントスタイル」の場合でも、最初の段落(見出し直後の段落)のみは字下げしない、という流儀もある。たとえば CSS のプロパティ text-indent の解説にもこのことが書かれている。まさにそこにあるように書くことで実現できる。

このサイトではこの流儀は採用していない。

日本語組版処理の要件

日本語については「日本語組版処理の要件」が重要な参考資料となる。「段落整形」の章でこの件について書かれている。

そこに、これまでどうしようか迷って自分でも揺らいでいた部分についての言及があった。

注

改行にして始めかぎ括弧[「] (LEFT CORNER BRACKET)及び終わりかぎ括弧[」] (RIGHT CORNER BRACKET)でくくった会話などを“といった……”などと受けて続く場合は，文節が連続していると考え，段落の先頭行の字下げは行わないで天付きとする（Figure 151）．横組の別行にした数式を受けて，改行で“となるので……”などと受ける場合も，同様に段落の先頭行の字下げは行わない．ただし，小説などでは，すべて段落の先頭行の字下げは行うという処理方法も行われている（Figure 152）．

「日本語組版処理の要件」3.5.1 段落先頭行の字下げ

要は、カギカッコの会話文や独立行の数式を挟んで文が続いているとき、それらの会話文や数式の後の段落は字下げしない。ここまで明確に書いてある説明をこれまで見ていなかった。

この記事でいうと、上のほうにある箇条書きに続く「のどちらかである。」のところは字下げしない、ということになる。これまでどうしたものかと思いっていたことの答がはっきりと示されていて、すっきりした。

内容に依存するため、さすがに一律に設定はできない。ここだけは字下げしないという場合にその CSS を適用する。WordPress のブロックエディターなら、右のほうのメニューの「ブロック」→「高度な設定」→「追加CSSクラス」で、前もって style.css か「追加CSS」に用意しておいた .noindent {text-indent: 0em} を指定するようにする。

2001–2010年ころの日本語システムフォント

ソフトウェア, , , 1件のコメント

これまでにも何度か書いているように、私自身は個人的には「日本語のある程度の長さのまとまった文章には、ゴシック体より明朝体のほうが向いている」と考えています。Web ページにおいても、です。

一方で、「Web ページはゴシック体」という意見が数多く見られます。おそらく、単純に「明朝派」か「ゴシック派」かで言えば、「ゴシック派」のほうがかなり多数のような印象があります。

システムフォントの歴史

いろいろ思い出すために、2000年頃以降のシステムフォント—大きなシェアを占めていた Windows と Mac にデフォルトで装備されているフォント—について、ざっと調べてみました。

Windows

2001XPMS明朝ゴシック 2.30 MS明朝 2.31
2006Vistaメイリオ 5.00 MS明朝ゴシック 5.00 MS明朝 5.00 (JIS X 0213:2004)
20138.1游ゴシック 游明朝

Mac

MacOS 9.2.2までOsaka 平成明朝 リュウミンライト-KL
2001OS X 10.0ヒラギノ角ゴ Pro W4・ヒラギノ明朝 Pro W3
200710.5ヒラギノ角ゴ ProN W4・ヒラギノ明朝 ProN W3
201310.9游ゴシック体 游明朝体 M

フリーフォント

私自身はこの時代より前から今日に至るまでずっと Linux (Debian) を常用していて、それにはデフォルトとか標準という考えがなく好みのフォントを使います。もう記憶が確かでない部分もあるのですが、主流だったと思えるものを拾い出してみました。

1998-1999渡邊フォント
2000-2003Kochi
2003-2004Sazanami
2007IPAゴシック・IPA明朝 (単体配布)
2010IPAexゴシック・IPAex明朝
2010Takaoフォント
2014源ノ角ゴシック / Noto Sans CJK JP
2017源ノ明朝 / Noto Serif CJK JP

参考:ブラウザーの歴史

1992mozaic
1994Netscape Navigator
1996NN3, IE3
1997NN4
2001IE6
2003Safari (10.3から。それ以前(10.2)の標準ブラウザはIEforMac)
2004Firefox 0.8
2006IE7
2008Chrome

漠然とですが、

  • 2001–2010年ころ、Web ページにとって明朝体は、技術的に「使い物にならな」かった
  • そのため、その頃とそれ以降、日本語の Web ページは圧倒的にゴシック体を主体としたものが多い
  • その環境で育った人たちは、もう「Web ページはゴシック体」が当たり前であり、技術的な問題が既に解決されても、むしろ明朝体だと違和感がある

のようなことではなかろうかと考えています[1]。

2001年のMacOS Xにヒラギノというのは本当に画期的だったとは思うのですが、何しろシェアが違いすぎ、それにあぐらをかいた Windows のために「暗黒の10年」だったと言っても過言ではありません。ブラウザーの IE6 天下と軌を一にしています。

話はややずれますが、ハードウェアとしてのディスプレイが CRT から LCD になっていったのものこの頃でした。私が切り換えたのはだいぶ遅めの2005年ころでしたが、CRT ではいい具合にボケていた文字の輪郭が LCD だとくっきりしすぎて、文字として美しくなくなったのを覚えています。それからアンチエイリアスとかヒンティングなどを意識することになりました。

  1. 翻って考えると、私の「日本語のある程度の長さのまとまった文章には、ゴシック体より明朝体のほうが向いている」という考えも、WWW 以前の、印刷物に接する時間が長かった(印刷物は言うまでもなく、本文は明朝系であることが圧倒的に多い)影響が強いのかもしれません。↑

「かけられる数」「かける数」ってわかりやすい言葉なのだろうか

ことば, 暮らし, , , , 1件のコメント

そうこうしているあいだに、小学2年生のスウちゃん(仮名)の冬休みが終わり3学期になりました。2学期末は学校でかけ算をやっていましたが、宿題で持ち帰るプリントやドリルでは、かの有名な「かけ算順序問題」が繰り返し繰り返し出されます。延べ10回は超えているでしょう。しかしスウちゃんはちっとも引っかからず、求められているとおりに答えるので、親としてはやや拍子抜けです。「かけ算順序問題」そのものについては、ここでは深入りしません。既にあちこちで語られているでしょうから。

さて、「6×4 の式でかけられる数はどちらですか」のような設問も見られます。この「かけられる数」という言葉(言い回し)は、どうにも分かりにくいと感じます。大人でも混乱しそうです。少なくとも私はそうです。たぶん「受け身」(受動態)という形が普通ではないからでしょう。私はしばらくあるフリーソフトの翻訳に関わっていましたが、そこでも日本語の訳文は「できるだけ受け身にしない」という指針でした。

毎年数万人、延べ何百万人の先生方は疑問に思わないのでしょうか? まあ先生ほど普段から使っているから身についてしまって何とも思わないのかもしれません。百歩譲って、「かけられる数」「かける数」の区別が重要だとしても(それは教える側の問題であって、子どもたちがそれを意識する必要はないというのが私の考えです)、たとえば「はじめの数」や「もとになる数」、もっと簡単に「もとの数」とかいう語ではだめなのでしょうか。だいぶましだと思うのですが。そういう語だと加減乗除のどの場合にも左側の数をそう呼べるので、統一的な理解にもつながりそうにも思います。そうしない理由がどこかにあるのでしょうか。

ところで、念のために「かけ算順序問題」についての私の考えをさらっと書いておきます。

  • 教室で子どもたちに順序つきで教えること自体に異論はない。逆順も教えなければならないとも思わない。
  • ただし、子どもが逆順で答えてきたものを☓にしてはならない。したがって順序を問うような問題はナンセンス。

Hubot で docomo 「雑談対話」API を使う — “敬称”を Hubot コマンドに

ことば, ソフトウェア, , , コメントを残す

これは Hubot Advent Calendar 2014 の 5 日目の記事です。が、その流れにうまく乗れているのかいないのか。1週間ほど前に自分の書いた「Hubot ping の日本語化」に引き続き、Hubot を日本語で楽しく使おうという話です。Advent Calendar の前日(4日)の記事の最後のほうでも、メッセージを日本語化するとより親しみがわく(あるいは腹が立つ)というお話でしたね。

さてさて、存在確認(ping)以外にもう少し会話的なものを楽しみたいのですが、大量の質問と答を仕込むのは労力の割に楽しくなさそうだし、人口無能みたいなものを組み込むのはこちらの技量からして難しいし……と考えあぐねていたところに、docomo Developer support 提供のAPI「雑談対話」というものを見つけました。しかもちょうど開発用APIキー有効期間の制限が廃止され、特に本申請をせずともよくなりました。

「hubot-docomo-dialogue をつくった」を参考にしました。そこでは、すべての発言に反応するよう

...
  robot.hear /.*/, (res) ->
...

となっていました。しかし、これではまじめな話をしているところに割り込んできてうっとうしいので robot.respond にしたいところです。さりとて、コマンドを日本語化したとしても

user> わぷー 雑談 今日は寒かったね。

というのも無粋というか興ざめです(「わぷー」というのは bot の名前です。hubot の起動時に bin/hubot --name wapuu --alias わぷー として起動して、日本語名を与えています)。

“敬称”をコマンドに

ちょっと思案して、敬称の「さん」をコマンドにしてみました。

...
  robot.respond /さん(?:、)?\s*(.*)/, (res) ->
...

使用する時は、bot名とコマンドのあいだの空白は実はなくても大丈夫なので、

user> わぷーさん、今日は寒かったね。

と、ずいぶん自然な文体にすることができます。「わぷー」がbot名、「さん、」がコマンド、「今日は寒かったね。」が処理に渡されるパラメータと解釈されます。

Hubot のほかのちゃんとしたコマンドのときは呼び捨て、雑談したいときは「さん」付け、と使い分けることになります。

Wikipedia「敬称」にあるものを適当に詰め込み、読点をつけてもつけなくてもいい(ただし呼び捨てに読点を付けると雑談になる)ようにしました。

雑談対話 API

雑談対話と知識Q&A雑談対話 API には“会話の継続”というものがあります。いったん言葉(リクエスト)を投げかけ、返答に含まれる「コンテキストID」を次のリクエストにつければ継続的な対話になるというものです。この機能も組み込むことにしました。これでしりとりもできるようになりました(「わぷー、りんご」みたいにいちいち呼びかけなければなりませんが)。そして、2分あいだをあけると継続としないことにしました。

できた script は

です。

試してみましたが、しりとりは確かに上手にできます。しかし継続対話は期待ほどではなく、的外れなものになりがちでした。API の向こう側の対話能力は今後バージョンアップされるのでしょうか。

同様の docomo API 「知識Q&A」を利用するための docomo-knowledge.coffee も作ってみました。

こちらも試してみましたが、うーん、あんまり実用的な答は返ってきませんね。

user> わぷー教えて、ロスはいま何時?
wapuu> ロサンゼルスの今の時刻は15時35分です。

がちょっと便利なくらいです。

Hubot ping の日本語化 — 「いるのか?」の正規表現

WordPress, ことば, ソフトウェア, , , , 1件のコメント

Hubot の ping コマンド

hubot_wapuuSlack というコミュニケーションツールを利用することになって、そこでこれは便利かもということで Hubot をいじってみています。

現時点での安定版 Debian Wheezy に Hubot をインストールするにはどうすればいいんだとか、Slack に連携させるときに Heroku を使う方法ならすぐに見つかるが、自前ホストのHubotとSlackを連携させるにはどうするんだとか、いくつか引っかかりながらも、ここにリンクした情報が既にあったのでうまくいきました。

この bot がちゃんと作動しているかどうか反応を見るのに、ping というコマンドがはじめからサンプルとして付属しています。bot の名前に ping と付けて問いかけると、PONG と答えるというものです。

user> hubot ping
hubot> PONG

さて、「HubotのScriptを翻訳するとかわいい」にありますように、日本語化すると愛着がわきます。ping の Script はとても簡単で、肝は

  robot.respond /PING$/i, (msg) ->
    msg.send "PONG"

です。使用目的はとにかく存在確認ですから、日本語にすると

  robot.respond /いるのか\?$/i, (msg) ->
    msg.send "はい、ここにいます!"

です。

また、Hubot を起動するときに bot 自身の名前と別名を付けることができます。そこでこれを日本語で

bin/hubot --name wapuu --alias わぷー

と付けてやると、ますます親しみがわきます。これで応答は

user> わぷー いるのか?
wapuu> はい、ここにいます!

となりました。

「いるのか?」のバリエーションの正規表現

このままですと、script の質問文のところは正規表現で書けるのに、ただ「いるのか?」に正確にマッチしないと返答しないということになっています。

「いるのか?」の分解存在確認の日本文「いるのか?」を考察してみます。これを4つ(疑問符を入れると5つ)に分けて、それぞれのバリエーションとその組み合わせを思いつくまま挙げてみました(図)。ありえない組み合わせ—たとえば、2段目が「ります」のとき、その前に「い」はありえない—の制限を付け加えながら、正規表現にして書いてみると、次のようになりました。

/(((い|ゐ|居)(て?))(?!り)|(お|を|居)|((い|居)(て?)は)(?!ま))((る|ん(?=の))|((り?)ます)(?!ん))((の?ん?)(です)?|(んだ)(?!か))?(か(い?な?|よ|ね)?|(よ?)(ね|な))?\s?(\?|？)/

これで、質問文は「いる?」から「いてはりますのんかいな?」(いや、これが現実にありうる表現かどうか確証は持てないのですが)まで対応できます。

ping の目的は存在確認なので、日本語では「生きてる?」とも言いそうです。1段目の前に「生きて」を付けて、元の1段目を必須から任意に変更すればよさそうです。さらに、「調子どう?」「元気?」というフレーズもよく使いそうですね。これはもうそのままということにします。だんだん手抜きになってきました。

結局、日本語版 ping はこうなりました。

  robot.respond /(((い|ゐ|居)(て?))(?!り)|(お|を|居)|((い|居)(て?)は)(?!ま))((る|ん(?=の))|((り?)ます)(?!ん))((の?ん?)(です)?|(んだ)(?!か))?(か(い?な?|よ|ね)?|(よ?)(ね|な))?\s?(\?|？)/i, (msg) ->
    msg.send "はい、ここにいます!"

  robot.respond /(い|生|活)きて(((い|ゐ|居)(て?))(?!り)|(お|を|居)|)?((る|ん(?=の))|((り?)ます)(?!ん))((の?ん?)(です)?|(んだ)(?!か))?(か(い?な?|よ|ね)?|(よ?)(ね|な))?/i, (msg) ->
    msg.send "はい、ここにいます。"

  robot.respond /(調子どう|元気)/i, (msg) ->
    msg.send "はい、元気です。"

wapuu_pingちゃんと数えていませんが、これで「いるのか?」を意味する数十種類の表現に答えることができるようになりました。

このWapuu bot は、WordPress の日本語コミュニティがこれから活用していこうとしている Slack にいます。WordPress 本体の開発元でこの Slack を使っていくことになったことに触発され、そこに収まりきれない話題—日本語圏特有の話題、日本語で話したほうが楽な話題など—を扱っていこうという場所です(たぶん)。単に「WordPressの使い方」を尋ねるような場所ではありませんが、何かちょっとでも手助けしたい(日本語圏で最も求められているのはたぶん翻訳です。本体のみならず多くのドキュメントやニュースなどが翻訳されるのを待っています。もちろんほかにも何かがあります。たとえばこの記事のように、どうでもいいような冗談を仕込むとかもきっと)と思っている方があればぜひ参加してみてください。参加資格などなく、参加方法の手続きを踏めさえすれば誰でも参加できます。Wapuu bot はそこで待っています。

WordPress プラグインやテーマの翻訳でうまく手を抜く(いい意味で)

WordPress, ソフトウェア, , 1件のコメント

WordCamp Kansai 2014 に行ってきました。2日め“コントリビューターデイ”、プラグイン・テーマ翻訳の世話役だったのですが、可搬 PC は持っていないし、子連れだし、遠方まで帰るために途中で抜けなければならないし、さらに、「Mac/Win で Poedit というアプリケーションを使う」というのが最も一般的と思われるのに自分では使っていないため[1]に操作方法を即答できない……、という幾重もの役立たずぶりですみませんでした。こどもの相手やら何やら、こちらのほうがお世話になりっぱなしで、ありがとうございました。

そういう中で質問を受けたことを、今さらながらここに書いておこうと思います。

翻訳作業のステップ

WordPress のプラグインやテーマの翻訳をやってみようという記事はあちこちにたくさんあります。ここでは細かく書きませんので、それらを参照してみてください。「POT ファイルとは何か」「PO ファイルとは何か」「それらはどこにあるか」などは既に知っているという前提で進めます。

おさらいです。WordPress のプラグインやテーマの翻訳作業のステップは

  1. プラグインやテーマのプログラムの中の翻訳されるべきメッセージに __() や _e() などのマークを付ける
  2. マークされた文字列を抽出して POT ファイルと呼ばれる、翻訳者にとって原本となるものを作成する
  3. POT ファイルを元に、メッセージをそれぞれの言語に翻訳した PO ファイル を準備する
  4. PO ファイルを編集する (これがほんとうの翻訳作業)

です。作業のスタート地点が後ろに近いほど、とっかかりやすいです[2]。

最も始めやすい状態: ステップ4から

たくさんある記事のひとつ、Nao さんの「2014年版: WordPress プラグイン・テーマの翻訳を始めてみよう」を見てみます。

その記事にありますように、最も手軽に始められるのが、既に全部または一部翻訳がなされているものに対して、誤訳を修正するとか、別の訳語にするとか、訳の抜けている部分を補う、というものです。これなら最初のハードルがぐっと低く、ともかく「やってみよう」という気になれます。

Poedit なら、書き換えたい PO ファイルを開き、当該箇所を修正・加筆するだけです。

その次に楽な状態: ステップ3から

プラグインやテーマそのものは翻訳可能 (POT ファイルが用意されている) だが日本語訳 (name-ja.po) がない状態というのが、その次にとっつきやすい状態です。

公式ディレクトリに登録されているプラグインやテーマなら「translation-ready」というタグが付けられているでしょう。ここでいうステップ1や2の処理が既にされているという意味です。

Poedit なら、「ファイル」-「POT ファイルを元に新しいカタログを作成…」で、「言語」に ja を指定して適切な名前 (name-ja.po の形) で保存します。

コマンドラインを使えるなら Poedit を使わずに、

msginit -i name.pot -o name-ja.po -l ja

です。意味はなんとなくわかりますね。

この時点で、翻訳率0% の日本語翻訳ファイル name-ja.po ができます。

ステップ3をステップ4に

「0%」……嫌な響きですね。これだけでやる気が削がれてしまいます。なので、過去の資産から使えるものは少しでも流用します。

たとえばテーマの翻訳をしようとしているとします。その最初に、既存の、たとえばデフォルトテーマの twentyfourteen の翻訳を取り込んでしまおうというのです。

もしステップ3をコマンドラインでできたようなら、これまたコマンドラインで

msgmerge -o name-ja.po -C wordpress/wp-content/languages/themes/twentyfourteen-ja.po name-ja.po name.pot

のように、msgmerge を使います。-C で参考とする PO ファイルを指定します。-C はひとつのコマンドラインの中に何度でも指定できるので、WordPress 本体の ja.po や admin-ja.po も追加するといいかもしれません。

Poedit ではこれに相当する操作が簡単にできないようです。そこでステップ3の代わりに、次のようにします。name-ja.po がまだ存在しない状態で、参考とする PO ファイル (たとえば twentyfourteen-ja.po) を name-ja.po という名前でコピーします。これを Poedit で開き、「カタログ」-「POTファイルでカタログを更新…」します。

すると、英文が合致する分の翻訳がそのまま取り込まれます[3]。プラグインでは参考にする似たものを見つけてくることが難しいかもしれませんが、テーマの場合は、デフォルトのテーマを参考にしてうまくいけば80%ほども翻訳済みにしてしまうことができます。

これで、スタート地点をステップ3からではなく、ステップ4からにすることができます。

翻訳メモリ

Poedit には翻訳メモリという機能があります。データベースに登録しておけば、それを自動的に参照して、英文が合致する分を埋めてくれます。まずは WordPress 本体の ja.mo や admin-ja.mo それにデフォルトのテーマの twentyfourteen-ja.mo を登録しておきましょう。

これによってもスタート地点をステップ3からではなく、ステップ4からにすることができます。

前節の方法と翻訳メモリの方法は同時に使うこともできますので、積極的に翻訳メモリを使うのがいいでしょう。

といっても私自身が Poedit 自体(ということは翻訳メモリも)使っていませんので詳しく書けません。かなり古い記事ですが Tai さんの「poEditの翻訳メモリ機能を使う」や Miyoshi さんの「poEdit で翻訳ファイルを作る 」の「翻訳メモリを活用する」の節などを参考にしてください。

手抜きの効果

「手抜き」というと負のイメージの言葉ですが、ここではまったくそういうことはありません。むしろ用語の統一という点でも、積極的にここに書いた方法をとるべきだと思います。

そこで、最初掲げたステップを修正して、

  1. プラグインやテーマのプログラムの中の翻訳されるべきメッセージに __() や _e() などのマークを付けておく
  2. マークされた文字列を抽出して POT ファイルと呼ばれる、翻訳者にとって原本となるものを作成
  3. POT ファイルを元に、メッセージをそれぞれの言語に翻訳した PO ファイル を作る
    1. 過去の資産を参照して自動的に、できるだけ翻訳を埋める
  4. PO ファイルを編集する (これがほんとうの翻訳作業)

の赤い字の項目を必ず実行するように意識することを強くお奨めします。

ざっと検索してみた Poedit の使い方、WordPress の翻訳や WordPress 翻訳祭りのような WordBench などでの解説でも「POT ファイルから PO ファイルを作りましょう。空っぽの ja.po ができましたね。さあ翻訳を始めましょう」と、このあいだのステップが飛ばされているように思います。

いまからやろうとしている翻訳は、単語レベルでは既に誰かがやっているかもしれません。WordCamp Kansai 2014 のキーワードは「Share 分かちあい」でしたね。share できるものは share して、抜ける手はなるべく抜いて、その余力は別のところで活かしましょう。

これくらいの下調べは前もってやっておくべきでした。すみません。今後の各地のイベントや、あるいは個人で、翻訳やってみようかなというときには、前に書いた「WordPress 翻訳祭り—今さら注意してもらえない「日本語」について 」と併せて参考にしてもらえればと思います。

  1. ふだんは Debian 上の Emacs の po-mode で作業しています。↑
  2. このあと、それを開発者に送るとか、開発者の側では送られてきたものを最新版に合わせてからパッケージに同梱するとかの作業もありますが、ここでは省略します。それらとステップ2については以前「プラグインやテーマの国際化を少し楽に」に書きました。↑
  3. 合致しなかった部分を掃除するには Poedit では「カタログ」-「Purge Deleted Translations」です。↑

WordPress 翻訳祭り—今さら注意してもらえない「日本語」について

WordPress, ことば, , 4件のコメント

今週末、全国各地で WordPress 翻訳祭りが開催されるようです。WordPressの各言語版がどのような仕組みで実現されているか、とか、実際に翻訳作業をするアプリケーションの説明などが、あちこちに見られるようになりました。(【追記】このあと WordCamp Kansai 2014 コントリビューターデイもありますし、今後も参照されるかもしれないので若干手直ししました。)

でも、もっとも根っこのところにある「日本語」については、日本語の話者ならもう今さら言うことはないという感じで、なかなか誰も注意してくれません。

ふだん自分が書く日本語と違う点は、これが協調作業だということです。WordPress 本体と、テーマやプラグイン、Codex で、書き手によって文体や表現がバラバラだと、読み手に対していらぬストレスを与えることになります。ここは自分が気持ちよく書くことよりも、自分だけ外れた書き方になっていないか、に注意することが必要です。

日本語スタイルガイド

WordPress 本体の翻訳にあたっては、ガイドラインを定めています。

まず基本となる「日本語スタイルガイド」(簡易版の PDF) があって、そこに書かれているルールから外れる WordPress 日本語版独自のルールという形で決めています。翻訳祭りに参加される方は、ぜひ事前に目を通して、もちろん全部覚えておくことは難しいでしょうが、「あれ、どうだったっけ?」と引っかかる程度にはしておくといいでしょう。

  • 日本語の句点は全角の「。」を、読点は全角の「、」を使う。
  • 日本語には全角文字 (2 バイト文字) を使う。
  • 英数字、符号には半角文字 (1 バイト文字) を使う。(例外は句読点、鍵括弧、中黒。これらは全角文字を使う)
  • 数字は、慣習的に使われている場合を除いて、算用数字 (1、2、3) を使う。

このあたりまでは、特に気をつけなくても大丈夫だと思います。

以下、気をつけないと自分の癖が出てしまいそうなところを挙げてみます。

文字間のスペース

  • 半角文字と全角文字の間には、半角文字 1 字分のスペースを入れる。ただし例外は
    • 半角文字の前後が『』 「 」 。、の場合は半角スペースを入れない。
    • 丸括弧 ( ) の外側には、全角文字がきても半角文字がきても半角文字 1 字分のスペースを入れる。
    • 丸括弧 ( ) の内側には、全角文字がきても半角文字がきてもスペースを入れない。
    • コロン : の前には半角スペースを入れない[1]。
    • 半角数字の前後には半角スペースを入れない(日時など。例: 2009年5月10日12時30分48秒、1件のコメント、150ピクセル)

です。これははじめに意識しておかないと、うっかり適当にやってしまいがちです。

外来語カタカナ末尾の長音表記

基本的には内閣告示第二号「外来語の表記」に従います。

ざっくり言うと原則として、英語の語末が -er、-or、-ar のときは長音記号を付け、-y のときは長音記号を付けません。ただし例外も多くあります。

漢字かな表記

漢字にするかかな書きするかは

  • 原則として名詞と動詞には漢字を使い、接続詞、連体詞、助動詞、補助動詞、助詞、連語、形式名詞、接頭語、接尾語はかな書きにする。

です。「日本語スタイルガイド」 (長いほうの PDF) の付録に一覧表があります。「してください」「すでに」「すべて」「だれも」などはかな書きです[2]。

ここまで、WordPress 本体のガイドラインを紹介しました。テーマやプラグインもぜひこれに準拠してほしいと思います。

Codex もほぼ準拠していると思いますが(どこかにガイドラインが示されていましたっけ?)、外れているものもけっこう見られます。括弧が全角になっていたり、和文-欧文間のスペースがあったりなかったり……。今回のような催しをきっかけにこのあたりのルールも整備されればいいなと思います。

ところで、「用語」は、WordPress 本体やテーマ・プラグインを参照して、合わせる必要があります。WordPress 本体で見かけた語が Codex では別の訳語になっていた、ではたいへん困ります。手間ではありますが、すでにある訳語を探して、合わせましょう。どうしてもそれらが間違った訳と思える場合には、それぞれの作者・翻訳者、日本語版作成チームに連絡して、連携して全体をよくしていきましょう。

それでは、Happy translating!

  1. 「日本語スタイルガイド」に明記はされていませんが、例文によるとこうなっています。↑
  2. 「すべて」「だれ」がかな書きなのは、この日本語スタイルガイドが作られた時点では常用漢字にそれらが含まれていなかったからだと思います。2010年の改定で「全て」の読み「すべて」、「誰」という漢字が含まれたので、今後はこれらは漢字書きでもいいかもしれません。しかしいま勝手にそう判断しても統一がとれませんので、全体の合意が形成されるまで当面はかな書きのままとしましょう。↑