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

Hi,
you are right that changing languages on the fly is not needed any more as soon as the language setting are set in the personal prefs.

What about this idea:
As soon as a user sets his preferred language, the change-on-the-fly flags are not shown any more - Saves space.

I think Josh solved that by only putting the language flags in the unregisterednav.tmpl so those that are not registered yet can chose their language while browsing. If they join then their language is already set and they need not use them so the registerednav.tmpl does not contain the flags. I think that this is probably the best route.

To have the flags not display after an unregistered user has chosen their language would require placing the flag link code into the ubbt.inc.php file as a variable and then have the templates print the information from the variable. Once the cookie is set the variable would be a blank string. The only drawbacks are that the html is being moved from the template back to the scripts and also if someone clicks on the wrong language they wont be able to click on the correct one.




Just some thoughts

Thats exactly what I did. The flags only appear in the unregisterednav.tmpl.
Once they reigister the "who's online" box appears exactly where the flags were.

I just went live at about 3am this morning with 6.0.1. I'd been playing with 6 in a test install. So far so good... knock on wood.

I think the flags become obsolete in the moment where a registered user has set the preferred language, either with the flags or later with his prefs. Agreed, that's a cool idea.

I mean, a non-registerd user was used to set the language with the flags. Now he has to go thru his settings page. I hope he finds the setting, but I fear, not. He's just missing the flags he was used to.

In 'editdisplay, the 'chose language' selection is set not to the cookie language but (back) to the default, if set for the first time. If a user does not correct that immediately, but does some other changes there and clicks ok in the form, he has the default language again, and probably does not even know, why. And still looks for the flags to get his old setting back. And if he does not understand the default language, he is really screwed, he does not even find editdisplay anymore, then.

I would prefer a small extra hack in the 'editdisplay':

a) that if no language has been set yet, previously to setting the default would be to check for the language cookie and preset that setting.

b) Put the icons of the flags next to the selection box. (The eye will recognize the familiar look and will pay extra attention to it. - That's how I plan to hack it in, at least )

That's a good idea to use the flags for selecting their language in their prefs. You could place a text field in for the language selection menu and have the flags set the text field to thir related language when clicked on.


(did that make sense?)

Cool.

I think the way it works is an unregistered user is browsing... they switch to their language... say french. Then they register. By default.... the new user they created is automatically set to french. So as long as they changed languages before registering, they shouldn't have to fool with it.

Clickable flags in the profile would be cool though.

> So as long as they changed languages before registering, they shouldn't have to fool with it.

No, you are right. Trouble start when they change editdisplay for the first time and do not realize that the language default setting in the popupmenu selection is set to a default and not to their previous set cookie's language. A sligt change in the code that looks for a cookie setup would be nice. I think I try to code something like that...

Solution:

In editdisplay.php, find:

code:
 
// ------------------------------- 
// Find out what language they use 
 
if (!$chosenlanguage) { $chosenlanguage = $config['language']; } 

---

and replace it with:

code:
 
// ------------------------------- 
// Find out what language they use 
 
 
// Swap Language HACK Preselect language: 
   //Hack out: if (!$chosenlanguage) { $chosenlanguage = $config['language']; } 
   if (!$chosenlanguage) { 
     	if (!$w3t_language) { 
    		$w3t_language = $config['language']; 
    	} 
  	$chosenlanguage = $w3t_language; 
   } 
// Swap Language HACK end 

---

Now it works and even most stupid users would not run into trouble any more

Nice one Carl

Thanks.

Oh I get it now. Sometimes I'm a bit slow. LOL
Nice one. Will add that.

Can someone please post the latest version on this, as I am confused I know not hard!

Ian.

just testing "last post by"

I hav a user that cannot login, he gets a javascrip error Reference Error, reference to undifined variable: "filters".

Since this hack is the only Javascript with that variable, something might be wrong here?

$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;"';
}

Can someone help, I am not that good with JavaScript.
I just see here the mixed use of "filter" and "filters", is that the problem?

Possibly. Try changing "filters" to "filter" and see what happens. Or perhaps just setting the variable to a blank string so there is no mouse over affects would be simplest?

>Or perhaps just setting the variable to a blank string so there is no mouse over affects would be simplest?

Thanks for encouraging me to kicking away that mouseover.

Since I don't know what the mouse over was good for
I left it untouched until now. Now it'S gone and I miss nothing.

hehe the mouseover was for IE browsers only... It may have worked on some of the other newer ones but I hadn't tested it. I don't think anyone will miss it either.

Help / Give up

OK - I was trying to get this to work with 6.1 but there's the database prefix/ cookie prefix issue to adjust for.... and I thought I was so smart and changed the variable for cookie prefix everywhere....

BUT.... on paper it looked great... in reality I really didn't know what I was doing.

Attached to this post is a candidate for ver 3.1 which DOES NOT work right.

Perhaps Dave or someone can look at it and see what I've missed.

If you click the flag.. it does change the language... but the cookie isn't being set right.. because as soon as you go to another page... you are back to english.

So if soemone can look at the attachment and see what I've missed, I'd apreciate it.

I'll have to stare at this again later... lol not sure where the problem is.


One thing though:

$language_q = "";
if($w3t_language != "") {
$language_q = addslashes($w3t_language);
}


This needs to be changed to include the cookie prefix too.