payment_details in checkout are not translated into not default languages

Can you please reroll the patch in unified format? The syntax is diff -up if that's the program you used.

So this is a compatibility issue with the i18n module? I'm not sure why you're manually adding in the ?q to the path in the JS. I thought we had a workaround for that?

I don't think Drupal.settings.basePath includes ?q=, regardless of the clean URLs setting.

Hello there,

I have ran today in similar issue and came with similar solution, but with little bit different approach.

What about let the Drupal core to completely take care about the urls?

 function uc_checkout_pane_payment($op, &$arg1, $arg2) {
    switch ($op) {
    case 'view':
     // Add URL paths as JS variables (be nice to i18n, allow URL rewrite)
      drupal_add_js(array('ucURL' => array(
        'adminPaymentDetails' => url('admin/store/orders/'),
        'paymentDetails' => url('cart/checkout/payment_details/'),
        'lineItems' => url('cart/checkout/line_items'),
        'creditCardCVVInfo' => url('cart/checkout/credit/cvv_info'),
      )), 'setting');
...

Then in uc_payment.js file we can just simply use:

$.post(Drupal.settings.ucURL.lineItems, li_info, ...
...
get_payment_details(Drupal.settings.ucURL.paymentDetails + payment_method);
...
get_payment_details(Drupal.settings.ucURL.adminPaymentDetails + $('#edit-order-id').val() + '/payment_details/' + $('#edit-payment-method').val());
...
etc

I'm now on RC3, if you wish I can make some patch against Dev.

patch from #3 works as expected

@wojtha
A patch would be greatly appreciated since it would be easier to test ...

I am changing the files manually and then UC thinks javascript is disabled and gives this message

Javascript must be enabled to view the order total preview.

Here's a patch that implements wojtha's idea for the payment pane.

Something kind of weird happens, though, and I'm not sure why when I use Secure pages. If I go to the checkout page in another language, everything seems to work fine (shipping quotes show up, taxes are added, the line items are regenerated) until I try to switch payment methods. The loading image appears, but nothing ever replaces. Firebug tells me that a 302 Found response was returned without any data. What's really odd is that if I try to switch payment methods again, it works. HTTP 200 OK, and the correct form elements appear (in the correct language, too). Every other time the payment method is changed, it works, and then it doesn't. It doesn't matter if I click on the same payment method or a different one, Firebug's console has zebra stripes for successful and failed requests.

Now that I remember right, someone's reported a similar problem. I don't think anyone had any good ideas about how to fix it.

I believe they are separate problems, though, so this patch ought to work fine on its own.

Mantooth, you sly animal. We should've thought of this approach sooner. : P

No, no. All credit goes to wojtha. I just made it happen.

Ahh, I see. Duly noted. Way to go, wojtha!

#8 resolves the problem
+1 for commiting this

Just had a thought. The same thing should probably be done for shipping quotes, and maybe taxes. Those can conceivably return translatable data, so the correct language should be taken into account.

@rszrama, @Island Usurper

Sorry guys, I have had no time /until now/ to make a patch. Nice to see my one of thoughs is going (probably) to be part of UC :-D

I can confirm that this code is working on one of my live sites. But it is only small shop - I don't use Https - so I can't test the Secure Pages issue mentioned in #8.

Status changed by accident... Most probably I opened this issue before Island Usurper sent his comment #14 and changed the status.

Well, at least now the URLs are consistent. It turns out that the quote system needs more work to be truly translatable. However, now we can actually test any work done towards that.

Committed. This issue is about as fixed as it will get. The Secure Pages problem will need to be looked into further, but I think it's outside of this issue's scope.

I should know better than to make statements like that. Someone apparently put the wrong key for the shipping quotes URL, and we shouldn't leave out the products order pane, either.

Fixed it for me. Drop the hammer!

Fire in the hole!

Er, I mean "committed".