Re: Thoughts and questions about input

["Adam Sleight" <adams linearcorp com>]

I agree with Sahbaz about being able to quick change language input method
rather than changing all menus.

> Now switching between multilingual typing modes is different from
> switching between overall gui translation.  By that I mean an Urdu user
> may be using english version of X-windows, but just need the ability to
> type a few lines in Urdu--which is when we need quick and simple mode
> switching.  If the user wants his/her whole gnome environment to switch
> from displaying menus etc. in english to urdu, then I don't see a great
> need for quick changes (but then again I don't think Pango needs to worry
> about this anyway).
> 
> Shahbaz C.
> chaudhar@umich.edu
> 
> 
> On 12 Mar 2000, Owen Taylor wrote:
> >   
> >  - Modified Roman layouts.
> >  - Completely separate keyboard layouts (Russian, Arabic, Hebrew)
> >  - Full input methods (Chinese, Japanese) with preedit strings,
> >    status windows, etc.

status windows?  I'm only familiar with Japanese.  I hate when you have to look
at a small window to change kanji at the bottom of your screen and after
choosing it, it inserts it into whatever application.  I believe that is what
Netscape 4.72 on Windows currently offers.  IE5 has Japanese input capability
but only within IE5..(possibly Outlook too just guessing). When forced to use a
status window it is easy to lose concentration.  It's better to change whatever
Korean, Chinese, Japanese directly where the user is inputting text rather than
off to the side somewhere.
> > 
> > There are a few twists on these types. For instance, Thai is basically
> > just a separate keyboard layout, but there are prohibited combinations,
> > so there is a need for a simple input method to validate the input.

You can have tons of combinations...say for example someone choose Japanese
input method.  You can could input with a Japanese layout keyboard but I doubt
many people do it that way anymore.  Instead they just input romaji
(a,i,u,e,o,ka,ki,ku,ka,ko) rather than just "ka" as a single key.  Perhaps
allowing them to set a default as to when they change into a language of input
as to which keyboard layout would be nice.

> > 
> > While the main thrust of Pango is to allow people to work in their own
> > languages, I think that full multi-lingual input is a compelling
> > feature that we need to support. (Nobody would design a system that just
> > allowed entering Chinese, and not English. Why should Arabic + Chinese
> > be any different?). But I don't have a clear picture of how this
> > should look to the user.
> > 
> > 
> > I can think of a number of ways of switching languages:
> > 
> >  - via keyboard hotkey. (This is most suitable for toggling between
> >    two languages). 
> > 
> >  - via right-click menu on the input field. 

I light this option best.  In the control-panel they can choose which languages
that they wish to have available for switching and in the right-click icon at
the bottom they can choose amongst those 2 or 3 or however many they prefer.

> > 
> >  - via system setting. (This could be in a control-panel, or in
> >    a shortcut applet of some sort.)
> > 
> > 
> > In many cases, the expected behavior is that changes to the
> > language setting are global. In X right now, when you switch between
> > Russian and English keyboard layouts, this is not much different than
> > Caps Lock - the user sees it as a property of the keyboard. In
> > general, I think having a per-application language setting would be
> > confusing to the user, and having a per-input-field language setting,
> > worse.

yes it would be confusing...as far as one app having menus in a certain language
and saving them as default.  I think it's all Chinese or no Chinese and a
restart of X should be necessary..most likely.  Otherwise too many fonts would
have to be loaded?  I'm not sure actually how it works but it wouldn't be all
that inconvenient.

However, the user should be able to switch on the fly into their chosen input
method in any application.  In Japanese the HOTKEY is ATL-~ (squiggly character)
which toggles between English-Japanese. I think F7 is katakana and F8 is
hiragana (could be wrong). Would DnD be supported possibly.  Say if a user
inputted Japanese in gEdit and wanted to copy over to Gimp or Eye of Gnome
whatever..that would be cool.  Let's say the gEdit app had Japanese Input
selected and you dragged it over to Gimp which didn't have Japanese Input
selected..but would all GTK+ apps be able to at least read Japanese fonts and
not be able to manipulate them ...only of course if Japanese input method was
chosen.

> > 
> > But the same is not really the case when input methods come into the
> > picture. For XIM, the choice of the input method is basically under
> > the control of the application.  (It is based on the locale setting
> > when the input method is opened.) While an application can switch
> > input methods on the fly, it isn't going to propagate globally.

If it propagated globally then have a quick HOTKEY to revert back would seem
necessary.  I doubt most people will be switching back and forth between more
than two langauges, maybe three...at least 95% or so.  

> > 
> > We could put a "INPUT_LANG" property on the root window. GTK+
> > programs would watch that, and when it changes close the current
> > input method and open a new one. However, that possibly is going beyond
> > the realm of a toolkit's proper scope.
> > 
> > 
> > I'd appreciate people's thoughts and experience in the matter; some
> > questions I have:
> > 
> >  - How does switching input language appear to the user on other operating
> >    systems that support it? (I believe both the Macintosh and Windows 2000
> >    have support for this.)

Win98 English...with IE5 Japanese Input support...their is an icon..lower right
En and when switched to Japanese it appears Ja. Then you have choices (small
toolbar) of input method..Hiragana (use spacebar to select kanji), Katakana,
English, Half-size Katakana, Half-size Hiragana.

Under Win98 Japanese edition you can install Photoshop English edition and input
Kanji into Photoshop and render graphics, etc. with Kanji. This would be nice to
be able to do the same under Gimp.  Gimp having English menus with various input
methods for various languages and have it render in whatever character set.

> > 
> >  - Is it important (or even good?) to make the language setting appear
> >    to be global?

global...well it probably wouldn't be hard to do.  File, Save As, New,
Open..once they are translated it can reflect across all applications.  It may
look corny if some menu items were left untranslated though.  I think having the
users choose (translate known menu items into so-and-so language) could be an
optition.  Abiword for example, Korean...they would probably want all menu items
to be translated over though.  Many people throughout the world know no Enlglish
whatsoever...so any English would be scary.

Having some sort of defineable parameters like .po offers would be the best bet
and leave it up to the individual translators for each application to translate
the uncommon menu items.  Perhaps within each app it would show a menu list of
the languages that it has been completely translated into.  Thus, if it was
partially translated they'd know what to expect.

> > 
> >  - Should the keyboard state ever change by something other than
> >    a user action? (From what I've seen of Macintosh docs, if you
> >    are using Arabic, then clicking in a segment of Arabic or 
> >    English will switch the keyboard state to match the new segment.)

Win98 English does this with Japanese Input.  For example. Right now I'm typing
in IE5 webmail in English.  Another window I have Yahoo Japan open and selected
Japanese Input Method.  As I flip between them it changes.  However, I chose
Japanese input method.  It should never switch automatically unless the user has
choosen that input method for that window or app.  Just because I open a
document in that has some English and a little Japanese....it shouldn't
automatically switch to that Japanese language unless that was the input method
I had chosen when I save the document.  

> > 
> >  - Is supporting a single caret important for bidirectional
> >    languages? (As mentioned above, things becomes somewhat easier
> >    if you only support dual carets.) 
> > 
> >    [ A dual caret (used on the Macintosh and in Java) means that 
> >      if you are sitting on a directional boundary, then two carets
> >      are visible, distinguished by shape or color. One caret indicates
> >      where a RTL character will appear if typed, the other caret indicates
> >      where a LTR character will appear if typed. ]
> > 
> > Thanks,
> > 
> >                                         Owen