[Uim] [Docs] Terminology problems

[Jan Willem Stumpel]

Martin Swift wrote:

> Hi Jan,

> [..] In your terminology, a monolithic software that converted 
> to a single language is an "input method" while if it were 
> modularized and catered to multiple characters, an "input 
> method framework".

But if modularized, it would not monolithic! So yes, I would call
it a framework.

I think uim is a *framework* which has a few *input methods*
shipped with it (as a sort of demos, but actually usable) by
default (like hangul2/3, romaja, py). In principle, it could be
shipped without them; but that would not be good marketing -- the
user should be able to do something with uim "out of the box".

Other "methods" can be plugged in, like anthy, and the whole m17n
collection. scim and IIIMF are likewise frameworks; for instance
ATOK can be plugged into IIIMF.

Interestingly, in the case of uim, when you install m17nlib, none
of the methods offered by m17n are accessible to uim by default.
You can make them available (or un-available) individually.

A "framework" in my view is a system that allows different
"methods" to be plugged in, offering a common user interface (like
uim's toolbar) and ensuring that the various "methods" do not
interfere with each other. I *think* that different frameworks
ought not to be active together on the same system (you can have
both uim and scim *installed* on the same system, but they cannot
be active at the same time, or you will get problems).

> What about modularized software that "could" be extended to use
> other IMs but isn't and won't?

> Inversely, what about monolithic software that clumps together 
> various character conversions?

If such a thing exists (perhaps m17nlib is one, but it is not
monolithic) I would call it an "input method collection". The
whole "collection" could possibly be plugged into an "input method
framework" like scim or uim, to make it available through a common
user interface.

> It seems more logical to me to use:

> * "input method" for any software that offers a complete system
>  of converting input.

What do you mean by "complete" here? A complete method for one
language, or something capable of doing input in all the world's
languages?

I chose my terms because "input method" has traditionally been
used for things like anthy and canna (for one language). Things
like uim / scim / IIIMF (with extensibility for all languages) are
relatively new. So it may make sense to invent some new word for
them.

> * "conversion engine" as a part of a modularized "input method"
>  that does the conversion.

> * "dictionary" as the ruleset that a "conversion engine" uses.

> I don't know if this makes sense or is practical but seems 
> useful to me as (from my reading up on IMs) some input methods 
> switch conversion engines (e.g. from Anthy to PRIME) and 
> conversion engines could also, in principle at least, switch 
> between dictionaries (lookup tables) and Anthy seems to have a 
> personalizable dictionary feature.

> In this language, Anthy would be a used by the "input method" 
> uim as a "conversion engine". Does uim delegate it's job to the
> "input method" Anthy, or does uim use an internal part of
> Anthy (then better termed "conversion engine")? If all uim does
> is delegate its job to other input methods, then, yes, Jan's 
> terminology of "input method frameworks" might fit better.

I _think_ that is what uim does (delegating the actual work to
anthy, only handling things like catching the keystrokes, and
pushing anthy's output to the application that the
keystrokes came from), but the experts should answer this.

I am not so sure that it is useful (for user-level documentation)
to make a distinction between an input method (or as you call it,
a conversion engine) and a "dictionary" (the actual set of
internal rules that the method/engine uses). For the user, the
"method" (or "engine") is how it behaves. And this is completely
determined by the rule set it happens to use at the given moment.

I suppose you would consider the m17n lib to be one "conversion
engine" with many different "dictionaries". But I think that
calling it a "collection of many different input methods" (which
can be plugged into a framework like uim/scim/IIIMF) is more
understandable to users.

Sorry, I made a typo in the URL of my site on "international text
on Linux". It should be http://www.jw-stumpel.nl/stestu.html

See section 6, especially 6.4. As stated there, in my opinion, one
of the great points about uim is that it has an "off switch" (i.e.
the "direct" input method, leaving all keyboard settings by the
user intact). scim does not have this; don't know about IIIMF.

Regards, Jan