translations support

As I understand... a translation of a node is stored in a different node (with different nid, etc.)

And links appear at the bottom of the node to access the translations...

So it is a matter for me to show these links to one or another translation...

I will look into this. I think I can help with that.

Thanks!

@Chill35,

Thx for the module.

What "univac" wanted to say is —as far as i understand as i am getting same problem with my Multi-lingual site—:
-Create a new "Page" content type for the ToU to use it
-We GoTo "admin/settings/terms_of_use" set information you know, which is very simple for just one language ;-)

But what if we have —like me— three languages (Arabic, English & Spanish)?!:
-Create a new "Page" content type in Arabic, let's say: node/1, then set its language to Arabic, and add a "Menu link title" for it.
-Create a new "Page" content type in English, let's say: node/2, then set its language to English, and add a "Menu link title" for it.
-Create a new "Page" content type in Spanish, let's say: node/3, then set its language to Spanish, and add a "Menu link title" for it.
-Now we go again to "admin/settings/terms_of_use" and we figure out that we are forced to enter just one path for the ToU "title post/node id"

This should be fixed to allow us to choose which path for which language we should be selecting to.

Ok, as far as i know —as i'm not a drupal master, just newbie— you should check how Drupal ppl made "Add item" for a Primary links under "admin/build/menu-customize/primary-links/add" cos there, you'll find the solution for it (created a "Language:" menu to choose from). This way, we all be very happy having ToU dealing with Multi-lingual sites as it should be ;-)

Thank you and hope you find a solution with what i said.

Now we go again to "admin/settings/terms_of_use" and we figure out that we are forced to enter just one path for the ToU "title post/node id"

Yep. I will leave it like that. I think it's my responsibility to figure things out.

I have to determine :

- What language is the one picked by the user currently browsing the site... I would use this variable here: http://api.drupal.org/api/global/language/6

- Look for the right translation when I do my node_load... Maybe doing an additional database query here, or not, to find out what node I must load.

So in the end it would not matter if you entered the nid (on settings page for this module) for a given translation and not for another. I would display the right node, based on the context.

Will look into this. Multilingual sites are important.

@Chill35,

Yep. I will leave it like that. I think it's my responsibility to figure things out.

And who said you have to change this?! :-O It's working perfectly. I respect your decision because it's you who know about how it works. I only meant that we should be able to have a chance to a right ToU txt for each language.

That's all, ;-)

As for the other things you said, you are the boss! , as i before mentioned:

…—as i'm not a drupal master, just newbie—…

Another thing i thought —as advanced user— (might be helpful or not) is that under "…/admin/settings/language/configure" there is an option for Language negotiation saying:
-Path prefix with language fallback. The presentation language is determined by examining the path for a language code or other custom string that matches the path prefix (if any) specified for each language. If a suitable prefix is not identified, the display language is determined by the user's language preferences from the My Account page, or by the browser's language settings. If a presentation language cannot be determined, the default language is used.

Maybe it's same as global $language;, you mentioned above, sorry for repetition if so.

I only help if i can, i like using easy interfaces when possible.

Agree totally that Multilingual sites are getting more & more a must for all of us!

Thanq again for your kind support.

And who said you have to change this?! :-O It's working perfectly. I respect your decision because it's you who know about how it works. I only meant that we should be able to have a chance to a right ToU txt for each language.

That's all, ;-)

Oh sure. I was just summarizing. I was not saying however, or but. I was saying just like you actually.

@Chill35 & all ppl,

Hello!

Am glad to announce to you that a solution is been given to add Legal module the ability to work and manage all languages the right way.

You can find it here http://drupal.org/node/79754#comment-1003388

Thanks to nedjo, this has become real.
Cheers!

That is great!

Thanks, errement.

*completly wrong therfore deleted by author*

what do you mean with that dddave? Please explain more!!

Here is a patch for the issue.

First of all the correct translation node will be used by the translation_node_get_translations() function. That was the easy part and should work well.

The other part that nearly drove me nuts was implementing i18n_strings like the legal module did it. Now all but the "You have to agree to the terms" text should be translatable.

Before if you once submitted the TOU form the string will be set into an internal variable and get monolingual by this. You could always use hook_form_alter but I thought it would be nice to really make an internationalization solution. So I used the i18n module.

Now if you submit the form you will set the string of the default language. Than you can look this string up in the "/admin/build/translate/search" interface and can translate it. Be aware that this means if your default language is other than English you have to translate the string again to English!

Please review this patch! Its late now, took me hours to understand i18n_strings for just two strings, I am not sure if there are any errors left and if I did it the best way.

[edit]
The i18n_strings module is optional! Everything is closed into if()
I reviewed the module with the coder model. Looks nice except some minor warnings. Good work!
Some spaces are left after line end.
If you don't want to add i18n support please use the node translation thing. It should work fine.

Best regards,

Kars-T

Hi,
thank you for looking at the patch! :)

the node itself can be translated with Drupal Core. That was the easy part.

