Possibility to integrate cck fields?

Can you describe the request in more detail? Do you want to translate CCK fields?

yes i want to edit the translation of the cck-field labels in the translation table and if possible sorted by content type.

I would also like this feature (the ability to translate cck custom content type field labels).
I have been looking through the code but I really have no idea where I should add/edit.

So far I know that the cck field labels are stored in content_node_field_instance.
Also I saw that translation table gets everything from locales_source and locales_target, right?

I'm trying to figure out the best way to approach this... any ideas?

i am interested in an easy way to translating the filed values of cck-fields. does anyone has an idea?
thnx!

I believe this could be easily done as soon as the following gets in: #531660: i18n + CCK.

I feel like i18n support in drupal is advancing like crazy in the last month! I'll gladly test any patch submited.

This is great!

Ok, here's a patch that adds a new tab "CCK" that allows you to deal with CCK related strings.

The patch is against latest development snapshot of Translation table module and requires the latest dev snapshot of CCK2 or CCK3 + the i18ncck module posted here: #531660: i18n + CCK.

Attachment	Size
translation_table_cck-499668-7.patch	8.88 KB

nice patch, thanks

I think this is little bit crazy to use a translatable string as array key..

and I guess the cck_scope filter could get really long quickly, so I will probably separate it into two filters as "content type" and "field". The field filter will have to be loaded via ahah callback as it depends on the content type. Let me know if you would like to work on this also.

is this ok? this does not seems good to me. are field labels translated like this in CCK?

Thanks for review. :)

- t() is used as keys because it is used to build a select list with optgroups. So these keys are the labels of those.

- I've been testing this patch on a site that has a lot of content types and fields with allowed values. The select in this filter was not too big, and it should not grow too much, I think.

- t() to wrap the field labels is how CCK is coded, and how translations of CCK fields work when i18n is not present, so I used the same convention here. You may want to use tt() here, but since this is not the case when building the select of content types in other filters I did not spent much time on that. This could be food for a separate issue, maybe.

I coded it like this because if you try it, one single select for both things is much easier to understand than more than one select.

I do not have much interest on this. I'm co-maintaining CCK, and it was requested to add support for i18n. I dealt with that, and then updated the i18ncck module in the i18n queue, and then found this issue and thought I could do this quickly. I just hope it helps, at least as a starting point to include support for CCK in TT. :)

References:

- #531662: Internationalization support (CCK issue - status: committed).
- #531660: i18n + CCK (i18n issue - status: needs review).

awesome, I learned something new. Added one module_exists() check to fix the "Fatal error: Call to undefined function content_fields()" and committed http://drupal.org/cvs?commit=251326

I do not understand why only the book content type is displayed (no page nor story) in the filter when I've just enabled the i18n and cck modules before testing. But never mind, I will just forward every support request to you ;) You should not have touched translations, it's a real trap.

Re: "... no page nor story ..."

hmm... you need to install the i18ncck module posted here: #531660: i18n + CCK. Then, make sure translation is enabled for your content types, then Refresh the strings of type CCK in Translate interface. Then you should see your fields, fieldgroups and allowed values list in TT.

Re: "Added one module_exists()"

Oops! Sorry about that.

Re: "You should not have touched translations, it's a real trap."

lol

Thank you! :)

Sorry for re-opening. I made a mistake in one place. :(

When building the list of content types for the CCK filter, we should not filter out types with translation disabled because CCK Fields are not content, but user interface literals that we should be able to translate.

Here's an inline patch that should fix this. It affects function translation_table_cck_filter() in file includes/admin.inc.

PS: For some reason the development snapshot has not been updated. :-|

thanks, committed
http://drupal.org/cvs?commit=252072

hopefully the new commit will fix the problem with the development snapshot.

Thank you!

For some reason, the development snapshot has not been updated yet. :-|

I have opened an issue to the Infra queue: #552586: Development snapshots not being updated?

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