@fugaco

英会話練習アプリ「Supika」とか

日常的に英語での読み書きリスニングはしていても、スピーキングとなるとなかなか機会がありませんよね。スカイプでやる英会話なんかが最近は多いですが、私は家で一人になれる時間がゼロですし、まとまった時間もほとんど取れません。なので、例え30分足らずでも、スカイプで話し続けるというのは難しいと思うんです。それから、生身の人間相手はちょっと…と最初は敬遠してしまう人もいますよね。そんな人におすすめなもの少しだけ紹介したいと思います。



生身の人間相手が難しいなら、コンピュータと寂しく話すしかないんですが、最近の音声アプリは高性能ですよね。


Supiki
http://supiki.com/



英会話の練習アプリです。ある女性の仕事先や恋愛の話を中心に展開するショートビデオを見た後に、関係する会話に参加します。こちらの発言によって相手の返答が変わるので、いろいろと返事を変えてみると面白いです。

例えば店員さんにコーヒーをかけられてしまって、「すみません、大丈夫ですか?」と言われる回があるんですが、テンパってると「It's okay.」くらいしか言えないこともありますよね。日本語でも、車に当てられてテンパって「大丈夫です」って言っちゃいますし。このアプリでなら、「大丈夫じゃないです!見てくださいこれ!びしょ濡れです!」なんて練習もできますし、そうするとその後の展開も少し変わります。

最初の方の回は基本的に「Yes/No」や「どっちが~」で応えられる簡単な質問が多いですが、「Yes, I do.」だけを答えるのではなくて、「Yes, I do. It's xxxxx. How about you?」などと会話に肉付けできるようになるといいと思います。どんな言い回しがあるのかは、他の人がどういう会話をしているかを聞くことができます。

まだ前半しかやっていませんが、レベルはやさしめだと思います。子供の声が入ってしまうので、ときどき聞き取りエラーを返されてしまい、なかなか進まないときもあります・・


google翻訳

Lang-8でロシア語の勉強をしているときに、google翻訳の音声入力機能で自分の発音チェックをするといいと教えてもらいました。英語以外にも、ロシア語、フランス語、ドイツ語、各種中国語、などなど多くの言語で音声入力ができました。フィンランド語は非対応だったかな?日本語の翻訳性能は悪いので、あくまで、しゃべった言葉がきちんと認識されているかどうかのチェックに使うといいと思います。ちなみにロシア語の発音チェックでは、英語に訳すようにしています。英語の翻訳なら、割とマシです。ハラショー。


Siri

iPhoneやiPadに入っている、音声ガイダンスです。私は充電節約のためにOFFにしていますが、日本語以外のSiriとも会話できるので、試してみると面白いと思います。ただ、日本語以外のSiriは、結構反応が遅かったです。ウェブで何か調べてるんですかね?



なんか大して目新しくない情報ですみませんが、google翻訳もSiriも、私にとっては盲点だったので載せてみました。Supikiのようなアプリ、他にもあったら教えてください。もう少しビジネス寄りだといいかなあ。

翻訳を少し経験しました

少し前の話ですが、翻訳関係のプロジェクトがあったので、翻訳の勉強をしました。語学は好きですが、翻訳は初めての領域です。よく言われることですが、英語ができることと翻訳ができることは別物ですよね。

プロの翻訳者が、「日本語ができても小説は書けないのはみんな知っているのに、英語ができれば翻訳もできると軽んじられている」と言っていました。これって、プログラミングができても、ソフトウェア製品を作れないのと似ているかもしれません。(普通に動くものは作れるでしょうが、製品としての欠陥があるかもしれないということです。)


翻訳には3分野あるようです。
  1. 文芸翻訳・・・小説などの翻訳
  2. 映像翻訳・・・映画やゲームの翻訳
  3. 産業翻訳・・・ビジネス上の翻訳(技術翻訳ともいう)

