Maybe it's by design, but there should be a clean way to do such things:
I needed to get the results of php's strftime() function translated to german language, and didn't want to use the internal translation system. So in my custom modules I just made a call of php's setlocale('LC_ALL', 'de_DE', 'deu') preceding each call of strftime(), and all went fine - even on windows platform, where you need the 'deu'.
As I have several calls of strftime() in my modules, I had the idea to use setlocale() just once in settings.php. This gave me strange results, as some components of drupal or contributed modules didn't work anymore. For example, hook_menu failed to create entries in the menu router table, or cck wasn't able to show certain settings pages.
There seem to be some dependencies between drupal core and php's locale settings, perhaps by design?
Regards,
Boris
Comments
Comment #1
shenzhuxi commentedAgree
This is important for non-English website.
Comment #2
Zilvador commentedI also agree. I need this right now. In Drupal 6 it even locks up the same way when calling the function inside a module, it seems.
Comment #3
tstoecklerWhat is your use-case for strftime()? More specifically, why aren't you using format_date()? (http://api.drupal.org/api/drupal/core!includes!common.inc/function/forma...)
Also setting to 8.x, as new things are usually fixed in the development version. Also setting to "needs more info" though, because, again, I really don't see what there is to fix here.
Comment #4
drubbAs for me, you're right! Just didn't remember there's a format_date() function. No need to use setlocale() / strftime() any more.
Thx,
Boris
Comment #5
tstoecklerMarking fixed.
Please revert if you disagree.