[REBOL] Re: locale Re: Re: %Maoww_english.r
From: carl:cybercraft at: 24-Aug-2002 16:40
On 24-Aug-02, [mh983--attbi--com] wrote:
> for what it's worth, I think the last one is the best approach: have
> one file per language and use named constants for the different
> strings you need. This way, you only need to get the files for the
> language(s) you want and adding another language to your
> installation is just a matter of getting one more file.
I agree. It should be as simple to add another language as possible
so people actually go to the trouble to do it.
Where would the script find the user's language, though? Should it
just be a word defined in user-startup? locale: "English" or
(perhaps the more REBOL-like) language: "English"? View has a
user-prefs object, but core doesn't, (though you could easily add one
of course), so perhaps that's the more appropriate place for it to
be?
> It would be nice to write an interface to the language file: you
> give it a filename (based on the language) and it loads and parses
> the file. Then you ask this object for the string with a given
> constant name. Now the use of the locale based strings is separated
> from the definition of those strings. Just my two cents.
>> 3) last but not least - on Amiga, IIRC, if e.g. system was switched
>> to Czech, and there was no catalogu available for czech language,
>> default one was used ... how to set (and where) what is default?
It should be in the script itself, as then there won't have to be a
minimum of two files for every script that's written. If a language
file's found that's the same as the default though, the file should
take precedence over the one in the script. That way updates to just
the language file can be made.
>> under AmigaOS:
>> /catalogs
>> myapp.czech
>> myapp.spanish
>> etc.
>> so maybe we would be too - better with separate file per language?
>> myapp.english (or myapp.default?)
>> [MENU_ITEM_1 "Open ..."
>> MENU_ITEM_2 "Close"
>> ]
>> get-locale: func [my-app /local temp][either not exists? temp: join
>> to-file my-app current-locale [join to-file my-app
>> ".default"][temp]
>> my-app-locale*: load get-locale my-app
>> Well, just a brainstorming ... you get the idea .... Anyway - I
>> will need similar system sooner than later, so if you are not lazy,
>> let's develop it further :-)
Let's. (:
A script's header is supposed to contain its file-name, so joining
that (minus the .r) to the user's language name would be the way to
get the file-path.
Maybe the language definitions should be an object? ie, create the
default so...
locale-words: make object! [
menu-item-1: "Open..."
menu-item-2: "Close"
]
and then if there's a file to over-ride the default, just load it
and...
locale-words: make user-locale
user-locale being a block of set-word!/any-type! pairs. That'd have
the advantage of keeping any default words that were missing from
user-locale.
We also need to consider that gfx (and sounds?:) might also need to be
localised, so best to make it so that any data can be localised if
the programmer thinks it should be allowed, which is why I put the
any-type! in the above.
--
Carl Read
