「まきせくりす」から牧瀬紅莉栖の「莉」を探すのに難儀せずにもってくる賢いAIだったり、
覇王翔吼拳の「吼」をいきなりピンポイントでひねり出すことができるウルトラC的なインターフェイスの提案である「[の][の]代表変換」。
いわゆる単漢字変換でこのようなスノッブな漢字へのアクセスを容易にするという(うまくいけば？)画期的なシステムでありますが、
潜在ニーズをキッチリとらえていけるのかは未知数ではあるものの漢字変換の常識に新しい風を吹き込むようないい提案になっているかと思います。
この機能においてちょっと不思議なのは賽子さいころとか蝸牛かたつむりとか難読のものはあるけれどそういったのはあまり重要ではない、ということです。
「賽」とか「蝸」を単漢字でいざ出そうとするとそれはそれで大変なのですがこれらの漢字が他の全く別の語の中に断片的に入っているという場面というのはあまり想像ができないので単純に難しい漢字を出したいという風に捉えられてしまうのは完全な誤解であります。
むしろその本領を発揮するのは「島津亜矢」(演歌歌手)の「亜矢」が出したいとかであるとか「とうとい」の「尊」が出したいとか日常に潜むちょっとした手の届く範囲で同音語に埋もれていそうな漢字を引っ張り出していくところにあります。
「違うよ！こっちの方の亜矢だよ！」というからには同音の別の変換候補が多数あって、それらから目的の語をズバリ指し示す「こっち」という具体例がすぐに挙げられる場合にまさに必要とされる機能であります。
勢いついでに単漢字といっておきながらいきなり「亜矢」という二文字の語を出してしまいましたが人名は苗字+名前なので「しょうじさだお」で「東海林」を出すという苗字の方を出したいという逆パターンもあります。
しかし無秩序に二文字以上のパーツへの変換を認めてしまうと「偕老同穴」を代表変換したいときに「偕老」(かいろう)なのか「偕」だけ出したいのか解釈が分かれてしまうという問題が起きてしまいます。
それに二文字の場合も考慮しなくてはならないとすると、さしもの「代表漢字選考プロセスAI」といえど処理負荷が増加して適切に提示することが困難になってしまうことも考えられるのでここは許容するケースを絞って適用していきたいところです。
今のところこれにはハッキリと固まっている方針というものがまだ決まっておりませんが思いつく範囲で基準を探ってみたいと思います。
例えば「地球周回軌道」の「しゅうかい(周回)」は同音異義語も多く二文字で切り出すことも妥当かと思われますが集会の場合は「集会をする」と格助詞の「を」を伴って使われるのが自然ですし周回の場合は「周回する」と助詞を伴わないサ変動詞としての形態が特徴的で何も代表変換で呼び出したりせずとも前後周辺の文字列を見ればある程度は推測のつく旗色となっています。
また動詞としてではなく何かの複合語の一部として使われている場合でも周回のつく複合語は「周回チェック」「周回積分」「周回遅れ」ぐらいのものでこれさえ登録しておけばそれほど悩ましい需要もなさそうです。
ただし「京葉線」の「けいよう(京葉)」としてピックアップする場合には複合語で「京葉格安住宅」みたいに連接可能性もそこそこありそうですからこういうのは出せるようにしたいですし文字数も「京葉」の二文字でなければ意味がありません。
また四字熟語では「けんこんいってき(乾坤一擲)」のリードで「いってき(一擲)」を出そうにもそれほど意味はなさそうでこの四字熟語の場合にはむしろ第一候補で「擲」を、第二候補で「坤」を、それぞれ別々の単漢字が出せる構えにした方が好都合です。
なにぶん検討不足で確かなことは言えないのですが以上の傾向を考慮して二文字以上の代表変換は少し範囲を縮小して人名・地名・組織名・公共物・公官庁・サービス名・作品名・料理/生活関連固有物あるいは固有名詞に限って、
しかも一文字だけで有力候補がある場合はそちらの単漢字を優先にして…という条件付きで代表変換のリードワードに適用するものとします。
なお「投資する」の「投資」を出すような複漢字サ変動詞は「する」まで含めて、「抹香臭い」の「抹香」を出すような複漢字形容詞については完全末尾部分まで含めてリードにできるものとします。
こういったサ変動詞は主に2文字の漢語複合物であると同時にこの2文字のカタマリ一単位をもって断片配列されていくという経験的法則があります。
他では「大過ない」「如才ない」のように「たいか」「じょさい」ひとかたまりで処理した方が他の同音語ライバルと峻別できそうな形容詞(特に<漢語2文字>+<補助形容詞・軽形容詞>の形のもの)も多く見られます。
さらに「不興げ」のように接尾辞「げ」と結びついていることで形状性名詞部分を強調できて「不況」や「布教」と区別が明確になる例もありますし、「勇壮さ」のような形で「郵送」と見分けがつきやすくなる例も同様です。こちらも漢語2文字で一単位と考えユニット対応していくのも便宜が通っているのでこういうケースでは許容されるべきかと思います。
そういった取り決めですので、四字熟語や把握不可能な複合語、観念語、抽象語の類は避け、たとえ有名な作品名であったとしても「善徳女王」の「善徳」で二文字を抜き出したいんだ、という要望をぐっと抑えてこれらは単漢字のみへの代表変換対応としたいと思います。
多少物足りないところもありますが、基本は単漢字(あるいは機能ユニット)という指針を確立した方が機能としてもスッキリしてわかりやすいというものですのでどうぞご理解ください。
それと前回の記事の補足で前後いたしますが、代表漢字選考プロセスでの絞り込み要件の言及漏れとして
かくりょう 書く量のような装定形バリエーションは外す(○：閣僚の「閣」)
こいくち 濃い口のような装定形バリエーションは外す(○：鯉口の「鯉」)
という項目も加えておきたいかと思います。
さて、ここまでの単漢字変換だけでは対処できない文字の並びとして
・サ高住(サービス付き高齢者向け住宅)：さこうじゅう
・グ浣(グリセリン浣腸)：ぐかん
・日サ協(日本サイン協会)：にっさきょう
・パ長(コンパ長)：ぱちょう
のようなカナ・漢字混成略語のような例があります。
もちろん「日サ協」のような場合は「日」「サ」「協」出たもの順で選択確定していけばできないこともないのですが部分的逐次的煩雑さがあるのは否めません。
また他の「頭文字カナ+漢字」の場合は[の][の]代表変換では直前文字列の遡りで文字検知をしている関係上、カナ部分も含んで遡ってしまい提示候補に混乱をもたらしてしまうケースもあり参照範囲がハッキリしないという難点があります。
そこで「これから漢字変換すべき対象文字列の捕捉動作」というものをあらかじめ組み込んでおいてその後の単漢字代表リード文字列を複数回順次入力していって渦中の捕捉文字列(これは全ひらがなの読みだけの見出しのようなもの)に当てはめられる代表漢字を検知するごとに順序良く相当部分に漢字を変換していくというプロセスを経て複合語・略語の類を形成していくというインターフェイスを新たに提案したいと思います。
ちょっと説明だけではパッと呑み込めないと思いますので先程の「サ高住」の例でどのように入力していくか詳しく追ってみますと、
まず文を打ち込んでいるうちに「さこうじゅう」という言葉が出てきたとします。このときはまだ未変換文字列なので選択・確定する前に「今タイプした単語は多分変換できないだろうからこれから特別な変換操作を行うから準備してね」とコンピュータに伝達することを示すために、5月の過去記事で定めた「新別口入力を含む空き未定義キー①②③の３つのうち②のキー」を新たに「単語登録ワンタッチキー」として定義し、これをあらかじめ押しておいてから
代表変換と同じ要領でリード「たかい」→「高」が、見出し「こう」の部分に当てはめられ、続くリード「すむ」→「住」が見出し「じゅう」の読み部分に当てはめられていくという動作を考えてみました。
見出しというのは「さこうじゅう」というこれから変換したい言葉のべたかな文字列の事です。リードというのは「連想基片」とでも訳しておきましょうか…代表変換で単漢字を出すために投げかけるヒントワードの事です(「たかい」のヒントで代表漢字「高」を出す仕組み)。
見出し部分は主に音読みの構成音が並んでいる場合が多いと思われ、逆にリードでは音でも訓でも代表漢字を導きやすいものならどちらでも使われていくという傾向があります。
ここで話を戻すと「サ高住」の「高」と「住」は順次リードが入力された段階でそれぞれ「たかい[の][の]」で「高」が部分確定し、「すむ→[の][の]」で「住」が部分確定するとういう動作を想定しています。
このとき「サ高住」の「サ」は結局[の][の]変換でそれらしいリードを検知できなかったのでスルーされ、後続の「高」「住」が順次確定していったので出番がなく終わるということです。
なので「サ」の部分は非漢字=ひらがなかカタカナの単文字になるというのがわかるのですが、傾向的に略語の類はカタカナ要素が優勢であるかと思われるのでデフォルトはカタカナで変換される(見出し相当の漢字変換が完了した段階で最後に「サ」が確定する)ように設定しておくのがよいでしょう。
ここで重要なのは一度漢字になれるチャンスを過ぎてしまったものは(サ)他の「高」「住」が後から継ぎ継ぎ決定されていく最中にあってもう一度「去る」などの「さ」で漢字になれそうなリードがやっと出てきたとしても、もうすでに「高」「住」が決定した後となってはさかのぼって漢字が当てはめられるということはできない、ということです。
あて込みは順次不可逆の原則でお願いいたします。
ここで未定義キーとしていた②のキーの配置を示すために図で今一度確認して頂きたいと思います↓。
<図１：未定義キー②は登録ワンタッチキーとして盤面右側に配置>
<図２：トランス音訓変換orパズルのピースをはめる変換 の操作流れ図>
前記事の代表変換/棚卸し変換の考えを一歩進めて、もっと多様な複合語にも対応できるようオペレーションを拡張したものであるとご理解いただけるかと思います。
「対象文字列の捕捉動作」があるおかげで何を変換すべきか前もって分かったうえで変換できるのがこの変換の強みであります。
もっと厳密にいうと、捕捉動作発動は後置マーキングですので、「でにをは」などの助詞や「て・し・Ø文字マーカー」などの別口入力を挟んでいれば捕捉チャンクもセパレートに取り出せるというものですが、
・しかし確変度の期待感が薄い しかしかくへんどの…
・至極ウサ饅頭(うさまんじゅう・造語)が食べたい しごくうさまんじゅう…
・ウチばかり曲イタチ(くせいたち・造語)だらけだ ばかりくせいたち…
・反日より用日だ よりようにちだ…
などのように接続詞部分や副詞部分と捕捉ワードの境界が溶け込んでしまって解釈不全をおこしかねない例もありますし、
(×歯科資格辺土の--のような誤変換)や
(×死語空佐饅頭--のような誤変換)もなくはないです。
さらには
(×ウチ馬鹿陸生達--のような誤変換)のような「ばかり」(三文字副助詞)の捕捉間違えや
(×半日よ利用二値だ--のような誤変換)のような「より」(三文字格助詞)の捕捉間違えもケースによってはあるかもしれません。
とにかく単文字の別口入力がセパレーターとしてはたらいていない場合は捕捉境界に曖昧さが残ります。もちろん単純に長々複合した造語もあるでしょう。
これを防ぐためには無文字のセパレーターとして使えるØ文字マーカーを予防線的に配置しておくのもひとつの手です。
あとは「より・から・ばかり・まで・こそ」などの複文字助詞は適切な構文解析によって主題名詞なり構文中の補語なりとの機能上の違いを検出してうまく分異化できるのを期待するしかありません。
このあたりはまだハッキリしたことが確定していなくて幾分宙に浮いたような感じではありますが、このまま話を続けます。
複合語・造語・略語はとにかく多様な構成要素スタイルがあってそれらの全てを網羅することはできませんが、パッと収集した変換例になりそうなものでは、以下のものが挙げられると思います。
・ごち肉フェス(初回変換のときには御血肉と出て面喰いました)
・住まいる情報館
・うつ転
・彩響菊花火
・絶許
・とん食っ食
まず「ごちにくふぇす」ではリードに「肉」とだけはめ込んでいってそのままそこだけ漢字に変換できればよいかと思います。
大事なのは「フェス」部分をスルーしたまま当該見出し部分を「閉じる動作」です。適切に閉じないとどのタイミングで変換完了させるのかわかりません。
これは「ごち肉フェス目当てで…」などと続いていくようなときに捕捉範囲に順次漢字をあて込んでいく動作の継続をいったん終了させなければ見出し部分の受け入れがあふれてしまいます。
これが[が]や[の]など別口入力で新たにマーカーされたときやスペース・句読点・改行などで切れ目だと判断してよいところではこの新変換の動作は自動的に解消させるようにしていけばよいのですが、
何か適当なマーカーをはさまなかったときはそこで[通常変換]のキーを押してそこまでの変換進行を一度清算(？)しておく必要があるでしょう。
あるいはまだ長く続く複合語の一部だというのなら、[Ø文字マーカー]を適宜配置していくようにしておくべきです。
…このような調子で変換していけば何とか取り仕切りの道が見えてきそうな気がしますが、
続く「すまいるじょうほうかん」では見出し「す」の部分に「住む」の語幹部分の音「す：住」が充てこまれます。このように単体で「す」だけをあて込もうとすると普通は「酢」や「素」など計り知れない数の同音語に埋もれてしまうところですが、リードの代表変換で「すむ」と指定されているので「す」で「住」の単漢字が送りがなカットの状態でズバリもってこれるのは非常によくできていると思います。
その後の「じょうほうかん」の部分はスルーできないので閉じなければいけませんが最初の見出しで「すまいるじょうほうかん」とタイプしたのち「すむ」→住 のあて込みを挟んでまた漢字部分の「じょうほうかん」をあて込ませるために入力せねばならないのは二度手間で面倒なのですがこれは単語登録作業も兼ねているので読みと表記のデータを完成させるために我慢していただきたいところであります。
その際、「じょうほうかん」のところで閉じるために[通常変換]を押さなければなりませんがこのとき見出しの「じょうほうかん」とリードの「じょうほうかん」の入力が重複しているのを受けて、この部分は漢字変換しておこうと気を利かせてくれるようなふるまいをプログラムしておくことが重要です。
提示漢字が思っているものと違うときは順次連続で[通常変換]を押していけばよいですし、このときのキー動作は「捕捉を閉じる動作」をおこなうのと「リード重複部分の漢字変換のタスク」を同時に兼ねている機能であると理解していただきたいと思います。
「うつてん」については通常の仕方で入力すると「打つ点」が妥当な変換結果だと思いますが、この新変換では「転」だけ漢字にしたいのであってその前にある「うつ」はリードで触れない場合は基本カタカナですからこのままだと「ウツ転」という表記が第一候補に出てしまうと思われます。
「転」についてはリードで「ころぶ」と訓からアクセスした方が最短距離ですし問題はなさそうなのですが「ウツ」とカタカナになってしまうのはちょっとモヤモヤしてしまいます。
この点については解決方法として[通常変換]を押した後に盤面中央にある「かな」キーを押せば「ウツ」の部分だけそっくりそのまま「うつ」に訂正することができます。「転」の部分は漢字のままです。特にカーソル移動で作用範囲を指定するといったこともありません。
これについてはこのブログではお馴染みのカナ変換時の漢字部分無干渉変換の考え方とほぼ同じ仕組みであります。
思い出しのため説明しますと三属性変換で「げーじつてき」を属性ハ(接尾辞つきワード)で変換させるとこれは未知語なため一旦「げーじつ的」と変換されますがこれを「ゲージツ的」と「的」を漢字で残したままそれ以外をカタカナで変換させたいときに接辞の「的」には一切影響をあたえずに[カナ]キーを押すだけで「げーじつ」の部分だけそっくりカナ表記に訂正するという機能のことです。
今回の「うつ転」の場合も「転」がリード入力で漢字に変換されたことを踏まえてその後の[かな]キー操作の際にはこの漢字部分「転」は「不変部分」で「無干渉に作用させるもの」として扱うという意味において、先程の「的」が接尾語として部分Fixオペレーションを済ませていることを酌んだ処理とも全く符合するものであります。
ひと手間掛かりますが、後付けで軌道修正できるので幅広く応用できる操作だと思いますし、何より変換対象範囲の伸ばし・縮め操作が一切不要で流れのままで[かな]キーを一つ押すだけで解決するのがいいところです。
そして「さいきょうぎく」については「さい」は「いろどり」の「彩」をはめて「きょう」は「ひびき」の「響」をあてるところまでは順当ですが、最後の「ぎく」をあてるときに濁らない素の「きく」から「ぎく」の音の見出しへ解釈できるような細かいチューニングが必要になってきます。
これは「ずり」に対して「刷る(刷)」をあてるような動詞連用形などのときにも同様に濁りを酌んで変換させるような配慮が求められるのと同じ図式です。このへんは見出し・リード共に連用形でそろえた方が一見良さそうですがやはり連用形は他の名詞と混同しやすくなってしまうのでリードの方だけはU段で終止感の出ている基本形(終止形)で引っ張っていた方が安心だと思います。
続く「ぜつゆる」もネットスラングではありますが「絶対」が「ぜっ」と発音するにもかかわらず見出しの「ぜつ」にうまくはめ込まれるようにここでも微妙な変換のチューニングが求められるところです。
「許」の部分に関しても通常では「ゆるす」と終止形で出すものではありますが、ここでは「ゆるさない」と否定形で入力してもアリ、なように柔軟に解釈してほしいところです。
ここのところは先程の「濁音化構成音でも原形から解釈する処置」の件とともに「促音化しない原形のままの構成音のときでもうまく当て込む処置」が表記の勘所として注意しこれらには着実に対応していきたいと思います。
最後に「とんくっく」の読み見出しでは「くう」ではなく「たべる」から「食」を出す代表提示の際に、「くう=食う=食べる」と異なる訓の同一性を認識して「く」の部分にあて込むようなインターフェイスはちょっと複雑ながらもぜひ実現してほしいものです。
さきほどの「住まいる情報館」の例の「す」あて込みと考え方は同じですが、異なる訓も乗り越えて解釈させるという点においてこちらはもう一段手間のかかるものとなっておりますが決して無理な注文ではないと思いますのでどうか助力いただきたい次第であります。
これで綺麗にシメたいところだったのですが、ここで「焼肉 ばぁ場」という店名が目に入ってきてしまいました。
これは「ばしょ」で「場」を出せるのは容易に思い至りますが、最初の「ばぁ」をあて込まずにスルーして末尾の「ば」だけを漢字にしたいということでそのとり捌きがいやはやなんともお手上げな状態となってしまいます。
同音が複数ある例では一の太刀、二の太刀で漢字化が一致しない使い分けも確かに存在しそうですし先行要素が非漢字、なおかつ同音の後行要素こちらは漢字に、などということは想定外でしたのでここへ来てから思わぬ弱点を露呈させてしまうという一例になってしまいました。
これについては紙面も足りなくなってきそうですので(というかまだ解決法が思いつかない)、今後の考察でのちのち検討していく事にしたいと思います。
…以上、長々と論じてきましたがこの新変換の名称もまだ決まっておりません。
説明中でチラッと出てはきましたが自分的には「トランス音訓変換」か「パズルのピースをはめる変換」と、ちょっとケッタイな名称を検討しています。
「トランス音訓変換」というのは「さい」を変換するのに「ふたたび」のリードをあてて漢字の「再」を出すといった風に、「さい」「ふたたび」という音・訓両方の決定要因を飲み込んでいるところが音訓横断的で単に音読みの語/訓読みの語だけもってしてを[読み→変換漢字]と単一に紐づけしているのではなくて、
もっと複眼的に「見出しの文字列(ひらがなの読み)」-「漢字構成物の部分部分(漢字：だいたいは音が多い)」-「部分単漢字の代表引き出し(連想リード：音でも訓でも)」
の3つの決定要因、つまり3項参照によって音訓を自在に行き来しながら変換していくプロセスをざっくり言い表す言葉として「トランス音訓変換」と名付けました。
いわば「トランス音訓データのフル活用」を謳ったものであり、従来の単語辞書では読みと単語のその場限りの対応紐づけに留まっているのは実にもったいないのではないか、ひとつの漢字というものが音読みも訓読みも併呑して立体的な複合体になっているのだというありかたを存分に利用しようではないかという野心的な試みでもあります。
もう一つのネーミングは「パズルのピースをはめる変換」、とちょっと比喩的な表現となっておりますがこれ以上ないほど[対象文字列の捕捉動作]から[単漢字それぞれのパーツを代表変換であて込む]プロセスまでが一連のジグソーパズルのようでもあることを如実に表したネーミングはこの他には考えられません。
先程の「トランス音訓変換」では常に音読み訓読みを行き交っているかのようなイメージをあたえますが、実際には音だけ、訓だけで完結する素直(？)な例も十分あり得ますのでこちらのような限定感を与えない実態に沿ったネーミングも捨てがたいところです。
いずれにしてもこのコンセプト自体まだまだ掘り下げが足りないと思っておりますので、今後の議論・考察の過程の中から相応しい名称を決めていければよいかと思います。
肝心の②番の新・ワンタッチ登録キーを具体的にどう機能させて流れの中にどう位置付けていくのかについても少ししか触れていませんでしたので(実は自分自身まだよくわかっていません)こちらもいずれということで継続していきたいと思いますのでどうかお待ちください。
さてこの他にも熟字訓の場合はどうするのか、音訓のほかに簡単な英単語(カタカナで)を漢字に対応させてみるのはどうか、などまだまだ検討事項は沢山ありますのですが今回はここまでにして
今後の内容がひとまとめになる程度まで試行錯誤しつつ、このトピックの追記事がいつになるのかはわかりませんがじっくりと練り込んでいきたいかと思います。
連日の長文記事に付き合っていただき通読胃もたれをおこしてしまった読者の方もいらっしゃるのではないかと心配しておりますが次回はちょっと軽い記事にしたいと思いますのでよろしくお願いいたします。
[2021.6.3 補足追加]
この記事のキモは入力文の音素情報のみから変換文をひねり出すということではなくて(1対1対応)、
読み情報、音読み可能性、訓読み可能性の3項参照で適切な変換文を生成するということ(いわば3項のすりあわせ)であります。
論点も散漫でちょっと読みづらい長文になってしまいました。
の記事のほうがレイター記事になっており、より要領を得た説明になっているかと思いますので
よければそちらのほうをご覧になって下さい。
名称は未定ですが、漢字変換まわりのインターフェイスであたためているアイデアがちょこちょこあります。
たとえばこんなのがあります。
「香薫あらびきポーク」という商品名をタイプしたいときに、「香薫」というワードが初回入力時にはどの字をあてて良いかわからないため、香りという字を出してから「り」を削り、薫風という字を出してから「風」を削り…といった調子で煩雑でややこしい入力になっていました。
そこでちょっと特殊な操作なんですが、別口入力の[の]を2回連続で[の][の]のように打ち込むとその直前のワードのすぐ思いつく漢字を"代表"変換して単漢字で出すというものです。
ちょっと分かりにくいので説明しますと、「香薫」とタイプで出したいときに
かおり[の][の]、と打ち込むと送り仮名のない「香」が単漢字で変換候補筆頭にあがり、([]は別口入力)
くんぷう[の][の]、と打ち込むと「薫風」のうち代表的な待望漢字：「薫」がピンポイントで変換候補にあがり、
両者を通しで入力すると、「香薫」が一発で変換できる…というものです。
この機能を仮に名付けて、「代表変換」か「棚卸し変換」として単漢字変換の目玉ギミックとして新たに提案したいと思っています。
[の][の]というのは「ニワトリの鶏」「干支の酉」のように「○○の○○」といった指定例示の用法の言い回しの感覚をそのまま別口入力タイプ化したもので、
普段別口入力[の]が2連続でタイプされることはありませんから、これを特殊なストロークと検知して[の][の]の直前のワードを抽出して薫風なり綺麗なりといった語に変換できる用意があるよとしたうえで
その文字列のうちあえて断片的に出したいであろう単漢字を一つ提示して「薫」なり「綺」なりのちょっとスノッブな方の漢字を省アクセスして変換してしまおうという目論見の新たな変換操作です。
「代表変換」といっても必ずしも使用頻度の多い漢字が選択されるわけではなく、稀少性があってその音の同音候補も多くよりアクセス困難度の高いものを選好するというメカニズムを想定しています。
なのでニュアンス的には「代表」というよりもちょっとひねって「棚卸し」変換とネーミングした方が良いかもしれませんがこのへんはまだ思案中です。
同様に「天保異聞 妖奇士(てんぽういぶん あやかしあやし)」というアニメタイトルも初回ではとても入力できそうにありませんが
ようかい[の][の]で「妖怪」の「妖」を出して(あるいは「あやかし」で直接単漢字の「妖」を出すこともできる)
きみょう[の][の]で「奇妙」の「奇」を同様に出し
さむらい[の][の]で「士」をダイレクトに出していき、3文字配列したところでEnterを押すと「妖奇士」が確定できるといった具合です。削除動作は一切ありません。
ここで細かい考察を加えますと、「あやかし」から「妖」をダイレクトに出すことは結構地味に画期的な事であると強調しておきたいと思います。
あやかしを普通に変換する段においては「あやかし緋扇」や「あやかし草子」といったひらがな表記の語も多いため通常変換では「妖」を単漢字で一発で出せる期待度は通常より低下し、不確定です。
そこへきてこの[の][の]変換においては単漢字変換が目的ですから漢字表記のものとしてダイレクトにアクセスできるところがハッキリしていて単漢字変換の目的に特化されています。ここが大きな違いです。
「奇妙」においては「奇」も「妙」もどちらも選ばれる可能性があるのですが、より同音漢字で埋もれやすい「奇」をピンポイントで出してきています。単漢字で「奇」を出すのは結構手間がかかります。
そして最後の「士」ですがさむらいというつづりでは侍という字もありますがこれは断片要素として使われることはまれで必要度の面から言っても「士」を代表として出すのは至極妥当な事です。
わざわざ「消防士」とやってから出すより即応的でもあり何より生産力の高いパーツですので代表要素にふさわしい候補であります。
そういった稀少性・断片活躍性・同音埋没性・生産力のファクターを個々に勘案して適切に代表漢字を提示する壮大な仕組みなのですが、これらのファクター以外にもケースバイケースで振り分けられる一定の傾向みたいなのも種々ありそうです。例を挙げると、
・「催促」の「催」は最上位候補、「最速」のような属性ハの候補は敬遠する
・「枯れる」の「枯」は上位、「狩れる」などのモダリティバリエーションは外す
・「加工」の「加」は上位、「書こう」などのモダリティバリエーションは外す
・どちらの成分が上位か判断が拮抗する場合には、画数の多い方を優先する
・「せいのじ」の場合は[の]別口入力せずべたで「せいのじ」：結果「正の字」の「正」を出す：慣用連語代表の考え方
・「わける」[の][の]→「分」、「わけ」[の][の]→「訳」
・「こうおつ」の「甲」、「こうおつへいてい」なら「丙」
・「じょうしする」[の][の]→「梓」：サ変動詞「上梓する」より
・「にる」だと順位不明だが「にている」なら「似」、「にこむ」なら「煮」が出る
・「いし」は「石」を出しても元々単漢字で意味がないので「意志」(「医師」は医者で代替が効くので軽視)そして代表漢字は「志」・同音埋没配慮から
・「あやか」の場合は種々人名があるが歌手の「絢香」の「絢」、有名人ということで有標性があるし字も固有
色々考えられそうなケースをあげてみましたが個別に説明していきますと、
「最速」のような属性ハの候補は敬遠する、というのはあくまで感覚的にそうした方が良いだろう程度の見解なのですが、例えば別の属性ハの「亭」や「邸」などの属性ハ(接頭語接尾語)のもののように連接範囲が広すぎて不確定要素が大きい、あるいは「江川邸」のとわざわざ邸をつけてまでも説明したい語というのはあまりなさそうですし、
同じ「てい」の音をもつ同音接辞というのは得てして増えがちであり代表提示が困難になる可能性をもっているという事情もあります。もともと接辞は漢語由来で定型的な音素が多く同音語の温床でもありますのでこれは仕方がありません。
なので基本的には属性ハをもつワードは敬遠しても良いかと思います。(「末廣亭」の「廣」のように重宝しそうな例もありますが…)
「狩れる」や「書こう」のようなモダリティバリエーションは外すというところにおいても典型的・代表的なものを出したいのですから動詞や形容詞の入力は基本形(辞書形)の活用のものにするというのが自然というものでしょう。
べたの「せいのじ」と入力させるのは別口入力の[の]で区切られてしまうと[の][の]代表変換の直前の語の参照が[の]以前のところまで届かずに断片化してしまう危険性を避けるためでこういった慣用的な成句においては頻出しそうなものはべたの字面でもデータ格納しておく必要性があるかと思います。
例えば「縁」についても「ひとのえん」で出せるようにしたり、[の]に限らず「たまにきず」で「玉に疵」の「疵」を出したりできるようにするなどこういった慣用成句は他にもいろいろありそうです。
「こうおつへいてい」については全体形(こうおつへいてい)と一部形(こうおつ)が重複部分があるにしても全体をスコープしているのであれば代表候補が差し替えられる可能性も担保しておきたいという視点を残すということです。
これに似た例としては「おかめ」で「岡目」の「岡」、「おかめはちもく」で「傍目」の「傍」が出せるなどのケースもあるかと思います。
「じょうしする」のようなサ変動詞については、使用形態に則して「～する」まで含めてタイピングするのが差別化のために理に適っているかと思います。
「にている」「にこむ」のような一般動詞/複合動詞についても適宜固有例を出して弁別できる構えをするのがベターです。
「いし」において「医師」と「意志」の衝突回避についてもより日常的な「医者」という代表語をもつものはあえてよそ行きのときに出しゃばらず、そこを自重するのはより穏当な解決手段です。
「絢香」のような有名人の人名がある種のスノッブ漢字の指標となっていて変換の素材となるのはユーザーのコモンセンスのうえからも土壌が共通化できてよいかと思います。
人名の収録においては、闇雲に流行を意識したミーハーなセレクションというよりも、「絢」のような固有・スノッブ漢字をもつものを有名無名にかかわらず収録して「この字が出したいんだ」というポインタとしての要請に適うものを集めていけばよいかと思います。
なお、ひとつ目の代表漢字候補でマッチしないときには[の]をさらに連打して別の構成漢字を順繰りに出していくかあるいは[の]連打が重複し過ぎると慌てて通り過ぎてしまう可能性もあるので別候補を繰り出したいときは[通常変換]キーに押し換えて入力していけばよいかと考えています。
いずれにしても代表変換ですので先述の条件で絞られるよう選択提示して、妥当な第一候補が出せれば大きな不満は出てこないであろうと思います。
ここまで列挙したもの以外の補足的な事項としましては、動詞の「忍び」「光り」「話し」がそれぞれ連用形転成名詞として単漢字表記を好む用途に向けて属性イ(イ万)であえて変換させた「忍」「光」「話」を出すための操作(三属性変換)や、
同じく三属性変換の属性イ(イ万)の操作で、「焼肉」「受付」「取組」など送り仮名をともなわない、「表記ゆれを漢字のみで構成する複合語に集約化する機能」のようにすでに似たような機能が三属性変換の名詞属性用途で提案されています。
詳しくはこちらの記事↓をご覧ください。
連用形転成名詞の一部は、表記上のニュアンスを区別するためよろづを使い分ける - P突堤2
ここのところは連用形転成名詞ということもあってか活用形が連用形ですので[の][の]代表変換のように動詞の受け付けは基本形(辞書形)を原則とする活用形指定とは一線を画すものであります。なので
よろづイ万の連用形転成名詞の変換 → 活用形：連用形
[の][の]代表変換の動詞呼び出しワード → 活用形：基本形(終止形・辞書形)
のように明確に住み分けして微妙な使い分けを確立していきながら利用してもらえればと思います。
ここまで[の][の]代表変換のおおまかな想定動作要件についてあれこれ考察してきましたがああしろ、こうしろと言う割には具体的なメカニズムの設計には触れずじまいだという調子で全くふがいないのですが、
すべての代表漢字・単漢字を出すための呼び出しワードをひとつひとつ紐づけするのはおそらく無理そうですし、
「ひろう」で「疲労」の「疲」が出てしまうのを避けるため「かんせいひろう」で「完成披露」の「披」を出したりする工夫がせっかくあったとしても「完成披露」のような複合語は処理の関係上すべてをカバーするのは困難ではないのか、データ網羅対応はどうするのかという問題が出てきたりします。
要は目的の代表漢字を呼び出すためのデータを膨大に備えればよいといった力任せの業は通用する見込みはないので漢字の読みと変換文字列や頻度情報などの基礎データだけからその都度代表漢字を推測するといった半自動化された賢い仕組みの助けが必ず必要になってきます。
先述のさまざま列挙したファクターの計算結果を瞬時に導き出して動的に動作するものは片やすべての代表漢字を個別網羅的に納める静的な動作のものではなくても、それと同等か遜色なく機能するように柔軟に設計された「代表漢字選考プロセスAI」のような特化した基盤プロセスみたいなものをのん気に夢想しているところであります。
勿論その実現のためには基礎データに添える補助データとして「漢字のスノッブ度」とか「同音語ライバルの多寡」といった固有のデータを新たに付け加える必要もあるかもしれませんが、個別的な周知の複合語でない、未知の組み合わせの複合語からも代表漢字を適切に選び出すことができれば言うことないですし、
何よりも誰もが代表漢字だと思うわかりやすさの「妥当性」だけではなくて、代表漢字を絞り込むさまざまな要件のファクターを忠実にフィルター濾しするその「納得感」ともバランスして両立する絶妙なさじ加減も求められる熟練を要する"ミッション"でもあるのだと思います。
アイデアそのものは単純な発想ですがそれを実現するためにはまだまだもって今後のより深い分析が求められているのだとこちらとしても十二分に自覚していかなければなりませんね。
最後に書き忘れていたのですが、打鍵キーについて別口入力[の]はキーボード下部左右に２つ配置されておりますが、どの別口入力からでも広く前後を問わず連接するというポテンシャルをもっているため特別にこれが認められています。
なので[の][の]連続打鍵にしても片側連続なのか交互連続なのか2つの場合があるかと思います。
今回の[の][の]代表変換におきましては、そのうち片側連続打鍵のものだけをストローク検知対象としたい方針です。
理由はそんなに深いものではありませんが、「のの」連続する文はほとんど見られないものの、準体助詞の「の」と格助詞の「の」が重なった
・すっかりひれ伏しているののなんと愉快な事か
みたいな用法においては連続で使われる例もなくはないのでこの例に対応する余地を残しておくためにこちらの場合は「の」交互打鍵でのタイプ可能性を残しておくべきかと考えました。
したがって特殊ストロークである[の][の]はより限定された片側連続打鍵に限って適用するものとします。
この辺、デバイス的なキーアサインにおいて面倒な処理になるかも知れませんが開発者の方にはどうかご容赦願いたいと思います。
以上で単漢字入力問題の有力な解決策となるかも知れない[の][の]代表変換でしたが、今回の記事で終わりというわけではありません。
単漢字に限らず、「地球周回軌道」の「周回」という2文字での代表漢字を出したい場合もありますし、「笑撃の事実」みたいな言葉遊びでよくみられるもじりを円滑に実現するのにはどうすればよいかという問題もあります。
何よりこの機能(とその発展事項)の周辺には今までなかった新語や独特の言葉遣いとも密接な関係性がありますから、同時に単語登録機能とも連動した何か新しいシステムの要請も結局ついて回ることになります。
次回以降ではもう少しその辺を突っ込んでより考察を深めていきたいと思いますので追記事の投稿がいつになるのかはわかりませんが近いうちに書き上げたいのでそれまでしばらくお待ちください。
たとえばこんなのがあります。
「香薫あらびきポーク」という商品名をタイプしたいときに、「香薫」というワードが初回入力時にはどの字をあてて良いかわからないため、香りという字を出してから「り」を削り、薫風という字を出してから「風」を削り…といった調子で煩雑でややこしい入力になっていました。
そこでちょっと特殊な操作なんですが、別口入力の[の]を2回連続で[の][の]のように打ち込むとその直前のワードのすぐ思いつく漢字を"代表"変換して単漢字で出すというものです。
ちょっと分かりにくいので説明しますと、「香薫」とタイプで出したいときに
かおり[の][の]、と打ち込むと送り仮名のない「香」が単漢字で変換候補筆頭にあがり、([]は別口入力)
くんぷう[の][の]、と打ち込むと「薫風」のうち代表的な待望漢字：「薫」がピンポイントで変換候補にあがり、
両者を通しで入力すると、「香薫」が一発で変換できる…というものです。
この機能を仮に名付けて、「代表変換」か「棚卸し変換」として単漢字変換の目玉ギミックとして新たに提案したいと思っています。
[の][の]というのは「ニワトリの鶏」「干支の酉」のように「○○の○○」といった指定例示の用法の言い回しの感覚をそのまま別口入力タイプ化したもので、
普段別口入力[の]が2連続でタイプされることはありませんから、これを特殊なストロークと検知して[の][の]の直前のワードを抽出して薫風なり綺麗なりといった語に変換できる用意があるよとしたうえで
その文字列のうちあえて断片的に出したいであろう単漢字を一つ提示して「薫」なり「綺」なりのちょっとスノッブな方の漢字を省アクセスして変換してしまおうという目論見の新たな変換操作です。
「代表変換」といっても必ずしも使用頻度の多い漢字が選択されるわけではなく、稀少性があってその音の同音候補も多くよりアクセス困難度の高いものを選好するというメカニズムを想定しています。
なのでニュアンス的には「代表」というよりもちょっとひねって「棚卸し」変換とネーミングした方が良いかもしれませんがこのへんはまだ思案中です。
同様に「天保異聞 妖奇士(てんぽういぶん あやかしあやし)」というアニメタイトルも初回ではとても入力できそうにありませんが
ようかい[の][の]で「妖怪」の「妖」を出して(あるいは「あやかし」で直接単漢字の「妖」を出すこともできる)
きみょう[の][の]で「奇妙」の「奇」を同様に出し
さむらい[の][の]で「士」をダイレクトに出していき、3文字配列したところでEnterを押すと「妖奇士」が確定できるといった具合です。削除動作は一切ありません。
ここで細かい考察を加えますと、「あやかし」から「妖」をダイレクトに出すことは結構地味に画期的な事であると強調しておきたいと思います。
あやかしを普通に変換する段においては「あやかし緋扇」や「あやかし草子」といったひらがな表記の語も多いため通常変換では「妖」を単漢字で一発で出せる期待度は通常より低下し、不確定です。
そこへきてこの[の][の]変換においては単漢字変換が目的ですから漢字表記のものとしてダイレクトにアクセスできるところがハッキリしていて単漢字変換の目的に特化されています。ここが大きな違いです。
「奇妙」においては「奇」も「妙」もどちらも選ばれる可能性があるのですが、より同音漢字で埋もれやすい「奇」をピンポイントで出してきています。単漢字で「奇」を出すのは結構手間がかかります。
そして最後の「士」ですがさむらいというつづりでは侍という字もありますがこれは断片要素として使われることはまれで必要度の面から言っても「士」を代表として出すのは至極妥当な事です。
わざわざ「消防士」とやってから出すより即応的でもあり何より生産力の高いパーツですので代表要素にふさわしい候補であります。
そういった稀少性・断片活躍性・同音埋没性・生産力のファクターを個々に勘案して適切に代表漢字を提示する壮大な仕組みなのですが、これらのファクター以外にもケースバイケースで振り分けられる一定の傾向みたいなのも種々ありそうです。例を挙げると、
・「催促」の「催」は最上位候補、「最速」のような属性ハの候補は敬遠する
・「枯れる」の「枯」は上位、「狩れる」などのモダリティバリエーションは外す
・「加工」の「加」は上位、「書こう」などのモダリティバリエーションは外す
・どちらの成分が上位か判断が拮抗する場合には、画数の多い方を優先する
・「せいのじ」の場合は[の]別口入力せずべたで「せいのじ」：結果「正の字」の「正」を出す：慣用連語代表の考え方
・「わける」[の][の]→「分」、「わけ」[の][の]→「訳」
・「こうおつ」の「甲」、「こうおつへいてい」なら「丙」
・「じょうしする」[の][の]→「梓」：サ変動詞「上梓する」より
・「にる」だと順位不明だが「にている」なら「似」、「にこむ」なら「煮」が出る
・「いし」は「石」を出しても元々単漢字で意味がないので「意志」(「医師」は医者で代替が効くので軽視)そして代表漢字は「志」・同音埋没配慮から
・「あやか」の場合は種々人名があるが歌手の「絢香」の「絢」、有名人ということで有標性があるし字も固有
色々考えられそうなケースをあげてみましたが個別に説明していきますと、
「最速」のような属性ハの候補は敬遠する、というのはあくまで感覚的にそうした方が良いだろう程度の見解なのですが、例えば別の属性ハの「亭」や「邸」などの属性ハ(接頭語接尾語)のもののように連接範囲が広すぎて不確定要素が大きい、あるいは「江川邸」のとわざわざ邸をつけてまでも説明したい語というのはあまりなさそうですし、
同じ「てい」の音をもつ同音接辞というのは得てして増えがちであり代表提示が困難になる可能性をもっているという事情もあります。もともと接辞は漢語由来で定型的な音素が多く同音語の温床でもありますのでこれは仕方がありません。
なので基本的には属性ハをもつワードは敬遠しても良いかと思います。(「末廣亭」の「廣」のように重宝しそうな例もありますが…)
「狩れる」や「書こう」のようなモダリティバリエーションは外すというところにおいても典型的・代表的なものを出したいのですから動詞や形容詞の入力は基本形(辞書形)の活用のものにするというのが自然というものでしょう。
べたの「せいのじ」と入力させるのは別口入力の[の]で区切られてしまうと[の][の]代表変換の直前の語の参照が[の]以前のところまで届かずに断片化してしまう危険性を避けるためでこういった慣用的な成句においては頻出しそうなものはべたの字面でもデータ格納しておく必要性があるかと思います。
例えば「縁」についても「ひとのえん」で出せるようにしたり、[の]に限らず「たまにきず」で「玉に疵」の「疵」を出したりできるようにするなどこういった慣用成句は他にもいろいろありそうです。
「こうおつへいてい」については全体形(こうおつへいてい)と一部形(こうおつ)が重複部分があるにしても全体をスコープしているのであれば代表候補が差し替えられる可能性も担保しておきたいという視点を残すということです。
これに似た例としては「おかめ」で「岡目」の「岡」、「おかめはちもく」で「傍目」の「傍」が出せるなどのケースもあるかと思います。
「じょうしする」のようなサ変動詞については、使用形態に則して「～する」まで含めてタイピングするのが差別化のために理に適っているかと思います。
「にている」「にこむ」のような一般動詞/複合動詞についても適宜固有例を出して弁別できる構えをするのがベターです。
「いし」において「医師」と「意志」の衝突回避についてもより日常的な「医者」という代表語をもつものはあえてよそ行きのときに出しゃばらず、そこを自重するのはより穏当な解決手段です。
「絢香」のような有名人の人名がある種のスノッブ漢字の指標となっていて変換の素材となるのはユーザーのコモンセンスのうえからも土壌が共通化できてよいかと思います。
人名の収録においては、闇雲に流行を意識したミーハーなセレクションというよりも、「絢」のような固有・スノッブ漢字をもつものを有名無名にかかわらず収録して「この字が出したいんだ」というポインタとしての要請に適うものを集めていけばよいかと思います。
なお、ひとつ目の代表漢字候補でマッチしないときには[の]をさらに連打して別の構成漢字を順繰りに出していくかあるいは[の]連打が重複し過ぎると慌てて通り過ぎてしまう可能性もあるので別候補を繰り出したいときは[通常変換]キーに押し換えて入力していけばよいかと考えています。
いずれにしても代表変換ですので先述の条件で絞られるよう選択提示して、妥当な第一候補が出せれば大きな不満は出てこないであろうと思います。
ここまで列挙したもの以外の補足的な事項としましては、動詞の「忍び」「光り」「話し」がそれぞれ連用形転成名詞として単漢字表記を好む用途に向けて属性イ(イ万)であえて変換させた「忍」「光」「話」を出すための操作(三属性変換)や、
同じく三属性変換の属性イ(イ万)の操作で、「焼肉」「受付」「取組」など送り仮名をともなわない、「表記ゆれを漢字のみで構成する複合語に集約化する機能」のようにすでに似たような機能が三属性変換の名詞属性用途で提案されています。
詳しくはこちらの記事↓をご覧ください。
連用形転成名詞の一部は、表記上のニュアンスを区別するためよろづを使い分ける - P突堤2
ここのところは連用形転成名詞ということもあってか活用形が連用形ですので[の][の]代表変換のように動詞の受け付けは基本形(辞書形)を原則とする活用形指定とは一線を画すものであります。なので
よろづイ万の連用形転成名詞の変換 → 活用形：連用形
[の][の]代表変換の動詞呼び出しワード → 活用形：基本形(終止形・辞書形)
のように明確に住み分けして微妙な使い分けを確立していきながら利用してもらえればと思います。
ここまで[の][の]代表変換のおおまかな想定動作要件についてあれこれ考察してきましたがああしろ、こうしろと言う割には具体的なメカニズムの設計には触れずじまいだという調子で全くふがいないのですが、
すべての代表漢字・単漢字を出すための呼び出しワードをひとつひとつ紐づけするのはおそらく無理そうですし、
「ひろう」で「疲労」の「疲」が出てしまうのを避けるため「かんせいひろう」で「完成披露」の「披」を出したりする工夫がせっかくあったとしても「完成披露」のような複合語は処理の関係上すべてをカバーするのは困難ではないのか、データ網羅対応はどうするのかという問題が出てきたりします。
要は目的の代表漢字を呼び出すためのデータを膨大に備えればよいといった力任せの業は通用する見込みはないので漢字の読みと変換文字列や頻度情報などの基礎データだけからその都度代表漢字を推測するといった半自動化された賢い仕組みの助けが必ず必要になってきます。
先述のさまざま列挙したファクターの計算結果を瞬時に導き出して動的に動作するものは片やすべての代表漢字を個別網羅的に納める静的な動作のものではなくても、それと同等か遜色なく機能するように柔軟に設計された「代表漢字選考プロセスAI」のような特化した基盤プロセスみたいなものをのん気に夢想しているところであります。
勿論その実現のためには基礎データに添える補助データとして「漢字のスノッブ度」とか「同音語ライバルの多寡」といった固有のデータを新たに付け加える必要もあるかもしれませんが、個別的な周知の複合語でない、未知の組み合わせの複合語からも代表漢字を適切に選び出すことができれば言うことないですし、
何よりも誰もが代表漢字だと思うわかりやすさの「妥当性」だけではなくて、代表漢字を絞り込むさまざまな要件のファクターを忠実にフィルター濾しするその「納得感」ともバランスして両立する絶妙なさじ加減も求められる熟練を要する"ミッション"でもあるのだと思います。
アイデアそのものは単純な発想ですがそれを実現するためにはまだまだもって今後のより深い分析が求められているのだとこちらとしても十二分に自覚していかなければなりませんね。
最後に書き忘れていたのですが、打鍵キーについて別口入力[の]はキーボード下部左右に２つ配置されておりますが、どの別口入力からでも広く前後を問わず連接するというポテンシャルをもっているため特別にこれが認められています。
なので[の][の]連続打鍵にしても片側連続なのか交互連続なのか2つの場合があるかと思います。
今回の[の][の]代表変換におきましては、そのうち片側連続打鍵のものだけをストローク検知対象としたい方針です。
理由はそんなに深いものではありませんが、「のの」連続する文はほとんど見られないものの、準体助詞の「の」と格助詞の「の」が重なった
・すっかりひれ伏しているののなんと愉快な事か
みたいな用法においては連続で使われる例もなくはないのでこの例に対応する余地を残しておくためにこちらの場合は「の」交互打鍵でのタイプ可能性を残しておくべきかと考えました。
したがって特殊ストロークである[の][の]はより限定された片側連続打鍵に限って適用するものとします。
この辺、デバイス的なキーアサインにおいて面倒な処理になるかも知れませんが開発者の方にはどうかご容赦願いたいと思います。
以上で単漢字入力問題の有力な解決策となるかも知れない[の][の]代表変換でしたが、今回の記事で終わりというわけではありません。
単漢字に限らず、「地球周回軌道」の「周回」という2文字での代表漢字を出したい場合もありますし、「笑撃の事実」みたいな言葉遊びでよくみられるもじりを円滑に実現するのにはどうすればよいかという問題もあります。
何よりこの機能(とその発展事項)の周辺には今までなかった新語や独特の言葉遣いとも密接な関係性がありますから、同時に単語登録機能とも連動した何か新しいシステムの要請も結局ついて回ることになります。
次回以降ではもう少しその辺を突っ込んでより考察を深めていきたいと思いますので追記事の投稿がいつになるのかはわかりませんが近いうちに書き上げたいのでそれまでしばらくお待ちください。
まずはこの図をご覧ください。
<図１ 入力モードの切り替え>
前回に引き続いて、今回は入力モードの切り替えとその時にデフォルトで提供されるタッチ液晶の文字セットがいかように遷移していくかの詳しい挙動について解説していきたいと思います。
タッチ液晶の英アルファベット・記号・数字などの配列は2種類あってこれはセットと呼んで英数主体の[セットA]と数字を省いて記号類を充実させた[セットB]とがあるのは前回解説した通りです。
セットは英数記号部分を入力するときの英数記号まわりに限った用途においてセット文字群が選択できるといった位置づけですが、入力モードの移行は従来的な"日本語入力""英語入力"といった言語による分け方ではなく
「日英混在文の入力１」と「日英混在文の入力２」との２つパターンを念頭に置いて入力モードを使い分けるものであります。
ちょっと根本に戻って説明させて頂きますと、かなクラスタキーを押せばそれはほぼ(記号以外で)かな文字でありますし、何かの間違えでアルファベットをクラスタキーから入力できるということは絶対にないというのはお分かりかと思いますが、
さらに他方タッチ液晶の面からかな文字が入力できてしまうということも原理上ありませんので打った字種分の揺るぎなき文字列がそのまま反映されるだけであるので日本語字種(かな)⇔英記号字種(液晶)のモードを意識する壁がそもそもないのです。
なので「日本語」/「英数」のモード分けという考え方はもとよりなく、常に日英混在文であることを前提にしているのであとは英語部分を含んで混在変換をさせるのか、あるいは英語部分をソリッドに解釈し混在変換のサポートを手つかずにして変換させる、との違いであります。
それでも英語部分はそれはそれとして日本語交じりの断片として混在的に処理するのであくまでも混在変換前提の中でのサポート関与度合いの違いとして「日英混在文の入力１」と「日英混在文の入力２」が存在するわけです。
詳しい説明にうつる前にまずは図でモード遷移について示したいと思いますので下図をご覧ください。
<図２ 英直接入力/標準入力の切り替えと液晶文字セットのデフォルトと遷移>(クリックすると新しいタブが開き拡大します)
文字セットについては後で説明します。まずはモードは2つと先程申しましたが、例外的に入力フォームで受け付け字種が英数に指定されている場合があるのでこれを加えて想定するモードは３モードとなります。
まず一番の基底状態と言えるのが中段にある英数混在の[標準モード]です。
ペンタクラスタキーボードの日英混在入力(標準モード)では利便性向上のために、以下の機能の実現を提案しています。
・AdobeやiPadやIotのような語を特にShiftキーで大文字指定することなく
[標準モード]においてadobe・ipad・iotのように入力して混在文の中で変換すると
コンピュータが大文字・小文字部分を適宜変換して省入力してくれる「英文字イニシャライズのサポート」
・W杯・A応P・スポーツch・用賀ICのような日英混成語の小文字大文字の微妙な違いも酌んで変換してくれる「日英混成語の変換サポート」
の２つの課題を掲げてあるのですが、これらはもちろん辞書登録単語にもともとあるから、といってしまっては元も子もないのですが、ペンタクラスタキーボードの日英字種完全分離の設計を大いに生かして変換前文字列でも入力字種の部分部分が曖昧でなくハッキリしていることが力強い支えになります。
単語登録に際しても混成語として文字列字種そのままに入力して事足りるという面があります。これは大きな強みです。
イニシャライズにおきましても手動で大文字化したいというのであればShiftキーを使って意識的に表記づけをすることもできますしおまかせもできます。
たとえ登録単語に入っていない場合でも未知語は原則全大文字に変換する、あるいは変換候補リストの中で頭文字イニシャライズのものを次点以降にもってくるなどのルール作りを整備したうえでユーザーにとって定常のルーチンを乱さないように挙動を定めておけば英文字の扱いもずっと道理にかなったものになるでしょう。
以上のようなサポートに加えて英単語部分の予測入力も(どこまでできるのかはわかりませんが)積極的に機能させていきたいと考えております。
単に英単語つづりの予測提示だけではなく、「Back to the future」みたいにいくつかのスペースを挟んだ形のものも提示候補として出せたらなお良いとおもいますし、ペンタクラスタキーボードでは別口入力マーカーでなにがしかのチャンク区切りが認識できるようになっているので、
スペースが入ったからといって安易に終端要素と捉えるのではなく、別口入力や日本語かな文字列が新たに出てくるまでは英文の一節が続いているのだな、と適切に判断して文字列を解釈していくことができれば気の利くインターフェイスに一歩近づけるのではないでしょうか。
基本状態として混在入力の中でこのように常に盛りだくさんのフォローしてくれるのが[標準入力]になります。
次に補佐的・サブ的な用途として設定してあるモードが[英直接入力]です。
まず大前提としてログインフォームやパスワード入力などで英数単語つづりを学習させたくないオプションとしての用途がこのモードの一番の意義であります。大事な文字列が数文字打ち始めただけで全部補完されてしまってはたまったものではありませんのでこれはマストです。
標準入力での英文字は未確定状態のときはアンダーライン付きで表示して、英直接入力のときの英文字部分はアンダーライン修飾をさせないようにすればモードの違いも明示的に分かるかと思います。
現在入力中の文字列の画面表示に配慮すると同時にタッチ液晶面にもわかりやすい現在モードの表示が必要になってくるかもしれません。
あと補足的には「英文字イニシャライズサポート」で予期せぬ大文字小文字違いが起こるのを回避するためにあえて大文字化のShiftキー同時押しを必須化したものとして使いたいとき、またそのように使えば間違いないとの意図のもとでの入力としてハッキリさせたいときにこのモードが役に立つかと思います。
一応日英混在文として日本語部分の変換は従来通り行われますが受け取った英文字部分の文字列には一切手を加えず、モザイク的に変換していきます。構文解析的にも特段の影響はありません。
ただし冒頭でも申し上げた通り、英文字部分の予測変換は機能しない挙動となっております。日本語部分は解釈の限り予測変換は変わらず機能していくものとします。
この辺りどのような副作用が現れるかどうかは未知数ですが善処していければよいかと思います。
そして[英直接入力]とも重なってきますが、入力フォームなどで特に直接入力/英数(日本語入力OFF)がむこうから指定されているときは特別なケースとなってきます。
日本語入力OFF指定のときは直接入力ですので英数記号のみの受け付けとなり、この場合に限っては日本語かな文字の入力は遮断というか未認識であるとみなされて、入力があったとしても反映はされません。
これはこれで特殊なケースであるので[標準入力][英直接入力]に続く第三の入力モードと位置づけられます。
ただ直接入力とは言うものの文字セットがA、Bと切り替えられるのを想定していますがこれはキーアサインの関係からこのような使い分けが現実的に可能なのかどうかについては浅学なため理解が及ばないので、ダメならダメでそこは「理想の入力形態を追求する」との大義名分のもとコンセプトだけは先行させていきたいのでどうかご容赦頂きたいかと思います。
…これで３種のモードについて説明していきましたが主要2モード間の移行は[英直接入力]/[標準入力]の各キーを押すことで順次即切り替え対応となっておりますし、「テキストフォーム内において日本語入力Offが指定されている場合」についてはその場で直接入力受け付け状態となりカーソルが出ている場合は他の2モードへの切り替えも不可逆的に受け付けない仕様とすべきかと思います。
ここでようやく出てくるのがその時の文字セットはどうなるのか、という問題で標準モードとその他の入力モードのそれぞれに細かな違いがあります。
まず[英直接入力]と「テキストフォーム内において日本語入力Offが指定されている場合」のケースにいるときには最初の変わりっぱなの状態では英数中心の文字セット<文字セットA>がデフォルトにくることになります。
<文字セットB>への移行はそこからタッチ液晶内のセット切り替えボタンでトグル式に変更できるようになっております。
それとは対照的に、[標準入力]へモード変更した直後はこれとは異なり記号中心の<文字セットB>がデフォルトとして出てくるようになっており、こちらは各種記号へのアクセスを重視した構えとなっておりますのでデフォルトセットもあえて変えてある仕様です。
こちらの場合もそこからタッチ液晶内のセット切り替えボタンで<文字セットA>へ移行していきさらにはもう一度セット切り替えボタンで<文字セットB>へトグル循環していきます。
以上で入力モード移行とセットトグル切り替えについて整理していきましたが、あと一つだけ、各種モードの略称について触れておきたいかと思います。
図にもあります通り、ちょっと砕けた言い回しですが「素っ気ないモード[素]」「標準モード[混]」「頑ななモード[頑]」の略称がそれぞれのモードにつけられています。
機能に基づいたセオリー通りの名づけからすれば「英直接入力[直]」「標準入力[標]」「テキストフォーム指定[指]」などのようにすればいいかもしれませんがあまり字面から機能イメージを感じることができません。
[直]に関して言えば英直接入力のものでも日本語入力Off状態のものでもどちらも直接入力の色合いが濃いですし微妙に混同して勘違いの元にもなりますので何かうまい呼称を考えなくてはいけません。
そこで英直接入力=「混在入力を保持しつつ英数部分は直接入力・英単語予測入力はなし」…という予測サポートやイニシャライズのサポートがないというニュアンスを感覚的にあらわした「素っ気ないモード[素]」というのがもっともさらっと特徴を捉えていてベストな表現ではないかと思います。
そして標準というくくりよりも日英混在入力のベース状態としての存在感を強く打ち出した「標準モード[混]」という名称の[混]という部分により特質があらわれていてこちらの方が固有的で良いかと思います。
「標準」という言葉は他の機能の説明のくだりでもひょっとしたら出てくるかもしれませんし抽象的な言葉であるので明確に混在を意識させる[混]のほうが扱い的にも意味カブりを避けられるのでベターかと思います。
最後のテキストフォーム内において日本語入力Offが指定されている場合=「頑ななモード[頑]」は「かな部分は受け付けない」というところがどこか素っ気ないを超えてより限定入力的であるのでちょっと強い言葉にしていますがよりマッチしているかと自負しているのですがどうでしょうか。
どれも比喩的というかイメージ付随のまなざしからくるワードではありますが限られた字数で要点を捉えた言葉をチョイスするにはやはりこうしたヒネリも必要だとは思います。
画面下部のタスクバーに表示されているスペースも1文字分がやっとでありますので[素][混][頑]とやってしまうことも決して思いつきではなく数々の考慮をとりまわした上での合理的な解決策だともいえるのです。
たとえが適当であるかわかりませんが、近年テレビの災害報道などで初動対応が迫られている場面などで「決してあきらめないでください！」「助けは必ず来ます！」といった心情や励ましの心理に訴えかけた呼びかけるようなアナウンスを見かけるようになりました。
テレビ報道は事実だけを淡々と伝えればよい…といった方針を転換して、コミュニケーションに重きを置いたこの手法はさまざまな試行錯誤のうえ考えられたメッセージ機能をもっているかと思われます。心情的であるというよりは、むしろ合理的な手法なのです。
ちょっと後付けかもしれませんが、ペンタクラスタキーボードの入力モード名称についてもこういった心理的機能をユーザーへの認知向上に役立てていこうという意味で先述の報道手法の例にならっているものだと力説したいところです。
ネーミングにもいろいろな可能性を視野に入れてこのような方策をとるのもご納得いただけるのではないでしょうか。
以上で説明を終わりたいと思いますがごく端的に要点を述べると
・Macのように即押しで入力モードを変更する
・モードによってデフォルトの文字セットが異なる
ここだけは押さえてもらいたいところであります。
入力字種完全分離による日英混在文の入力スタイルの最適形に少しでも近づけるよう、有意義な提案になっていれば良いなと思います。
<図１ 入力モードの切り替え>
前回に引き続いて、今回は入力モードの切り替えとその時にデフォルトで提供されるタッチ液晶の文字セットがいかように遷移していくかの詳しい挙動について解説していきたいと思います。
タッチ液晶の英アルファベット・記号・数字などの配列は2種類あってこれはセットと呼んで英数主体の[セットA]と数字を省いて記号類を充実させた[セットB]とがあるのは前回解説した通りです。
セットは英数記号部分を入力するときの英数記号まわりに限った用途においてセット文字群が選択できるといった位置づけですが、入力モードの移行は従来的な"日本語入力""英語入力"といった言語による分け方ではなく
「日英混在文の入力１」と「日英混在文の入力２」との２つパターンを念頭に置いて入力モードを使い分けるものであります。
ちょっと根本に戻って説明させて頂きますと、かなクラスタキーを押せばそれはほぼ(記号以外で)かな文字でありますし、何かの間違えでアルファベットをクラスタキーから入力できるということは絶対にないというのはお分かりかと思いますが、
さらに他方タッチ液晶の面からかな文字が入力できてしまうということも原理上ありませんので打った字種分の揺るぎなき文字列がそのまま反映されるだけであるので日本語字種(かな)⇔英記号字種(液晶)のモードを意識する壁がそもそもないのです。
なので「日本語」/「英数」のモード分けという考え方はもとよりなく、常に日英混在文であることを前提にしているのであとは英語部分を含んで混在変換をさせるのか、あるいは英語部分をソリッドに解釈し混在変換のサポートを手つかずにして変換させる、との違いであります。
それでも英語部分はそれはそれとして日本語交じりの断片として混在的に処理するのであくまでも混在変換前提の中でのサポート関与度合いの違いとして「日英混在文の入力１」と「日英混在文の入力２」が存在するわけです。
詳しい説明にうつる前にまずは図でモード遷移について示したいと思いますので下図をご覧ください。
<図２ 英直接入力/標準入力の切り替えと液晶文字セットのデフォルトと遷移>(クリックすると新しいタブが開き拡大します)
文字セットについては後で説明します。まずはモードは2つと先程申しましたが、例外的に入力フォームで受け付け字種が英数に指定されている場合があるのでこれを加えて想定するモードは３モードとなります。
まず一番の基底状態と言えるのが中段にある英数混在の[標準モード]です。
ペンタクラスタキーボードの日英混在入力(標準モード)では利便性向上のために、以下の機能の実現を提案しています。
・AdobeやiPadやIotのような語を特にShiftキーで大文字指定することなく
[標準モード]においてadobe・ipad・iotのように入力して混在文の中で変換すると
コンピュータが大文字・小文字部分を適宜変換して省入力してくれる「英文字イニシャライズのサポート」
・W杯・A応P・スポーツch・用賀ICのような日英混成語の小文字大文字の微妙な違いも酌んで変換してくれる「日英混成語の変換サポート」
の２つの課題を掲げてあるのですが、これらはもちろん辞書登録単語にもともとあるから、といってしまっては元も子もないのですが、ペンタクラスタキーボードの日英字種完全分離の設計を大いに生かして変換前文字列でも入力字種の部分部分が曖昧でなくハッキリしていることが力強い支えになります。
単語登録に際しても混成語として文字列字種そのままに入力して事足りるという面があります。これは大きな強みです。
イニシャライズにおきましても手動で大文字化したいというのであればShiftキーを使って意識的に表記づけをすることもできますしおまかせもできます。
たとえ登録単語に入っていない場合でも未知語は原則全大文字に変換する、あるいは変換候補リストの中で頭文字イニシャライズのものを次点以降にもってくるなどのルール作りを整備したうえでユーザーにとって定常のルーチンを乱さないように挙動を定めておけば英文字の扱いもずっと道理にかなったものになるでしょう。
以上のようなサポートに加えて英単語部分の予測入力も(どこまでできるのかはわかりませんが)積極的に機能させていきたいと考えております。
単に英単語つづりの予測提示だけではなく、「Back to the future」みたいにいくつかのスペースを挟んだ形のものも提示候補として出せたらなお良いとおもいますし、ペンタクラスタキーボードでは別口入力マーカーでなにがしかのチャンク区切りが認識できるようになっているので、
スペースが入ったからといって安易に終端要素と捉えるのではなく、別口入力や日本語かな文字列が新たに出てくるまでは英文の一節が続いているのだな、と適切に判断して文字列を解釈していくことができれば気の利くインターフェイスに一歩近づけるのではないでしょうか。
基本状態として混在入力の中でこのように常に盛りだくさんのフォローしてくれるのが[標準入力]になります。
次に補佐的・サブ的な用途として設定してあるモードが[英直接入力]です。
まず大前提としてログインフォームやパスワード入力などで英数単語つづりを学習させたくないオプションとしての用途がこのモードの一番の意義であります。大事な文字列が数文字打ち始めただけで全部補完されてしまってはたまったものではありませんのでこれはマストです。
標準入力での英文字は未確定状態のときはアンダーライン付きで表示して、英直接入力のときの英文字部分はアンダーライン修飾をさせないようにすればモードの違いも明示的に分かるかと思います。
現在入力中の文字列の画面表示に配慮すると同時にタッチ液晶面にもわかりやすい現在モードの表示が必要になってくるかもしれません。
あと補足的には「英文字イニシャライズサポート」で予期せぬ大文字小文字違いが起こるのを回避するためにあえて大文字化のShiftキー同時押しを必須化したものとして使いたいとき、またそのように使えば間違いないとの意図のもとでの入力としてハッキリさせたいときにこのモードが役に立つかと思います。
一応日英混在文として日本語部分の変換は従来通り行われますが受け取った英文字部分の文字列には一切手を加えず、モザイク的に変換していきます。構文解析的にも特段の影響はありません。
ただし冒頭でも申し上げた通り、英文字部分の予測変換は機能しない挙動となっております。日本語部分は解釈の限り予測変換は変わらず機能していくものとします。
この辺りどのような副作用が現れるかどうかは未知数ですが善処していければよいかと思います。
そして[英直接入力]とも重なってきますが、入力フォームなどで特に直接入力/英数(日本語入力OFF)がむこうから指定されているときは特別なケースとなってきます。
日本語入力OFF指定のときは直接入力ですので英数記号のみの受け付けとなり、この場合に限っては日本語かな文字の入力は遮断というか未認識であるとみなされて、入力があったとしても反映はされません。
これはこれで特殊なケースであるので[標準入力][英直接入力]に続く第三の入力モードと位置づけられます。
ただ直接入力とは言うものの文字セットがA、Bと切り替えられるのを想定していますがこれはキーアサインの関係からこのような使い分けが現実的に可能なのかどうかについては浅学なため理解が及ばないので、ダメならダメでそこは「理想の入力形態を追求する」との大義名分のもとコンセプトだけは先行させていきたいのでどうかご容赦頂きたいかと思います。
…これで３種のモードについて説明していきましたが主要2モード間の移行は[英直接入力]/[標準入力]の各キーを押すことで順次即切り替え対応となっておりますし、「テキストフォーム内において日本語入力Offが指定されている場合」についてはその場で直接入力受け付け状態となりカーソルが出ている場合は他の2モードへの切り替えも不可逆的に受け付けない仕様とすべきかと思います。
ここでようやく出てくるのがその時の文字セットはどうなるのか、という問題で標準モードとその他の入力モードのそれぞれに細かな違いがあります。
まず[英直接入力]と「テキストフォーム内において日本語入力Offが指定されている場合」のケースにいるときには最初の変わりっぱなの状態では英数中心の文字セット<文字セットA>がデフォルトにくることになります。
<文字セットB>への移行はそこからタッチ液晶内のセット切り替えボタンでトグル式に変更できるようになっております。
それとは対照的に、[標準入力]へモード変更した直後はこれとは異なり記号中心の<文字セットB>がデフォルトとして出てくるようになっており、こちらは各種記号へのアクセスを重視した構えとなっておりますのでデフォルトセットもあえて変えてある仕様です。
こちらの場合もそこからタッチ液晶内のセット切り替えボタンで<文字セットA>へ移行していきさらにはもう一度セット切り替えボタンで<文字セットB>へトグル循環していきます。
以上で入力モード移行とセットトグル切り替えについて整理していきましたが、あと一つだけ、各種モードの略称について触れておきたいかと思います。
図にもあります通り、ちょっと砕けた言い回しですが「素っ気ないモード[素]」「標準モード[混]」「頑ななモード[頑]」の略称がそれぞれのモードにつけられています。
機能に基づいたセオリー通りの名づけからすれば「英直接入力[直]」「標準入力[標]」「テキストフォーム指定[指]」などのようにすればいいかもしれませんがあまり字面から機能イメージを感じることができません。
[直]に関して言えば英直接入力のものでも日本語入力Off状態のものでもどちらも直接入力の色合いが濃いですし微妙に混同して勘違いの元にもなりますので何かうまい呼称を考えなくてはいけません。
そこで英直接入力=「混在入力を保持しつつ英数部分は直接入力・英単語予測入力はなし」…という予測サポートやイニシャライズのサポートがないというニュアンスを感覚的にあらわした「素っ気ないモード[素]」というのがもっともさらっと特徴を捉えていてベストな表現ではないかと思います。
そして標準というくくりよりも日英混在入力のベース状態としての存在感を強く打ち出した「標準モード[混]」という名称の[混]という部分により特質があらわれていてこちらの方が固有的で良いかと思います。
「標準」という言葉は他の機能の説明のくだりでもひょっとしたら出てくるかもしれませんし抽象的な言葉であるので明確に混在を意識させる[混]のほうが扱い的にも意味カブりを避けられるのでベターかと思います。
最後のテキストフォーム内において日本語入力Offが指定されている場合=「頑ななモード[頑]」は「かな部分は受け付けない」というところがどこか素っ気ないを超えてより限定入力的であるのでちょっと強い言葉にしていますがよりマッチしているかと自負しているのですがどうでしょうか。
どれも比喩的というかイメージ付随のまなざしからくるワードではありますが限られた字数で要点を捉えた言葉をチョイスするにはやはりこうしたヒネリも必要だとは思います。
画面下部のタスクバーに表示されているスペースも1文字分がやっとでありますので[素][混][頑]とやってしまうことも決して思いつきではなく数々の考慮をとりまわした上での合理的な解決策だともいえるのです。
たとえが適当であるかわかりませんが、近年テレビの災害報道などで初動対応が迫られている場面などで「決してあきらめないでください！」「助けは必ず来ます！」といった心情や励ましの心理に訴えかけた呼びかけるようなアナウンスを見かけるようになりました。
テレビ報道は事実だけを淡々と伝えればよい…といった方針を転換して、コミュニケーションに重きを置いたこの手法はさまざまな試行錯誤のうえ考えられたメッセージ機能をもっているかと思われます。心情的であるというよりは、むしろ合理的な手法なのです。
ちょっと後付けかもしれませんが、ペンタクラスタキーボードの入力モード名称についてもこういった心理的機能をユーザーへの認知向上に役立てていこうという意味で先述の報道手法の例にならっているものだと力説したいところです。
ネーミングにもいろいろな可能性を視野に入れてこのような方策をとるのもご納得いただけるのではないでしょうか。
以上で説明を終わりたいと思いますがごく端的に要点を述べると
・Macのように即押しで入力モードを変更する
・モードによってデフォルトの文字セットが異なる
ここだけは押さえてもらいたいところであります。
入力字種完全分離による日英混在文の入力スタイルの最適形に少しでも近づけるよう、有意義な提案になっていれば良いなと思います。
当ブログ開設以来、ペンタクラスタキーボードではタッチ液晶パネルを採用して日本語かな/英数アルファベットが完全分離をする…と謳ってあります。
モード移行のごちゃごちゃからくる変換行程の不具合を物理的に完全分離してしまえば、キーの数は増えますがローマ字入力のように日本語なのにアルファベット音素を用いてかなを表すという二度手間がなくなりますし、
従来のかな入力でも日英混在の変換はいろいろと煩わしいものでしたがこちらは完全に役割を分けて、日本語かなクラスタキーは日本語だけ、タッチ液晶部は英数だけ、と住み分けが鮮明ですから何より字種の兼任ということがないので原理上も非常にすっきりします。
ただ液晶面は限られてきますし採用する文字をどうするか、あるいは液晶外のクラスタキーでの記号の取り扱いとなるべく被らないように必要な文字を広くカバーすることが重要になってきます。
それはそうと今まで日⇔英のモード移行について肝心のところを決めていなかったので今回配置図を用いて軽く触れておこうかと思います。
図１<標準入力モードと英直接入力モード切り替えのキーの位置>(クリックすると別タブが開き拡大します)
上図黄色く塗ってあるのが入力モードの切り替えのキーになります。
今までのキー形状に少し変更を加えて、ソリッドなキーであった[Enter]キーを斧の刃キーに替えて[英直接入力]/[Enter]の上下2方向に増置したのが大きな変化です。
これはMacの入力切り替え方法に倣っておりトグル式ではない即押しモード移行の仕方が直感的に分かりやすいのでこれと同様の非トグル切り替えにしました。
ネット各所でも自分が今どのモードにいるのかがわかりやすくWindowsよりも合理的だと好評でしたのでペンタクラスタキーボードとしてもこれを取り入れた形です。
今回の記事では切り替えの詳細を説明する前に準備のためにタッチ液晶部の文字セットがそもそも今のままでいいのかという見直しをこの際やってみるということで、
いわばメインの説明に入る前の地ならしという形で記号関係の取り扱いを根本から見直していこうかと思います。なのでここではモード切り替えについてはあえて次回の記事に回したいところですのでご留意ください。
さて現在改定後の定義によればタッチ液晶の文字類は、上段が
["][#][‘][’][-][^][~][|][逆スラッシュ]の「標準モード(仮)」と
[1][2][3][4][5][6][7][8][9][0]の「英数モード(仮)」としておりましたがいろいろ検討した結果「モード」は入力モードとの混乱をきたすもとになるのでまずは名称を改めて文字セットからとった「セット」の呼称を使っていこうかと思います。
あとは逆スラッシュの使用も言語環境の特殊性から色々と取り扱いの難しい記号ですのでこれをあきらめ、代わりになにか使い出のありそうな記号を新たに採用したいと思います。
ここは文章であれやこれや説明していくより配置画像をお見せする方が早いのでとりあえずそれをご覧いただいて後ほど説明をしていこうかと思いますのでどうぞ。
図２<液晶英数の文字セットA>
図３<液晶英・記号の文字セットB>
まずはモード名を混同するとややこしくなるので[文字セットA」と[文字セットB]という呼称を使います。
上段に数字キー1-0までの配列を持つ文字セットAにおいては元となった配列の採用文字から一部入れ替えを施して若干変更があります。
変更箇所は下段両袖にあった[€][￥][$]のキーをやめて、[@][-][_]を配置しました。￥や$は物理キークラスタキーにもありますし本当に必要そうな記号を吟味していったところ、
メールアドレス・ID・パスワードの入力でよく使われるであろう[@][-][_](アットマーク/ハイフン/アンダーバー)を優先した次第です。
こちらもクラスタキーと一部かぶってしまいはするのですが、重要度から鑑みて利便性に資すると判断したものです。
次に上段に各種の記号を配置してある文字セットBですが
["][#][‘][’][-][^][~][|][℃]と元から若干変えてあります。下部両裾は[@]-[;][:]と変更はありません。
逆スラッシュは現実的ではないので、何か他の頻出のものでいいものはないかと考えを巡らせましたが熟考の結果摂氏温度の記号[℃]を採用することとしました。
日本語話者では摂氏は一般的ですし、何よりもひとつ℃とキーを決めてしまえば、同じ音の記号の角度の[°]のときにはこちらは変換から出すときに突出候補となることで液晶入力[℃]との住み分けが自然にできていく…といった図式が期待できます。
漢数字の[度]は直前の文字がかな入力のものであればおそらく数字部分も漢字表記ですから後続も[度]にするのが推察できますしまたアラビア数字の数値の場合も[°]がくることが自然で収まりも良くなってきています。
セット間の移行は[123_]をタッチすれば([123\]改め)数字主体の「セットA」に移行し、(現セットはB)
[ABC#]をタッチすれば記号主体の「セットB」へと移行します。(現セットはA)
液晶を介してはいますが基本挙動はトグルで変わっていきます。
外部物理キーで移行するのではなく、液晶内の問題は同じ液晶内での変化にした方が意図がわかりやすいのではないか、との考え方です。
このようにして液晶・アルファベット/記号入力の基本形をリメイクいたしましたが、いずれは改訂版の基本コンセプトにも反映させていきたいかと思いますのでしばしお待ちください。
モード移行のごちゃごちゃからくる変換行程の不具合を物理的に完全分離してしまえば、キーの数は増えますがローマ字入力のように日本語なのにアルファベット音素を用いてかなを表すという二度手間がなくなりますし、
従来のかな入力でも日英混在の変換はいろいろと煩わしいものでしたがこちらは完全に役割を分けて、日本語かなクラスタキーは日本語だけ、タッチ液晶部は英数だけ、と住み分けが鮮明ですから何より字種の兼任ということがないので原理上も非常にすっきりします。
ただ液晶面は限られてきますし採用する文字をどうするか、あるいは液晶外のクラスタキーでの記号の取り扱いとなるべく被らないように必要な文字を広くカバーすることが重要になってきます。
それはそうと今まで日⇔英のモード移行について肝心のところを決めていなかったので今回配置図を用いて軽く触れておこうかと思います。
図１<標準入力モードと英直接入力モード切り替えのキーの位置>(クリックすると別タブが開き拡大します)
上図黄色く塗ってあるのが入力モードの切り替えのキーになります。
今までのキー形状に少し変更を加えて、ソリッドなキーであった[Enter]キーを斧の刃キーに替えて[英直接入力]/[Enter]の上下2方向に増置したのが大きな変化です。
これはMacの入力切り替え方法に倣っておりトグル式ではない即押しモード移行の仕方が直感的に分かりやすいのでこれと同様の非トグル切り替えにしました。
ネット各所でも自分が今どのモードにいるのかがわかりやすくWindowsよりも合理的だと好評でしたのでペンタクラスタキーボードとしてもこれを取り入れた形です。
今回の記事では切り替えの詳細を説明する前に準備のためにタッチ液晶部の文字セットがそもそも今のままでいいのかという見直しをこの際やってみるということで、
いわばメインの説明に入る前の地ならしという形で記号関係の取り扱いを根本から見直していこうかと思います。なのでここではモード切り替えについてはあえて次回の記事に回したいところですのでご留意ください。
さて現在改定後の定義によればタッチ液晶の文字類は、上段が
["][#][‘][’][-][^][~][|][逆スラッシュ]の「標準モード(仮)」と
[1][2][3][4][5][6][7][8][9][0]の「英数モード(仮)」としておりましたがいろいろ検討した結果「モード」は入力モードとの混乱をきたすもとになるのでまずは名称を改めて文字セットからとった「セット」の呼称を使っていこうかと思います。
あとは逆スラッシュの使用も言語環境の特殊性から色々と取り扱いの難しい記号ですのでこれをあきらめ、代わりになにか使い出のありそうな記号を新たに採用したいと思います。
ここは文章であれやこれや説明していくより配置画像をお見せする方が早いのでとりあえずそれをご覧いただいて後ほど説明をしていこうかと思いますのでどうぞ。
図２<液晶英数の文字セットA>
図３<液晶英・記号の文字セットB>
まずはモード名を混同するとややこしくなるので[文字セットA」と[文字セットB]という呼称を使います。
上段に数字キー1-0までの配列を持つ文字セットAにおいては元となった配列の採用文字から一部入れ替えを施して若干変更があります。
変更箇所は下段両袖にあった[€][￥][$]のキーをやめて、[@][-][_]を配置しました。￥や$は物理キークラスタキーにもありますし本当に必要そうな記号を吟味していったところ、
メールアドレス・ID・パスワードの入力でよく使われるであろう[@][-][_](アットマーク/ハイフン/アンダーバー)を優先した次第です。
こちらもクラスタキーと一部かぶってしまいはするのですが、重要度から鑑みて利便性に資すると判断したものです。
次に上段に各種の記号を配置してある文字セットBですが
["][#][‘][’][-][^][~][|][℃]と元から若干変えてあります。下部両裾は[@]-[;][:]と変更はありません。
逆スラッシュは現実的ではないので、何か他の頻出のものでいいものはないかと考えを巡らせましたが熟考の結果摂氏温度の記号[℃]を採用することとしました。
日本語話者では摂氏は一般的ですし、何よりもひとつ℃とキーを決めてしまえば、同じ音の記号の角度の[°]のときにはこちらは変換から出すときに突出候補となることで液晶入力[℃]との住み分けが自然にできていく…といった図式が期待できます。
漢数字の[度]は直前の文字がかな入力のものであればおそらく数字部分も漢字表記ですから後続も[度]にするのが推察できますしまたアラビア数字の数値の場合も[°]がくることが自然で収まりも良くなってきています。
セット間の移行は[123_]をタッチすれば([123\]改め)数字主体の「セットA」に移行し、(現セットはB)
[ABC#]をタッチすれば記号主体の「セットB」へと移行します。(現セットはA)
液晶を介してはいますが基本挙動はトグルで変わっていきます。
外部物理キーで移行するのではなく、液晶内の問題は同じ液晶内での変化にした方が意図がわかりやすいのではないか、との考え方です。
このようにして液晶・アルファベット/記号入力の基本形をリメイクいたしましたが、いずれは改訂版の基本コンセプトにも反映させていきたいかと思いますのでしばしお待ちください。
