Showing posts with label English. Show all posts
Showing posts with label English. Show all posts

2018-07-24

しないでマイクロソフトのスタイルガイドライン準拠の翻訳

マイクロソフトは将来的に買収する見込みのGitHubで.NETのドキュメントを公開している。ハロウィーン文書が公開された頃のマイクロソフトからは考えられないほど変わったものだ。

https://github.com/dotnet/docs.ja-jp

その中にある変数名の命名規則に関するスタイルガイドラインについて書かれたドキュメントの文章がおかしい。

https://github.com/dotnet/docs.ja-jp/blob/live/docs/standard/design-guidelines/names-of-type-members.md

しないで動詞または動詞句は、メソッドの名前を指定します。

しないで名詞、名詞句、または形容詞を使用してプロパティの名前を付けます。

しないで次の例のように、"Get"メソッドの名前に一致するプロパティがあります。

しないで後に"List"または"Collection"単数形の語句を使用する代わりに、コレクション内の項目を記述する複数形の語句でコレクションのプロパティの名前を付けます

日本語として極めて不自然な文章になっていて意味がわからない。

原文は英語で書かれている。

https://github.com/dotnet/docs/blob/master/docs/standard/design-guidelines/names-of-type-members.md

原文を確認するとようやく意味がわかる。

DO give methods names that are verbs or verb phrases.

DO name properties using a noun, noun phrase, or adjective.

DO NOT have properties that match the name of "Get" methods as in the following example:

DO name collection properties with a plural phrase describing the items in the collection instead of using a singular phrase followed by "List" or "Collection."

なるほど、"DO"を間違えて「しないで」と訳してしまったのだな。"DO NOT"も「しないで」と訳されている。翻訳する上で間違えて機械的に置換でもしたのだろう。原文の文章の形をなるべく維持したまま日本語に訳すならば、"DO"を「正:」、"DO NOT"を「誤:」とでもすればいいのだろう。ただ、その場合"DO NOT"を使った文中で代替案も示してしまっているのが問題なので、これはできれば原文自体を「すべきこと」と「すべきでないこと」に分割すべきだろう。

そして間違いが20日にissueで指摘された。

https://github.com/dotnet/docs.ja-jp/issues/118

そして土日を挟んで今日、マイクロソフトから正式に回答があった。

https://github.com/dotnet/docs.ja-jp/issues/118#issuecomment-407202477

こんにちは、@megascus

言語に関するフィードバックをお寄せいただきありがとうございました。

お寄せいただいたフィードバックの内容を Microsoft の言語チームで検証いたしましたところ、残念ながら、マイクロソフトのスタイルガイドラインに従わない という理由で、承認基準に完全には適合していないという結果になりました。

記事の品質向上にご協力いただき誠にありがとうございました。引き続きお客様からの貴重なフィードバックをお待ちしています。

敬具

Microsoft DOCS International Team

そしてissueはclosedされた。

ん? である。問題は日本語の翻訳にあるのであってソースコードのスタイルガイドラインとは何の関係もない。上記の日本語を読解できるだけの日本語能力があるならば容易に気がつくはずで、まるでBOTによってなされたような回答だ。

その結果、マイクロソフト用語では"DO"は「しないで」を意味するのだとか、マイクロソフト社内では"DO"と"DO NOT"は同じ意味を持つのだとか、Google翻訳のほうがよっぽどマシな翻訳をしてくれるとか、ユーモラスなコメントが並ぶことになった。

マイクロソフト用語を使うと以下のようになる。

DO fix the document which has a translation error.

しないで誤訳を含むドキュメントの修正

DO translate with MS style guideline conformance.

しないでMSスタイルガイドライン準拠の翻訳

押すなよ、絶対押すなよ(押せ)、というダチョウ倶楽部メソッドを久しぶりに思い出してしまった。

2014-10-08

C++のtypeidとtype_infoとtype_index

10月の論文集が発表されるまで暇なので、typeidとtype_infoと、C++11から追加されたtype_indexの解説をする。

C++でRTTI(Run Time Type Infomation/Identification)と呼ばれる機能がある。

