{デラング}{希哲15年5月の一日一文}{ルビ対応}{大枠}{ルビ記法整備}{一日一文}{デルン初期実装}{ルビ記法}{使いやすく}{思い入れ}...=}(43)

{日本語におけるルビの重要性について K#F85E/A-E74C-5DDE}

ここのところ取り組んでいたデラングルビ記法整備がようやく一段落した見本

実はこのルビ記法デルン初期実装からあったもので,月庭でも一時期よく使っていた。デラングではその仕様大枠を受け継ぎ,細部洗練させた。

今のデライトには他にも多くの課題があるが,それでもこのルビ記法への思い入れは強く,後回しに出来なかった。

ルビ日本語柔軟性を与えてくれるものだ。実験的用語導入などにあたっては,これが使えるかどうかは大きな問題になる。私の場合は言うまでもなく,希哲館訳語使いやすくしたい,という動機が強かった。

現状,HTML でも汎用的標記マークアップ言語でも,ルビはあまり重要視されていない。一部日本語サービス通類ツールの“独自記法”としては散見されるものの,冗長過ぎたり簡潔だが紛らわしかったり,どれも一長一短あり,集約される気配は無い。

デライトデラングルビ対応は,個人知識管理一般で使えるように自然簡潔かつ明示的であることを重視した,割と革新的なものだと思う。

よりよい日本語探求のため,これからもルビ最大限活用していきたい。

{希哲15年4月22日の日記}{投げ遣り}{翻訳語整備}{掲示板スクリプト}{過言ではない}{希哲館訳語の原点}{phpBB3 日本語パック}{間違いない}{デライトの RSS 対応}{一日一文}...=}(66)

{希哲館訳語の原点,サブスクと待っ読(まっとく) K#F85E/A-E74C-B90D}

先日,デライトでも RSS 対応をした。以下のように,任意の輪郭一覧RSS で「待っ読(まっとく)ことが出来る。

この「待っ読」,フィードにおける〈subscribe〉あるいは〈subscription〉翻訳語として昔考案したものだ。

今のようにデルンデライト)で何でもかんでも記録するようになる前だったので,正確な考案時期は忘れてしまったが,デルンが実用化した希哲6(2012)年より前だったことは間違いない。ただ,しばらくはの一つだったようで,希哲8(2014)年に改めて採用することを決めている〈subscribe〉を「待っ読」と訳す

今となっては希哲館訳語蓄積膨大なものとなったが,そのほとんどはデルン実用化後に出来たものだ。「待っ読」は独自性を持つ最古の希哲館訳語と言える。「希哲館訳語の原点」と言っても過言ではない


この「待っ読」,すでにお気付きかもしれないが「積ん読」にちなんだものだ。

そもそも〈subscribe〉翻訳語を考えるきっかけは,phpBB3 という掲示板スクリプト日本語パックを作りたいと思ったことだった。希哲館事業発足間もない希哲2(2008)年のことだ。

phpBB3 は,希哲館情報交換のために使える掲示板として当時は有力な選択肢だった。かねてより必要を感じていた翻訳語整備も兼ねていた。今はデライトがあるが,このデライトを実現するためにデルンの実用化を目指すことになり,この望事プロジェクト自体は立ち消えとなった。

その中にこの用語があったが,直訳の「購読」では明らかに不自然だった。散々考えた挙句,投げ遣り気味に「積ん読」と訳すことを考えたRSS フィード等の “Subscribe” は「積ん読 (つんどく)」か。これは流石に無理があったものの,しばらくして「待っ読」の元になったわけだ。


それから十数年経ち,〈subscription〉という概念は,サービスなどの定額制を意味する「サブスク」として広く認知されるようになった。

しかし,フィード等の〈subscribe〉をどう翻訳するか,という問題は当時から未解決のままだ。

デライトでは,利用者が出来るだけ自然に使えるように,希哲館訳語のほとんどをあえて採用していない。見慣れない翻訳語に気を取られて欲しくないので,多少のカタカナ語には目を瞑っている。

