64
Replies
Birnou & Osgood: thank you both for your suggestions. I have almost zero knowledge of JS, so I do need simple. And I won't be able to test either solution for a few days when I get a replacement computer (if it arrives). In both cases, do I understand correctly thet the script is on the English or Spanish page rather than in the "included" header? 🙂
By @Galeodan
The script can be inserted in the 'included' header file, otherwise you would have to include the script in each individual page, which defeats the object because if you want to change the script at any time in the future you would have to update all the pages where the script resides rather than in just the 1 file.
It knows where it is, so to speak. So the button in the header could have JS to find a specific ID on the page it finds itself on. At that ID, I would have a simple link: On the English page, "aboutus.html", this link would point to "aboutus-es.html". And on the Spanish page, "aboutus-es.html", the link would point to "aboutus.html". These links would be invisible to the user and execute automatically. I would have to code specific links for every page, but that would not be a burden - The rest of the page is different in any event. Perhaps I have this all wrong - I would NOT be surprised 🙂
By @Galeodan
Yes, the links would be invisible to the user, they would either click a button or a flag option, depending on which script you use, which takes them to the correct language page.
EDITED
IF you are using a .php include file then all your other pages will be .php files rather than .html files
By @osgood_
Would it be simpler to use a session variable? Pressing the buttom would set the value of the session to `en` or `es`. The session variable can then be used for the URL.
Nutshell: Does a button in an included header know what page it is on?
Background: I am in the process of completely re-coding some bilingual websites that were generated using Netobjects Fusion.
===========
Short Answer: No. HTML alone doesn't DO much of anything except provide structure for content.
NetObject Fusion: Ugh! You have my deepest sympathies. Throw everything out and use WordPress with the WP Multi-Lingual Plugin (WPML).
I beta tested and wrote tutorials for NOF users so I say this with more than casual experience using it. What NOF did to botch up code was unforgivable but understandable given that it was never a code editor. It was a Code Generator supported in large part by optional add-ons or 3rd party widgets -- the same ilk as GoLive and Muse, all of which are dead now. Nothing generated by NOF is worth salvaging except the basic, unstyled text content which you should strip and paste into WordPress.
Good luck with your project!
from my point of view, I would say that the 'English' toggle button is not useful on the English page, and similarly the 'Spanish' button is not necessary on the Spanish page
By @B i r n o u
I think it can be useful in terms of visual appeal if flags are used, although its not strictly necessary. My issue with using a button is that it looks a bit dull, whereas using images of country flags is visually more pleasing........you could always swap the flags according to which language page you are on if you didnt want both the English and Spanish flags on the page at the same time.
i think you misinterpreted my statement.
No, its something l wondered about when the OP posted saying they had 2 buttons, as flags. Theres really no need to have both, only for visual appeal. I guess it becomes then a matter of personal preference as to whether one thinks including both adds anything to the clarity for the user or visual impact.
Either way both scripts presented can easily be adapted to use 1 button or 1 flag, or both.
definitly...I agree
as the OP said that the buttons were in the included header, and it was a two language only, it was easly adaptable to focus on only one swapper button only.
A one flag per page adapted script, assuming flag images are stored in a flags folder. The applicable flag and applicable language link get injected into the <a> tag by the script.
<a href="" class="language"></a>
<script>
const language = document.querySelector('.language');
const url = window.location.href;
const pageName = url.substring(url.lastIndexOf('/')+1);
const currentPage = pageName.split('.');
const currentLanguage = currentPage[0].includes('_es') ? "english_flag.jpg" : "spainish_flag.jpg";
let destinationPage = '';
switch(currentLanguage) {
case "english_flag.jpg":
destinationPage = currentPage[0].replace("_es", "") + ".html"
break;
case "spainish_flag.jpg":
destinationPage = currentPage[0] + "_es.html"
}
language.setAttribute('href', destinationPage);
language.innerHTML = `<img src="flags/${currentLanguage}">`;
</script>
Well plenty to think upon but I think we have it covered from most angles. There should be a solution in this thread which will work for the OPs requirements.
Thank you all for your help and sorry I couldn't jump in sooner. I have not been able to try any of the soultions but hope to shortly. Meanwhile, I can join the conversation about button-strategy. This is how I handle it at the moment:
The English page headings show the English flag and the Ecuadorian flag:
The English flag does nothing but has a thick green border to indicate that is the active language. If you click on the Ecuadorian flag it takes you to the Spanish home page (in future it will take you to the parallel Spanish page). Although it's pretty obvious you are on an English page, I think the visual clue is still useful.
On the Spanish pages, the setup is reversed. The Spanish flag is highlighted and clicking on the English flags takes you to the English page.
Showing both flags also shows the user there are 2 choices. I use the Ecuadorian flag because that's where we are. We don't expect many users to recognize it as the Ecuadorian flag but I think it looks "Spanish" enough to serve purpose. I could always put a small "Esp" on it.
a filter on the active language should be added, just to avoid to reload the same page when the appropriaté language is on.
By @B i r n o u
That should do it:
<script>
// assign language anchor tags to variables
const english = document.querySelector('.english');
const spanish = document.querySelector('.spanish');
// get current url
const url = window.location.href;
// get pageName from url string
const pageName = url.substring(url.lastIndexOf('/')+1);
// remove .html from page name
const currentPage = pageName.split('.');
// remove _es from page name
const destinationPage = currentPage[0].replace("_es", "");
//add link and border to flag
if(currentPage[0].includes('_es')) {
english.setAttribute('href', destinationPage + '.html');
spanish.setAttribute('href', '#');
spanish.style.border = "4px solid green"
}
else {
spanish.setAttribute('href', destinationPage + '_es.html');
english.setAttribute('href', '#');
english.style.border = "4px solid green";
};
</script>
yes I use var when I don't wont to be block scoped. so when first coding (except when I know exactly where I'm going) I use var... and I keep const for real constant that won't never change its value.
By @B i r n o u
I dont think 'var' is needed any longer, it can be replaced by 'let' in any instance, however I don't really have a problem with anyone using 'var' as its not technically wrong. The introduction of 'let' and 'const' just identified in which scope they could be used a bit clearer for the developer.
I often get annoyed when programs like the 'php storm' editors warning system suggests you might want to use 'let' or 'const' if I do use 'var' - I guess its doing its job in trying to get you to use modern practices but hey I'll decide what I'm going to use, thanks. Until 'var' becomes officially redundant, it isnt, so if its just a coding habit from years of using it, then its really doing no harm.
Im just trying to keep myself evolving, so I rarely use 'var' now.
I dont think 'var' is needed any longer, it can be replaced by 'let' in any instance,
By @osgood_
Sorry, I had a conf call...
In fact , var still have the ability to be parsed, where the declaration is made (top, in between function, ... anywhere) before the script execute. you know the two reading passages of the javascript engine...
so var still have the ease of being able to be written in a grouped manner by nature of functionality... while allowing to be used, if necessary, by written blocks upstream.
try
<script>
console.log("'------------------'");
console.log('var : ' + _var_foo);
console.log('let : ' + _let_foo);
console.log('const : ' + _const_foo);
console.log("'------------------'");
var _var_foo = 'ok';
let _let_foo = 'ok';
const _const_foo = 'ok';
</script>
let and const both create a respective error well identified as such, the first let, as a use before declaration, and the second const, as an attempt of second declaration
AdChoices