Recommendations for Multilingual welcome.htm?


I was just trying out keyman desktop on OSX (really cool BTW!) and the keyboard help file launched by the (?) icon got me thinking about how best to support two languages. The help file displayed was the contents of the welcome.htm , and was in English. I would like to add another language and thought I should check if there is already a convention for doing so?

My thought is to have the welcome.htm present two languages using tabs, where the foreground tab is in the keyboard language and English is obscured. Clicking on the English tab it comes to the foreground and the other language is now out of view. This takes a small amount of CSS and JS to work -are there any limitations in support for CSS+JS in the various ways the welcome.htm is presented (Windows, OSX, Android, iOS, etc. particularly in non-web browsers)?

At worst, we could simply have one language follow the other and the user gets internal hyperlinks to jump to their preferred language. Any advice appreciated.

For reference, here’s two multilingual welcome.htm files from external keyboard developers
(the content for the .php files come from welcome.htm)

Line by line

Separate paragraphs

While there’s historical documentation about localizing welcome.htm, currently the mobile apps will only display welcome.htm when installing the keyboard packages.

@darcy, you may want to look at the bidi support in the arabic_izza help file.

@dyacob, I have been thinking about bilingual help. The the dvsp example makes sense for the php help files, but for the welcome.htm files I’d be inclined to default to the language of the average user first, then English as a fall-back. I would add a simple language switcher that toggle visibility of each language. The language of the keysin the 8mage may be better in the target language.

But since you use a mnemonic rather than a positional layout, the approach I use for generating the images may not work for you.


I am planning to revisit this in 11.0 with a whole-of-product internationalization check. The currently accepted model is rubbery. In theory we have support for welcome-<bcp47>.htm for documentation but support is spotty. So everyone does their own thing.

Long term, I think that we will go with a pattern of welcome.<bcp47>.html as this matches what other apps tend to do. Similarly, readme.<bcp47>.html. Then the UI will present the additional language options. (Disclaimer: this is forward looking blah blah blah)

This goes along with a bunch of other issues for language selection. One of the weird challenges with Keyman is that there are two places for language selection – keyboard, and user interface. No matter how we designed it, we always ended up with users trying to choose their keyboard in the UI language menu, and vice-versa… This is kinda unique to our situation :slight_smile: