Translation of option labels (allowed values)

Let's make sure this is possible; otherwise, translation of options (lists) is pretty much useless.

Tagging for Commerce integration.

I didn't spend much time mulling on this in the latest months, but IIRC we were planning to support this through DDT. If this weren't possible (we had the serialized values issue), probably this is the right place.

@rfay:

A new object translation approach proposed by sun and to be implemented in contrib:

#593746: Prepare Drupal core for dynamic data translation

@rfay:

Also, @das-peter points out that this might be able to be done using the contrib cck module enabled and configuring a php function to return allowed values, which might be able to use t() (yuck) or some other approach.

This could be a good interim workaround, but we cannot use t() here, since we have user-defined strings, the choice is between using i18nstrings() or DDT (the relation between the two is still to be clarified). The only real alternative to those I can see, is a custom solution through Translation.

The actual core issue that tried to attempt this in light of DDT was #549698: Prepare field label and description for DDT (translatable queries) - which did not land for D7. :(

Since it didn't land, the allowed values are still stored in a serialized data column, and DDT/Translatable requires data to be contained in dedicated columns. Therefore, it's likely that we need to implement a workaround in Translation. IMHO, this belongs into Translation, because it's directly tied to fields and Translation module is about translatable fields.

subscribe

@rfay:

Running labels through t() would be ugly but might do the job...

It's not ugly, it simply does not work, I won't support this. You can easily workaround this with a custom PHP function that calls t(), but here we need to find a clean solution: as said above, either integrate with i18nstrings() or find a dedicated solution (i.e. storing translations somewhere in the field settings).

I don't think the requested functionality belongs in this module. This module is concerned with providing translation features for *user entered content* and not translation features for *the ui to enter that content*. This module does not let you translate the field labels and descriptions of the translatable fields either, does it? I think this belongs entirely elsewhere unless the scope of this module is blown up of course :)

@Gábor Hojtsy: Well, it's not that simple. If you want to be technically concise, the options/allowed values are user-entered content. (It's even a textarea... :P) We can certainly agree on the argument that it is an edge-case, and that's also the reason why it's not covered yet.

AFAICS, the main "difference" is that these texts are not really content (even though it could be perfectly valid considered as user-entered content), because they are not exposed as common content afterwards, but are configuration instead. To some extent, we have a similar situation with custom menu links, for example — for certain sites/use-cases, they should be considered as user content, but for others, they are plain configuration.

Regardless of that technical hair-splitting, we need a solution for this issue. The Translatable/DDT approach cannot be applied, because these values are stored in a serialized eat-all field configuration data column. I'm not sure whether the i18n project has any plans or existing efforts on the topic, but generally speaking, the Translation module is mainly about translatable fields; and the options/allowed values of a field are an substantial ingredient of fields. Therefore, I do not really understand the objection to the idea of solving this problem space within this module.

@rfay: well, in that light it does make sense yes. Will translatable fields also take on the responsibility of translating default values for fields then (or is that also already done in core)? Is translating field options and default the responsibility of field translation or would it also be applicable if you'd use some other translation method (such as node based translation?). So does it belong to this module or somewhere that can be shared between different translation methods? That is my thinking.

(I should look at where and why does field module uses the built-in interface translation method of Drupal 7 for translating field labels, that will make certain other things, such as trying to find unused leftover interface translations in the database much harder to implement).

@Gábor Hojtsy: The so called "node translation" approach, which involves two different nodes that are attempted to be kept in sync (i.e., the core Translation module) does not use translatable fields. However, you may have a point in that users of that translation method might still want to translate the field options/allowed values, as the translation nodes share the same fields (and thus also field configuration), so when translating a node into another language, you'd likely want to see translated field options, too.

However, this quickly brings us back to the fundamental discussion about the validity and general need for the node translation approach... In our many in-depth discussions over the past two years, we concluded more than once that the translatable fields concept is able to fully replace the node translation (and synchronization) concept including all possible use-cases. In turn, it is highly questionable whether it is worth to attempt to provide an independent general purpose solution in the first place.

Regardless of that, and to keep all doors open, we could implement the functionality in a sub-module, which may not necessarily has to depend on Translation module.

@sun: well, I took hours with the field translation module today and my assessment of the module to be fully be able to replace node translation, all interfacing modules such as views, rules, (node) access, nodequeue, etc. need to be aware that they need to support entity granularity below the entity level, basically on the "language sub-entity" level that the module defines, so that you can do things like listing German and French content on a site with views, or promote nodes in some languages but not in others, possibly maintain separate node queues, etc. That to me sounds like they need to rethink their relation system entirely, and work with "this language version of this entity" as a piece of entity versus "this entity". Given the module itself is in development, sounds like for all the contrib ecosystem to catch up with translations moving down one level is still to be off in the future.

I've elaborated on this more at http://hojtsy.hu/blog/2011-jan-31/drupal-7039s-new-multilingual-systems-... and would love your comments on how field translation could entirely replace node translation. I've also submitted a set of issues of problems I found, such as lack of support for revisions, which I thought is an inherent flaw of the approach but then found it is just not implemented yet and would be entirely possible. So many things I'm finding as current limitations are probably to be resolved in the future, but then I'm seeing that instead of thinking of an entity, we need to think of "X language version of the entity" as a piece across all of Drupal core and contrib. Even Drupal core's standard node listing page needs to be replaced to be able to list translated versions separately, so I can actually use its filters to look up unpublished translations with this model for example.

Anyway, this is a huge offtopic tangent, and I was thinking of not posting it, but it actually also serves as supporting rationale for not implementing unrelated functionality in this module that other methods of translations can use.

Moving to the Entity Translation queue. Read #902760: Change module name so it can work with Core translation for details.

i18n_field should address this.

I have the same problem.

The allowed values from the list fields of my custom content types never got translated.
Same is true for the allowed values defined in og_access.module and og_register.module.

Generally speaking all allowed values that don't come from an 'allowed_values_function' but are defined as an array in 'allowed_values' of the field settings seem not to get translated.

I attached a patch to this issue: http://drupal.org/node/1098796

#21 does work fine. Just download the Internationalization (i18n) package and then enable the Field translation (i18n_field) module which is part of the i18n package. It probably should be called Field settings translation though because it sounds like you should be able to translate the fields themselves rather than the settings (label/description/etc.) based on the current module name.

Kristen

I installed entity translation to translate content field and i18n to translate labels and select options.

When i edit or create a node i get correct translated options but when i view the node i get only default language options. Labels are OK.

I dont want to set this select field as translatable because i dont want the tranlated versions to have different selected options than the original.

@calculus: sounds like an i18n module bug, since you experience issues with the functionality that should have been made to work with i18n.

Thank you Gabor. I want to make sure that this isn't the designed behavior of 18n and that there is not some kind of conflict with entity translation. Should i post a bug to i18n issues?