Language specific starting scene?

multilingual

(Uli Zappe) #1

Hi,

sorry if the following question is already covered. I searched and found several similar topics, but none that explicitly focuses on this seemingly basic task.

I want to use Hype for the home page of a website that is currently plain HTML.

In the current version of the website, the home page appears in German or English depending on whether the user language is German or not. I.e. when only the domain of the website is called without specifying an html file, the server serves index.de.html or index.en.html depending on the user language. This works reasonably well.

Now, I want an animated transition from one language specific home page to the other if the user decides to manually switch the language. This means the two language specific home pages must be two scenes within one single Hype document. If only the domain name is called, the scene corresponding to the user language should be displayed, but it should also be possible to link to the home page with the desired language explicitly specified in the URL.

So, is there a canonic way how to implement this?

Thanks in advance for any insight!

Uli


(Mark Hunte) #2

To determine which url is used you could try using the Javascript in an IF conditional block:

window.location.pathname

The user switching will be basic Hype button actions and transitions.

But really we would need an example to look at of what you have so far

As I assume you are already using something detect the language any way (navigator.language) which could be used here also


(Uli Zappe) #3

Well, I don’t have anything, because I’m not sure what’s the best architecture for this task to start with.

Since many websites behave language sensitive, I would have thought this is a common task and there is some canonical best practice.

To determine which url is used you could try using the Javascript in an IF conditional block:

window.location.pathname

This is a good example for an architectural approach that might be problematic.

If I still use two different landing pages (index.en.html and index.de.html), this would mean I have two different pages which both load the same Hype document. I’m too new to Hype to be able to judge if this will waste resources (traffic, memory) in specific constellations.

Also, if I stick with two different landing pages (index.en.html and index.de.html) for the domain-only call, the following could happen:

Let’s assume a German users visits, so he’ll land on index.de.html. But then he decides he wants to see the content in English, so he uses the German Hype scene on this page to switch to the English Hype scene. As a result, he will now see the English main menu (within Hype), which will correctly link (via URLs) to English subpages, but the URL of this page is still index.de.html. This is at least confusing, so I thought there might be a better way.

And what if he uses the Back button in the web browser? (He should land on the English home page scene, but will he, when the browser goes, of course, back to index.de.html? – This would only be the case if the JavaScript on that page was able to tell a domain-only page call (scene must be set according to whether it’s on index.en.htm or index.de.html) from a web browser Back button page call (last scene should show again).)

The user switching will be basic Hype button actions and transitions.

Yep, that part is trivial.

As I assume you are already using something detect the language any way (navigator.language) which could be used here also

No, I don’t, because so far, the web server took care of it. I did a quick search for language determination via JavaScript, and my impression from browsing StackOverflow etc. was that this is not a trivial task in JavaScript if it should be reliable. But it probably could be done, I didn’t spend too much time on it because I wasn’t sure I’d need it.

So the two architectural approaches I see so far are as follows:

1. Two landing pages (index.en.html and index.de.html), as before

+

  • Reliable automatic language detection already exists
  • English and German can be easily linked to with URLs

  • Possibly inefficient? (Two different web pages will load identical Hype document)
  • Possibly confusing (after manual switching, the user might see the English menu on index.de.html and vice versa)
  • Will web browser Back button work consistently?

2. One landing page (index.html)

+

  • No inconsistency between URL and actual language within Hype on that page
  • Hype document will be loaded only once

  • How to determine the user language (again, only in case of a domain-only call!) and make Hype use the corresponding scene?
  • How to specify the desired language with a URL?

So, in one way or the other, both approaches have the problem that at one point JavaScript must decide whether it should set the scene according to the user language (domain-only call) or not (web browser Back button in the first approach, all calls except domain-only calls in the second appraoch)

Since I assumed this to be a common task, my hope was that there is a clever third architecture I’ve failed to see.


(Mark Hunte) #4

Well this is a bit more than what we had before…

It was not clear if this was being done by the browser /server or your page JS. And it was not clear you wanted to transition away from index.de.html or index.en.html .

So from what I am understanding, you want the server to point the correct scene in a Hype Page.

You may want to look at

This should allow you to point to individual scenes on a single Hype page and solve the browser back button. I refer to anchors.


(Uli Zappe) #5

Sorry if I did not make this clear enough. I referred to it when I wrote the server serves index.de.html or index.en.html depending on the user language in my original post.

And it was not clear you wanted to transition away from index.de.html or index.en.html.

But I don’t know if I want/should transition away from the index.de.html/index.en.html approach. That is exactly my question: What is the best architectural approach to address the task at hand, i.e. opening the home page (with the Hype content) with a scene selection depending on the user’s language if and only if he first opens this page (but not when he manually selects the other language, and then, by using the browser’s Back button, comes back to the home page from some subpage of the website).

In the plain HTML solution this is all very clean cut: If the user simply calls my.domain.com, the server decides whether to serve index.de.html or index.en.html depending on the user’s language. As an example, let’s say it’s index.de.html (German). Then, when the user decides he wants to use English instead, he clicks on an English Version button on index.de.html and thereby switches from index.de.html to index.en.html, which is unambiguous. When he goes to some English subpage linked from index.en.html and then uses the web browsers’s Back button, he will be back again on index.en.html, his selected language, as it should be.

The whole problem with the Hype version starts with the fact that when the users switches from (in my example) German to English, the page URL does not change, only the displayed scene changes. No matter whether it’s the index.en.html/index.de.html approach or the index.html only approach, there’s always (in one form or another) the question: How do I present the scene corresponding to the user’s language at the first call of the home page with my.domain.com only, but the scene last used when the user returns to the home page from some subpage with the browser’s Back button? (The site does not use any cookies, BTW.) Let’s call this the “consistency problem”.

You may want to look at Linking to a specific scene from inside and outside of a Tumult Hype document Scenes

I found that one in my search, of course, but it addresses only a part of the puzzle. For the index.html only approach I still wouldn’t know how to determine the user’s language via JavaScript, but most importantly, the “consistency problem” detailed above isn’t addressed by that.

To be able to even start, I’d first have to decide between the index.en.html/index.de.html and the index.html only approach. So addressing the whole problem step by step, and assuming neither approach is clearly better suited for the “consistency problem”, the first two questions to decide are probably:

  1. Would the index.en.html/index.de.html approach result in the Hype document being loaded twice when both pages are displayed at some points in time, thus being less efficient? (Both index.en.html and index.de.html would use the same Hype document, just display a different scene at first call.)

  2. Is there a JavaScript method to determine the user language which is as reliable as the index.en.html/index.de.html approach which is driven by server logic?

For both questions, the answer Yes would argue for the index.html only approach, and No for the index.en.html/index.de.html approach.

(I’m still surprised this isn’t a “standard problem”.)


(Mark Hunte) #6

Oops, sorry missed that…

What if you keep the index.de.html & index.en.html but just have either redirect to a hype page and scene.
I assume then this would takeout the need for you to write any JS for the language and any load concerns you have since you are only using one Hype page. And the index ones are simply redirects.


#7

It isn’t a “standard problem” because it’s relatively easy to determine the user’s location by using a set of methods that each browser accepts in order to detect the language and using whichever language you prefer. Which as has already been stated, is what is happening when your existing HTML site serves “index.en.html” or “index.de.html”.

Code, used within Hype can implement the same or similar approach to determine user language and serve scenes based on the info returned.

First things first. Hype (even though it can be used in order to create full web pages) is a tool primarily conceived to create web animations. So, there is no “best practise” when it comes to re-creating websites and specifically, serving pages (scenes) based on user language. The fact that Hype allows for users to use Javascript inside of it, opens it for (ab)use as a tool to create more than just animations.

It looks like you have thought a lot (too much in my opinion :slight_smile: ) about this already. There is no “best architectural approach” (based on the info above) in my opinion. I would just start building and see what problems arise.

I think the solutions Mark has proposed are a good basis to build on.


(Uli Zappe) #8

Hmm, yes, I’ve already thought along those lines.

But the redirect cannot explicitly call for a language specific scene.

Because if, let’s say, index.en.html redirects to index.html#en, then we’d again have the problem that using the browser’s Back button from a subpage, we’d end up on index.html#en even if the user had switched to German in the meantime.

To start somewhere, I have put together a simple demo Hype document that uses the index.html only approach and assumes that the JavaScript function window.navigator.language() works with all current browsers:

LanguageSelection.hype.zip (114.2 KB)

This implementation uses a Hype document with an empty, unused first scene. On Scene Load of this scene triggers the following JavaScript function:

function languageSelection(hypeDocument, element, event) {
	var lang = window.navigator.language.substring(0, 2);
	if(lang == "de") hypeDocument.showSceneNamed("German");
	else hypeDocument.showSceneNamed("English"); 
}

