World: r3wp

has anyone used the localisation framework of cheyenne?

I digged into it a little and I don't know how to make it load other 
than default language en

<% 
locale/set-default-lang 'en
print say "test" 
probe locale

print "<hr/>"

locale/set-lang 'fr
print say "test" 
probe locale
%
this generates:

test make object! [ path: %www/cebelca.biz/lang/ lang: 'en current: 
make hash! ["lang" "test" ] default: make hash! ["lang" "test" ] 
......
<hr/>

test make object! [ path: %www/cebelca.biz/lang/ lang: 'en current: 
none default: make hash! ["lang" "test" ] ...
--

after I set lang to fr I have file in fr/fr.cat it says current: 
none (so it didn't load it)

if I reverse the fr and en in code in first case default and current 
are still en and in second they are both en.

It seems like it can't find fr/fr.cat in either of these cases

case = examples , the one up there and reverse

I suspect that directory lookup is different for default 'en and 
when you set-lang , set-default-lang

I found in source: ;--- Define the localization resources directory 
(relative to the webapp) .. now I moved the test to webapp, I had 
it on the frontend before but it behaves the same (I have binary 
release 0.9.19

I will try with the source version from SVN

same behaviour

file: join path [mold id slash mold id ".cat"]    ; current dir is 
in the webapp aleready so the path to file doesn't resolve
unless exists? file [return none]

I don't know what is the right solution in the global context, differentyl 
calculated path , different current dir .. so it's best you solve 
it :) .. I made a hack/fix so I can work on

great, it works.. also outside webapp

that static form for localised strings is a great idea #[...] 


does localisation effect performance much? I suppose it increases 
RAM usage since app holds the two hashtables in memory (which is 
needed I know for speed)

the #[..] is awesome idea. I have tons of javascript that would otherwise 
become an ugly mix of javascript and rebol

I don't recall anyone using the localization framework besides me 
and now you. :-) This framework is still experimental, it might be 
not suitable for a big application as it relies on a single namespace 
(using same words in differents pages will give you the same translation, 
this is not always desirable).

I'm not aware of issues wrt 'set-default-lang, but I must admit that 
I've never used it, I just switch the languages in my browser for 
testing.

Please add a ticket for that issue at http://curecode.org/si/view-tickets.rsp.

I agree that #[...] really makes things easier and cleaner. Performance 
impact is not significant, the overhead is just a string! PICK in 
a block with a static index as argument (that's one of the nice advantage 
of compiling RSP scripts). OTOH, the SAY function has to do a hash 
table lookup to get the right index (so a tiny little bit slower 
than the literal form).

Good. I have a lot of javascript so #[] really saved my day. I had 
started with >element.innerHTML = "<%= say "some text" %>" and element.innerHTML 
= "#[some text]" is 10x better :)

I will add a ticket, I need to use this function because I basically 
set language globaly for english / slovene version (not based on 
user preferences or anything, it's also different website).

Some texts (that are part of application) are a little longer. I 
was thinking of replacing all of them with "tags", like "add_now" 
instead of "Add now" and "warning_text" instead of "bla bla ........................" 
and having the default language as this tag language from which it 
is then translated to english, slovene, etc.. anyone has any thoughts 
about this?


I could also make a tool that would statically replace all the values 
in say "..." and #[...] if I decide to do so at one time. That's 
why I would preferr the same system for most of things.


I will probably have a separate files where the whole page is text 
, like the instructions.

Looks like a good idea to dig.

cheyenne does support mysql only? or can we use sqlite or sql server 
thru odbc?

you can use anything rebol can use. I am using sqlite also for example 
somewhere.

I have a webapp that uses captcha as part of the authentication. 
 But I need also to allow scripts in ... and so I had to disable 
the captcha.  Any other solutions?

I got the SVN version. How to proceed?

a) how can I get the SVN version to run on my server?
b) how can I create an encapped version of it?

do %cheyenne.r

there's an encap script that comes with the distro

Do I need to configure any paths to get it up & running without encapping?

AFAIR no unless you are using a webapp

is there any other configuration or something to use databases with 
cheyenne? I configured as it shown in web site but I always get the 
error:

##RSP Script Error: 
	URL  = /
	File = www/index.rsp
	** Access Error : Invalid port spec: odbc://test2
	** Where: do-sql 
	** Near:  [do-sql 'test2 "select * from table" 
__txt 62
] 

my rsp site is:
<%
	print do-sql 'test1 "select top 10 * from sec_log1"
%>

and the httpd.conf file:

databases [
	test1	mysql://[root-:-localhost]/test
	test2	odbc://test
]

typo, it should be: print do-sql 'test2 "select top 10 * from sec_log1"

In order to use the mysql protocol, you have to include it as a worker-lib, 
I guess.

Add %path/to/mysql-protocol.r to your WORKER-LIBS block in the %httpd.cfg, 
that should do the trick.

Endo, does opening the database directly from console work?
>> db: open odbc://test2


Also, check what REBOL kernel Cheyenne is running on, if you're using 
one of Cheyenne's binary releases, you won't have ODBC support (requires 
encapping with encmd).

I tried it with mysql also, but the result was same. So it is not 
an odbc issue I guess.

I'm using cheyenne-r40.exe on windows xp pro.

mysql.exe command-line works well.

I tried with cheyenne-r0919.exe binary version with mysql server 
on localhost, same error: 
** Access Error : Invalid port spec: mysql://[root-:-localhost]/test

cheyenne-r40.exe doesn't have ODBC driver.

Can you connect from REBOL console using : 
>> db: open mysql://[root-:-localhost]/test

??

db: open mysql://[root-:-localhost]/test gives same error on console, 
I'm using R2/View 2.7.7.3.1

mysql driver is not already in cheyenne?

no, you must download it here: http://softinnov.org/rebol/mysql.shtml

I think it should be

then how cheyenne load it?

See ChristianE explanations above.

Oldes: I agree, given how often it is used in combination with Cheyenne/RSP.

Hmm.. p: open odbc://test works on console

But cheyenne-r0919.exe still gives ** Access Error : Invalid port 
spec: odbc://test

Don't use odbc - Cheyenne doesn't support it with the default build. 
Use the standalone mysql protocol linked above.

Or if you have the SDK, encap your own binary.