hook_language_init is a bootstrap hook and needs bootstrap_invoke_all()

regarding this issue, think about its "backport", which would consist only in some documentation #681938: document proper practice for mymodule.token.inc files

I can't duplicate this since it works just fine for me. This shouldn't be necessary since module_implements() should auto-include the .tokens.inc files. Please re-open if you can re-confirm with latest HEAD code.

Can you see if #710860: Static caching in drupal_multilingual() breaks tests fixes it?

Oh wow, yeah you're right. Enabled a second language and *poof* there went tokens. So the problem is when we have multiple languages enabled, the call to module_invoke_all calls module_implements before we have a full bootstrap, add all modules loaded. So its caching the wrong information.

Ok got this figured out. Since its called before we have a full bootstrap, we need to convert this to bootstrap_invoke_all() so that hook implementations aren't cached too early.

Tested the attached patch and confirmed that we get the correct results from module_hook_info() and tokens worked.

Upgrading to critical as it breaks functionality completely if more than one language is enabled.

Ack, yeah. Give this one a try. It uses the same format as module_invoke_all().

Fixed. Back to RTBC.

I'd love to test and review this patch but it is outdated and can't be applied to the current D7 dev release. Could you please re-roll the patch?

#18: 642782-language-init-bootstrap-D7.patch queued for re-testing.

The patch is for bootstrap.inc revision 1.352 but the current file is of revision 1.362 and the file has changed a bit since.

The patch still applies fine. Here it is re-rolled to remove some offsets.

Some other patch got mixed into that one.

Thanks for catching that.

code looks good to me. nice detective work

Works fine here too.

I'm confused. I searched core for language_init and didn't came up with any results.

drupal-cvs dries$ grep -r "language_init(" *

There aren't any core implementations of it. It's merely for contrib I'm guessing. But the fact is it causes major problems with module_implements() caching.

I'd like to better understand that hook then. Is there a reason that hook should be called language_init? Why can't those modules use _boot() ? It sounds to me like this warrants some code comments.

I was asking about the name of the hook because other modules might want a similar hook? I'm not sure other use cases exist. If they are other use cases for a similar hook, we should probably go with a more generic name?

@Dries: hook_language_init() was introduced to have a safe method to translate configuration variables, translation that cannot rely on the method proposed in #593746: Prepare Drupal core for dynamic data translation; IIRC the _init suffix has been given because the hook invocation happens in the language initialization phase.

To generalize this approach we might want to introduce a bootstrap hook to alter the configuration variables (e.g. hook_configuration_alter()) at a proper bootstrap phase. This must happen after language initialization to be useful, though.

Thanks for the explanations. That seems to make sense. Could we, at a minimum, at some minimal documentation so we don't end up scratching our heads 2 years from now?

Here is the hook documentation. I reverted the cufa change as the $types parameter was uneeded.

rerolled

Looks good, thanks!

I'm still slightly puzzled for the need of this hook. Typically, variables are translated on output.

@Dries: Actually, no. :) Variables are user-defined strings and therefore shouldn't be translated via t() at all, since the source string can change without notice and you'll lose any translation you had for it. The i18n module for D6 implemented a tt() function to translate arbitrary user-defined strings, but that didn't gain full momentum throughout Drupal. A couple of Internationalization team members are now working on new translation systems for D7 over in the http://drupal.org/project/translation project. Among those is #593746: Prepare Drupal core for dynamic data translation, which identified the need for a dedicated hook to translate variables, which runs as early as possible in the bootstrap (ie. directly after variables and the language system have been initialized).

Thanks for the explanation in #41. I think we could make the PHPdoc of the example code in the patch a bit more meaty by embedding some of that information into it. It would have avoided my questions.

meatier docs :)

+++ modules/locale/locale.api.php	6 Apr 2010 22:39:56 -0000
@@ -25,6 +25,34 @@ function hook_locale($op = 'groups') {
+ * variables. ¶

trailing whitespace :(

Powered by Dreditor.

Committed to CVS HEAD. Thanks.

 /**
 * modules implementing hook_boot() should be aware that language initialization
 * did not happen yet and thus they cannot rely on translated variables.
 */
function hook_language_init() {

that's incorrect, either add it to hook_boot or change it to hook_language_init

So, something more like this?

A good chance to clean a couple of things up.

+++ modules/system/system.api.php	7 Apr 2010 20:10:54 -0000
@@ -864,31 +864,41 @@ function hook_forms($form_id, $args) {
- * For example, this hook is a typical place for modules to add CSS or JS
- * that should be present on every page. This hook is not run on cached
- * pages - though CSS or JS added this way will be present on a cached page.

Looks good. Just a question: why were the lines above removed?

Powered by Dreditor.

No longer sure why I removed it. I guess because it sounds like we are suggesting that it is a good idea to globally and unconditionally add JS/CSS on all pages.

IMO the comment above suggests that might exist cases in which makes sense adding JS/CSS on all pages. What about restoring it? ;)

Bugs are fixed in the development version first, backported then.

The patch needs a reroll.

hook_language_init is gone from 8.x