Ok, another clean install with 2.3.1 on the live system. Dropped the db and removed all from the file system. A really clean install, only the i18n::set_locale('de_DE'); in the _config.php on mysite.

The result: interesting. With 2.3.1 all languages are functioning, only the german language do not ;-(. And with 2.3.1 german isn't functioning at all, no language mix, all is now in english, so the system don't find the german translations? I also removed the set_locale, but no chance, the german isn't functioning.

I also changed my installation: I uploaded this time the silverstripe tar to the server and extract it on the server. At the earlier installs, I extract the tar on my local machine and uploaded the complete directory tree with FTP. So there could be case problems with my earlier installs and its nothing to do with 2.3/2.3.1. But now the question is, why is german the only language that is not functioning ;-(

Another small observation: In the 2.3.1 installation under cms/lang there are strange files in the french translation fr_FR.php.orig,fr_FR.php.rej seems a merge problem.

So please one last idea, so I get the german language working ;-)? Is there a log file to see what is the problem with the german?

Thanks, Marcel

> But now the question is, why is german the only language that is not functioning ;-(
Uhm, no discrimination against Germans that I'm aware of ;) (I'm German as well)

> Another small observation: In the 2.3.1 installation under cms/lang there are strange files in the french translation fr_FR.php.orig,fr_FR.php.rej seems a merge problem.
Removed the files, yeah was a merge problem, doh...

I've tried a mint 2.3.1 tar.gz with the only customization being i18n::set_locale(), logged in with default admin created through the installer, went to /admin/myprofile and changed the language in the dropdown to "German (Germany)". After refresh, backend is in German as expected.
So you have your member record in the database with a Locale = 'de_DE', right?

Can you run a syntax check over all de_DE.php files you have in your installation? You can do this on the commandline via "php -l".

I'm slowly running out of ideas without seeing something reproducible here ;)

Ok, after a lot of reinstalls of silverstripe on my live system, I have tracked the problem to the following:

I can change to the german language (or any other), after this I have to flush my browsers chaches (Firefox) and then login to the admin area and all is in german ;-)... but only for one time. The second login, all is in english. Then after deleting all my cookies in Firefox and login in again, all is in german ;-), but only for one login. I have always to delete the cookies.

With IE I can't get a german admin area, deleting the cookies has no influence ;-(

So it seems something with caching/cookies on my live system in combination with the browser.

Can you login two times in the german language on a unix box? I can only one time!

Marcel

Uhm, do you have anything that sets "lang" or "locale" cookies on this domain? Perhaps another service in another subfolder is setting global cookies which affect SilverStripe? Assuming you're using a uncustomized SS install, so no manual setting of cookies in your initialization code, right?

Flushing template cache shouldn't be necessary to detect and use templates in a different language (the cached templates just store the _t() calls, not the translated string). I didn't need flush to get the language after switching it in my profile, simple refresh did the trick.

> Can you login two times in the german language on a unix box? I can only one time!

Logged in/out a couple of times with switching languages in between on FF3/OSX, no problem.

Same problem with test system (WAMP) and live system. I found out that on my live system "register_globals = On" is set. After setting "register_globals = On" on my test system i got the same error.

Now my provider is changing this...

@wagnerma: can you please check your php settings?

Perfect...
Now my live system works fine...

@ingo: Can you check this issue in install.php?

Uhm, register_globals is evil, and is a serious security risk if enabled on production hosts. Amongst other things, you'll get trouble with global variables like $lang. register_globals is deprecated in PHP 5.3, see http://nz2.php.net/manual/en/ini.core.php#ini.register-globals.

More background on the issue: http://nz2.php.net/manual/en/security.globals.php

I've created a ticket for the installer to throw a warning when register_globals is on, see http://open.silverstripe.com/ticket/3928

Thanks for the register_globals info, at the production site it was still on, I turned it off. (now same as my development site)

But it had no influence on my language mix problem.

But after a lot of reinstalls, I realize that I don't use a plain sliverstripe! Argh...., I always installed the blog module, because my site uses it! And it seems, that the blog module messed up somthing with the locale! The plain silverstripe works fine, no language mix. Installing the blog module, things seems to get wired.

I do further testing.

Cheers,
Marcel