I am running advanced forum on a multilingual site with English and Spanish. The New [Content Type Name] button only displays the default language content type name no matter what language you are viewing the site in. Tested on fresh install with same results. Modules used on fresh install:

Drupal 7.12
Advanced Forum 7.x-2.0
Views 7.x-3.3
Chaos tool suite (ctools) 7.x-1.0-rc2
Variable 7.x-1.1+19-dev
Internationalization 7.x-1.4+20-dev
Localization update 7.x-1.0-beta3

I made the Forum topic content type translatable and added a translation for content type name in Spanish but it does not display for the button when you visit the forum on the Spanish site. if you go to the node/add page the translation is working just fine.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

trigdog’s picture

Status: Active » Needs review
FileSize
900 bytes

Here is a patch that localizes the content type name with i18n_string_translate.

BTMash’s picture

Michelle asked for a comment in here though as someone with old i18n experience...is there a reason to use i18n_string_translate over t()? t() seems like a more flexible option. Plus...doesn't something in i18n take over when passed through t() (that is what the string overrides module does)?

trigdog’s picture

Agreed, I thought t() would work too. That is what I did first, but I couldn't get it to work. Maybe you can enlighten me :)

// Fetch the "General" name of the content type.
$node_type = node_type_get_name($type);
$node_type = t('@content_type', array('@content_type' => $node_type)); 

This still gives me just the default language (English) content type name ever if I am viewing the site in Spanish.

BTMash’s picture

@trigdog, it should just be t($node_type) because the @content_type is taken as a placeholder that will come through without being translated. http://drupal.org/node/322732 has much more information on the topic.

Michelle’s picture

Status: Needs review » Needs work

Thanks for your help, BTMash. I've only done English sites so my localization knowledge is sketchy at best. It's sounding like this still needs some work so setting the status appropriately.

BTMash’s picture

Status: Needs work » Needs review
FileSize
619 bytes

Given that I **think** this should just get wrapped in a t() function (or maybe someone else has a better idea - there must be something I missed), attaching a patch.

Michelle’s picture

Hmm... I was curious why core didn't do this and went to see what was done there. Looks like it's change quite a bit from what I remember in D6. While adding t() here seems like it would work, I wonder if we should be considering all that core is doing here and if more of it should be copied to AF?

http://api.drupal.org/api/drupal/modules!forum!forum.module/function/for...

I'm going to defer to troky as he is more familiar with AF in D7 than I am (not to mention more likely than me to make actually do the committing ;) ). Just throwing that out there as a suggestion.

trigdog’s picture

@BTMash,
I can confirm that your patch using t() works. Thank you :)

troky’s picture

Patch from #7 looks fine to me. I will commit it later.

Michelle’s picture

Thanks, troky!

troky’s picture

Status: Needs review » Fixed

Commited.

Michelle’s picture

Thanks BTMash and troky!

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Drave Robber’s picture

Anybody’s picture

This is still not in the latest stable version, but critical for all multilang-sites. It takes at least half an hour to find this bug and fix it.

I think we could need a new stable release containing the fix soon. Is that possible?