アカウント名:
パスワード:
世の中にはWebベースの業務システムっていうものがいっぱいある。こういうシステムで、定型的な入力作業（たとえば何かの申し込み情報のデータエントリーとか）を最適化するのに、IME制御が有効な場合は多い。
例えば住所氏名を入力する場合、
郵便番号を入力→（TABで次の欄へ）→住所を入力→（TABで次の欄へ）→氏名を入力→（TABで次の欄へ）→電話番号を入力
っていうのを下手すると一日何100件も繰り返すことになる。こういう場合は、IME制御があるとないとでは入力効率がぜんぜん違う。
この判断は、実務をまったく分かっていない馬鹿エンジンニアが判断したとしか思えない。
そこまで大変なら、受け付けた後で自動変換すりゃええやん。一般ユーザ向けについては、「ユーザ様がご入力された文字列に手を加えるなんてまかり成らん」という暗黙のルールがあるから無理でも、仕事対仕事なら、「仕様です」で済む話やん。
受け付けた後で自動変換すりゃええやん。
douiukizyunndezidouhennkannsurunoyo?という入力を、どういう基準で自動変換するのよ？
ってサーバー側で変換するのって結構大変だと思います…。
勘違いされている方が多いですけど、入力を受け付けるプログラム側でのIME制御は「入力内容を制限する機能」ではなく「ユーザーの手間を減らす便利機能」なんですよ。Web画面上でIME制御をしていたって、Webサーバー側のチェック機能はひとつも減らないんです。ただ、定型的な入力処理を100回も200回も行うような入力画面（それがネイティブアプリであろうとWebアプリであろうと）ではユーザビリティが大きく向上する便利機能になるわけです。コールセンターなどの対応時間の短縮を要求されるような現場などでも「全角／半角」の切り替えをユーザー側に委ねずシステム側で制御することが要求されたりもします（例えば、次々に来る問い合わせ内容を画面入力していくのに一々切り替えをしてられない、という感じ）。
逆に、（オレは）その画面は1度しか使わないんだから制御は不要だ、というユースケースもあるわけで、こちらの意見にも一理あるとは思うんです。結局これはユーザーの好みの話であって、
a. IMEは全てプログラム側で適切に制御されることを望む人（非対応アプリも許さん！） b. IME制御は完全にユーザー側にハンドリングさせるべきと考える人（アプリケーション側での制御は全て禁止だ！） c. どっちでもいい（おそらく大多数）
という感じに分かれるとは思うんですが、現実には、非対応のアプリも存在するし、上記のようにアプリ側で制御したい現場もあるわけで、a. と b. を「OSレベル／プラットホームレベル」両立させることは難しいのではないかという気がします。そうなると、全ての「非対応アプリ」を対応アプリにさせていくのは非現実的なので、b. の、制御されたくない側の人が利用できる機能として「アプリ側からの制御を無視する」という機能を、IMEそのものやプラットホーム側（OS／Webブラウザ）の機能として用意するのがベターなのではないかと考えますね。
まあ、私もそこが本質的には落としどころだろうと思います。馬鹿かどうかは置いておくとしても、現実問題として現実の問題の解決策が提示されないのは問題だと思うし。W3Cに意見を送れば解決するとも思われない。こういうものが出てくる時点で違う文化を無理やり展開しているように思える。
えーと、そもそも、アクセシビリティの話なんだと思うよ。
IMEの定義が「アルファベット→漢字」変換な人には言っても無駄だけど、タッチパッドで仮想キーボードがせりあがってくるのもIMEの一種なんだから、IMEを禁止するとアルファベットすら打てなくなって、入力フォームそのものが死んでしまう。音声入力だってIMEだし、もう、ウェブサイトにアクセスしてくる機器に必ずキーボードがついているという幻想は捨てなければいけない。ただし、入力装置自体が何もないというところまでは想定しなくてもよいから、IMEの制限は余計なお世話ってことなんだろう。
だから、やるとすれば、input要素のtype属性の値に"ascii"を追加して、asciiをどうやって入力するかはIMEが決めればいい。
君がばかなことはよくわかったのでもう書き込みしないでほしい
サーバー側でIME呼び出して、候補に対して学習ベースで評価値を得てソートすればいいだけでは...どちらかというとそのほうがサーバー側で変換精度をカスタムできるし、より優れていそう。
まあ学習アルゴリズムとか書いたことがなければ仕方ないかもね。まともにCSやってないってことだし。
>> 受け付けた後で自動変換すりゃええやん。>douiukizyunndezidouhennkannsurunoyo?>という入力を、>どういう基準で自動変換するのよ？
同じローマ字文字列や、同じひらがな文字列で区切り位置が違うので別の文字列に変換されるのなんていくらでもあるわけで。
どうやってそこを”入力者の意図にそって正しく区切るの？”（今はＩＭＥを矢印などで操作してるわけだが）「橋を架ける（はしをかけるーhasiwokakeru）」と「橋を駆ける（はしをかけるーhasiwokakeru）」とかサーバーサイドでどうするつもり？
日本語理解してないでしょ、あなた。
さらに英字の「hasiwokakeru」のままが正解な場合もありえますからね。サーバ側でどうにか出来る問題じゃないです。
実はタイプミスで二つ目は 「端を駆ける」を入れるつもりだったり。
「花と鼻をなんとなく使い分ける」なんてのも、花が先か、鼻がさきか。 「なんとなく」か「何となく」か「何と無く」か。
鼻と花が同音意義、なんとなくが区切りの問題。どうやってサーバーサイドでやるのやら。
変換候補返すだけでも、文字列の長さによっちゃ数十から数百いきますね、数百のリストから選べとでもいうのかね？
住所はまぁデータベース引っ張れば一発で収束しますが、氏名とかどこに収束するんでしょうね？元コメを引用したのは評価しますけど、そんなに全力で私は哀れな馬鹿です宣言しないでください。笑っちゃった自分が言うのもなんですが、ギャグとしてもそれはどうかと思います。
学習したところで、一番使われてるのが正解とは限らないんだから、サーバーサイドで決めようがないって話なんだがな。
「ほんとに日本語理解してないんだね」「バカは自分がバカと理解できないって本トだね」
>douiukizyunndezidouhennkannsurunoyo?>という入力を、>どういう基準で自動変換するのよ？
なんでそっちに寄せるのよ。仕事中は、IMEはONのままにしとけ、と社内教育して、
どういう基準で自動変換するのよ？＃２７６８６５４
の2行目を、#2768654に自動変換すりゃええやん。
まあ、個人的に、何も考えていない善意のお節介に迷惑をかけられることを極端に忌避する原理主義に偏ってるんだけど。許してしまうと、昔のWindowsの、「電源を切る/再起動ダイアログ」の「開いたときのデフォルトが前回押したボタン」仕様とか、(電源は毎晩切るけど、再起動は滅多にや
単純にime-mode自体は実装して、指定されてなければ制御なし、指定されていればそれなりに制御するというので十分ではないかな？
それとも、スマートフォンの影響かなあ。スマートフォンでなんかを前提に、タッチパネルの仮想キーボードとIMEを同一視するなら、文字入力時に必ず使うのだから、ime-modeなんか実装する必要がないという割り切りなのかなあ。
もっとも、VBベースの業務アプリでできていたＩＭＥ制御と同じレベルのものを要求されて困ったことは何回もある。
Web”ブラウザ”なので、見るのが主体の道具がaの尻拭いをするのもどうかと思いますがね。Excel方眼紙ほどでは無いにしても、やりきれないなぁ。。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stableって古いって意味だっけ？ -- Debian初級
現実を知らない判断 (スコア:0)
世の中にはWebベースの業務システムっていうものがいっぱいある。
こういうシステムで、定型的な入力作業（たとえば何かの申し込み情報のデータエントリーとか）を最適化するのに、IME制御が有効な場合は多い。
例えば住所氏名を入力する場合、
郵便番号を入力→（TABで次の欄へ）→住所を入力→（TABで次の欄へ）→氏名を入力→（TABで次の欄へ）→電話番号を入力
っていうのを下手すると一日何100件も繰り返すことになる。こういう場合は、IME制御があるとないとでは入力効率がぜんぜん違う。
この判断は、実務をまったく分かっていない馬鹿エンジンニアが判断したとしか思えない。
Re: (スコア:0)
そこまで大変なら、受け付けた後で自動変換すりゃええやん。
一般ユーザ向けについては、「ユーザ様がご入力された文字列に手を加えるなんてまかり成らん」という暗黙のルールがあるから無理でも、
仕事対仕事なら、「仕様です」で済む話やん。
Re:現実を知らない判断 (スコア:1)
douiukizyunndezidouhennkannsurunoyo?
という入力を、
どういう基準で自動変換するのよ？
ってサーバー側で変換するのって結構大変だと思います…。
勘違いされている方が多いですけど、入力を受け付けるプログラム側でのIME制御は「入力内容を制限する機能」ではなく「ユーザーの手間を減らす便利機能」なんですよ。
Web画面上でIME制御をしていたって、Webサーバー側のチェック機能はひとつも減らないんです。
ただ、定型的な入力処理を100回も200回も行うような入力画面（それがネイティブアプリであろうとWebアプリであろうと）ではユーザビリティが大きく向上する便利機能になるわけです。
コールセンターなどの対応時間の短縮を要求されるような現場などでも「全角／半角」の切り替えをユーザー側に委ねずシステム側で制御することが要求されたりもします（例えば、次々に来る問い合わせ内容を画面入力していくのに一々切り替えをしてられない、という感じ）。
逆に、（オレは）その画面は1度しか使わないんだから制御は不要だ、というユースケースもあるわけで、こちらの意見にも一理あるとは思うんです。
結局これはユーザーの好みの話であって、
a. IMEは全てプログラム側で適切に制御されることを望む人（非対応アプリも許さん！）
b. IME制御は完全にユーザー側にハンドリングさせるべきと考える人（アプリケーション側での制御は全て禁止だ！）
c. どっちでもいい（おそらく大多数）
という感じに分かれるとは思うんですが、現実には、非対応のアプリも存在するし、上記のようにアプリ側で制御したい現場もあるわけで、a. と b. を「OSレベル／プラットホームレベル」両立させることは難しいのではないかという気がします。
そうなると、全ての「非対応アプリ」を対応アプリにさせていくのは非現実的なので、b. の、制御されたくない側の人が利用できる機能として「アプリ側からの制御を無視する」という機能を、IMEそのものやプラットホーム側（OS／Webブラウザ）の機能として用意するのがベターなのではないかと考えますね。
Re: (スコア:0)
まあ、私もそこが本質的には落としどころだろうと思います。
馬鹿かどうかは置いておくとしても、現実問題として現実の問題の解決策が提示されないのは問題だと思うし。
W3Cに意見を送れば解決するとも思われない。
こういうものが出てくる時点で違う文化を無理やり展開しているように思える。
Re: (スコア:0)
えーと、そもそも、アクセシビリティの話なんだと思うよ。
IMEの定義が「アルファベット→漢字」変換な人には言っても無駄だけど、タッチパッドで仮想キーボードがせりあがってくるのもIMEの一種なんだから、IMEを禁止するとアルファベットすら打てなくなって、入力フォームそのものが死んでしまう。音声入力だってIMEだし、もう、ウェブサイトにアクセスしてくる機器に必ずキーボードがついているという幻想は捨てなければいけない。ただし、入力装置自体が何もないというところまでは想定しなくてもよいから、IMEの制限は余計なお世話ってことなんだろう。
だから、やるとすれば、input要素のtype属性の値に"ascii"を追加して、asciiをどうやって入力するかはIMEが決めればいい。
Re: (スコア:0)
君がばかなことはよくわかったのでもう書き込みしないでほしい
Re: (スコア:0)
サーバー側でIME呼び出して、
候補に対して学習ベースで評価値を得てソートすればいいだけでは...
どちらかというとそのほうがサーバー側で変換精度をカスタムできるし、より優れていそう。
まあ学習アルゴリズムとか書いたことがなければ仕方ないかもね。まともにCSやってないってことだし。
>> 受け付けた後で自動変換すりゃええやん。
>douiukizyunndezidouhennkannsurunoyo?
>という入力を、
>どういう基準で自動変換するのよ？
Re: (スコア:0)
同じローマ字文字列や、同じひらがな文字列で区切り位置が違うので別の文字列に変換されるのなんていくらでもあるわけで。
どうやってそこを”入力者の意図にそって正しく区切るの？”（今はＩＭＥを矢印などで操作してるわけだが）
「橋を架ける（はしをかけるーhasiwokakeru）」と「橋を駆ける（はしをかけるーhasiwokakeru）」とか
サーバーサイドでどうするつもり？
日本語理解してないでしょ、あなた。
Re: (スコア:0)
さらに英字の「hasiwokakeru」のままが正解な場合もありえますからね。
サーバ側でどうにか出来る問題じゃないです。
Re: (スコア:0)
実はタイプミスで二つ目は 「端を駆ける」を入れるつもりだったり。
「花と鼻をなんとなく使い分ける」
なんてのも、花が先か、鼻がさきか。 「なんとなく」か「何となく」か「何と無く」か。
鼻と花が同音意義、なんとなくが区切りの問題。どうやってサーバーサイドでやるのやら。
変換候補返すだけでも、文字列の長さによっちゃ数十から数百いきますね、
数百のリストから選べとでもいうのかね？
Re: (スコア:0)
そちらはそもそもの問題設定を正しく理解できてないんですから哀れですなあ。
> 郵便番号を入力→（TABで次の欄へ）→住所を入力→（TABで次の欄へ）→氏名を入力→（TABで次の欄へ）→電話番号を入力
特殊用途で、さらにおそらく大量の人間が継続的に使うんだから、
機械学習の収束速度は一般の入力を想定しないといけないIMEよりも簡単なのは当然でしょう。
サーバー側でカスタムとはそういうこと。
住所入力用の欄ならば 「どういう基準で自動変換するのよ？」「はしをかける」 なんて入力を想定する必要はな
Re: (スコア:0)
住所はまぁデータベース引っ張れば一発で収束しますが、氏名とかどこに収束するんでしょうね？
元コメを引用したのは評価しますけど、そんなに全力で私は哀れな馬鹿です宣言しないでください。
笑っちゃった自分が言うのもなんですが、ギャグとしてもそれはどうかと思います。
Re: (スコア:0)
学習したところで、一番使われてるのが正解とは限らないんだから、サーバーサイドで決めようがない
って話なんだがな。
「ほんとに日本語理解してないんだね」「バカは自分がバカと理解できないって本トだね」
Re: (スコア:0)
>douiukizyunndezidouhennkannsurunoyo?
>という入力を、
>どういう基準で自動変換するのよ？
なんでそっちに寄せるのよ。仕事中は、IMEはONのままにしとけ、と社内教育して、
どういう基準で自動変換するのよ？
＃２７６８６５４
の2行目を、#2768654に自動変換すりゃええやん。
まあ、個人的に、何も考えていない善意のお節介に迷惑をかけられることを極端に忌避する原理主義に偏ってるんだけど。
許してしまうと、昔のWindowsの、「電源を切る/再起動ダイアログ」の「開いたときのデフォルトが前回押したボタン」仕様とか、
(電源は毎晩切るけど、再起動は滅多にや
Re: (スコア:0)
単純にime-mode自体は実装して、指定されてなければ制御なし、指定されていればそれなりに制御するというので十分ではないかな？
それとも、スマートフォンの影響かなあ。スマートフォンでなんかを前提に、タッチパネルの仮想キーボードとIMEを同一視するなら、文字入力時に必ず使うのだから、ime-modeなんか実装する必要がないという割り切りなのかなあ。
もっとも、VBベースの業務アプリでできていたＩＭＥ制御と同じレベルのものを要求されて困ったことは何回もある。
Re: (スコア:0)
Web”ブラウザ”なので、見るのが主体の道具がaの尻拭いをするのもどうかと思いますがね。
Excel方眼紙ほどでは無いにしても、やりきれないなぁ。。