Missing t() for field labels
enli - December 11, 2006 - 13:25
| Project: | Content Construction Kit (CCK) |
| Version: | 4.7.x-1.x-dev |
| Component: | General |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | won't fix |
Description
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.
#1
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.
#2
Just applied the patch, and seems to work perfectly!
Thank you so much for your help
#3
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.
#4
Oops... didn't know... sorry....
#5
You may want look at this: String translation: why using t() for user specified text is evil?
#6
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).
#7
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
#8
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 and this is only way we can translate field label, let's do it -- add t().
#9
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??
#10
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
#11
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).
#12
The patch works flawlessly.
#13
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.
#14
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.