You are not logged in.

Some thoughts for multilanguage support in krpano

Dear visitor, welcome to krpano.com Forum. If this is your first visit here, please read the Help. It explains in detail how this page works. To use all features of this page, you should consider registering. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.

Luis Erantzcani

Intermediate

  • "Luis Erantzcani" started this thread

Posts: 248

Location: Mexico City

Occupation: Virtual tours, Krpano coding, Graphic Design, Photographer, Panographer

  • Send private message

1

Sunday, February 28th 2021, 4:06am

Some thoughts for multilanguage support in krpano

Hello Klaus,

I've been thinking recently about multilanguage support in krpano, currently It's done in many ways by community but I have this idea that maybe could work and ease out things for all us.

Right now I love the way krpano manages multidevice with the DEVICE global variables that is used to specify specific ELEMENTS for each platform, example:

Source code

 
1

<layer name="button1" devices="desktop".../> <layer name="button1" devices="tablet".../>


And ATTRIBUTES with the attached "surname" for the device that let's us specify then in a very specific way. Example:

Source code

 
1

width.desktop="80%" width.mobile="100%"


Following this already existing path could it be possible that we have a similar LANG (LANGUAGE) global variable? Then if we declared it as let's say "en" for english or "es" for spanish then hotspots, layers, etc. would be defined very quickly in code for each specific language, example:

Source code

 
1

html.en="[h1]Welcome![/h1]" html.es="[h1]¡Bienvenido![/h1]"

Source code

 
1

<data name="body_text" lang="es">...</data> <data name="body_text" lang="en">...</data>


For regular non specific language it could be left empty so it didn't apply, like currently done when device is not specified.

I can think of some hacks right now to enable this on my own tours but in the end would be turnarounds for this idea, so I think it would be great if we could have this in a native way.

I don't know if something like this exists (haven't seen it) or can be possible (though I know you make everything possible *squint* ) so I'd love to hear your insight about this.

If somebody else wants to share thoughts or experience go ahead, I think we can all benefit of multilanguage native support in next Krpano versions.

Thank you.

Luis *thumbup*
imagen360.com / skyvr.mx
facebook.com/Erantzcani360
facebook.com/skyvrmx

indexofrefraction

Professional

Posts: 1,241

  • Send private message

2

Sunday, February 28th 2021, 2:43pm

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 *whistling*
zFilter plugin -- zFlare plugin -- zSnapshot plugin

This post has been edited 5 times, last edit by "indexofrefraction" (Feb 28th 2021, 3:07pm)

spacerywirtualne

Professional

Posts: 1,091

Location: Poland, Europe

Occupation: krpano developer : virtual tours : the cms4vr owner

  • Send private message

3

Sunday, February 28th 2021, 3:12pm

Source code

 
1

<data name="body_text_es">...</data> <data name="body_text_en">...</data>


Source code

 
1
2

set(lang, es);
get(data[calc('body_text_'+lang)].content)

or

Source code

 
1

<data name="body_text" lang="es">...</data> <data name="body_text" lang="en">...</data>


Source code

 
1
2
3
4
5
6

set(lang, en);
 for(set(i,0), i LT data.count, inc(i), 
  if(data[get(i)].lang == lang,
   // english data
  );
 );



Piotr
Your own professional, online cloud tool for creating virtual tours - www.cms4vr.com

facebook page :: youtube

cms4vr team *thumbsup*

Luis Erantzcani

Intermediate

  • "Luis Erantzcani" started this thread

Posts: 248

Location: Mexico City

Occupation: Virtual tours, Krpano coding, Graphic Design, Photographer, Panographer

  • Send private message

4

Monday, March 1st 2021, 3:04am

Hello people, yes, as I mentioned I also can think of some ways of doing this by actions and dynamic code (been doing krpano for some years) but I think the most straight simple way to do it (IMO) would just coding language attribute or "surname", no extra actions, no calc, just set which language would each "item" be.

If krpano parser could handle this It could be doing the task for everything (is this correct Klaus?), layers, hotspots, data and even other elements (I use a lot of custom ones like <photo> <gallery> <notifications>, etc, not accesbile by for regular data, layers, hotspot loops) and wouldn't require any extra actions, just defining language maybe at embed code in html or as a query (Matterport guys do it this way BTW), or not defining it at all for the same behavior we have right now.

Taking the example by Piotr as a dynamic language config structure, I can see it perfectly working but in number of codelines compare that with just adding the language attribute to both data elements, now if krpano also has to have something similar for hotspots, layers and other elements, it will needmuch more lines in comparison to just adding some attributes right?

BTW, look at your own code, by syntax structure the language "surname" has to be specified in some way, either by an element name or some attribute, or attribute value or somewhere else, that "_eng", "_it" "_spanish" thing is already there, just managed diferently by everybody so I just say, why not adding some native support in krpano?

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.

Now this way I mention is one option though there may be some better way to do it in a native way, if you have some thoughts about just go ahead mention them. Fact is there's no krpano specific support for multilanguage right now and I'd just love to have something in the future to not have to do more code than needed in my favorite 360 viewer. ;-)
imagen360.com / skyvr.mx
facebook.com/Erantzcani360
facebook.com/skyvrmx

spacerywirtualne

Professional

Posts: 1,091

Location: Poland, Europe

Occupation: krpano developer : virtual tours : the cms4vr owner

  • Send private message

5

Monday, March 1st 2021, 12:31pm

Quoted from "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
Your own professional, online cloud tool for creating virtual tours - www.cms4vr.com

facebook page :: youtube

cms4vr team *thumbsup*

jeromebg

Professional

Posts: 1,100

Location: Angers - France

Occupation: 360 experiences creator

  • Send private message

6

Monday, March 1st 2021, 2:01pm

Luis Erantzcani

Intermediate

  • "Luis Erantzcani" started this thread

Posts: 248

Location: Mexico City

Occupation: Virtual tours, Krpano coding, Graphic Design, Photographer, Panographer

  • Send private message

7

Monday, March 1st 2021, 2:47pm

Hello Piotr, you're missing the point, I mean about adding language support in the way I propose.

Best

Quoted from "spacerywirtualne"

Quoted from "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.


Piot'
imagen360.com / skyvr.mx
facebook.com/Erantzcani360
facebook.com/skyvrmx

Luis Erantzcani

Intermediate

  • "Luis Erantzcani" started this thread

Posts: 248

Location: Mexico City

Occupation: Virtual tours, Krpano coding, Graphic Design, Photographer, Panographer

  • Send private message

8

Monday, March 1st 2021, 2:52pm

Quoted from "jeromebg"

https://krpano.com/forum/wbb/index.php?p…rlang#post44674
Yes, but my discussion point here is not on how to do it but about finding better ways to integrate it to krpano other than what's already available.

Best
imagen360.com / skyvr.mx
facebook.com/Erantzcani360
facebook.com/skyvrmx

indexofrefraction

Professional

Posts: 1,241

  • Send private message

9

Tuesday, March 2nd 2021, 9:55am

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)
zFilter plugin -- zFlare plugin -- zSnapshot plugin

This post has been edited 3 times, last edit by "indexofrefraction" (Mar 2nd 2021, 10:27am)

Luis Erantzcani

Intermediate

  • "Luis Erantzcani" started this thread

Posts: 248

Location: Mexico City

Occupation: Virtual tours, Krpano coding, Graphic Design, Photographer, Panographer

  • Send private message

10

Tuesday, March 2nd 2021, 4:23pm

Yes, adding it as a higher level sounds like some change in the way we do it, right?, but I think it can be useful and straight forward for coding multilanguage and in the end doesn't conflict with any of the methods already used by community (just leaving lang="null").

As I mentioned currently we're basically coding turnarounds to this (specifying language "inline" and using actions to configure it dynamically, basically more codelines) so why not to have it supported by the viewer?



Anyway, this are just some thoughts I wanted to share, I'd be glad if they can help but if not it's ok. Klaus, there's all this posts above so you decide if this makes some sense or not. ;-)


Best
imagen360.com / skyvr.mx
facebook.com/Erantzcani360
facebook.com/skyvrmx

klaus.krpano

Administrator

Posts: 13,244

  • Send private message

11

Tuesday, March 2nd 2021, 5:12pm

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:

Source code

 
1

html.en="[h1]Welcome![/h1]" html.es="[h1]¡Bienvenido![/h1]"

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.

Source code

 
1
2
3
4

<translations name="en" title="Hello" ... />
<translations name="de" title="Hallo" ... />
...
html="get:translations[get(language)].title"


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:

Source code

 
1
2
3
4

<include url="translations_en.xml" if="language == 'en'" />
<include url="translations_de.xml" if="language == 'de'" />
...
html="get:translations.title"



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:

Source code

 
1
2
3
4

html.lang.en="Hello"
html.lang.de="Hallo"
url.lang.en="english.png"
url.lang.de="german.png"


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

indexofrefraction

Professional

Posts: 1,241

  • Send private message

12

Tuesday, March 2nd 2021, 6:01pm

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
zFilter plugin -- zFlare plugin -- zSnapshot plugin

This post has been edited 5 times, last edit by "indexofrefraction" (Mar 3rd 2021, 8:09am)

Luis Erantzcani

Intermediate

  • "Luis Erantzcani" started this thread

Posts: 248

Location: Mexico City

Occupation: Virtual tours, Krpano coding, Graphic Design, Photographer, Panographer

  • Send private message

13

Saturday, March 27th 2021, 9:03pm

Sorry people, last weeks have been such a rush of work I had to disconnect.

Klaus, thanks for your open mind to new ways to improve Krpano, that's exactly what I think had taken your viewer to the place is now.

I came to create this post as the way of thinking I've adopted for some time in krpano is like "This would be the easiest simplest way to code it" then find ways to make it possible. Generally I can handle everything by myself or by posts on the forum but in this case this required higher support so I thought about sharing this view here.

As I mention I think a "special placeholder" would be the best easiest way for multilanguage, just set it for attributes/elements and that's it. Any tour, no matter how complex it's structure could be easily taken to many languages. Main issue with this is dynamical config, that's it . I agree with your example below, I see we definitely have to have another variable/dimension added to attributes/layers that could sort the parser and be available for later dynamical actions:

Source code

 
1
2

html.lang.en="Hello" html.lang.de="Hallo"
url.lang.en="english.png" url.lang.de="german.png"


I get it would be interfering directly with style asignation so it would require deeper modification of the viewer and parsing process, though, this may open new paths for other funcionalities as well? Surely you have other priorities of development but now you have this in mind in case you see this is worth to explore further.

I know all people in this post are perfectly capable of doing complex stuff (much beyond this) but let's not forget new people is arriving to community, and I think the lower the entry barrier to adopt krpano the better impact will have on overall adoption growth.

Cheers!

Luis *thumbsup*
imagen360.com / skyvr.mx
facebook.com/Erantzcani360
facebook.com/skyvrmx

panomaster

Intermediate

Posts: 295

Location: Kobyłka, Poland

Occupation: Virtual Tours - Spherical Panoramas - Krpano developer

  • Send private message

14

Tuesday, March 30th 2021, 3:32am

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.
Leszek Cuper
Panoramy 360
Wirtualne spacery

This post has been edited 2 times, last edit by "panomaster" (Mar 30th 2021, 8:47pm)

lerayfle

Beginner

Posts: 46

  • Send private message

15

Thursday, September 9th 2021, 9:46am

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

This post has been edited 1 times, last edit by "lerayfle" (Sep 9th 2021, 10:09am)

Similar threads