Use of variables in t()

[Derek Wright-2]

In the D6 API docs for t(), it says:

http://api.drupal.org/api/function/t/6
> The only case in which variables can be passed safely through t() is  
> when code-based versions of the same strings will be passed through  
> t() (or otherwise extracted) elsewhere.
...

I have a few questions about this:

A) The D5 docs don't say the same thing.  However, this seems like the  
sort of thing that would be equally true of t() in both branches,  
unrelated to all the i18n changes in D6.  Can someone confirm that t()  
didn't change in D6 to allow for this edge-case, but only that the API  
docs improved?

B) I seem to have an example in one of my contribs where this edge  
case is being hit.  Once I add t($foo) to my code (where all possible  
values of $foo are listed via t() around string literals elsewhere in  
the code), potx.php starts throwing error messages about "Invalid  
marker content ...".  Is there anything I can do to tell potx "yes, I  
know, but this is that edge case where it's ok, please shut up  
again"? ;)


Thanks,
-Derek (dww)



_______________________________________________
translations mailing list
translations@...
http://lists.drupal.org/mailman/listinfo/translations

[Gábor Hojtsy-2]

On Tue, Dec 23, 2008 at 11:36 AM, Derek Wright <drupal@...> wrote:

> In the D6 API docs for t(), it says:
>
> http://api.drupal.org/api/function/t/6
>> The only case in which variables can be passed safely through t() is
>> when code-based versions of the same strings will be passed through
>> t() (or otherwise extracted) elsewhere.
> ...
>
> I have a few questions about this:
>
> A) The D5 docs don't say the same thing.  However, this seems like the
> sort of thing that would be equally true of t() in both branches,
> unrelated to all the i18n changes in D6.  Can someone confirm that t()
> didn't change in D6 to allow for this edge-case, but only that the API
> docs improved?

t() did not improve in this regard at all.

> B) I seem to have an example in one of my contribs where this edge
> case is being hit.  Once I add t($foo) to my code (where all possible
> values of $foo are listed via t() around string literals elsewhere in
> the code), potx.php starts throwing error messages about "Invalid
> marker content ...".  Is there anything I can do to tell potx "yes, I
> know, but this is that edge case where it's ok, please shut up
> again"? ;)

No, there is no way, and it does throw the same warnings on core code,
where the same applies. By the way, I'd advise you to upgrade your
potx, since later versions give better warnings and even link to more
docs where you can read details (and do not say criptic things like
"marker error").

Gábor
_______________________________________________
translations mailing list
translations@...
http://lists.drupal.org/mailman/listinfo/translations

[Derek Wright-2]

On Dec 23, 2008, at 3:07 PM, Gábor Hojtsy wrote:

> t() did not improve in this regard at all.

Duly noted, thanks.  Any objection to backporting these improved API  
docs to D5 to help avoid confusion?  If not, I'll roll a patch and  
submit an issue.

> No, there is no way, and it does throw the same warnings on core code,
> where the same applies.

Alas.

> By the way, I'd advise you to upgrade your
> potx, since later versions give better warnings and even link to more
> docs where you can read details (and do not say criptic things like
> "marker error").

Ahh, thanks for the reminder.  My version of potx-cli is from a very  
old DRUPAL-5 branch checkout.

Thanks for all the info,
-Derek (dww)



_______________________________________________
translations mailing list
translations@...
http://lists.drupal.org/mailman/listinfo/translations

[Gábor Hojtsy-2]

On Tue, Dec 23, 2008 at 6:15 PM, Derek Wright <drupal@...> wrote:
> On Dec 23, 2008, at 3:07 PM, Gábor Hojtsy wrote:
>
>> t() did not improve in this regard at all.
>
> Duly noted, thanks.  Any objection to backporting these improved API
> docs to D5 to help avoid confusion?  If not, I'll roll a patch and
> submit an issue.

