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.
ok? Mike, want to send me the files?
(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).)
Robby
On Wed, Apr 22, 2009 at 7:34 PM, Matthias Felleisen
<matthias at ccs.neu.edu> 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
>>