Translation of date formats not working

Permalink 13 14 Browser Info Environment
I started to de-customize our custom core and found a problem I'm not sure about. It might be the heat in our office but from what I understand right now, it's not the cause..

My testsite is a multi lingua site where I'd like to use the internationalization add-on. This add-on contains code like this:

public static function setupSiteInterfaceLocalization() {
      // don't translate dashboard pages
      $c = Page::getCurrentPage();
      if($c instanceof Page && Loader::helper('section', 'multilingual')->section('dashboard')) {
      $ms = MultilingualSection::getCurrentSection();
      if (is_object($ms)) {
         $locale = $ms->getLocale();
      } else {
         $locale = DefaultLanguageHelper::getSessionDefaultLocale();
      // change core language to translate e.g. core blocks/themes
      if (strlen($locale)) {

This switches the language to assure the correct translation of strings in blocks, themes etc.

When I look into the dispatcher, I see that localization.php is loaded twice (this is where the date formats should be translated):

However, the package events are loaded a few lines further down:

This means that the t-functions executed in line 67 and 87 can't work properly.

I don't want to load the localization.php a third time but I can't see how current code can work.

I hope I've missed something!

Status: New
mlocati replied on at Permalink Reply
Please note that:
- at line 66 we run startup/localization.php
- at line 87 we run config/localization.php
Remo replied on at Permalink Reply
you're of course right, but I don't think it really matters.
I wouldn't even want to load localization twice..

at the end we probably have to make sure the internationalization add-on is loaded pretty early because you might need t(date_format) in another add-on.

package dependencies here we come again!
mlocati replied on at Permalink Reply
For me too it's quite a problem to have use define() for locale-aware strings: changing locale after those constants have been defined leads to problems like the one you highlighted.

What I'd do in your case is to setup the locale before config.php is loaded, for instance checking the request path in /config/site_post_autoload.php, but it's just a workaround...
Remo replied on at Permalink Reply
what if we'd remove the t's from config/localization.php like that:

# New date constants
if (!defined('DATE_APP_GENERIC_MDYT_FULL')) {
   define('DATE_APP_GENERIC_MDYT_FULL', t('F d, Y \a\t g:i A'));

# New date constants
if (!defined('DATE_APP_GENERIC_MDYT_FULL')) {
   define('DATE_APP_GENERIC_MDYT_FULL', 'F d, Y \a\t g:i A');

and move the old part into the internationalization add-on:

# override existing date formats
define('DATE_APP_GENERIC_MDYT_FULL', t('F d, Y \a\t g:i A'));

mlocati replied on at Permalink Reply
I don't think that's a good idea: what about single-language websites that don't use the internationalization package?
Remo replied on at Permalink Reply
Yeah that get's ugly!

Well, we could keep the code in the core but still override the constants in the internationalization add-on. Also pretty ugly but it would at least work. Too much DRY though.. I'll keep on looking for a better solution
mlocati replied on at Permalink Reply
It's not possible to re-define an already defined constant.

The best solution would be to get rid of locale-dependent constants. Anyway that implies a lot of code-breaks.

Another solution could be to add a new method to the packages, and call it before including config/localization.php (something like 'on_initialize' that makes clear that it happens before 'on_start').
The current startup/packages.php should remain after the localization has been fully configured.
Remo replied on at Permalink Reply
Well, you're right, I wouldn't want to redefine a constant, otherwise it would be called variable but just in case, with runkit you can redefine a constant. But again, I'm not saying we should do that!

Adding an additional on_initialize method would do the trick but so far this is the only issue I ever had where I'd need that method. Scanning and loading all the packages to analyze them with some kind of reflection just for this?

But so far this is the best solution I see!

I also thought about adding the internationalization add-on into the core, that would offer a lot more flexibility as well but again, a pretty drastic change.

Some CORE TEAM member around?
PatrickHeck replied on at Permalink Reply
Remo replied on at Permalink Reply
Thanks Patrick! I guess it's time to get this fixed!

I never noticed it because I'm still working with a pretty custom core.

concrete5 Environment Information

# concrete5 Version

# concrete5 Packages
Internationalization (1.1.7-dev).

# concrete5 Overrides
controllers/page_types, tools/test.php

# Server Software
PHP 5.4.9 Development Server

# Server API

# PHP Version

# PHP Extensions
bcmath, calendar, cli_server, Core, ctype, curl, date, dom, ereg, fileinfo, filter, ftp, gd, hash, iconv, json, libxml, mbstring, mcrypt, mhash, mongo, mysql, mysqlnd, odbc, openssl, pcre, PDO, pdo_mysql, Phar, Reflection, session, SimpleXML, soap, SPL, standard, tokenizer, wddx, xdebug, xml, xmlreader, xmlwriter, xsl, zip, zlib.

# PHP Settings
max_execution_time - 30
log_errors_max_len - 1024
max_file_uploads - 20
max_input_nesting_level - 64
max_input_time - -1
max_input_vars - 1000
memory_limit - 128M
post_max_size - 8M
sql.safe_mode - Off
upload_max_filesize - 2M
mysql.max_links - Unlimited
mysql.max_persistent - Unlimited
odbc.max_links - Unlimited
odbc.max_persistent - Unlimited
pcre.backtrack_limit - 1000000
pcre.recursion_limit - 100000
session.cache_limiter - nocache
session.gc_maxlifetime - 7200
soap.wsdl_cache_limit - 5
xdebug.max_nesting_level - 100
xdebug.var_display_max_children - 128
xdebug.var_display_max_data - 512
xdebug.var_display_max_depth - 3

Browser User-Agent String

Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1581.2 Safari/537.36