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

locale Re: Re: %Maoww_english.r

 [1/10] from: petr::krenzelok::trz::cz at: 23-Aug-2002 19:44


Jason Cunliffe wrote:
>>And if you want czech translation - I'll try my best :) >> >> > >Yes please. It would be nice to get Volker's multi-language block approach >going.. >./Jason >
OK, trying once again, with mozilla settings slightly changed ... I earlier outlined how localisation could work. I think that simple strings in block - flat structure - is not enough. If you think in terms of AmigaOS e.g., user will want to switch his desktop to Czech e.g., and will expect all his apps to appear in Czech. How do you know what position in block is Czech language at? What about something like: 1) locale: [ english [ "this" "that" "something" ] czech [ "toto" "tamto" "neco" ] ] locale*: locale/czech ; or locale*: select locale 'czech ; or 2) maybe we have to think in terms of named system messages (constants) .... locale: [ MENU_ITEM_1 [ czech "Otevrit ..." english "Open ..." ] locale/MENU_ITEM_1/czech ..... 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? 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 :-) -pekr-

 [2/10] from: mh983:attbi at: 23-Aug-2002 20:03


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. 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. mike

 [3/10] 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
<<quoted lines omitted: 4>>
>> 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
<<quoted lines omitted: 13>>
>> 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

 [4/10] from: petr:krenzelok:trz:cz at: 24-Aug-2002 12:07


Carl Read wrote:
>Let's. (: >A script's header is supposed to contain its file-name, so joining
<<quoted lines omitted: 12>>
>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. 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? 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? -pekr-

 [5/10] from: rebolek:seznam:cz at: 24-Aug-2002 12:36


Hi, ----- Original Message ----- From: "Petr Krenzelok" <[petr--krenzelok--trz--cz]> To: <[rebol-list--rebol--com]> Sent: Saturday, August 24, 2002 12:07 PM Subject: [REBOL] Re: locale Re: Re: %Maoww_english.r
> Carl Read wrote: > >Let's. (:
<<quoted lines omitted: 37>>
> other UI items will be in Czech? > -pekr-
I'm writing Castro (Red Commander) as localized. I've patched VID-styles so they check for language in feel/redraw function and you can change language dynamically while running that program. But I'm still not sure how to organize different language versions. Now I use this approach - before every string written in english is function 'translate that checks for language and "translates" string. So, with new versions, if it does not find translation for some string original string is used. But on the other hand I must use function 'translate before every string. Any ideas? bolek

 [6/10] from: carl:cybercraft at: 24-Aug-2002 23:44


On 24-Aug-02, Petr Krenzelok wrote:
> Carl Read wrote: >> Let's. (:
<<quoted lines omitted: 15>>
> 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..."]
<<quoted lines omitted: 5>>
> 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

 [7/10] from: carl:cybercraft at: 25-Aug-2002 1:33


On 24-Aug-02, Boleslav Brezovsk=FD wrote:
> I'm writing Castro (Red Commander) as localized. I've patched > VID-styles so they check for language in feel/redraw function and
<<quoted lines omitted: 6>>
> use function 'translate before every string. > Any ideas?
Would this be anything like you'd want?... lang-1: [word-1 "abc"] lang-2: [word-1 "xyz"] lang: copy/deep lang-1 change-lang: function [new-lang][x][ foreach [word value] new-lang [ if x: find/tail lang word [insert clear x/1 copy value] ] ] lo: layout [ text lang/word-1 button "Lang-1" [change-lang lang-1 show lo] button "Lang-2" [change-lang lang-2 show lo] ] view lo A show of a layout will update the whole layout, while the "insert clear x/1" (instead of "x/1:") in change-lang ensures the text in the layout is referencing the new text - since the new text is still the same reference. --- Incidentally, I'd wondered how to localise functions - and localising the comments at least would be quite easy... lw: [ desc "Sums two numbers." arg-1 "First value" arg-2 "Second value" ] sum: func reduce [ lw/desc 'a [number!] lw/arg-1 'b [number!] lw/arg-2 ][ a + b ]
>> sum 2 2
== 4
>> ? sum
USAGE: SUM a b DESCRIPTION: Sums two numbers. SUM is a function value. ARGUMENTS: a -- First value (Type: number) b -- Second value (Type: number) How useful that would be without the rest of the function being localised is debatable though. -- Carl Read

 [8/10] from: zokie:libero:it at: 24-Aug-2002 18:20


Hello [mh983--attbi--com] On 23-Ago-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
yes, this is an old idea used with succes by locale.library of AmigaOS 3.x!! Many months ago I started to make a Rebol Tools to implement any routines of locale.libray, but after a little experiment I haven't more time to complete it :( It is based on external files, collected into a directory called %catalog/. Each file stores messages definition and its names is obteined by joining application ID and language ID, to localize a Rebol Script all you need is at script startup to call: messages: make-catalog "your applicationname" Massages becames an object, so each catalog string definition will not collide with global variables used in the script. In the file user.r you must add a language definition, which may contain more than a language setup, so application will do automaticaly the best user's preference match :) It is possible to add for each message a minimal or/and maximal length so it will be easy to make a self-formatting user interface or for translator to choice the best word to unchange user interface layout. For example: ; line to add to %user.r, languages are sorted by preference user-prefered-languages: ["italiano" "english"] ; at script begin make-catalog: func [ app-name [string!] "Application name" /default my-list [block!] /force language /local catname cat ] [ if default = TRUE [return cat: make object! my-list] cat: none if exists? %catalog/ [ either force = TRUE [catname: join %catalog/ join app-name join "-" join language .cat ] [ foreach language user-prefered-languages [ if exists? catname: join %catalog/ join app-name join "-" join language ".cat" [break] ] ] if exists? catname [ my-list: load catname cat: make object! my-list ] ] return cat ] rdui: make-catalog "RebolDex" ;and from now on we may access to localized strings by using a mnemonical code like this: print rdui/hello-msg .... How you can see by looking make-catalog source, you may force a language choice or may give a minimal user interface by using refinements like force or default. They had been implemented for rapid developing or for degub purpose. To add another "language" you need only to translate text and put it into %catalog/app-name-"language".cat file, no one source line needs to be modified :)
> Just my two cents.
This is just my old experiment :) ; locale-english.cat [greetings: "regards" ] ; locale-italiano.cat [greetings: "saluti"] ... ui: make-catalog/force "locale" "english" print ui/greetings -- "Where did you get all those facts!?!"

 [9/10] from: petr:krenzelok:trz:cz at: 24-Aug-2002 19:06


Francesco De Napoli wrote:
>Hello [mh983--attbi--com] >On 23-Ago-02, [mh983--attbi--com] wrote:
<<quoted lines omitted: 8>>
>complete it :( >It is based on external files, collected into a directory called %catalog/.
Yes, I know. But then we have to decide, if we add system-wide directories as /catalogues, /skins, etc., or each app will use its own directory? Because - in rebol, the app = few KB script in many cases, so maybe it would be sufficient to look at app directory subdir, or directly at directory where script resides (no /catalogues subdir, just catalogue files) we could e.g. use app-name.czech.cat or even app-name.czech and use suffix? func to get language name. But it could look confusing having app-name.r containing app itself, default catalogue and app-name.czech to contain only language catalogue, not script ... The problem is - whatever aproach si possible. The only question is, what way to go ... And also - don't forget to somehow check for the version needed? So if you will receive new version of your app, you may try to force not to use catalogue older than 1.4 version or so ... So now we would need catalogue to carry its version number too .... -pekr-

 [10/10] from: zokie:libero:it at: 24-Aug-2002 18:49


Hello Petr On 24-Ago-02, Petr Krenzelok wrote:
> Carl Read wrote: >> Let's. (:
<<quoted lines omitted: 17>>
> items use default language, so e.g. new button will be in English, while > other UI items will be in Czech?
I think reblets are re-download every time they are updated, why don't we update even catalog file on-the-fly? Yes, with a version tuple will be easy recognize obsoleted catalog, it is not diffucult to add to my old idea :) [ version: 1.2.0 hello-msg: "Hi! Rebolers!" ] my-cat: make-catalog "app-name" if app-version > my-cat/version [ ; Now we must download new "user choiced laguage" catalog file .... my-cat: make-catalog "app-name" ] Please Note: version check & auto-update maybe embedded into make-catalog function definition Regards -- "Where did you get all those facts!?!"

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted