10/4 水、+0:22 語尾の y を ie に変えて s
中学で英語を習うと、『名詞〈study〉の複数形を作るには、語尾の〈-y〉を〈-i〉に変えて〈-es〉を付ける』とか教わりますけど、此の説明は変だとずっと思ってます。変な点:
- なぜ y を i に置き換えられるのか。〈studi〉じゃ別物じゃないか。
- 〈studi〉になったら語尾は最早〈-i〉なんだから、其れに付くのは〈-es〉じゃなくて〈-s〉でしょう。
ならどう説明すれば良いかと言うと、『〈-y〉を〈-ie〉に変えて〈-s〉を付ける』です。〈funny〉と〈funnie〉の様に、元々語尾の〈-y〉と〈-ie〉は同じ様に働くし，〈studie〉に〈-s〉を付けるのは原則に沿います。
で、「"yをieに変えてs"」で Google 検索をしてみたら、同じ考えの人が少しだけ見付かりました。
10/4 水、+0:22 インテル、はいってる
「Intel inside.」を「インテル、はいってる」とした訳は、とても旨く行った例だと思います。韻をちゃんと残せてますよね。
でも、原語では『〜在中』辺りの表現とも掛けてあるんじゃないかなぁとも思います。「壊れ物在中」みたいな。
日本語では同じ様な概念でも場面に合わせて別の表現をするけど、英語では其れを一つの言い方に纏めてる感じが有ります。日本語のやり方は、態と其の場面に合わない表現をしておかしみを生み易い。英語は、本来別分野で使われるのと同じ型の表現で、単語を一つ取り替えるだけで違った事を表して、おかしみを生み易い。どっちもどっちですね。後者では［「落石注意」「落雷注意」→「巨大ワンワン注意」］を思い出しましたけど此れはちょっと違うかな。
10/4 水、+0:22 〈U.S.A.〉
〈U.S.A.〉などに使われる〈.〉は、〈U.〉なら〈United〉の省略である事を示す物であって、区切り記号じゃありません。だから、〈U.S.A〉みたいに、最後の〈A〉だけ〈.〉が無いのは変です。省くなら〈USA〉と全部省いて下さい。
…と私は認識してますけど、余り自信たっぷりに此んな事を書くと、後で間違っていた事が分かってうろたえたりするからなあ。
10/4 水、+0:22 Enjoy!
絵を描いてみたり，YouTube に動画を載せてみたりすると、英語圏では添える言葉の終わりに「Enjoy!」だの「Enjoy it!」だの書く人が結構居ますよね。まあ確かに面白い物も多いんですが、日本人は絶対書かんよなぁとか。直訳の「楽しめ!」は在り得ないし，「お楽しみ下さい」も相当自信が無いと書けないし，「お楽しみ頂ければ幸いです」ぐらいならまだ気楽に書けるけど全ての作品に書いたりはしないし長ったらしいし。
其れを、あの方々は、目も当てられない様なアレな絵にすら『かなり努力しました! 今までで最高の出来です! 楽しんで下さい!』。凄いなぁ。
10/16 月、+0:14 どう森に遅れても時計を弄らない
二日程前に風邪引きました。喉と鼻がむずむずします。
一応“どうぶつの森”は、時計を巻き戻したりしない方針でやっています。
でも、常に 10 分ぐらい遅れた設定にしてあります。と言うか、勝手に遅れて然うなってるんですが。此れなら、『ヤバい、間に合わないか』と云う時には間に合います。
10/16 月、+0:14 蛍光灯が弱った
チラチラするので取り合えず其の部分だけ点けないでおいています。交換したくあります。
10/16 月、+0:14 髪を切った
土曜日に床屋に行って来ました。頭が少し寒くあります。でも、髪を洗うのに石鹸が少なくて済むのは良いなぁ。
10/16 月、+0:14 午後の紅茶を買う場所
大学の食堂の一つ‘はるにれ’の入っている建物の、はるにれの前の自動販売機では、‘午後の紅茶 ミルクティー’350 ml が 110 円で売られています。でも、はるにれの中では 500 ml が 100 円で売られています。此れは、中で買うしか無いでしょう。
10/16 月、+0:14 文書には符号化方式の情報を埋め込まねばならん
以下、文字配列の事を知らない人に配慮しないで書きます。
装飾などの情報が一切含まれない、文章だけの書類の形式が在ります。Windows とかなら「*.txt」とか云う拡張子が付く奴です。
最近、符号化文字配列の事を調べていたら、此の文書書類の形式に就いても知りたくなりました。『文字が二進の符号で表されてるのは分かるが、其の文章本体の前後にはどんな情報が入ってるんだ』って。
でも、どうやら、ホントになんにも無いみたいですね。詰まり、システムが『こっからここまで一つの書類ね』って枠を用意したら、其の中にはもう文字を符号化した物だけがズラーッと入ってる。成る程、だーから、システムのかなり基礎的な所で［テキストファイルとバイナリファイル］みたいに分別されてるんですね。
でも此れって駄目じゃないですか。符号化方式が ASCII だけの頃なら其れで用は足りたでしょうけど、ISO 646 とか言って色んな符号化方式が出て来た時点で［此の文書がどの方式を使ってるか］の情報は必須になってた筈。なのにどうして、其れを埋め込む統一した形式をみんなで決めなかったのか。
其れをしなかったから、此の 21 世紀になってすら『此の符号列は此っちの方式では出現しないから、あっちの方式である可能性が高い』とかって面倒な処理を書類を開くたんびに一々やって、而も其れに時々失敗してギョッとさせて呉れる。（TextEdit は JIS X 0208 を Latin-1（正確には Mac Roman）と認識しやがりますが、‘エスケープシーケンス’ぐらいちゃんと見て下さい。）
今でも遅くないので、Apple と Microsoft と其の他諸々がちゃんと話し合って、‘テキストファイル ver. 2’（拡張子「*.tx2」，Mac ファイルタイプ「TXT2」）（仮称）を作って下さい。文書書類の冒頭 64 バイトに符号化方式の情報を埋め込むだけで宜いから。
10/16 月、+0:14 ‘逆スラッシュ又は円記号’
ASCII の逆スラッシュの位置は、JIS X 0201 英字部分では円記号に置き換えられました。此れが今でも問題を起こしているのは、知ってる人はよっく知ってる事です。結構前の話ですが、此の円記号問題が実際に目の前に現れて驚きました。Shift_JIS で書いてた JavaScript 書類を Unicode にしたら、円記号が本当に Unicode での円記号の位置に対応付けられて、正常に動作しなくなったんです。
此んな事を避ける為に、Windows では、『JIS で円記号になってる所も Unicode に変換する時は逆スラッシュの位置に対応させるが、日本語の活字では見た目は円記号にする』って云う苦しい策を取りました。其の御陰で、「価格 ¥200」と云う文字列を含む書類を Unicode に変換した時に「価格 ＼200」みたいなのに化けてしまう事は、見た目上は一応回避できたみたいですね。が、Mac に入ってる活字は正直に逆スラッシュなので、Windows での時と同じ調子で処理する FireFox 1.5 君は、Shift_JIS の書類であっても逆スラッシュにして表示して呉れます。
此の問題って其も其も、Unicode 上の ASCII 部分の逆スラッシュの位置を、日本で此の位置が未だに円記号として使われている事情を無視して逆スラッシュにしちゃったのがいけないんじゃありませんか。‘ハイフンマイナス’とかと似たノリで‘逆スラッシュ又は円記号’にすれば宜かったのに。純粋な逆スラッシュと円記号とは其れ其れ別の位置に用意。
其りゃ、ISO 646 の入れ替え可能部分は別の地域でも色々と入れ替えられましたけど、フランス語とかあの辺りは Latin-1 で解決できるじゃないですか。違う? 現役の文字配列（而も日本語に取ってはほぼ唯一の選択肢）である JIS 配列（及び其れに基く Shift_JIS と EUC-JP）で未だに円記号になってるのとは話が違うんじゃないかと思います。
まあ、余所の国の事情はよく知らないで書いてますけど、円記号と同じ様な状態になってる記号が ASCII 部分に他に在るならば、其れも‘逆スラッシュ又は円記号’とおんなじ扱いにすりゃ宜いですよ。とに斯く Unicode の ASCII 記号は互換性の為の物。色んな意味を与えられた記号なら、色んな意味を其の儘持って来れば宜いんです。