Translated strings are cached in _info() hooks

subscribing for now.

menu does solve it with the title callback. I think a solution is to move it up to somewhere where it does not get cached, and use non-translated strings in those _info hooks.

Moving out the t() calls would be a way to go, but the translations template extractor won't find the strings any more. Currently it has extra detects hook_menu, but we could try to solve that in a more generic way instead.

Note: The recently introduced hook_entity_info() is also affected of this problem.

We could add a do-nothing function around the strings that just makes the translation extractor find it, and then translate at display time by passing the variable into t().

So in the _info hooks you'd have

function node_entity_info() {
  $return = array(
    'node' => array(
      'name' => te('Node'),

With function te() being something like

function te($arg) {
  return $arg;
}

The template extractor would have to be extended to catch all strings in te().

And at display time you'd do

  print t($info['node']['name']);

The original issue description refers to a hook (node_fieldable_info) that I think no longer exists.

Right now, _field_info_collate_types calls and caches a structured array which is the result of iterating over the following hooks:

• hook_field_info
• hook_widget_info
• hook_field_formatter_info
• hook_entity_info

I have re-rolled yched's patch above for the current versions of _field_info_collate_types and image_effect_definitions, and tested on HEAD. The language-specific caches are created and made available to the relevant user.

One complication I can think of is that calling _field_info_collate_types with $reset = TRUE clears all cached copies, but only repopulates the version corresponding to the current user's language. Shouldn't be a problem in practice?

Please test some more!

Well I like the solution of Frando above - that way we could avoid having a lot of duplicated caches. Also we'd save some potentially costly cache rebuilds. However I'd prefer a notion not involving PHP execution e.g. comments like /*t*/ 'Node' /*t*/ - but that's ugly. te() is looking much better and it's easy to deal with for potx.

This is very critical, because this will break multilingual sites.

A commenting standard won't fly, because developers will get it wrong.

A no-op function could be considered and doesn't cost too much. However, it would have to be complemented by a different function than t() to translate those strings, because potx has to warn about usage of $variables in t().

We perhaps also want to differ between stuff that makes sense to cache per language. Menu (tree) links, for example, are cached by language now. However, caching image styles/effects per language would not make any sense.

well we could also do a cacheable::t(), which returns a small wrapper object using __toString() to run t() on output. Would be pretty transparent and allow use to just cache one version, though I'm not sure whether the overhead of wrapper objects for something that simple as strings is feasible?

The te() option seems very reasonable to me.

Also the current patch contains:

+    cache_clear_all('field_info_types:', 'cache_field', TRUE);

with no language code, so even if we end up going with that (would rather not since this is a complete duplication of large arrays just for a couple of t() calls) the patch here needs work.

te() is an API change and a major DrupalWTF one at that, since t() alone is more than confusing enough, let alone more than one possible wrapper (we already have st()).

I don't quite understand why this is needed. Menus run into this same thing, and the solution is simply not to wrap titles/descriptions in t(). Can't we make the rule here?

According to #10, Gabor is on board with the patch in #8. This is also an API change to a bunch of cache_clear calls, but this affects far fewer module developers than every single _info() hook.

Menus run into this same thing, and the solution is simply not to wrap titles/descriptions in t(). Can't we make the rule here?

Yes we could do this, I think it means i18n module would need to handle entities and some other info hooks separately in D7, I think that makes the most sense though.

I'm not sure whether I understand #14.

In general, however, I'm not sure whether we shouldn't prefer regular t() usage everywhere (too late to change hook_menu() & co, but anyway)... saves us a couple of t() calls on every page?

+++ modules/field/field.info.inc	5 Sep 2009 09:40:50 -0000
@@ -61,16 +61,21 @@ function _field_info_cache_clear() {
+  // The informations contain already-translated strings, so we have to cache
+  // and retrieve them based on the translation language

+++ modules/image/image.module	5 Sep 2009 09:40:50 -0000
@@ -622,10 +622,16 @@ function image_style_path($style_name, $
+  // The informations contain translated strings, and are thus cached by
+  // language.

1) s/informations/information/

2) Missing period.

3) Not sure whether those comments are needed in the first place.

Powered by Dreditor.

>And for each hook, it needs to know the 'translatable' keys. That's pretty tight coupling.

This certainly is no good way to go as there might be much more hooks that store translatable strings. In fact the same problem applies to the rules2 hooks and any other contrib that's going to cache its info data.

Cleaning-up the "language system" issue queue as per http://cyrve.com/criticals.

#18: hook_info_t-503550-18.patch queued for re-testing.

Alrighty. Looks like the only doable fix, unless we want to defer D7 to 2011.

Welcome to the wonderful world if i18n and all the complexity it introduces. ;-)

Patch looks good though. Committed to CVS HEAD.

Follow-up: #1542144: Mark strings as localizable/translatable (new t()-alike string function that isn't t(), only for potx)