[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Editor Priorities


At Thu, 9 May 2002 02:27:38 -0500,
Branden Robinson wrote:

> > In case of visual/motor impairments, I completely agree it is 
> > important to support these users.  If there are any easy
> > technical way to improve usability for them without spoil our
> > usability, it should be adopted.  Unfortunately, I am not an
> > expert of this field and I don't have any idea.  However, when
> > someone would propose something in this field, I would never
> > oppose them.
> If we had a text editor designed for the visually impaired that was very
> frustrating for sighted users to operate, would you "never oppose" a
> proposal to make that text editor the default?


> > languages, because there are several editors and other softwares which
> > can handle CJK/bidi/... languages.  Why should we avoid giving priority
> > to such softwares?
> Because they might alienate and frustrate more users than they help.

Well, you also may be misunderstanding that multilingual softwares are
not useful for European-language speakers.  I will never agree to give
high priority for Japanese-only editors, even if there are many
European-languages-only editors.

> > I didn't hear any convincing opinion against it.  Anyway, I decided
> > to improve and internationalize terminal emulators.  It takes years
> > and now it is partly successful.  rxvt-beta and eterm have LC_CTYPE
> > sensibility support which is written by me.  I am also joining the
> > development of mlterm and try to improve xterm with Juliusz's luit.
> And that's exactly where this type of work *should* be going on.

It depends on cases.  In case of terminal emulators, there are not
so many implementations, and it is enough to improve a few of them.
On the other hand, there are so many editors.

And more, even for terminal emulators, I hope multilingual terminal
emulators will have higher priority, because not all terminal emulators
are multilingual.  Thus, I need to work in *both* fields, upstream
and Debian.

> Because you are undermining your own thesis.  Your position is that
> CJK/bidi/Indic/combining support is mandatory if Debian is stop its
> tradition of racist sin[1], and yet your own proposal doesn't even go very
> far to accomplishing that goal.  The low score you attach to it amounts
> to little more than using the alternatives mechanism as a forum for
> editorializing about how we ought be good little boys and girls and not
> disenfranchise the CJK/bidi/Indic/combining support community.

You mean, I should give more scores?  It may be true, because I
didn't examined my scores.

However, I wonder that all other items (undo/redo, and so on) are
well examined or not.  I think the scores for these items should
be reviewed *after* we determine the items to be adopted, because
what is important is *not* the absolute values of the scores, *but*
the relative values among terms.

> The point of this thread, if I recall correctly, is to improve the
> chances that a sysadmin -- regardless of his experience level with
> Unix-style systems -- will have a editor with sufficient functionality
> to carry out administrative tasks in a non-intimitdating way.  Frankly,
> until most of the files in /etc can be written in Devanagari or
> Japanese, I do not think a CJK/bidi/Indic/combining editor is very
> important for this goal.  I agree that is is suboptimal that Debian
> sysadmins who don't speak English have a river to cross when it comes to
> /etc.  I don't think CJK/bidi/Indic/combining (10) is going to do
> anything to help these people.

I understand your point.  However, I don't think the priority score
*must* be limited for sysadmin purpose.  There are a lot of scenes
where a software wants to invoke some text editor.

If you say that alternative mechanism is not a place for i18n,
where do you think is suitable?  I think alternative mechanism
*is* suitable.  When we have a method which can be used, I think
we should not re-invent similar mechanism.

>>  * 8bit clean (+20)
> Do we have any editors in Debian that *aren't* 8-bit clean?  Is this
> going to serve to differentiate anything?

I hope you have already read I wrote "I don't know" in the original
message where I introduced "8bit clean".  If there are no such editors,
European people don't have i18n problem in this field.  Then, please
don't disturb non-European people trying to solve this problem.

Tomohiro KUBOTA <kubota@debian.org>
"Introduction to I18N"  http://www.debian.org/doc/manuals/intro-i18n/

To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: