i18n + CCK

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

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

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

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.

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. :)

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

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". ;-)

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

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

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

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

Thank you!

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

Cheers

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.

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?

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.

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

subscribing

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

Sweet. Thanks! :)

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

@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.

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.