Multilingual support

If you wish, you can also make use of the existing hook_commerce_ogone_data_alter()-hook, like so:

function myshop_commerce_ogone_data_alter(&$data, $order, $settings) {
  global $language;

  // For multilingual sites, attempt to use the site's active language rather
  // than the language configured through the payment method settings form.
  $language_mapping = array(
    'nl' => 'nl_BE',
    'fr' => 'fr_FR',
    'en' => 'en_US',
  );
  $data['LANGUAGE'] = isset($language_mapping[$language->language]) ? $language_mapping[$language->language] : $settings['language'];
}

I wonder if we should not just ditch the current language setting and automatically map the Drupal site language with Ogone's languages (only problem would be nl, which I guess should be mapped to 'nl-NL'). I assume that's the behavior the majority of users would expect, no? (And the other < 5% of users can resort to the _alter hook).

Or do you have a use-case where you would want to deviate from such a default language mapping and allow the store administrator to specify which language Ogone should use for each Drupal language?

Another option would be to give the admin a couple of options:

1. Set one specific language to always use
2. Automatically map languages
3. Manually provide language mappings

(Where the latter option seems to be the one you need?).

We've made a patch which will add a dropdown box per enabled language. Now you are able to assign language codes to any language that is enabled on your Drupal installation or to a default.

Thanks, I'll try and take a moment to review later today. Some quick comments:

• I'm getting two notices after applying the patch when visiting the Ogone settings page:
  

  Notice: Undefined index: language_list in commerce_ogone_settings_form() (line 78 of /home/ivangeer/workspace/commerce_ogone_drupal/commerce_ogone.module).
  Notice: Undefined index: default_language in commerce_ogone_settings_form() (line 126 of /home/ivangeer/workspace/commerce_ogone_drupal/commerce_ogone.module).
  

• Could you re-roll the patch against HEAD (7.x-1.x), as there seems to be at least one change that is reverted by your patch( http://drupalcode.org/project/commerce_ogone.git/commitdiff/2178d12f3ca1...).

The notices should be fixed in this updated version of the patch. Thanks for your comment.

Kristof found a small bug in my previous patch, which is fixed in this one.

Thanks.

Thanks for working on a patch for this!

I'm still not convinced that we should actually provide drop-downs for every enabled language, especially since most of the mappings will be no-brainers like 'Italian => Italian', 'German => 'German', 'Turkish => Turkish', etc, something we can do automatically without the need to provide a wall of drop-downs to end-users. However, I'm leaving it to svendecabooter to decide how to proceed.

If we do offer the drop-downs, I think we should:
a) Introduce vertical tabs and move language settings to a "Language" tab, and account settings to an "Account" tab.
b) Let the end-user choose between "Use language abc" (so basically no mapping) or "Manually map languages" (which is what this patch provides -- more of an expert option).

Now, on to a review of the patch itself:

+++ b/commerce_ogone.moduleundefined
@@ -36,6 +36,34 @@ function commerce_ogone_commerce_payment_method_info() {
+  global $language;

The global $language variable is not used further down in the code, and is actually overwritten in a foreach causing the language on the payment settings form to be changed.

+++ b/commerce_ogone.moduleundefined
@@ -36,6 +36,34 @@ function commerce_ogone_commerce_payment_method_info() {
+  $languages = array();

The first assignment is obsolete and should be removed.

+++ b/commerce_ogone.moduleundefined
@@ -36,6 +36,34 @@ function commerce_ogone_commerce_payment_method_info() {
+    'zh_CN' => 'zh_CN',
+    'da_DK' => 'da_DK',

I think we should use the user-friendly language names rather that ISO-codes in the drop-down (so for example: 'it_IT' => t('Italian'))

+++ b/commerce_ogone.moduleundefined
@@ -69,11 +98,29 @@ function commerce_ogone_settings_form($settings = NULL) {
+  $form['language_list']['languages'] = array();

No need to assign an empty array.

+++ b/commerce_ogone.moduleundefined
@@ -69,11 +98,29 @@ function commerce_ogone_settings_form($settings = NULL) {
+  foreach ((array)$languages as $language) {

Since language_list() always returns an array, I don't think we need to explicitly cast it here.

+++ b/commerce_ogone.moduleundefined
@@ -453,3 +500,17 @@ function commerce_ogone_feedback_status($status) {
+ * Search for languages in settings

Ideally this should follow the Drupal coding standards for function comments
- One-line summary should be third-person and end with a period.
- Should include a @param and @return block.

It would also be great if we can somehow provide sensible defaults per language (since right now all language drop-downs are set to ar_AR).

Thanks for reviewing the patch!

I've cleaned up the patch, replaced the ISO codes of the drop-down fields with human readable names and added better support for defaults per language.

About the drop-down boxes, I see your point that some of them are unnecessary. Although, I personally think it's best to leave them in. You never know if someone needs to change those mappings :). But I'm going to leave that up to you and Sven.

Thanks for reviewing the patch!

I forgot to sort the language codes alphabetically. So this patch includes a sorted code list :).
I've cleaned up the patch, replaced the ISO codes of the drop-down fields with human readable names and added better support for defaults per language.

About the drop-down boxes, I see your point that some of them are unnecessary. Although, I personally think it's best to leave them in. You never know if someone needs to change those mappings :). But I'm going to leave that up to you and Sven.

Committed patch in #11 by renzor.
Added extra logic to generate the default prefix code: now there is verification if the default generated code based on the path prefix (e.g. 'fr' > 'fr_FR' actually exists as an Ogone language code. If not, it falls back to the default language / English (whatever is set).

This avoids a problem for language code 'en' where the code would attempt to set it to en_EN, which doesn't exist. The consequence of that is that English was set to Arabic by default instead...

Vertical tabs would be a good idea, but couldn't get them to work immediately...