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

locale

 [1/11] from: zokie::libero::it at: 25-Aug-2002 20:30


Hello Petr On 24-Ago-02, Petr Krenzelok wrote:
> 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)
I think to put %app-name.r & %catalog/ in the same directory, so they maybe installed, copied, removed together :) Yes! Rebol applications requires few KB and to collect many catalogs colud enlarge them, but we should consider to distribute them with few or only one catalog file (p.e. english one) and modify make-catalog function or add another function to autodownload prefered catalog file(s) if in the user setup are specified different languages, so only first application launch needs to start with "wrong" catalog and download correct one if we can't do catalogs download during app installation and then re-define catalog. Another approch could be this: an application is distributed with all avaible catalog files and on the first launch are removed unused ones or user force their deletion. I think first solution is the best one :) Do you want a global locale/catalog directory? No problem!! app-name-language.cat works fine even with global locale/catalog directory until two or more application haven't the same "app-name" :) I've an opened mind: that was only my first experiment on "Rebol Scripts Localization" not the ultimate solution :)
> 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
Their are both valid solution, but I think .cat suffix is better to make searches or use wildcard ;)
> app-name.r containing app itself, default catalogue and app-name.czech > to contain only language catalogue, not script ...
If app-name.r contains code & default catalog we may waste KB, i.e. I'm Italian and I like use Italian Language but default catalog is Czech, source code contains Czech strings definition even if at runtime them will be replaced by Italian ones, but they are still there and even on harddisk! Otherwise if all catalog are external file I could delete Czech and all other unused catalogs, app-name.r will be as tiny as it needs to be and only one or few catalogs will be stored on harddisk. To have default catalog as an external file may help translators to make their dirty job :)
> 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
No, I don't forgotten it, see my other post, version number is another field in block definition ;) Regards -- "Where did you get all those facts!?!"

 [2/11] from: carl:cybercraft at: 26-Aug-2002 8:54


RT must've thought a bit about this. Have they ever given any pointers to how they would wish to do it? -- Carl Read

 [3/11] from: gscottjones:mchsi at: 25-Aug-2002 16:11


From: "Carl Read"
> RT must've thought a bit about this. Have they ever given any > pointers to how they would wish to do it?
Good point. And that also reminds me that Sunanda expressed an interest in this a few months back. --Scott Jones

 [4/11] from: petr:krenzelok:trz:cz at: 25-Aug-2002 23:12


Carl Read wrote:
>RT must've thought a bit about this. Have they ever given any >pointers to how they would wish to do it? >
there is system/locale ... but even if you change some items in-there, it is not reflected by functions like request-date or so ... so that's how they deeply thought about it :-) ... just kidding ... I think that they think of many things. But - everything is about priorities I think. However - they sell IOS. IF they want to sell to non English speaking areas, the right aproach to localisation is needed. And no, sorry, - I am not about to edit each reblet and replace strings in there - forget it - that's not architecture, that's not a concept - I want to be able to switch between the languages freely ... ;-) -pekr-

 [5/11] from: petr:krenzelok:trz:cz at: 25-Aug-2002 23:38


