Typing around the world

Keyman Desktop 8.0.332.0 Beta Release

Keyman Desktop 8.0.332.0 is being released today as a Beta version.  This release addresses two reported issues with Keyman Desktop:

• Keyman Desktop 8.0 is not working with legacy applications that require WM_UNICHAR for Unicode input (regression from 7.1)

This affects a number of legacy applications, as well as programs that use the RichEdit control in a non-Unicode mode.  Basically, Keyman Desktop 8.0 would recognise that the program did not support Unicode input, but would then not switch into its legacy support mode.  If you have not experienced this problem, then you do not need to upgrade at this stage.

Applications known to be affected by this problem: Paratext 6.

• If a non-Latin script keyboard or IME is the default input method for Windows, then Keyman Desktop keyboard layouts may not operate correctly 

This issue had two primary symptoms:

1. If using mnemonic layouts, then the non-Latin script base keyboard would mean that no mnemonic layouts would operate, as the basic A-Z Latin script letters would be missing.
2. If the base layout was an IME (e.g. Japanese, Amharic, Korean, Chinese), then some hotkeys could interfere with the operation of any Keyman Desktop keyboard.

The fix now identifies the base keyboard script, and if it is a non-Latin base keyboard, will use US English as the base keyboard for Keyman Desktop keyboards to avoid this issue.

This release can be downloaded from http://www.tavultesoft.com/beta/

Keyman 8.1 Keyboard Language Proposal: Extensions to Keyboard Options

Introduction

Keyboard options were introduced in Keyman Desktop 8.0 in response to a common issue – many keyboard packages include multiple keyboards to cater for minor configuration changes. For instance a Tigrigna package has both Eritrean and Ethiopian keyboard layouts, with only a single character difference – the question mark symbol which differs between the two countries. Or Greek keyboards which differ in how the diacritics are typed.

With keyboard options, the keyboard developer can present the user with a dialog box to let them choose how they wish to use the keyboard. This is both less confusing and more flexible than having multiple keyboards.

Now when reviewing this feature a couple of weeks ago, we realized that with some small tweaks, it would become even more useful.

Proposed New Features

Three small updates to the keyboard options feature are proposed:

• Testing for base layout. This would enable you to have rules conditional for a French base layout, for example. This, combined with the improvements to mnemonic layouts in Keyman Desktop 8.0, should make it possible to cater for all European base layouts with a single keyboard.
• Allowing for On Screen Keyboard-specific rules. This would back up the functionality described in my previous blog post Keyman 8.1 Keyboard Language Proposal: Dynamic On Screen Keyboard and make the dynamic on screen keyboard more flexible.
• Add feedback on option changes via bubble and icon. While this needn't be limited to notification of option changes, some sort of feedback is really pretty essential for keyboard options to be most useful.

Testing for Base Layout

The test for base layout could be implemented with a special system store, for example:

if(&baselayout = 'FR') + 'q' > 'that key next to Caps Lock'
if(&baselayout = 'EN-US') + 'q' > 'that key next to Tab'

Determining how to identify the base layout has not yet been discussed.

Testing for On Screen Keyboard-specific rules

Again, this could be implemented with a special system store. In the following example, the 'Q' key would always show with a capital Q, even though the output would be lower case:

if(&osk = '1') + 'q' > 'Q'
if(&osk = '0') + 'q' > 'q' c not technically necessary but shown for completeness

Giving feedback via balloon or icon change

The details of how additional icons could be stored in the keyboard (and the preferred image formats) are not settled. However, in principle it could work as per this example:

store(happy-face-icon) "happy-face.png"
store(happy-message) "Keyman is now happy"
store(sad-face-icon) "sad-face.png"
store(sad-message) "Keyman is now sad"

store(sad-option) "0"

+ 'a' > seticon(happy-face-icon) showhint(happy-message) set(sad-option='0')
+ 'b' > seticon(sad-face-icon) showhint(sad-message) set(sad-option='1')

Determining the icon to use when the keyboard is initially selected would also need to be covered. At this stage, it is not anticipated that the icon would change in the menus or in the configuration screens, but feel free to ask for this – now's a good time to ask!

Keyman 8.1 Keyboard Language Proposal: Dynamic On Screen Keyboard

Introduction

Keyman 8.0 improved mnemonic keyboards by remapping the On Screen Keyboard to the underlying hardware layout. Previous versions of Keyman did not do this well. This has been a big improvement and makes mnemonic keyboards much more useful with European hardware layouts.

However, apart from this one change, we had to postpone some of the design features that we wanted to add to the On Screen Keyboard. A couple of weeks ago we had a great discussion on how we could improve the On Screen Keyboard by making it more dynamic. While dynamic updates to the keyboard have been on the future feature list for some time, details of how this could work had never been properly explored.

We also linked this discussion to some tweaks to the keyboard options feature introduced in Keyman Desktop 8.0. These were tweaks primarily around testing for base layouts and providing feedback to users when options are selected. The extensions to keyboard options have some relationship to a dynamic On Screen Keyboard but will be expanded on further in a separate blog.

Dynamic On Screen Keyboard

The big breakthrough we made in our discussion was in how we could instruct the On Screen Keyboard to dynamically update. Initially we just thought we could use the existing rules in the keyboard source code to tell the keyboard how to dynamically update. This seemed logical, but the more we looked at it, the more we realised that this would end up being confusing for the end user. There were a few reasons:

1. Keyman Desktop keyboard rules have to deal not only with basic mapping but also with character reordering and normalisation. These rules would probably be confusing when displayed on the keys.
2. Some rules make changes to multiple characters in the context but displaying the full output would not be helpful to the end user.
3. Some rules may input an invisible character but the On Screen Keyboard should instead show a hint for that letter

So we came up with the idea of a new begin statement to cater for the On Screen Keyboard (OSK). This could point to the same group as the normal begin unicode statement, or to a separate group designed to update the On Screen Keyboard. This group could use all the same context matching and finesse that the normal groups could, but the output would only be going to the On Screen Keyboard. So one trick to remember is that the output of the On Screen Keyboard rules will not affect the context for the next keystroke. The new OSK begin rule would be written as follows:

begin OSK > use(osk)

group(osk) using keys

The processing of any groups fired by the begin OSK statement have an important nuance: every matching context rule will be processed in order to render the On Screen Keyboard, for each keystroke. This means that effectively the On Screen Keyboard would run the group 47 or 48 times when updating. This shouldn't have a significant performance cost on computers today. If no rule matches for a given key, then Keyman would render the default output based on either the underlying layout or the US base key (depending on whether the keyboard is mnemonic or positional).

Keeping this in mind, we realised that colour, highlighting, graphics and font hints could be added to the output with a few additional simple statements. These additional formatting hints would be ignored by the keystroke processor, and would just be used by the On Screen Keyboard engine.

• bg(colour | default), or background(colour | default)
  
  This would set the background colour for the whole key. The last colour set in the execution of the statements would be the one that would take effect. The colour reference will probably be either a #rrggbb triplet or a standard web colour name.
  
  
• bg(colour | default), or background(colour | default)
  
  This would set the foreground colour for the subsequent letters to be printed on the key cap. In some scenarios, for example with combining diacritics, this may not be possible, and needs to be investigated.
  
  
• font(name, size, style)
  
  There are some issues with specifying the size due to the resizeability of the on screen keyboard. It may be specified as a percentage of default size.
  
  
• image(source-image)
  
  Source-image would refer to a store name which would then cause the image to be embedded in the keyboard file for use in the On Screen Keyboard. Suggested file format would be PNG to allow for alpha transparency. There are issues about sizing and mixing images and text that would need to be resolved.
  
  
• hint(text)
  
  If the user hovered the mouse cursor over the key, the hint text would be displayed in a balloon. There may be some visual indication on the key of the availability of a hint.

As there may no longer be a static On Screen Keyboard, we may need to specify font and other preferences such as 101 or 102 key layout as well. This is also a topic for further discussion.

Example Dynamic On Screen Keyboard Source File

The following straightforward keyboard will be used as an example of how we envisage dynamic on screen keyboards working.

store(&VERSION) '8.0'
store(&NAME) 'Dynamic OSK Example'

begin Unicode > use(main)
begin OSK > use(main)

store(vowel) 'aeiouAEIOU'
store(diaK) "`" "[" "]" ";" "'" "."
store(diaO) U+0300 U+030F U+030B U+0308 U+0301 U+0307
store(ZWNJ) U+200C

group(main) using keys

+ any(diaK) > $ZWNJ index(diaO, 1)

$ZWNJ any(diaO) + any(vowel) > index(vowel, 3) context(2)

c nomatch -> use default output

For simplicity in this example I have not tried to use any pre-composed letters but just left the combining diacritics in place. You'll note that we are using the same rule set for the Unicode rules as for the OSK rules, despite the discussion above. This is because this example is demonstrating the concepts rather than being a comprehensive and complete keyboard layout.

Given the keyboard source above, the Dynamic On Screen Keyboard would display initially as the image below. There isn't anything extraordinary there. The key difference is that there is no static definition for the On Screen Keyboard; rather, Keyman uses the begin OSK statement to define the display of the On Screen Keyboard. Deadkeys (as per the dk(diac) statements) would not be highlighted in any way on the On Screen Keyboard by default. This is because the deadkey statement in Keyman keyboards tends to be used for state management and not purely as a deadkey flags.

Let's look at how the keyboard could be modified to highlight deadkeys. The formatting hints given the example above would be ignored by Keyman Engine for keystroke processing, so let's keep the rules together for now.

store(&VERSION) '8.0'
store(&NAME) 'Dynamic OSK Example'

begin Unicode > use(main)
begin OSK > use(main)

store(vowel) 'aeiouAEIOU'
store(diaK) "`" "[" "]" ";" "'" "."
store(diaO) U+0300 U+030F U+030B U+0308 U+0301 U+0307
store(ZWNJ) U+200C

group(main) using keys

+ any(diaK) > $ZWNJ index(diaO, 1) bg(yellow)

$ZWNJ any(diaO) + any(vowel) > index(vowel, 3) context(2)

c nomatch -> use default output

Now with an empty context the keyboard would display something like the following mockup:

Finally, let's tweak the keyboard to make the dynamic keys with context highlighted so they are more visible. I'm not going to make the example comprehensive – it'll only cover the grave accent key.

store(&VERSION) '8.0'
store(&NAME) 'Dynamic OSK Example'

begin Unicode > use(main)
begin OSK > use(main)

store(vowel) 'aeiouAEIOU'

store(diaK) "`" "[" "]" ";" "'" "."
store(diaO) U+0300 U+030F U+030B U+0308 U+0301 U+0307
store(ZWNJ) U+200C

group(main) using keys

+ any(diaK) > $ZWNJ index(diaO, 1) bg(yellow)

$ZWNJ any(diaO) + any(vowel) > index(vowel, 3) context(2) bg(yellow)

$ZWNJ U+0300 + '`' > '`' bg(green)
$ZWNJ U+0300 + any(diaK) > context(1) index(diaO, 3) bg(grey)

c nomatch -> use default output

This would render as per the following example.

Conclusion

The concepts outlined here present a simple model of how on screen keyboards could give feedback to the end user and help make keyboards more self-documenting. I'd be very interested in any feedback or suggestions you may have – just put them in a comment on the blog.

In the next blog post, I'll discuss how the tweaks to options we discussed can also be used for integration of the On Screen Keyboard.

Updated 23 Aug 2011: In examples, replaced any(diaK) with any(diaO) in context, and replaced deadkey usage with ZWNJ to avoid side-effects with typing diacritic after another letter.

Designing the new Tavultesoft home page

As part of the Keyman Desktop 8.0 release work, we needed to give the Tavultesoft website some attention: the pages were looking dated, and the content had grown over time and was getting out of control. The Tavultesoft website has thousands of pages of content, and finding the right content was becoming increasingly difficult.

This blog is a description of how we redesigned the home page. The new home page will be going live soon, and we'll be doing some more testing once it has gone live, with you, our users!

Here's the existing home page:

First we brainstormed what we want to communicate on the home page.  This gave us 5 key groupings for content:

1. Confidence: Quality, you can trust us
2. Information: Who we are, what we do
3. Call to action: Download, buy, contact, learn more
4. Currency: News, we are still alive
5. Blather: Copyright, navigation, other necessary evils

We also quickly went through how someone could end up at this page.  This is not a comprehensive list but just to get us thinking about what the purpose of the page is.

1. "Tavultesoft" or "Keyman" search – word of mouth or existing knowledge
2. "Tamil Keyboard" – i.e. type in a specific language, looking for a solution for their language.
3. Links from other sites (word of mouth)
4. "Create a keyboard": Developer
5. "Type online": KeymanWeb.

We realized that the core role of the home page is really confirmation: yes, I'm in the right place, this is where I want to be.  So the messages and content need to be structured around communicating that message and moving the user onto their final destination as quickly as possible.

Then we took the existing home page and broke it down as best we could into those areas. 

Here's a key to the colours in the diagram:

Red – Confidence

Orange – Information

Green – Call to action

Blue – Currency (news)

Black – Blather

This helped us to see the following, among other things:

1. We had no clear call to action anywhere on the page.
2. Messages and actions are hopelessly muddled in the key areas of the page – the product information areas. What's more, it was not clear that any of the key product links were clickable.
3. We have a big emphasis on trust and confidence – all the red areas in the graphic above.

