This week, I have got the Rocket library loading and correctly displaying menus with localization. This involved a considerable amount of work to get character sets, fonts, and the internal representation for locales to work correctly. There's still quite a bit of polishing to do, but I think I've identified the trouble spots and worked around them.
Obviously, we need Unicode fonts with very good coverage of character sets. For my test page, I used Google's "Noto" fonts, which are designed for maximal coverage with fairly consistent styles.
In some cases, we need to use different fonts for the same characters. For example, there is "traditional Chinese", preferred in Taiwan and "simplified Chinese", preferred in mainland China.
Since Rocket provides no way to allow one font to fall back to another for characters that aren't supported, we can't use a single font for a whole page with multiple languages on it. Instead, we specify languages at the XML element level, and get Rocket to select an appropriate font based on the language.
This was necessary to get Devanagari and Arabic locales to display along with the untranslated English original on my test page.
Two Types of Language Support
There are two different localization systems being demonstrated in this test. The first is player-based localization, in which the player provides the translation for known "labels". For example, the PLAY button at the top looks like this in the test menu file:
<a href="../media/feature.lrv"><h1 label="PLAY">Play</h1></a>
The "label" doesn't strictly translate the button at all, but just tells Lib-Ray what the label means. The player then provides the correct translation or else falls back to the original text ("Play").
This has some advantages:
- The volume author does not need to know or provide multiple languages.
- New languages added to the player will localize pre-existing releases.
- Different releases will use the same vocabulary for their functions, avoiding potential confusion for users.
And a few disadvantages:
- The volume author is limited to the available labels, or must use some that won't be translated.
- The problem of translation for labels lies with player developers.
- Can't be used for more sophisticated text than button labels.
My initial release includes 13 concept labels with 12 translations for each, into the "language system" languages (the theory being that most people in the world will understand at least one of these, even if it is not their native language): English, French, Portuguese, Spanish, Russian, German, Arabic, Swahili, Chinese, Japanese, Hindi, Indonesian (Malay). Future releases might include more concept labels.
I did make an effort to get correct in-context translations for each of the labels, but it's practically inevitable that I will have made errors. I'm hoping that native speakers will be able to provide improvements to these where needed. And of course, I'll be relying on submissions for additional languages.
The player will not attempt to translate more sophisticated text. Instead, the release author will have the option to provide alternate translations where needed.
The last button in the examples above is localized in this way. Translations were provided for English, French, Spanish, and Russian in the test page. So if one of those locales is used, then the appropriate text shows up, but if not, then the default text ("No Translation Provided") is presented, as you can see in some versions.
Here's what the full block looks like in the test menu:
<h2 lang="en">This is English.</h2>
<h2 lang="fr">Ceci est Français.</h2>
<h2 lang="es">Esto es Español.</h2>
<h2 lang="ru">Это русский.</h2>
<h3>No Translation Provided.</h3>
Roadmap to Release
The next few steps of development should get us to a minimally-functional player:
- Scan for 'href' attributes and assign callbacks (both the scan and callback assignment have been tested, so this shouldn't be hard at all).
- Parse and distinguish the different classes of URLs: other menu pages, extras pages, remote URL links, and player actions. This is a simple application of Python's 'urlparse' library.
- Spatial navigation for keyboard or remote-control support (i.e. pushing the "left" arrow will go to the button that is presented to the left of the currently-focused button -- this sounds really trivial but is actually kind of tricky to implement).
- Write an outer loop to scan for and load Lib-Ray volumes when they are inserted.
- Implement infrared remote control support via LiRC/PyLiRC.
Seems simple enough.
I hope it goes quickly. After that and a bit of polishing, we should have a minimally functional Lib-Ray player, and I can focus on the other parts of the Kickstarter delivery: in particular documentation, mastering the test releases, and fulfilling rewards for backers.
After that, I'll continue with extended goals:
- A wizard to aid in creating Lib-Ray volumes.
- Creating an "archive" or "library" mode to browse Lib-Ray titles.
- Packaging the software to simplify installation.
- Creating an inexpensive embedded player.
Right now, I can't see any reason why this should take more than a month to get to the player software release, or more than a few months to finish the whole project, but I've been very wrong before, so I'll try to just stick to reporting what's done.