the device (dot) attributes get evaluated when krpano starts and are not accessible anymore later.
this is not what you want for languages, because you might want language changes later on.
but why "native" anyway? this can be done quite easy with some code.
i use a similar localisation concept for years ..
hm maybe i should release it as a plugin

or






Piotr

Zitat von »Luis Erantzcani«

The downside of this method as I can see now is that to change language krpano would need to "restart" the tour/scene (with a new "language value"), though if you see most websites all over the web work just like that.

Why? The language can be reloaded dynamically. I always do this. No need to restart the project.


Piotr

https://krpano.com/forum/wbb/index.php?p…rlang#post44674

i don't know if predefining a certain way of localisation at a higher level is really necessary.
its is a normal coding task and users can implement it in several ways already. (just my opinion)

Hi,

having a build-in solution would be definitely great, and ideally it should be dynamically, but I'm still unsure about how...

Static solutions with reloading would be already possible in several ways.

E.g. related to this example:

You could have a globally defined language variable and some custom tables with the translated texts and then 'insert' them where you need them in the xml using the 'get:' or 'calc:' xml attribute expressions:
https://krpano.com/docu/xml/#xmlget

E.g.


or just one <translations> element, one for each language defined in a separate xml and include only that xml that matches the current set language, then also such code would be possible:



But I think the more interesting solution would be a dynamic one - that means to change the language without reloading. Here I'm thinking about special placeholders in the textfields - or a special settings that tells the viewer to automatically update the content when the global/predefined language variable changes.

Maybe something like this:


So that variables defined with a '.lang.xx' tag will get automatically tracked and updated on language changes. But that would lead to problems with the resulting variables get copied, e.g. when using <style>. Then the automatically updating wouldn't reach the actual target variable...

I will keep thinking, but all ideas are welcome of course!

Best regards,
Klaus

hi klaus,

i think there are just two cases, not?

1) the localisation is defined in the xml element itself
eg. <layer ... html.de="hallo" html.en="hello" />

this is pretty easy, you could just have a global lang variable
with a setter triggering an update everywhere

2) centralized localisation
eg <data ... /> which must be copied to an element

here you could stick with the data element
<data localize="hotspot[test].hml" lang="en">hello</data>
<data localize="hotspot[test].hml" lang="de">hallo</data>
or use a new element
<localize target="hotspot[test].hml" html.de="hello" html.de="hallo" />

with this (kind of reversed) thinking the texts in the elements would stay undefined
and updated by processing the data (or localize) elements

i still think something like that is fairly easy to do on the user side
but an integrated solution is welcome of course

I think adding attribute.variable="..." feature would be absolutely fantastic. But this technique would not be useful for changing the language. There are many examples of the use of multilingualism that you can analyze and create your own standard. Peter has its own, I have my own, PTP has its own. The existing KRPano mechanisms allow for the creation of comprehensive mechanisms in this area (replacing signs, graphics, etc. - example https://www.zamek-pszczyna.home.pl/wz/index.html) but attribute.variable feature (where variable is bool value) would be interesting.

Check https://gist.github.com/msikma/8912e62ed866778ff8cd for a list of languages to manage on the net.
When visits have dozens of different languages, I'm curious about the html.lang.en and html.lang.de proposed...

We have around ten languages on our side, managed like this :
<layer name="layer1" html="get:language[get(lang)].layer1_html" .../>

<layer name="layer2" url="get:language[get(lang)].layer2_url" .../>

<language name="en-UK" layer1_html="english html" layer2_url="english img" .../>
<language name="en-US" layer1_html="US html" layer2_url="US img" .../>
<language name="nl-BE" ..../>
<language name="fr-FR" .../>
<language name="fr-CA" .../>
...
works kind of well with many languages.

what is still not handled on our side is in case the layer1_html attribute is not filled in for a given language, there will be some empty string displayed. we thus need to be very rigourous in filling all <languages>. Actually, it would be nicer to define the fact en-UK is default and if no attribute layer1_html is found in language[nl-BE] then krpano would read layer1_html in the language[en-UK] node .

Interested in the "attribute.variable" thing though, and better if it is not restricted to languages only (currently this attribute.variable is restricted to devices for instance), and if it is constantly assessed (should not require a reload).

Florian