(Of course, you might add as many additional languages as you like with else if lines before the else line which specifies the default language (English in this code example). And note that you need to cut the language string returned by JavaScript after two characters, since some browsers return e.g. en and others en_us or en_US.)

Now, if a user first visits the home page, the Hype document is going to load the first, empty scene, which triggers the languageSelection() function and thus in the end displays the scene with the correct language to the user. In contrast, when the user goes to some HTML subpage (in the demo Hype document represented by the English and German Apple home pages) and then returns via the Back button of the browser, the languageSelection() is not triggered again, instead, the last scene is used. So even if the user switched to another language, everything is still consistent.

But here is where it ends. Because if the user returns from the subpage via a Home URL on that page, the languageSelection() function will run again and the user default language will be displayed even if he switched to another language and returned from a subpage this language. This is incorrect behavior.

Of course, you could add a mechanism to the Hype document that would allow to address a specific scene from the URL (per the Linking to a specific scene from inside and outside of a Tumult Hype document documentation linked above). So then e.g. all English subpages could link to the home page via index.hml#en and would – correctly – force the return to the English home page. But as soon as you do this, the Back button of the browser wouldn’t work as expected anymore: For instance, the user returns to the home page from an English subpage, thus via index.html#en. There, he switches to German (maybe he went to the home page to do exactly that) and goes to a German subpage. Now, if he clicks the browser’s Back button, he will go to index.html#en (because the URL didn’t change when he switched languages within Hype) and will get the English home page instead of the German one.

And this is true for all variants I thought through so far. From the three ways to go to the home page

  • by using the domain name of the site (should result in the home page in the user language)
  • by returning from a subpage of the site via a link on that page (should result in the home page in the language last used)
  • by returning from a subpage of the site via the browser’s Back button (should result in the home page in the language last used)

there is always at least one way that does not work.

And the reason is basically that the home page URL does not change when the user switches the language within Hype, i.e. moves from one scene to another.

Meanwhile, I’m almost convinced that because of that, this is simply not possible with Hype (without state preserving cookies, that is).


(Uli Zappe) #9

I’m well aware of that. And that is exactly what I intended to use Hype for: To provide an animated transition between different language settings on a web site that is otherwise mostly plain HTML.

Ironically, it is exactly the fact that I do not intend to use Hype for the complete website that seems to make this task impossible. Because the whole problem arises if you try to combine the scene based Hype with the URL based web pages. If the whole website stayed within Hype, the problem I tried to describe would simply not exist.

I would just start building and see what problems arise.

I already know what problems will arise. :stuck_out_tongue_winking_eye:

I think the solutions Mark has proposed are a good basis to build on.

No, they are not, unfortunately. You obviously underestimate the structural problem.


(Jonathan Deutsch) #10

You do need to preserve state somehow, because if there’s a reload then your “state” does get lost. While you could use cookies, you may instead want to consider the browser.pushState() call - this manipulates the URL without loading, and then you can use your URL detection method when the back button is pressed.


(Uli Zappe) #11

Well, yes, that’s at the core of this issue – preserving/communicating state without changing the URL.

While you could use cookies, you may instead want to consider the browser.pushState() call - this manipulates the URL without loading, and then you can use your URL detection method when the back button is pressed.

Now this sounds extremely interesting. I’m no expert at all in web technologies, so I never heard of that. I will evaluate this as soon as time allows.

Thanks for the info!


#12

to be honest I have no idea what the structural problem is. As most of your posts seem to be unclear as to what it is you want to do, at least to me. I’m sure you know but I can’t seem to follow the logic. So, for that reason, I’ll bow out.


(𝕄𝕚𝕔𝕙𝕒𝕖𝕝 𝔾𝕒𝕣𝕠𝕗𝕒𝕝𝕠) #13

Local Storage might be an easy way to do this… https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage

I’m feeling inspired in creating a new Free Hype Template …I’m thinking of creating a Multilingual template.

Maybe pick friendlier words. He was trying to help you. :slightly_smiling_face:


(Uli Zappe) #14

This was indeed the right hint to a solution. However, the solution turned out to be even easier.

As I wrote, I’m no expert at all in web technologies, and that even implies that I wasn’t aware that window.location isn’t read-only, but can be written as well. Shame on me, and sorry!

This simple fact immediately solves the whole issue, as it brings the selected (language) scene in Hype and the page URL in sync, thus getting rid of all the problems I described.

Here is a new and working version of the demo Hype document:

LanguageSelection.hype.zip (207.9 KB)

The basic concept is that once the language is determined, a #en or #de hash is always appended to the home page URL (i.e. from then on it’s always index.html#en or index.html#de).

The script from above is extended as follows:

function languageSelection(hypeDocument, element, event) {
	var hash = window.location.hash;
	
	if(hash == '#en') hypeDocument.showSceneNamed("en");
	else if(hash == '#de') hypeDocument.showSceneNamed("de");
	else	// no known language setting in the URL hash;
			// determine language automatically
	{
		var lang = window.navigator.language.substring(0, 2);
		if(lang == "de") 
		{
			hypeDocument.showSceneNamed("de");
			window.location = '#de';
		}
		else
		{
			hypeDocument.showSceneNamed("en");
			window.location = '#en';
		}
	}
}

The additional first few lines check if a known language hash is already appended to the URL. If so, the corresponding Hype scene is displayed and the script exits. This allows links and manual URL input in the browser’s address field to directly address the desired language of the home page.

All links in the language specific subpages that lead back to the home page must also always use index.html#en or index.html#de and never index.html.

If no known language hash is appended to the URL, the previously already used JavaScript function to determine the user language is executed, the corresponding Hype scene is displayed and the corresponding hash is appended to the URL.

This makes sure that the displayed home page will always be either index.html#en or index.html#de and never index.html alone. Thus, the browser’s Back button will also always work correctly.

However, there’s still one thing missing: An additional function that makes sure the URL stays in sync with the selected language when the user switches the language manually in one of the Hype scenes.

This is this function:

function adjustURL(hypeDocument, element, event) {
	if(element.id == 1) window.location = '#en';
	else if(element.id == 2) window.location = '#de';
}

It is called when clicking either the Switch to English button (which is assigned a Unique Element ID of 1 in the Identity Inspector) or the Switch to German button (which is assigned a Unique Element ID of 2).

Together, these functions make sure everything is always consistent, without storing any state information locally (which might be legally important if you think of the recent, (at least in the EU) insane cookie laws).

Note: If you download the demo Hype document and test it from within Hype, you can, of course, not actually call the example subpages; empty pages will appear instead and you’ll have to “simulate” clicking the link back to the home page by entering the index.html#en or index.html#de URLs manually.

To fully test this demo, you must export it to a server root directory (if you still have your Apache running on macOS, it could be ~/Sites, called with http ://localhost/~yourUserName). I have added a demo site directory within the archive, with the Hype demo already exported, LanguageSelection.html renamed to index.html, and two demo subpages.

I hope that helps those with a similar problem.

Uli


(Uli Zappe) #15

@jonathan

I wonder if the solution I just presented has a very generic aspect to it.

Judging by the popularity of the Linking to a specific scene from inside and outside of a Tumult Hype document post, there are many Hype users who want to directly address a scene by a URL.

But that’s only half of the equation. The other half required for round turn consistency is that switching the scene also changes the URL. That this does not happen by default was the core of my consistency problem.

I could imagine that some Hype users would favor such a behavior for their Hype documents in general, maybe as a Preferences option (or as a scene specific/document specific option?). If turned on, Hype would – without any kind of additional functions such as those in my solution above – take care that a # SceneName hash will always automatically be appended to the current URL and reflect the current scene, and inversely, that a URL with # SceneName appended would always automatically select the corresponding scene, without the need of explicitly specifying a sceneURL() function.

I think that would be an extension that is very consistent with standard HTML usage and would make the coexistence between Hype pages and plain HTML pages much easier in some situations.


(Hans-Gerd Claßen) #16

as a feature request i guess it’s a good one -> Like :slight_smile:


(Uli Zappe) #17

Upon renewed inspection I realized that the sceneurl() function described in Linking to a specific scene from inside and outside of a Tumult Hype document does in fact already change the URL according to the selected scene.

So I wondered why this did not work for me when I tested this function. I cannot reconstruct exactly what I did wrong, but I think the reason was that both sceneulr() and the setTitle() function suggested somewhere else use the scene name as their variable. However, you will hardly ever want the same string as a hash and as your document title.

In my case of language selection, the obvious choice for the hash are the language codes (en, de, …) whereas these codes would be very poor page titles. :wink:

So while my suggested “feature request” might basically boil down to integrating the sceneurl() function within Hype itself, it would certainly make sense to be able to specify separate hash and title names for the GUI in each scene. You can use the scene name for one, but you’d need an additional entry for the other.


(Jonathan Deutsch) #18

Glad you were able to use the anchor solution. This is a good feature request (in fact it is quite long-standing; we’ve had it on our tracker since the beta for v1.0).