We then scored each area subjectively.  This was a muddled value about how effective we think the area is, and also how attractive.  This was really quick and just to give us a quick picture of what we react to on the page.  This is not a number that indicates how important the item is!

It was a bit embarrassing to realize that the links for the products scored so poorly in our subjective review.

Now it was time to throw away the old and brainstorm the new.  Armed with the ideas of what is important to communicate, we came up with the following wireframe:

We spent more time designing the Keyman Desktop, KeymanWeb and Keyman Developer sections.  Under those three boxes goes Testimonials and Customer Logos on the left, and News and Community Links on the right.

We were not sure what graphic to use for the Keyman Desktop box.  We could have a screenshot of Keyman, a happy user photo, or a graphic – e.g. a map, or some conglomeration of Unicode characters.

A lot of this seems obvious in hindsight.  But it often seems to take a lot of work to get there!

You'll note the video link is not included at present – because it needs to be reworked for Keyman Desktop 8 and I think we'll be too busy on everything else to get it done for release.  We'll work on the video post-release.

We have also redesigned the banner at the top and the navigation for the site, as you'll see in the image below.

And here's what we have come up with for the final page (note, the footer is not finalized).

What do you think?

Keyman Desktop 8.0 Default Options

Today we had a meeting to finalise the default options for Keyman Desktop 8.0, and determine how we would migrate option settings when upgrading from earlier versions of Keyman Desktop. For those of you who are interested, I reproduce the table below. Any comments or suggestions are always welcomed!

Option	Clean Install	Upgrade from 6/7	Upgrade from 8
Toggle Hotkeys	Yes	Migrate	Preserve
AltGr Simulation	No	Migrate	Preserve
Show hint messages	Yes	Migrate	Preserve
Universal Keyboard Switch	Yes	Yes	Preserve
Startup
Start with Windows 1	Yes	Migrate	Preserve
Show Start Screen	Yes	Yes	Preserve
Show Welcome Screen	Deleted
Auto Update Check 1	Yes	Migrate	Preserve
Conflicting App Check	Yes	Migrate	Preserve
On Screen Keyboard
Release modifiers after key	No	Migrate	Preserve
Always show OSK when keyboard selected	No	No	Preserve
Switch to OSK/Usage auto	Yes	Migrate | Yes	Preserve
Show OSK on startup	Yes	Yes	Preserve
Advanced
Supplementary Chars	No	Migrate	Preserve
Enable Unknown Language	Deleted
Debugging	No	No	Preserve
Switch Win lang with kbd	Yes	Yes	Preserve
Uniscribe Manager	No	Migrate	Preserve
Hotkeys
Switch keyboard off	Alt+Shift+O	Migrate | Alt+Shift+O 2	Preserve
Open Keyboard Menu	Alt+Shift+M	Migrate | Alt+Shift+M 2	Preserve
Open Switch Lang Window	Alt + Left Shift	Alt + Left Shift	Preserve
Show On Screen Keyboard	Alt+Shift+K	Migrate | Alt+Shift+K 2	Preserve
Show Usage	-	-	Preserve
Show Font Helper	-	-	Preserve
Show Character Map	-	-	Preserve
Open Text Editor	-	-	Preserve
Open Configuration	-	-	Preserve

 

¹ These options are configurable via the bootstrap installer – the default in the installer will be read from the existing installation settings for the currently logged-in user.

² The intent for the hotkeys when upgrading from version 6 or 7 is to set the default hotkeys as per the table, unless another hotkey has already been configured by the user.

Notes: Migrate means copy the setting from the previous version settings; Preserve means keep the setting that is currently configured. Where a previous version does not have a specific option (e.g. Uniscribe Manager was introduced in 7.1, so an upgrade from 7.0 would not have a setting for the Uniscribe Manager), the default is copied from the "Clean Install" option.

We have had to switch on comment moderation due to an unwelcome influx of comment spam – rest assured we will publish any comments that are relevant to the posts as quickly as we can – we are not trying to censor your views on Keyman Desktop!

Adobe Reader X’s Sandbox and Keyman Desktop

Adobe recently released a secured version of Reader which includes a new security feature called sandboxing. A sandbox restricts the privileges of the PDF viewer built into Adobe Reader to access computer resources, which in turn helps to reduce the impact of as-yet undiscovered security flaws in the PDF viewer, because when these security flaws get exploited, the exploit is much less able to attack the system it is running on. This is a fantastic effort by Adobe and in theory at least makes reading PDFs in Adobe Reader much safer.

