Address fields are no longer multilingual variables and cannot be translated

a lot variables are not translatable anymore...

New account details help message in
/admin/store/settings/checkout/edit/panes

/admin/store/settings/checkout/edit/messages

/admin/store/settings/checkout/edit/fields

add to cart button

subscribing

I know this method tostubo but this doesn't work anymore after upgrade to 6.2.4.

If you succeed to resolve your issue, i could certainly do the same :-)
Could you please display the content of your file after patch. Thanks

I replace my uc_store/uc_store.module with yours, and I still have the same problem...

Have you inserted any i18n strings in your settings.php ?

Which version of i18n have you installed ? I have Internationalization 6.x-1.5.

I don't have this bug anymore with internationalization 6.x-1.6 http://drupal.org/node/902742

Works with internationalization 6.x-1.6 and seems to be broken again with 1.7?

Can confirm this issue with internationalization 6.x-1.5 issue fixed after upgrade to 1.6 and 1.7.
Solution: upgrade i18n.

"Needs review" is for when there is a patch to review.

Can confirm issue. I tried out the patch above and have not been able to get this to work. Broken in Ubercart 6.x-2.4 and I18n 1.7.

Tested this further using a fresh installed Drupal 6.19, Admin, CCK 2.8, I18n 1.7, I18n Views 2.0, Localization Update 1.0a, Token, Translation Overview 2.4, Ubercart 2.4, Views 2.11

For store config, I enabled enough stuff to run a basic working localized shop--added one product but haven't fiddled with settings yet or done translation through the translation interface. Only imported translations as per the automatic add language update stuff.
***Now, I went and checked the Address Fields in the checkout and they correctly switch language at this point.***

Now, if you go and change one word in Store Admin >> Config >> Checkout Settings >> Edit >> Address Fields
/admin/store/settings/checkout/edit/fields --> This will break translation of the address labels on the checkout page and you can't get it to work again, even clicking on restore to default doesn't help.

The changed words (address form field label) appears to be saved/used as the value for both languages (doesn't matter if you switch languages and change the value as it will only use the one you entered.

@coolnewmedia: You say "Tested this ..." - *what* did you test?

Sorry, I tested the patch and it *did not seem to resolve the issue*. However, it might still be a piece in this puzzle. As well, my exploration was to recreate the bug in a basic I18n shop; to help confirm the bug in a simple setup; and to help developers recreate it.

There's a patch in the original post, in #1, and in #2, and there's a complete replacement for a core Ubercart file in #10. Which one did you test?

#1 is wrong (deleting required variables), #10 is uc_store 2.4 + the patch in #2. I don't think these 2 additional variables are necessary to get language dependent, but it also doesn't harm.

#17 The point is "clean install". Changes of the label names on updated installs also won't work, but at least you have the old translated variables.

Since http://drupal.org/node/850708 i18n doesn't care anymore for variables saved in hook_form_submit(). The label variables are saved in function uc_store_address_fields_form_submit() line 800.

If I am right this would be a major change in the way i18n works affecting more modules, so I try to get some clarification in the above mentioned thread.

The first "variable_set()" is what UC needs to get supported again, otherwise we would be forced to separate the label names and the "required" settings in the form itself:

/**
 * Save the address fields settings.
 *
 * @see uc_store_address_fields_form()
 */
function uc_store_address_fields_form_submit($form, &$form_state) {
  $fields = array();
  $required = array();
  foreach ($form_state['values']['fields'] as $field => $data) {
    variable_set('uc_field_'. $field, $data['title']);
    if ($data['enabled'] == TRUE) {
      $fields[] = $field;
    }
    if ($data['required'] == TRUE) {
      $required[] = $field;
    }
  }
  variable_set('uc_address_fields', drupal_map_assoc($fields));
  variable_set('uc_address_fields_required', drupal_map_assoc($required));
  drupal_set_message(t('The configuration options have been saved.'));
}

Clarification on my patch test. I tested #2 and #10 (I realized #1 was wrong as well). I recall that I diff'ed #2 + #10 in my local SVN to see what it changed and didn't see any difference. Thanks for the further details Al01.

The problem seems to be in the uc_get_field_name function in uc_store/uc_store.module.

When a field name is requested, first a default value is fetched using the t() function. Which is as it should be.

*Then* a call to variable_get is made. If this returns something, whatever it returns overrules the previously fetched default. The result of the call to variable_get is *not* passed through t().

Meaning if during install or during some other time variables have been set for address name fields, they will never be returned to the interface translated.

What would be the proper solution to this problem?

For my own use I've employed this quick fix:

--- uc_store/uc_store.module	(revision 947)
+++ uc_store/uc_store.module	(working copy)
@@ -1196,7 +1196,7 @@
     return '';
   }
 
