Hotel MSSNGR is a multi-language tool, which means that you can offer content to your guests in any language you want. However, due to technical reasons, there are different types of languages a guest will encounter:

This is the language of the guest's device, either the system setting of their iOS or Android device, or the language their browser is set to if they are using the web app.

When guests first open the MSSNGR App or the website, MSSNGR will automatically detect the best fitting language option and show the content in this language.

In the Admin Area, you can add as many content languages as you need to, ideally, you'll offer all languages you're expecting your guests to speak.

You can add languages in the Hotel settings > General area as an Admin and can then switch languages easily on any content page:

Some bits of text cannot be set by you but are preset by the system. This includes error messages, generic help texts, date formats, and some chrome items in the Apps and website. We aim to make as many of these items configurable from the Admin area (for example booking buttons, feature naming, form fields, etc.), but some items need to be fixed.

For these items, we only offer a subset of languages, e.g. Croatian, English, French, German, Italian, Portuguese, Spanish, and Turkish.

In addition, some texts are provided by the system in the operating system language (like permission requests and warnings), these will be shown in the language the operating system provides.

As mentioned before, the system will automatically determine the best fitting language, and if none can be found, a sensible fallback.

Let's pretend you have a hotel that has German, Polish and English content set, with English as a fallback, here is an example of what a guest will see:

So, for German, it's obvious: As both App and content language exist in German, everything is provided in German. For Italian, we offer an Italian App translation, but no content, so some chrome parts and error messages will be in Italian, but the Rest in English. For Polish, we don't offer an App translation, so the chrome will be in English, but the content is in Polish. For Dutch, we don't offer any localization, so everything will be in the fallback language English. Some parts of the DS (the weather app for instance) will also fall back on the most sensible language as this information is not locally generated.

*On some systems, the user may change the order of the system fallback languages, meaning that the fallback of the App language could actually be a different fallback than English.

When guests enter a hotel, they can switch languages in the settings (native Apps) or with the world symbol (Web App). The system will offer all content languages supported by the current hotel. When selecting a language, the client language is switched, meaning the whole fallback logic is applied as shown in the table above.

So, if in our example, a guest would switch from German (the client language) to Polish, they'd see Polish content and English chrome.

Attention: If they now would switch to a hotel with German and English content, they'd see everything in English, as the system now treats Polish as their client language. They could now switch back to German in the settings again.