翻訳と言うと(1)文芸翻訳や(2)映像翻訳をイメージすることが多いですが、(3)産業翻訳が業界の9割ほどを占めているようです。(3)産業翻訳にはメールの翻訳、マニュアルの翻訳、契約書の翻訳、などなどビジネス上で必要なあらゆる翻訳があり、その分野も医療、IT、特許、製造、などなど多岐に渡っていました。

今回私が関わったのはIT系の(3)産業翻訳ですが、IT系の仕事は量が多く参入しやすい反面、質より量を求められ、賃金は下降傾向にあるそうです。若い人や元SEが多いとか。なるほど。


参考までに、私が読んだ本を一部紹介します。
うちの市の図書館は本当に品ぞろえが悪いので、買うはめになることが多いんですが、借りた本の方が買った本よりも有用だったりすると、ちょっと切ないです。





他には、Apple、Windows、Googleなどのライティングルール、シカゴマニュアル、日系企業のドキュメントなどなどを参考にしました。


例文を調べるのには、Google検索のほか、コーパスを使いました。Google検索だと、用法として間違っている文章でも検索に引っかかってしまいますが、コーパスならばニュース記事などが元になっているので、信頼性が高めです。また、「動詞+teeth」というような品詞を指定した検索もできるので、「teeth」を目的語に取る動詞には、どのような言い回しがあるのか調べたりもできます。

アメリカ英語のコーパス
http://corpus.byu.edu/coca/

こんな感じ。

corpus.png


コーパスなんて今回初めて知りました。他にも翻訳を通じて、いろいろと新しいことを勉強することができたので、またいつか役に立つといいと思います。

英単語の漫画 (3) - click

ソフトウェア開発者にはとても身近な単語「click」ですが、「異性にビビビッと来る」なーんて意味もあるんですよ。 

そんなclickが漫画になっていたので紹介します。

 

-----

http://www.ecenglish.com/learnenglish/lessons/word-day-click

 

click idiom

この漫画は click に複数の意味があることをベースにしています。

名詞の click は、短くてはっきりとした音です。

"The door closed with a click."

"Turn the handle until you hear a click."

口語英語では、click は突然何かを理解したり思い出したりしたときの状況を表すのに使います。

"When she started talking about Boston, it suddenly clicked where I had met her before."

"I had to read the report a couple of times before it clicked."

seat belt とは、乗り物や飛行機で移動するときに体の回りに締めて、事故が起こったときに体をシートに固定するためのものです。(訳注:日本人なら説明されなくても分かりきってますよね。笑)


-----


一応漫画の台詞の意味を書いておきます。 

「どうやってシートベルトを締めたらいいか分からなかったんです。でも突然ピンと来たんです。」 

頭の中で何か(it)がひらめく(click)様子と、シートベルトがカチッと言う(click)様子を掛けた漫画でした。 

ソフトウェアのローカライズにおける12カ条

少し昔の記事ですが、ざっと訳してみました。
英語で開発している前提なので、日本語で開発している私たちとは少し条件が異なりますが、参考になると思います。


Twelve Commandments Of Software Localization
http://coding.smashingmagazine.com/2012/07/18/12-commandments-software-localization/


-----

あなたは新しいウェブサイトを社内発表し、大好評を得ました。デザインは新鮮で、コードにはバグがなく、いつでもリリースできる予定でした。そのとき、ある社員が言いました。「このサイトは日本語でも動きますか?」

あなたは何と答えていいか分からず、汗だくになりました。このサイトは英語で作っていて、他の言語は後からリリースしようと思っていました。とにかく他の言語にも対応させなければなりません。リリース日が過ぎ、その後二ヶ月はバグの修正に追われ、しかもバグの半分を見落としていたことに気づきました。

ローカライズすると、アプリはどんな言語にも対応できる準備ができます。しかも、最初からローカライズしておいた方がより簡単です。以下の12の簡単なルールに従えば、世界中のどこでも動かせるようになりますよ。



1. すべての文字列をリソース化すること


ローカライズの最初のステップでは、ユーザーが目にする文字列をコードから抜き出し、リソースファイルに記述します。例えば、タイトル、製品名、エラーメッセージ、画像の中の言葉など、ユーザーが見るかもしれないすべての文字列です。

大抵のリソースファイルでは、それぞれの文字列に名前を付け、その文字列に別々の翻訳語を設定できるようにします。多くの言語は、次ようなプロパティファイルを使っています。

name = Username


もしくは、次のような .pot ファイルや、

msgid "Username"
msgstr "Nom d'utilisateur"


XLIFFファイルを使います。

<trans-unit id="1">
 <source xml:lang="en">Username</source>
 <target xml:lang="fr">Nom d'utilisateur</target>
</trans-unit>


ライブラリはリソースファイルを読み込み、ロケールと言われる言語と国の組み合わせを元に、適切な文字列を特定します。
文字列をリソースファイルに別にして置いておけば、アプリでサポートするロケールごとにそのファイルを翻訳者たちに送り、翻訳してもらうことができます。



2. 文字列は絶対につなげないこと


ある文字列を別の文字列とつなげると、ほとんどの場合ローカライズ上のバグになります。例えば色などの修飾語句でよく起こります。
ある文房具ストアで、鉛筆、ペン、用紙などを扱っていると仮定しましょう。利用客は買いたい物を選び、色を選択します。そしてショッピングカートで「red pencil」「blue pen」などと表示するために、次のような関数を使うかもしれません。

function getDescription() {
    var color = getColor();
    var item = getItem();

    return color + " " + item;
}


このコードは、色が先に来る英語では正常に動きますが、フランス語ではおかしくなります。フランス語では、「red pencil」は「crayon rouge」に、「blue pen」は「styloencre bleue」と訳されるからです。フランス語(だけではありませんが)では、修飾語句が修飾される語の後に来ます。単純に文字列をつないでいる getDescription 関数では、フランス語のような言語には決して対応することができません。

これを解決するには、パラメータ化された文字列を使い、品名と色の順番を言語によって変えるようにするのです。次のようにリソースの文字列を定義します。

itemDescription = {0} {1}


十分には見えないかもしれませんが、これできちんと翻訳ができます。これを新しい getDescription 関数で使ってみましょう。

function getDescription() {
    var color = getColor();
    var item = getItem();

    return getLocalizedString('itemDescription', color, item);
}


このように、翻訳者が簡単に語順を変更できるようになります。

itemDescription = {1} {0}


この getLocalizedString 関数は、itemDescription というリソース文字列名とは別に、color、item というパラメータを取り、そのリソース文字列にあるプレースホルダをパラメータで置き換えます。

このメソッドは、テキストを含む文字列でも使用できます。

invalidUser = The username {0} is already taken. Please choose another one.

({0}というユーザー名はすでに使われています。別の名前を選択してください。)



3. 句読点はすべてリソースファイルに記述すること


句読点は後から付け加えた方が絶対にいいと思うかもしれません。そうすれば同じ文字列を使いまわせて、例えば、ラベル用にコロンを付けたり、ツールチップ用に何も付けなかったりできます。しかしこれも、文字列結合の悪い例です。

WordPress の PHP を使った簡単なログインフォームを考えてみましょう。

<form>
<p>Username: <input type="text" name="username"></p>
<p>Password: <input type="text" name="password"></p>
</form>


他の言語でも動くように、文字列をローカライズします。WordPress では、__(アンダースコア2つ)という関数で簡単にローカライズできます。

<form>
<p><?php echo(__('Username', 'my-plugin')) ?>: <input type="text" name="username"></p>
<p><?php echo(__('Password', 'my-plugin')) ?>: <input type="text" name="password"></p>
</form>


どこがバグか分かりますか?ここでも文字列をつなげてしまっています。ラベルの後ろのコロンがローカライズされていません。これはフランス語などでは間違った表記です。フランス語では、コロンの前後にスペースが必要です。句読点は文字列の一部なので、リソースファイルに記述します。

<form>
<p><?php echo(__('Username:', 'my-plugin')) ?> <input type="text" name="username"></p>
<p><?php echo(__('Password:', 'my-plugin')) ?> <input type="text" name="password"></p>
</form>


これならば、英語では Username: となり、フランス語では Nom d'utilisateur : とできます。


続きを読む "ソフトウェアのローカライズにおける12カ条"

コンピュータには決して解けない問題とは

今日は春一番が吹きましたね。暖かくなってくるとわくわくしませんか。

最近WIREDの記事をいろいろ見ているのですが、停止性問題について扱っている記事があったので和訳してみました。訳した後に、日本語のこの記事の方が短くて分かりやすいと思いましたけどねっ。(o´ω`o)



The Questions That Computers Can Never Answer
http://www.wired.com/wiredscience/2014/02/halting-problem/


コンピュータは車を運転したり、火星に探査機を送ったり、Jeopardy(TV番組)で人間に勝つことができます。しかし、コンピュータにもできないことはあるのかと考えたことはありますか。もちろんコンピュータにはハード面での制限があります。私のスマートフォンは電気カミソリの代わりにはなりません。けれどもそれは物理的な制約で、もし本当にやろうと思えばできる類のことです。ですので質問をもう少し正確に言い換えると、コンピュータが解決できない問題はあるのか、ということです。

もちろん現時点ではコンピュータに解くことの難しい問題は山ほどあります。例えば学校では、30 = 2 × 3 × 5 や 42 = 2 × 3 × 7のような因数分解を習い、学生は単純な手順で因数分解を解く方法を教わります。それでも、2007年までは以下の数字の因数分解に10万ドルの懸賞金がかけられていました。

1350664108659952233496032162788059699388814756056670275244851438515265106
48595338339402871505719094417982072821644715513736804197039641917430464965
89274256239341020864383202110372958725762358509643110564073501508187510676
59462920556368552947521350085287941637732853390610975054433499981115005697
7236890927563

そして2014年現在、誰もこのパズルを説いたと公式に発表する人はいませんでした。解き方が分からないのではなく、単に解くのにとても長い時間がかかるのです。コンピュータはそんなに処理が早くありません。(インターネットは暗号化技術のおかげで成り立っていますが、暗号化はこのように因数分解するには果てしなく難しい大きな数字が元になっているのです。)

では、現在の技術面での制限を受けないように質問を言い換えてみましょう。どんなに高性能なコンピュータで、どんなに時間をかけても、答えられない問題がコンピュータにはありますか。

意外にも、答えはイエスです。停止性問題(Halting Problem)というのがあり、あるコンピュータプログラムがあったとき、それはいずれ終了するか、それとも永遠に動き続けるか、という問題です。これはとても日常的な問題です。なぜなら無限ループというのは、プログラムのコードににひっそりと入り込む、典型的なバグだからです。1936年に、天才数学者で暗号解読者であるアラン・チューリングが、あるコードを走らせたときに終了するかしないかを検証することは、コンピュータにとって不可能であることを証明しました。言い換えれば、チューリングは停止性問題を解けないことを証明したのです。

ファイルをまとめてコピーすると、進捗バーが例えば99%で止まってしまった…そんな経験はありませんか。どの時点で、動き出すのを待つのを諦めますか。永遠に動かないのか、あるいは、数百年待てばいつかはコピーが完了するのか、どのように判断したらいいでしょう。スコット・アーロンソンの言葉を借りて言えば、「もし自分の時計が永遠に止まらないことを掛けたら、いつ勝ちを宣言すればいいのだろうか。」

copying

コピーの進捗バーが動くのを待つのが嫌になった人は、こういう厄介なバグを取り除くデバッグプログラムを誰か書いてくれたらいいのにと思うかもしれません。そんなプログラムが書ければ、Microsoftが大金で買ってくれるでしょう。しかしそんな挑戦をする前に、チューリングの忠告を聞きましょう。コンピュータは決して、コードがきちんと終了するかどうかを、期待通りに調べることはできません。

これがどんなに大それた要求かを考えてみましょう。チューリングは今日実現可能なことについて言っているのではありません。コンピュータがこの先実現可能なことに対しても、本質的な制限を掲げています。停止性問題を解けるコンピュータは、今も、この先も、2450年になっても、決して現れないのです。

チューリングの証明ではまず、コンピュータとプログラムの意味を数学的に定義する必要がありました。この準備を経て、伝統的な背理法を使い、証明を完成させることができました。チューリングの証明を理解するためのウォーミングアップとして、嘘つきパラドックス(Liar paradox)と呼ばれる例題を考えてみましょう。誰かがあなたに、「私は嘘を言っています。」と言いました。もしその発言が本当なら、発言の内容の通り、嘘を発言していることになります。もしその発言が嘘ならば、発言の内容とは逆に、本当のことを発言していることになります。しかしこれでは、発言が本当であり嘘でもあり、矛盾しています。この自己言及を使って矛盾を作る考え方が、チューリングの証明の中心になっています。

コンピュータ科学者のスコット・アーロンソンは、これについて以下のように説明しています。(訳注:ごめんなさい、この引用は上手く訳せませんでした。)
チューリングの証明は自己言及のすばらしい一例です。人間はなぜ完璧な内省ができないのかという古くからある討論を形式化させました。なぜなら、もし内省できるなら、今から10秒後に何をしようか決めることができて、それを実行することができるからです。チューリングは停止性問題を解ける特別なマシーンを想像してみました。そして、そのマシーンがマシーン自身をどのように解析するかを説明しました。それは、もし永遠に動き続けるなら止まり、止まるなら永遠に動き続けるようにさせることでした。自分の尻尾をつかんで食いつく猟犬のように、その架空のマシーンは矛盾という猛威の前で消滅しました。
"Ouroboros" by the Flipside CORE project  and Burning Man

さて、停止性問題はコンピュータには決して解けないというチューリングの証明、もしくは、なぜループ発見器を作ることはできないのかについて、考えを進めてみましょう。今から説明する証明は多少一般的ではないかもしれません。アラン・チューリングに敬意を表してGeoffrey Pullumがドクター・スースー風に書いた詩です。許可をもらい、ここにコピーを貼ります。


(訳注:ここに貼るのはよろしくないので、原文ページで確認してください。)


楽しく風変りな詩的表現に、チューリングの証明の落ちがあります。ここに、同じ原理の図を載せます。ひし形はループ発見器プログラム P を表しています。このプログラムは、フローチャートのプログラム Q が停止するかどうかを判断します。

loop-snooper-serpents-tail.png

自分の尻尾を食べようとする蛇のような、自己言及のパラドックスをチューリングは思い付きました。そのプログラムは、ループ発見器が止まらないと言えば止まり、止まると言えば止まりません。この矛盾を解決するためには、そんなループ発見器は存在しえないという結論に行きたいと思います。

この考え方による結論は応用範囲がとても広いです。コンピュータがきちんと正しい答えを導くことができない問題は、数えられないほど多く存在します。それらの解決不可能な問題の多くは、見方を変えればループ発見器と同じです。あるプログラムがウイルスかどうか、あるいは、付け込む隙のある脆弱なコードを含んでいるかどうかを特定する、というのも、コンピュータが完璧にこなせない作業です。完璧なアンチウイルスソフトや解読不能なソフトというものは、諦めるしかありません。2つの異なるプログラムが同じことを行うかどうかを判断することも、コンピュータには不可能です。コンピュータの授業の宿題を採点するハメになったかわいそうな人にとっては、不幸な真実です。

ループ発見器を消滅させることで、コンピュータができることには本質的な制限があることを、チューリングは教えてくれました。私たち人間には制限がありますが、私たちが作る人工知能にも同じように制限があるんだということは、ある意味安心するのではないでしょうか。

1/35  | 次のページ »

カレンダー

 «  2014年04月  »
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30      

検索