Making "Available Options" Translatable

Are 'allowed values' in normal select list fields translatable?

Well it sounds like you know more about this than me, so if you can contribute any code please reopen.

I know in Drupal 7 there is a 'hook_field_prepare_translation' but I don't even get how to use it, and the field modules I'm looking at aren't giving me any clues.

I really need the options to be translatable like regular check boxes/radio buttons from core. I am willing to sponsor a patch. Any takers?

To get a feature like this with options translated, I ended up using a core select field and the Form API/Conditional Fields module, which allows you to use the core and i18n translation features. This is a bit more involved to set up, but the translation works.

I took a quick look at this and here's my tuppence.

The reason i18n_field does not pick up / translate options for select_or_other is that it looks by the type of the field (not widget!) and processes only list fields with finite sets of allowed values - see code here and here. Select_or_other, on the other hand, uses simple text field (or number, which is not relevant to the case at hand) which does not have an allowed values set at all.

While it might be possible (not sure) to torture i18n_field into making some exceptions, I doubt if it's possible to do so in a not-too-hackish manner to get the patch accepted. Hence, an eventual solution would need to be coded from scratch (relying on i18n_string) on this end, and probably in a submodule (as only a small part of users need it).

Marked #1922712: Make select or other translatable as a duplicate of this issue.

I also need to translate the options for select/radio buttons. Drave Robber it's right, because this module it's implemented as a widget for the Text field type, the i18n_field module doesn't register the strings to be localized.

I don't know why the creator of the module chose when coding it to provide the widget for the text field type (maybe he has a good reason). I changed the module to provide the widget for the list_text field.

select_or_other.field_widget.inc
line #13

