Multilanguage possible on textboxes or buttons?

Hi @robby,

My understanding of the original question is , it is about having an easy way to build a setup where the end user not the developer can select a language from a button on the site… This has to be a dynamic process

Although what you refer to is similar It may be better if you create a separate request RE: static language export.

Thanks for your feature request. We don’t get many requests for multilingual element support, so for now @MarkHunte’s example is a great way to accomplish your and @Tomi’s goal.

@rene used a similar method for several of his interactive children’s books for sale:

Hi Guys, I was able to do this with Edge… I did some tests and was able to port over the code to Hype and it works. You store translations in a text file and based on the URL parameters you show the correct text version… For example,



1 Like

Awesome, do you have a sample/simple document to share with your specific technique?

One issue you may run into with this approach is that some languages take up a lot more space than others, which will impact on the look of the final product. Depending on the languages you need to translate for, creating separate scenes might be a better approach.

1 Like

Yep. But there are ways to handle that…

Also Just had a thought that you can use the anchor hash in a link for language selection.

First Example is a stripped version of the version above ( Buttons & storage stripped )

If you enter the normal url you will get the first scene as normal. But if you use:



You will get the language chosen. This still uses the global variables that represent the language text for each element.

We just get the window.hash to get the anchor and use that to pick the language. ( in Head )

Since we still have a single scene we can just run the other javascript functions in the normal way using the inspector. (40.9 KB)

You can also use the same method if you want to have multiple language scenes .

Since we have a multiple scenes we run the other javascript functions from the head.

<script type="text/javascript"> 
 window.langChosen = window.location.hash.substring(1); 
	function sceneTitleCallback(hypeDocument, element, event) {
console.log( "call");

if("HYPE_eventListeners" in window === false) {
window.HYPE_eventListeners = Array();
window.HYPE_eventListeners.push({"type":"HypeDocumentLoad", "callback":sceneTitleCallback});


The lang() function will then load the correct scene corresponding with window.langChosen (19.9 KB)

Note: Initially thought of this and wrote my code but then did a search on the forum for hash to see if it had been discussed before. It had in @Daniel 's excellent thread where I nicked the .substring(1); bit :smile:

1 Like

Why doesn’t that surprise me! Thanks Mark.

1 Like

Mmm, thought I had this working but not quite. Will show what I did in Edge Animate that works.
If anyone can help port it to Hype I think it would be a tremendous help for everyone.

So the way I had it setup was keep all my translated in a separate javascript file to separate content from design.
The files looks something like this:

var Localize = {
		"es": {
			"Hello": "Hola",
			"Goodbye": "Adios",
    	"fr": {
			"Hello": "Bonjour",
			"Goodbye": "Au Revoir"

In my document I would create corresponding labels that would contain the translations.
Then when my Edge document would load (compositionReady) I would do the following.

First, I would run a script that to create a variable from the the URL parameter.

sym.getParameter = function(name) {
    name = name.replace(/[\[]/, "\\\[").replace(/[\]]/, "\\\]");
    var regexS = "[\\?&]" + name + "=([^&#]*)";
    var regex = new RegExp(regexS);
    var results = regex.exec(window.location.href);
    if (results == null)
        return "";
        return results[1];

var Lang = sym.getParameter('lang');

Then lastly, I would easily tell Edge what I wanted translated by the following:


That was it. To view the correct language all you would have to do is customize the url, for example…


My problem seems to be the eval() portion of my solution.
Can anyone help?

OK, got it working. See attached source files. You can use this method to localize any text and keep content separate from design. (23.6 KB)

Instead of eval(). You can use,

hypeDocument.getElementById('Hello').innerHTML = window['Localize'][lang]["Hello"];
hypeDocument.getElementById('Goodbye').innerHTML =  window['Localize'][lang]["Goodbye"];
1 Like

nice, thanks mate.

Just been making a personalised Christmas card to people. Yes one card to fit all. I’m lazy and find this more fun than writing out cards. Oh and help save the trees…

But this whole idea is really great for them.

Using a version of the posted above, I am able to change the creating using the above methods, love it. :smiley:

Looking at this again, and I think it’s way to complicated. I still want a way to do alternatives (content, sizes, etc.) in Hype and switch between them with on click: EN verison, DE version and have elements shown / hidden.

Then I want to export EN version (using all EN flagged elements) or DE version etc.

It could be that simple…

(BTW: I can hack JS back and forth, etc. but it’s not the KISS way to do it)

I think thats called Scenes… :sunglasses:

No, it’s not. To make it more clear:

Below you see the _EN and _DE element names. Depending on what I want, I turn them on or off. I have enabled one EN and one DE so you see the effect.

The thing is, I keep the animation which is in big parts the same between EN and DE only once. With scenes I would have a copy and need to duplicate changes… not very efficient.

What I want is a way that I can switch to all *_EN elements or all *_DE elements. It’s pretty simple…

with applescriptsupport you would be able to for instance switch on/off elements with equal nameparts!!!

@hype so this would be a nice usecase … :slight_smile:

1 Like


I must admit I am not convinced with your argument and would much prefer an Applescript solution.
( Which if we had I am pretty sure Applescriptors like my self would offer up code)

But a suggestion (simplified ) of how the Hype team may do this is to offer a new type of Group.

These groups would be called Advanced Export Groups.

If you create a Advanced Export Group, a new Advanced Export Group icon appears at the top of the element tree.
Advanced Export Groups will always be at the Top of the element tree.

Elements added to a Advanced Export Group do not show as moved in the element tree. This is because we do not want to change the layer index. But opening an Advanced Export Group will reveal a reference to any elements added to it.

Advanced Export Groups could also have the hidden/display eye next to it.
If set to hide, all referenced elements would be hidden. Overriding the original elements hidden/display.
If set to display then the referenced elements original setting is honoured, which would be either hidden or display

When using Advanced Export, the Advanced Export Groups will be listed with a check box to include or not include.

The trick with the name part was just done so I can distinguish the different things fast. Overall it’s not the way to go. It’s a messy hack because of missing alternatives. And I don’t like the AS approach… but this is purely emotional based as it smells like a messy hack on top of a messy approach :wink:

@MarkHunte While I can understand your idea, I’m not a fan of grouping or mapping of information to trees. It’s a categorization, and mostly needs to be MECE. Which is often not the case.

I would like to be able to hack in tags on wich I can then filter (inlcude / exclude) prior an action. That would be most flexible.

Not sure what these are ( ok, I know what a kiss is, think I had one once but pretty sure it’s not what you mean) can you elaborate ?

It may be that the tree is the wrong place to display them but in essence the type of group I mention are Tags.

MECE principle: mutually exclusive, collectively exhaustive (see wikipedia)
KISS = Keep it simple stupid :wink: