On Apr 22, 2009, at 8:53 PM, Robby Findler wrote:
How about this: Mike has (I believe) string-constant-izied some files
so that he can use the testing code in German. I'll take what he's
done and abstract it slightly differently so that we just have two
versions, a German one and an English one and htdp will use one and
deinprogramm the other.
I think this is a fair compromise for now.
(But note that I don't think your first reaction is appropriate for
the start of this thread -- here we're localizing the PL that
implements a program (hdtp langs vs deinprogramm langs, not the
program itself. It does make sense for apps that are actually
localized to use the user's locale, but that is still a drscheme-level
issue (or maybe framework).)
A PL is just a scriptable app. So I think my reaction is basically on
the right track.
-- Matthias
Robby
On Wed, Apr 22, 2009 at 7:34 PM, Matthias Felleisen
<[email protected]> wrote:
Now I get it.
The natural language selection is a drscheme-specific preference,
because
that's where language selection is visible (has an effect).
So for teaching languages, the string-constants library stores the
current
"locale" in the preferences.
Ergo, when drscheme creates an executable for programs in TLs,
this program
suddenly depends on the preferences.
;; ---
I have two reactions to that:
1. Since people wish to build apps that are locale-specific (say
British
English vs German vs whoknowswhat), perhaps the DrScheme
preferences are the
wrong place to store this selection.
2. Teaching languages are perhaps the wrong place to teach the
creation of
locale-specific apps. BUT, for heaven's sake, we should be happy
that a
non-English speaking culture wishes to exploit our ideas and
software, let's
figure out to help them.
;; ---
Having said that, I am wondering how Java apps are localized.
Anyone know?
-- Matthias
_________________________________________________
For list-related administrative tasks:
http://list.cs.brown.edu/mailman/listinfo/plt-dev
