半月記 » ことば http://pasero.net/~mako/blog Wed, 23 Jun 2010 09:25:44 +0000 ja hourly 1 http://wordpress.org/?v=3.0 subscribe の訳語は「継読」で http://pasero.net/~mako/blog/s/113 http://pasero.net/~mako/blog/s/113#comments Thu, 04 Feb 2010 08:49:51 +0000 Mako http://pasero.net/~mako/blog/?p=113 続きを読む →]]> RSSフィードやメーリングリストなど、subscribe の訳語を「購読する」、名詞形の subscription を「購読」としているのを目にする機会がしばしばあります(ほかに文脈に応じて「登録」や「加入者」(subscriber の訳として)としている場合もありますが、ここでは専ら「購読」について考えます)。

RSS フィードをはじめとして、インターネットでは、ある情報の更新を何らかの手段で通知するための機能がいろいろとあり、特定の情報をその管理下におくように指定することを “Subscribe” (署名する、賛同する、予約する、購読する、などの意) といいます。

この訳語がどうもしっくりこないと感じているのは、私だけではないようです。違和感は「購」が、代価を支払う、という意味を持っているところにあります。

「購読」とは「金を払って読む」事であって、ウェブ上の、いくらでも無料で参照できるリソースに対して使用する語ではないだらう。初めてこれらを「購読」した時、「え、金かかんの?」と思ったものだ。

ほかに適切な訳語があればきっとそれが当てられているでしょうから、しかたないということのようです。

だったら、「RSSフィードを購読する」よりももっと適した日本語訳があるかというと…これが意外と難しいようで…。

適切な語がないのだったら造ればいいのか、「統計」や「神経」だって最初はそうだったのだ、などと思いながら布団に入り込み、あれこれ考えているうちに「継読」というのを思いつきました。我ながらこれはなかなかいいと悦に入って眠りにつきました。

翌朝、「継読」で検索してみると、意外に多く引っかかりました。読書界(?)で多く使われているようで、特にシリーズ物を次々に読んでいくことを指している用法も見受けられ、ちょうどここで考えている意味とも合致しそうです。そのほかにメールマガジンに対して用いられているものも見つかりました。そして、ここでの主張と同じものも発見しました(『購読』ではなく『構読』や『継読』にすべき)

この造語の最初の発案者にはなれませんでしたが、あらためて

  • subscribe は「継読する」
  • subscription は「継読申込」または短くして「継読」

と訳してはどうかと主張します。

この語の難点のひとつは、見た目が「継続」に似ていて、「間違いじゃないの?」と思われそうだというところでしょうか。

タグ

, ]]> http://pasero.net/~mako/blog/s/113/feed 0 外来語のカタカナ表記の末尾の長音について http://pasero.net/~mako/blog/s/99 http://pasero.net/~mako/blog/s/99#comments Sun, 31 May 2009 03:58:11 +0000 Mako http://pasero.net/~mako/blog/?p=99 続きを読む →]]> 1年ほど前にマイクロソフト社の方針変更で話題になったものですが、今ごろになって書いてみます。

検索してみると、これについて論じているページはたくさん出てきます。
そもそもカタカナ表記はどうしても元の発音を表現できないので長音をつけてもつけなくても五十歩百歩(例えば、「カタカナ語の長音表記」について)という主張は、そのとおりだと思います。

例えば「コンピュータ」と「コンピューター」を(これが英語の computer のことだという知識があると難しいのですが、その発音を思い起こしてしまわないように注意しながら、単純に日本語のカタカナだと思って)発音して比べてみると、後者のほうが「タ」のアクセントが強くなります。たぶん私だけでなく一般的にそうだと言ってもいいと思います。英語ではありませんが、「イタリア語では長音を区別しないが、単語を単体で発音するとアクセント位置が長くなる（単子音の場合は顕著）ので」長音を使うとしている場合もあります。つまり逆に考えると、カタカナに長音があるとそこにアクセントが置かれやすいことの現れです。

私は素人なのでこれ以上詳しく述べることはできませんが、検索しても英語のカタカナ表記の長音とアクセントについて言及しているものがあまり多くは見つからないのは意外でした。

私自身は、五十歩百歩とはいえ少しでも隔たりの小さいほうがまし、という考えで、不要なアクセントを作ってしまう語末の長音には賛成しません。

タグ

, ]]> http://pasero.net/~mako/blog/s/99/feed 0 第何何曜日 http://pasero.net/~mako/blog/s/68 http://pasero.net/~mako/blog/s/68#comments Mon, 09 Apr 2007 10:59:24 +0000 Mako http://pasero.net/~mako/blog/s/68 続きを読む →]]> 日付を尋ねる場合に「何年何月何日」のようにあいだに別の語が挟まればいいのだが、「第何何曜日」というのは言いにくい1)。次のような事情で「第何何曜日」を求める方法を検索したく、この単語でいいのだろうかと思ったが、やはり仕方ないのかこのまま書いてあるのがいくつか見つかった。ともあれ意味は通じるし、そもそも未知のところを「何」に置き換えればほぼそのまま表現できる日本語は強力だ。

さて、その事情というのは……うちの資源ゴミの収集日は「第 2, 4 月曜日」だ。うっかり忘れてしまうことがしばしばあるので、収集日 (の前日) に自分宛にメールを飛ばそうと考えた。cron では「第何何曜日」という指定はできないので、スクリプトのほうで判定する。せっかくだからメモしておく。

Y 年 m 月 d 日は、その月の第 i の w 曜日か

これは検索ですぐに見つかった。曜日は、PHP なら求める手段は用意されている。

PLAIN TEXT
PHP:
  1. $i = floor(($d+6)/7);
  2. $w = date("w", strtotime($Y . $m . $d));

Y 年 m 月の第 i の w 曜日は、その月の d 日か

上の逆だから簡単だと思ったが、何度か試してみてようやく

PLAIN TEXT
PHP:
  1. $w1= date("w", strtotime($Y . $m . "01"));
  2. $d = $i*7-6 + ($w+(7-$w1))%7;

とした。ここで $w1 は当該月の 1 日の曜日である。$d が当該月の最大日を越えない判定が必要かもしれないが、ゴミ収集日はたいていの場合 5 回目の曜日には設定されないので省略した。

---

ところでこのために PHP マニュアルの日付・時刻関数を見ていたら、日の出時刻や日の入り時刻を返す関数というものまであるではないか2)。

現代の都市生活者には日の出・日の入り時刻より、ゴミ収集日を返す関数のほうがありがたい。……と思ったら、この日の出・日の入り時刻関数は宗教上の必要から作られたらしい。別に農耕狩猟生活のためというわけではなかった。


  1. 「第何週の何曜日」というと誤解を招く。今月はたまたま 1 日 が日曜日だからいいとして、たとえば来月 (2007年5月) の「第 2 週の月曜日」は 7 日? 14日? ↑
  2. 残念ながらここのサーバは PHP のバージョンが 4 なので、これらを使えない。 ↑

タグ

, , ]]> http://pasero.net/~mako/blog/s/68/feed 1 電子テキストの文字校正 http://pasero.net/~mako/blog/s/67 http://pasero.net/~mako/blog/s/67#comments Sat, 31 Mar 2007 01:54:48 +0000 Mako http://pasero.net/~mako/blog/s/67 続きを読む →]]> 印刷を目的としない文章を、修正個所を判りやすく指示 (つまり「校正」) しながら遠くにいる人ととともに作っていくにはどうするか。メールでやりとりすることを念頭において考えていたことをまとめてここにメモしておく。

ごく短いプレーンテキスト

「2 段落めの最初の文、ふたつめの『ロボット』を『人間』に置換」という感じの、電話で口伝えするような、長たらしい指示。
ごく短い文書で校正個所が少ないときにはこれでも伝わるが、増えてくると嫌になる。

指示を受け取った側 (この文章では「著者」と呼ぶことにする) は、その指示にしたがって元の文書を書き換える。

改行が少ない文書

自然言語の単純なテキストファイルや HTML の文書など1)。

校正の内容は、プレーンテキストなら文字種や大きさはないので、ほとんど削除・挿入のみ (置換は「削除して挿入」で表現できる) となる。

タグによる校正記号

<del> と <ins> で表現する。校正に関するコメントは著者と校正者で了解して <comm> にするとか、あるいは HTML の範囲内のタグを流用する。

PLAIN TEXT
HTML:
  1. ロボットは他の<del>ロボット<comm>これは「人間」のはず</comm></del><ins>人間</ins>に危害を加えてはならない．

HTML を知っている人には意味が通じやすい。しかし、人間に伝えるためのもので、実際に HTML のタグとして機能するわけではない2)ので注意が必要である。エディタは HTML 対応のもので代用できるかもしれない。

校正の作業

校正者は対象ファイルにエディタで直接タグを書き込んでいく。置換の場合、<del> と <ins> が連続することになる。

ruby を使える環境なら Docdiff (単語あるいは文字単位の差分でとる) を利用する方法がある。docdiff.conf で

PLAIN TEXT
CODE:
  1. tag_del_start           = <del>
  2. tag_del_end             = </del>
  3. tag_add_start           = <ins>
  4. tag_add_end             = </ins>
  5. tag_change_before_start = <del>
  6. tag_change_before_end   = </del>
  7. tag_change_after_start  = <ins>
  8. tag_change_after_end    = </ins>

と設定しておく。

元ファイルを別に保存しておき、対象ファイルは校正後の形に書き換える。

PLAIN TEXT
BASH:
  1. docdiff --format=user example.txt.orig example.txt

で校正記号入りテキストを作成する3)。コメントには対応していないので、その後エディタで開いて書き込む。

著者の作業

校正記号入りテキストを受け取った著者は、エディタで <del> のタグで囲まれた部分 (もし校正者の指摘を受け入れられなければ <del> ではなく <ins> で囲まれた部分) や <comm> で囲まれた部分を削除する。さらに <ins> タグを (囲んでいる内容は残して) 削除する。

HTML 文書

HTML 文書の場合、上記の <del> や <ins> のタグを使う方法では校正記号が目立たない。また、タグ自体の校正をするときに特に混乱する。たとえば

PLAIN TEXT
HTML:
  2.   <li>ロボットは他の人間に危害を加えてはならない．</li>
  3. <del></ol><comm>閉じタグが間違っています</comm></del><ins></ul></ins>

となってしまう。そもそも上記の方法で用いたタグは人間のためのもので、著者と校正者で了解できていれば何でもよく、<del> や <ins> でなければならないわけではない。

それを一般化した 真鵺道 Manued というものがある。もちろん HTML 以外のプレーンテキストにも使える。規則は少ないのですぐに覚えられる。たとえば上の例は

PLAIN TEXT
TEXT:
  1. <ul>
  2.   <li>ロボットは他の人間に危害を加えてはならない．</li>
  3. 【</ol>／</ul>＃閉じタグが間違っています】

のように書くことができる4)。

真鵺道 Manued の最大の特長は機械処理が可能という点である。Emacs (系) には manued.el がある。しかし残念ながらほかのエディタの対応は見かけない。

校正の作業

対象ファイルにエディタで校正記号を書き込んでいく。Emacs で manued.el を使えば楽である。

校正ファイルの先頭に、アプリケーション (Emacs の manued.el のみなのか) に対する修正記号定義コマンドと、人間に対する注意書 (著者と校正者がしっかり了解していればなくてもいい) を付ける。

PLAIN TEXT
CODE:
  1. defparentheses  [ ]
  2. defdelete       /
  3. defswap         |
  4. defcomment      ;
  5. defescape       ~
  6. deforder        newer-last
  7. defversion      0.9.5
  8. 校正記号は次のとおりです。
  9. [α/β]          αをβに変更する
  10. [/α]            αを挿入する (変更の特殊形)
  11. [α/]            αを削除する (変更の特殊形)
  12. [α|γ|β]       αγβをβγαに並べ換える
  13. [α||β]         αβをβαに並べ換える(並べ換えの特殊形)
  14. [;コメント]    校正に関するコメント

ruby を使える環境なら、Docdiff (単語あるいは文字単位の差分でとる) を利用する方法がある。

元ファイルを保存しておき、

PLAIN TEXT
BASH:
  1. docdiff --format=manued example.txt.orig example.txt

とする。

真鵺道 Manued 自体は上述の定義コマンドで修正記号を変更できる。しかし Docdiff は真鵺道のデフォルトの修正記号 (上記のもの) に固定されていて自由に変更できない。また Docdiff はコメントには対応していないので、後でエディタで書き込んでいく。

著者の作業

もし著者が Emacs で manued.el を使えるなら、受け取った校正記号入りテキストで、個々の校正記号についてオリジナルか修正指示のどちらを選択するかを簡単な操作でできるし、校正記号を含まない元の文書または修正された文書の全体を取り出すことも簡単にできる。

もしそれを使えない場合は、前述のタグ表現の場合と同じように、いちいち校正個所を直していく。

改行を多く含む文書

もちろん適宜改行されているテキストに対しても上記の方法は適用できる。
そのほかに diff を使うことができる。元ファイルを保存しておき、

PLAIN TEXT
BASH:
  1. diff -u example.txt.orig example.txt

とする。ディレクトリごとまとめて扱うこともできる。
プログラムのソースコードなどに向いている。よく改行されている HTML 文書や TeX の文書に使うこともできる。

校正コメントは使えない。

著者は diff ファイルを受け取ったら、patch で元ファイルに反映させることができる。

書き換えてしまう

ここまで「変更個所および変更内容をわかるように指示する」ことに留意して、ファイルを直接書き換えてしまう (オリジナルを残さずに) ことは考えなかった。

だんだん「校正」から逸れてきたが、履歴がきちんと残るのなら直接書き換えてしまうということも考えられる。メールでのやりとりではないが Wiki という手もある。しかし短い単なるテキストを扱うには大袈裟すぎる。それに校正段階では一般に公開しないのが普通で、そのためには認証のしくみをつけて、いちいちログインしてもらうようにしなければならない。いわゆる一般人にはそれだけでも敬遠される。

cvs, subversion などと適切なブラウザの組み合わせも、変更点がわかるので「校正」と言えなくもない。しかしこれもプログラマやそれと同じ程度にコンピュータに興味を持って向かい合える人以外にはなかなか受け入れてもらえないだろう。

朱を入れる

OpenOffice.org Writer, MS Word, PDF などの文書に「朱」を入れる。それぞれのデータを扱えるソフトを著者と校正者がそれぞれ所有していて、その「コメント機能」の類を使えることが前提となる。商用ソフトが必須となったり Linux では揃えられなかったりと障壁が大きい。

文字種や大きさ、レイアウトなどの校正は、ここで言う文字校正の範囲を越える。文字校正だけなら、テキストに変換して上記の方法を適用することも考えられる。

最後の手段は、紙にプリントして朱を入れる。もはや「電子テキスト」からも逸脱する。ついでなのでここにメモしておくが、「印刷校正記号 JIS Z 8208:2007」は 2007-01-20 改正になっている。これは有料となっているが、素案 (PDF) がネットで見つかった (発効されたものと違うかもしれないので注意)。


  1. HTML の地の文で適当に改行を入れると、たいてい微妙に空白がはいってレンダリングされる。英語などでは改行は単語間空白という取り扱いで問題ないのだが、日本語では格好悪いので 1段落のあいだ改行を入れないことが多い。pTeX はこのへんをうまくやってくれるので気にせず適当な文字数で改行をいれたほうがいい (エラーの際に行番号が表示されるので場所を特定しやすい)。 ↑
  2. 全体を <pre> で囲むだけでもブラウザでそれなりに見えるかもしれない。 ↑
  3. Docdiff には --format=html というオプションもある。変更点を HTML で美しく表示できるようにするものである。しかしその表示のためにたくさんのタグなどがはいるので、著者が校正結果を抽出するのにやや手間がかかる。 ↑
  4. defparentheses を【 】、defdelete を／、defcommentを＃と設定している場合。 ↑

タグ

, , , ]]> http://pasero.net/~mako/blog/s/67/feed 0 日本語スタイルガイド http://pasero.net/~mako/blog/s/66 http://pasero.net/~mako/blog/s/66#comments Thu, 22 Mar 2007 03:29:39 +0000 Mako http://pasero.net/~mako/blog/s/66 続きを読む →]]> Wiki 書式をやめて(簡略)HTML で書くようになったら、そのほうがむしろ書きたいように楽に書けることが判って、なんだという気がしている。

さてそうすると内容以外の、文章のスタイルについても気になってきた。それは何もここに書くときだけではない。自分のなかではこれまでの経験からある一定のルールというのが出来ているのだが、重要度 (自分にとっての) に応じてブレるものもある。

そこで文章のスタイルについてのガイドラインについて、検索してみた。Gnome.JP の Wiki を経由して、タイムリーにも出たばかりの What's Translation@Sun の 日本語スタイルガイド を発見した。元々の Sun 内部の指針を再編されたものということだ。英語から日本語への翻訳を前提に書かれているが、はじめから日本語の文章を書く場合にもよく当てはまる。いったん通読したら普段は クイックリファレンスを見るだけでも随分役に立ちそうだ。何しろ個人や小さなコミュニティではこのような明文化の作業はしない (できない) ので、たいへんありがたい。

自分のなかのルールといくつかの点で違いはある。たとえば感嘆符・疑問符は使わない、としている点。横書きの、特にブログのような場面では既に日本語の一部として使用可能だと思う。さらに、もし使う場合 (メッセージでは使うとされている) には日本語と疑問符のあいだにスペースを入れるとしている点も疑問に思う。そのほか漢字とかなの使い分けのなかにもいくつか自分の基準と違うものがある。

しかしそれらを除いて大部分はたいへん有益な内容である。カタカナ語の末尾の長音は、自分のなかでも場面ごとにブレが大きく気になっていたので、100% 同意できるかどうかは別として、大いに参考になった。元々が技術文書、マニュアルを対象として作られているので、それ以外にそのまま適用できないかもしれないが、参照資料のひとつとして活用したい。

タグ

, ]]> http://pasero.net/~mako/blog/s/66/feed 0