Hi,

First thanks for this a great module. I have a problem because currently I'm maintaining a multilingual site and the [site-name] was not translated. I now use the following hack to make the sitename translated:

$page_title_pattern =  str_replace('[site-name]', t(variable_get('site_name', 'Drupal')), $pattern);

but still wondering if there's any better way to do that?

CommentFileSizeAuthor
#3 token_tt.patch1.56 KBaufumy
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

nicholasThompson’s picture

nicholasThompson
Primary language English
CreditAttribution: nicholasThompson commented

Hmmm Translated tokens! Interesting. How do other token modules get around this?

nicholasThompson’s picture

nicholasThompson
Primary language English
CreditAttribution: nicholasThompson commented
Project: Page Title » Token
Version: 6.x-2.x-dev » 6.x-1.x-dev
Category: feature » bug

Turns out other modules dont get around this ;-)

Spoke to eaton on IRC and it turns out this is an issue with Token which is under discussion...

aufumy’s picture

aufumy CreditAttribution: aufumy commented
Status: Active » Needs review
FileSize
token_tt.patch1.56 KB

add i18n module tt wrapper, to allow node type info to be translated

Dave Reid’s picture

Dave Reid
he/him
Primary language English
Location Nebraska USA
CreditAttribution: Dave Reid commented
Category: bug » feature

I wrote in #545710: Token are not all translated correctly, which was marked a duplicate of this issue:

Token would have to pass those strings through t() as a variable, which is explicitly discouraged in t()'s documentation, but I've seen done elsewhere. The other option is to define a small token function that can run i18nstring.module's tt() function (for example, see #635474: Add support for i18n to translate node type names). The third option would be to define your own tokens for the translated node type.

Since core's D7 token implementation does not translate variables, I think we should put this as won't fix since #3 is the only appropriate solution.

Plus, translating something that's not normally should probably be a feature, not a bug. :)

srobert72’s picture

srobert72 CreditAttribution: srobert72 commented

Subscribing

Dave Reid’s picture

Dave Reid
he/him
Primary language English
Location Nebraska USA
CreditAttribution: Dave Reid commented
Status: Needs review » Needs work
mediamash’s picture

mediamash CreditAttribution: mediamash commented

any updates on this? Is this feature available in dev version? this would be superb for SEO reasons!

intyms’s picture

intyms CreditAttribution: intyms commented

subscribing

klonos’s picture

klonos
he/him
Primary language English
Location 90% Melbourne, Australia - 10% Larissa, Greece
CreditAttribution: klonos commented

Ping?

Dave Reid’s picture

Dave Reid
he/him
Primary language English
Location Nebraska USA
CreditAttribution: Dave Reid commented

The i18n module should provide its own tokens if it needs to.

Dave Reid’s picture

Dave Reid
he/him
Primary language English
Location Nebraska USA
CreditAttribution: Dave Reid commented
Status: Needs work » Closed (won't fix)
liquidcms’s picture

liquidcms CreditAttribution: liquidcms commented

Dave, i dont think this is about tokens specifically for i18n. Its about the token framework being able to support other modules adding tokens that can be translated.

I see it used in some token code now; but when i just added some new token code and wrapped in t(). The strings never showed up in translation interface search.

Dave Reid’s picture

Dave Reid
he/him
Primary language English
Location Nebraska USA
CreditAttribution: Dave Reid commented

That's because doing t($variable_or_something_that_is_not_actually_a_string); is an invalid usage of t().

liquidcms’s picture

liquidcms CreditAttribution: liquidcms commented

in mymodule_token_values()

if i have

$values['some-token'] = t("some string i would like to translate");

this string is not searchable in translation interface.