What you desire is done by Drupal itself. You give a node a language and translation. This is mapped through core tables. So you really don't need this reproduced inside of the TOU module! You let point TOU at one node and the rest is done the normal drupal way. The other translations are tied together with the node. Maybe we should alter TOU to present links to all translation nodes so its easier and / or provide links to start the translation from here. But we just shouldn't add more node reference fields.

The tricky part is using the tt() function from i18n_strings. Did you find how to translate the strings from the TOU module?

Does the patch in #11 require the i18n module to be enabled? I'm guessing it does.

I offer my sites interface in two languages using the Locale module, however the content itself is always in one language.

No the patch has an optional dependency. The node is translated through core and the texts are translated through the tt() function if i18n_strings is activated.

@ Chill35

Is there a new release planned? That would be superduper because I fear patching. ;)

I've tested this patch and can confirm that this is ready to be committed.

I am finally giving Terms of Use some love this afternoon.

Thank you for your patience...

I've decided for now not to add code to be understood only by the i18n module. I understand that there is no dependency on the i18n module in the patch. However, I want to keep this module's code bloat under check, and the localization and content translation modules that come with core do a fine job already with interface and content translation respectively in Drupal 6.

I am running all title attributes through the t function now -- in current patch to be committed. This was an overlook. These fixes will help with interface translation.

In step 2 of my multilanguage support effort, I plan on adding the option of displaying links to all other translations of the Terms in the registration form. For now (in this modest effort), I will show the Terms in $language->language as per the patch, without links to other translations.

Thanks, and stay tuned. I should create a new release today.

Hi Chill35 and thanks for the patch!

the localization and content translation modules that come with core do a fine job already with interface and content translation respectively in Drupal 6.

Sadly they don't. You use:

variable_get('terms_of_use_fieldset_name', t('Terms of Use'))

which is way to go to do such things. But this is a common Drupal problem as well. If 'terms_of_use_fieldset_name' is set the variable will never use t() again and will be monolingual. I have to submit the TOU node for your module and by this I loose any multilingual abilities. :(

If you don't want to use tt() which is the only way for D6 to translate user given strings I would advise to remove the strings from the form so other ways of translation or string replacement like http://drupal.org/project/stringoverrides can be used. Or at least put the strings to a separate form.

Kars-T, I had no idea that user-submitted strings used for system variables are set once and re-used without translation.

I will correct this in the next release, soon.

I am sorry.

Caroline

setting it to "needs review because Chills says he will look in #22

however, I am happy with univac's solution. Perhaps we need to add this to the documentation?

Here is the re-rolled patched against 1.10.
It was conflicting when applying to 1.10 but I resolved the conflicts by integrating Kars-T's code into the new one.

I kept the check_plain() in order to keep the same level of security.

I got no idea how to apply patches, so it would be really great if there will be an update of the module..
I use 1.10 and i18n and I got the same problem..

You can try solution from #25 in the meantime which works as described

The patch works for us.

applying patch #27 seems to be save after days in production. please apply to CVS.

subscribing

Just remove the t() from form elements :

'#default_value' => variable_get('terms_of_use_fieldset_name', 'Terms of Use'), // Removed t() of 'Terms of Use'

// And

'#default_value' => variable_get('terms_of_use_checkbox_label', 'I agree with these terms.'), // Removed t() of 'I agree with these terms.'

And after :

// Change
'#title' => check_plain(variable_get('terms_of_use_fieldset_name', t('Terms of Use'))),

// By
'#title' => t(variable_get('terms_of_use_fieldset_name', 'Terms of Use')),

// And change
$checkbox_label = check_plain(variable_get('terms_of_use_checkbox_label', t('I agree with these terms.')));

// By
$checkbox_label = t(variable_get('terms_of_use_checkbox_label', 'I agree with these terms.'));

So we can set the text in settings form (in original language) and after translate it with translate interface, the only bad thing is that t() will use a variable value but it's not a big problem because these strings must not change when they are set.

@sinasquax

This is a real bad idea. Please read: http://groups.drupal.org/node/15177

Using i18n and tt() is the only real solution to this issue.

Just to let people know - I included multilingual feature in a combined patch #759064: Combined patch to address multiple issues and feature requests

iva2k i appreciate your updates.
However please remain on issues already available and provide clear reduced patches to strictly limited issues. Combined patches are not the drupal way how issue tracker work.
Only if you refactor a module you might solve multiple issues with one final commit.

Please spread your "found few new issues" to the original issues.

@miro_dietiker - thanks for the feedback. Please read my posting in its entirety to find out why reduced patches do not work anymore. Especially read comment #3 for inter-patch incompatibilities - these may be not transparent from individual issues. And in fact, my post #759064 turns into a significant refactoring with patch in #3.

Here I only shared the link to the place where people could also find a solution to the issue of "translations support". If you object, I can scrape it out.

I am setting this to "needs work" as this should be done with a wrapper function.

#299416 by Kars-T, roychri | Chill35, univac, errement, miro_dietiker: Added translations support.

Fixed at Drupal Dev Days München!

Just to mention:

It seems that i18nstrings API is changing. So this might break in future version. If you do not use i18nstrings I believe there will be no problem because terms of use module checks if i18nstrings is active or does nothing.