Re: lynx-dev Re: lynx should respect LANG

[Atsuhito Kohda]

From: Klaus Weide <address@hidden>
Subject: Re: lynx-dev Re: lynx should respect LANG
Date: Mon, 22 May 2000 23:25:43 -0500 (CDT)

> > Well, I do not know so well about the technical aspect
> > of this issue but I have used the $LANG value and it seems
> > to work fine for (at least) Japanese users.
> 
> That test doesn't go very far - that's just a binary decision,
> (if $LANG matches ja* then do Japanese; else do English).
> I assume you have tested only for one Language, and only in one
> environment (Debian GNU/Linux).

Oh yes, you are right.  It is tested only in Debian for only
Japanese.

> Even for ($LANG matches ja*) the situation is not so simple in general.
> Some ja* locales imply EUC-JP, others Shif_JIS, and maybe still others
> ISO 2022.
> 
> Locale names don't map cleanly and clearly to charsets.
(snip)
> 
> What if Lynx is running on a Windows system.  Then the display
> character set for a Japanese user should probably be Shift_JIS.
> (Yes, you are probably not interested in Windows - but if we
> are talking about adding some support in the source code, we have
> to consider that and canot just make UNIXish assumptions.)

I see your point and, yes, I considered only UNIX or even
only Linux and missed completely Windows.

But I would like to point out that in Windows it is perhaps 
common that Japanese version of lynx is distributed as a binary 
compiled by someone who does appropriate settings for Japanese
environment (for Shift-JIS for example).

And perhaps refined 'configure' can select the right way
of compilation according to whether it is compiled in Windows
or in UNIX like OS.

(Very sorry that my explanation is very abstract because
I do not know Windows at all and technical aspect neither.)

If I consider the separate package like lynx-ja for Debian
then the situation is very simple and is similar with Windows.
It will be sufficient for me to modify userdefs.h appropriately 
for Japanese users and to create lynx-ja package.

Perhaps FreeBSD or other distribution of Linux might do this 
kind of forking, I guess(Sorry if I misunderstand).

But I think this kind of fork is not good and it is much
better if one lynx package can work well for peoples
all over the world as far as we can.

> What if the user is telnetted in from a Windows system to a
> Unix system - I assume that's not uncommon at all - then Lynx's
> display character set should probably also be Shift_JIS.

I missed this situation but I think this can not handle well
in any way unless a user set up appropriately by himself.

> That's just one of many open questions, that have to be answered
> in order to do this right in general (not just for EUC-JP Japanese).
> 
> Basically, the locale concept doesn't map very well to what lynx
> does, IMO.  At least, the idea of controlling a program's localized
> behavior by just one (set of) environment variable(s) is not really
> sufficient.  Lynx is more powerful than that; basically every
> application that deals with text in more than one character encoding
> is.

I can see that this is essentially difficult problem.

And I have no knowledge at all to answer this.  But
I hope that members of lynx-dev might find out some appropriate
and realistic solution in this point.  As I said before

> > In any way, I do not care what method to be used to determine
> > preferred language but I think it is important that lynx
> > has some mechanism to select automatically the preferred
> > language.

this is all I can say now (very sorry).

> But what you are suggesting (if I understand it right) isn't really
> automatic.  Someone, somewhere, still has to set LANG (or LC_*?)
> correctly, at least.  If that's just as system-wide thing (set up
> by the administrator), then the administrator could just make an
> equivalent setting in the system-wide default lynx.cfg.
> To allow users to customize their environment (deviating from the
> system-wide default) with this method, they have to be taught to set
> LANG correctly; that's not so much different from teaching them to
> set up lynx corrrectly themselves.

No it is not so, I think.  In this point, at least in Japan
and in Linux or *BSD environment, the situation is the one you
just stated in the following;

> For situations where one can assume that $LANG has been set up in a
> meaningful way, and is already used to control other progams'
> behavior, it probably makes sense to derive some of lynx's relevant
> settings from $LANG - at least as initial defaults.

Unless a user set $LANG appropriately, Linux or *BSD is not usable 
at all for Japanese users so it can be safely assumed that $LANG is
set up correctly.  And I think, yes, only as initial defaults.

> settings from $LANG - at least as initial defaults.  But they will
> still be wrong for some users and some situations, even if we can come
> up with a meaningful answer to "What's $LANG supposed to mean".  So
> I'm not sure how much of that really belongs in lynx code.

You say it is not complete so it is doubtful it needs to belong 
in lynx code but please think a bit realistic.  Compare lynx which
can change its behavior corresponding to some environment variables
and the present lynx which is set up only for English by default.

I think we would get not so small benefit from lynx which can change 
its behavior corresponding to some environment variables even if
it is far from complete.

Best Regards,                   2000.5.23

--
 Debian JP Developer - much more I18N of Debian
 Atsuhito Kohda <address@hidden>
 Department of Math., Tokushima Univ.

; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden