Internationalization needed for Legal module

Good point, I'll look at implementing this on the Drupal 6 version.

Subscribe. I'll be interested to see how this comes along. Considering the extreme length of the typical Terms of Service, Legal should implement it's own language control, adding a "language" column to its table (as opposed to trying to use the over-taxed t() function).

Agreed.

I'll actually be needing internationalisation on Legal myself soon:

http://www.atta-project.net

Alternatively, it looks like Terms of Use module stores the legal agreement as a node (giving you revisions and translations by association). Personally, we just decided to stick with Legal module but include all the translations in a single, huge text.

Yeah, I saw that.

I'm still weighing up the pros and cons of moving T&C content to a node. If I do switch to that approach it will be after updating to Drupal 6.

I concur with this feature request. Accepting a T&C in a non native language may result in a void agreement.
Am not an expert with Drupal, but I think that storing the T&C in a node would allow a cleaner solution, eventually with the support of i18n, which allows switching from one language to another at node level.
Also the translation of the checkbox labels should be allowed,which doesn't come out from the node translation. Perhaps this can be supported via the string translations?

I also would like to see it dealing with Multi-lingual sites, as i am wishing to have a working module dealing right with Multi-lingual sites.

We asked Chill35 (ToU) about this on http://drupal.org/node/299416 maybe you find an idea for it to get it working.

I posted a couple of ideas, specially on how drupal deal with this under:
-admin/build/menu-customize/primary-links/add
-admin/settings/language/configure

Chk' em on same node i said before, under #2 & #4 respectively.

Thanq.

Here is a patch.

Reasoning: it's best to do this through the Locale system, since that's where most site admins will be used to doing translation. Working directly with the locale system is complex. The i18nstrings module provides handy methods. Better not to introduce a dependency on it, though, as legal will sometimes be used on single language sites.

Therefore, introduce multilingual support such that data will be translated if the i18nstrings module is enabled but will be unaffected if not.

The patch has the following approach:

1. Support the i18nstrings 'refresh' option. This is useful for reading all existing data into the translation system. E.g., an existing site has existing terms and conditions, needs to read them in.

2. When new terms and conditions are created, register them for translation.

3. Whenever terms and conditions are being displayed, fetch available translations.

4. Key translations by version ID (tc_id) so that all versions can be translated.

The following fields are set for translation:

* conditions
* extras
* changes

Because the extras field is serialized before being stored, it is handled in its unserialized form.

Result: legal's translatable strings are handled through the translation system at admin/build/translate just like other groups.

@nedjo on #8,

Thanq, thanq, thanq, thanq, Thank You!!! :-))

This is a GURU man, guys!

I have tried your patch and i confirm gladly that finally we can have a working terms & conditions dealing in the right way with different languages.
My site is working with 4 languages (Arabic, English, German & Spanish) at last i could sleep with happy dreams knowing that all users will read T&C on their native languages ;-))

Thx again —a lot— nedjo,

;-)

P.S. i have changed status to fixed. Feel free to change it as you like, and ah don't forget to assign it to you nedjo, as you fixed it. Contact also Robert Castelo personally to speak with him about your patch. Cheers!

@nedjo,

Sorry to say to you that i enjoyed happiness only for small period of time —almost 2 hours— :-(

Everything worked perfectly as i before mentioned, but thought "What if i change the T&C text?", logical no? of course this way the user again must accept it!!
I indeed changed the txt under "…/admin/settings/legal", explained changes and clkd save, great till now.

Now the user i created (user/2), i logged him in, waiting for the T&C page to view and accept it, but… Voilà!!… a nice & sweet blank page with this URL:
"…/legal_accept/2/280716e28cc163fed112125b7efddb86"

What happened?

I made a clean install with the original legal.module on a new dev site and same procedure worked nicely, so thought you should know it.
Does it have to do with your patch? I think yes.
Can you find a solution?
Could you explain it, pls?

Thank you ;-))

Thanks for the testing. I'll look at this issue and report back.

Please see this handbook page for information on the meaning of project issue status options: http://drupal.org/node/156119.

New patch with a fix for the reported issue (I needed to change db_fetch_object() to db_fetch_array() in one place).

@errement: if you could do further testing and report back here that would be greatly appreciated.

Need to make it obvious to site admins how to make T&C translatable.

New patch including help messaging at admin/settings/legal. If the i18nstrings module is not present, give a message that translation can be enabled by installing it, with download link. If it is available, give a message with a link to the translation interface.

@nedjo,

So the function legal_display_changes finally will be:

