t() cannot be used in a define() statement - document that fact.

I've been bitten by this at least once, so I agree that this should be in the documentation.

Perhaps we want to add a line saying what developers should do instead, because that isn't straight forward. Because t(DEFINED_CONSTANT) is evil as well. We can refer to the documentation in #336115: Additional documentation for t(), which covers translation of variables.

An extra line explaining what you should do sounds good. Marking to CNW for that.

Re $locale in the comment: do you mean $language?

Attached a patch which changes $local to $language.

Looks like the test bot was broken that day.

+++ includes/common.inc	24 Nov 2008 13:04:06 -0000
@@ -904,6 +904,9 @@ function fix_gpc_magic() {
+ * CAUTION: Do not use t() in a constant define() since $language is unknown at

Would the words 'not defined' possibly be a better alternative to the word 'unknown'? Also, I think the word 'constant' isn't needed. Besides that, I think this patch is nice and simple.

I'm on crack. Are you, too?

Oh gosh.

That text didn't really belong where it was inserted in the last patch. In trying to find a better place for it, I ended up reorganizing and rewriting much of the doc, in order to be able to add a short paragraph about not using t() in a define() statement, and having it all make sense.

patch no longer applies to HEAD.

#10: t_rewrite.patch queued for re-testing.

Looks like this patch does indeed need to be redone.

Apparently the t() function moved to a different file. Here is a reroll of the patch above.

looks good, nice style cleanups in addition to the define() documentation.

+ * Also, you cannot use t() in a PHP define() statement. The reason is that
+ * the language variables will not be initialized yet at the time t() is called,
+ * so the string will not be translated into the correct language.

This is not limited to define statements; any t() call before the language is defined will result in

1) an incorrect string
2) atrocious performance (at least this was so in the past).

ok... more specifically can we say that "before the language is defined" means that before DRUPAL_BOOTSTRAP_LANGUAGE is reached? How about this as an alternative?

/**
 * Also, you cannot use t() early in the bootstrap process, prior to the
 * DRUPAL_BOOTSTRAP_LANGUAGE phase. The language variables will not be
 * initialized yet, so the string will not be translated into the correct
 * language. Examples of places where t() cannot be used include:
 * - In a PHP define() statement.
 * - In a hook_boot() implementation.
 */

I like the suggestion in #18. Would you like to roll it into the patch?

Only change is the block from #18:

Oh gracious. I should really be shot for this one, and it was in my patch above.

The first line should start with a verb in 3rd person: "translates" rather than "translate".

Otherwise, I'm happy with this latest patch. What say you Heine?

ok, corrected first word. Feedback on the technical accuracy about DRUPAL_BOOTSTRAP_LANGUAGE would be appreciated.

Thanks for making that correction... I am happy with that patch. Perhaps Heine can comment on the technical accuracy question, since that is who brought up the latest round of re-patches?

Discussed with bdragon during the drupalcon sprint. We verified that the change proposed in #18 is accurate.

Patch still applies, so this should be ready.

Do you want to mark it RTBC?

yep!

Geez. ;) At least re-title these issues to something like "Fix everything in the world wrong with t()" so I know what I'm getting myself into. ;)

Anyway, took a spin through the changes and looked good overall.

Committed to HEAD!