Adobe have written a couple of technical blogs about the Reader sandbox design at http://blogs.adobe.com/asset/2010/10/inside-adobe-reader-protected-mode-part-1-design.html and http://blogs.adobe.com/asset/2010/10/inside-adobe-reader-protected-mode-%e2%80%93-part-2-%e2%80%93-the-sandbox-process.html More information is also available at http://learn.adobe.com/wiki/display/security/Protected+Mode+FAQ

Unfortunately, the release of Adobe Reader X exposed a bug in Keyman Desktop when interacting with sandboxed processes. Interestingly, Chrome and Office 2010 include similar sandboxes but they did not trigger the flaw in Keyman Desktop. In December 2010, we started receiving reports of a crash that initially did not make any sense to us at all: Keyman would crash when shutting down, with an error that it could not "unregister a controller window". We could not see how the existing release suddenly started failing, given it had been in use for some time without problems. It wasn't until we received a report from a user of Keyman Desktop that it wasn't working with Adobe Reader X that we were alerted to the issue ourselves: when I started testing this problem, as well as replicating the inability to type into Adobe Reader X, I suddenly started experiencing the crash that had been reported by other users.

Some debugging and research uncovered the problem that caused the crash – basically, the Keyman Engine keyman32.dll which was attached to the sandboxed Adobe Reader process was unable to communicate with the main Keyman Engine window and left the Keyman Engine in an unstable state. This error state was exposed when Keyman Desktop was shutting itself down and cleaning up.

I have written a fix for the beta of Keyman Desktop 8.0 to resolve the crash and will release an updated beta shortly. However, we have not yet completed development to enable Keyman input into Adobe Reader X while protected mode is switched on, because the way that the process is sandboxed restricts the ability of Keyman Desktop to communicate with the application, and this will take more effort to resolve.

The workaround that both avoids the crash and enables input into Adobe Reader X is to turn off protected mode. While I acknowledge that this is not a wonderful solution, it at least enables you to do your work, and at the very least you are no worse off than when running previous releases of Adobe Reader.

Tavultesoft Knowledge Base Article 69 provides a step-by-step workaround and will be updated when we complete resolution of this problem.

Installing Keyman 8

In the last week, I've spent a fair bit of time tidying up the installer.  There were a number of issues I had to resolve, such as problems upgrading when the user's admin status had been removed in between the original install and the upgrade ... yep, we've had to deal with this.

I also removed a lot of legacy code supporting Windows 95, 98 and Me: the setup installer for Keyman Desktop 7 needed to support these operating systems, as we still supported them when we released version 7.0.  It was a nice feeling removing that code!

Much of the work over the last week was under the hood and won't be visible to you as an end user, but I have also made what I think is a significant improvement to the installation user experience.

The installation process for Keyman Desktop 7, while not overly complicated certainly could be daunting to a newbie user.  The big reason for this was the large number of dialogs that the user could be presented with during a typical installation.  Here's how Keyman Desktop 7 installed for a typical user:

And here's the equivalent in Keyman Desktop 8:

I do feel that's a big improvement.  All the Windows Installer dialogs have been hidden, and the install process now consists of checking a single checkbox to agree to the license, then clicking on the Install Keyman Desktop button. I've removed the 'power user' options from the decision sequence and placed them under the "Install Options" dialog:

Similarly, the End User License Agreement (do you read all the EULAs you are presented with?) is now printable and easier to read but less intrusive.  The agreement itself hasn't changed!

The user interface language choice has been moved to a consistent and common location both in the Welcome screen and the Keyman Configuration screen.  This has the advantage of being less easily confused with keyboard layout choice:

Behind the scenes, Keyman Desktop still uses a Windows Installer .msi package to install, so it can be deployed on networks just as simply as before.  However, for the typical end user, I'm hoping these modifications will make it much simpler to understand the installation process.

For the technically-minded, here are a handful of the more interesting changes among the 30-odd changes and fixes I've made in the last week:

• When keyboards are included in the installer, they install for all users, not just the installing user
• Welcome screen no longer appears underneath Explorer and other windows after the install completes
• Keyman will be started from the installer as a non-elevated process even though the installer is elevated
• Keyman 6 and Keyman 7 user-installed keyboards will be transferred correctly for the user who launches the installer, even if they have to elevate to another admin user account
• Keyman 8 automatically removes the Keyman 7 installation when it runs.  You cannot install both Keyman 7 and Keyman 8 on the same computer at the same time.

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.