// get all changes since user last accepted
function legal_display_changes($form, $uid) {
    
    $last_accepted = legal_get_accept($uid);
    if (empty($last_accepted)) return $form;
    
    $results = db_query("SELECT * FROM {legal_conditions} WHERE tc_id > %d ORDER BY tc_id DESC", $last_accepted->tc_id);
    
    if (empty($results)) return $form;
    
    $form['changes'] = array(
        '#type' => 'fieldset',
        '#title' => t('Changes List'),
        '#description' => t('Changes to the Terms & Conditions since last accepted:'),
        '#collapsible' => TRUE,
        '#collapsed' => TRUE,
        '#tree' => TRUE,
    );
    
    while ($conditions = db_fetch_array($results)) {
      // We're displaying to the end user, so localize.
      $conditions['changes'] = legal_localize("legal:version-{$conditions['tc_id']}:changes", $conditions['changes']);
       
       unset($changes);
        
        if (!empty($conditions['changes'])) {
        
            $changes = explode("\r\n", $conditions['changes']);
            
            foreach($changes as $change) {
                $form['changes'][] = array(
                    '#value' => filter_xss_admin($change),
                    '#weight' => 2,
                );
                $is_list = TRUE;
            }
        }
        
    }
    
    if (!$is_list) $form['changes'] = NULL;

    return $form;
}

I'll try it now!!

@nedjo,

Thx a lot for the new patch #12 i confirm that it works ;-))
Now i could finally say "Yes, AT LAST this is working as i expect it to, my site users will appreciate it"

Will try the new #14 patch to see how it works and tell you later on.

Also thx for http://drupal.org/node/156119 —i am new to all this system, but learning very fast—

@nedjo,

I tested your last patch #14

It's hard for me to go around ALL the patch again & again, giving that i already have replaced lot of lines before, wouldn't it be easier to just say what's new respecting to the older patches, instead of attaching all??

Ok, i discovered that the difference was just adding these lines:

      if (!module_exists('i18nstrings')) {
        $output .= ' '. t('To make terms and conditions translatable, install and enable the !i18n package\'s Strings module.', array('!i18n' => l('Internationalization', 'http://drupal.org/project/i18n', array('absolute' => TRUE))));
      }
      elseif (user_access('translate interface')) {
        $output .= ' '. t('Legal terms and conditions may be translated using the !translate page.', array('!translate' => l(t('Translate interface'), 'admin/build/translate')));
      }
     break;

It works with i18n installed, but why not consider giving this instead: 'admin/build/translate/search' in any way, admins will still have to seach T&C strings, no? No sense for Overview i think.

      elseif (user_access('translate interface')) {
        $output .= ' '. t('Legal terms and conditions may be translated using the !translate page.', array('!translate' => l(t('Translate interface'), 'admin/build/translate/search')));
      }

Now without i18n installed, i think you should —sorry ;-)— also consider rephrasing this "To make terms and conditions translatable, install and enable the Internationalization package's Strings module.", who already knows how i18n works wouldn't have to know this, but brand new admins might need to have more explanations.
I mean for example: "To make Terms and Conditions translatable, install and enable Internationalization module, then enable Strings." or something similar.

A great job, any way for me personally i won't have to get this when i visit "…/admin/settings/legal" the system is easy enough to understand its workings.

You decide, contact owner.
;-))

Thanks for your help, really appreciate it a lot.

dear nedjo,

first of all, many thanks for delivering a patch on this issue.

I have tried to apply the patch at comment #14, but the patch command failed with

patch -b legal.module legal-module-patch1.diff
patching file legal.module
Hunk #9 FAILED at 750.
1 out of 10 hunks FAILED -- saving rejects to file legal.module.rej

and the rejected part is the following

############################################
cat legal.module.rej
*************** function legal_save_accept($uid, $tc_id)
*** 669,678 ****
return;
}

- function legal_get_conditions() {

$conditions = db_fetch_array(db_query("SELECT * FROM {legal_conditions} ORDER BY tc_id DESC LIMIT 1"));
$conditions['extras'] = empty($conditions['extras']) ? array() : unserialize($conditions['extras']);
return $conditions;
}

--- 750,763 ----
return;
}

+ function legal_get_conditions($localize = FALSE) {

$conditions = db_fetch_array(db_query("SELECT * FROM {legal_conditions} ORDER BY tc_id DESC LIMIT 1"));
$conditions['extras'] = empty($conditions['extras']) ? array() : unserialize($conditions['extras']);
+ // If we're localizing, pass conditions and extra labels through localization.
+ if ($localize) {
+ $conditions = legal_localize_conditions($conditions);
+ }
return $conditions;
}
###############################

Question: to which version of the legal.module file the patch shold be applied?
Mine was the one coming from the latest legal beta4 distro.

Many thanks.

The patch is against HEAD. Changing the Version to reflect that.

@errement: thanks for the suggested help tweaks, I'll include them in the next version of the patch.

@nedjo,

Thanks to you for your precious time creating for us this patch. I really appreciate it !!