Fine with me. I keep committing API docs changes to D6 so that our
code is better documented, not entirely sure about Niel, but I think
he can be convinced.

Happy holidays!

Gábor
_______________________________________________
translations mailing list
translations@...
http://lists.drupal.org/mailman/listinfo/translations

[Hans Salvisberg]

Derek Wright wrote:
> B) I seem to have an example in one of my contribs where this edge  
> case is being hit.  Once I add t($foo) to my code (where all possible  
> values of $foo are listed via t() around string literals elsewhere in  
> the code), potx.php starts throwing error messages about "Invalid  
> marker content ...".  Is there anything I can do to tell potx "yes, I  
> know, but this is that edge case where it's ok, please shut up  
> again"? ;)
>  

Here's what I do to get potx to shut up:

$tr = 't';
$tr($foo)

I forgot why I'm not using $t, but I think there was a reason...

Hans (salvis)

_______________________________________________
translations mailing list
translations@...
http://lists.drupal.org/mailman/listinfo/translations

[Derek Wright-2]

On Dec 23, 2008, at 6:53 PM, Hans Salvisberg wrote:

> Here's what I do to get potx to shut up:
>
> $tr = 't';
> $tr($foo)

Slick! ;)  Very clever, thanks!

> I forgot why I'm not using $t, but I think there was a reason...

Because potx still sees "$t($foo)" as if it's "t($foo)" and it gives  
the warning, anyway.  By using $tr($foo) it all works.

I guess it's a minor performance hit to do this, and it slightly  
obfuscates the code, so I doubt we can convince core to either  
implement or document this practice...

@Gabor: thoughts? ;)

Thanks,
-Derek (dww)



_______________________________________________
translations mailing list
translations@...
http://lists.drupal.org/mailman/listinfo/translations

[Fernando P. García]

Derek,

I'm sure you have a good reason to pass string $variables to t(), instead of "strings".

What current potx does is to respect(and honor) the Drupal coding starndards. So the "good practice" is to use t("string") for text translation.

What I suggest is to create a tin 4 lines alias function:
/**
 * Alias function of t(), use only with variables and constants.
 * For "strings" please use t() instead.
 */
function tr() {
  $args = func_get_args();
  call_user_func_array('t', $args);
}

I enjoy the $tr = t way, but perhaps core might realize about "what if..." ...somebody needs to silently(abot poedit) translate $variables and CONSTANTS.

Merry Christmas! Feliz Navidad!

On Tue, Dec 23, 2008 at 3:31 PM, Derek Wright <drupal@...> wrote:

On Dec 23, 2008, at 6:53 PM, Hans Salvisberg wrote:

> Here's what I do to get potx to shut up:
>
> $tr = 't';
> $tr($foo)

Slick! ;)  Very clever, thanks!

> I forgot why I'm not using $t, but I think there was a reason...

Because potx still sees "$t($foo)" as if it's "t($foo)" and it gives
the warning, anyway.  By using $tr($foo) it all works.

I guess it's a minor performance hit to do this, and it slightly
obfuscates the code, so I doubt we can convince core to either
implement or document this practice...

@Gabor: thoughts? ;)

Thanks,
-Derek (dww)

_______________________________________________
translations mailing list
translations@...
http://lists.drupal.org/mailman/listinfo/translations

--
Fernando P. García, http://www.develcuy.com
Developer - Analista de Sistemas
[phone], Mz. P Lt. 30 1et Urb. Pachacamac - VES, Lima - Perú

_______________________________________________
translations mailing list
translations@...
http://lists.drupal.org/mailman/listinfo/translations

[Derek Wright-2]

On Dec 23, 2008, at 10:42 PM, Fernando P. García wrote:

> I'm sure you have a good reason to pass string $variables to t(),  
> instead of "strings".
>
> What current potx does is to respect(and honor) the Drupal coding  
> starndards. So the "good practice" is to use t("string") for text  
> translation.

Yes, but there are a few cases where it's impossible to do so, and  
I've hit one of them.

> What I suggest is to create a tin 4 lines alias function:
...

But if someone happens to install two modules that define the same  
tr() function, they get PHP errors on duplicate function definitions.  
For this to be a viable work-around, it needs to be in your module's  
namespace, such as mymodule_tr().  I'm not sure that's fundamentally  
more readable than just doing:

$tr = 't';
$tr($foo);

And, the extra mymodule_tr() function invocation adds even more  
overhead than the variable...


Anyway, thanks to everyone who participated on this thread, very  
illuminating.

For anyone interested in the PHPdoc improvements, I posted the issue  
(with patches) here:
http://drupal.org/node/350708

Cheers,
-Derek (dww)



_______________________________________________
translations mailing list
translations@...
http://lists.drupal.org/mailman/listinfo/translations

[Fernando P. García]

 

But if someone happens to install two modules that define the same
tr() function, they get PHP errors on duplicate function definitions.
For this to be a viable work-around, it needs to be in your module's
namespace, such as mymodule_tr().  I'm not sure that's fundamentally
more readable than just doing:

What I mean is to include that function in the Drupal core. That's it.

Blessings!

--
Fernando P. García, http://www.develcuy.com
Developer - Analista de Sistemas
[phone], Mz. P Lt. 30 1et Urb. Pachacamac - VES, Lima - Perú

_______________________________________________
translations mailing list
translations@...
http://lists.drupal.org/mailman/listinfo/translations

[Derek Wright-2]

On Dec 24, 2008, at 3:11 AM, Fernando P. García wrote:

> What I mean is to include that function in the Drupal core. That's it.

Asking every user of my contributed module(s) to hack their copy of  
core (even to add a 4 line helper function) isn't a viable work-
around, either. ;)

But thanks for the suggestions.

Cheers,
-Derek (dww)



_______________________________________________
translations mailing list
translations@...
http://lists.drupal.org/mailman/listinfo/translations

[Fernando P. García]

Derek, hacking core is not a "good practice", my suggestion is for Drupal core developers. Nothing about hacking.

Blessings!

On Wed, Dec 24, 2008 at 4:05 AM, Derek Wright <drupal@...> wrote:

On Dec 24, 2008, at 3:11 AM, Fernando P. García wrote:

> What I mean is to include that function in the Drupal core. That's it.

Asking every user of my contributed module(s) to hack their copy of
core (even to add a 4 line helper function) isn't a viable work-
around, either. ;)

But thanks for the suggestions.

Cheers,
-Derek (dww)



_______________________________________________
translations mailing list
translations@...
http://lists.drupal.org/mailman/listinfo/translations

--
Fernando P. García, http://www.develcuy.com
Developer - Analista de Sistemas
[phone], Mz. P Lt. 30 1et Urb. Pachacamac - VES, Lima - Perú

_______________________________________________
translations mailing list
translations@...
http://lists.drupal.org/mailman/listinfo/translations

[Derek Wright-2]

On Dec 24, 2008, at 5:21 PM, Fernando P. García wrote:

> Derek, hacking core is not a "good practice", my suggestion is for  
> Drupal core developers. Nothing about hacking.

Sorry, we seem to be talking past each other.  If your suggestion is  
for Drupal core developers, then it needs to be in the form of an  
issue in the core queue to be useful, and your email to this list  
should include a link to that issue for interested parties (like I did  
with the issue about backporting the API documentation improvements to  
t()).  As an API change, your issue could only be for D7, and  
therefore, while helpful in the future, we'd still have this problem  
in D6 and D5 contrib.  Without a link to a core issue, it sounds like  
you're proposing a solution to this problem in contrib space, and I've  
been trying to reply to your suggestion as such.

Cheers,
-Derek (dww)



_______________________________________________
translations mailing list
translations@...
http://lists.drupal.org/mailman/listinfo/translations