Closed (won't fix)
Project:
Content Construction Kit (CCK)
Version:
4.7.x-1.x-dev
Component:
General
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
11 Dec 2006 at 13:25 UTC
Updated:
23 Jul 2008 at 21:53 UTC
Jump to comment: Most recent file
Comments
Comment #1
Moxide commentedHello,
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.
Comment #2
enli commentedJust applied the patch, and seems to work perfectly!
Thank you so much for your help
Comment #3
yched commentedenrico78 : 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.
Comment #4
enli commentedOops... didn't know... sorry....
Comment #5
mki commentedYou may want look at this: String translation: why using t() for user specified text is evil?
Comment #6
Moxide commentedI 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).
Comment #7
enli commentedI 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
Comment #8
mki commentedSorry 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().
Comment #9
karens commentedI 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??
Comment #10
lor commentedHi !
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
Comment #11
Moxide commentedHello,
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).
Comment #12
maherg commentedThe patch works flawlessly.
Comment #13
karens commentedI'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.
Comment #14
dopry commentedwe'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.