Add proper way to translate all occurring strings via dictionary

[DanielBiegler]

Hey @mpetroff !

I implemented translatable strings. I already provided full translation in german and russian!

I personally tested it and played around with it. It defaults to english if no language is set.

One can setup the language via the field "languageCode" inside the config or via URL parameter when using the standalone version. A list of the ISO 639-1 codes can be seen here.

One thing though: I - for now - ignored the strings inside the standalone.js. I'd like to handle this as follow up commits after your feedback. How would you implement that there? At the point of URL parameter parsing, the languageCode could come after an error occurs. Printing english first and switching language midway, after the languageCode is set, is easily doable but could look messy and or unprofessional.

---

I asked myself whether there should be checks inside of pannellum when the user types in an unsupported languageCode like "abc"? That results in strings saying 'undefined' and thats just ugly. I think the user is responsible for writing in a proper languageCode though. Whats your take on this?

I thought about 2 different ways one could structure the dictionary.

1. Constant name first, language code second

"ERROR_INVALID_IMG_TYPE": {
        "de": "Error: Falscher Bild-Typ angegeben!",
        "en": "Error: invalid image type specified!",
        "ru": "Ошибка: неправильный тип Изображение!"
    }

2. language code first, constant name second

"de": {
    "ERROR_INVALID_IMG_TYPE": "Error: Falscher Bild-Typ angegeben!"
    },
"en": {
    "ERROR_INVALID_IMG_TYPE": "Error: invalid image type specified!"
    },
"ru": {
    "ERROR_INVALID_IMG_TYPE": "Ошибка: неправильный тип Изображение!"
    }

As you can see in the commits, I chose the first option because I think it is cleaner, easier to translate when you see other languages side by side, you can search properly for the constant-name via ctrl+f and the file is generally kept smaller because you dont have to repeat the constants all the time.

And lastly, are you concerned about language-bloat? What happens if people start translating in multiple languages and the dictionary becoming huge. Let's assume french, chinese, japanese, korean, polish, dutch, ... - this would become pretty big after a while. Your thoughts?

---

This is my first pull request, I would really like to contribute. Feedback is much, much appreciated!

Best regards,
Daniel.

[MrUpsidown]

Good idea. If this gets merged, I will provide French translations! Cheers

[strarsis]

Providing the dictionary as JSON file per language maybe?

[DanielBiegler]

@strarsis while that being possible, I think the added complexity might not be worth it. Right now sites can just copy pannellum.js and pannellum.css and be done with it. Thats pretty neat and appealing imo. If my site would like to support 3 or more languages I'd have to include pannellum.css, pannellum.js (which would include english), pannellum_german.json, pannellum_french.json, ... and maybe to make it cleaner I'd need a new folder for holding the languages. On top of the file complexity, we'd have to manage making requests from inside pannellum.js to get the appropriate files, handling errors, ...

This is all not that complicated and could be done, sure.

I'm not sure if this outweighs having a slightly larger file. (Which would get cached anyway)

One more possibility would be to provide an API for specifying the dictionary yourself inside your config.json. That does seem unclean to me though.

I'm curious about @mpetroff s opinion on this.

[mpetroff]

I think the approach taken here is fairly optimal for providing a set of default translations (except for the minor implementation detail of breaking encapsulation). However, since I don't want to be responsible for maintaining a set of translations, I don't want to take this approach.

Due to this pull request and other recent interest in translation support, I implemented it as a configuration dictionary in 93f3df1. There's now a strings configuration parameter that can be used to change all of the user-facing strings. See the defaultConfig.strings definition in pannellum.js for details of the configurable strings. While not as clean a solution if only translations are considered, it does not require me to maintain a set of translations and allows for more flexibility, as strings can be changed for reasons besides translation (or obscure languages can be used). Obviously, including translations in every configuration is tedious. Thus, I plan on adding a way to load an additional configuration file to include defaults such as this; I opened #487 to track this.

I'm open to feedback and suggested improvements for the changes I just made.

Although I'm not going to merge it, I appreciate the pull request nonetheless. Thanks.

[DanielBiegler]

Sad to see this, because I personally much prefer a central, maintained location for translated strings. That would make Pannellum more attractive because "it just works out of the box".

Now there will be collectively so much time waste when multiple people start translating the same languages locally and everyone ending up with a slightly different version.

If I see a bad translation for my native language, as a user, how do I know that the dev is at fault and not Pannellum just being "bad"? That right there leaves a bad taste in my mouth. If I, as a user, see a different Panorama viewer that has correct text, then this has to be "better", right? I know not everyone thinks that but some will sure do.

While I can totally understand you not wanting to maintain a big dictionary, I do believe that the overall quality suffers now.

As a dev I don't want to deal with translation, that's a boring and tedious task. I want to implement functionality. So now with this change I have to either translate it myself, look for a third party that translates it for me, or find some unconfirmed source that may or may not be correct.

Making an extra request for an extraconfig that just includes stuff that should be baked in (imo) just seems unclean to me.

So I personally dislike this approach. Maybe it's just me though, if more people could weigh in on this, that'd be great.

What I do like however, are the format strings. This way, cleaner and more complex messages are possible. +1 on that.

Best regards,
Daniel.

[strarsis]

@DanielBiegler: You could create a new GitHub repo "pannellum-translation" and fill it with translations over time. This could also be announced as official translation source by @mpetroff.

[mpetroff]

If I see a bad translation for my native language, as a user, how do I know that the dev is at fault and not Pannellum just being "bad"?

For all languages I don't speak fluently, I have no way of knowing whether or not a submitted translation is good, so I don't think having a centralized set of translations fixes this.

As a dev I don't want to deal with translation, that's a boring and tedious task. I want to implement functionality.

I agree with this completely, just as a library developer instead of a library user. As it is, I spend more time providing support for Pannellum than I do actual development.

[DanielBiegler]

Mh, alright. I see you've made your decision, that's OK.

Would you be willing to link to a third party repository that tries to centralize translated strings like @strarsis proposed? I would be willing to maintain it.

I can personally vouch for the German and Russian version. For other translations I could get a third party through my university before I accept pull requests.

Tomorrow I have time to create the repo. Right now I'm on mobile.

Best regards,
Daniel.

[DanielBiegler]

By the way

As it is, I spend more time providing support for Pannellum than I do actual development.

I appreciate that very much. I always got answers on my issues and that feels good. Thank you.

[mpetroff]

I'm willing to add a link to a third party translation repository in the README.

[DanielBiegler]

OK. I will maintain it then. I will add the german and russian strings tomorrow! I'll post here again to let you know when it's done.

[DanielBiegler]

OK, @mpetroff the repo stands now. Have a look here. Feedback?

@MrUpsidown cheers.

[mpetroff]

I just added a link to it in 8c992e8.

It looks good, although my tendency would be to use IETF language tags instead of ISO 3166 country codes for the translation files, since languages don't necessary follow political boundaries (and the IETF tags are what are used for HTML).

[DanielBiegler]

Alright.

I'll add the IETF proposal as issue if someone wants to implement that. Cheers!