Here's a module which provide translation for CCK fields (labels, descriptions, options).

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

neochief’s picture

This module depends on some changes to CCK: #531662: Internationalization support

neochief’s picture

Issue tags: +i18n + CCK
neochief’s picture

Jose Reyero’s picture

Status: Needs review » Postponed

Your module looks good, but it still needs the cck side patch. If that ever gets in we just add this module.

Otherwise, sorry, but no way we are shipping patches with the modules

neochief’s picture

Yes, I know, thanks for review, will lobby that patch :)

markus_petrux’s picture

For the project I'm working on, we're starting to play with i18n right now, so I expect to have time to review the proposed CCK patch and this module, hopefully soon.

drupal_alter() against the whole content types structure could be dangerous, as it opens the door to other module to alter things that shouldn't be altered. I'll try to find a way to just expose a structure of data for i18n.

Well, subscribing here. Updates on possible alternatives to the current i18n+CCK patch will be at #531662: Internationalization support.

markus_petrux’s picture

As posted in the CCK issue, I think we have now something that needs testing, and that's aimed to cover field labels and descriptions. I'm not 100% sure about allowed values and content_format().

For example, in content_format(), item values are not always in $item['value']. What about fields that are not strings? ...etc.

So I would focus on the translation of labels/descriptions of CCK fields. This module could then be committed here, starting to support that. And once we one one piece, we can work/think on the others.

Well, it's just an idea. :)

neochief’s picture

FileSize
1.62 KB

Attaching updated version (I think tarball is preferred, until module will be ready to be included).

markus_petrux’s picture

Status: Postponed » Needs review
FileSize
1.34 KB

Hi, the CCK module already has the feature for fields and allowed values. I'm going to commit the stuff related to fieldgroups asap.

And here's an updated i18ncck module in tar format.

I have tested this on our environment and seems to work nicely.

PS: After downloading, rename the file from "i18ncck.tar_.gz" to "i18ncck.tar.gz". ;-)

markus_petrux’s picture

I'm going to commit the stuff related to fieldgroups asap.

Done. Support for fieldgroups committed to CCK repo (branches CCK2 and CCK3). ;-)

markus_petrux’s picture

FileSize
1.36 KB

Tar updated to fix drupal_alter() implementations to avoid generating entries when descriptions are empty.

Jolidog’s picture

Just tested this sub module, it's working great!

Thank you!

markus_petrux’s picture

Also posted a patch to add support for CCK to Translation table module, here: #499668: Possibility to integrate cck fields?.

Cheers

markus_petrux’s picture

FileSize
1.31 KB

The tar in #11 has an issue: we're filtering out content types that do not have translations enabled, but we shouldn't because CCK stuff is not content, but user interface stuff.

Attached tar fixes this.

Please, rename the file extension from "tar_.gz" to "tar.gz" before extracting.

Pasqualle’s picture

can you give an example when it makes sense to translate a CCK field of a non-multilingual node? Or you mean that a CCK field could be attached to other entities also, therefore the filter is wrong?

markus_petrux’s picture

What we're translating here are field labels, descriptions, etc. and this is part of the user interface. That is, regardless of the fact that nodes of a particular content type can be translated or not, CCK field labels, descriptions, allowed values, etc. should match the user interface language, therefore these strings should be translatable.

markus_petrux’s picture

Is there anything else we can do to make it easy to validate this addition to i18n?

Once this is included, we can start removing the use of t() in all those modules than display CCK field labels, etc. And this will avoid all those warnings that are displayed by Coder module when it finds t($field['widget']['label']), or when running potx to generate translation templates. :)

For example, once this module is committed to i18n, I would love to awake the following issue in Node Relationships module queue: #557070: Deprecate use of t() for field labels as soon as i18ncck module is committed to i18n project

attiks’s picture

subscribing

neochief’s picture

Status: Needs review » Fixed

Commited to 6.x-1.x-dev. Thanks! Marking this as fixed for now.

markus_petrux’s picture

Sweet. Thanks! :)

Status: Fixed » Closed (fixed)

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

Jose Reyero’s picture

Status: Closed (fixed) » Active

@neochief,

Nice work.

But I am thinking now this would be better merged into i18ncontent module, what do you think?

Also having a textgroup like 'CCK' is not much help for translators so maybe everything in 'Content types' text group would make more sense.

MantasK’s picture

Does cck translation module work correctly? My default language is not English. So I enter label and options for select type in my native language. They all correctly appear in "Translate interface", but when I choose English on node view, strings are not translated. And I cannot use t() function in my template file, because there I must put English, but text comes not in English.

heliotrope’s picture

@Mantask

I had the same issue.
Default language set to french and english translation of cck label did not display.
I noticed that the location field in db were wrong.
I fixed this by refreshing the cck string (build/translate/refresh)

Hope that helps.

:)

EDIT : DO NOT USE REFRESH FEATURE or you will lose all your translation => http://drupal.org/node/732680

kewlguy’s picture

subscribing

loominade’s picture

subscribing

gease’s picture

It would be nice if this feature supported translation of field suffix/prefix as well.

Jose Reyero’s picture

Component: Code » Blocks
Status: Active » Closed (won't fix)

We are no adding any new features to i18n 6.x at this point so you can try creating a stand alone module.