Francesco De Napoli wrote:
>Hello Petr >On 24-Ago-02, Petr Krenzelok wrote:
<<quoted lines omitted: 8>>
>I think to put %app-name.r & %catalog/ in the same directory, so they >maybe installed, copied, removed together :)
OK, then remember the directory can contain more than one app (script) .... just a note :-)
>Yes! Rebol applications requires few KB and to collect many catalogs colud >enlarge them, but we should consider to distribute them with few or only
<<quoted lines omitted: 8>>
>their deletion. >I think first solution is the best one :)
hmm, IIRC Amiga has some organisation called ATO (Amiga Translation Organisation). If someone develops app, he/she can contact ATO to do translation to other languages, which can be ready till app release time. I am not sure ppl here + RT will agree to: 1) have default language pack external to script. It would mean EVERY script would have to have two files - script itself, and catalogue. On the other hand - if author doesn't wish to support localisation, he does not need to create catalogue. 2) to have it downloadable. I am not sure app itself should download it dynamically. Such capability should be provided by app itself, if author wishes to do so.
>Do you want a global locale/catalog directory? No problem!! >app-name-language.cat works fine even with global locale/catalog directory >until two or more application haven't the same "app-name" :) >
correct :-)
>I've an opened mind: that was only my first experiment on "Rebol Scripts >Localization" not the ultimate solution :) >
hey, I am not guru either :-)
>>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 >> >> > >Their are both valid solution, but I think .cat suffix is better to make >searches or use wildcard ;) >
hmm, you are right here. What about .catalogue or .language suffix? Are we really all influenced by MS Win3.1 era crap? :-)
>>app-name.r containing app itself, default catalogue and app-name.czech >>to contain only language catalogue, not script ...
<<quoted lines omitted: 8>>
>only one or few catalogs will be stored on harddisk. To have default >catalog as an external file may help translators to make their dirty job :)
Well, I always liked componentisation, but some ppl here will tell you stories about so called "dll hell" - if you don't find a component, your app is not operable. That's why we have Rebol in one executable file and scripts are mostly one .r files and everything-inside-aproach is often used :-) Think e.g. of Rebol itself. It contains many messages. They are in English. How to translate them? Well, main rebol dir could contain something like suggested rebol.czech.cat. Then we need to tell Rebol to use Czech language, right? How? Is the user.r the right place? What word should be used? What about using system/locale object? System/locale/preferred-language: "Czech". Then: - Rebol - would load that catalogue, checking version number of course - other app : a) does not support localisation and nothing happens b) support localisation - should call some helper function switch-to-language doing two things - 1) look at system/locale/preferred-language 2) checking its dir if app-name.czech.cat is available -pekr-

 [6/11] from: al:bri:xtra at: 26-Aug-2002 17:22


Just thinking out loud. What about an automatic language translation of Rebol code? With a language field set in the header of the script? Like: Rebol [ Name: 'Test Language: 'English ; Could be Czech, Spanish, ] For example, a Czech person (is there a better phrase?) gets a Rebol script written in English, and wants the display in Czech. And so they use a English to Czech translator script that uses, say, Babelfish or other online resource to translate individual string! values (or individual words within the string! value) into Czech. After some minutes searching, I can across this URL: http://www.mtranslations.cz/scripts/dict/en/query_new.idc?Slovo=Hello&lang=c z&dia=on which translates English/Czech words, and can be easily plugged into Rebol. I'm sure that a language translation function could be written that does the majority of the work. Andrew Martin ICQ: 26227169 http://valley.150m.com/

 [7/11] from: petr:krenzelok:trz:cz at: 26-Aug-2002 7:55


Andrew Martin wrote:
>Just thinking out loud. >What about an automatic language translation of Rebol code? With a language
<<quoted lines omitted: 17>>
>ICQ: 26227169 http://valley.150m.com/ >-><-
Hello Andrew, I too thought about header item usage. My thoughts so far are as follows: 1) you need to know somehow, what languages are supported for certain app, right? (e.g. to fill drop-down menu with selection) so: get-languages 'app-name (including-path) ... would return something like: == ["czech" "english" "spanish" "italian" "french"] etc. 2) then there should be some place, to store user selection. Two levels - system and app. btw - would it be usefull to have system running in one language as a whole, while having app-xy running in different language? If not, we only need some place to store language selected. Imo the right place is to extend system/lolace using 'preferred-language item or so. RT could add it. If not added, we can place it into user.r temporarily (or other config file for Link). So, maybe 'language item in a header is not necessary at all? Isn't one system-wide setting enough? 3) what is also probably needed, is some way of how to invoke language catalogue? I am trying to think from the script writer perspective. What should programmer do? e.g.?: load-locale 'app-name == app-name-locale: context [ ....] load-locale: func ['app-name /language language][ either language [ either find get-languages app-name language [load join app-name [language ".cat"]][none] ][ either find get-languages app-name preferred-language [..... you get the idea .. :-) -pekr-

 [8/11] from: rebolek:seznam:cz at: 26-Aug-2002 8:34


>... just kidding ... I think that they think of many things. But - >everything is about priorities I think. However - they sell IOS. IF
they
>want to sell to non English speaking areas, the right aproach to >localisation is needed. And no, sorry, - I am not about to edit each >reblet and replace strings in there - forget it - that's not >architecture, that's not a concept - I want to be able to switch
between
>the languages freely ... ;-)
Yes, me to :) But the question is HOW and if we pick some solution can we hope RT will make some use of it or will they come in 3-4 years (maybe less ;) with their own solution (of course incompatible) ? bye, bolek

 [9/11] from: zokie:libero:it at: 27-Aug-2002 7:59


Hello Petr On 25-Ago-02, Petr Krenzelok wrote:
>> I think to put %app-name.r & %catalog/ in the same directory, so they >> maybe installed, copied, removed together :) >> > OK, then remember the directory can contain more than one app (script) > .... just a note :-)
Ok! I'll use selective delete: delete %catalog/app-name-XXX.cat ;) I use a different directory for each application, only application module, plug-in, companion may share the same dir :)
> hmm, IIRC Amiga has some organisation called ATO (Amiga Translation > Organisation). If someone develops app, he/she can contact ATO to do > translation to other languages, which can be ready till app release > time. I am not sure ppl here + RT will agree to:
Why can't we start a Rebol Free Translators Organization?
> 1) have default language pack external to script. It would mean EVERY > script would have to have two files - script itself, and catalogue. On > the other hand - if author doesn't wish to support localisation, he does > not need to create catalogue.
Yes! 1 script only for old-style Rebol Script :)
> 2) to have it downloadable. I am not sure app itself should download it > dynamically. Such capability should be provided by app itself, if author > wishes to do so.
Yes! Author may use refinement to active/deactive autodownload of missing/obsolete catalogs. It is not difficult to implement with Rebol :)
>> Their are both valid solution, but I think .cat suffix is better to make >> searches or use wildcard ;) >> > hmm, you are right here. What about .catalogue or .language suffix? Are > we really all influenced by MS Win3.1 era crap? :-)
Virtualy any suffix length is good for me, I hate too ridiculous M$'s 3 letters extention, but are out there million of human being that could have an heartbreak if they discover on their computer a not M$ standard extention :) A long file name may arise compatibility problems on different platfom, i.e. AmigaOS File System has 31 char bound for file name lenght, even if it reverve space for 108 chars! Short names should be better, so we must consider idea to replace "language" with shorter "languageID", i.e. "en", de , "it", "cz",... especialy if we add a version tuple
> Well, I always liked componentisation, but some ppl here will tell you > stories about so called "dll hell" - if you don't find a component, your > app is not operable. That's why we have Rebol in one executable file and > scripts are mostly one .r files and everything-inside-aproach is often > used :-)
I know about "dll hell", but ppl that works at M$ aren't programmers they are just chaos maker! AmigaOS use shared library too, but none has encountered any kind of problem with them. Any library has it version tag, and services may only added and not removed or renamed, so if you use a newest version your old applications will work as fine as newest one, if you require a specific new service, at opening time, you must specified the minum version number which support that service, if it is non present you will get an error and all you need to do is replace the library file with the newest avaible. Catalog files should be similar, and because Rebol is a net oriented language it is easy to do an autoupdate routine, so application doesn't work only there is a server fault :)) To do a fast version check we shoult add a version tuple even in file name, i.e. app-name-language-x.y.z.cat Uhm!? Not a standard suffix, heartbreaks are around the corner :)
> Think e.g. of Rebol itself. It contains many messages. They are in > English. How to translate them? Well, main rebol dir could contain
I think we were speak about Rebol Script Localization and not Rebol Environment Localizzaztion, even if a Global & Official solution is better :) At the end of this thread we should make a RFC and send it to Rebol Technologies. If they'll think it is good enough they may endorce it ;)
> something like suggested rebol.czech.cat. Then we need to tell Rebol to > use Czech language, right? How? Is the user.r the right place? What word > should be used? What about using system/locale object? > System/locale/preferred-language: "Czech". Then:
All I get with probe system/locale is: make object! [ months: [ "January" "February" "March" "April" "May" "June" "July" "August" "September" "October" "November" "December" ] days: [ "Monday" "Tuesday" "Wednesday" "Thursday" "Friday" "Saturday" Sunday ] ] We shoul try to add an object entry for each first opened catalog file, so it is accessable globaly and any more time we run a script catalog will be just there! Every localizzed script should start with: my-cat: open-catalog "app-name" version-tuple and end with: close-catalog "app-name" version-tuple So Rebol Garbage Collector may remove all unused catalogs when memory is not enough Regards -- "Where did you get all those facts!?!"

 [10/11] from: zokie:libero:it at: 27-Aug-2002 7:33