function select_or_other_field_widget_info() {
  $field_types = array(
    'text_list' // instead of 'text'
    'number_integer',
    'number_decimal',
    'number_float',
  );

This way you'll have the option to translate the allowed values in the interface and will use the i18n_field module (although there's a little issue with this: http://drupal.org/node/1971714). It's just a start and some more modifications are needed (because when editing the field, Allowed values appears twice). See the screenshots attached.

This is a little tricker than just changing to text_list. If you do that, everyone's site who is currently using this on a text list field will break because the formatter will no longer be available. I don't know the logic behind doing this on a text field other than back in D6 and CCK it may have been easier to do this with a text field storage wise but now that fields are in core that does not seem to be the case.

If we are going to convert to a list field, we will need to adjust for integers, decimals, and floats as well. Also we are going to need an upgrade path. Really this should probably be a new major release for this feature to so people know big things are changing. Changing a field type is no small process either apparently. See http://stackoverflow.com/questions/7811840/convert-field-text-to-list-text-drupal-7.

I might be wrong but methinks text_list won't work as it presumes a fixed set of allowed values which sort of defies the whole purpose of '...or other'.

@Drave Robber The functionality I think it's the same.

@haydeniv Yes, it would be the case for a major release with upgrade path. But choosing this way fewer lines of code will be necessarily. If not, custom code using i18n_string/field API.

@sergiu.popa Makes sense to me. I actually created a new dev release for 3.x so we can get started on this.
You can track the status of the 3.x release here #1972166: META Select (or other) 3.x release

Also I marked #1832396: Internationalization Support as a duplicate of this.

Of course patches are always welcome.

Correct version now that we have a release created.

Here is a patch to provide some translation for Select (or other) fields. I needed this for a very specific use case, hence I didn't spend a lot of time trying to make all options work, however I think this is a step in the right direction. The only bit I am unsatisfied with is the use of hook_entity_view to show translations on the front end, however, as this module is providing a widget for the text module, I couldn't immediately think of a better way to hook in and attempt translations, suggestions and feedback are welcome.

Thanks for this patch. Tried it and so far works against 2.x and 3.x. Only slight problem I found is that it stores the key with the value when you enter the available options in the key|value format.

So you end up with this in the translation interface

Select (or other) Other
select_or_other:field_sectors:other field_sectors:other

Select (or other) Fisheries|Fisheries
select_or_other:field_sectors:#allowed_values:Fisheries|Fisheries field_sectors:#allowed_values:Fisheries|Fisheries

I've added a check for this to split up the key and value and only store the value for translation.

Also a minor issue there is a ddl() call left in the code (ever tried dsm() or is ddl even better?). I've re-rolled the patch (against 3.x) and removed that.

Hi @miiimooo ,

I would suggest to include "Select (or other) check boxes/radio buttons" as well. Something like:

if (isset($field['widget']['type'])) {
if($field['widget']['type'] == 'select_or_other' || $field['widget']['type'] == 'select_or_other_buttons') {

Tested the patch and it seems to be working OK.

Thanks

The patch in #15 worked for most things for me.
The only issues were for two lines

Line 88 was using the key for the translation string.
So it my case
for the key|value set : friends_or_family|Friends or Family

it would use
select_or_other:field_how_did_you_find_us:#allowed_values:family_or_friends
instead of
select_or_other:field_how_did_you_find_us:#allowed_values:Family or friends

So the translation string would not be found

I also added an isset condition on a if statement at line 494 to remove a warning that was being shown depending on my display mode settings.

I have added an updated version of the patch that worked for me.

Thanks for the help.

The attached updates #17 with the following:

1. Implements #16 to work with the buttons widget.
2. Consistently wraps the context value in htmlentities(trim()) - this fixes an issue I was having with non-ascii characters in the english strings causing translations to fail.

This patch is against 7.x-2.20, but I'll re-roll and follow-up.

As promised, see attached patch against 7.x-3.x.

Did I something wrong? I take the #18 patch against select_or_other-7.x-2.22., but nothing happens.
My Fields with "Select (or other) Check boxes" - Widget show not the "Available options" for translation under
Field => Translate => Fieldsettings.
Have someone a hint?

@umakart,

After applying the patch, go to the field settings page and save the field settings for each field to make sure the strings are in the translation system. From there, head to the Translation interface and search for one of the available options. They should appear and have a context like "field_example:#allowed_values:Possible Option". The patches do not address the issue of having the available options show up under the Translate tab.

Attached is the patch from #19 rerolled against the 7.x-3.x branch and tweaked a bit.

1. Cleaned up a few things to better match Drupal coding standards.
2. Switched to using hook_field_update_instance to refresh the available option strings for translation.
3. Use select_or_other_field_formatter_view() to translate the option when outputting the field value. This removes the need for select_or_other_entity_view() but means that using the "Select or other" field display formatter is required if translation is needed. This allows translation to work for any location where the field is displayed, e.g. Views in my case.

@CalebD
Now i got it! Thanks a lot for your guidance. My mistake to search under the Translate tab caused from this image: 3-translated-string.png

Thanks everyone for the work on this patch!

#22 applied cleanly but a string refresh only refreshed "other", not the other options.

It turned out that select_or_other_i18n_string_refresh() needed some fixes.

Attached patch exposes all options on my box - please test.

Note: strange that on string refresh i get "refreshed 1 string" but all options are translatable now... Is this a "feature" of i18n?

I write another solution.
I18N List

need PHP 5.4+
requirement modules:

• Mixin (Mixin)
• X Autoload
• I18N

It can use Field Translation UI to help more easy to translate. (Use filed textgroup)

But I found a litte problem.
When you input 'label' as key in Available options then see a translated node page, you will see the translated value which has the 'label' key replace the field label text.
I have no idea to debug the problem, please help me.

label bug is fixed

2015/08/31: support Views Filter

The patch at #24 works great, but the available options are not translated if you use a token for the 'select or other' field (eg: in DS field code).

#27
I think we can get this patch in and work on follow-ups after for that use case.

I made two changes:

+++ b/select_or_other.field_widget.inc
@@ -347,6 +365,39 @@ function select_or_other_field_widget_settings_form($field, $instance) {
+  $settings = $instance['widget']['settings'];

This was giving me a warning while creating fields using the interface not every step has the widget in the instance array.

Also Implemented hook_field_create_instance because creating select_or other fields using features the update hook is not called when you install the feature for the first time and the strings never translated until you update the instance.

Added one more check to avoid warnings when the field instance is not complete.

Sorry I mixed in another patch from another issue.
Forget about #30

Now I'm adding one more check to avoid warnings when the field instance is not complete.

Mmm I guess the settings had to be checked separately

The following is just a review of the patch, no functional testing has been done.
I am all for fixing translation issues and think this should be resolved, but I don't want to add such an extensive patch without proper test coverage.
Also, I'd like the issue summary to be updated to reflect the current status quo. Which problem are we trying to solve and how do we want to solve it.

1. +++ b/select_or_other.field_widget.inc
   @@ -74,7 +74,12 @@ function select_or_other_field_widget_form_prepare_option(&$options, $key, $opt)
   -    $options[$opt] = html_entity_decode($opt);
   +    $key = $opt;
   +    $options[$key] = html_entity_decode($opt);
   

   This changes nothing?

2. +++ b/select_or_other.field_widget.inc
   @@ -347,6 +365,53 @@ function select_or_other_field_widget_settings_form($field, $instance) {
   +    empty($instance['widget']['settings']['available_options_php'])
   ...
   +    if (strpos($option, '|') !== FALSE && empty($settings['available_options_php'])) {
   

   I removed available_options_php in favour of an alter hook in commit affbee. There should be no more use of that key.

3. +++ b/select_or_other.field_widget.inc
   @@ -347,6 +365,53 @@ function select_or_other_field_widget_settings_form($field, $instance) {
   +    $option = filter_xss($option);
   +
   ...
   +      list($key, $value) = explode('|', $option);
   +      $option = (isset($value) && $value !== '') ? html_entity_decode($value) : $key;
   +    }
   +    else {
   +      $option = html_entity_decode($option);
   +    }
   

   This needs documentation.

4. +++ b/select_or_other.field_widget.inc
   @@ -347,6 +365,53 @@ function select_or_other_field_widget_settings_form($field, $instance) {
   +    select_or_other_tt($tkey . ':#allowed_values:' . htmlentities(trim($option)), $option, array('update' => TRUE));
   ...
   +  if (!empty($settings['other'])) {
   +    select_or_other_tt($tkey . ':other', $settings['other'], array('update' => TRUE));
   +  }
   ...
   +  if (!empty($settings['other_title'])) {
   +    select_or_other_tt($tkey . ':other_title', $settings['other_title'], array('update' => TRUE));
   +  }
   
   +++ b/select_or_other.module
   @@ -13,6 +13,82 @@ module_load_include('inc', 'select_or_other', 'select_or_other.test_form');
   +            select_or_other_tt($tkey . ':other', $settings['other'], $update);
   +            select_or_other_tt($tkey . ':other_title', $settings['other_title'], $update);
   

   Why run select_or_other_tt if the output is not used?

5. +++ b/select_or_other.field_widget.inc
   @@ -347,6 +365,53 @@ function select_or_other_field_widget_settings_form($field, $instance) {
   +  select_or_other_field_create_instance($instance);
   

   If we're doing this, create a helper function and call it from both hook_field_create_instance and hook_field_update_instance

6. +++ b/select_or_other.field_widget.inc
   @@ -592,8 +657,9 @@ function select_or_other_field_formatter_view($entity_type, $entity, $field, $in
   +
   

   extraneous whitespace

7. +++ b/select_or_other.module
   @@ -13,6 +13,82 @@ module_load_include('inc', 'select_or_other', 'select_or_other.test_form');
   +/**
   + * Wrapper function for translating items using i18n
   + */
   +function select_or_other_tt($name, $string, $options = array()) {
   

   Needs a better, more descriptive function name.

8. +++ b/select_or_other.module
   @@ -13,6 +13,82 @@ module_load_include('inc', 'select_or_other', 'select_or_other.test_form');
   +/**
   + * String refresh function
   + */
   

   Needs more extensive documentation

9. +++ b/select_or_other.module
   @@ -13,6 +13,82 @@ module_load_include('inc', 'select_or_other', 'select_or_other.test_form');
   +  $field_map = field_info_fields();
   +  foreach($field_map as $field_name => $field) {
   +    foreach ($field['bundles'] as $entity_type => $bundles) {
   +      foreach ($bundles as $bundle) {
   +        // We need to load the field instance to check the widget at this point.
   +        if (isset($field['type']) && $field['type'] == 'text') {
   +          $instance = field_info_instance($entity_type, $field_name, $bundle);
   

   This seems like a really expensive operation. How often is this called, can't this be done in a simpler, less expensive manner?

10. +++ b/select_or_other.module
    @@ -13,6 +13,82 @@ module_load_include('inc', 'select_or_other', 'select_or_other.test_form');
    +            $options = array();
    ...
    +            foreach ($options as $key => &$option) {
    +              $option = select_or_other_tt($tkey . ':#allowed_values:' . $key, $option, $update);
    +            }
    

    $options is populated but never returned or used. Why?

11. +++ b/select_or_other.module
    @@ -13,6 +13,82 @@ module_load_include('inc', 'select_or_other', 'select_or_other.test_form');
    +  return TRUE;
    

    Always return TRUE?

Next round.

I replaced the hook i18n_string_refresh with hook_i18n_string_list().

Small bugfix + basic tests.

DrupalCore/ CI do not understand project:module format in info files. :(

I forgot the tests in the patch file. Still waiting for #2860017.

I got the latest 7.3.x dev version
error: patch failed: select_or_other.info:6
error: select_or_other.info: patch does not apply

diff --git a/select_or_other.info b/select_or_other.info
index 51b4688..9e1bcc4 100644
--- a/select_or_other.info
+++ b/select_or_other.info
@@ -6,4 +6,7 @@ package = Fields
files[] = tests/select_or_other_admin.test
files[] = tests/select_or_other_number.test
files[] = tests/select_or_other_text.test
+files[] = tests/select_or_other_i18n.test
files[] = tests/SelectOrOtherTestBase.test
+
+test_dependencies[] = i18n

i could not find anything wrong with the patch on its self
but

+files[] = tests/select_or_other_i18n.test file does not exist
files[] = tests/select_or_other_admin.test file does not exist
files[] = tests/SelectOrOtherTestBase.test file does not exist

Tried it again from new dev download.
Now the patch works

except for the requirement line
patching file select_or_other.info
Hunk #1 FAILED at 6.
1 out of 1 hunk FAILED -- saving rejects to file select_or_other.info.rej

I have no idea why it did not take, added the line manual

extra issue with special caracters like ' gets translated to '

solution from here kind of same issue: https://www.drupal.org/files/issues/2018-03-21/auto_nodetitle-dont_doubl...

Reroll.

Hello Drupalers,
Patch #45 seems to be working fine using select_or_other 7.x-3.0-alpha3 and Drupal 7.63
Only the 'value' can be translated, not the 'key' (which is not a problem for my current project).
Thanks

Move the part to add the test_dependencies into an own issue. #3028600: Add i18n as test_dependencies

As long as 3028600 is not commited, the testbot can not tests the patch.

Closing as outdated because no activity in a long time and Drupal 7 goes EOL soon. Feel free to re-open if needed.

Patch in #48 is still working well against current 7.x-3.x-dev.

Thank you very much!

Automatically closed because Drupal 7 security and bugfix support has ended as of 5 January 2025. If the issue verifiably applies to later versions, please reopen with details and update the version.