Re: Fwd: [i18n] Input Method and Fonts improvements for Gutsy
On Sat, Aug 11, 2007 at 09:10:57AM -0500, Ming Hua wrote:
> On Sat, Aug 11, 2007 at 11:26:08AM +0100, Matt Zimmerman wrote:
> > Ubuntu does in fact use tasks, though they aren't presented to the user by
> > default in the installer, as in Debian. I'm curious why you feel that the
> > distinction between main and universe is an issue here.
>
> Oh, I didn't know that Ubuntu also uses tasks. But I think most Ubuntu
> installation use language-support packages instead of tasks to install
> input methods anyway.
That much is correct, yes.
> My understanding (which may be wrong) is that all language-support
> packages in Ubuntu are main packages, and therefore all their
> dependencies are also main packages. I think this also makes Ubuntu
> developers want to minimize the number/size of supported (does supported
> seed equal to main?) packages, leading to the decision of using SCIM for
> input method support for all languages. However, as I wrote, it may not
> be optimal from a user's point of view.
language-support packages are part of the default installation (depending on
the language selected), and therefore they may depend only on fully
supported packages (i.e. main).
It is naturally preferable to support fewer packages, if they can do the
same job as a larger number of packages, but the ultimate priority is of
course the user experience. If the scim methods do not work for some
languages, and there exists an alternative which is maintained and
supportable, then we would consider using it instead.
> In Debian, however, tasks can depend on (include? -- since missing
> dependency in tasks in not fatal) input method packages as long as they
> are in the archive, without going through the "main inclusion process"
> as they need to do in Ubuntu. So many tasks include more than one input
> method packages, and quite some of them don't use scim at all. As
> im-switch is essentially an alternative system, users can then use
> im-switch to choose the input method he/she prefers. I doubt Ubuntu
> will be willing to support multiple input method packages.
We would prefer to standardize on one approach per language, yes, and
devote our efforts to ensuring a good quality implementation of that one
approach, rather than offering many alternatives.
> SCIM doesn't have the best support for all languages, its biggest
> advantage is multi-language support. SCIM also has its own shortcomings,
> the most infamous one being causing crash in GTK+ applications linked to
> libstdc++5 [1,2,3], which means firefox from mozilla.org, Adobe acroread,
> ATi proprietary video driver, etc.
This sounds more like a bug than a shortcoming; can it not be fixed? It
sounds like a dynamic linking issue, and there are folks around who know
that part of the stack much better than I do.
> For users only using one language (or English and another language only),
> they have many reasons to prefer another input method. Debian's task
> system can support this easily. Ubuntu's language-support package system
> doesn't seem to be supporting this now, and I don't feel it will support
> this unless there are significant changes in the way input method packages
> are developed/tested and in the main inclusion process.
Your concerns seem to have nothing to do with the language-support packages
or with tasks, but rather which packages we choose to use by default to
provide input method support.
Our policy should be to use the best method for each language, while
respecting the need for these packages to be supportable. We do not wish to
ship unmaintained software, but this does not mean that we cannot consider
reasonable alternatives where they exist.
--
- mdz
Reply to: