Ditto - German Umlauts in Dates Problem

Generally speaking, the problem is that a variety of applications have to work together: Apache, PHP, mySQL, MODx, phpMyAdmin, 3rd-party files (snippets etc.). You’d even have to take into account the user’s browser + WYSIWYG editors (complete applications in their own right).

A lot of these options are controlled by the hosting company: e.g. the default charset defined by Apache is still by default ISO-8859-1 on most Western European systems.
On some configurations, you can override those values, on others you can’t.
A string entered into the modx manager passes a lot of different "layers" till it’s stored on the server. Browser > WYSIWYG > PHP/MODx > mySQL. Often you got JSON/JS inbetween as well. If only one of those things don’t work like they’re supposed to, you end up with garbage. Hooray for technology!

But I’m afraid all this rambling isn’t helping mmjaeger much with this specific Ditto problem right now...

Quote from: ganeshXL at Mar 03, 2008, 06:09 AM

Generally speaking, the problem is that a variety of applications have to work together: Apache, PHP, mySQL, MODx, phpMyAdmin, 3rd-party files (snippets etc.). You’d even have to take into account the user’s browser + WYSIWYG editors (complete applications in their own right).

A lot of these options are controlled by the hosting company: e.g. the default charset defined by Apache is still by default ISO-8859-1 on most Western European systems.
On some configurations, you can override those values, on others you can’t.
A string entered into the modx manager passes a lot of different "layers" till it’s stored on the server. Browser > WYSIWYG > PHP/MODx > mySQL. Often you got JSON/JS inbetween as well. If only one of those things don’t work like they’re supposed to, you end up with garbage. Hooray for technology!

But I’m afraid all this rambling isn’t helping mmjaeger much with this specific Ditto problem right now...

But I’m afraid all this rambling isn’t helping mmjaeger much with this specific Ditto problem right now... - you’re right - unfortunately, I didn’t get any further yet -  In the meantime I’m just showing numbers instead of the month for instance. unfortunately that doesn’t work for the archive/reflect.

Sometimes our language(Japanese) has same problem.
Check if this(specify charset) would work.

Quote from: tkfm at Mar 03, 2008, 06:55 PM

Sometimes our language(Japanese) has same problem.
Check if this(specify charset) would work.

setlocale(LC_ALL, 'de_DE.UTF-8');

unfortunately, that doesn’t work either - using the above setting is totally ignored and everything is returned in English.

hope there is a solution soon - my client gets kind of angry.

There are other language files that affect to this problem, like manager, quickedit, docmanager...
If you are logged in as manager, you should change(setlocale) language file for manager(manager/includes/lang/).

I’m running the manager in English to avoid such problems - the main issue is the front-end.

In addition, check your manager/includes/config.inc.php line 9 if there is the utf8 connection string:

Quote from: yoomai at Mar 04, 2008, 02:49 AM

In addition, check your manager/includes/config.inc.php line 9 if there is the utf8 connection string:

$database_connection_charset = 'utf8';

thanks - it’s already set to utf8

this seems to solve the problem in the reflect snippet: $month_text = utf8_encode(strftime("%B", mktime(10, 10, 10, $mon, 10, $year)));

You can use PHx to format your date output, see this thread.