Re: [Gnu-arch-users] Re: Extension language

[Charles Duffy]

On Sat, 2003-10-18 at 02:48, address@hidden wrote:
> You do know that translations have to be seperately installed, and compiled,
> don't you?   If the user does not have the encoding enabled and 'compiled'
> your lost.   And have you ever tried to convince your machine to talk german
> (for example) to you in your shell?  I can promise you that normal users don't
> have any idea how to do that.

*sigh*.

No, translations do not need to be separately compiled and installed, if
the architecture you're using to maintain them is anything approaching
sane. Using gettext, for instance, one (1) binary of the app handles any
available language. As long as gettext is being used, and your
"translation" is bundled with the primary app, just set the LANGUAGE
environment variable before calling to your subshell, and bam, it's
done.

Now, traditionally, all I've ever dealt with is setting the environment
variable LANGUAGE to "C" (or whatever else you're willing to write yer
parser to) before calling the app to ensure that it isn't using an
unfamiliar language table, and that *works*.

It doesn't matter whether "normal users" know how to do this or not --
we're a programmatic interface, we can afford to know how to do more
than an average user can.

Simply put, you're making this sound waaay harder than it is.

> This effectively is a lot harder then any other solution I have seen.

Setting an environment variable to ensure you're using a known
translation table (or, if appropriate, a specifically created
translation table) is so bloody difficult? I'm sorry, but I simply don't
believe you.

> Are you talking from experience; or just think this might be a cool solution?

Done it before, but not in this particular context.

> > Sure it (subprocess control w/o an intervening shell) works from Perl or
> > Python, and I'm pretty sure Java. Likewise on win32.
> 
> The above (scsh) does not provide it; system calls /bin/sh, so how is this
> done?  Making a technical decision based on "I'm  pretty sure Java can.."
> is rather weak since I just told you it can't.  So you would really be better
> off providing really good evedence instead of just calling me (implictly) a
> lyer.

I'll tell you exactly how it bloody well works, you don't use system but
rather fork and one of the many java.lang.Runtime.exec variants. (BTW, I
didn't call you a *liar*, I called you *wrong*; there's a substantial
difference).

> Btw; if you do know of a way to sidestep a shell; then you also can't put
> env variables in your shell-environment anymore.  Making your first argument
> moot.

Environment variables aren't shell-specific -- every process has 'em. Go
learn how yer bloody OS works before making blatently false statements
in public.

> My point in the email you replied to was that Tom only said "no you are wrong"
> kind of arguments, which really did not contain any viable arguments at all.

Tom's email made plenty of sense -- presuming an audience having the
background to appreciate his arguments. In the case of folks needing
additional background information to understand where Tom was coming
from -- there, I can see where you're coming from.

> I really hope that you guys take advantage from each others experiences here;
> and start to act a bit more mature,  since 'yes'/'no' fights without content
> are really boring to look at.

I don't think the arguments are quite so content-free as you interpret
them to be, presuming one has the relevant background (ie. everything I
said here, excepting of course the wrong bits[:)], which ought to be
pretty damn obvious to someone who's been doing UNIX a while -- and Tom
et all have been doing it far, far longer than I).

> And the resulting software is also going to be really weak.

The software is already very, very far from weak.