Windowsの各国語キーボードの使い難さ

毎月一度以上の投稿を目指していたのに、先月は投稿し忘れた。投稿するネタが何もないわけではないが、最近はMSKLCというマイクロソフトが無料で提供しているツールでキーボードの開発に夢中で、つい忘れていた。

MSKLCとは

MicroSoft Keyboard Layout Creator の頭文字を取って名付けたソフトで、マイクロソフトのホームページから無料でダウンロード出来る。

MSKLC でググれば、一番上にマイクロソフトのMSKLC ver.1.4 のダウンロードページが出てきた。(投稿日)

キーボードと言えば、キーを押した時に キートップに刻印されている字が入力されるのが当たり前だと思っている人もいるかもしれないが、ユニコードの文字の範囲で自分の好きなように定義した マイキーボードを作る事も出来る。その為のツールがMSKLCなのだ。

マイクロソフトがWindows10で提供している各国語のキーボードもやはりそのMSKLCによって作られているはずである。

Windowsキー+Space によってMSKLCを使って作ったマイキーボードに切り替えた後の最初の1文字目の入力がデッドキーに割り当てた文字だった場合に、その文字が入力出来なかったが、その同じ問題点が Windows10の各国語キーボードでも存在する事を発見した時、そう確信した。

その社内ツールを全世界のWindowsユーザーの為にマイクロソフトが好意で提供してくれているのである。

そのMSKLCでキー定義した結果は、そのツールのメニューの中から “Build DDL and Setup Package” を選ぶとWindowsにインストール出来るパッケージが出来る。そのパッケージの中の setup.exe というファイルをダブルクリックしてPCにインストール後、PCを再起動させれば自分でキーを定義したキーボードが使えるようになる。

また定義自体は拡張子を .klc とするテキストファイルにも保存できる。

赤の他人にも使って貰う

自分の作ったキー定義を赤の他人にも使って貰うには、この .klc の拡張子のテキストファイルを公開することで実現できる。

知らない人が公開しているパッケージだと、どんなウイルスが含まれているかも知れないから簡単には試して貰えない。しかし、.klc のテキストファイルなら安心して試して貰えるはずである。その .klc ファイルをMSKLCに読み込ませれば、使う人のPCでパッケージをビルドできるのだ。

何故キーボードを自分で定義するのか

私は元エンジニアなので、キーボードはASCII文字(ユニコードの 0020 から 007F まで)が全て打てる “USキーボード” が基本だと思っている。しかし、各国語のキーボードではアクセント記号の付いたアルファベットを入力する必要性で入力出来ないASCII文字があったり、或いは “USキーボード” のキー配列とは違う位置にキーが定義されている。

だから、色んな言語を扱う度に違う言語のキーボードに切り替えて使うとなると、各国語のキー定義をそれぞれ覚える必要がある。

Windowsで定義している “US International” というキーボードなら欧米の主要言語をキーボード切り替えなしで入力可能なのだが、肝心のASCIIの部分で、( '  `  " ~ ^ ) の5つの記号がデッドキーになっていて、これも使い難い。

一方、Mac には ABC-Extended という、ASCIIの部分は全く変更無しに多言語が打てる上に記号の入力も可能なキーボードが存在して評価が高い。なぜ、ASCII部分には全く変更がないのかと言うと、その他の文字や記号は Optionキー というものを押しながら入力するようになっているからだ。

同様の仕組みはWindowsにもあって、AltGr というキーを押しながら入力するというやり方だ。PCの元祖 IBM によれば、AltGr とは、Alternate Graphic の略号とのこと。キーボード上には AltGr と刻印されたキーは存在しないが、右側Altキー がそれである。左側Altキー も Ctrlキー を同時に押すことで AltGr の役目をする。

そこで、Macの ABC-Extended と同じ考えで、ASCIIの部分は全く変更無しに多言語が打てるキーボードだが、キーの定義はMacとは異なるものを作ることにした。

入力すべき文字・記号の範囲を考えた時、HTML4.0の文字実体参照で定義されている文字・記号というのが客観的に必要性の高いものだと考え、その全てを入力可能なようにしたかったが ABC-Extended では実現されてないからだ。それに、文字をどのキーに割り当てるのかについても成程と思えるものが少なかった。私はそれよりはもっと上手く割り当てる。

各国語キーボードの使い難さ

各国語のキーボードのキー配列が異なるとしても、その言語に最適化する為に必要とあれば納得出来る話なのだが、実はそうでもない。

例えば、ドイツ語の引用符は „ABC“ のように書くのだが、ドイツ語キーボードではこの引用符は打てないし、フランス語キーボードも フランス語の引用符 «ABC» だけでなくフランス語に必要な合字 æ やœ さえ打てない。じゃあ、一体どうして入力しているのか検索で調べて見ると、キーボード自体の機能には頼らず 独語版や仏語版の MS Word の機能を使えば良いらしいとの話があった。

ドイツ語キーボードでもフランス語キーボードでも AltGr で定義していないキーは沢山あって、それらの言語に必要な文字・記号を定義することは幾らでも出来たはず。つまり、マイクロソフトは本気で各国語キーボードを作っているとは思えないのだ。

もしかしてマイクロソフトの戦略として各国語キーボードの機能はわざと低くしておいて Word の売上を増やそうとしているのかも知れない。

MSKLCの機能を最大限に活用する

MSKLCでは、一つのキーに対して

1. そのまま
2. Shift を押しながら
3. AltGr を押しながら
4. Shift + AltGr を押しながら
5. Cntl を押しながら
6. Shift + Cntl を押しながら
7. CapsLock 状態で そのまま
8. CapsLock 状態で Shift を押しながら

の 8通りの定義が可能になっているが、マイクロソフトは 5. と 6. についてはアプリで Cntlキーを押しながら使うショートカットキーと被る恐れから非推奨としている。

残った 6通りの定義の内、1. – 4. については一つのキーに4文字までの文字列を定義出来る。7. と 8. については 1文字しか定義出来ない。

更に、デッドキーという仕組みもある。そのデッドキーの次に押すキーとその時に出る文字(1文字のみ)のセットを定義することで、一つのデッドキーに沢山の文字が定義出来るようになっている。但し、(Altキーの)デッドキーの次に押すキーとして定義できるのはアルファベットとスペースキーに限られ、数字や記号のキーは定義できない。また、Shiftの有無は区別される。つまり、一つのデッドキーには最大で54通りの定義が出来る。

Altキーでないキーをデッドキーとする場合には数字や記号のキーを定義することも出来る。しかし、ASCIIの部分には手を付けない方針だから、使えるとすれば Shift + Space キーの場合しかない。しかし、この場合にはGoogle日本語入力のキーボードとして使う場合に上手く動作しない。そこで、デッドキーの次のキーとして数字や記号のキーは定義しないことにした。

MSKLCの画面では CapsLock 状態を使う 7. と 8. でもデッドキーが定義出来るのだが、動作しない。

ところで、CapsLock 状態を利用する 7. と 8. は、この 7. と 8. で定義してある文字を続けて使うような場合でないと使いずらい。

そこで、CapsLock 状態にした時の動作として ⓐ 上付き、下付きの数字モード、ⓑ 発音記号モード、ⓒ ロシア語モード という 3つの活用方法を考えた。

カスタマイズできる

各国語キーボードでは、ASCII文字以外の各国語に必要な文字をなるべく 1. そのまま と 2.  Shift を押しながら に割り当てている。そこに収まらなくても、せいぜい 3. の AltGr を押しながら までの割当で、4. の Shift + AltGr を押しながら という使い方は殆ど利用されていない。

これは2つのキー( Shift と AltGr )を押しながら更に別のキーを押さなければならないのが大変だからだろう。

そして、デッドキーに定義した文字についても キーを2回押す必要があるから使用頻度の低い文字・記号にしか使われていない。

しかし、1. そのまま や 2. Shift を押しながら については us キーボードの定義を変えない方針だし、CapsLock状態を利用出来る文字は限られている。

だから、文字実体参照全体という沢山の文字を定義するにはどうしても AltGr とデッドキーは使う必要がある。しかし、そうすると各国語のキーボードに比べて使い勝手がよろしくない。と、悩んでいた時に Spaceキー を使う方法が閃いた。

usキーボードの中に一つだけ冗長なキーがある。Shift + Space である。Shift を押しても Space が出力されるだけ。勿論、Space の前後が Shiftキーを押す必要のある文字だった時は Shiftキーを押したままで入力出来るという利点もあるが、この限られた利点はあきらめ、これをデッドキーに転用すれば、AltGrキーを押さずとも新たに56種類の文字が入力出来るのだ。

しかし、新たに定義出来るキーが増えたのは良いが、どういうキーをこの新たな領域に配置するのがよいのか、その基準が明確でないと使う側も大変だ。

色々考えた挙げ句、この Shift + Space デッドキーに定義する文字は使う人の自由にしようと考えた。必要な文字は全て他所で定義しておく。どんな文字が手近に必要なのかは使う人によって異なる。だから、この領域には使う人が自分で良く使うお気に入りの文字を集めるのだ。

Shift+Spaceを活用する3種類のキーボード例

自由にとは言っても、私なりに目的別に3種類の例を考えてみた。まずは、一般的なものとして、スペイン語、イタリア語、ドイツ語、フランス語、などが書きやすいようにしたもの。アクセント記号のついた大文字の出現頻度は少ないので小文字だけを集めている。

次の例は中国語の発音記号であるピンインが書きやすいようにしてみたもの。最初の例となるべく同じにして、必要な文字だけ入れ替えてある。

3つ目の例は、シフトしない場合は最初の例と同じだが、シフト側はスペイン語とドイツ語が書きやすいようにアクセント記号のついた大文字を配置してある。

詳しい話はこのプロジェクトが完成したら、また投稿する。

｢かなプラス｣に名前を変える

こぶりローマ字変換という名前を付けて、このブログで成果を公開していた｢Google日本語入力のローマ字テーブルのカスタマイズファイル｣を大幅に変えて、今度は GitHubで公開することにした。

｢かなプラス｣に名前を変える

今度の名前は、名前自体でどういうものかを表している。つまり、ローマ字かな変換の機能以外にも機能があるよ、との表明である。

更に、MSKLC というマイクロソフト社が無償で提供しているソフトで作り、｢ASCIIpls｣という名前を付けたカスタマイズ言語キーボードと連携しているよ、という表明でもある。

こぶりローマ字変換では、欧文符号やアクセント記号付きのアルファベットなども出せるように機能を拡大して複雑になり過ぎていた。そこで、欧文関連はカスタマイズ言語キーボードで実現させるようにして、その言語キーボードをGoogle日本語入力で使う言語キーボードに指定することで連携させる事を考えた。

即ち、IME On の状態ではGoogle日本語入力が機能して、IME Off の状態では言語キーボードの切り替えが不要でカスタマイズ言語キーボードが使えるのである。

その為には、ASCIIpls は通常の USキーボードの機能を損なうことなく欧文符号やアクセント付きのアルファベットが出せるようにする。

GitHub アカウントを cobli に変える

GitHub は、情報を公開する場合には無料で利用できる。アカウント名は早い者勝ち方式で決められる。

最近になって、GitHubが公共性のある成果物を公開する手段としては最も良い方法だと思うようになって cobli のアカウントを取ろうとしたが既に登録されていて別のアカウントしか取れなかったので若干やる気が削がれた。

アカウント名は単にログインに使うだけでなく、情報も github.com/アカウント名 で公開されるので、対外的にも非常に重要なのだ。google や apple などの企業もその名前のアカウントを取って情報を公開している。

しかし、調べてみると先に cobli のアカウントを登録していた人は2010年に単に登録しただけで何の利用もしていない。そのようなアカウントはGitHubのサポートに連絡して開放してもらえるという情報をネットで知ったので、コンタクト先にお願いしてみた。

すると、金曜日の夜に連絡したのだが、翌朝返事のメールが届いていて、こちらの要求通りに開放したとの返事をもらった。それで早速アカウントを cobli に変更した。これでやる気が戻った。

まだまだこれから

これで情報を発信する基盤は整ったが、GitHub の使い方を始め、手元の情報と頭の中の情報を整理して体系的にドキュメント化するのは まだまだこれからである。

取り敢えず、https://github.com/cobli/KANApls にアクセスしてもらえば進捗は分かるはずだ。

韓国語キーボードを使う

放送大学の放送授業「韓国語Ⅱ」を今期は受ける事にしたので、この半年は韓国語の勉強と(ウクレレの練習)にいそしむ。

それで、韓国語の入力もちゃんとやろうと、韓国語キーボードを導入してみた。Windows10 なら、言語設定で韓国語を追加するだけ。2ボル式という方法で、キートップにハングルの刻印が無い事を除けば USキーボードでも普通に使える。

変換キーについて

韓国語キーボードでは、ハングルと英語アルファベットの切り換えに 右Altキー、入力したハングルを漢字に変換するのに 右Ctrlキー を使う。我がPCの 右Altキー は日本語入力の切り換えの為に F13キー に変更されているのだが、その代りに 左Altキー を 右Altキー に割り当てている。

それは、MSKLCというソフトを使って多言語対応のキーボードを自作して使うためにそうしていた。右Altキー は特殊記号を入力するために役立つのだ。

そして、左Altキー は PrtScキー に割り当てた。パソコン操作の説明をするために画面をキャプチャーする必要がある時には PrtScキー も役に立つのだが、文字入力よりは使用頻度はずっと低い。PrtScキー が無くてもWindowsアクセサリの中にある Snipping Tool というものを使えば問題ない事を知ってそのように割り当てた。

キーの配置

韓国語の入力練習の出来るサイトにお邪魔して毎日ちょっとやっている。アルファベットのキーとは全く無関係にハングルを割り当てているから覚えないといけないのだが、ある程度規則的に配置しているので少しは楽だ。

まず、子音は左側、母音は右側のキーに割り当ててある。

そして、QWERTYの行に在るキーを上段、その下の行を中段、スペースバーの上の行を下段として説明すると、シフトを使うのは上段のみ。

• 子音では qwert には「ㅂㅈㄷㄱㅅ」が割り当ててあるが、シフトするとそれぞれの濃音「ㅃㅉㄸㄲㅆ」が入力出来る。
• 母音では op には「ㅐㅔ」 が割り当ててあるが、シフトするとそれぞれに/j/の音が加わった「ㅒㅖ」が入力出来る。

激音は下段 zxcv に 「ㅋㅌㅊㅍ」が配置してあるが、平音とは左右が逆になっている(何故?)と覚える。(q ⇔ v、w ⇔ c、e ⇔ x、r ⇔ z が対応。)

その他の子音の配置については残念ながら規則的なものは見い出せなかったが、いくつかの文字は「ㅅ」はパッチムの音が t であるとか、「ㅇ」は子音が消えてる(disappear)とか、「ㄷ」は E に形が似てるとか、こじつけて覚えてる。

母音は全ての基本母音字と opOP に割り当ててある4文字以外は2つの母音で合成する必要がある。母音の配置はかなり規則的なので子音よりは覚えやすい。

まず、母音を横系「ㅛㅗㅜㅠㅡ」と縦系「ㅑㅏㅓㅕㅣㅖㅔㅐㅒ」として見ると、横系は子音と縦系の間の一列 yhn 及び n の両隣(下段)に配置され、縦系は上段と中段の縦系より右側に配置されている。

タッチタイピングだと、右手の指は全て母音のキーになる。左手の指は大半が子音のキーだが、B は 母音である ᅲ が割当てられている点に注意。

  「ㅓㅏ」は jk 、「 ㅗㅜ」は hn に配置されているのは方向感覚として納得出来るし、/j/の音が加わると元の音の上側若しくは左側に配置されているのも分かり易い。

入力は、子音 ⇒ 母音(横系) ⇒ 母音(縦系) ⇒ パッチム(左下) ⇒ パッチム(右下) の順番で行う。

1. 入力したいのが母音のハングル文字「아」であっても、最初に子音として「ㅇ」を入力する必要がある。
2. キー割り当てがある母音の場合は、横系か縦系どちらか一方を入力する。
3. パッチムが2文字の場合でも同じ文字(「ㅆ」と「ㄲ」の場合)は濃音の1文字として入力する。

漢字に変換

ハングルを入力した後で 右Ctrlキー を押すと変換候補の漢字が表示される。複数ハングルからなる熟語を入力して漢字変換しても、表示されるのは最後のハングルに対応する漢字だけである。つまり韓国語IMEは単漢字変換しか出来ないのだ。

韓国語ではもはや漢字は(名前以外は)殆ど使われないからそれで十分なのだろう。それでもそのハングルに対応する漢字が分かるだけでも韓国語学習には役立つ。

スマホアプリには Google Korean Input というものがあって、それなら熟語でも漢字変換出来るのかもしれないが、生憎とPC用のソフトは無い。

NHK BSプレミアム 刑事モース

最近見始めたのが、NHK BSプレミアムで放映中の「刑事モース」というドラマ。不器用なモースが推理力と博識を活かして難事件を解決していく話だ。

主人公はオックスフォード大学中退だが、奨学生だった経歴の持ち主。それだけで優秀な頭脳の持ち主である証明と共に不器用であり、貧しい平民階級出身という事が分かる。英国社会に階層が厳然として存在する事を意識させられる。

欧米エリートの考えている教養

このドラマを見ていると、この世界を動かしている欧米エリートの考えている事が見えてくる。

今回の事件ではオペラが謎解きの鍵だったし、前回は被害者の残した数字が元素番号で、その元素名が犯人の名前を示していたという落ちで、彼らの考えている教養の片鱗を見ている気がする。

単に博識では駄目で、その知識を活かしてこそ本物の教養なのだ。

そう言えば、Dlife で放映中の「スーツ」というドラマでもオペラ好きのルイスというキャラが登場する。こちらはハーバード大出身者で固めた弁護士事務所が舞台で、下町育ちのハービィーが格好いい役でルイスが何時もコケにされているのは、オペラの知識が仕事の役に立ってないからかも…とも思える。

そして、英国の弁護士事務所との合併話があって英国の事務所から派遣された弁護士とそのルイスの仲が悪かったのにオペラと猫が好きと分かってから急に仲良くなったのが面白かった。これも、米国人が英国人をどう見ているのかを暗示しているのかも、と思った。

モース・モーティス・女性

所で、このドラマの話を持ち出したのにはもう一つ理由がある。「刑事モース」というタイトルで「モース・モーティス・女性」の事を思い出したからだ。

それは、私がラテン語の勉強を始めるきっかけとなった「ラテン語のはなし」という本の中で書かれていた。その本を見返して原作者がコリン・デクスターだと確認したから、やっぱりその「モース」だ。

主人公の名前 Morse に引っ掛けて「死」を意味するラテン語の名詞 mors で検死官が呼びかけた、とあって、モースの後に「モーティス・女性」という呼びかけが何故続くのかを説明するきっかけになっている。

私は第3変化名詞の事をこれで知ったのだが、「刑事モース」の読者は当然ラテン語を知っている前提で作者はこの推理小説を書いているのである。

現代の教養

知識があれば物事をより深く理解し楽しめる、という事だが知識を得るには時間がかかる。しかし、現代であれば知識が無くても「検索」という武器が使いこなせればモース並みの推理も可能だろう。

そして、語学についてもまた同じ事が言えるのではないかと思う。人前で流暢に喋る見栄や試験の為という事が無ければ、単語や語彙をひたすら暗記する意味はもう無くなった。情報機器を駆使出来る現代では、言語の仕組みや論理を押さえる方が重要だろう。

学校の語学教育もそうなって欲しいものだと妄想する。

日経の｢遊遊漢字学｣

ぺらぺらの日経新聞日曜版の中にもお気に入りの記事はあった｡その連載は日曜版がぺらぺらになった時から始まった､と記憶する｡

まあ､褒める相手は日経ではなくて書き手の阿辻哲次さんなのだが､毎回楽しくてためになる話が載っている｡昨日は､｢師｣という漢字が古くは兵士2,500人の集団を意味していたという話が載っていた｡それが｢近衛師団｣などの言葉に繋がっていたのだ｡

電子辞書の漢字源

しかし､この連載がなくても我が家の電子辞書に入っている漢字源で調べれば､その漢字の事をかなり詳しく調べることが出来る｡｢師｣の意味の一つに､

{名}いくさ｡集団をなした軍隊｡周代には2,500人を一師といった｡

との説明がある｡ それに､<解字>という解説で字の成り立ちを詳しく説明してくれるし､漢字コードや中国の発音や<名付け>で人名として許される範囲も分かる｡

私はキラキラネームかどうかは漢字源の<名付け>に載っているかどうかで判断している｡

漢字教育と旧字体

そう言えば､私は昔から丸暗記は苦手だが､理屈で納得した時は良く覚えている｡漢字源の<解字>だと複雑な漢字も単純な漢字の組み合わせに過ぎないと納得出来て直ぐに覚えられそうだと感じる｡

学校教育でも漢字の成り立ちを詳しく教えてくれれば楽しく漢字を覚えられたはずである｡しかし､その為には成り立ちを無視して字体を勝手に変えてしまった字ではなく､本当の漢字で教育するべきだ｡

学校で教えている新字体とは､漢字を撲滅させる意図をもった役人が戦後推し進めた政策の下に作られた字で学術的な考慮も何もない嘘字である｡

中国でも､手書きの負担を減らす為に簡体字という字が出来たが､日本の嘘字にはそういう観点も欠けているらしい｡

例えば､｢歩｣という字は正しくは｢步｣であると中国語を勉強していて知った｡きっと､｢止｣と｢少｣という部品の組み合わせの方がバカな国民には覚え易いだろうというバカな考えからだろう｡わざわざ画数を増やした嘘字を国民に教えているのである｡しかし､｢捗｣という漢字の事までは役人の頭が回らなかったらしい｡

一見複雑でも､その成り立ちの意味を考えるなら崩す訳には行かない｡しかし､手書きの機会が殆ど無くなった現在､嘘字を教えるのではなく､正しい漢字を復活させるべきではないかと思う｡日本語変換の手間は嘘字でも正しい漢字でも全く変わらないのだから｡

旧字体と呼ばれてはいるが､香港と台湾では今でも正しい漢字(繁体字)を教えている｡漢字国がバラバラに独自の字を使うよりも､正しい漢字に統一する方が利便性もあるだろう｡

吾唯足知の意味

図書館から先日借りてきた ｢財政破綻に備える 今なすべきこと｣ というタイトルの本を読んだ｡

この本の著者は古川元久という衆議院議員で､民主党政権時代には大臣を勤めたこともある人だが､今回の衆議院選挙では希望の党から出馬するそうである｡

消費税増税させないと言っている希望の党に加わるのは財政破綻を促進させる行為であるが､議席の方が大事なのだろう｡

足るを知る

その著書の中で､｢自立した地域社会｣ と ｢足るを知る｣ という提言をしていた｡つまり､著者は財政破綻を不可避だとして､そうなった場合の事を書いているのだ｡と言うことは､希望の党に入るのは著書と矛盾している訳では無い?

戦後の混乱期､お金の価値が暴落していく中でも農村地帯では食うに困らなかった例を挙げたり､経済成長を目的とするのが正しいのかとウルグアイの元大統領 ホセ･ムヒカ氏の言葉を引用したりして､財政破綻した時のショックを和らげる策を説明していたが､私はそれとは別の話に興味を持った｡それは､京都の龍安寺の裏庭にある蹲居(つくばい)に印された文字のことだ｡

蹲居とは､茶室に入る前に手や口を清める手水鉢のことだが､この蹲居は一説によると､徳川光圀の寄進だとされる｡円柱形の石で出来ていて上面には水を貯める正方形の窪みがあり､その正方形の四方に文字が描かれているが､真ん中の正方形を口偏に見立てているところが洒落ている｡字の向きは揃っているのでどの方向が上になるかは分かる｡(著作権の為､ここには載せないが､ネット上に写真は色々あるので確認出来る｡)

上から時計回りに読むと､｢吾唯足知｣と読める｡それを件の本では(われ ただ たるを しる)と紹介しているが､私は漢文なら｢吾唯知足｣の順ではなかろうか､と思った｡

漢文とは古代の中国語に他ならず､その語順は 動詞→目的語(これは現代中国語と同様)のはずである｡

そもそも､どういう順番に読むべきかも不明で､数学的に言えば24通り(4!)の読み方が存在するけど､漢文として意味があり､かつ順序的にも不規則ではないものとなると限られる｡

• 唯吾知足 (反時計回り) 私だけが足ることを知っている
• 吾唯足知 (時計回り) 私はただ知を足すのみである

それで､知足に拘るなら上の解釈だが､足知という順でも意味が通じるのではないかと思ったのだ｡つまり､勉学に集中する宣言だと｡…検索しても足るを知るのことばかりで､こんな意見は何も無いが｡

しかし､口偏の位置が真ん中なので､この4つの漢字なら字の配置はこれ以外はあり得ない｡すると､この文の意味を字の並べ方から考えるのは正しくないのかも知れない｡

読みの順番で､上→右→左→下という説を後で発見した｡確かに､上から下の流れは自然で､真ん中は2つあるから､右→左の順で読めば良い｡これなら吾唯知足になる｡ 

英語学習とIT技術

今日もコワーキングスペースでブログを書く集まりがあって、今回の投稿を書いている。今日の司会は英語の翻訳家の人なので英語について最近思う事を書く。

Google翻訳

日本政府は英語の教育に熱心だが、最近のAIの進歩の状況を踏まえて路線の変更をしないのだろうか。

というのも、AIの進歩によって、これから日本人が勉強しなければならない事、勉強しなくても良い事が従来とは変わって来るに違いないと思っているからだ。英語教育に関して、私はAI全体の事を知っている訳ではないが、少なくともGoogle翻訳の精度が急激に向上しているという事実からでも、単語を沢山知っていなくても大丈夫だと分かる。

それよりも、Google翻訳の結果に何か問題点がないか感じ取れる能力の方が余程大事である。

そもそも情報として正しいのか

その和訳を見て感じる違和感と言えば、勿論、英語から日本語への変換過程での問題点もあるだろうが、加えてその英文がそもそも情報として正しいのか、という事も当然含まれる。

そういう事を感じ取れる教養や論理が正しいのか判断出来る能力は、当然に日本語での教育でも培える。英語の勉強は程々にして、要所だけを締める、というのがAIと共存するこれからの社会でお薦めできる方法だと思う。

そう言えば、以前に放送大学で「ロアルド・ダールの短編を読む」という面接授業を受けたことがある。そのテキストは英文に日本語の注釈が付いたもので、日本の松柏社という出版社が出しているものを先生が指定していた。

その授業の中で、ある一文について先生が「これは非常に珍しい用法なんです。」と言って得々と説明していた事を、今思い出した。しかし、ちょっと疑問に思って家に帰ってから検索して原文を見つけたら、原文の方は普通の用法だった(カンマの有無だったか…引っ越しの際にテキストを処分したので確認出来ないけど)。

即ち、単に日本の出版社が誤植しただけの事で 珍しくない話なのに、先生は そんな可能性を疑いもせず非常に珍しい用法だと思い込んだらしい。

この件では、たまたま原文の方は正しかったけど、筆者だって間違って書く事もある。与えられた英文は絶対に正しいと思い込むのは危険だと思わないのだろうか。ともあれ、英語を一生懸命勉強するだけではマズイ。

読み書きを重視

IT技術の発達で、日本語でも予約、問い合わせ、手続き、などはブラウザやメールを通じて行えるようになってきて、電話が必要な場面は極端に減ってきた。増してや時差や国際電話料金の事を考えると、海外とのやり取りで電話が必要な事はまず無いだろう。

そういう時代なのだから、英語学習では会話能力よりも読み書き能力を高めた方が余程役に立つと思う。今の会話重視の風潮は、英語教育産業の要請に政府が答えた結果なのだろうか。

英語聴覚障害者と開き直る

聞き取り能力に関しては(個人差もあるが)日本語を母語として育てば、一定年齢以上では日本語に最適化かつ固定化されている。従って、英語では別の音素でも日本語で同じ音素とされる範囲では いくら訓練を積んでも区别することはもはや不可能になる。だから、日本人に英会話が出来なくても当たり前の事で自分を責めるのは良くない。

寧ろ、英語聴覚障害者として開き直ってみれば道も開ける。そうすれば話す方も便宜を図ってくれるはずだし、IT機器も大いに利用すれば良い。英語スピーチを英文に変換するソフトなどスマホでも使える訳だし。

英会話の訓練の目的が、「英語が出来るカッコイイ私を演出」というだけなら無理だけど。

文系とSE

就職活動もいよいよ大詰め。我が家の息子と娘も人気企業ではなくが、内定を貰い、まあここに勤めてもいいか、という状態だ。

娘は食品関連の仕事を探していたが、内定を貰ったのはIT企業のSE職だった。食品関連の企業からは内定が貰えない中、自分のプロフィールを登録しておくと企業の方からオファーが来る仕組みで幾つかオファーが来た。その中から幾つか選んで説明を聞きに行った内の一つが 内定を貰ったIT企業だった。

子供の就活にはなるべく口を出さないようにしてはいるが、意見を聞かれれば思っている事を正直に答える。文系の娘には プログラミングの経験は無いが、プログラムも一つの言葉だし、外国語の得意な娘に出来ない訳が無いと答えておいた。

IT企業のススメ

新卒の就活先如何で一生の勝ち負けが決まる、とは思ってないが、良い企業に入れればとは思う。良い企業が何かは人によって異なると思うが、特に若い間は仕事を通じて目指す人生に必要な能力を得る事が出来る環境である、という事が一番重要だと思っている。

大きな会社だと、その会社の業務を一通り経験させるような研修をさせる所も多い。その会社で一生働くのならその効能も分かるけど、目指す職を得る為に自分に到底合わないような職をやらされるのも嫌だろう。

そういう意味では IT企業は取り敢えずおススメ出来る。何と言っても、現代の知的生産活動でITは欠かせない道具である。最終的にどんな職に就こうともITの知識を身に付けておくと役に立つ。それに、場所や資金が無くても、パソコンとインターネットさえあれば独立して仕事も出来る。

文系とSE

それから、SEに最も必要な能力は、プログラムを書く能力ではなく、コミュニケーション能力と論理思考能力だと言う。プログラムは なるべく書かないのが良いSEなのである。必要なプログラムは既に巷にある。それをうまく組み合わせるだけで大抵の事は出来る。

そう言う意味では、文系はSEに向いている。お客が何をやっていて何を求めているのか、にプログラムを書くよりも関心を持てるのが大事なのだ。

それに、プログラムは人工の言語を使って記述する。言語を扱える人に出来ない筈が無い。勿論、技術的な対象を扱う場合は理系のセンスも必要だが、それ以外は論理思考さえできれば大丈夫だ。

プログラムと言語

私がオブジェクト指向言語の事を理解した時、英語の冠詞と全く同じだと思った。つまり、クラスからオブジェクトを作る(例えば Java だと new というコマンドを使う。)時、あっ、これは英語の冠詞の a と同じだと思い、その作ったオブジェクトを指し示すのが the だと思い、言語の理解にプログラムの知識も役に立つものだと気付いたのだ。

そして、英語が名詞と呼んでいるものの正体はクラスであって、実体を直接示すものでは無いと気付き、それに対して日本語の名詞はそれ自体で実体を表していて、冠詞の説明はそこからやらないと本当に理解した事にはならないはずであると思う。(英語では、代名詞と固有名詞のみが それ自体で実体を示す。)

思えば、コンピュータと同様に 人間の脳の中でも文章中の要素は脳内のメモリに記憶されて処理されているはずで、言語学もIT的な解釈で説明する方が簡単な気がする。

言語学を専攻している娘にもこの感覚を味わって貰いたい、というのもIT企業への就職を後押ししている理由の一つなのだった。

アーリーが書けなくて満足

情報技能のページを大幅に変えてみた。そして、ローマ字変換の定義も。分かり易くなって、一番助かっているのは私自身だと思うけど、これで英語キーボードの普及や、カタカナ語の改善に繋がるとすれば嬉しい。

「ん」は nn の入力で納得

以前、こぶり羅馬字変換の説明で「ん」の為の専用キーに l を割り当てる、としていたが、l は英語発音の[l]をカタカナとして入力する為のキーに変更した。

それは、入力時に かなモードにし忘れて、アルファベットで入力してしまった時に、「ん」の入力に l を使っていると もしかして変換 の御利益を受け損なうからだった。それに、「ん」の入力に n と nn を使い分けるのが思考の妨げになると思っていたけど、慣れれば大丈夫というネット上の情報が在った。

確かに、nn としなければならない場合は母音か拗音の前なのだが、「ん」の発音自体も n で入力出来る場合とは異なっている。だから、発音に忠実な n と nn を使い分ける入力で納得なのだ。

rr の動作

そして、rr と入力した時の動作も、促音「っ」+r となるように変更した。

以前は、arrir と入力して「あーりー」に変換したけど、今のローマ字変換の定義だと「あっりー」になる。英語発音には[r]の連続は在り得ないので、どっちの定義でもいいのだが、ローマ人に「スッラ」という人物がいたから、それは入力出来るようにしたいと思った。

じゃあ、「あーりー」はどうするか、というと長音符の入力は本来の - キーを使えば良いのだった。長音符の入力に r を使う事が当たり前になってすっかり忘れていた。

ローマ字変換でも R と L の違いを意識出来る

処で、「アーリー」って英語の early をカタカナにしたもので、発音は[ˈəːli]だから、「リー」の部分は l なのだった。だから、arlir と入力してみる。すると、「あーるりー」と変換された。

これは、私が[l]の発音の表現方法に拘っているからで、もし li の変換を単に「り」にしておけば、入力時に R と L の違いを感じつつ、かつ長音符の入力に r を使って違和感なく入力出来た。だから、「アーリー」が書けなくて満足なのである。

しかし、正しく[ˈəːli]を私の定義でカタカナにするには、qely と入力する。これは、「あぇるりぃ」と変換される。

こぶりローマ字変換のヘルプページ

以前から、英語の発音をカナで表記する方法について研究してきたが、「エイ」と「エー」、「オウ」と「オー」を書き分けても無駄だと思うようになった。つまり、日本語話者にとっては、この2つの表記のどちらも同じ音として記憶されてしまうのだ。

「エイ」と「エー」、「オウ」と「オー」の違いは記憶されない

私の考えでは、日本語の母音には、「ア」、「イ」、「ウ」、「エ」、「オ」 の5種類以外にも、「エー」 と 「オー」 のような複合母音が日本語の中には存在している。しかし、伝統的には長音符(棒引きの記号)は外来語にしか用いないルールなので、「エー」 と 「オー」 の表記方法は 「エイ」 と 「オウ」 だった。

つまり、表記を変えたとしても同じ音を指し示す。だから、この音を書き分けたとしても その違いは記憶されない。

英語のカナ表記

そうすると、今迄は英語の発音で 「異なる音には異なるカナの表記を割り当てる」 という方針だったが、表記が異なっていても どちらだったのか記憶されて無ければ困ると思った。

例えば、英語の発音で coat [koʊt] と court [kɔːt] は、区別されるべき音である。これは 「コウト」 と 「コート」 に書き分ける事が出来るけど、音の記憶としてはどっちがどっちか区別して覚えていない。

一方、「エー」 という英語の発音は無い事になっている。だから、現在使われている英語のカナ表記で 「エイ」 と書くべき所が軒並み 「エー」 となっていても、幸い問題にならない。「ケーキ」→「ケイキ」、「スケート」→「スケイト」と脳内で変換出来るから。

以前、使わない 「エー」 という表現を [əː] という発音に割り当てようと考えていて、しかし、 skirt [skəːt] を 「スケート」 と書くのはどうかと思いとどまった事がある。しかし、これを「スカート」と書くと [ɑː] という発音とカナ表記上の区別が付かない。

その結果、[əː] という発音に新しいカナ表記を考える事にしたのだった。それと同じく、今回は [ɔː] という発音に新しいカナ表記を考える。

ローマ字テーブルの改定

結論: [əː] には 「アェ」、[ɔː] には 「アォ」 を割り当てる事にする。その結果、[oʊ] には 「オウ」でも「オー」でも使え、[ei] には 「エイ」でも「エー」でも使える事とする。

例: skirt は 「スカェト」、court は 「カォト」 と書く。

この結論によって、今迄作ってきたローマ字変換テーブルなどの情報を変更する。そして、ヘルプコマンドを新たに作ることを思い付いた。ローマ字で \h と打てば、このローマ字変換を説明するヘルプページのアドレス( blog.cobli.jp/p/help.html )に変換されるようにするのだ。Webブラウザのアドレスの処でそうすれば、ヘルプページに何時でも飛べる。

日経新聞は悪文の宝庫

日経新聞を読んでいると、時々引っかかる表現に出くわす。今日はテニスの錦織選手がブリスベン国際大会で決勝進出を決めた記事の中の一文。

決勝で第1シードのラオニッチを破ったディミトロフを迎え撃つ。

これは、文法的には ディミトロフは決勝で第1シードのラオニッチを破った としか解釈出来ないが、決勝はこれからだから、事実はそうでは無いはずである。つまり、言いたかったのは、

• 決勝でディミトロフを迎え撃つ。
• ディミトロフは第1シードのラオニッチを破った。

という事だと読者が余分に考えなければ分からない。こういうのは悪文というよりも間違いの文である。では、正しい文に直していこう。やり方は幾つもある。句点を入れる、助詞を入れる、語順を変える、括弧書きにする。

• 決勝で、第1シードのラオニッチを破ったディミトロフを迎え撃つ。
• 決勝では第1シードのラオニッチを破ったディミトロフを迎え撃つ。
• 第1シードのラオニッチを破ったディミトロフを決勝で迎え撃つ。
• 決勝で(第1シードのラオニッチを破った)ディミトロフを迎え撃つ。

正確な文章を書かせる教育

日経新聞の記者達には、朝日新聞の記者だった 本多勝一氏 の書いた 「日本語の作文技術」 を読んで実践して貰いたい。

文の要素がどう結びつくのかは四則演算の法則の如く優先順位がある。読者はその規則に従って文を解釈する。日経新聞には、こんな基本的な事を知らない記者と校正係がいるらしい。お陰で、日経新聞を読む楽しみが増えるのである。

ところで、「日本語の作文技術」は良い本だと思うが、そもそも国語の教育で文の要素の結びつき方についての文法的な説明をしていれば、わざわざ特定の本を推薦する必要も無かった。

英語の早期教育に熱を上げるよりも、国語の教育で役に立つ日本語の文法規則を教え、正確な文章を書かせるようにして欲しい。

文法は情報工学の分野

正しい文に直す方法では 語順を変えるやり方が最も優れていると思う。書いてある順番通りに意味解釈をする事が出来るからだ。その他の方法では、「決勝で」という情報を一旦横に置いて後で利用する事を句点や助詞や括弧で示すから、意味解釈に余分な負担を強いる。

その一旦横に置くという行為は、コンピュータに詳しければ、「ああスタックに積むのと一緒だな」と理解できる。

そう言えば、妻は問題の文は主語が書かれていないから不正確と言っていたが、この文より前に錦織選手に関する話題である事が示されているからそれで事足りる。

西欧語の主語とは異なり、日本語には文中に主語は必須では無いのだ。必要なのは、文章の話題を示す言葉 主題語であり、しかも一度示されれば、その後別の主題語に入れ替えるまで有効なので 後の文中で毎回示す必要はない。

この主題語に用いられる助詞「は」について、「象は鼻が長い」で有名な文法学者 三上章 は 「は」は文を越える と表現しているけど、これもコンピュータで言えば グローバル変数だなと理解できる。

つまり、文法も情報を司る規則であり、コンピュータと同じく情報工学で扱える分野の一つと言えるのである。私は情報工学の観点から日本語の文法を分析して見たいと思っている。

日経の悪文から文法を考える

日経新聞の今朝の「朴大統領、友人に内部文書」という記事の文章について。

記事を読んでいると次の文章に違和感を覚えた。

疑惑は韓国のテレビ局JTBCが伝えた。海外にいる崔氏がパソコンの処分を依頼した関係者からパソコンを入手し、データを分析した結果、2014年3月にドイツで北朝鮮政策のロードマップを示した演説の草稿など文書44件を発表前に受けとっていたと報じた。

この後ろの文だけを素直に読めば、「パソコンを入手」と「データを分析」と「報じた」 主格は「崔氏」である。但し、「パソコンの処分を依頼」したのが誰かについては疑問が残る。「崔氏」とも考えられるが、内容から考えて自分が処分を依頼したものをわざわざ入手するはずもないから、この文では明示されてないが別の人物であろう、と推測出来る。

しかし、2つの文の内容から考えて、後ろの文は、主格は明示していないが「テレビ局JTBC」であるべき文といえる。つまり、次のように括弧書きして「崔氏が」という節を文全体に掛からないようにすると記者の意図どおりに解釈出来る。

改善例その1: (海外にいる崔氏がパソコンの処分を依頼した)関係者からパソコンを入手し、データを分析した結果、2014年3月にドイツで北朝鮮政策のロードマップを示した演説の草稿など文書44件を発表前に受けとっていたと報じた。

又、主格を明示する事でも解決する。

改善例その2: JTBCは、海外にいる崔氏がパソコンの処分を依頼した関係者からパソコンを入手し、データを分析した結果、2014年3月にドイツで北朝鮮政策のロードマップを示した演説の草稿など文書44件を発表前に受けとっていたと報じた。

文から主格に読める部分を無くしてもOK。

改善例その3: 海外にいる崔氏にパソコンの処分を依頼された関係者からパソコンを入手し、データを分析した結果、2014年3月にドイツで北朝鮮政策のロードマップを示した演説の草稿など文書44件を発表前に受けとっていたと報じた。

以上の改善例から考えて、日本語の文法には、

日本語では、文脈で分かれば 主格はなくても文として成立する。しかし、主格の無い文を書いた積りでも、主格が置かれる位置に「～が」を置くと主格と判断される。

という性質があるものと考える。括弧書きを使えば正しく解釈出来るのは、括弧書きの中身はもはや文の構成要素ではなく、関係者という言葉を修飾するだけの存在であると示せたからである。即ち、括弧内に ～が という分節があっても決して文全体の主格とは判断されない。

話し言葉では括弧を視覚的には表示出来ないが、口調を変える事で同様の効果が見込める。複雑な文章は、括弧書きをもっと活用して分かり易く書くべきだろう。

ハングル用の辞書を作る

最近、妻と一緒に韓国ドラマを毎日のように見ている。

以前、韓国語の勉強をした事があって 語学の勉強の積りで付き合って見るか、という態度だったけど、韓国と日本の文化の違いや同じ点を発見したり 言葉だけでなく、色々と興味が湧く。

確かに、取り箸を使わずに銘々が自分の箸を鍋に突っ込んだり、女性が立て膝だったりして あれっと思う事もあるが、家の中でも靴を脱がないような欧米のドラマとは違って、殆どの場面で文化面でも心情面でも日本人には全く違和感なく受け入れられる。単に喋っている言葉が異なるだけである。

それで、また韓国語の勉強をやってみたくなった。字幕に頼らずに聞いて分かる部分がちょっとでも増えれば楽しいから。

ハングル入力

私は地道に単語を覚えたりする事は苦手だが、色々と仕掛けを考えるのは大好きだ。韓国語を勉強するとなると、ハングルをパソコンで書けるようにして置きたい、と思って色々と調べた。

日本語の入力には日本語入力メソッドがあるように、韓国語の入力には韓国語入力メソッドがある。これには Windows に元々備わっているものも使えるし、Google Korean Input というものもあるらしい。

しかし、韓国語では もはや漢字は殆ど用いられないから、事実上 ハングルさえ入力出来れば良い。日本語入力のままでハングルが入力出来れば 日本語との混在も楽なのだ。そうすると、日本語の辞書にハングルとその読みを追加する、という方法がある。

読みは最初の文字が半角アルファベットの大文字、残りが半角アルファベットの小文字、という形をとり、アルファベットとハングルの対応は「文化観光部2000年式」に基づく。

「文化観光部2000年式」は、ハングルの読みをアルファベットで表す韓国政府の公式の方法で、韓国中の案内板に書かれているので 覚えておいて損は無い。但し、これは読みを表す方法なので、入力に使うとなると全く同じには出来ない。

それは、ハングルには母音の後にパッチムと呼ばれる子音が付随する場合があるが、そのパッチムの読みには「異なる子音の字母でも同じ読み」となる場合があるからだ。そこで、パッチムの入力コードも母音の前の子音と同じ入力コードを使うように変更する。

ハングルには、最初の子音が18種類、母音が21種類、パッチムが27種類存在する。そして、その組み合わせでハングルの文字の形が定まるので、理屈では(子音とパッチムは無しの場合も含め)全部で (18+1)*21*(27+1)=11,172種類 のハングル文字が存在する事になる。その中で実際には使われていない文字もあるけど、ユニコードではその全てが定義されている。

実は、11,172文字揃った Google日本語入力の辞書用のハングル入力辞書データがネット上に存在していて、有難くダウンロードさせて貰った。しかし、これには著作権は存在しないので、私が自由に改変して公表することも出来る。

辞書を改変する

まず、ᄎ という子音のコード ch について、c も使えるようにデータを追加する。この ᄎ 以外に c は使われていないから h を入力するのは余計な事だとの判断である。今使っているGoogle日本語入力のローマ字変換でも c が ch と同様に使えるようにしているのと合わせたいという気もある。

この改変で 検索と置換 機能で ch を c に変えるだけなら簡単だが、そうすると ch は使えなくなるのでちょっと困る。だから、c 又は C を含んだ行を抜き出してコピーした上でコピーした行の ch を c に、Ch を C に置換しなければならない。

ダウンロードした辞書はGoogleスプレッドシートに入力して加工。コードの先頭にある Ch はソーティングで集まるからコピーは簡単に出来るが、パッチムの ch はコードの先頭には無いから検索で見つけ、その行をコピーし、コピーした行の ch を c に置換する、という作業は手作業になる。それで、幾つかやってみて これでは駄目だと悟った。

それで、簡単に出来るように考えた。要は、c と C を含む行に何か印を付けてそれでソーティングすれば全部が集まるから、コピーして置換するのは一回の操作で済む。

それで、列を一つ増やして、=regexmatch(A1,"[cC]") という関数を一行目に書いた。これを列の最後までコピーすれば、2行目は =regexmatch(A2,"[cC]") というように自動的に数字が置き換えられている。

これで、A列にあるハングル文字コードに c 又は C が含まれている場合は TRUE、含まれてなければ FALSE、という値となり、これでソーティングして、行をコピーし、966行が増えた。因みに、ch を c にしたのが399箇所、Ch を C にしたのが588箇所になる。作業後に関数の列は削除した。

字母も追加

ハングル文字だけならこれでOKだけど、その子音だけ、母音だけ、パッチムだけ、の文字ユニコードで定義されていて、これも欲しい。さっき書いた ᄎ も子音だけの文字なのである。ハングル文字だと 츠 のように必ず母音を含むから、説明上都合の悪い事もあるのだ。

それで、子音、母音、パッチム の字母用のデータを作った。

G	ᄀ	独立語	1100
Kk	ᄁ	独立語	1101
N	ᄂ	独立語	1102
D	ᄃ	独立語	1103
Tt	ᄄ	独立語	1104
R	ᄅ	独立語	1105
M	ᄆ	独立語	1106
B	ᄇ	独立語	1107
Pp	ᄈ	独立語	1108
S	ᄉ	独立語	1109
Ss	ᄊ	独立語	110A
X	ᄋ	独立語	110B
J	ᄌ	独立語	110C
Jj	ᄍ	独立語	110D
Ch | C	ᄎ	独立語	110E
K	ᄏ	独立語	110F
T	ᄐ	独立語	1110
P	ᄑ	独立語	1111
H	ᄒ	独立語	1112

Xa	ᅡ	独立語	1161
Xae	ᅢ	独立語	1162
Xya	ᅣ	独立語	1163
Xyae	ᅤ	独立語	1164
Xeo	ᅥ	独立語	1165
Xe	ᅦ	独立語	1166
Xyeo	ᅧ	独立語	1167
Xye	ᅨ	独立語	1168
Xo	ᅩ	独立語	1169
Xwa	ᅪ	独立語	116A
Xwae	ᅫ	独立語	116B
Xoe	ᅬ	独立語	116C
Xyo	ᅭ	独立語	116D
Xu	ᅮ	独立語	116E
Xwo	ᅯ	独立語	116F
Xwe	ᅰ	独立語	1170
Xwi	ᅱ	独立語	1171
Xyu	ᅲ	独立語	1172
Xeu	ᅳ	独立語	1173
Xui	ᅴ	独立語	1174
Xi	ᅵ	独立語	1175

Xg	ᆨ	独立語	11A8
Xgg	ᆩ	独立語	11A9
Xgs	ᆪ	独立語	11AA
Xn	ᆫ	独立語	11AB
Xnj	ᆬ	独立語	11AC
Xnh	ᆭ	独立語	11AD
Xd	ᆮ	独立語	11AE
Xl	ᆯ	独立語	11AF
Xlg	ᆰ	独立語	11B0
Xlm	ᆱ	独立語	11B1
Xlb	ᆲ	独立語	11B2
Xls	ᆳ	独立語	11B3
Xlt	ᆴ	独立語	11B4
Xlp	ᆵ	独立語	11B5
Xlh	ᆶ	独立語	11B6
Xm	ᆷ	独立語	11B7
Xb	ᆸ	独立語	11B8
Xbs	ᆹ	独立語	11B9
Xs	ᆺ	独立語	11BA
Xss	ᆻ	独立語	11BB
Xng	ᆼ	独立語	11BC
Xj	ᆽ	独立語	11BD
Xch | Xc	ᆾ	独立語	11BE
Xk	ᆿ	独立語	11BF
Xt	ᇀ	独立語	11C0
Xp	ᇁ	独立語	11C1
Xh	ᇂ	独立語	11C2

表はGoogle日本語入力の辞書に合わせて、一列目は文字コード、二列目は文字、三列目は品詞、四列目はコメント、になっている。品詞は 全部「独立語」とし、コメントには ユニコードの番号を16進数で書いた。

子音のコードはハングル文字のコード(から母音を除いたもの)と同様だが、子音無しを示す ᄋ (「이응」 イウﾝｸﾞ という名があるけど) をどうするか悩んだ結果、X にした。

母音のコードはハングル文字と同じに出来ない( ᄋ 抜き)ので、頭にXを加えた。

パッチムのコードも子音のコードと区別する必要があり、頭にXを加えた。

これでOKと思いきや、実際にGoogle日本語入力の辞書にインポートしてみると、何故か最後の行が入力されていない。バグなのか仕様なのか不明だが、辞書の最後にダミーの行を追加する事で回避する。因みに、ダミー行として 「こぶり ハングル 辞書」 として置いた。

この改変したGoogle日本語入力用の[ハングル文字辞書ファイル]を公開する。(但し、コメント欄は空白にしてある。)

ローマ字変換テーブル、早くも Ver.2

先日、ほぼ完成と言いながら大幅に変更して、早くも Version 2 となった。

変更したのは、妻からの nn が「ん」にならない代物など使えない、との一言から。自分の理想で変更すると一般の人には使い難いらしい。だから、普通に使う限りGoogle日本語入力のデフォルトの設定と同じ変換結果になるように変更することにした。

それは、自分一人だけで満足しているよりも大勢の人に使って貰えれば、カナ書きについても良い方向に変化していくかも知れないと思ったから。

例えば、/ti/ の表現に「てぃ」が普及しているけど、/si/ の表現は未だに「し」のままで、このままでは sit と shit の区別が付かない。それは rice と lice の取り違え以上に危険なのだ。

未だ普及しないのは、内閣告示の「外来語の表記」というガイドラインに「てぃ」はあるけど、「し」に代わる表現の記載が無いのが原因だと私は思っている。

一部の人は、その表現に「すぃ」を使っているけど、私は「せぃ」を推したい。例えば、「すぃーと」と書いて、sweet なのか seat なのか、「すぃ」なら分からないけど、「せぃ」ならば、「すぃーと」と「せぃーと」に書けるから区別は付く。

/ti/ が「てぃ」という表現になったのは、単に「つ」が /t/ とは異なる音価なので使えないという理由よりも「え」の段と「ぃ」の親和性によるものだと思っている。

そして「すぃ」が一般化する前に、このローマ字変換テーブルが普及していれば「せぃ」の表現を定着させる事が出来るかも知れないと期待する。

カナ書きに適する

さて、Google日本語入力のデフォルトの設定では、「てぃ」の入力方法は thi と t'i の2通りが提供されているが、「すぃ」や「せぃ」の入力方法は提供されず、「す」や「せ」の後に小書きの「ぃ」を自分で加えるしか無い。

その点、私のローマ字変換では、「てぃ」は ty 「すぃ」は swi 「せぃ」は sy と綴るようにしている。英語に於いては、y や w が i や u の代わりを務める場合があるからこの綴りは覚えやすいし、必要なキーの数も少ない。

その他、カナ書きに適する様々な仕掛けを加えたのだが、それでも普通の日本語を入力する使い勝手が同じなら一般の人には魅力が無いだろう。だから、Ver.2 では普通の日本語でも使いやすい点を増やした。

普通の日本語でも使い易い点

まずは、「ん」の入力方法を改善する。今迄は n を一回押すだけで「ん」が入力出来るようにして満足していたけど、その後に母音や「や」行のカナが来る場合に、余分に ' を入れる必要があって面倒だ。やはり、「ん」専用のキーが欲しいので l を割り当てる。 l は押しやすい位置にあり、頻度の高い「ん」の入力には最適だ。l を /r/ と /l/ の書き分けに利用出来なくなるのは残念だが、rx を /l/ の入力キーとして使うことにする。

また、c を「ちゃ」行の入力に割り当てる。「じゃ」行の入力が j なのに、「ちゃ」行の入力には ch とキーの数が増えるのが嫌だという理由だ。ci や ce はイタリア語の読みと同じなので不自然では無いだろう。

陽母音と陰母音

韓国語を習うと、まず母音に陽母音と陰母音の区别が在ると教わる。この違いが動詞や形容詞の活用の違いなどに繋がるのだから、当然である。

それに、この区别は語感の違いも生んでいる。陽母音が「明るく、小さく、軽い」印象を与えるのに対して、陰母音は「暗く、大きく、重い」印象を与えるのだ。そして、複合母音では陽母音と陰母音の組み合わせは存在しない。

しかし、英語や日本語の事を考えていると、これらの言語でも、文法上の違いこそ無いけれど、やはり陽母音と陰母音の区别が在りそうな気がする。

日本語では、「あ」「え」「い」は陽母音、「お」「う」は陰母音だと思っている。先に挙げた「明るく、小さく、軽い」と「暗く、大きく、重い」の母音がまさにそうだし、その他思い付くだけでも、

• 陽母音 「きれい」 「かあさん」 「かわいい」 等
• 陰母音 「ぶす」 「とうさん」 「くさい」 等

そして、日本語でも母音の組み合わせは決して5種*5種=25通り全部が現実的とは言えない。「あい」、「えい(えー)」、「おう(おー)」、辺りは複合母音と言っても良さそうな程に繋がりが良い。その半面、「あう」のような組み合わせは「おう」に変換されたりする。(関西弁では、「買って」が「こうて」となり、「会って」が「おうて」に変化する。)

これは、陽母音と陰母音の組み合わせは日本語でも成立し難い事を示しているのではないだろうか。

そして、これは、個人的な体験だが、中国語を勉強していて duo(多) という言葉を dou(都) と覚えてしまったり、xie(謝) が「シェイ」になったりする。私だけでなく、日本人が謝謝を間違えて「シェイシェイ」って言うのを数多く知っているから、「うお」や「いえ」という母音の組み合わせは日本語には無いに違いない。

「うお」や「いえ」は、陽母音と陰母音の組み合わせでは無いが、口を閉じる方向へ母音が組み合わされる法則が在りそうだ。(あ→え→い 及び お→う の方向のみが成立し、逆は組み合わされない)

そうすると、[si] の音を書き表すのに 「スィ」と書くよりも「セィ」と書いた方が良いのではないか、と考えて見た。英語の [ɪ] は「い」と「え」の中間的な音だから尚更である。city をカナにして、「スティ」と「セティ」ならどっちが原音に近いか考えれば「セィ」に軍配が上がるはず。

しかし、日本語の「さ」行に於ける [s] の音は英語のそれに較べて異質で(「い」の段が異なっているのは周知だけど)、「す」と「せ」を較べれば、母音の音だけでなく子音の質もやはり異なっていると感じる。そして「す」の子音の方が「せ」の子音よりはまだ英語の [s] に近いと思われる。では、「スィ」に決定か、というと、これでは [swi] との区别が付かなくなる(例:「スィート」)、という問題が新たに生じる。

書き分ける、という目的からはやはり「セィ」の方が「スィ」よりも優れているのだった。

このような語感の違いは子音にもある。清音と濁音のペアがそうだ。擬態語だと思い付くだけでも、

• 清音 「ころころ」 「さくさく」 「からから」 「しつしと」 等
• 濁音 「ごろごろ」 「ざくざく」 「がらがら」 「じとじと」 等

英語の発音で日本語話者には区别出来ない R と L のペアも同じく L が陽で R が陰の語感を持っている。

• L light little gold blank 等
• R dark gravity grave grand break 等

black は L でしょ、なんて例もあって必ずしも当たらないけど、L が 「ら」行で R が「ら゛」行と言った書き分ける決まりがあれば苦労しないのに、と思ったりする。

R が「ら」行という慣行を変えられないなら、いっその事 L を「ら゜」行と表現するのはどうだろう。Wikipediaによると、明治初期にはそうした試みがあったそうで、又、現在でも国語学などでは異音を示すのに使われるとの事。(例: 鼻濁音の「が」を「か゜」で表現)

グロービッシュの元ネタ

グロービッシュの単語集で発音記号からカナ書きへ変換する試みのテストが終わったけど、この単語の集まりの偏り方は気になる。

数字、曜日名、暦月名、等の最重要単語が無いのに、弾丸とかハイジェャクとかの物騒な単語は載っている。何故なのだろう。

そして、今日、その理由が分かった。Globish1500語の元ネタはVOAのSpecial Englishにある単語らしいのだ。VOAとはアメリカのラジオ放送で、英語を母国語としない人々にもニュースを届けるべく、使う単語を1500語に制限した番組も提供している。

その単語集 Word Book をネット上に見つけて、Globishと見比べたら、数字、曜日名、暦月名、等は巻末に Special Words and Information という項目があって そこに纏めて書かれていた。

そして、本体の単語集には 弾丸もハイジェャクも 載っているのだ。

興味があるから、Word Book と Globish を統合した単語帳を作ろうと思う。公開している Globish のファイルに新しいシートを付け加えて入力するので、作業中の様子も分かるだろう。

半角カタカナを利用する

英語発音のカナ書きで解決していないのが「アクセントの有無の表示」をどうするか、という問題だ。細かな音の違いよりも、正しいアクセントで話した方がよっぽど通じる、という話を良く耳にする。

アクセントのある音節をボールド体にするとか、アクセントの無い音節をイタリック体にするとか、考えて見たけど、そのような文字飾りはテキストファイルからは抜け落ちるし、カナにはイタリック体は無さそうだし、短い単語だとほぼ全部がアクセントのある音節だから、ボールド体ばかりになってしまうし、良い解決策とは言えない。

それで、アクセントの無い音節は半角カタカナで表すのはどうだろうか、と考えて見た。それなら文字コードで区別出来るし、日本語入力の機能には半角カタカナへの変換が備わっている。

しかし、「半角カタカナは使うな」との言い伝えが頭にこびり付いているものだから、それで大丈夫なのか考えて見た。

元々は、半角カタカナは 1 byte (=8bit) のデータでカナを表す仕掛けだった。英数字と記号、それに制御コードを入れても 7 bit あれば足りて、 8bit の空間がまだ半分 (=128文字) 空いているのだから、漢字は無理でも (8 bit目を 0 にすれば制御コードと重なるエリアは避けて利用するから 実際には使えるのは 128 文字よりも少なくて) カナだけなら 何とかそこに押し込められる。

銀行の通帳に印字される文字が未だにカナなのもその当時の名残りである。しかし、欧米の通信システムなど、日本の事情などにはお構いなしに、7bit のデータを扱えれば十分ジャネ…とか言って、残り 1 bit をパリティビットに勝手に使ったりして電子メールシステムで 8 bit のデータは送ると文字化けする可能性があった。

そこで、日本語の電子メールシステムでは 7bit にデータが収まるように漢字コードを変換させてやり取りする規格を作ったのだが、そこに半角カタカナは入れて貰えなかった。それで、「電子メールで半角カタカナは使うな」 という格言が生まれたのだ。

しかし、時代は移り変わり、今や「半角カタカナ」は 1 byte のデータではなく、ユニコードに定義された文字群の一つとなった。だから、こうしてブログの投稿で発音記号の[æ]を問題なく扱えるのと同じく[ﾊﾝｶｸｶﾀｶﾅ]も問題なく扱える訳だ。(電子メールだと問題あるが)

だから、これからは「半角カタカナ」も積極的に使うことにする。全角カタカナへの変換キーには Shift + CapsLock(F14) を割り当てていたので、半角カタカナへの変換キーには Shift + Tab を割り当てて見た。抜群に使いやすい。

ローマ字テーブルのテスト

Globish1500語を使って、カスタマイズした Google日本語入力のローマ字テーブル をテストした。カタカナ語の入力が楽になるように、かつ、日常の日本語の入力も問題なく出来るように考えて作ったので、こうやってブログの記事を書くのにもカスタマイズ版を使っている。

このカスタマイズ版を使い始めて、通常の日本語の入力でもこれは便利と思ったのが n を一度押しただけで「ん」が入力され、r を一度押しただけで「ー」が入力されること。「ん」を入力するのに nn と押す癖はもうなくなった。(nn が「んん」になってしまうから)

テストは、Globish1500語のリストに発音記号と対応するカナを加える事で行う。アクセントの無い音節は半角カナで表現した。元のリストは1500語丁度だったけど、同じ綴りでアクセントと発音が異なる単語は別の単語扱いをしたので11語増えて1511語になった。

スプレッドシート形式にした[Globish&VOAwordbook]を公表する。単語のリストにも著作権は認められるのだが、これはGlobishの創始者が無料で公開しているものを利用しているので問題はないと思う。

後日談: Globishに加えて、VOA Special English Word Book という単語集にある単語を追加した。

このリスト中の単語の文字総数は8062字、そのカナを入力するのに要したアルファベットの総数は245文字減った。

これは、普通のローマ字変換では子音字を入力するのに有りもしない u とか o とかを打つ必要がある(例: supureddosi-to 「すぷれっどしーと」…カスタマイズ版でも変換可能)のに対して、カスタマイズしたローマ字変換ではそれが不要(spreddsirt 「すぷれっどしーと」)である事が大きい。

そして、英語の綴りと入力文字が完全に一致するものが141語もある。又、c x も使うと一致する率が更に向上するのだが、発音記号との対比が分かり難くなる事と 音節のアクセントの有無をカタカナの全角と半角で書き分けるようにしたから、x が使えない場合( k と s を分ける必要が出て来る)もあったので、このリストでは止めておいた。

テスト中に幾つかの問題点を見つけて修正したので、このカスタマイズでかなり完成に近づいたと思う。

日本語にし易い英語発音を選ぶ

Globish 1500語の発音記号を入力は、現在のところ、403語迄進んだ。その際に思い付いたのだが、日本語話者にとっての理想の発音を決めたいと思う。

それと言うのは、英語の発音は一つの辞書でも複数載っている事もあるし、使う辞書によって異なる事も度々。そのどれを採用するのかは私の選択による。英国式と米国式を混ぜこぜにするのは良くないとは言え、辞書に記載されているものを載せる限り、通じない事も無いだろう。

ちゃんとした辞書を作るのであれば世の中で実際に使われている複数の発音の一つだけを編者の意向で選ぶ事は許されないだろうが、発音を正しく記録できるカタカナ語を作ろうという私的な試みだから許される。

その選び方は、なるべく日本語話者にとって発音し易く、かつ、綴りから規則的に定まる発音に近いのが良い。それに語源から見ても正しいもの。更に条件を付けるとすれば、既に出回っているカタカナ語にも近いもの。

例えば、direct という単語がある。

ジーニアス英和大辞典によれば、音節の分け方は di・rect であり、発音は [dɚ'rekt] | [daɪ'rect] | [də'rekt] | [dɪ'rekt] の4種類ある。

一方、Oxford現代英英辞典によれば、音節の分け方は dir・ect であり、発音は [də'rekt] | [dɪ'rekt] | [daɪ'rect] の3種類ある。

理屈では、i が閉音節なら [ɪ] だし、開音節なら [ə]か 後続の r の影響で米国式に [ɚ] になるはずである。[aɪ] の読みは開音節かつアクセントがある場合だけど、2音節でそのどちらにもアクセントがあるのは例外的だ。

つまり、どちらの辞書も分節のやり方を2通り示す必要があったはずだけど、そんな余裕は無いだろうから仕方ない。ただ、語源からいうと di・rect が正しい。rect はまっすぐという意味のラテン語の単語に由来する。rectangle (直角) も同じ語源。

そんな事を考えて、[də'rekt] の読みを選んだ。

別の例では cast という単語。

これは、米国式には [kæst] と [kɑːst] の2通りがあり、英国式は後者のみである。カタカナ語では配役という意味で「キャスト」がある。

もう一つ caste という単語があって、発音は cast と全く同じだが、階級制度という意味で、カタカナ語では「カースト」と読み、「キャスト」と使い分けている。

どの発音を使うのか、色々考える事も多い。

加減と乗除との大きな違い

最近はローマ字変換テーブルの改変に余念が無い。日本語の入力についてだけでも通常の日本語入力よりも絶対に優れていると思っているが、カタカナ語の入力を更に改善するべく、Globish1500語でテストする。

1554語のリストの内、現在、41語まで発音記号とカタカナ語の入力が終わった所。その間に改善点を思い付いてローマ字変換テーブルを書き換えてブログの内容を更新したりしてなかなか進まないけど、なるべく早く終えて公表したい。夏休みの宿題だと思って頑張る積もりだ。

最近、情報技能についての投稿が多い。一つのテーマについて考えれば関連した事が次々と浮かんでくるから仕方ない。今回もその関連で一番大事だと思っている事を書く。

さて、タイトルを読んで私が言いたい事が分かるだろうか。つまり、足し算・引き算 と 掛け算・割り算の大きな違いは何かという問いだ。この事を理解しているかどうかで、数学や理科の成績も大いに違ってくるはずだ。しかし、この事の重要性について学校ではちっとも教えないで、どうでもいい枝葉ばっかり知識を詰め込んでいるのだ。

その答えは…

• 足し算・引き算は同じ質のモノの間でしか演算出来ないし、結果も同じ質のモノになる。
• 掛け算・割り算は異なる質のモノの間でも演算出来るし、例え同じ質のモノ同士の演算でも結果は異なる質のモノに変化する。

具体的に言うと、体重50kgと身長160cmを足す事は出来ないし、その数字を足したとしても全く無意味である。体重の足し算だとしても、50kgと100gを直接足すことも出来ない。単位を揃えて初めて意味のある足し算が出来る。

しかし、掛け算や割り算なら全く異なる質の間の演算も意味を持つ。例えばBMIという肥満指数は(体重)/(身長)^2という事になっている。あるいは、長さという同じ質同士を掛けると面積という全く異なる質に変化する。

これらは当たり前の事だと思うだろうが、とてつもなく強力で例外のない原理だ。物理の複雑な公式に巡りあっても、「加減の記号の前後は同じ単位を持つ量である」という大原則がどんなに理解や推測を助けてくれることか。

しかも、これは数学や物理に限った事ではない。あらゆる論理や言語に於いても成り立つ原則なのだ。例えば、文章中の接続詞の前後には同じ質のモノが並ぶ。名詞と名詞、形容詞と形容詞、動詞と動詞、文と文、…といった具合である。中には文と名詞といった一見異なる組み合わせもあるけど、それは名詞に何かを補って文として解釈することを暗に求められている。

こんな観点から文章を眺めるのも面白い。