std::type_infoは、型情報を表現するクラスである。type_infoのオブジェクトは、typeid式で得ることができる。typeid式は、オペランドに式かtype-idを取る。typeid式の結果は、constなstd::type_info型のlvalueである。typeid式を使うには、typeinfoヘッダーをincludeする必要がある。

#include <typeinfo>

std::type_info const & t1 = typeid(int) ;
std::type_info const & t2 = typeid(double) ;

std::type_infoはデフォルト構築もコピーもムーブもできないクラスである。std::type_info型のオブジェクトは、typeid式によってしか作れない。

typeid式は、constなtype_info型のlvalueを返すので、type_infoを使う場合は、リファレンスかポインターで参照しなければならない。


std::type_info const & t1 = typeid(int) ;
std::type_info const * t2 = &typeid(int) ;

typeid式が返すオブジェクトの寿命は、通常とは変わっていて、プログラムが終了するまでである。つまり、以下のようなコードが動く。

#include <typeinfo>

int main()
{
    std::typeinfo const * ptr ;
    {
        ptr = &typeid(int) ;
    }

    ptr->name() ; // OK、
}

typeidが返すオブジェクトの寿命はプログラムの終了までなので、リファレンスやポインターで安全に保持できる。寿命や解放を考える必要はない。

type_infoのオブジェクトは型を表現する。type_infoのオブジェクト同士を等号比較することで、型が等しいかどうかを調べられる。


typeid(int) == typeid(double) ; // false

また、nameというメンバー関数を持っていて、これは実装依存の型を表現する何らかのnull終端された文字列を返す。

int main()
{
    std::cout << typeid(int).name() << '\n' ;
}

GNU/Linuxでは、IntelのItanium用のC++ ABIがデファクトスタンダードとなっていて、GNU/Linux用のGCCやClangでは、この仕様に従ったマングル名が返される。デマングルして人間にわかりやすい型にするには、以下のようにすればよい。

#include <cxxabi.h>
#include <cstdlib>
#include <string>
#include <memory>

struct free_delete
{
    template < typename T >
    void operator ()( T * ptr ) const noexcept
    {
        std::free( ptr ) ;
    }
} ;

std::string demangle( std::type_info const & ti )
{
    int status = 0 ;
    std::unique_ptr<char, free_delete >
        ptr( abi::__cxa_demangle( ti.name(), nullptr, nullptr, &status ) ) ;

    if ( !ptr )
    {
        switch ( status )
        {
        case -1 :
            return "memory allocation failure" ;
        case -2 :
            return "invalid mangled name" ;
        case -3 :
            return "invalid arguments" ;
        default :
            return "Shouldn't reach here" ;
        }
    }

    std::string result( ptr.get() ) ;

    return result ; 
}

それはさておき・・・

typeid式が実行時型情報と呼ばれている理由は、ポリモーフィッククラス型の式をオペランドに与えると、実行時になるまで分からない型を表現するtype_infoが返されるからだ。

struct A
{
    virtual void polymorphic() { }
} ;

struct B : A
{ } ;

void f( A & ref )
{
    // refがA, Bどちらを参照するのかは実行時に決まる
    // tiが表現する型も実行時に決まる
    decltype(auto) ti = typeid( ref ) ;
}

これにより、以下のようなコードを書くことができる。

struct Base { virtual void p() = 0 ; } ;
struct Cat : Base { } ;
struct Dog : Base { } ;

std::string get_name( Base & ref )
{
    decltype(auto) ti = typeid(ref) ;
    if ( ti == typeid(Cat) )
        return u8"猫" ;
    else if ( ti == typeid(Dog) )
        return u8"犬" ;

    return u8"謎" ;
}

もちろん、世間一般的に、この場合にはvirtual関数を使うのが礼儀正しい作法であるとされている。

struct Base { virtual std::string get_name() = 0 ; } ;
struct Cat : Base { std::string get_name() { return u8"猫" ; } } ;
struct Dog : Base { std::string get_name() { return u8"犬" ; } } ;


auto get_name( Base & ref )
{
    return ref.get_name() ;
}

さて、typeidの結果であるtype_info型は、かなり扱いづらい。すでに説明したように、type_infoはデフォルト構築、コピー、ムーブができず、typeid式から得られるオブジェクトを、リファレンスやポインター経由で参照して使うしかないからだ。これは、type_info型のオブジェクトの大量に管理したい場合に問題になる。オブジェクトを大量に管理するには、vectorやmapやunordered_mapなどのコンテナーを使いたいが、type_info型を直接使うわけには行かない。とすると、ポインターだろうか。

std::vector< std::type_info * > v ;

vectorならこれでよくても、やはり型情報という性質上、それぞれの型に何らかの値を付属させて、後から検索したい都合も出てくる。mapやunordered_mapで使いたい。

そのためには、type_info *型をラップするという手がある。しかし、正しくラップするのは、以下のように単調でめんどくさい。

namespace ezoe {

class type_index
{
public:
    type_index(const std::type_info& rhs) noexcept
        : target( &rhs ) { }
    bool operator==(const type_index& rhs) const noexcept
    { return *target == *rhs.target ; }
    bool operator!=(const type_index& rhs) const noexcept
    { return *target != *rhs.target ; }
    bool operator< (const type_index& rhs) const noexcept
    { return target->before( *rhs.target ) ; }
    bool operator<= (const type_index& rhs) const noexcept
    { return !target->before( *rhs.target ) ; }
    bool operator> (const type_index& rhs) const noexcept
    { return rhs.target->before( *target ) ; }
    bool operator>= (const type_index& rhs) const noexcept
    { return !rhs.target->before( *target) ; }
    std::size_t hash_code() const noexcept
    { return target->hash_code() ; }
    const char* name() const noexcept
    { return target->name() ; }
private:
    const std::type_info* target;
} ;

}

namespace std
{
    template < >
    struct hash< ezoe::type_index >
    {
        size_t operator() ( ezoe::type_index ti ) const noexcept
        {
            return ti.hash_code() ;
        }
    } ;
}

このコードは、誰が書いてもこのようになる。しかし、これを正しく書くのは面倒で、間違いやすく、しかもお互いに非互換なラッパーが乱立してしまう。そこで、このようなラッパー、std::type_indexが、C++11では標準ライブラリに追加された。使うには、ヘッダーファイルtypeindexをincludeする必要がある。

#include <typeindex>
#include <map>

int main()
{
    std::map< std::type_index, std::string > m =
    {
        { typeid(int), "int" },
        { typeid(double), "double"}
    } ;

    std::cout << m[typeid(int)] << '\n' ;
}

ドワンゴ広告

この記事はドワンゴ勤務中に書かれた。

次に解説すべきC++11で追加されたライブラリを探している。

ドワンゴは本物のC++プログラマーを募集しています。

採用情報|株式会社ドワンゴ

CC BY-ND 4.0: Creative Commons — Attribution-NoDerivatives 4.0 International — CC BY-ND 4.0

2013-05-04

ladyの語源はパン生地をこねる人、lordの語源はパンを守る人

lady - Wiktionary

lady(女)の語源は古英語のhlǣfdīġeにまでさかのぼることができる。これは hlāf (パン) + dīġe (メイド)の組み合わせであり、dǣġe (パン生地を作る人)とも関連性がある。文字通りの意味は、「パン生地をこねる人」である。

lord - Wiktionary

lord(主人)の語源は古英語のhlāford, hlāfweardにまでさかのぼることができる。これは、hlāf (パン) + weard (番人、守護者)の組み合わせである。文字通りの意味は、「パンを守る人」である。

パン生地といえば、ドーナッツはdough(パン生地) + nut(ナッツ)だと最近知った。

2011-08-25

米軍の言語専門家の無駄遣い

Lost in Translation: How The Army Wastes Linguists Like Me | Danger Room | Wired.com

抄訳。

2006年の冬のこと、私は軍隊に、言語専門家として志願した。外国語の翻訳を担当する兵士だ。軍の採用担当は、大学で何年もアラビア語を履修した私のジェイムズ・ボンド的技能を信用しなかったようだ。ともかく群の採用担当は、実地における経験を積めるよう配慮すると約束した。そこで、私は入隊して教育訓練を受けた。

2年間の教育訓練の後、国内でのアラビア語関連の仕事を経て、ついに2009年の3月、私はデルタ基地に着陸したブラックホークより降り立った。イラク南部のアルクートに近い基地だ。私の仕事は、傍受したアラビア語の通信を翻訳して、前線兵士に警告を出すことであろうと、私は考えていた。

任地で私を迎えた曹長の専門言語が朝鮮語であると知った時の、私の驚きを想像してもらいたい。どうやら、私の配属された5人班の半分は、朝鮮語話者であるようだ。イラクの砂漠で、朝鮮語の需要がどれだけあるというのか。これが、私の配属は、訓練内容とまったく合っていないのだと知る、最初の兆候であった。

イラクでの任務が始まり、私は、誰が言語を英語に翻訳しているのかという事実を、すぐに知った。それは、中年の巨漢なアラブ人であった。私ではない。モースル生まれのネイティブであり、我々の配属が必要としている翻訳の半分をこなす、民間人からの任用者であった。噂では、彼は20万ドル以上儲けているらしい。私の給料の優に5倍の額である。その間、私の班員は、暇そうにそこらへんに座り、装備をいじったり、パソコン画面を眺めたりして、退屈な時間を過ごしていた。

どうやら、どこの班でも事情は同じらしい。私は8ヶ月の勤務中に、35冊の本を読み終えた。そのうちの一冊は、Fiasco: イラクにおけるアメリカ軍兵士のアドベンチャーであった。

例えば、イランの国境に近いアマラーの基地にいる、ある兵士は、ペルシャ語を流暢に話す。もし、彼が通信兵に配属されたならば、非常に便利であろう。では、彼は代わりに何をしているのか? 彼は同僚がWoWで遊ぶのを観察するという非常に忙しい任務に付いている。

私の知る限り、軍隊内の言語専門家は、皆同じ問題を抱えている。

こんな状況ならば、そもそも軍は言語専門家など派遣するべきではないのだ。戦地に派遣されなかった言語専門家は、NSAとかのインテリジェンス部門で働いている。海外に派遣された者とは違い、彼らは実際に言語技能を活用して、派遣された兵士の力になっている。毎日の仕事によって、彼らの言語技能は維持されている。ある防衛会社などは、言語専門家を遠隔通信で前線にいる兵士とつなぎ、必要な翻訳を担当させるようなことまでしている。

一方、現地に派遣された言語専門家は、全く関係ない退屈な仕事をしている。他の兵士と何ら変りない。専門の言語技能は必要とされず、技能を維持することすら難しい。多くの者は、技能確認のテストに落第してしまう。

少なくとも、軍は我々言語専門家を、どこにでも使える万能要員のように扱うのを辞めるべきだ。我々の技能は専門的である。朝鮮語話者は朝鮮にいるべきであって、アルクートにいても仕方がない。スペイン語やフランス語専門の者は、ラテンアメリカとかNATO軍とかに配属されるべきなのだ。

まあでも、軍は私の代わりに、民間任用者を多数雇用して仕事をさせている。むしろこっちの方が優れているのだろう。ネイティブの技能には、太刀打ちできるわけがない。金はかかるが、品質も悪くない。

2011-08-23

今日学んだ英単語:defenestrate

defenestrate [diˌfɛnəˈstreɪt]
動詞
窓から(人、物を)投げ捨てる

そんな動詞があるのか。

Defenestration - Wikipedia, the free encyclopediaによると、それなりに歴史のある言葉らしい。

2011-05-18

Sorting it all Out: 英語を強制させないことだってできるさ。あるいはアホになるか。どっちでもいいけど

You can choose to *not* impose a "Non-English Tax" on your feature. Or you can be a jerk. Whichever.... - Sorting it all Out - Site Home - MSDN Blogs

このブログ記事に書かれている内容は、アイロニーだらけである。

つまりだ。俺は英語を書いてるわけだ。

他の言語も覚えようとしてるんだけどさ、英語こそが、俺の一番得意な言語なわけだしさ。

もし英語の知識とやらが、正しい文法とかスペリングだと言うのなら、そもそも俺だって、英語ができないということになるかもしれん。

まあ、それはさておく。エラーメッセージをローカライズすべきかどうかというスレタイのスレで、こんなレスつけたやつがいた。

エラーメッセージはローカライズされるべきじゃないし、分かりやすくあるべきでもない。

エラーメッセージというのは、共通の言語を使うべきだ。たいていは英語だ。一般的に言えば、開発チームの使ってる言語だ。そうすれば、そのAPIを使う開発者は、インターネットでテキストを調べることができる。フランス人の開発者が、フランス語のエラーメッセージを得たところで意味がない。

エラーメッセージというのは、開発者は理解できるが、実行環境の詳細は漏らさない形で書かれるべきだ。単なるユーザーに対して、エラーメッセージを表示すべきではない。つくっているものがAPIフレームワークで、ユーザーというのが開発者である場合はともかく。

このコメントには、マイクロソフトのレドモンドの悪習がふたつある。とくに、最近のマネージドコードにあるわけの分からんエラーメッセージに共通する悪習だ。

  1. 読みやすく、理解しやすいエラーメッセージは邪悪であるという掟
  2. 「ネットで探せ」というのが、エラーメッセージに英語を使う理由であるという掟

このアホくさいクソな悪習に賛同する奴は、根本的な問題を分かってない。たとえ英語ネイティブであろうと、英語で書かれているものがすべて理解できるわけではないし、そもそも、まともな開発スタイルでもない。ユーザーの手を縛り上げるようなiPhoneアプリケーションは、iPhoneの利用の妨げになるのと同じだ。

開発者の心得:インターネットでエラーメッセージを探すのは、「エラーメッセージが理解出来ないから」である。どんな言語を使っても同じだ。

世界には大勢の開発者がいる。英語が分からない者も大勢いる。英語を学ぶ者も大勢いる。どの程度、英語ができるようになるかは、人それぞれである。本文で使われているようなとんでもない方言だってあるのだ。大抵は、英語を学ぶのにとても苦労しているので、代わりに別の言語を学ぶ。例えばC#とか。そういう人間には、英語より、フランス語とか日本語の資料でC#を学んだほうが、仕事を見つけるのが楽なのだ。

英語を学んだ者は、英語で情報を得ることができるが、だからといって、英語を理解しないものより優れているとは限らない。だから、そういう堅苦しい問題よりも、より多くの開発者を集めることに労力を割くのだ。

英語を話し、英語限定のソフトウェアを作っている開発者よ。英語に流暢な人間であっても、お前の書いたものが理解出来ない奴は必ずいる。物事を他人に伝えるという能力が如何に劣っているかを自覚しろ。そういう態度を改めることこそが、分かりやすいソフトウェアを作ることにつながるのだ。

英語を話すということは素晴らしいことだ。ある国では、英語が分かるということは、仕事を見つけるために必須である。しかし、ある言語習得が必須である理由というのは、他の国の開発者だって同じだ。

結局、物事をより広く、便利に提供するということは、何の害もないのだ。

しかしまた同時に、英語が分からない人間に物事を理解させるというのは、恥ずべきことではない。ぶっちゃけ言うと、奴らに英語を強制させるほうが恥ずべきことじゃないのか?

そんなわけで、.Netフレームワークを使う開発者で、世の中のプログラミング作業を簡単にしたいのならば、自分の制作物の使用に際して、英語を強制させないという選択肢を取れるわけだ。

あるいは、アホになるかだ。

どっちでもいいけど。

本文で最大のアイロニーは、当然、本文がすべて英語で書かれているということである。私の能力上の都合で、私は読者に英語を強制しているわけだ。でも、お前らは俺よりうまくやることだってできるさ。

この英語は翻訳しづらかった。理由は、一文が長いためだ。

2011-04-28

Translation is impossible

This is one of planning posts explaining about the situation of Japan and programming. This time, I would like to write about non technical matters. How bad the translation is.

Last time, I explained Why Japanese don't know English. Short answer is: We don't need to because there are enough translations.

So It's all about translation. Is it good? Short answer, No. Long answer, NOOOOOOOOOOOOOOOOO.

I say, translation is enough to be a good programmer. You can't be the best programmer by translation.

The translation, in general, is horrible.

The author of Boost.locale said by using English, It's easy to translate to other languages.

You even do not have to be a professional tanslator with a degree in Lingustics to translate messages from English to your own language.

This is the last thing localization library designer can say.

Translation is a bad idea. Translation is a workaround. It's works as lossy encoding like using 32kbps mp3. It just barely sufficient to grasp the meaning of original text. All non-essential nuances are removed.

Especially, translation between English and Japanese are nightmare.