-  return variable_get('uc_field_'. $field, $default);
+  return t(variable_get('uc_field_'. $field, $default));
 }

It rather crudely translates every result of the call to variable_get.

Unfortunately, that solution is not workable. From the t() documentation:

However tempting it is, custom data from user input or other non-code sources should not be passed through t().

@longwave #24 : I understand, and thanks to the t() documentation and http://www.drupaler.co.uk/blog/multilingual-drupal-some-dos-and-donts/482 I now know to set those fields in the Store admin section.

However, that merely results in variables being saved in the new language. That does not make the address field names translatable (actually, it makes it worse, as t() uses the English strings to translate from.

So I guess what is needed is to rewrite the ubercart address field mechanism to no longer use variables for the address field names. This way, localization teams can provide translations (for the strings in questions many already exist, btw).

I'm aware that the drawback of no longer using variables is that site owners can't change the name of the fields anymore, but in my view that is a small price to pay for having translatable strings.

I'm willing to dig through the code and implement this change myself, btw.

@rhmtts did you find any way to get those address fields translatable ?
Thanks In Advance.

@mandreato #26 : either me or an ubercart maintainer would have to modify the code, but before that can be done a decision needs to be made about where address field names will be stored in the future, which I guess is up to the ubercart maintainers.

If any of them is reading this, I'd be more than willing to help out with Ubercart for Drupal 6 , seeing as that I'm currently knee-deep into a D6 Ubercart project and will probably continue to work with D6 Ubercart for quite some time to come.

Thank you rhmtts for clarification.

The thing is, I guess, that you want both to be able to define your own address fields (to use fax number instead of phone number for instance) and be able to use translation. My suggestion therefore would be to send the filled in fields (i.e. field title on the edit/fields page) through the translation process.

subscribed, thanks!

subscribing

subscribing

subscribing

btw, is .dev version solving this issue?

No it is not yet...

Easy hack, in a custom module add:

function custommodule_menu() {
  $items = array();
  $items['admin/store/settings/checkout/edit/fields_lang'] = array(
    'title' => 'Translate address fields',
    'description' => 'Translate the address field names',
    'page callback' => 'drupal_get_form',
    'page arguments' => array('custommodule_uc_store_address_fields'),  
    'access arguments' => array('administer store'),
    'type' => MENU_LOCAL_TASK,
    'weight' => 8,
  );  
  return $items;
}

function custommodule_uc_store_address_fields() {
  $form = array();
  //Copied from uc_store_address_fields_form
  $fields = array(
    'first_name' => array(t('First name'), TRUE),
    'last_name' => array(t('Last name'), TRUE),
    'phone' => array(t('Phone number'), TRUE),
    'company' => array(t('Company'), TRUE),
    'street1' => array(t('Street address 1'), TRUE),
    'street2' => array(t('Street address 2'), TRUE),
    'city' => array(t('City'), TRUE),
    'zone' => array(t('State/Province'), TRUE),
    'country' => array(t('Country'), TRUE),
    'postal_code' => array(t('Postal code'), TRUE),
    'address' => array(t('Address'), FALSE),
    'street' => array(t('Street address'), FALSE),
  );
  //Just loop and build the fields
  foreach ($fields as $field => $data) {
    $form['uc_field_'.$field] = array(
        '#type' => 'textfield',
        '#title' => $data[0],
        '#default_value' => variable_get('uc_field_'.$field, $data),    
    );
  }
  //Magic happens
  return system_settings_form($form);
}

Enable the module (or if it is in a working one, clear cache) and u will see the form in admin/store/settings/checkout/edit/fields_lang. Translate like u normally do with others i18n_variables ;)

hi all,

#36 --> this hack working?

subscribing

gr.

sven

@nonius #37
Hi,
I have just tried the hack from #36 and it is working for me.
Thanks @brutuscat!
Cheers.
Daniel

That "was" a major problem for over a year in the ubercart world.
Until @brutuscat saved us!!!

Thanks
#36 working like a charm for me too

Hi firewing1,

Did you test your patch? I tries it but it didn't work for me.

Hi Brutuscat,

Hope you don't mind, but I used you code above in my effort for a Ubercart translation module. Hope on you idea's and comments here: http://drupal.org/project/uc_i18n

Many thanks
Mark

Easy hack in #36 works for me.
I applied firewing1's patch in #2. No results.
I'm running version = "6.x-2.4"

p.s. Just by looking at the length of this thread... This should be set to Major, that is, unless you live in a single language world. :-/

I think we should be using the "variable" module.

* Copy the attached file as ubercart/uc_store/uc_store.variable.inc
* Enable the modules: variable variable_admin
* Tell Drupal that those variables are multi-lingual by going to /en/admin/config/regional/i18n/variable (check the appropriate variables, then save)
* You will then be able to edit the multi-lingual variables by visiting: /en/admin/config/system/variable/module

This also makes it unnecessary to declare variables in hook_init(). c.f. #855180: Add hook_i18nvariable()

If this sounds like the right solution, it should also be applied to other modules, such as

payment/uc_2checkout/uc_2checkout.module
payment/uc_credit/uc_credit.module
payment/uc_google_checkout/uc_google_checkout.module
payment/uc_payment_pack/uc_payment_pack.module
payment/uc_payment/uc_payment.module
payment/uc_paypal/uc_paypal.module
shipping/uc_quote/uc_quote.module
uc_cart/uc_cart.module
uc_catalog/uc_catalog.module
uc_product/uc_product.module
uc_roles/uc_roles.module
uc_stock/uc_stock.module

(I can provide patches)

Mathieu (bgm on freenode, #drupal-ubercart, #aegir, #civicrm)

New patch with small corrections for the grouping of variables in /en/admin/config/system/variable

I'm not sure though why it's failing the tests. I think it's more an issue with the tests, not my patch?

oops, i just realized my patch is for Drupal 7, and this issue is for D6.. sorry!

I think firewing1 put his finger on the problem in #44 with #1205804: Variables set in the submit handler functions of forms are updated but never created in i18n_variables...

subscribing

Fixing issue title.

Subscribe.

Subscribe.

The attached patch was sufficient for me. It adjusts uc_store.module

@PieterDC: Why did you set the issue to "needs work"? Is your patch incomplete? I changed the status to "needs review" so the testbot will look at the patch.

My patch only adresses store address fields, no customer address fields. That's why I set it to 'needs work'.

Thanks bgm for your solution in Drupal 7. It works perfect!!!

I tried to follow your directions but I can't:

* Copy the attached file as ubercart/uc_store/uc_store.variable.inc

done

* Enable the modules: variable variable_admin

done (it was)

* Tell Drupal that those variables are multi-lingual by going to /en/admin/config/regional/i18n/variable (check the appropriate variables, then save)

what? check variable here? I see:

Languages for content
x Enabled languages only.
x All defined languages will be allowed.
Determines which languages will be allowed for content creation.

(probably I just miss the right path for this)

* You will then be able to edit the multi-lingual variables by visiting: /en/admin/config/system/variable/module

From here if I select store, I can edit variable's but it is one value, so I have no translation, just one language, different from English, but I still want English, Italian and German .. this is multilingual, I missed something in the previous step I think

subscribing :)

This patch cleans up and fixes the address fields form at /admin/store/settings/checkout/edit/fields to support multilingual variables if i18n is enabled.

Committed #62. Needs testing and probably porting to 7.x.

longwave #47 bgm is for 7.x (it works I miss to activate variable translation)
I think shipping translation is missing

We should probably still port the improvements to the address fields form to 7.x, to keep the code consistent if nothing else.

@longwave
Yikes! The patch in #62 breaks the address field settings screen in Extra Fields Pane. Was it really necessary to rename $form['fields'] to $form['uc_address_fields']? I see you also added a $form['uc_address_fields_required'] somewhere.
Can you explain why you changed it like that? This way it may be easier for me to adapt Extra Fields Pane to the new situation.

I changed it so we could use system_settings_form() to set the variables rather than a custom submit handler, and i18n can also use this format to set the translated strings.

This patch ports #62 to 7.x and adds hook_variable_info based on #47. This lets you set translations for address field labels on the address fields form in Ubercart or the i18n variable settings form.

@longwave
Thanks for the explanation. I will adjust the Extra Fields Pane code (see issue #1697988: Cluttered admin screen with Ubercart 6.x-2.x-dev from July 18, 2012 or later). I plan to review #68 also, but I may not be able to do that this week.

I didn't manage to get it to work fully until I made some changes in the uc_store_variable_info() function (see further).
I haven't much experience with i18n yet, so maybe it was due to a misconfiguration or a missing module or something.

Steps token

1. I enabled the following modules:
   • Variable 7.x-2.1
   • Variable admin 7.x-2.1
   • Variable realm 7.x-2.1
   • Variable store 7.x-2.1
   • Internationalization 7.x-1.7
   • Variable translation 7.x-1.7
   • Required Ubercart modules 7.x-3.x-dev from July 22 (also tested with 7.x-3.x-dev from August 4)
   • Required Drupal core modules 7.14
2. I went to the variables page (admin/config/regional/i18n/variable) and noticed "Ubercart checkout settings" there, but not "Ubercart store settings".
3. I checked the differences between the two variable groups and noticed the "Ubercart checkout settings" has "type" specified for each variable.
4. I added 'type' => 'string', to each variable in uc_store_variable_info().
5. I flushed caches and now the new variables showed up. I enabled them.
6. Now the variables were multilingual on the address field settings page (admin/store/settings/countries/fields) and translating them worked.

Other issues

• (minor) Not all variable titles are in t(). "First name" and "Last name" are in t(), but this is not the case for the other variable titles.
  'title' of "uc_field_first_name" is in t():

          +  $variables['uc_field_first_name'] = array(
          +    'title' => t('First name'),
          +    'description' => t('Ubercart address field label.'),
          +    'group' => 'uc_store',
          +    'default' => t('First name'),
          +  );
        

  'title' of "uc_field_city" and several others are not in t():

          +  $variables['uc_field_city'] = array(
          +    'title' => 'City',
          +    'description' => t('Ubercart address field label.'),
          +    'group' => 'uc_store',
          +    'default' => t('Country'),
          +  );
        

Well, here is an updated patch that fixes the issues I had noted above. I'm not sure if I followed the right steps to test this, though.

Hm, I guess something went wrong with creating the patch. The patch in #70 is just the same as in #68. When using normal git diff > patch.patch new files won't get in. I was trying to figure out how to get a new file in a patch, but something went wrong in that process.

New try.

I now just combined the results of

git diff > patch1.patch

and

git add uc_store/uc_store.variable.inc
git diff --cached > patch2.patch

Thanks for the review and spotting the missing t() calls. In fact I realised that all t() in that hook should be t('String', array(), $options), so I committed #71 including that change. I also noticed that the defaults for Street address 1 and 2 are "Street address" and "" respectively, so fixed that as well.

I couldn't reproduce the problem you had in step 2 in #70, the variables showed up immediately after clearing cache, but setting type to 'string' is better anyway.

To make a single patch file including changes and new files, you can use

git add uc_store/uc_store.variable.inc
git diff HEAD > patch.patch

@longwave
Thanks for the note about how to easy create a patch with new files.

I'm aware that the drawback of no longer using variables is that site owners can't change the name of the fields anymore, but in my view that is a small price to pay for having translatable strings.

You can use the localization system of Drupal itself to change field names. For the foreign (non-English) language you can simply change the translation. For the original English you can create new alternative language en_mine that holds your preferred strings. I have done this successfully in one site with drupal 6.x and the same should be possible with 7.x

I have 7.x-3.x-dev installed and still cannot translate the address field labels. Fixed means that patches have been submitted to the dev version, isn't it? Please confirm that they were.

Yes, "fixed" generally means any patches from the issue are included in the -dev version.

You need to install i18n_variable module and go to /admin/config/system/variable/realm/language/configure and check the variables you want to translate (address fields are in the "Ubercart store settings" section). After doing this, at /admin/store/settings/countries/fields you should see "This is a multilingual variable" under the selected fields, along with a language selector at the bottom of the page.

This issue is still not fixed, at least not in UC 3.0-rc4.

But the simplest solution by rhmtts #23 worked for me. Thanks a lot rhmtts!

For the record, in UC 3.0-rc4, I had to modify the code a bit for it to work.

In uc_store.module , the line to edit is line 1169 where
– return variable_get(‘uc_field_’ . $field, $fields[$field])
+ return t(variable_get(‘uc_field_’. $field, [$field]));

I then translated the field name strings in configuration\translate\translate interface. Effectively the strings become translatable when they weren’t before. But you still won't get a readymade translate tab to translate like other contents.

@johnching: You should absolutely NOT be using 7.x-3.0-rc4. That was released on January 23, 2012, six months BEFORE the fixes in this issue were implemented. It is a huge mistake to use such an old and unsupported version.

@TR. Thanks for the warning. I checked my Ubercart again.

It says Ubercart 3.0-rc4, 2012-1-23 in the Changelog.txt BUT it's the latest version 7.x-3.8, 2014-Oct-22 downloaded from from https://www.drupal.org/project/ubercart by me two months ago.

1) Am I using an old version? Or is the info in Changelog.txt just not updated.

2) If I am using the latest Ubercart version then then I am afraid, the issue in this thread still exists.

Thanks for your advise.