Hello Andrew On 26-Ago-02, Andrew Martin wrote:
> script written in English, and wants the display in Czech. And so they use > a English to Czech translator script that uses, say, Babelfish or other
Babelfish and other automatic translator are funny toys, nothing more. They work fine for words and simple phrases translation, but misunderstaind complex phrases, human translator not! Also it is not possible to translate from any lenguage to another. Regards -- "Where did you get all those facts!?!"

 [11/11] from: oliva:david:seznam:cz at: 29-Aug-2002 12:11


Hello Andrew, Monday, August 26, 2002, 7:22:59 AM, you wrote: AM> Just thinking out loud. AM> What about an automatic language translation of Rebol code? With a language AM> field set in the header of the script? Like: AM> Rebol [ AM> Name: 'Test AM> Language: 'English ; Could be Czech, Spanish, AM> ] AM> For example, a Czech person (is there a better phrase?) gets a Rebol script AM> written in English, and wants the display in Czech. And so they use a AM> English to Czech translator script that uses, say, Babelfish or other online AM> resource to translate individual string! values (or individual words within AM> the string! value) into Czech. After some minutes searching, I can across AM> this URL: AM> http://www.mtranslations.cz/scripts/dict/en/query_new.idc?Slovo=Hello&lang=c AM> z&dia=on which translates English/Czech words, and can be easily plugged AM> into Rebol. :-))) I was working for mtranslations (now moravia-it:) ... I would like to see them when they recognize that the server log is full of Other browsers not just M$IE.... but I think there are better translators (and Cyphre has somewhere his rebol gui for them) Anyway, I'm not sure if such a translation will provide good results (especially czech language has quite complicated grammer) I was using these two ways to make multilangual scripts: 1. for generating pages I have: languages: [cz en] languageid: 2 ;for english localized: func [msg /local txt][ msg: append copy [] msg txt: any [pick msg languageid msg/1] txt ] ;And then i have one script for both languages with for example: print localized ["Ahoj" "Hello"] ;or months: [ ["Leden" "Únor" "Březen" "Duben" "Květen" "Červen" "Červenec" "Srpen" "Září" "Říjen" "Listopad" "Prosinec"] ["January" "February" "March" "April" "May" "June" "July" "August" "September" "October" "November" "December"] ] print join localized ["Dnes je " "Today is "] pick localized months now/month ;the advantage of this approach is that I have all data in one file ;and when I'm too lazy to translate something, the default language is ;used print localized "Tohle jsem neprelozil" ;or to have different content for english users as: layout localized [ [image %nejaky.jpg] [text "You are not allowed to see this czech picture"] ] ....... 2. for pure Rebol scripts (used in R-box2) this was not system solution.... I have for czech and english different file called: %msgs.cz.inc and %msgs.en.inc where I have localized function for status bar messages 'do-msg and a block with localized strings as: locstr: ["Zpět" "Nová hra" "Ulož hru" "Načti hru" "Skladník se vrací!"] and in the script I use: do-msg 'loaded ;-> prints "Hra načtena..." or "Game loaded..." in the statusbar print locstr/5 The disadvantage of this method is, that it's quite complicated to see what you are printing while coding it (in the R-box there was not too much texts but in some large projects it may be an issue) ....... Using both methods at once may be good approach - in the main script you may use the localized function and then simply "build" the language catalogs (the locstr block?) from it using some translating tool BUT.... why I should translate my scripts to Czech when I don't see correct czech characters in Rebol:( I think that rather then playing with skinning for the new VID or meditating if it's good to have %local/ directory somewhere, RT should make some other improvements in the kernel (at least native rich-text and unicode support and I don't mind if the new View will be 700kB or 1MB large), because they are only people allowed to do that (we can change VID by yourselfs)

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