Clannad英語版の特徴

そういえば、Clannad英語版の本編、まだ詳細を書いてなかったかも。
Clannad英語版タイトル画面
基本的にはClannad Fullvoiceが英語になっているものです。
メニュー項目で増えているのは「Dangopedia」と「Achivements」(実績)ですね。(ゲーム機版には実績機能はあるのかも知れませんが……。)
Clannad実績
この画面はSteam版のものなので、Steamの実績と連動しています。Dangopediaは本編と連動した機能で、文中に出てくる単語を解説してくれる機能です。
Clannad単語ハイライト
例えば、この画面では「anpan」という単語が赤くハイライトされています。これはDangopediaに当該項目があることを意味しています。
Clannad Dangopedia
例えば、この場合、anpan(あんぱん)に関して、Dangopediaに上記のような形で解説されています。
ちなみに英語版においては、三点、向上している点があります。
一点目は画面のアセットがHD版になっている、という点。
Clannad画面サイズ
上の画面サイズは1680×1050ですが、そのサイズに比べても内容が高解像度で表示されていることがわかります。(この画面写真はWINEで動作させているものなので、実際にネイティブ環境で動かしている場合は一部表示が異なる場合があります。もちろん、WINEでの動作は公式のサポート外です……。普通には動くのですが、ムービーの再生などに難があるので、一般人の人は普通にWindowsで動かしましょう……。)
二点目は、音楽がリファインされている点。こちらは違いは微妙だったりするのですが、印象が異なっている曲はあります。
三点目はDRMがなくなっている点。プレイするのにディスクを入れる必要がありません。ちなみにSteam版ではSteamクラウドに対応しているようで、セーブデータはオンライン保存ができるようになっています。
と、まあ、各種メッセージ等は英語ですが、声なんかは普通に日本語ですので。Sekai Project版ではプラネタリアンなんかは日本語も設定できるようにしてくれていますが、これがClannadに踏襲されるかは分かりません。(Dangopediaなど、独自作成部分が多いから難しいかな……Steam上で表示される実績は日本語ですが。)

Clannad英語版(ディスク版)開封の儀みたいなもの

今日、この大きな箱が到着。
Sekai Projectより到着した箱
結構大きい……。ゆのさんと比べるとこんな感じ。
ゆのと大きさを比較
開封の儀みたいなものをやってみます。
開封
中は大きくともまあ、ほとんどが緩衝材です。
内容
内容的にはTierとして指定したものではなくて、デジタル版・ディスク版セットの上にいろいろとアドオンを追加したりしたものです。尚、プロジェクト自体はまだ続いている部分があるので、これは完全な発送ではないようです。

このボックス内の内容は:

  • Clannad英語版本体
  • ミニ色紙セット
  • オリジナルサウンドトラック
  • タペストリー

ミニ色紙セットは、箱の絵、実は持ってたりする画集の表紙の絵、もう一つは多分描き下ろしになっています。
Clannad英語版ボックス
ゲーム本体は特別な箱に入っています。
Clannad英語版ボックス裏面
裏はこんな感じ。
Kickstarterシリアル番号
シリアル番号が打ち込まれていて、自分のは920でした。自分のバッカー番号が1424だったので、もしこれが同じ基準であるとすれば、ディスク版を追加したのは65%ぐらいなのかも。ただし、1400番台ということで、結構熱心なファンが多い頃合いだったかも知れないので、このあたりは完全に憶測の域を出ません。そもそもこの番号が対応しているのかもわからないので。この箱に関してはもう少しあとで。
Clannad OST
サウンドトラックは日本で2014年に販売されたKSLA-0012〜14です。と考えると、ゲーム内の音楽はリファインされているということですので、実はこのサウンドトラックの一部はゲーム内のものと異なる、ということですね。
ゲームの箱に移ります。
Clannadガイドブック
箱を開けるとまず入っているのがオフィシャルガイドブック。紙質も内容もなかなかしっかりしています。
Kickstarterバッカーリスト
Kickstarterのバッカーのリストがあるのですが、アルファベット順でもなく、自分を探し出すのに20分ぐらいかかりました。どんな順番になっているのかは不明。
Clannad英語版ディスク
その下に入っているのが英語版ディスク。ちなみにDRMはかかっていない(はず)です。
Clannad MABINOGI
その下に入っているのはアレンジサウンドトラックのMABINOGI。これは確か日本でも初回版以後は入ってなく、別売りもなかったと思うので新品としては実はかなり貴重なのかも知れません。
Clannadタペストリー
最後にタペストリ。こちらは箱の絵と同じです。
ということで、開封の儀(みたいなもの)でした。WINE立ち上げてプレイせねば。

なぜInboxよりもGmailが使いやすいか

ここ半年ほどInboxを使ってきましたが、Gmailの方が使いやすいな、と感じる部分がいくつか。ちょっとまとめてみる。

Inboxでの利点

Inboxのナビゲーション自体は良く出来ていて、全体的には使いやすいと感じる。添付ファイルなどが入っているとそれが大きく表示されるし、また全体的に使っていてより楽しいのがInbox。

処理的にもかなり意欲的な出来であり、メールの扱いのやり方を変えよう、という発想があるのは面白い。

短所と感じる部分

でも使っていて、使いにくいと感じる部分も多い。ほとんどがGmailで出来て、Inboxで出来ないことなので、かなり惜しく感じてしまう。

アドレスごとの署名管理がない

InboxではGmailと同じように複数のメールアドレスを管理できるのだが、Inboxには他のアドレスを使用した場合に、署名を切り替えることができなくなっている。コンベンション用など使い分けているのでこれができないのは非常に致命的。

HTML形式がデフォルトで変更できない

Inboxは送信メールはHTML形式がデフォルトであり、切り替えることができない。Gmailにはテキストメールへの切り替えができるようになっている。妙なメタデータが紛れ込んだりするので、できるだけHTMLは送信しないようにしているのでこれはかなり不便だったりする。

ソース表示ができない

これは多分99%の人には関係ないのだろうけど……。Gmailのメールはソースを見ることができないので、ヘッダの確認などをすることができない。微妙なメールが届いた時にざっと確認する場合もあるので、是非欲しいところなんだが。

変更ができない言語に依存した返信ヘッダ

これも煩わしい問題。Gmailで返信をすると次のようなヘッダが追加される。

2016-02-17 13:26 GMT-08:00 John Doe <johndoe@example.com>:

これをInboxですると次のような感じになる。

2016年2月17日(水) 13:26 John Doe <johndoe@example.com>:

なぜGmailの方が優れているかというと、受取人の言語に依存しないから。受け取る人が日本人であろうと、あメリカ人であろうと全く問題がない、言語非依存の形式お使用しているのがGmail。Inboxの場合、日本人しか読めない。せめて形式を指定できればいいのだが。

まとめ

上記を書いた後に考えると、恐らくInboxが想定しているのは読むのが主で、カジュアルなユーザーなのかな、と。Gmailにある機能がInboxに入るかその逆があればすごいいいと思うのだが……。

なぜGrub2の認証脆弱性は大きな問題ではないか

Linuxのブートローダー、Grub2にバックスペースを28回押すとレスキューシェルに入れてしまうバグがあるということがこの数日報道されています。

脆弱性があるということ自体に問題があるということを否定するわけではありませんが、まず、Grub2を含む、ブートローダーの認証を過信するのが問題です。実質的にブートローダーの起動パスワードが入力できる状態であるということは即ちハード自体へのアクセスがあることを意味します。ハード自体へのアクセスが行えるのであれば、ブートローダーをUSBドライブ経由などから読み込ませて起動すれば、レスキューシェルなど、簡単に実行できてしまいます。ハードのアクセスが物理的に行える以上、この脆弱性が存在しようがしまいが、本質的にはセキュリティには全く影響しないのです。

そのため、セキュリティ問題としてこの問題を解消するには次のような施策が必要になってきます。

  • ハードへの物理的なアクセスを制限する。
  • パーティションを暗号化する。

尚、Grub2の認証機能自体、そもそも幻想のセキュリティを提供する形になってしまっていますので、本来はこんな機能自体削除しまったほうがいいぐらいです。(カジュアルな運用でレスキューシェルへ簡単にアクセスできてしまうこと自体が問題になるのであれば、ブートローダーからレスキューシェルは取り外して、必要に応じてそれを有効にしたブートローダーを外部メディア経由で起動するほうが余程マシな運用です。)

OnionShareを使用した安全なファイル共有

OnionShareを使用することにより、簡単にファイルを共有することができます。

OnionShareはTor秘匿サービスの仕組みを使用しています。秘匿サービスを使用することにより、検閲システム等に影響を受けにくく、また、点から点を暗号化された接続で結ぶことにより、第三者にファイルを預けることなく、Torのネットワークを介して、データを転送することができるようになっています。

OnionShareを使用するのに必要なものは次の二点です。

上記をダウンロードし、インストールした後は、まずはTor Browserを起動します。

TorBrowser

Tor Browserが正常に起動したのを確認した後、OnionShareを立ち上げます。

OnionShare起動後

OnionShareでファイルを選択します。

OnionShareファイル追加後

Start Sharingボタンを押します。(●表示が黄色になります。)

OnionShareファイル公開準備中

●が緑色になったら表示されている.onionアドレスを読み、受信者に伝えます。(そのままコピーすることもできます。)

OnionShareファイル公開

受け取り側はTor Browserを開いて提供された.onionアドレスを開きます。

TorBrowserで表示したOnionShare

ダウンロードのボタンを押すとダウンロードが開始されます。尚、受信者側で次のような警告が表示されることがあります。(既定で表示される。)

TorBrowserダウンロード警告

これはファイルが持つ潜在的な危険性(例えば、実行ファイルなど)を警告するものです。ZIPファイルにはそのようなファイルが入っている可能性があるため、この警告が表示されるようになっています。ダウンロードするだけでは危険はありませんが、内容物に含まれるファイルが匿名性を損なわせる可能性があることを警告している文言です。

OnionShareダウンロード完了

既定では受信者がダウンロードを完了すると、自動的に公開は停止されます。Stop sharing automaticallyのチェックを外すと自動的に停止されないので、複数の人にダウンロードしてもらう場合は、このチェックを外す必要があります。(ファイルの公開が停止された後に、再公開すると別のアドレスが生成されます。)重要なのは相手がダウンロードを完了するまで、OnionShareの共有は有効にしておく必要があります。

このようにファイルを手軽に転送できますが、特徴として以下が挙げられます。

  • 点から点への暗号化接続
  • Torに接続できている限り、ポート転送などの設定は必要なし
  • サイズの制限なし(システム上のファイルサイズの制限などに依存します。転送速度は遅めになります。)
  • Hidden Serviceが備える高い匿名性(ただし、その匿名性は当然.onionアドレスを知らせる手段により変化します。)

恒久的に、特に不特定多数にファイルを提供する場合、Webサーバを使用したHidden Serviceサイトを構築する方がいいですが、手軽にファイルを特定の相手に転送するのには便利かと思います。

LINEのLetter Sealingに関するフォローアップ

9月1日にLINEのE2EE実装「Letter Sealing」初見という記事を書いて、そこに

(公式情報が投稿され次第、加筆などはする予定です。)

と書きましたが、本日、メッセージの安全性新時代:Letter Sealingという記事が公式ブログのLINE Engineers’ Blogで公開されてますので、公約通り、加筆します。

基本的、公式サイトで解説されているのはLetter Sealingはごく一般的な公開鍵暗号方式が使用されているということです。鍵交換方式はECDH、暗号化はAES-CBC-256HMACと、方式的にはOpenPGPなどで使われている機構とそう変わりません。(ECDHはちなみにGnuPG 2.1で対応しています。)

ここで気になってくるのはECDHを使っているという表記。もし、これを額面通りに受け取るのであればLINEの実装はPerfect Forward Secrecyを実装していない、ということになります。(もし実装しているんであれば、DHEなり、ECDHE使ってますって書くよね?)
PFSは最近のメッセンジャーの暗号化の実装では一般的なもので、セキュリティを高めるのに非常に重要な要素なので、この実装はぜひ検討していただきたいものです。

また、前回の記事でも指摘したように、メッセージが暗号化されているかどうかがわからないのがこのシステムの致命的なところですが、それに関しては修正が検討されているようなのでよかった。

なお、この手の情報を一般向けに取っ付き易く説明するのは非常に骨の折れる話です。LINEのエンジニアのブログではそのあたり、結構丁寧に解説しているので、この点は非常に賞賛できると思います。

翻訳に関するあれこれ

今回は翻訳について書いてみる。

公私問わず結構翻訳することがあるのだが、今回はそのことについて書いてみたい。(ただし、翻訳を専業とする翻訳専門家ではないので、そのあたりは少し含んで読んで欲しい。ただ、翻訳をアウトソースすることも多く、このあたりの流れはある程度は掴んでいる。)

翻訳の方法

ベタ翻訳

支援ツール(これらについては後述)などを使わない方法で、そのままテキストファイルなどを翻訳する方法。一番大変な方法だが、画像や、プロテクトされたPDF、果てはOCRできないクオリティの印刷物を翻訳するにはこの方法しかなかったりする。当然手間がかかるので翻訳会社などに頼む場合、支援ツールが使えるか否かにより納品までの時間はより長くなり、高くなる。(逆に翻訳会社に翻訳を頼む場合、元ソースが編集不可のものである場合は一度翻訳元の言語で編集可能なフォーマットに落としたほうが早く安くなる。)

編集できるフォーマットであってもソースコードのコメントを訳してほしい、というような場合など非翻訳部分が多く含まれる場合はやはり翻訳が部分のみを抽出して渡した方が安くなる。(そもそも原文の単語数でコストが決定される場合が多いので・・・・・・。)

検索支援ツールを使用した翻訳

