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:

    Code
    <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:

    Code
    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:

    Code
    html.en="[h1]Welcome![/h1]" html.es="[h1]¡Bienvenido![/h1]"
    Code
    <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*

  • 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*

  • Code
    <data name="body_text_es">...</data> <data name="body_text_en">...</data>
    Code
    set(lang, es);
    get(data[calc('body_text_'+lang)].content)


    or

    Code
    <data name="body_text" lang="es">...</data> <data name="body_text" lang="en">...</data>
    Code
    set(lang, en);
     for(set(i,0), i LT data.count, inc(i), 
      if(data[get(i)].lang == lang,
       // english data
      );
     );


    Piotr

  • 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. *wink*

  • 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

  • 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. *wink*


    Best

  • 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:

    Code
    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.

    Code
    <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:

    Code
    <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:

    Code
    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

  • 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

  • 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:

    Code
    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*

  • 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 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



    Einmal editiert, zuletzt von lerayfle (9. September 2021 um 10:09)

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!