Hello,

I'm trying to get support with the following issue: http://drupal.org/node/102621; my problem is knowing what's the name of the variables related to the fields of a specified content type, in order to be able to translate them.
I hope that someone will help me.
Thank you.

CommentFileSizeAuthor
#1 cck_missing_t.patch750 bytesMoxide

Comments

Moxide’s picture

Category: support » bug
Status: Active » Needs review
StatusFileSize
new750 bytes

Hello,
The fields' labels are available for translation through the system localization:
administer > localization > manage strings

But, there is a missing t() in content.module's theme_field function, that causes the displayed content page to show non-translated labels.
Here is a patch against 4.7-dev, that corrects it.

enli’s picture

Category: bug » support
Status: Needs review » Fixed

Just applied the patch, and seems to work perfectly!
Thank you so much for your help

yched’s picture

Title: CCK fields and i18n » Enclose field labels in t()
Category: support » bug
Status: Fixed » Needs review

enrico78 : An issue is not fixed because the patch worked for you :-)
The patch needs to be reviewed, to determine whether or not the modification gets included in the "official" code for the module.

enli’s picture

Oops... didn't know... sorry....

mki’s picture

Moxide’s picture

I think the new title of this issue is slightly inaccurate : field labels are already enclosed in t() !

The purpose of the patch is to add one missing t(), that causes the labels not to be translated when you view a node (when you edit a node, the labels are already translated).

enli’s picture

Category: bug » feature

I understand the importance of the issue, but I don't understand HOW to solve this problem; I mean, at the moment there is no alternative... so why should I prefer not to translate (I run my site in both english and italian) rather than using t()?

http://groups.drupal.org/node/1827

mki’s picture

Title: Enclose field labels in t() » Missing t() for field labels

Sorry of creating commotion. String translation: why using t() for user specified text is evil? -- this is future, but important to know what we can expect and which solution shoud be choose for our website today. If field labels are already enclosed in t() and this is only way we can translate field label, let's do it -- add t().

karens’s picture

I need some feedback from someone who knows the proper way to handle translations. In reading through various articles, it looks to me like we should remove the t() from all the field labels completely and just display and store the raw values, then let the i18n module handle translations. (Or perhaps we should keep all the t() functions, which may work correctly if the values are all stored in English so that the translations will work.)

I dug through the taxonomy module (which also lets users create names on the fly) and the 5.x version of the node module, and it looks like neither of them uses t() for user-created labels.

Anyway, can anyone who knows more about this provide some insight into the right way to handle this??

lor’s picture

Hi !

I got the same problem : I have translated my CCK fields labels with localization and no results !
I tried the patch above too, to see... No more results !
May I have to re-install CCK module ?
Won't it disturb my website (sorry, I'm a newbee !) ?
Thanks for any answer...

lor

Moxide’s picture

Hello,
Which version of cck are you using ?

@KarenS
I'm not an i18n specialist, and the only good method I see is to make i18n support CCK. That's what is done with the examples you gave (taxonomy and node).

maherg’s picture

The patch works flawlessly.

karens’s picture

I'm still waiting for someone who knows how the t() is supposed to work to provide some feedback. There are two questions:

1) Are we supposed to be using the t() anywhere in this module, including the edit fields, for user-supplied values. I'm not sure we are.

2) If it's OK on the edit fields, I'm still not sure it should be on the display fields, since we have to keep translated values out of the cache.

I'm not going to commit this without making sure about those two things.

dopry’s picture

Status: Needs review » Closed (won't fix)

we're just not going to fix this in 4.7. i'm sur eit will pop back up if it is a real issue..plus i18n has completely changed.