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)
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)
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@dwwright.net 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@drupal.org http://lists.drupal.org/mailman/listinfo/translations
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)
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!
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)
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@dwwright.net 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@drupal.org http://lists.drupal.org/mailman/listinfo/translations
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)
-
Derek Wright -
Fernando P. García -
Hans Salvisberg