Welcome to JavaScript 
Strange things happen all the way here
thank you Megazoid… BUT BUT BUT:
I don’t want to send it back to the front-end: I want to use it on the back-end… that’s the only reason I sent it to the back-end… I already have it on the front-end; I sent it to the back-end because I need to use it on the back-end…
here’s an example of why I need this lang-var on the back-end:
if ($langFmAjax === "es") {
$sectionsN = array (
[array elems in one language]
);
}
if ($langFmAjax === "en") {
$sectionsN = array (
[array elems in another language]
);
}
…
<ul>
<?php
for ($i = 1; $i < $iSectionsLength; $i++ ) {
$sect = "section" . $i;
?>
<?php if ($sect != $currSect) { ?>
<li><a href="........."><?php echo $sectionsN[$i-1];?></a></li>
<?php
} else if ($sect === $currSect) {
?>
<li class="selected"><span><?php echo $sectionsN[$i-1];?></span></li>
<?php } ?>
<?php } ?>
</ul>
it would be huge huge pain to have to do this on the client-side with Javascript…
so you can’t use a var you send to the server with AJAX on the server?? you can only use by sending it back to client? seriously? I need to use it on the back-end…
by the way, the syntax for the sending of the param I got from the book “jQuery in Action” (pg 253), there were no quotes around the name in that name-value pair…
You can use it. But you should understand that page you’re sending AJAX request from is already in the browser. If you want to reload whole page using new language – you don’t need AJAX at all, just go to new URL (page.php?lang=en). If you want to reload part of the page (block in sidebar, for example) you can use AJAX to retrieve that block from server but you will have to manually put it back in the right place with JavaScript (using callback in $.post).
thank you megazoid…
oh man… you talk about the page I’m sending the AJAX from, but I’m not concerned with that, I’m concerned with the page (.php) I’m sending it to… that’s where I need to use it…
still don’t get why I can’t use it on the page I’m sending it to thus:
$langFmAjax = isset($_REQUEST['lang']) ? $_REQUEST['lang'] : NULL;
echo "$langFmAjax<br>"; // prints only on console, not browser
// why is this var not available? why does it print only on the console?
// (again: php I'm sending it TO is a file-include... so whatever I print on this include .php file I should see on the browser...)
$language = $langFmAjax;
echo "language -- $language<br>"; // prints only on console, not browser
if ($langFmAjax === "es") {
echo "ES<br>"; // prints only on console, not browser
$testLang = "Espanol";
}
if ($langFmAjax === "en") {
echo "EN<br>"; // prints only on console, not browser
$testLang = "English";
}
echo "testLang -- $testLang<br>"; // throws error - undefined variable
// WHY AM I GETTING AN ERROR HERE????? I just don't get this...
I guess in the worst case I have to reload every time I change languages, but I still don’t get why I can’t do it the way I want to do it…
thank you…
follow-up:
it says here,
http://stackoverflow.com/questions/3855337/php-localstorage :
Not sure why this was closed or downvoted as it seems to be a valid question. LocalStorage is client side and PHP is server side, so you cannot access Local Storage on the server until the client loads the page. However at that point, you can easily send LocalStorage values to the server via AJAX and then you have the values on the server in PHP. Very easy to accomplish.
[italics mine]
so when I saw this I just thought I could have the var I sent with AJAX to PHP available to me in PHP…;~))
PS: in this SO thread they also mention PHP $_SESSION, but that’s only lasts for the current session, right? I need the user’s language choice to be remembered for the next session…
What do you want to achieve?
You want pass variable with language and then change all texts on the page, right?
In such case you don’t need an AJAX.
When you open PHP page in browser (by typing URL), PHP compiler reads script and produces HTML document as a result. Then that document sends back to the browser and you see the page. After that you can’t modify that page with PHP! - because PHP is already finished it’s job for that page. You can make an AJAX request, BUT it will start ANOTHER (background) thread of PHP. So you can’t do echo directly to the browser from that thread because browser already contains a document made by first (foreground) thread. But you still can retrieve a response from that another PHP thread started by AJAX and modify page in browser with javascript.
oh brother… that’s too bad… it would have been so cool if I could have done it that way… so what are my options: cookies? reload pg with the lang param in url? db? (no, actually I don’t want to do db for this…)
I need the user’s language choice to be remembered for next session… cookies can be set to be remembered for next session, right? thank you…
Yeah, I think cookies would be best choice for that.
Also you can try to autodetect user language depending on which languages his browser accepts.
Use $_SERVER['HTTP_ACCEPT_LANGUAGE'] for that.
It would work well enough I suppose. I don’t imagine a lot of non-techies even know about clearing old data.
If it was me, as much as I understand what maya90 is going for, I’d be tempted to save a choice made during registration in a database with some kind of way to “change” in place.(which should be there somewhere no matter)
There are two things to consider with this problem. The state of the user’s language choice and the actual rendering of the page in the language chosen by the user. Two completely different problems.
You can rerender the page with the changed language text from an ajax call, but it would require a pretty intensive SPA like functionality and I would say, it wouldn’t be worth the effort, as just reloading the SPA (or the page) with the new language would be a whole lot easier. So, we are back to what megazoid was pointing out. Since reloading the page is the easiest solution, you could simply send the choice of language with the request for the new page and after that, all content is sent from the server in that chosen language. I don’t think I’ve ever seen a web application ever do it any other way.
The next challenge is remembering the state of the user’s language choice. And, there are a number of ways to handle this. One is through a parameter in the URL query string (as megazoid pointed out) and keeping this available throughout the user’s time on the site, as a parameter or part of the URL. Though, you must remember to add it to every link your application has and it looks ugly as a parameter. You must also get the user’s choice somehow too and store it. This means, without a login, the user sees the default language all the time until the language is selected (again), and this is suboptimal.
This next paragraph isn’t really about storage of the choice, but still partially relevant. You could also have your application work under different subdomains or domains for each language, like de.mysite.com for a German site and es.mysite.com for a Spanish site. The domain determines the language choice. This will mean some hefty web server jockeying, to get the result. For a simple application, it is clearly overkill. And, here you are making a clear choice for the user. They’ll only be able to see any content, one language at a time. If they want to see content in a different language, they’d have to go to a different site. This could end up a UX nightmare too, if the user must login to the sites, since cookies don’t cross domains (i.e. for the logins). So, this is definitely only a choice for the public side of any web application without logins and still quite suboptimal, for a user who is multilingual (and there are actually billions of multilingual users out there).
The last choice is storing the language preference over a cookie (or in local storage with browsers that can do HTML5), and yes, you can set up a cookie to outlive the session with a very long expiration time.
http://php.net/manual/en/function.setcookie.php
Setting the cookie is very easy and unless you are using local storage for other reasons and don’t care about older browsers not working properly with your site (or needing another workaround for them), then use local storage to store the language choice.
I’d go with a simple cookie. Some people might argue, that some users might have cookies turned off. If they do, you’ll either need to account for that (the change to the parameter in the URL query string option) or just say, “you don’t use cookies, so you’re experience with us might not be as nice as you’d expect.”
And lastly, you should store the choice in your database. The user might change computers or browsers or might delete cookies. Obviously, if they aren’t logged in or don’t make a new selection of a language, they’ll be shown the default language again, but if they do login, you’ll have their choice remembered, which also would be clearly expected by the user.
I hope that helps. Language choice for a website is actually a complicated topic. We are only discussing the choice and storing that choice and eventually what to do to show the language, but actually showing all dynamic content in multiple languages is real challenge in and of itself.
Scott
I’m wondering how often a user would want to “switch” language.
I see it as more of a “preference” that a toggle-able option.
In any case, I \think a way to “change” should be available
This is sort of a side topic. But, what does a multilingual user want to see? I’ve seen systems, which toggle all content, and I’ve seen systems, where there is a chosen (toggled) language just for the UI, but the user can also choose to see content in different languages too, at the same time. This is actually how my forum is built to work. You will see english first as a guest or new user, but if you register/log in and then join the “Deutsche Benutzer” (means German users), you can see the “German” forums with German content too. So, it isn’t a toggle, but rather an additional choice.
Scott
this was never a complicated problem at all, until I came across content that I generate from the back-end (actually, that’s not accurate; practically all content is generated from the back-end (like the example I posted above, to generate links to next/prev section…) it’s just that some content depends on back-end vars (mostly arrays, as in example I just mentioned)).
I have another smaller, simpler site, where I switch languages too – no dependence on vars on the back-end to generate content – and it’s all done with local storage, very simply, and works like a charm (and jQuery for the actual language-switching, which also works very well…)
but in this one I have some arrays and stuff on the back-end that “feed” to the front-end… and one of the arrays is a long array, that contains the captions for the photos; I think this long array, if loaded client-side, might slow things down a bit (need only caption at a time; now will have to load entire array client-side… not my preferred solution…)
I don’t like the idea of cookies, precisely because of the issue someone mentioned, of user being able to disable – or clear – cookies
(that’s a neat thing about local storage, they can’t do that – they can’t disable it and they can’t clear what’s stored on local storage… as far as I know…
I think after all is said and done, and based on all the responses I have gotten here, my best option is to move those arrays on the back-end to the front-end and just have no content that depends on vars on the back-end… I don’t like any of the options for switching languages (& having the app remember the user’s choice across sessions) on the back-end… too bad…
thank you very much to all for your responses… learned a lot as always…
You can certainly use local storage for language choice storage. You can also use local storage for storing the actual strings needed for i18n for the application language. However, your user would have to make the same selection again, on another computer. This is why you need a backend to store the language choice for the user (if you have registration and user login, of course).
Scott
This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.