(9)(525){日本語におけるルビの重要性について}{希哲館訳語の原点，サブスクと待っ読（まっとく）}{希哲館訳語の原点}{希哲紀元とは何か}{交度英語のすすめ}{あれ}{あれ}{通注}{輪括}{希哲15年1月30日の日記}...(43)ここのところ取り組んでいたデラングのルビ記法整備がようやく一段落した（見本）。
実はこのルビ記法，デルン初期実装からあったもので，月庭でも一時期よく使っていた。デラングではその仕様の大枠を受け継ぎ，細部を洗練させた。
今のデライトには他にも多くの課題があるが，それでもこのルビ記法への思い入れは強く，後回しに出来なかった。
ルビは日本語に柔軟性を与えてくれるものだ。実験的な用語の導入などにあたっては，これが使えるかどうかは大きな問題になる。私の場合は言うまでもなく，希哲館訳語を使いやすくしたい，という動機が強かった。
現状，HTML でも汎用的な軽標記言語でも，ルビはあまり重要視されていない。一部日本語サービスや通類の“独自記法”としては散見されるものの，冗長過ぎたり簡潔だが紛らわしかったり，どれも一長一短あり，集約される気配は無い。
デライト・デラングのルビ対応は，個人知識管理一般で使えるように自然・簡潔かつ明示的であることを重視した，割と革新的なものだと思う。
(66)先日，デライトでも RSS 対応をした。以下のように，任意の輪郭一覧を RSS で「待っ読」（まっとく）ことが出来る。
この「待っ読」，フィードにおける〈subscribe〉あるいは〈subscription〉の翻訳語として昔考案したものだ。
今のようにデルン（デライト）で何でもかんでも記録するようになる前だったので，正確な考案時期は忘れてしまったが，デルンが実用化した希哲6（2012）年より前だったことは間違いない。ただ，しばらくは案の一つだったようで，希哲8（2014）年に改めて採用することを決めている（〈subscribe〉を「待っ読」と訳す）。
今となっては希哲館訳語の蓄積も膨大なものとなったが，そのほとんどはデルン実用化後に出来たものだ。「待っ読」は独自性を持つ最古の希哲館訳語と言える。「希哲館訳語の原点」と言っても過言ではない。
この「待っ読」，すでにお気付きかもしれないが「積ん読」にちなんだものだ。
そもそも〈subscribe〉の翻訳語を考えるきっかけは，phpBB3 という掲示板スクリプトの日本語パックを作りたいと思ったことだった。希哲館事業発足間もない希哲2（2008）年のことだ。
phpBB3 は，希哲館で情報交換のために使える掲示板として当時は有力な選択肢だった。かねてより必要を感じていた翻訳語整備も兼ねていた。今はデライトがあるが，このデライトを実現するためにデルンの実用化を目指すことになり，この望事自体は立ち消えとなった。
その中にこの用語があったが，直訳の「購読」では明らかに不自然だった。散々考えた挙句，投げ遣り気味に「積ん読」と訳すことを考えた（RSS フィード等の “Subscribe” は「積ん読 (つんどく)」か）。これは流石に無理があったものの，しばらくして「待っ読」の元になったわけだ。
それから十数年経ち，〈subscription〉という概念は，サービスなどの定額制を意味する「サブスク」として広く認知されるようになった。
しかし，フィード等の〈subscribe〉をどう翻訳するか，という問題は当時から未解決のままだ。
デライトでは，利用者が出来るだけ自然に使えるように，希哲館訳語のほとんどをあえて採用していない。見慣れない翻訳語に気を取られて欲しくないので，多少のカタカナ語には目を瞑っている。
それにしても，「サブスクライブ」も「購読」も自然で分かりやすいとは言えない。なら「待っ読」でいいんじゃないか，と採用することになった。
(77)私はよく「希哲〜年」と書いている。例えば今年（2021年）なら希哲15年となる。これは「希哲紀元」という希哲館独自の紀年法だ。希哲館事業発足の2007年を希哲元年とし，そこから希哲2年，希哲3年と数えていく。
この希哲紀元を私的に使い始めたのが希哲8（2014）年頃だから，もう7年ほど経つ。
希哲館訳語からも分かる通り，希哲館では日本語を最重要視している。日本語の力を活かして知識産業革命を成し遂げ，日本語を世界中に広めたいと思っている。
ところがここで一つの問題があった。日本語で使える普遍的かつ合理的な紀年法が無かったのだ。
我々日本人は元号に慣れているし，愛着を持つ人も多いだろうが，元号はあくまでも天皇の権威に由来するものであり，外国人に押し付けられるものではない。紀年法としての分かりやすさを犠牲にする代わりに時代感を共有しやすいなどと言われるが，それも国内の問題に過ぎない。
それでも日本人は元号を使うんだ，と言えるほど元号にこだわりがあるのかと言えば，実態はそうでもない。西暦も当たり前のように使われており，面倒だから西暦だけにしてくれという人もまた多い。ではその西暦に問題が無いのかと言えば，キリスト教の価値観に基く紀年法が中立なわけはない。
キリスト教徒の少ない日本で，元号を捨てて西暦だけを使うようになった日本人というのも奇妙だろう。かといって，元号のみを使うのも皇紀を使うのも現実的ではない。併用している現状が良いのかと言うと，やはり面倒なことが多々ある。
残念ながら，日本語の現状として，気持ち良く使える紀年法は無い。この気持ち悪さに自分なりに決着を付けたかった。希哲紀元を使い始めた動機はそんなところだ。
希哲紀元を初めて見た人はぎょっとするだろうが，実は，一つ一つの理屈は単純明快だ。馬鹿正直過ぎるくらいかもしれない。
希哲紀元が希哲館事業発足の年を元年とするのは，希哲館にとってそれ以上に独立性を示せる出来事が無いからだ。宗教や特定の文化に依存することを極力避け，どこかに始点を置かなければならない以上，希哲館は希哲館の始まりを元年とするほかない。まあ，「苦節云年」を難しく言ったものだと思ってもらってもいい。
希哲紀元には，文化的独立性を保つという意義に加え，これまでの紀年法の欠点を克服しようという試みもある。
希哲紀元は元号風だがあくまでも「紀元」なので，西暦と同じように改元は無い。ただ，「希哲」には元号同様，新時代への思いが込められている。それは今後数十年ではなく，半永久的に続く時代の名前だ。
さらに，希哲紀元には元年の前に「零年」がある。その前が「前1年」だ。つまり，歴史上の全ての年を整数として扱うことが出来，計算しやすい。これは西暦にない利点だ。
元号にも西暦にも使用義務は無く，あくまでも文化の一つとして任意で使うものだ。当然ながら，希哲紀元も私個人や希哲館の内部で使っているもので，無理に使わせたいということもない。これが本当に合理的なものなら，自然に広まっていくだろう。
(112)希哲館における珍奇な語彙といえば「日本語史上最大の翻訳語体系」こと希哲館訳語ばかりが注目されがちだが，実は，もう一つそれに負けず劣らず珍奇な言語関連望事がある。それが「交度英語」（Code English），略して「交語」（Codish）だ。
これは主に希哲館情報技術体系で利用しているもので，簡単に言えば，「英語を勘報機向けに簡略化した人工言語」だ。
勘報の世界では，技術者であれば誰でも理解出来るような略語というものが多数存在する。例えば，std は〈standard〉，int は〈integer〉，str は〈string〉……といった具合だ。多くは「歴史的経緯」で定着したものだ。
一方で，こうした略語の使用を避けるという文化も優勢になっている。その主な理由は，「共有しにくい」からだ。特に新しい論組言語では，英語を略さずに使う傾向があるため，妙に冗長な交度が増えた。
はっきり言おう。私は，これが非常に馬鹿げた考え方，いわば「略さない病」であると思っている。この病気によって世界から失われた効率性を金額に換算すれば天文学的なものになるに違いない。
よく考えてもみてほしい。略語というのは，どんな専門分野でも記録や情報交換の効率化のために自然発生するものだ。数学の一見意味不明な略語・記法は，数学者が本質的な仕事に専念するために編み出したものだろう。日夜神経を磨り減らして交度と向き合う情報技術者がそれを封じるのは，狂気の沙汰と言ってもいい。
実際のところ，「略語を使わない」ルールが徹底されているかというと，そうではない。例えば，String str; なんて記述は世の中に溢れかえっている。C++ には shared_ptr（pointer），Java には println()（line）なんてものがある。「モダン」なはずの HTML5 にも img（image）やら kbd（keyboard）やら残っている。こうした混在が当たり前になっているのが現状だ。なぜなら，「略語を使わない」というのは本来不自然なこと，無理のあることだからだ。
長い方に合わせるのは無理なのだから，短い方に合わせればいい。共有しにくいなら，「略語を使わない」のではなく，「略語の辞書を作る」ことを考えればいい。頻繁に使うものなら人間は慣れる。これがつまり，交度英語の考え方だ。
交度英語では，すでに定着している英略語を基礎に，実践を通じて新しい略語を提案，問題があれば修正しながら語彙を作り上げていく。
具体的には，論組をしながら，どう略せばいいのか分からない英単語にあたった時，私はまず適当に略してみて，それをデライトで検索する。他に前例があればそれと突き合わせて修正することもあるし，無ければどういう意図で使ったかを描き出していく。これを繰り返すことで，デライトが自然と辞書の役割を果し，妥当な略語の使い方に導いてくれるようになる。
これは基本的に希哲館訳語で行っていることと同じであり，デルン／デライトがはじめて可能にしたことでもあるのだろう。
希哲館ではまだ素交の公開などはしていないので，交度英語を使った交度の実例としてすぐに見せられるものは少ないが，最近書いた「JavaScript の beforebegin，afterbegin，beforeend，afterend に代わる要素位置記法」などにはその片鱗が見えるかもしれない。
(10)(16)
引き入れ操作によって作られる輪郭同士の関係。
希哲14年3月28日，「輪郭間の引き入れ関係」を表す語として考案，暫定的に採用していた「輪結」（linkage）に代わり採用を決めた。
希哲館訳語「輪結」と「引括」（inclusion）のかばん語で，綴りは linclusion よりも link の意が分かりやすい〈linklusion〉を採用。
(89)日本の情技業界を騒がせている業務素交流出事件に思うところあり，希哲館でも原則として素交を公開していく「素交公開原則」の採用を本格的に検討し始めた。
昨年の今頃もそんなことをぼんやりと考えていたが，特にこの頃，描出公開原則の成功に確信が持てるようになったり，政治参加方針の公開が考えられるようになったり，「隠すべきものを持たない強み」を実感することが多くなっていた。となれば，素交公開も自然の流れだろう。
もともと虎哲関係の素交は独自性が強過ぎ，動作環境も備立方法も特殊，文書や込め言には独自用語と希哲館訳語が満載という状態であり，盗んだところでまともに運用するのは不可能だ。これを「自然難読性」と呼び，ある種の強みと考えていた。
第一には，私自身の完璧主義的な性格であり，見せる必要もないところで不完全なものを晒したくなかった。
次に，希哲館事業収益化の不可能に近い困難さがあった。万が一にもなさそうだった成功の可能性を探る上で，万が一でもその障害になりそうな要素は排除しなくてはならなかった。手札は一つでも多い方が良かった。
これについては，デライト収益化が実現してしまえば無用の心配になる。
もう一つ，技術的な問題もある。昔から，デルンを基礎にした版存管理司組を構想してきたこともあり，素交公開するなら独自の基盤でと考えていた。無論，そんなものを開発する時間は無かった。
色々な意味で余裕が必要になるので，いずれにせよデライト収益化後に決断することになるだろう。
素交公開原則の利点はいくつも考えられる。献典としては死蔵してきた希哲館技術体系の宣伝，デライトも含めた希哲館事業全体の透明性・信頼性の向上，機密保持に関する費用削減とリスク低減，そして最も大きいのは開発者コミュニティを作れることだろう。
「KitHub」というのは一昨年思いついたことだが，それこそ GitHub のように成長すればそれだけで希哲館事業の強力な武器になる。
この日は久しぶりに希哲館のマスコット構想「きっとん」を思い出し，具体的なイメージを練ったりもした。これがのらくろに似ていることに気付いたのは収穫だった。