;-))

Here is a cheap fix for 5.x if anyone needs it. You can use the localization modulate to translate TC as a string.

Here's a revised patch with two fixes:

1. Help changes as per errement's suggestions.
2. Fixed incorrect use of l() in string placeholders.

To test:

1. Enable locale and legal modules. Install French languages. Enable language switcher block.
2. Create a terms and conditions record. Expected result: message informing that a string has been added for translation.
3. View admin/build/translate/search. Limit search to 'Legal'. Submit. Expected result: one strings shows up.
4. Enter a French translation for the string.
5. Log out. Go to register as a new user (in English). Expected result: terms and conditions in English.
6. Use the language switcher to switch to French. Go to register. Expected result: terms and conditions are in French. Complete registration.
7. Log in as admin. Switch to English. Revise the terms and conditions. Expand the "checkboxes" fieldset and add two strings. Enter some text also for Expected result: messages for four new strings that have been created.
8. View admin/build/translate/search. Limit search to 'Legal'. Submit. Expected result: five strings show up--one for the original version, four for the revised version.
9. Enter French translations for all strings.
10. Log out, switch to French, log in as user registered in step 6. Expected result: Revised terms and conditions plus checkbox labels plus changes notes are in French.

I've added a simpletest for the internationalisation features to this patch. It's using the 7.x/6.x-2.x API for simpletest. Doesn't cover every case yet but ensures the basics work.

I've reviewed this and it works perfectly. I've tested it with multiple users, languages, revisions and checkboxes and it works great. All simple tests pass too.

Cheers,
Stella

This patch doesn't seem to work against the released 6.x version.

Edit: I checked out HEAD and the patch works. I don't know how this will affect the module behavior but so far everything seems to work nicely.

Talked about version issues with Robert. E.g, what about multiple translations of the same T&Cs, for instance if an error is found in the translation and is amended - can we track which version was accepted?

These version issues are not completely handled by the locale-system-based approach in the current patch. There would be a separate translation per original version, but not separate versions per language (i.e., you couldn't have versions 1, 2, and 3 for Italian and only 1 and 2 for French). Translation changes for a particular version would overwrite previous copies--i.e., if version 2's French translation was subsequently edited, there would be no record of the previous version 2 French translation.

So it's sounding like, to cover these nuances, a different approach including separate language field and maybe different version per language may indeed be needed.

Setting back to needs review.

On the plus side if you've used this patch your T&C records won't be adversely affected if you do stop using it.

One way this general issue is sometimes handled is to designate an authoritative, legally valid version (the original), and link to that in translations, noting that any translated version is provided for user convenience only and that the original is the authoritative version.

This is what we do for example with our statutes in the Drupal Association, see: http://association.drupal.org/about/statutes-and-internal-regulations

Doing this might in fact be the best approach for most cases, since it's difficult to ensure that legal nuances are properly covered in each translation (without getting review by lawyers proficient in that language). The current patch would work with this approach if it included a disclaimer with a link to the original-language version.

Robert, thoughts?

tried #14 and #25. they applied correctly, but still nothing - could not find how to translate anything even after #24 walktrough.

so i just took a clean HEAD code and placed this line in function legal_get_conditions() right before "return $conditions"

$conditions['conditions'] = t($conditions['conditions']); // !CODE_HACK! - ENABLE TRANSLATION

A quick and dirty hack, works for me.

I've added internationalisation features to Legal module 6.x-2.3-rc1

If no critical bugs are reported for this new version after a week I'll release it as the next full version.

Please help test, and if you do find bugs open new issues.

In the mean time I'll update the documentation to explain the new features, hopefully most of it is already self explanatory though.

Nedjo, thanks for helping me think through how this should work...

Each version of the T&Cs can now be translated into whatever languages the site is set up for, and the concept of revisions has been added.

Every translation can have as many revisions as necessary, with each version + language having it's own revision audit.

When a revision is made only users that have accepted the T&Cs in that language previously, and new users, are asked to accept the new T&Cs. This is intended for improvements to the translation rather than changes to the actual terms and conditions being offered.

Creating a new version will ask all users to accept the new T&Cs.

Hope this cover's everyone's user case, let me know if it doesn't, if you find bugs, or if you've tested and it works as expected.

If I get good feedback, and no bugs are reported, I'll make a full release next week.

hey everyone,
how to translate the extra fields description you can set?

any ideas?

i need to know that one, too... tried with string override, but no success :(

It's a bug, which needs to be fixed.

Will try and work on it as as soon as I can.

I just added a fix for internationalization of 'Explain Changes' field entries to the master version of Legal, will roll out a release soon.

This issue is now closed, and should stay closed.

If you find any internationalization bugs or want new internationalization features please open a new issue for the specific bug or feature.

Thanks!