Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[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