Translation support

Hi Roberto,

Localizer looks really appealing, integrating cck with it seems like a good idea, of course.
CCK already "integrates" with other contrib modules (Views, Pathauto), the preferred way when possible being the inclusion of an additional .inc file containing the relevant code, in order to ensure clean separation.

Can you provide more info on the changes you mention ?

Thank you for addressing this issue. Translation of CCK content types is one of the most important issues on my list.

Will it also be possible to provide/store translations of the human-readable name of a content type?

The labels of select boxes/check boxes/radio buttons are currently setup as key|value pairs using one single textfield widget for all key|value pairs. I don't think that it will be possible to provide a user friendly way to translate those labels using this approach. We probably need a new interface for defining the key|value pairs. We probably need a separate widget for each key|value|label pair of an option widget. The key and value of an option are certainly the same for all translations, but just the label needs to be translatable.

The tricky thing here is going to be interacting with the CCK cache. We can't cache translated values which is why many things don't use the t() function. Unfortunately, I have no solution, I just wanted to bring this up and keep it on the table.

Cache : this could be possible.

More generally, we have to take these two facts into account :
- you probably don't want to have to ship localizer with patches the user should apply to cck (wich code is constantly moving anyway...)
- we probably don't want to sprinkle if(module_exists('localizer') { } branches all around cck code. And what you describe does not seem to be containable in a content_localizer.module...

For instance, I don't think the UI to translate field labels belongs to cck - it should be implemented through hook_form alter form another module - which would probably be localizer.
Intercepting fields on display to translate labels might not be easy too.

I just wanted to point out that "Text - text fields" as opposed to "Integer - text fields" get translated OK (using Localizer and as the CCK stands at this moment) but only when you "edit" the node not when you "view" it (??????)

I guess that is happening because not all strings are wrapped around "t()" function ? (as KarenS is pointing out)

What would happen if all "field label text" were wrapped around in "t()"s ? would I run into trouble with the CCK cache or the drupal cache ?

(In my setup the "limited" translation of "text text fields" labels is taking place OK - I do have drupal cache disabled though)

The CCK cache is the issue. Each node's view is cached so you don't have to re-run all the field queries every time someone views the output, so nothing in the view can be wrapped in a t() unless we store a separate cached view for each language. Doing that would require code changes, so it has to be carefully thought through. There's no problem on the edit form since that's not cached, which is why wrapping form labels in t() works fine.

i finally managed to get a temporary solution http://drupal.org/node/119103#comment-205029

translates the CCK field labels
and apparently the field values are searchable (??)

That's an interesting solution, and I think it could actually be done in the core version so you don't have to customize your theme. yched, you work with translations more than I do. Do you see any problem with making that change to field.tpl.php in CCK?

Just for reference, the change to field.tpl.php is to add the t() there, as:
if (!$field_empty) : $label = t($label);

Sure, we should have done that earlier
(I did not actually have to set up any multilingual site yet, so I type my labels directly in french :-) )

I guess I'd rather do that like in the attached patch, actually.

Thinking about this more, will this still end up getting cached? It won't go into the CCK cache but would go into the regular page cache if caching is used, so might still be a problem if we do it in the content module itself. Sites that only have a single language could safely use it in their themes, though, so maybe we just need to document that.

Maybe it's really OK, just checking.

I have been using it with drupal cache ON all this time and it seem ok

We're sort of hijacking the thread, which was much larger than just labels (which are harmless IMO)
My fault, I should have posted my followup #13 in the 'display translated labels on node view' thread : http://drupal.org/node/119103.

and the patch should not be reviewed here - I'm posting it to the other thread

FYI, the 'translate label on node display' issue in http://drupal.org/node/119103 is now fixed

Any progress on that, yet? Is it possible to translate the prefix/suffix strings of a field?
I have fields like 'Maximum Occupancy' where the English suffix is 'person|persons', but in another language this has to be translated.

Will it be possible to translate CCK field labels with Drupal 6?

This is an old thread from the D5 version and translation is handled differently in D6, plus there are more recent issues about it and the Localizer module seems not to have a D6 release. Unless there is some specific task that still applies to the D6 version, I'm going to close this issue as being outdated.