UBB.Developers Forums UBB.threads 6 V6 Modifications Archived Mods [UBBT 6.0] Swap Language "on the fly" 1.0

Here's a small hack I just made. I only covered the languages in the language file so any languages not supported will have to be added in by the webmaster/admin. Most important, it seems to be working the way I wanted it to... LoL

After downloading the zip file upload the "flags" folder to your images directory and then follow the swaplanguage.txt instructions.

For an example have a look here:

http://www.chattersonline.com/test

Enjoy

Nice It shows us where the language files don't touch yet

Thanks

I noticed that too. Also, I need to rework how the language links figure out where they are located so that users are taken back to the correct spot when viewing a page that has more than ?Cat= in the URL. Of course I think that those users with problems revolving around their referer information will continue to have problems with Windows XP/Norton INS.

I'll be posting an update soon.

If anyone sees other problems please let me know.

I'm going to create an external script to set the cookie when changing languages. This way the user can be returned to the page they came from correctly. (provided the referer varaible is present)

2.0 soon.. lol

This is an update for swaplanguage 1.0 modification. This update fixes (or attempts to) flag links so that they capture the query string that was used to access the page.
This also will keep the links from adding additional parameters when more than one flag is clicked on.

I also changed the image tags to be xhtml compliant. I added an IE filter for a mouse over affect with the flags. The filter is applied to only IE 5.0 and higher.

Here's the example:

http://www.chattersonline.com/test


Edit Note: This still does not lend itself to being xhtml compliant. I'll try and make it so as soon as I can.

Dave, try on your site http: // www.chattersonline.com/test to make Logout, to switch language to any another and enter on a forum. The mistake is given out: All of the required fields are not filled in.

That is interesting, for example, at the time of that translation the Spanish version was translated so that it didnt have a [:"red"]&[/]ntilde; . When I was not able to log into threadsdev with the Spanish cookie set on my system, we we thought it was because of that (See Bug report). But that is not the case here, there is not [:"red"]&[/] in the form fields. So in that bug tracking we might have been wrong. Its easier to test it at chattersonline because of the language hack.

Hi Goshik,

Yeah that's the oddest thing. I logged out then changed languages to German, Romanian and Russian and tried to log in with each one but failed with "required fields" error.

The hack changes the language variable during the send_header function and prior to anything else being able to read the variable. I'm not sure why it fails when trying to log in. I'll have to look that over some I guess.

Also, the flag display is not xhtml compliant as of yet. There seems to be problems caused by having the Cat variable and the other query string information in the flag's language link. I may have to use an external script to swap the languages after all to avoid this.

At me in a structure on www.chattersonline.com/test language english is established. If I shall establish(fix) at an input(entrance) on a forum language of the interface russian, I shall receive a mistake. It is wrong. Excuse for my English. I use www.translate.ru

Ok I think I know why this one is not working...

The hack doesn't modify the w3t_language cookie value. It set's a second cookie called templang from which it reads during the send_header function and then replaces the $ubbt_language variable with that value. The w3t_language cookie remains the same.

The login page takes you through the start_page.php script to decide what it should do next. This script doesn't use the send_header function untill after it has decided what your request is (get password or login). The script does pull in your langauge file based on the w3t_language cookie value which is unchanged so it could at times not match the templang value.

I had thought about having the hack just modify the w3t_cookie value directly just because it would be one less cookie in the mix and now it seems that that is the only way to go unless one is to modify the start_page script and probably some others too.

I'll update the hack today and also see if I can get it xhtml compliant. (I really am trying to be compliant with this stuff now... lol)

No problem Goshik

I'm glad you found that bug. I hadn't thought of trying to login in a different language.

Dave, you do(make) for development of a forum much and I very much in it am grateful to you! At me only one request, do(make) all èçèåíåíèÿ a forum for many languages.:) Excuse, for my English.:) do not take offence at me, please.

Thaks Goshik

Oh and all of the text on the index page has been moved into language files. This should make it even better now.

Thank, Dave! I very much hope for you...

I changed the hack to modify the w3t_language cookie value and now I can log in with various languages. One problem though, the start_page function in the ubbt.inc.php script will change a user's language value to the value listed in their profile. Also, not sure yet, the language cookie may get reset during the start_page display. I'm still looking over things to see what all happens at login.

I ask to excuse me, but it takes place...

I'm not quite sure I understand. The langauge change works after login? If so that's good news. Mine wouldn't stick because it was already set to english in my profile.

Hi,
maybe a soulution for the start_page.php conflict with your great hack:


//find in your hack:

$ubbt_language = $tmplang;
require ("{$config['path']}/languages/$ubbt_language/generic.php");
}

//add thereafter:

if (stristr(find_environmental('HTTP_REFERER'),"start_page.php")) {
echo <<<REDIR
<html>
<head>
<meta http-equiv="Refresh" content="1;url={$config['phpurl']}/login.php?$langLinkEnd">
</head>
<body>
</body>
</html>
REDIR;
exit; }


I have no idea if this is proper code, but it seems to work