それにしても,「サブスクライブ」も「購読」も自然分かりやすいとは言えない。なら「待っ読」でいいんじゃないか,と採用することになった。

最も思い出深い翻訳語がここで復活してくれたことに,運命的なものを感じざるをえない。

=}
{年月日}{文化的独立性}{気持ち悪さ}{時代感}{一日一文}{最重要視}{希哲前1年}{希哲8年}{希哲零年}{希哲館事業発足}...=}(77)

{希哲紀元とは何か K#F85E/A-E74C-DC33}

私はよく「希哲〜年」と書いている。例えば今年2021年なら希哲15年となる。これは「希哲紀元」という希哲館独自の紀年法だ。希哲館事業発足2007年希哲元年とし,そこから希哲2年希哲3年と数えていく。

この希哲紀元を私的に使い始めたのが希哲8(2014)年頃だから,もう7年ほど経つ。


希哲館訳語からも分かる通り,希哲館では日本語最重要視している。日本語の力を活かして知識産業革命を成し遂げ,日本語を世界中に広めたいと思っている。

ところがここで一つの問題があった。日本語で使える普遍的かつ合理的紀年法が無かったのだ。

我々日本人元号に慣れているし,愛着を持つ人も多いだろうが,元号はあくまでも天皇権威由来するものであり,外国人に押し付けられるものではない。紀年法としての分かりやすさ犠牲にする代わりに時代感共有しやすいなどと言われるが,それも国内の問題に過ぎない。

それでも日本人は元号を使うんだ,と言えるほど元号にこだわりがあるのかと言えば,実態はそうでもない。西暦も当たり前のように使われており,面倒だから西暦だけにしてくれという人もまた多い。ではその西暦に問題が無いのかと言えば,キリスト教価値観に基く紀年法が中立なわけはない。

キリスト教徒の少ない日本で,元号を捨てて西暦だけを使うようになった日本人というのも奇妙だろう。かといって,元号のみを使うのも皇紀を使うのも現実的ではない。併用している現状が良いのかと言うと,やはり面倒なことが多々ある。

残念ながら,日本語現状として,気持ち良く使える紀年法は無い。この気持ち悪さに自分なりに決着を付けたかった。希哲紀元を使い始めた動機はそんなところだ。


希哲紀元を初めて見た人はぎょっとするだろうが,実は,一つ一つの理屈単純明快だ。馬鹿正直過ぎるくらいかもしれない。

希哲紀元が希哲館事業発足の年を元年とするのは,希哲館にとってそれ以上に独立性を示せる出来事が無いからだ。宗教や特定の文化に依存することを極力避け,どこかに始点を置かなければならない以上,希哲館は希哲館の始まりを元年とするほかない。まあ,「苦節云年」を難しく言ったものだと思ってもらってもいい。

希哲紀元には,文化的独立性を保つという意義に加え,これまでの紀年法の欠点克服しようという試みもある。

希哲紀元は元号風だがあくまでも「紀元」なので,西暦と同じように改元は無い。ただ,「希哲」には元号同様,新時代への思いが込められている。それは今後数十年ではなく,半永久的に続く時代の名前だ。

さらに,希哲紀元には元年の前に「零年」がある。その前が「前1年」だ。つまり,歴史上の全ての年を整数として扱うことが出来,計算しやすい。これは西暦にない利点だ。


元号にも西暦にも使用義務は無く,あくまでも文化の一つとして任意で使うものだ。当然ながら,希哲紀元も私個人や希哲館の内部で使っているもので,無理に使わせたいということもない。これが本当に合理的なものなら,自然に広まっていくだろう。

ただ一つ,希哲紀元を使い始めてから年月日を書くのが楽しくてしょうがない。

=}
{略語を使わない}{略さず}{共有しにくい}{一日一文}{略す}{略さない病}{JavaScript の beforebegin,afterbegin,beforeend,afterend に代わる要素位置記法}{デライト一日一文}{人工言語}{kbd 要素}...=}(112)

{交度英語のすすめ K#F85E/A-E74C-244F}

希哲館における珍奇語彙といえば「日本語史上最大の翻訳語体系」こと希哲館訳語ばかりが注目されがちだが,実は,もう一つそれに負けず劣らず珍奇な言語関連望事プロジェクトがある。それが「交度英語」(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 に代わる要素位置記法」などにはその片鱗が見えるかもしれない。

いずれ『希哲辞典』のように辞典として整えて公開することも考えているが,まずは考え方を紹介しておきたかった。

{希哲15年4月4日のツイスト}{希哲15年4月4日}{平解き}{ツイスト}{希哲館訳語}{凄い}{ヒアドキュメント}=}(7)
{希哲15年3月26日のツイスト}{希哲15年3月26日}{〈subscription〉}{ツイスト}{希哲館訳語}{最初期}{解放}{購読}{誤訳}{待っ読}=}(10)
{引き入れ}{輪括}{強い輪結}{りんかつ}{希哲14年3月28日}{輪結}{引括}{輪郭画表}{〈linkage〉}{輪郭法用語}...=}(16)

{輪括 K#F85E/A-5B28-ED9F}

リンクルージョンlinklusion)。

引き入れ操作によって作られる輪郭同士の関係。

希哲14年3月28日,「輪郭間の引き入れ関係」を表す語として考案,暫定的に採用していた「輪結」(linkage)に代わり採用を決めた。

希哲館訳語輪結」と「引括」(inclusion)のかばん語で,綴りは linclusion よりも link の意が分かりやすい〈linklusion〉を採用。

{開発者コミュニティ}{リスク低減}{費用削減}{困難さ}{隠すべきものを持たない強み}{希哲15年2月1日3歩}{きっとん}{素交非公開原則}{素交公開原則}{素交公開}...=}(89)

{希哲15年1月30日の日記 K#F85E/A-E74C-E10D}

日本の情技業界を騒がせている業務素交流出事件に思うところあり,希哲館でも原則として素交公開していく「素交公開原則」の採用本格的検討し始めた。

昨年の今頃もそんなことをぼんやりと考えていたが,特にこの頃,描出公開原則成功確信が持てるようになったり,政治参加方針公開が考えられるようになったり,「隠すべきものを持たない強み」を実感することが多くなっていた。となれば,素交公開自然流れだろう。

もともと虎哲関係の素交独自性が強過ぎ,動作環境備立方法も特殊文書込め言には独自用語と希哲館訳語満載という状態であり,盗んだところでまともに運用するのは不可能だ。これを「自然難読性」と呼び,ある種の強みと考えていた。

それでもいわば「素交非公開原則」で来た理由はいくつかある。

第一には,私自身の完璧主義的な性格であり,見せる必要もないところで不完全なものを晒したくなかった。

次に,希哲館事業収益化不可能に近い困難さがあった。万が一にもなさそうだった成功可能性を探る上で,万が一でもその障害になりそうな要素排除しなくてはならなかった。手札は一つでも多い方が良かった。

これについては,デライト収益化実現してしまえば無用心配になる。

もう一つ,技術的問題もある。昔から,デルン基礎にした版存管理司組構想してきたこともあり,素交公開するなら独自基盤でと考えていた。無論,そんなものを開発する時間は無かった。

色々な意味で余裕が必要になるので,いずれにせよデライト収益化後に決断することになるだろう。

素交公開原則利点はいくつも考えられる。献典としては死蔵してきた希哲館技術体系宣伝デライトも含めた希哲館事業全体の透明性信頼性向上機密保持に関する費用削減リスク低減,そして最も大きいのは開発者コミュニティを作れることだろう。

KitHub」というのは一昨年思いついたことだが,それこそ GitHub のように成長すればそれだけで希哲館事業の強力な武器になる。

この日は久しぶりに希哲館マスコット構想「きっとん」を思い出し,具体的なイメージを練ったりもした。これがのらくろに似ていることに気付いたのは収穫だった。

2月1日振り返り日記

{希哲館訳語}
{}