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 23:44

On 24-Aug-02, Petr Krenzelok wrote:
> Carl Read wrote: >> 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. > hmm, that's the question of using block vs. object. if you use > object - you define words.
But it's most likely programmers will define them anyway, else how else are they going to use them? If not something like this... lw: locale-words view layout [choice lw/menu-item-1 lw/menu-item-2] then how? Nothing to stop them using blocks of strings to cut down on the word definitions of course... lw: make object! [ menu-1: ["Main" ["Open..." "Close"]] menu-2: ["Edit" ["Cut" "Copy" "Paste"]] ] view layout [ across title lw/menu-1/1 100 title lw/menu-2/1 100 return choice lw/menu-1/2/1 lw/menu-1/2/2 choice lw/menu-2/2/1 lw/menu-2/2/2 lw/menu-2/2/3 ] Okay - would work with this too... lw: [ menu-1 ["Main" ["Open..." "Close"]] menu-2 ["Edit" ["Cut" "Copy" "Paste"]] ] so I guess an object's only advantage would be the ease of replacing the old with the new while keeping any words that haven't be included in the new language.
> Block offer more dynamic aproach imo: > locale-words [menu-item-1 "Open..."] > few handlers could be defined as well - remove-locale-item, > add-locale-item, replace-locale-item or so ... > but generaly - it is not probably so important, if it will be block > or object ... > Now let's say you use IOS - you centrally switch it to Czech > language. So - each app should know somehow, it should try to use > Czech language catalogue. How to do it?
Others can sort that out - I've not tried IOS yet...
> And also - versioning - reblets are changed dynamically - so, > someone posts new reblet, containing new UI item. You switch to > Czech language, but your catalogue is old, and item not found - will > you a) stay with english (default) language b) use Czech (selected) > one, and on missing items use default language, so e.g. new button > will be in English, while other UI items will be in Czech?
Hmmm. That could be a problem, as you could end up with some very old language versions. Maybe the languages should state which script version they were created for and the programmer should have the script decide at which point old versions shouldn't be used?
>> 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