What still don't work is the hack at login.php (when not logged in yet) itself. There half of the code is in the right language (probably words from the generic language file) and some words are unchanged from the old login.php language file.. Strange...

This is the most important place where a user might want to change the language to get the log in procedure already in "his" language, so he understands the details. To bad that here the hack does not work yet. Any ideas?

I have changed the code to the following:


// IE Filter
$ieFilter = "";
$userAgent = find_environmental("HTTP_USER_AGENT");
if (strpos($userAgent,"MSIE 5") || strpos($userAgent,"MSIE 6")) {
$ieFilter = ' style="filter:alpha(opacity=65);-moz-opacity:0.65" onMouseout="this.style.MozOpacity=0.65;filters.alpha.opacity=65" onMouseover="filters.alpha.opacity=100;this.style.MozOpacity=1;"';
}


$langLinkEnd = find_environmental("QUERY_STRING");
$langLinkStart = find_environmental("PHP_SELF");
if (!$langLinkEnd) {
$langLinkStart .= "?";
$langLinkEnd = "&Cat=$Cat";
}
else {
if (eregi("swaplang",$langLinkEnd)) {
$langLinkEnd = eregi_replace("swaplang.*&","",$langLinkEnd);
}
$langLinkStart .= "?";
$langLinkEnd = "&$langLinkEnd";
}

if ($swaplang != "") {
if ($swaplang != "" && $swaplang != $tmplang) {
setcookie("w3t_language","$swaplang",time()+$config['cookieexp'],"{$config['cookiepath']}");
$w3t_language = $swaplang;
}
$ubbt_language = $w3t_language;
require ("{$config['path']}/languages/$ubbt_language/generic.php");
}



This will change the w3t_language cookie value directly so logins will work.

(editited: solutions found)


Hi Dave,
thanks for working on the code.

Some observations:
1. My code (see abbove) or something else like that is still necessary:
If you are on the "start_page.php after log in, a refresh or a language change produces this UBTT error: "you cannot continue, not all neccessary filds are filled out".

But that might be more a general UBBT bug, and I filed a bug report, so my code might be not necessary as soon as Rick has that fixed.

2. Your new code does not work at all on my board. (Everyghing stays "english". I try to find ot what went wrong....
aha, this line of code is the problem:
if ($swaplang != "" && $swaplang != $tmplang) {
should be:
if ($swaplang != "" ) {
(the 'tmplang' cookie is not updated any more and the variable should go now (also in other part of your code with the "globals" readout)! )

3. Did you see that you have to press a language button
twice(!) before changes are accepted on the login page?

On the login page there are 2 language files used, one works right away after 1 click, the other one (languages/login.php) is only refreshed ot the new language if I click the flag a 2nd time.

ok, I tried something: Add this (or better) code to your hack and the problem goes away:
if (stristr(find_environmental('HTTP_REFERER'),"login.php")) {
require ("{$config['path']}/languages/$ubbt_language/login.php");
}

Greetings

At me a similar situation.

Good eye

I forgot to yank that $templang varaible..

The code proabably was working for me as I still had the templang cookie cached.

Your right, the $templang can be removed from the global call too.

I'll clear my cookies and start messing with this to get a better idea of what to do. I still need to move it to an external script so I can get the language links to be xhtml compliant.

Ok I went through the code tonight.

I think I have this working correctly and I figured out what was wrong with the language links as far as not being xhtml compliant. I had to make sure that all & were & when displayed.

Now this modification should be xhtml compliant (it checked ok when validated)


Also, I added in some code so that when a new user is signing up and they have their language chosen it will also be added to their profile data right away. No need to go edit it after loging in. (this should help other matters also)

The file is attached. Let me know how it goes. I would recommend clearing all cookies and signing up as a new user on your board to test it out. Choose a language other than english if english is your default so you can see the difference.



(caymuc, try this out at my test site and tell me what happens when you sign up in german. Does it work right? http://www.chattersonline.com/test )

> (caymuc, try this out at my test site and tell me what happens when you sign up in german. Does it work right? http://www.chattersonline.com/test )

Ok
1. On the login page (at the stagewhere you have the enter Name&passwort it is still that you have to click the language button twice, before changes are completely visible (see my fix for it).
2. Start page problem is still there. See my fix, which is not perfect, because the same problem will also appear with adduser, changebasic, changeprofile and such other pages. This is mainly a problem of UBBT, and the same errors would shor if I only refresh those pages. Reported that as a bug.
3. Appart from those special "effects" it seems to work all right

Ok for some reason it finally sunk in what you where saying about having to click the language flag twice. I didn't know that not everything was being changed with the first click. That's an odd thing though.

The errors with adduser, changebasic, changeprofile and other pages that recieve form information via "post" will inform you that you need to send the data again when you refresh them. On a page such as addpost.php this will error if you had already posted saying that the post already exists.

It's strange that the errors still occured after signing in. The language should have been added automaticly at signup.

I'll keep kicking this around. I think I'll eventually have it smoothed out.

> That's an odd thing though.

No, not really, many pages just need two language files, a GENERIC and a page specific page. You just got the first one updated.

This is my fix with an optional 2nd "require" command. (Maybe you can make leander code of it, but this works fine, and one does not change languages so often that time counts ):

after:
[:"brown"] require ("{$config['path']}/languages/$ubbt_language/generic.php");
[/]

add:
[:"red"]
// find out name of page.php:
$url_string = find_environmental('HTTP_REFERER');
$url_base = ($config['phpurl']);
$pagename_start = strlen($url_base)+1;
$pagename_length = strpos($url_string,"?") - $pagename_start;
//find specific language file!
if (($url_string !="") && ($config['phpurl'] !="")) {
$php_pagename = substr($url_string,$pagename_start,$pagename_length);
if (file_exists("{$config['path']}/languages/$ubbt_language/$php_pagename")) {
[:"brown"] require ("{$config['path']}/languages/$ubbt_language/$php_pagename");[/]
}
}
[/]

I also came up with a fix for the second language file. You beat me to posting though.

Have a look at my fix. Kinda simular. LoL

Only one click is needed now at my test site to change langauges. So I think it's working. LoL



The reason I said it was odd was that the page specific language file should load in the related language as it's using the w3t_language cookie after it has been changed to the new language. But, then again, I'm sure I'm overlooking something... LoL

I have attached the latest update, swaplanguage.3.0.zip for those that are interested.

Hi,

I had about the same problems. (your version 3.0 on ubbt 6 final and a win2k server running IIS5)
When hitting another language flag the language would not complete be switched. I would have to logout/login to make it work.
When changing languages as an anonymous user, the new selected language would also not be completely used. I still see parts of the language files from the other language
Also logging in became impossible when the selected language was different from the profile setting.

I hope you guys can fix this, cause the hack is a must have!

Regards,

Ron.

Hi Dave,

I found a conflict between this hack and your other hack:
'Mark One or All Read (markallread.6.1.php) '

Id you switch the language and click markallread right thereafter, markallread has a problem with the referrer (the url still has that extra "language=english") and then IE5/MAc gives a blank page instead of a refresh.

I think the problem could be in this hack and not in Markallread.

greetings
carl

Hi caymuc,

That's an odd error. I'll see what's up with that. Also, the Mark One or All hack isn't quite right yet. I have to go over it again this weekend.

Thanks for letting me know about the bug. I'll see if I can recreate it at my test site.

caymuc, what page are you on when you hit the the language selection and then "mark all read"... I just did it with my test site's forum listing and it was fine.

One thing to keep in mind about both of these hacks is that they can't capture posted data so when the hack is used it can only return information from the query string. Perhaps it's possible to check to see if the page was posted to and if so put all variables into the query string? And there are some pages that would be blank on return, such as the addpost.php page bacause it's expecting a post and exits when it sees information is being sent via get. Would that possibly be the problem?

ubbthreads.php.

you can log in at my board with test / test2
http://www.colour-ize.de/php/forum/ubbthreads.php
and then go to the main page:
click the language flag, then Reset in the menu.
After the reset the page remains empty.
(not in NS4 but in IE 5/Mac at least.)

The problem is this url:
?swaplang=english[/b]&Cat=]http...ads.php?swaplang=english&Cat=
that seems to confuse MarkAllRead when doing the refresh after the flags-changes.

I'm getting an incorrect password for that username? test / test

works now, I was cecking it a minute ago

I changed the password now to test2
to make it not too obvious for playful users.

with test2 it should work.

No problem. I signed up already.

And.. hate to say it... it works for me.

I went to the forum listing.. (ubbthreads.php) and changed my language to english (http://www.colour-ize.de/php/forum/ubbthreads.php?swaplang=english&Cat=) and "Marked All Read" and it worked and returned to the correct page with everything displayed.

Aha, then this problem seems to be MAC IE related.

As soon as I get my wind*ws thing repaired, I check that too on a PC.

Thanks for checking.

No problem.

Let me know how it goes with your windows box when you get it back.

This hack seems to work fine on my windows machine.

But on my Mac IE... I have to click the flag twice to get everything to change.

The only hacks I've got installed are: Spell Check, Inline Pics and PMEmailer

This may be because I'm calling the javascript function from the <a> tag. I need to change this to call a dumby function and use the onClick attribute to fire the real function. I think that will fix it. I will try to get this changed as soon as possible.

No hurry. I'm still testing my 6.0 and probably won't go "live" with it until next month (going on vacation the 4th).

It's an awesome hack Dave! It's one that we saw somewhere on the Perl forums... but never found here.

Just a variation / tip to others (thanks to the templates) that others may wish to consider. The beauty of the templates is that you can have it appear in the ubbt_unregisterednav.tmpl and NOT the ubbt_registerednav.tmpl.

I figure, if an anonomous user is browsing the site, they can click the flags to change their language... then if they register a new user...it writes that language into their preferences.. thus once they log in they are in that language. I figure that a registered user doesn't switch between languages on the fly... but anonomous users might want to when they find the site.

Thanks again Dave!