Typing around the world

A case study on why you should NEVER, EVER check in a last minute fix

Yesterday we released Keyman 7!  The excitement may have been somewhat overshadowed by a rather larger product release on the same day in the US, and ironically, an update to MSKLC was released on the same day.

I'm not writing about the new features etc etc - if you want to read about those, visit our website. 
I'm writing about the bugs.  Perhaps this is airing the dirty laundry but here goes anyway.

The day before release, our testers identified a couple of issues.

 

The first of these was purely cosmetic.  If a user had too many languages installed, the languages tab would not fill the available space but would leave about 100 pixels of whitespace at the bottom - see image.  This space was there because the User Interface Language button was moved from there to the Options page.

But for some silly reason, we decided to put in a fix.  So we put in a fix, tested it (well, obviously we didn't...  wait and see) and put the release online with only one minor issue - the Configuration dialog now did not work at *all*:

Fortunately, that was only online for a couple of minutes before we took it down - and rolled the changes back.  The second issue was more significant.  Pressing ENTER in the Activation dialog (as opposed to clicking the Activate button with the mouse) would open a Windows Explorer window instead of processing the activation:

We quickly put in a fix for this - and broke the Activate button.

Last minute fixes:

• Are done in a reckless state of mind brought on by the euphoria of impending release
• Never get tested properly
• Do not get proper attention to design and potential side-effects

The moral of the story is: NEVER, EVER do a last minute fix.  If a fix is important enough to do at the last minute, it is important enough to delay the release by a full test cycle...

Translating the Keyman Desktop UI

The Keyman Desktop 7.0 Beta 2 UI is now both customizable and localizable.  Localization of the user interface is possible via editing a single XML file called locale.xml.

The default locale.xml file is in the folder

[Program Files]\Tavultesoft\Keyman Desktop Professional 7.0\xml\

First steps to creating a translation

1. Find the language code for your translation
   

   Use the ISO 639-2 or ISO 639-3 language code (we recommend using the ISO 639-3 codes as many Keyman keyboards support languages not included in ISO 639-2!).

2. Create a folder for the translated locale.xml file and copy the default locale.xml into it
   
   The folder should be called:
   
     [Program Files]\Tavultesoft\Keyman Desktop Professional 7.0\locale\langcode

File Format

The file format is straightforward - most strings have identifiers (e.g. SKButtonOK for the OK button).  The identifier of the string is the XML tag name.  We have three different types of strings in the file - plain, HTML and format strings.

• Format strings often include %#:s or %#:d markers that are placeholders for parameters, and should be included in a translated string.  The order of the markers in the translated string is not important.
• Plain strings must be just that - plain text.
• HTML strings can include tags - there are only a few of these, and they are flagged in the locale.xml file.  The most obvious of these is in the Welcome screen text.

The only exception is the strings on the tray menu, which do not have identifiers, but instead use the following format (note that the Caption attribute should not include the & entity):

    <Menu Caption="Keyman Configuration...">localized &amp;text...</Menu>

The &amp; entity is used to mark hotkeys in menu items, labels and buttons.  It can be used only with strings identified as formatted messages (these mostly start with SK) and with the Menu strings.

Editing the File

First, edit the file's language information - SKUILanguageName, SKUILanguageNameWithEnglish, and SKLanguageCode.

<!--   The name of the UI language, localized -->
<SKUILanguageName>English</SKUILanguageName>

<!--   Show the name of the UI language, localised, with English name in parentheses (this message is used when the user gets stuck in a strange UI language) -->
<SKUILanguageNameWithEnglish>English</SKUILanguageNameWithEnglish>

<!--   The language code for the current translation -->
<SKLanguageCode>en</SKLanguageCode>

Note that any entries missing from the translated locale.xml will be retrieved from the default file.

Editing other Files

If you find that you need to do more work on the user interface, you can always copy the other files from the default xml folder into an xml subfolder of your locale folder, and edit them directly.  Note that the XSL file for each dialog (e.g. activate.xsl, or keyman.xsl) references other files - these other files must also be copied to the locale xml folder:

  [Program Files]\Tavultesoft\Keyman Desktop Professional 7.0\locale\langcode\xml

The format of these files is somewhat more complex; I may talk about them in the future.  But feel free to play around and edit!

Finally...

The Keyman Developer user interface is also localizable (not 100% ready yet), but it primarily uses gettext, with a small amount of translatable XSLT.  We will include the gettext .pot template in the release of Keyman Developer.

The usual beta warning applies - these file formats are not necessarily 100% stable, and some changes may occur.  However, we expect only that more strings will be added to the final locale.xml, and we don't expect structural changes.

Character Map

I was editing a keyboard in Keyman Developer 6 today (European Latin) and after using the Character Map in version 6 for a few minutes started to hanker for the version 7 Character Map that I have been using for the last few weeks while preparing for Beta 1.   In the end I had to run over to the test desk and use the version 7 Character Map.  I wanted to use the filter feature - especially the ability to use the * wildcard - I searched for "latin*ligature" so I could find all the Latin ligatures.  No way to do that in version 6.

In the image above, you can see some of the characters are in grey rather than black.  This indicates characters missing from the selected font and instead of skipping them, uses a backup font, in this case Code2000.  The character map also uses font linking to try and get a fallback character where one is missing - unfortunately, font linking does not appear to work in the supplementary planes.  James Kass's Code200x fonts provide great fallback coverage for the Character Map, with only a few scripts (mostly newer ones for the Unicode standard) missing, so we will be including them with Keyman Developer.

Of course, we still need to support showing all the characters in a given font - which is currently broken in beta 1.

The filtering currently supports a single phrase, with * and ? (or % and _) wildcards.  Any SQL fans will recognise the LIKE wildcard terms there.  You can also use [ and ] but we haven't tested that yet!  I'm not sure how valuable more complex filtering support is.

The automatic 'follow' feature in Keyman Developer 6 (where the character map shows the character under the cursor) doesn't really work all that well.  I think that we will make it follow only when a hotkey is pressed in Keyman Developer 7.

One other Good Thing: the version 7 Character Map uses Unicode 5.0.

The Beta Process

We released the first beta of Keyman and Keyman Developer 7 on Friday and were very pleased by the number of people who asked to join the beta in the first day.  They have already created 15 issue reports of high quality which is very encouraging (Join the beta).

After publishing the beta first thing on Friday, we spent the rest of the morning tearing down the wall between our two new offices - found it quite a good way of bleeding off the stress of putting out the release!  We have no more walls we can take down so I am not quite sure what we will do after publishing beta 2.

 

Yes, this is my first blog entry.  I tend to find it hard to write down this kind of thing and I am hoping that an informal outlet will be a good place to do that.  I do have a lot of things I want to write about regarding Keyman, so that will hopefully keep me going for a while.