I'm not shure if I should fill in a bug report so you 'll find my story first here to consult a second opinion.
My site runs in the Dutch language (Nederlands). The locale is set on nl_NL (in the admin/configuration section).
No one can subscribe anymore to the moodle environnement. People are left with the attached error message (see picture below).
The odd thing is : If I use as locale-en they can subscribe! But of course this leaves me with some english words in the courses.
Summary :
using lang "English" with local - en : no problem
Using lang "Nederlands" with local - en no problem (except for some words ...)
Using lang "Nederlands" with local - nl_NL creating new account impossible.
Using lang "Nederlands" with empty local field results in resetting the field in nl_NL after I look again ...
I had never a problem like this before, I'm on the latest cvs
Must be a language thing or ...
running Moodle 1.3 development (2004050500) in productionenvironment with your settings and no problems ( www.ritacollege/be/elo )
No idea
Custom theme ???
Hi Koen (we ''ll keep it in english) 
Run Beta 2004051100 on a production machine.
You can check http://www.vanhorne.nl/moodlecursus wich runs the default theme.
Play with the choosen language and you 'll see. (f.i. just fill in a username and submit)
I can't explain it either. Will look if the file had changes in cvs.
If not, tomorrow I clean the cache, machine consumes a tremendous high value of memory.
I'm using PHP-accelerator
See http://www.vanhorne.nl choose "info".
I used a fresh copy of the beta, deleting the old and replaced the code.
If time, I see how it reacts on my test server at home.
Run Beta 2004051100 on a production machine.
You can check http://www.vanhorne.nl/moodlecursus wich runs the default theme.
Play with the choosen language and you 'll see. (f.i. just fill in a username and submit)
I can't explain it either. Will look if the file had changes in cvs.
If not, tomorrow I clean the cache, machine consumes a tremendous high value of memory.
I'm using PHP-accelerator
See http://www.vanhorne.nl choose "info".
I used a fresh copy of the beta, deleting the old and replaced the code.
If time, I see how it reacts on my test server at home.
Heu, I don't see any problem (made a new account, as you can see, logged in, surfed around)
Did I mis something ?
Now I get confused, and a little bit worried ... 
(On my test machine freeBSD all is oke, brrr...)
I definitely clear the /tmp dir tomorrow !
Thanks for info.
(On my test machine freeBSD all is oke, brrr...)
I definitely clear the /tmp dir tomorrow !
Thanks for info.
I solved the problem by comparing the cvs versions of signup.php and deleted the red color around line 91.
This seems to solve my problem. Normal signup procedures are working again ...
$string = eregi_replace("[^(-\.[:alnum:])]", "", $user->username);This seems to solve my problem. Normal signup procedures are working again ...
OK, this was added recently to solve a problem with German and other languages ..."Invalid range end" eh? I wonder why this only happens with some locales? (What locale are you using by the way?)
I may have to go back to plain alphanumerical characters again for login names.
I may have to go back to plain alphanumerical characters again for login names.
Martin,
lang --> "Nederlands(nl)"
locale --> "nl_NL"
It only comes up at the production machine ( a rather old Red Hat 7.2 patched system)
I have no problem with it on a test machine (a rather new freeBSD 5.1 system) using the same lang - locale combination.
lang --> "Nederlands(nl)"
locale --> "nl_NL"
It only comes up at the production machine ( a rather old Red Hat 7.2 patched system)
I have no problem with it on a test machine (a rather new freeBSD 5.1 system) using the same lang - locale combination.
Hi!
Not working for Czech locale/cs too (using encoding iso-8859-2 on Windows with mbstring extension, full overloading of string functions).
IMHO some option should be placed in config.php, default setting could be ASCII characters and numbers only.
skodak
PS: actually thera are two files to edit - login/signup.php and user/edit.php.
Not working for Czech locale/cs too (using encoding iso-8859-2 on Windows with mbstring extension, full overloading of string functions).
IMHO some option should be placed in config.php, default setting could be ASCII characters and numbers only.
skodak
PS: actually thera are two files to edit - login/signup.php and user/edit.php.
OK, these are enough reasons to go back to the plain alphabet method as a default.
I'll add an option for those who want to try using NO parsing at all.
I'll add an option for those who want to try using NO parsing at all.