That's not all. You can't avoid mistranslation.

I'll show you one example. One example that is enough to makes you understand that translation never works. The most infamous mistranslation in the history of computer science. Brace yourself.

There is a book called "The Programming Language C++ 3rd" by Bjarne Stroustrup. Of course, There is a Japanese translated version for this. At 4.4.1 Integer Literals [dcl.int.lit] of this book, there is a sentence:

on a machine on which an int is represented as a two’s complement 16-bit integer

This was translated in Japanese as follows.

2つの補い合う16ビット整数でintを表現するマシンでは

(Literally translated back to English by me.)

on a machine on which two 16-bit integers that are complementing each others represents an int

I'm not joking. I don't make up this. I tried to translate as literal as possible. It's real. It literally says "two 16-bit integers". This set of integers are somehow complementing each others. And it somehow represents an int. Yes this two integers represents an int. not "be represented".

This legendary horribly translated version of his book is still sold even today. You can find it in Japanese local bookstore.

Of course, there are books written by native Japanese. But for some reason, it only covers the basics. So we have to read translation.

This problem can be solved if we all learn English. But that's impossible. I think the reason of that is a good topic for next post.

South Parkのシーズン15が開始

HUMANCENTiPAD (Season 15, Episode 1) - Full Episode Player - South Park Studios

誰も許諾文なんて読まないというネタ。

Japanese programmers don't know English

"Japanese programmers don't know English."

This is a fact. Sure, there are few exceptions. But I can safely say almost all Japanese programmers don't know English.

Why is it? Why we don't know English? How could that even be possible? How can we learn programming without knowing any English.

Why? Because we don't need to. How? Because there are enough Japanese translations.

In the world of programming, English is the first class citizen. Any other languages are secondary. I don't argue with that. It's a fact.

But we have translations. Almost all English programming books are translated to Japanese. It's not just books. Standards, documents and every interesting text in the internet are translated to Japanese. If you google for it. There is a high chance it has been already translated by man(not machine).

Because of this, we don't need to learn English just to learn programming. Of course, if one want to be the best programmer, he or she still have to learn English. But you don't need to be the best programmer. Actually, you can't be the best programmer. It's a simple fact that you can't master all. There is always better programmer than you for some domains. What we need is good programmers. Because we have enough Japanese translations, we can learn most of the stuff in Japanese.

Now, you may wonder like this. "But programming language is based on English. Writing a code means writing an English. same applies for reading. isn't it?"

That's not what we do. We are dealing with programming language, not English. When we read fopen, we don't think "It's a function which open a file". We think ファイルを開く関数(a function which opens a file). We don't recognize f stands for file and open means, well "open". We think "fopen" as some kind of identifier and whatever that means it opens a file in Japanese. Likewise, when we write variable name such as file, we don't recognize it as "file". We think ファイル(file).

It's just same you guys use Japanese words like samurai, ninja and hentai without understanding its true meaning. Just because you use these words doesn't mean you understand Japanese. You don't even know what it really means. Most samurais were doing boring jobs that is equivalent to current office job. Reading, Writing and computing. Ninja doesn't ware black clothes and they weren't super athletes. They were spys. Their job was same with modern spy. Obtaining informations and propaganda. Hentai does NOT mean porn anime and manga. It's more generic word. It may be translated to naughty or dirty.

Japan is a interesting country. In 1867, Edo bakufu(a feudal government at that time, they banned forign culture Sakoku) gave up and returned its rights to the Tenno(They got rights to govern the Japan in 1603 from Tenno.) After that, we were eager to learn western knowledge. We built many western style buildings made by bricks(most western style buildings were destoryed by earthquake, notably 1923 Great Kantō earthquake. Earthquake is the reason our ancestor never built a house made by brick.)

Well, enough of history. The point is, many western technologies were far superior than ours at that time. We had to learn fast to keep up with them. Or else, we ended up to be invaded and become a colony of western countries. We had to avoid that. The only way to prevent that is learn.

In order to learn western knowledge, it's obvious we need to read western languages. Of course, the smartest people learned it. The most interesting thing is they translated it to Japanese. So all Japanese could read it. Did you know that the Japan's literacy rate was really high even at that time. I think we made so many translation because of the high literacy rate. If literacy rate was low, we didn't need to translate it to our language.

Even today, we translate most of the forign books. I think the biggest reason Japanese can't use English is, just because we don't need to. We have translations. That's enough for becoming a good programmer.

I don't know how long we can keep doing this. We need a common language and English is the best candidate whether we like it or not. Eventually, minor languages will slowly fade away. I think Japanese language survives. Well at least I hope so.

2011-03-05

Scarborough Fair

Scarborough Fairという歌がある。理不尽に不可能なことを要求し、その要求を満たした場合、結婚しようという内容の歌だ。Simon & Garfunkelがカバーしている。

いい歌だ。

ところで、この歌詞、二重否定が強い否定の意味で使われているのではないか。

Tell her to make me a cambric shirt
Parsley, sage, rosemary, and thyme
Without no seams nor needlework

"without no seams nor needlework"となっている。

2011-03-04

値段のつけ方

たとえば、100円で売りたい商品があるとする。多くの店は、100円で売ることはない。98円で売る。同様にして、1000円の商品は、980円で売られる。これは、どの店でもやっていることである。

この、あまり正直ではない値段の付け方は、日本だけではなく、世界中で行われている。ただし、国ごとに事情が異なるので、微妙に値段の付け方も異なっている。

たとえば、アメリカでは、$10の商品に、$9.99の値段を付ける。日本では、999円ということは、あまり行われていない。大抵は、980円である。これは、歴史や文化の違いであろう。

フィンランドになると、€9.95になる。なぜならば、フィンランドのユーロ硬貨の最小単位が、5セントだからだ。

また、アメリカにおける、ガソリンの値段の付け方が面白い。たとえば、「2.99 9/10」などという値段を付ける。この9/10は、10分の9セント、すなわち、0.9セントであり、0.009ドルである。米ドル硬貨の最小単位は、1セントなのに、なぜこのような値段をつけるのか。それは、このガソリンの値段は、1ガロンあたりの値段だからだ。たとえば、2.99 9/10という値段で10ガロンいれるのならば、値段は29ドル99セントになる。

基本的な考え方は同じだが、事情が異なるので、微妙に値段の付け方も異なっているのだ。

2011-02-12

面白い英語

English pronunciation test

異なる発音なのに同じスペリング、または反対に、同じ発音なのに異なるスペリングの単語を組み込んだ英語の詩である。

これはなかなか面白い。この英語を正しく発音できるようになれば、かなり英語ができるようになったと実感できるだろう。まだ無理だ。

2010-10-26

これが実現したらいいのに

三単現の“s”20年めどに廃止 米・教育局

ただしソースは虚構新聞。ああ、ソースが虚構新聞でなければいいのに。

ほかにも、articleとpluralを廃止して欲しい。

他の言語版:男性複数与格を2018年めどに廃止─ロシアでも言語ゆとり政策 : bogusnews

2010-09-07

weirdは由緒正しき言葉

weirdという英単語がある。私は、今まで特に理由もなく、直感だけで、weirdは、比較的最近の言葉だろうと考えていた。スラングではないかとさえ思っていた。だいたい、響きからしてweirdではないか。ところが、これが違うのだ。

weirdという言葉は、西暦900年以前にまでさかのぼれる、由緒正しき言葉である。元はといえば、バイキングが、「運命」という意味で使っていたらしい。

Runecasting - Runic Divination
Wyrd - Wikipedia, the free encyclopedia

現在、weirdという言葉は、「奇妙な」などという意味で使われる。これは、1815年に用例が確認されている。意味が定着したのは、20世紀に入ってからであるとされている。

とすれば、比較的最近の言葉、もしかしたらスラングではないかという、私の言語的な直感は、それほど間違ってはいなかったということになる。

ちなみに、何故そのような直感があったかというと、weirdが使われている文脈は、いずれも口語的な英語であり、堅い英語では、用例をみなかったからだ。Weird Al Yankovicの存在も大きいだろう。

2010-08-07

いまだに慣れない英語

"Not a native speaker of English?"(英語ネイティブか?)と聞かれて、「違うに決まってるだろ!」と言いたかったのに、自信満々に、"Of course I am!"(あたりまえだろ、俺はネイティブだよ!)と答えてしまった。英語の否定疑問文には、一生慣れる気がしない。少なくとも、ネイティブではないことを実証することに成功したわけだが。

pronounceとpronunciationのスペルをしょっちゅう間違える。どう間違えるかというと、pronunceとpronounciationだ。このスペルの違いは、実際の発音の違いを表しているのだが、文字を打つときは、必ず間違えてしまう。おそらく、私の頭に、この二つの単語の発音の違いが叩き込まれていないのが、原因だと思われる。

2010-06-29

2010-05-09

easy peasy

英語は使わないと忘れる。いつものように英語を聞いていたところ、easy peasyなる言葉が耳に入ってきた。意味は自明だが、なかなか面白い言葉だ。

思うに、英語には、この手の言葉遊びが、非常に少ないと思う。似たような言葉に、Holly Mollyとか、Okey Dokeyがある。他にもあるだろうか。

ちなみに、このeasy peasyという言葉の歴史が気になったので、調べてみた。何でも、1970年代に、イギリスのテレビで、Lemon Squeezy detergent(レモン絞り洗剤)なる商品を広告するのに、この言葉を使っていたらしい。広告の最後に、"Easy Peasy Lemon Squeezy"と締めるのが常だったらしい。

まあ、最近は、この手の言葉を、あまり聞かない。このeasy peasyにしたって、私のきいたコンテキストでは、コミカルなキャラを目立たせようと、わざとこういうセリフを言わせていた。

2010-04-19

なぜ、how muchというのか

freenodeの##japaneseチャンネルで、「ここには、あまり多くの日本人がいない」という意味で、"Not much japanese here"と言ったところ、manyを使うべきだと言われた。

manyというのは、数えられる物に対して使う言葉であり、muchというのは、数えられない物に対して使う言葉である。"not much japanese"というと、ここでは、あまり日本語が使われていないというニュアンスになるらしい。それは、理解できる。

ではなぜ、「値段はいくらか?」という意味で、"how much?"、というのか。金額というのは、数えられるのではないのか。なぜ、金額に対して、"how many?"と言わないのか。

これはどうも、moneyというのは、金という一般的な総称であって、通貨を表すのではないらしい。たとえば、"three monies"とはいわない。

では、「5グラムの金に相当する」とか、「1キログラムの米に相当する」などという言い方も、moneyなのかというと、これまた違うらしい。それは、moneyの量を表すのであって、moneyそのものではないという。moneyは、あくまで、金そのものを意味するらしい。

しかし、一般的に、"how many USD is it?"(何米ドルだ?)よりも、"how much is it in USD?"(米ドルでいくらになる?)というフレーズの方が、よく使われている。

日本語で、このような区別のある言葉はないものかと考えたところ、「大勢」という言葉が浮かんだ。これは、人とか動物とか、兵力などに使うことができるが、単純に、金額とか物質量などに大しては、使わない言葉だ。

2010-04-02

サウスパーク:医療用フライドチキン

Medicinal Fried Chicken

最近、サウスパークは、英語圏の文化に強く依存したエピソードばかり放送している。今回も、解説が必要だと感じたので、解説しておく。

医療用のマリファナについて

まず、アメリカの一部の州では、末期がん患者やエイズ患者などの病人のために、医療用のマリファナを処方しているところがある。マリファナの効用としては、鎮痛作用や、嘔吐抑制などがある。マリファナには、依存性や副作用があるが、それは、どんな薬でもあるのであって、利点が優っているのであれば、薬としても使えるのである。例えば、睡眠導入剤や、咳止め薬の類も、依存性がある。

Jamie Oliverについて

彼は、学校における、KFCやマクドナルドなどの、加工品を給食として出すことに反対している。作中で、カーネル・サンダースが、彼を嫌っていて、暗殺指令までだすのは、そのためである。

半裸の女性が、ケンタッキのフライドチキンを用意しているのは、有名な犯罪映画、New Jack Cityや、American Gangsterへのリファレンスと、違法な麻薬としてのマリファナというものは、あのように仕分ける作業があるということを、念頭に置いている。

また、作中では、カートマンが、キリスト教によって行われた、複数の小児性愛に関する事件を参照して、"Do I wanna do it? Does the pope help pedophiles get away with their crimes?"、と発言している。