ベタ翻訳は大変で、時間もかかるので、その負担を軽減するために開発されたのが各種の検索支援ツール(CAT — Computer Assisted Translation)ツール。Google Translateみたいな機械翻訳をイメージするかもしれないが別物、とはいえ、機械翻訳は翻訳のベースとして使用することはあるので、関連した技術とも言える。商用ではTRADOSなどが有名。(結構お高い)無料のものではOmegaTなどがある他、Googleもウェブアプリとして、Google Translator Toolkitを提供している。なお、フォーマットなどもタグ化されるので、例えば、太字などの装飾が行われている場合でも翻訳結果にそれを反映させることができる。前述のように機械翻訳を組み合わせて使えるので、その翻訳結果が提示するコンテキストを汲み取り、意味が通るように修正しながら作業を行うことにより、効率が大幅にアップする。対象文書の機密具合で機械翻訳が使用できない場合、時間とコストが上がる。(最近、安く翻訳してくれる翻訳会社が増えた背景にはこういった技術が使用できる、という背景があるように思われる。)

翻訳支援ツールは翻訳文(文節)を翻訳メモリと呼ばれるファイルに保存する。これはデファクトスタンダードがあって、TMXというXMLファイルが広く使われている。翻訳メモリを使用することにより以下の利点が生まれる。

  1. 同じ原文が提示される場合、以前の翻訳結果が再利用できるので、何度も同じ原文を翻訳する必要がなくなる。
  2. 上記に関連して、似た原文がある場合、それも提示されるので、訳文のばらつきを抑えることができる。
  3. 同じ原文の更新版が提供された場合、差分を取る手間を省き、以前の翻訳文を再利用できることができる。
  4. 複数の訳者がいる場合、共有することができる。

翻訳支援ツールには単語集機能が大抵装備されていて、単語が登録されている場合、その訳文を表示してくれる。専門分野で翻訳が必要な場合は、文中に現れる分野で広く使われている対訳があればあらかじめ訳者に提供しておくと翻訳の精度が高くなる。(こちらは共通フォーマットはないので、CSVなどリストとしてオーガナイズした形で準備するとよい。)

翻訳の質について

ほとんどの翻訳会社はいろいろな種類のドキュメントの翻訳をやってくれるが、それをどのような用途に使用するか、ということに関しては留意する必要がある。以下のようなケースでは特に注意。もちろんそれらに特化した翻訳会社もあるので、検討するのが望ましい。(そういった翻訳会社は当然価格が高くなる傾向にある。)

翻訳者は訳者であって文章の創作者ではないので、有能な翻訳者こそ、原文に忠実にあろうとする傾向があるのに注意する必要がある。

文芸作品

文芸作品の翻訳を頼む場合、そのまま出版できるクオリティのものは期待してはいけない。あくまでもあらすじをつかめるもの、ぐらいの認識でないといけない。これは簡単な話、訳者は訳者としての能力はあっても、文筆家であるとは限らないから。こういった作品の出版としての翻訳はそういった専門の知識を持った翻訳家に任せる必要がある。(反対に文芸作品の翻訳ができる人とというのは、翻訳言語で本が一冊書ける能力を持った人であるということ。)

意匠性の高いコピー

スローガンや、商品のキャッチコピー等。以前アップルの日本語キャッチコピーが直訳すぎると話題になったことがあったが、まさにあんな感じ。訳者はコピーライターではないのでどうしても直訳っぽくなってしまう。コピーライターがちゃんと書きなおせば、と思うだろうけど、そもそもコピーライターに原文を読解する能力があるとは限らないという問題もあり、特に異なる言語での一意性にこだわる会社(多分アップルもそう)だとジレンマになってしまうのではないかと思う。(まあ、これは会社のポリシーにも問題があるんだろうけど。)

契約書、法文書など、法的な文書の翻訳

契約書などの翻訳は一般的な翻訳の場合、その有効性・対応性に疑義が生じる可能性があるので注意。これは原文の地域と翻訳言語を使用する地域の法律が当然ながら違ってくるので、双方の法知識が必要になるため。

最後に

他のどのような仕事と同じように、納期、価格と品質のうち優先度を選べるのは2つまでであるので注意すること。安くて納期が速くかつ品質が高い仕事などというものはない。(良心的な翻訳家は品質を低くするような仕事は受けないのでここでは価格と納期のどちらかを選ぶ決断になる。ただし、無理な仕事を押し付けたり、不当に催促したりすると、当然の話、チェック時間などに取れる時間が短くなるので品質は低下することになる。)翻訳に関しては具体的に言うと、一日に捌ける仕事量というのは決まっているので、例えば、その限界に近い仕事を依頼すると他の仕事を止めたり、私用の時間を割いたりする必要が出てくるので当然価格が高くなる。なので、余裕を持ったスケジュールで臨むのが翻訳料を下げる方法の一つとなる。