*See the difference between the two layouts in Keyman Developer.*
> [!NOTE]
- > The "Display 102nd Key (as on European keyboards)" checkbox can be left unchecked.
+ > The "Display 102nd Key (as on European keyboards)" checkbox can be left unchecked.
> To ensure compatibility, the extra key shouldn't be assigned since it won't be accessible on an ANSI physical keyboard.
Auto-fill underlying layout
@@ -270,20 +270,20 @@ Template...
be lost. Therefore, selecting an appropriate template early in the
development process is suggested.
- - template-basic: has only a phone layout (4 rows of keys), with three layers: default (K_A through K_Z
- plus some punctuation), shift (Shift K_A through Shift K_Z, plus some punctuation), numeric (K_0 through
+ - template-basic: has only a phone layout (4 rows of keys), with three layers: default (K_A through K_Z
+ plus some punctuation), shift (Shift K_A through Shift K_Z, plus some punctuation), numeric (K_0 through
K_9 unshifted and shifted, plus other non-alphanumerice keys).
- - template-latin: has both phone and tablet layouts (which are identical except for some key spacing,
- each with 4 rows of keys), with four layers: default, shift, numeric, symbol. The first three layers
- are similar to those of template-basic, with the addition of longpress keys for accented characters.
+ - template-latin: has both phone and tablet layouts (which are identical except for some key spacing,
+ each with 4 rows of keys), with four layers: default, shift, numeric, symbol. The first three layers
+ are similar to those of template-basic, with the addition of longpress keys for accented characters.
The symbol layer has many symbols not usually seen on a physical keyboard.
- - template-traditional: has both phone (4 rows of keys) and tablet (5 rows of keys) layouts. The phone
- layout is similar to the template-basic layout. The tablet layout has eight layers: default, shift, ctrl,
- shift-ctrl, alt, shift-alt, ctrl-alt, shift-ctrl-alt. The default layer has the keys from the default layer
+ - template-traditional: has both phone (4 rows of keys) and tablet (5 rows of keys) layouts. The phone
+ layout is similar to the template-basic layout. The tablet layout has eight layers: default, shift, ctrl,
+ shift-ctrl, alt, shift-alt, ctrl-alt, shift-ctrl-alt. The default layer has the keys from the default layer
of the desktop layout, the shift layer has the keys from the shift layer of the desktop layout, and so on.
-
+
Import from On Screen
: If you have an existing On-Screen Keyboard for your keyboard layout,
importing the design from the On-Screen Keyboard can reduce the
@@ -413,7 +413,7 @@ ID
- `U_####[_####]` is used as a shortcut for a key that
will output those Unicode values, if no rule matches it. This is
similar to the overloaded behaviour for `K_` ids. Thus `####`
- must be valid Unicode characters.
+ must be valid Unicode characters.
The square bracket characters `[` and `]` indicate an optional portion of the sequence
and are not to be included in the shortcut. E.g. `U_0259` would generate a
schwa if no rule matches. It is still valid to have a rule such
@@ -479,7 +479,7 @@ file. This makes certain operations simpler, such as batched rearranging
of keys, or using another text editor to make bulk changes. The Code
view uses the standard [editor](editor).
-The format of the layout file is described in [Creating a touch keyboard layout guide](../guides/develop/creating-a-touch-keyboard-layout-for-amharic-the-nitty-gritty).
+The format of the layout file is described in [.keyman-touch-layout file format](../reference/file-types/keyman-touch-layout).
#### Long-press, Flicks, and Multitaps controls
diff --git a/developer/docs/help/guides/__index.txt b/developer/docs/help/guides/__index.txt
new file mode 100644
index 0000000000..57ea270e2f
--- /dev/null
+++ b/developer/docs/help/guides/__index.txt
@@ -0,0 +1 @@
+-distribute
\ No newline at end of file
diff --git a/developer/docs/help/guides/develop/__index.txt b/developer/docs/help/guides/develop/__index.txt
new file mode 100644
index 0000000000..e88328ff8a
--- /dev/null
+++ b/developer/docs/help/guides/develop/__index.txt
@@ -0,0 +1,4 @@
+-creating-a-touch-keyboard-layout-for-amharic-the-nitty-gritty.md
+-creating-a-touch-keyboard-layout-for-amharic.md
+-tutorial
+-touch-keyboard-tutorial
diff --git a/developer/docs/help/guides/develop/creating-a-touch-keyboard-layout-for-amharic-the-nitty-gritty.md b/developer/docs/help/guides/develop/creating-a-touch-keyboard-layout-for-amharic-the-nitty-gritty.md
index f33ea20c34..a895225331 100644
--- a/developer/docs/help/guides/develop/creating-a-touch-keyboard-layout-for-amharic-the-nitty-gritty.md
+++ b/developer/docs/help/guides/develop/creating-a-touch-keyboard-layout-for-amharic-the-nitty-gritty.md
@@ -1,756 +1,3 @@
---
-title: Creating a Touch Keyboard Layout Part 2
+redirect: .
---
-
-
-
-
-
-
-This article will continue the guide to creating a touch keyboard layout. In
-particular, we'll look in more detail at how keys are arranged, just what can be
-specified for each key, and lastly, how this all looks in the JSON code used to
-define the long press layout.
-
-## Key and Key Layer Organization
-
-There are two issues that are immediately apparent when considering key layout
-on touch devices.
-
-First, on smaller touch devices, such as phones, if we try to display the same
-arrangement of keys that is used for a typical desktop keyboard, the keys are so
-small that it is difficult to reliably select the wanted key. If used in
-'portrait' view, key widths are too narrow for our 'fat fingers':
-
-
-
-Or if in 'landscape' view, key heights are too small:
-
-
-
-The situation is improved markedly if we limit the number of keys per row to ten
-and have no more than four key rows:
-
-
-
-and, in landscape view:
-
-
-
-So which keys can be eliminated, and which keys must be on the base (default)
-layer? This brings us to the second point. When using phones and other touch
-layout devices rather than desktop keyboards, text entry is most often
-single-handed, which makes it best to avoid using the 'shift' layer for entering
-normal text. Secondary keyboard layers will, of course, still be usually needed
-for uppercase, numerals and symbols, but will be used much less frequently.
-
-Most desktop keyboards (for European languages, at least) are already laid out
-with no more than ten letter (or digit) keys per row, with the remaining keys
-being used for accented letters, punctuation and other non-letter input. So the
-obvious choice is to move non-letter keys (and accented letters) either to a
-secondary key layer, or to long press ('pop-up') keys. The GFF Amharic desktop
-keyboard is fortunately also arranged with only ten letters per key row (other
-keys being used for punctuation, etc.), as the many different characters in the
-Amharic 'abugida' are generated by multi-letter sequences rather than being
-displayed on separate keys. The Geez script does not have both upper-case and
-lower-case forms, so those initial consonants that require use of the 'shift'
-layer on the desktop keyboard have been added to the corresponding base-layer
-key as long press keys:
-
-
-
-Arrangement of punctuation and other non-letter keys is more flexible as mobile
-users are generally familiar with using long press keys or a secondary key layer
-for finding and entering digits and special characters. However, some
-punctuation characters are used so frequently that they need to be on the base
-layer. For the GFF Amharic keyboard, the most frequently used punctuation
-characters can be output from the base layer using standard or long press keys.
-The Geez word space character, in particular, is so frequently used that it was
-considered useful to add it to the bottom key, adjacent to the space bar, as is
-sometimes done for other scripts, such as Japanese, on desktop (physical)
-keyboards.
-
-## Arranging keys with the layout editor
-
-The Keyman Developer layout editor really makes it quite easy to try different
-key layouts and choose what is best for your keyboard. The image below
-highlights just how, for any selected key, using the clickable icons circled, a
-key row can be added above (1) or below (2), a key added before (3) or after
-(4), the selected key deleted (5), and how an array of long press keys
-(sometimes called "subkeys") can be added (6).
-
-
-
-## Key properties
-
-For each visual key, the appearance and behaviour is determined by a number of
-properties:
-
-### Key code
-
-Each key must be given an identifying key code which is unique to the key layer.
-Key codes by and large correspond to the virtual key codes used when creating a
-keyboard program for a desktop keyboard, and should start with `K_`, for keys
-mapped to standard Keyman virtual key names, e.g. `K_HYPHEN`, and `T_` or `U_`
-for user-defined names, e.g. `T_ZZZ`. If keyboard rules exist matching the key
-code in context, then the output from the key will be determined by the
-processing of those rules. It is usually best to include explicit rules to
-manage the output from each key, but if no rules matching the key code are
-included in the keyboard program, and the key code matches the pattern
-`U_xxxx[_yyyy...]` (where `xxxx` and
-`yyyy` are 4 to 6-digit hex strings), then the Unicode characters
-`U+xxxx` and `U+yyyy` will be output. As of Keyman 15, you
-can use more than one Unicode character value in the id (earlier versions
-permitted only one). The key code is always required, and a default code will
-usually be generated automatically by Keyman Developer.
-
-- `K_xxxx` is used for a standard Keyman Desktop key name, e.g.
- `K_W`, `K_ENTER`. You cannot make up your own `K_xxxx` names.
- Many of the `K_` ids have overloaded output behaviour, for instance, if no
- rule is matched for `K_W`, Keyman will output 'w' when it is touched. The
- standard key names are listed in [Virtual Keys and Virtual Character
- Keys](/developer/language/guide/virtual-keys "Virtual Keys and Virtual
-Character Keys"). Typically, you would use only the "common" virtual key
- codes.
-
-- `T_xxxx` is used for any user defined names, e.g. `T_SCHWA`. If you wanted
- to use it, `T_ENTER` would also be valid. If no rule matches it, the key
- will have no output behaviour.
-
-- `U_####[_####]` is used as a shortcut for a key that will output those
- Unicode values, if no rule matches it. This is similar to the overloaded
- behaviour for `K_` ids. Thus `####` must be valid Unicode characters.
- The square bracket characters `[` and `]` indicate an optional portion of the sequence
- and are not to be included in the shortcut. E.g.
- `U_0259` would generate a schwa if no rule matches. It is still valid to
- have a rule such as `+ [U_0259] > ...`
-
-As noted above, some `K_xxxx` codes emit characters, if no rule is defined.
-There are also some codes which have special functions:
-
-| Identifier | -Meaning | -
|---|---|
| `K_ENTER` | -Submit a form, or add a new line (multi-line); the key action may vary depending on the situation. | -
| `K_BKSP` | -Delete back a single character. This key, if held down, will repeat. It is the only key code which triggers - repeat behavior. | -
| `K_LOPT` | -Open the language menu (aka Globe key). | -
| `K_ROPT` | -Hide the on screen keyboard. | -
| `K_TAB`, `K_TABBACK`, `K_TABFWD` | -Move to next or previous element in a form. Note that these key functions are normally - implemented outside the touch layout, so should not typically be used. `K_TAB` will go to previous - element if used with the `shift` modifier. | -
| Identifier | -Meaning | -
|---|---|
| `K_NUMERALS` | -Switch to a numeric layer | -
| `K_SYMBOLS` | -Switch to a symbol layer | -
| `K_CURRENCIES` | -Switch to a currency layer | -
| `K_SHIFTED` | -Switch to a shift layer | -
| `K_ALTGR` | -Switch to a right-alt layer (desktop compatibility) | -
| Text String | -Key Cap | -Key Purpose | -
|---|---|---|
| `*Shift*` | - | -Select Shift layer (inactive). Use on the Shift key to indicate that it switches to the shift layer. | -
| `*Shifted*` | - | -Select Shift layer (active). Use on the Shift key on the shift layer to switch back to the default layer. | -
| `*ShiftLock*` | - | -Switch to Caps layer (inactive). Not commonly used; generally double-tap on Shift key is used to access the - caps layer. | -
| `*ShiftedLock*` | - | -Switch to Caps layer (active). Use on the Shift key on the caps layer to switch back to the default layer. - | -
| `*Enter*` | - or | -Return or Enter key (shape determined by writing system direction) | -
| `*LTREnter*` | - | -Return or Enter key (left-to-right script shape) | -
| `*RTLEnter*` | - | -Return or Enter key (right-to-left script shape) | -
| `*BkSp*` | - or | -Backspace key (shape determined by writing system direction) | -
| `*LTRBkSp*` | - | -Backspace key (left-to-right script shape) | -
| `*RTLBkSp*` | - | -Backspace key (right-to-left script shape) | -
| `*Menu*` | - | -Globe key; display the language menu. Use on the `K_LOPT` key. | -
| `*Hide*` | - | -Hide the on screen keyboard. Use on the `K_ROPT` key. | -
| `*ABC*` | - | -Select alphabetic layer (Uppercase) | -
| `*abc*` | - | -Select alphabetic layer (Lowercase) | -
| `*123*` | - | -Select the numeric layer | -
| `*Symbol*` | - | -Select the symbol layer | -
| `*Currency*` | - | -Select the currency symbol layer | -
| `*ZWNJ*` | - (iOS) or (Android) | -Zero Width Non Joiner (shape determined by current platform) | -
| `*ZWNJiOS*` | - | -Zero Width Non Joiner (iOS style shape) | -
| `*ZWNJAndroid*` | - | -Zero Width Non Joiner (Android style shape) | -
| `*ZWNJGeneric*` | - | -Zero Width Non Joiner (not platform-specific) | -
| `*Sp*` | - | -Regular space | -
| `*NBSp*` | - | -No-Break Space | -
| `*NarNBSp*` | - | -Narrow No-Break Space | -
| `*EnQ*` | - | -En Quad | -
| `*EmQ*` | - | -Em Quad | -
| `*EnSp*` | - | -En Space | -
| `*EmSp*` | - | -Em Space | -
| `*PunctSp*` | - | -Punctuation Space | -
| `*ThSp*` | - | -Thin Space | -
| `*HSp*` | - | -Hair Space | -
| `*ZWSp*` | - | -Zero Width Space | -
| `*ZWJ*` | - | -Zero Width Joiner | -
| `*WJ*` | - | -Word Joiner | -
| `*CGJ*` | - | -Combining Grapheme Joiner | -
| `*LTRM*` | - | -Left-to-right Mark | -
| `*RTLM*` | - | -Right-to-left Mark | -
| `*SH*` | - | -Soft Hyphen | -
| `*HTab*` | - | -Horizontal Tabulation | -
| Text String | -Key Cap | -Key Purpose | -
|---|---|---|
| `*Tab*` | - | -Move to next input element in tab order | -
| `*TabLeft*` | - | -Move to previous input element in tab order | -
| `*Caps*` | - | -Select caps layer (legacy) | -
| `*AltGr*` | - | -Select AltGr (Right-Alt) layer (desktop layout compatibility) | -
| `*Alt*` | - | -Select Alt layer (desktop layout compatibility) | -
| `*Ctrl*` | - | -Select Ctrl layer (desktop layout compatibility) | -
| `*LAlt*` | - | -Select Left-Alt layer (desktop layout compatibility) | -
| `*RAlt*` | - | -Select Right-Alt layer (desktop layout compatibility) | -
| `*LCtrl*` | - | -Select Left-Ctrl layer (desktop layout compatibility) | -
| `*RCtrl*` | - | -Select Right-Ctrl layer (desktop layout compatibility) | -
| `*LAltCtrl*` | - | -Select Left-Alt-Ctrl layer (desktop layout compatibility) | -
| `*RAltCtrl*` | - | -Select Right-Alt-Ctrl layer (desktop layout compatibility) | -
| `*LAltCtrlShift*` | - | -Select Left-Alt-Ctrl-Shift layer (desktop layout compatibility) | -
| `*RAltCtrlShift*` | - | -Select Right-Alt-Ctrl-Shift layer (desktop layout compatibility) | -
| `*AltShift*` | - | -Select Alt-Shift layer (desktop layout compatibility) | -
| `*CtrlShift*` | - | -Select Ctrl-Shift layer (desktop layout compatibility) | -
| `*AltCtrlShift*` | - | -Select Alt-Ctrl-Shift layer (desktop layout compatibility) | -
| `*LAltShift*` | - | -Select Left-Alt-Shift layer (desktop layout compatibility) | -
| `*RAltShift*` | - | -Select Right-Alt-Shift layer (desktop layout compatibility) | -
| `*LCtrlShift*` | - | -Select Left-Ctrl-Shift layer (desktop layout compatibility) | -
| `*RCtrlShift*` | - | -Select Right-Ctrl-Shift layer (desktop layout compatibility) | -
| Key Type | -Value | -Meaning | -
|---|---|---|
| Default | -`0` | -Any normal key that emits a character | -
| Special | -`1` | -The frame keys such as Shift, Enter, BkSp. | -
| Special (active) | -`2` | -A frame key which is currently active, such as the Shift key on the shift layer. | -
| Deadkey | -`8` | -Does not impact behavior, but colors the key differently to indicate it has a special function, such as a - desktop-style deadkey. | -
| Blank | -`9` | -A blank key, which may be used to maintain a layout shape. Usually colored differently. Does not impact - behavior. | -
| Spacer | -`10` | -Does not render the key, but leaves a same-sized gap in its place. The key cannot be selected. | -
-
-## Tips
-
-***Flicks** and **long presses** can both be used in a single keyboard. In this scenario, it is recommended to use flicks in only one direction—south (down). Long presses work well alongside this pattern. See, for example, [sil_euro_latin](https://help.keyman.com/keyboard/sil_euro_latin/3.0.3/sil_euro_latin#toc-mobile-keyboard-layout).
- * Another helpful tip seen in the sil_euro_latin keyboard is using south-flicks on the base and shift layers corresponding to the numeric/symbol layer, this aids in both memorization and discovery.
-* **Flicks** in multiple directions are possible, but currently Keyman does not support hints for multiple directions, so they are not very discoverable.
-* **Long presses** are more discoverable, but **flicks** are faster. We suggest using south flicks along with long presses, and including the flick output in the long press for maximum discoverability and optimum ergonomics.
-
-## Caution
-
-* **Flicks** near screen edges tend to be problematic--once you drag off the screen, then Keyman can no longer tell that you are flicking (or you may end up activating system controls on the bottom edge):
- * On the bottom row, south flicks are not recommended.
- * On the top row, we have the banner space reserved in order to be able to support flicks and long presses up into that region of the screen.
- * Left/right screen edges, horizontal flicks are not the best practice.
-
-## See also
-
-* The [Winchus keyboard](https://help.keyman.com/keyboard/winchus/1.4/winchus#guia-rapida-celular)
-* The [GFF Amharic keyboard](https://help.keyman.com/keyboard/gff_amharic/3.2.1/gff_amharic#toc-using-this-keyboard)
\ No newline at end of file
+(Replaced by new walkthrough in v19)
\ No newline at end of file
diff --git a/developer/docs/help/guides/develop/touch-keyboard-tutorial/index.md b/developer/docs/help/guides/develop/touch-keyboard-tutorial/index.md
index acfe3efcec..7505708ee1 100644
--- a/developer/docs/help/guides/develop/touch-keyboard-tutorial/index.md
+++ b/developer/docs/help/guides/develop/touch-keyboard-tutorial/index.md
@@ -1,60 +1,5 @@
---
-title: Creating a Simple Touch keyboard
+redirect: ..
---
-## Introduction and design
-
-If you have experience in designing Keyman keyboards for computers, the
-interface for designing mobile keyboards looks very similar, but it
-hides the reality of additional steps necessary for mobile keyboards.
-This tutorial attempts to walk you through the process.
-
-The [Quick French tutorial](../tutorial/) shows how to create a simple
-desktop keyboard for typing accented characters used in French and other
-European languages. It is possible to create a touch screen format of
-that keyboard, but it is probably unnecessary. The default keyboards for
-both Android and iOS devices have a way to type these accented
-characters. Press and hold on a vowel, and a popup menu will give you a
-choice of accents to put on that letter.
-
-For this tutorial we will demonstrate something usable for the Fulfulde
-language cluster spoken across many Sahelian countries of Africa.
-Fulfulde is usually written using the Latin alphabet, but there are a
-few characters added to the usual list of alphabetical characters. So
-this is a useful example for any language wanting to add a few
-characters to the standard Latin keyboard. Here are the characters we
-are going to add, together with their Unicode values.
-
-| | | | | | | | | |
-|-----|----------|-----|----------|-----|-----|----------|-----|----------|
-| `ɓ` | `U+0253` | `Ɓ` | `U+0181` | | `ɗ` | `U+0257` | `Ɗ` | `U+018A` |
-| `ŋ` | `U+014B` | `Ŋ` | `U+014A` | | `ƴ` | `U+01B4` | `Ƴ` | `U+01B3` |
-
-Here we will likely want to proceed differently than with the desktop
-keyboard. The usual approach for a desktop keyboard is to create a
-deadkey. The keyboards I have used for Fulfulde (going back to decades
-ago) used the / key as the deadkey.
-/b gave ɓ,
-/d gave ɗ, and so on.
-
-It would be possible to use that desktop keyboard logic on touch
-screens. But your mobile device users will find these rules annoying.
-
-Instead of two keys they would probably have to press four, since the
-standard alphabetical keyboard on most touch devices does not have the
-slash key. So they would have to press the key to switch to the numeric
-keyboard, then press slash, then press the key to switch back to the
-alphabetical keyboard, and then the letter. What touch screen users would
-appreciate is something that uses the great feature of touch screens,
-the long press or press and hold on a letter, to see analogous letters.
-
-So we’ll set up a touch screen keyboard that lets you
-* press and hold ‘d’ to see the two hooked d characters
-* press and hold ‘b’ to see the hooked b characters, and so on.
-
-[Next: Making, testing and distributing the touch
-keyboard](making-touch-keyboard)
-
-## See also
-
-* Tips for using [gestures](gestures) in Keyman Developer
+(Replaced by new walkthrough in v19)
\ No newline at end of file
diff --git a/developer/docs/help/guides/develop/touch-keyboard-tutorial/making-touch-keyboard.md b/developer/docs/help/guides/develop/touch-keyboard-tutorial/making-touch-keyboard.md
index 5039acb262..7505708ee1 100644
--- a/developer/docs/help/guides/develop/touch-keyboard-tutorial/making-touch-keyboard.md
+++ b/developer/docs/help/guides/develop/touch-keyboard-tutorial/making-touch-keyboard.md
@@ -1,361 +1,5 @@
---
-title: Making a touchscreen keyboard
+redirect: ..
---
-## Setting up your Keyman project
-
-This is a useful convention for keeping track of your files:
-
-1. Create a folder on your hard drive for all your Keyman developer
- files
-2. In that folder, create a folder for this project, named after the
- language. Use all lowercase letters for compatibility with other
- platforms.
-3. Now create a project in Keyman Developer with the same name as the
- new folder, and save it inside the new folder
-
-Now you will be able to use this project to organize and create any
-files for desktop, mobile, web or other. It also facilitates uploading
-the files to the Keyman website later on.
-
-## Add touch to an existing keyboard or create a new keyboard?
-
-You can add a mobile touchscreen keyboard to an existing desktop
-keyboard, or you can create a new touchscreen keyboard from scratch. You
-should be aware that there will be cross-over between mobile and desktop
-keyboards. (In Keyman terms, "desktop" includes laptop computers or any
-device with a physical keyboard). Your mobile device can have an
-external keyboard, which will use the desktop Keyman keyboard. So the
-Keyman strategy is to always bundle touch keyboards with desktop
-keyboards to make them work on multiple platforms.
-
-If creating from scratch, you click the New icon in the Keyman Developer
-toolbar (or select File > New from the menu), and specify the file
-name for your keyboard. We recommend a name using only lowercase
-letters, numbers and underscore. I’ll choose “mobile_fulfulde.kmn” .
-
-
-
-## Adding the required metadata
-
-After creating the file, Keyman Developer will ask you to name the
-keyboard. This name can include spaces and upper case letters if
-desired. I’ll name this one “Fulfulde for Mobile”.
-
-
-
-The first thing you need to do is to tell Keyman Developer this keyboard
-will include some kind of mobile device. You do this in the Targets
-list just below the keyboard name. I’ll select “mobile ” in the list,
-(towards the end). You see in the picture above that Keyman Developer
-checked the “windows” box by default, I can uncheck that or leave it
-checked if I am going to add a Windows keyboard to this set.
-
-
-
-This will include all mobile devices, both Android and iOS, both phones
-and tablets. It is possible if needed to select Android only or iOS only
-if needed, and to develop a different keyboard layout for tablets than
-for phones, but for this example, with only a few characters needed to
-be added to the default keyboards, there is no need for that kind of
-complexity.
-
-(If you are adding a mobile layout to an existing keyboard file, you
-would open that file in Keyman Developer, go to the Targets box and
-check “mobile” or whatever mobile targets you wanted to specify, then
-follow along from here).
-
-## Adding the touch optimized feature
-
-The next step is to add the touch-optimised feature to our keyboard
-setup. If you scroll to the bottom of the details tab, there is the list
-of features to add. I’ll click the Add button and choose “touch
-optimised keyboard.”
-
-
-
-Keyman developer asks me to choose one of three templates for the mobile
-layout.
-
-
-
-The “template-latin” layout includes many accented characters, like the
-default keyboards for Android and iOS do. The “template-basic” layout
-has no extra characters, and the template-traditional has a few extra
-characters (mostly punctuation symbols if you long-press period or full
-stop). For this example, I’ll choose “template-basic” because accented
-characters are not needed for Fulfulde. But if I knew that many eventual
-users might want to be able to type French or other European languages
-as well as Fulfulde, and wouldn’t like to have to switch the keyboard to
-do so, I could choose “template-latin”.
-
-## Defining one or several touch layouts
-
-I select the template and click OK. Keyman Developer now adds a new tab
-in the left column, the Touch Layout tab.
-
-
-
-That is where we need to go now to add characters to our touch layout.
-But before doing that, there is one important thing to take note of in
-the touch layout. By default, Keyman Developer has created a layout for
-phones and another layout for tablets. They all start out the same, but
-as I add characters, I will have to make sure I add all the characters
-to both layouts, or I’ll discover that my keyboard does not work for all
-device sizes.
-
-In the image, you see in the Platform box that Keyman Developer is currently showing the
-tablet layout. This box is where I’d choose which layout I’d design in.
-
-But I’m going to make this keyboard simple, and just have one layout for
-both tablets and phones. So in the platform box, I am going to click
-the “minus” button, to delete the tablet layout. When there is only one
-mobile layout, Keyman Developer will compile that layout for all mobile
-devices. (I could also have chosen to delete the phone layout and done
-my layout design in the tablet layout).
-
-
-
-## Adding longpress characters
-
-Now I can start adding characters. I’ll click on the “y” key in the
-layout, then I’ll look at the “longpress keys” area at the lower
-left.
-
-
-
-I click that, and Keyman Developer adds a new key below the keyboard
-layout.
-
-
-
-I'm going to use this key for the y with hook. I click inside it to make it active, then I’ll go look for my y
-with hook character in the character map to the right. If I type “y
-hook” in the search box, Keyman Developer shows the character I’m
-looking for.
-
-
-
-If I double click on the lower case y with hook, that copies the character
-to the keycap box of my new key. (I could also click and drag the character from the character map to the key).
-
-
-
-## New key info
-
-There are several important pieces of information that got copied over. If we
-look at the properties of the new key to the right, we see that this new key has
-the “text” ƴ (what appears on the keycap), the “Unicode value” U+01B4 and the
-“ID” U_01B4. All of these were copied from the character map.
-
-NOTE: If you copy one character from the character map to a new key, then
-realize you copied the wrong character, dragging a second character may not
-replace all the needed information into the key. If a key has a character in it
-already, it works better to hold Ctrl as you drag the new character
-into it.
-
-I could add the other three characters; hook b, hook d, and eng, as longpress
-characters as well. I could select the regular letter I want to longpress,
-click plus in the longpress keys area and copy the needed character. Here for
-example is the b with hook:
-
-
-
-After I have added my four lowercase characters as longpress keys, the keyboard
-looks like this. Even when I don't have that letter selected, I can see which
-keys have longpress keys by the dot beside the letter.
-
-
-
-[See the Keyman Language guide on virtual keys](../../../../language/guide/virtual-keys#toc-virtual-keys-and-touch-layouts)
-
-## Adding uppercase characters
-
-I could do two different things for the upper case letters. I could add them as
-longpress keys beside their lowercase equivalents, by pressing the plus key
-again to add a second longpress character to each letter.
-
-This would mean users would not have to press Shift to be able to type the upper
-case hook y. But since a user needs to press Shift for all the regular Latin
-upper case letters, it might make more sense to put the uppercase letters into
-the Shift layer.
-
-I can change to the shift layer by finding the layer box at lower left, and
-choosing `shift` instead of `default`.
-
-
-
-Now I see the upper case letters on the keyboard, and I can add longpress
-characters to these in the same way I did on the default layer. I click the
-letter, then click `+` to add a key, then copy the character info from the
-character map. Adding my upper case y hook to Y would look like this:
-
-
-
-(If I had clicked on the green triangle to the left of my first key, the
-new key would be added to the left of that key).
-
-For this new key, I go through the same steps. I click in the empty box
-on the new key, then double click the upper case y with hook in the
-character map to put that in the keycap. I also change the code of this
-new key to “U_01B3”
-
-
-
-## Another option for upper case characters
-
-I might also add the upper case character to a longpress character on
-the upper-case Y key, because some users will press the Shift key then
-look for the letter to type. To do this, I change the layer at the top
-of the tablet layout to "shift" from "default".
-
-
-
-Now I click the Y key, and add a longpress character, then add the upper
-case y with hook to the keycap and add the keycode as shown before.
-
-
-
-You can design your keyboard either way, with the upper case characters
-in the same longpress row as the lower case, or in a longpress row off
-of the shift layer. The rest of this tutorial shows the upper case
-characters in the same row as the lower case, but I don't mean to
-present this as the best way. If you do put upper case characters in the
-shift layer, you'll have to remember to change the layer back to
-"default" when you want to add a lower case letter, then back to "shift"
-when adding an upper case letter. You could put the upper case
-characters in both places, if you think that best.
-
-Now I’ll add the two d hook characters as a longpress popup for the d
-key. I click the d key in the layout, click “Add longpress popup”, add
-the lower case hook d to the keycap and change the code to “U_0257”;
-then click the plus sign to add a second key, add the upper case hook D
-to the keycap and change its code to “U_018A”. The end result should
-look like this:
-
-
-
-I’ll do the similar step to add two characters as a longpress popup for
-“b”
-
-
-
-And two characters as a longpress popup for “n”. (Tip, to search for ŋ
-in the character map, type “eng”).
-
-
-
-When no keys are selected in the keyboard layout, I can still see which
-ones I have set up longpress popups for, because Keyman Developer shows
-a faint gray line at the top right corner of the key. So you should have
-a faint diagonal line on your y, d, b and n keys.
-
-
-
-## Replacing the Unicode and Code automatically
-
-1. Hold the Ctrl key while dragging and
- dropping a character from the Character Map to the touch layout
- editor, and it will replace the Code as well as the character.
-2. Hold the Shift key while dropping, and it
- will only add the character to the key.
-3. Finally, hold
- Ctrl+Shift, this
- will add the character to the key AND update the Code to match the
- full set of characters represented on the key.
-
-## Compiling your keyboard
-
-Now click Save to save your work, and compile the keyboard. (Keyboard
-> Compile Keyboard, or press F7). Hopefully you’ll see it compiled
-with no error messages:
-
-
-
-If you see a warning like:
-
-```
-Warning: line 0 warning 2092: Key " T_new_579" on layer "default", platform "phone", is a custom key but has no corresponding rule in the source.
-```
-
-This shows you forgot to enter the correct keycode for a new key you
-added. Double check your longpress popup keys for one with a “T_new_NNN”
-code, and add in the desired “U_NNNN” code.
-
-You might also see a message like
-
-```
-Error: line 0 error 405A: Key " U+0181" on "phone", layer "default" has an invalid identifier.
-```
-
-This shows you attempted to change the keycode but mistyped the code.
-I’ve gotten this more than once, because I am used to typing `U+0181`to
-refer to a Unicode value, but the correct syntax for a keycode in Keyman
-Developer is `U_0181`
-
-# Testing your keyboard
-
-Other Keyman help pages describe how you can test your keyboard:
-
-- [On a virtual device in the Chrome web browser on your
- computer](../../test/keyboard-touch-mobile-emulator)
-- [On your own device accessing the keyboard over the
- network](../../test/keyboard-touch-and-desktop)
-
-If your device cannot connect to your computer on the local network (for
-instance if your computer is on a wired office network and your device
-is on the wireless office network), the above technique for sharing may
-not work. You can put your keyboard in a package and share it over the
-Internet with your device, as described below.
-
-# Packaging and distributing your keyboard
-
-Another Keyman help file describes [how to build a package
-file.](../../distribute/tutorial)
-
-## BCP 47 tags for Fulfulde
-
-[Step 3](../../distribute/tutorial/step-3) of the package building
-tutorial describes adding the BCP 47 language tag to your package. When
-I came to the step of adding a tag for Fulfulde, I had to do some
-research. I naively thought "Fulfulde" was a clear enough label for the
-language. It is not, since it is a language chain rather than one
-language. The BCP 47 tag in many cases is the same as the [SIL
-Ethnologue code](https://www.ethnologue.com), so that is where I had to
-go to find the tags I needed. In the end I added four tags for four
-Fulfulde languages:
-
-
-
-I also added the script designator `Latn` for Latin script. This is
-recommended for Windows, which sometimes fails to install the desktop
-keyboard if there is not a script designator on the BCP 47 tag. We
-recommend that you always put in the script tag unless there is a
-specific reason not to.
-
-Some languages have only two letters in their BCP 47 tag. For instance,
-the Hausa language has an Ethnologue code `hau` but the BCP 47 tag is
-`ha`. Keyman Developer knows about this, and will change the tag to `ha`
-if I put in the Ethnologue tag.
-
-# Next steps
-
-The two following articles on Amharic describe a more complex
-touchscreen example where quite frequently two keys are pressed to get
-one distinct character. (Amharic is a Abugida or syllabary script, where
-one character can represent a consonant and following vowel).
-
-- [Creating a touch keyboard layout for Amharic - part
- 1](../creating-a-touch-keyboard-layout-for-amharic)
-- [Creating a touch keyboard layout for Amharic - part
- 2](../creating-a-touch-keyboard-layout-for-amharic-the-nitty-gritty)
\ No newline at end of file
+(Replaced by new walkthrough in v19)
\ No newline at end of file
diff --git a/developer/docs/help/guides/develop/tutorial/index.md b/developer/docs/help/guides/develop/tutorial/index.md
index 3642ddc1ed..e27c01cf2f 100644
--- a/developer/docs/help/guides/develop/tutorial/index.md
+++ b/developer/docs/help/guides/develop/tutorial/index.md
@@ -1,56 +1,3 @@
---
-title: Keyboard Tutorial
+redirect: ..
---
-
-[Step 1: Planning the Keyboard](step-1)
-
-[Step 2: Writing the Header](step-2)
-
-[Step 3: The Keyboard Header](step-3)
-
-[Step 4: The Keyboard Body](step-4)
-
-[Step 5: Rules with Context](step-5)
-
-[Step 6: Stores, 'any', and 'index'](step-6)
-
-[Step 7: Testing the Keyboard](step-7)
-
-[Step 8: Deadkeys](step-8)
-
-[Step 9: The Finished Keyboard](step-9)
-
-## Overview
-
-Welcome! In this tutorial, you will learn the basics of Keyman keyboards
-and create a simple French keyboard which can be used with any physical
-keyboard layout.
-
-The keyboard will use a basic English layout, and add some deadkeys to
-define vowel diacritics and a few other characters.
-
-While this tutorial is based on a physical keyboard such as used on a
-desktop or laptop computer, the principles of the keyboard language that
-you will learn are applicable to developing touch layouts as well.
-
-This keyboard will use Unicode. Unicode is a character encoding standard
-that supports most of the world's scripts, and includes support for
-user-defined scripts. Unicode is the accepted standard for text encoding
-in modern applications and operating systems.
-
-In Keyman Developer keyboard source files, Unicode characters are
-specified with `U+xxxx`, where `xxxx` is a four-digit hexadecimal
-number.
-
-At the bottom of each page in the tutorial, will be a link to both the
-previous page and the next page. You can use these links to work your
-way through the tutorial. You may also find links to reference
-information, which you can select to learn more about a particular
-aspect of creating Keyman keyboards.
-
-## Let's begin
-
-Let's get started! Move on to the next topic to begin the first step,
-planning the keyboard.
-
-- [Continue with Step 1: Planning the Keyboard](step-1)
\ No newline at end of file
diff --git a/developer/docs/help/guides/develop/tutorial/step-1.md b/developer/docs/help/guides/develop/tutorial/step-1.md
index 96db7592ee..7505708ee1 100644
--- a/developer/docs/help/guides/develop/tutorial/step-1.md
+++ b/developer/docs/help/guides/develop/tutorial/step-1.md
@@ -1,71 +1,5 @@
---
-title: Step 1: Planning the Keyboard
+redirect: ..
---
-## Choosing the characters
-
-First of all, we need to decide which characters we want the keyboard to
-produce. Next, we must find out the codes used to represent them, using
-a program such as Character Map, or with the Character Map in Keyman
-Developer (go to **View**, **Character Map**).
-
-French uses the same 26 letters as English, with some additions. As our
-keyboard is based on English, we only need to work with these additional
-letters. Note that for completeness, we will design our keyboard to
-produce a few other accented vowels that are not used in French. Also,
-we want our keyboard to include the angled quotes `«` and `»`.
-
-These characters, with both uppercase and lowercase forms, are listed in
-the table below along with their Unicode codes.
-
-| | | | | | | | | |
-|-----|----------|-----|----------|-----|-----|----------|-----|----------|
-| `À` | `U+00C0` | `à` | `U+00E0` | | `Á` | `U+00C1` | `á` | `U+00E1` |
-| `È` | `U+00C8` | `è` | `U+00E8` | | `É` | `U+00C9` | `é` | `U+00E9` |
-| `Ì` | `U+00CC` | `ì` | `U+00EC` | | `Í` | `U+00CD` | `í` | `U+00ED` |
-| `Ò` | `U+00D2` | `ò` | `U+00F2` | | `Ó` | `U+00D3` | `ó` | `U+00F3` |
-| `Ù` | `U+00D9` | `ù` | `U+00F9` | | `Ú` | `U+00DA` | `ú` | `U+00FA` |
-| `Â` | `U+00C2` | `â` | `U+00E2` | | `Ä` | `U+00C4` | `ä` | `U+00E4` |
-| `Ê` | `U+00CA` | `ê` | `U+00EA` | | `Ë` | `U+00CB` | `ë` | `U+00EB` |
-| `Î` | `U+00CE` | `î` | `U+00EE` | | `Ï` | `U+00CF` | `ï` | `U+00EF` |
-| `Ô` | `U+00D4` | `ô` | `U+00F4` | | `Ö` | `U+00D6` | `ö` | `U+00F6` |
-| `Û` | `U+00DB` | `û` | `U+00FB` | | `Ü` | `U+00DC` | `ü` | `U+00FC` |
-| `Ý` | `U+00DD` | `ý` | `U+00FD` | | `Ç` | `U+00C7` | `ç` | `U+00E7` |
-| `«` | `U+00AB` | `»` | `U+00BB` | | | | | |
-
-If you are not familiar with the hexadecimal (base-16) numbering system,
-don't worry: you can use the Character Map in Keyman Developer to find
-the character you want, and then drag-and-drop or copy-and-paste its
-character code into your keyboard.
-
-Note that you must be careful to use the right character: The Unicode
-standard has many characters with the same shape as another, but a
-different meaning; an example of this is the Greek capital letter Sigma
-(`U+03A3` Σ) and the mathematical summation symbol (`U+2211`, ∑). An application
-supporting Unicode would treat these two characters differently. If in
-doubt whether a character is the right one, you can look up the
-reference tables at [www.unicode.org](http://www.unicode.org/).
-
-## Designing the layout
-
-After choosing the characters we want our keyboard to use, we must
-decide how we want the user to be able to enter them. For some
-languages, you might replace each letter on the English keyboard with a
-letter from the language. In this case, however, most of the letters are
-accented vowels, we will use two keystrokes for each: one for the
-accent, and one for the vowel.
-
-| Character | Keystrokes |
-|-------------|-------------------------------|
-| `À, à, ...` | back-quote (`), then the vowel key. |
-| `Á, á, ...` | quote ('), then the vowel key. |
-| `Â, â, ...` | caret (^), then the vowel key. |
-| `Ä, ä, ...` | double-quote ("), then the vowel key. |
-| `Ç, ç` | quote ('), then lower- or uppercase C. |
-| `«, »` | two less-than (<<) or greater-than (>>) symbols. |
-
-Now that we have decided which character to use and how the user can
-enter them, we can start to write the keyboard.
-
-- [Continue with Step 2: Writing the Header](step-2)
-- [Back to the Introduction](index)
+(Replaced by new walkthrough in v19)
\ No newline at end of file
diff --git a/developer/docs/help/guides/develop/tutorial/step-2.md b/developer/docs/help/guides/develop/tutorial/step-2.md
index 5867973fb3..5e2725a24e 100644
--- a/developer/docs/help/guides/develop/tutorial/step-2.md
+++ b/developer/docs/help/guides/develop/tutorial/step-2.md
@@ -1,53 +1,5 @@
---
-title: Step 2: Writing the Header
+redirect: .
---
-## Overview of a keyboard file
-
-A keyboard file is divided into two sections: the **header** and the
-**rules** section. The header section defines the name of the keyboard,
-its bitmap, and other general settings. The rules are used to define how
-the keyboard responds to keystrokes from the user, and are divided into
-groups. We will start by writing the header.
-
-## The keyboard header
-
-The keyboard header is the first part of a keyboard; it consists of
-statements that help Keyman identify the keyboard and set default
-options for it. Each statement in the header must be on a separate line.
-While there is no technical requirement to put header statements at the
-start of a keyboard source file, keeping them there helps you identify
-them easily, and keeps them consistent with keyboard programs other
-people might write.
-
-We will begin to write the keyboard. If Keyman Developer is not already
-running, start it now. Create a new keyboard file, navigate to the
-**Layout** tab, and click on the **Code** tab at the bottom of the
-screen to switch to the Code view.
-
-Type or paste the following code into the keyboard file. This is the
-header of our keyboard file.
-
-```keyman
-c Simplified French Keyboard for Keyman 9.0
-c
-c This keyboard program uses a simplified set of keys
-c for typing French, especially for those who don't know the
-c standard French keyboard.
-c
-c NOTE: This keyboard was created from the Keyman keyboard
-c programming tutorial.
-
-store(&Version) "9.0" c This keyboard is for use with Keyman 9.0
-store(&Name) "Quick French"
-store(&Bitmap) "qfrench.ico"
-store(&MnemonicLayout) "1" c This keyboard uses a mnemonic layout.
-
-begin Unicode > use(Main)
-```
-
-An explanation of the various parts of the header follows on the next
-page.
-
-- [Continue with Step 3: The Keyboard Header](step-3)
-- [Back to Step 1: Planning the Keyboard](step-1)
\ No newline at end of file
+(Replaced by new walkthrough in v19)
\ No newline at end of file
diff --git a/developer/docs/help/guides/develop/tutorial/step-3.md b/developer/docs/help/guides/develop/tutorial/step-3.md
index 81777aec6a..5e2725a24e 100644
--- a/developer/docs/help/guides/develop/tutorial/step-3.md
+++ b/developer/docs/help/guides/develop/tutorial/step-3.md
@@ -1,99 +1,5 @@
---
-title: Step 3: The Keyboard Header
+redirect: .
---
-## Comments
-
-```keyman
-c Simplified French Keyboard for Keyman 9.0
-```
-
-Most of the header in this example is made up of
-[comments](/developer/language/guide/comments). A comment is used
-to make notes about the keyboard, or to provide information on the
-workings of the keyboard. The comments are readable by anyone looking at
-the source code of the keyboard.
-
-A comment always starts with a lowercase `c`, followed by one or more
-spaces, and continues to the end of the line. Keyman Developer will
-ignore comments when compiling a keyboard.
-
-Comments can take up a whole line, or can start in the middle of the
-line. The latter is useful for making short notes about individual
-lines. As you can see we have used both kinds of comments in the header.
-
-## The `&Version` store
-
-```keyman
-store(&Version) "9.0" c This keyboard is for use with Keyman 9.0
-```
-
-The [`&Version` store](/developer/language/reference/version)
-identifies the Keyman version for which this keyboard was written; this
-keyboard is for use with Keyman 9.0. The `&Version` store is an optional
-part of the keyboard header, but if present, it should be the first
-store in the file.
-
-## The `&Name` store
-
-```keyman
-store(&Name) "Quick French"
-```
-
-The [`&Name` store](/developer/language/reference/name) specifies
-a descriptive name for the keyboard, which can be up to eighty
-characters long. The name we have given to this keyboard is
-`"Quick French"`. The `&Name` store is not required but is highly
-recommended!
-
-## The `&Bitmap` store
-
-```keyman
-store(&Bitmap) "qfrench.ico"
-```
-
-The optional [`&Bitmap` store](/developer/language/reference/bitmap)
-tells Keyman which image to use for the keyboard's icon. The picture
-should be in the standard Windows .ico format, and should contain at
-least a single 16x16 pixel image. It can also contain higher resolution
-images for high resolution "High DPI" displays. If you use a modern icon
-editor, the icon can use alpha transparency.
-For this keyboard we will be using the following bitmap:
-; it is
-found in the Keyman Developer folder, under
-`Samples\Examples\qfrench.ico` - you should copy it into the same folder
-in which you will save your keyboard.
-
-## The `&MnemonicLayout` store
-
-```keyman
-store(&MnemonicLayout) "1"
-```
-
-The [`&MnemonicLayout` store](/developer/language/reference/mnemoniclayout) tells Keyman that
-the layout is meant to conform to the user's keyboard layout; for
-example, if the user presses the quote key ' on
-their keyboard (whether they are using a US English, UK English, French,
-German, Swedish, or other keyboard) it should work in the same way. The
-opposite of this is a positional layout (which is the default if this
-store omitted), which is intended for keyboards for which there is not
-necessarily a correspondence between what is printed on the physical
-keyboard and what is output when that key is pressed.
-
-## The `begin` statement
-
-```keyman
-begin Unicode > use(Main)
-```
-
-The [`begin` statement](/developer/language/reference/begin) tells
-Keyman which group of rules to process first when it receives a
-keystroke. The use of multiple groups is an advanced feature, and
-unnecessary for this tutorial, so we will use a single group, called
-`Main`. The `begin` statement is required in every keyboard, and marks the
-start of the keyboard body. The `begin` statement also tells Keyman
-which encoding to use for the keyboard. Nearly all keyboards will use
-`Unicode`, today.
-
-- [Continue with Step 4: The Keyboard Body](step-4)
-- [Back to Step 2: Writing the Header](step-2)
\ No newline at end of file
+(Replaced by new walkthrough in v19)
\ No newline at end of file
diff --git a/developer/docs/help/guides/develop/tutorial/step-4.md b/developer/docs/help/guides/develop/tutorial/step-4.md
index e8a861ae1c..5e2725a24e 100644
--- a/developer/docs/help/guides/develop/tutorial/step-4.md
+++ b/developer/docs/help/guides/develop/tutorial/step-4.md
@@ -1,102 +1,5 @@
---
-title: Step 4: The Keyboard Body
+redirect: .
---
-The body of the keyboard is the most important part: it determines the
-behaviour of the keyboard. The body consists of groups, which in turn
-contain one or more rules which define the responses of the keyboard to
-certain keystrokes.
-
-## Groups
-
-There are two types of groups:
-* groups that process the keys pressed and the context.
-* groups that process only the context.
-
-For simple keyboards, the latter type of group will not be required. A group begins
-with a [`group` statement](/developer/language/reference/group), and
-ends either at the start of another group, or at the end of the keyboard
-file.
-
-We will only use one group in the Quick French keyboard, called `Main`.
-We mark the start of it with the `group` statement below. Add this line
-to the keyboard if it's not already there.
-
-```keyman
-group(Main) using keys
-```
-
-The `using keys` clause tells Keyman that this group will process
-keystrokes.
-
-## Basic Rules
-
-A rule tells Keyman the output to produce for a certain input. A rule
-consists of three parts: the **context**, the **key**, and the
-**output**.
-
-* The **context** specifies the conditions under which a rule will act. If
-what is shown in the document to the left of the cursor matches the
-context of a rule, the rule will be processed.
-* The **key** specifies which keystroke the rule will act upon.
-* The **output** determines the characters that are produced by a rule.
-The output replaces the matched context in the document.
-
-## Simple rules
-
-The simplest rules in Keyman consist of just a key and output, as below.
-(The examples in this section are just for illustration, and do not form
-part of the Quick French keyboard).
-
-```keyman
-+ "a" > "ä"
-```
-
-In this rule, the key is a, and the output is `"ä"`. A simple rule
-begins with a plus sign, followed by the key, a greater-than symbol
-(suggesting "becomes"), and finally the output. As you might guess, this
-rule will change a lowercase a key typed by the
-user into **ä**.
-
-The key and output can be written as a character in single or double
-quotes (as above), or as its Unicode character code, or using a named
-constant. The rule above could have also been written any of the
-following ways, among others:
-
-```keyman
-+ 'a' > 'ä'
-
-+ U+0061 > U+00E4
-
-store(ADIERESIS) 'ä'
-+ 'a' > $ADIERESIS
-```
-
-You can also write the key in one form and the context in another.
-
-## Rules with longer output
-
-The output of a rule is not limited to a single character. You could,
-for example, write a rule such as the following:
-
-```keyman
-+ "f" > "ph"
-```
-
-This would change any f keys typed into **ph**.
-If the output of a rule consists of more than one character, you can
-write the characters in different ways if necessary, with a space
-separating each part. You can specify multiple characters in quotes, but
-if you use the Unicode codes to write the characters, you must separate
-each with a space:
-
-```keyman
-+ "f" > U+0070 U+0068
-
-+ "f" > U+0070 "h"
-```
-
-These rules are functionally identical to the one [further above](#toc-simple-rules).
-
-- [Continue with Step 5: Rules with Context](step-5)
-- [Back to Step 3: The Keyboard Header](step-3)
\ No newline at end of file
+(Replaced by new walkthrough in v19)
\ No newline at end of file
diff --git a/developer/docs/help/guides/develop/tutorial/step-5.md b/developer/docs/help/guides/develop/tutorial/step-5.md
index 88a76bce34..5e2725a24e 100644
--- a/developer/docs/help/guides/develop/tutorial/step-5.md
+++ b/developer/docs/help/guides/develop/tutorial/step-5.md
@@ -1,76 +1,5 @@
---
-title: Step 5: Rules with Context
+redirect: .
---
-## Rules with Context
-
-Very often we want a keyboard to produce different output based on more
-than just the last keystroke. For example, in the Quick French keyboard,
-we want the key e to produce one of è, é,
-ë, ê, or just e, depending on what was typed immediately before
-it. To do this we must make our rules look at the context.
-
-The context is the output from previous rules; that is, the characters
-that are displayed on the screen. We can make a rule work with only
-certain context by putting this before the plus sign in the rule:
-
-```keyman
-"^" + "e" > "ê"
-```
-
-With this rule, whenever an e is typed, if it
-was preceded by a caret (^), the output will be ê. It is important
-to remember that the context consists of **output
-from previous rules**, not the previous keystrokes. To emphasize
-this point, consider the four rules below:
-
-```keyman
-+ "a" > "b"
-+ "b" > "c"
-"b" + "c" > "d"
-"c" + "d" > "e"
-```
-
-With these rules, typing b c would produce the
-output `cc`, and not `d`, as you might initially expect. This is because
-the key b is converted by the second rule into
-the output `c`, while the third rule expects a context of b, and not
-c; we would have to type a c to get `d`.
-
-However, if a key has no matching rule, the output will be the same as
-the key: so the output `e` will be produced for either of the inputs c d (because c by itself has no rule), and b d.
-
-## Continuing the Quick French keyboard
-
-Now we know how to create context-dependent rules, we can continue
-making the Quick French keyboard. Let's start with the rules for
-acute-accented characters, using the ANSI codes from the table we
-prepared earlier:
-
-```keyman
-c lowercase characters with acute accent
-"'" + "a" > U+00E1
-"'" + "e" > U+00E9
-"'" + "i" > U+00ED
-"'" + "o" > U+00F3
-"'" + "u" > U+00FA
-"'" + "y" > U+00FD
-
-c uppercase characters with acute accent
-"'" + "A" > U+00C1
-"'" + "E" > U+00C9
-"'" + "I" > U+00CD
-"'" + "O" > U+00D3
-"'" + "U" > U+00DA
-"'" + "Y" > U+00DD
-```
-
-We can also create similar rules for the other thirty-odd accented
-characters.
-
-As you can see, even for a simple keyboard like this we quickly end up
-with a large number of rules, which makes for clumsiness. We can make
-things simpler using stores, and the `any()` and `index()` statements.
-
-- [Continue with Step 6: Stores, `any()`, and `index()`](step-6)
-- [Back to Step 4: The Keyboard Body](step-4)
\ No newline at end of file
+(Replaced by new walkthrough in v19)
\ No newline at end of file
diff --git a/developer/docs/help/guides/develop/tutorial/step-6.md b/developer/docs/help/guides/develop/tutorial/step-6.md
index 95ade8767c..5e2725a24e 100644
--- a/developer/docs/help/guides/develop/tutorial/step-6.md
+++ b/developer/docs/help/guides/develop/tutorial/step-6.md
@@ -1,116 +1,5 @@
---
-title: Step 6: Stores, any(), and index()
+redirect: .
---
-When we have many similar rules, as in the last example on the previous
-page, we can group them together into one rule by using stores. A store
-is a set of characters that are grouped under a single name. Stores are
-used in rules with the [`any()`](/developer/language/reference/any) and
-[`index()`](/developer/language/reference/index) statements. We create a
-store with a [`store()` statement](/developer/language/reference/store):
-
-```keyman
-store(vowels) "aeiou"
-```
-
-This creates a store called `vowels`, which contains the five lowercase
-vowels.
-> #### Note:
-We could also have written the content of the store
-using ANSI or Unicode character codes, in the same way as the output.
-
-The `any()` statement is used to match a character from a specific
-store. For example, the following rule will replace any vowel with a
-period, when used with the store above:
-
-```keyman
-+ any(vowels) > "."
-```
-
-The `any()` statement can be used in the context or in the key part of a
-rule. It cannot be used in the output.
-
-The second statement that is used with stores is the `index()`
-statement. It is usually used in the output of a rule, and will output
-the character from a particular store at the same position as the
-character matched by a specified `any()` statement. This is best shown
-with an example; this rule will convert all input to uppercase:
-
-```keyman
-store(lowercase) "abcdefghijklmnopqrstuvwxyz"
-store(uppercase) "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
-
-+ any(lowercase) > index(uppercase,1)
-```
-
-When a letter, such as j is typed, the `any()`
-statement finds its position in the `lowercase` store; the `index()`
-statement then gets this index from the `any()` statement, and outputs
-the character at the same position in the `uppercase` store, in this
-case `J`.
-
-The `index()` statement has two parts: the store from which it takes the
-output character, and the offset of the `any()` statement that it gets
-the character position from. This offset is found by counting the
-characters and statements in the context and key parts of the rule up to
-the `any()` statement. Again, a few examples may help to illustrate
-this:
-
-```keyman
-"a" + any(somestore) > index(otherstore,2) c The 'any' statement
- c is character #2
-"ab" any(somestore) + "c" > index(otherstore,3) c The 'any' statement
- c is character #3
-
-c Here the 'index' statement references the second 'any' statement used,
-c which is character #4
-U+0041 any(somestore) "B" + any(otherstore) > index(thirdstore,4)
-
-c You can have multiple 'index' statements in the output, which can
-c reference the same or different 'any's
-any(store1) + any(store2) > index(store1,2) index(store2,1) index(store3,2)
-```
-
-## Using stores in the Quick French keyboard
-
-We can now reduce the number of rules needed for the Quick French
-keyboard by using stores. We will make five stores: one for the
-unaccented vowels, and one each for vowels with acute accents, grave
-accents, circumflexes, and diereses. For clarity, the `group()`
-statement is repeated below:
-
-```keyman
-group(Main) using keys
-
-store( plainvowels ) 'a' 'e' 'i' 'o' 'u' 'A' 'E' 'I' 'O' 'U'
-store( acutevowels ) U+00E1 U+00E9 U+00ED U+00F3 U+00FA U+00C1 U+00C9 U+00CD U+00D3 U+00DA
-store( gravevowels ) U+00E0 U+00E8 U+00EC U+00F2 U+00F9 U+00C0 U+00C8 U+00CC U+00D2 U+00D9
-store( circumvowels ) U+00E2 U+00EA U+00EE U+00F4 U+00FB U+00C2 U+00CA U+00CE U+00D4 U+00DB
-store( dresisvowels ) U+00E4 U+00EB U+00EF U+00F6 U+00FC U+00C4 U+00CB U+00CF U+00D6 U+00DC
-
-"'" + any( plainvowels ) > index( acutevowels, 2 )
-"`" + any( plainvowels ) > index( gravevowels, 2 )
-"^" + any( plainvowels ) > index( circumvowels, 2 )
-'"' + any( plainvowels ) > index( dresisvowels, 2 )
-```
-
-This is far clearer than the long list of rules that we used earlier.
-Obviously we should add one or two more ordinary rules to produce uppercase
-and lower-case ç, ý, and also the angled quotes « and ». Then we
-will have almost finished the keyboard:
-
-```keyman
-"'" + "y" > U+00FD c Acute-accented Y
-"'" + "Y" > U+00DD
-
-"'" + "c" > U+00E7 c C-cedilla
-"'" + "C" > U+00C7
-
-"<" + "<" > U+00AB c Angled quotes
-">" + ">" > U+00BB
-```
-
-All we need to do now is to test the keyboard.
-
-- [Continue with Step 7: Testing the Keyboard](step-7)
-- [Back to Step 5: Rules with Context](step-5)
\ No newline at end of file
+(Replaced by new walkthrough in v19)
\ No newline at end of file
diff --git a/developer/docs/help/guides/develop/tutorial/step-7.md b/developer/docs/help/guides/develop/tutorial/step-7.md
index 2432bb76f4..5e2725a24e 100644
--- a/developer/docs/help/guides/develop/tutorial/step-7.md
+++ b/developer/docs/help/guides/develop/tutorial/step-7.md
@@ -1,52 +1,5 @@
---
-title: Step 7: Testing the Keyboard
+redirect: .
---
-# Compiling the Keyboard
-
-Before we can test the keyboard, we must compile it. Choose
-Keyboard, Compile
-Keyboard or press F7 to compile the
-keyboard. The Message window will display the results of the
-compilation; if you have no typing errors, the keyboard should compile
-successfully.
-
-If there are any mistakes, an error message will be displayed in the
-Message window, which will tell you the line on which the error
-occurred.
-
-## Compiling the Keyboard
-
-After compiling the keyboard successfully, we can start testing it.
-Choose Debug,
-Start Debugging or press
-F5 to begin testing. The Keyboard debug window
-will appear.
-
-Now we test that all the rules operate as expected. To test the rules,
-we type the keystrokes that will give us the output; for example, we can
-type a quote ' followed by one of
-A, E,
-I, O,
-U, or Y to test the
-uppercase acute-accented vowels. Similarly we can test the other
-accents, and C-cedilla (`Ç`) and the angled quotes. If the rules are
-correct, all this should work as we wanted.
-
-Testing the rules in isolation like this will show if the rules are
-correct or not, but won't show other possible errors that might occur in
-everyday usage of the keyboard. For example, look at what happens if you
-type the following quote:
-
-> `'Alors Alice demande, "Où est mon chat ?"'`
-
-As you can see, it comes out incorrectly as:
-
-> `Álors Alice demande, Öù est mon chat ?"'`
-
-The problem occurs when we have a word in quotes that begins with a
-vowel: the keyboard will convert it to an accented vowel. We will need
-to come up with a solution to this problem.
-
-- [Continue with Step 8: Deadkeys](step-8)
-- [Back to Step 6: Stores, `any()`, and `index()`](step-6)
\ No newline at end of file
+(Replaced by new walkthrough in v19)
\ No newline at end of file
diff --git a/developer/docs/help/guides/develop/tutorial/step-8.md b/developer/docs/help/guides/develop/tutorial/step-8.md
index 52f532ce76..5e2725a24e 100644
--- a/developer/docs/help/guides/develop/tutorial/step-8.md
+++ b/developer/docs/help/guides/develop/tutorial/step-8.md
@@ -1,78 +1,5 @@
---
-title: Step 8: Deadkeys
+redirect: .
---
-## Solving the Problem
-
-Probably the easiest solution to the problem which we encountered on the
-last page is to design the keyboard so that the user types a quote key
-twice when they want to produce a quote, but once when they want to use
-it as an accent. However, we cannot simply use the rule:
-
-```keyman
-"'" + "'" > "'"
-```
-
-This will certainly produce a single quote after it's typed twice;
-however it will still produce the same error, because the following
-keystroke will continue to swallow the quote character from the context.
-We need to distinguish between the output of this rule, when the user
-wants a quote, and that of a single quote press, when the user wants to
-place an accent on a vowel. To implement this behaviour, we use
-[deadkeys](/developer/language/reference/deadkey).
-
-## Deadkeys
-
-A deadkey is like a character that is used in the context or output but
-never appears on the screen. We use deadkeys like this:
-
-```keyman
-+ "'" > deadkey(quote)
-
-c Handle acute accents
-deadkey(quote) + any( plainvowels ) > index( acutevowels, 2 )
-
-c Handle a single quote
-deadkey(quote) + "'" > "'"
-```
-
-Note that for the sake of convenience, a deadkey can also be written in
-a short form:
-
-```keyman
-dk(quote) c This is identical to deadkey(quote)
-```
-
-Type the three rules above in place of the existing rule for acute
-accents in the keyboard so far. If you test the keyboard now, you will
-find that the error no longer occurs. This is because accented vowels
-are only produced after the deadkey, and no deadkey is output if the
-user types a quote key twice.
-
-But we've introduced another difference to the keyboard now: the quote
-is no longer displayed before you type the vowel. This is because we are
-converting the quote to a deadkey. If we prefer, we can still
-distinguish between rules in the above manner and display the quote, if
-we just add a quote before the deadkey, like this:
-
-```keyman
-+ "'" > "'" dk(quote)
-
-c Handle acute accents
-"'" dk(quote) + any( plainvowels ) > index( acutevowels, 3 )
-
-c Handle a single quote
-"'" dk(quote) + "'" > "'"
-```
-
-However, we will not use this technique for the Quick French keyboard.
-
-Now we can make changes so that all the other accents use deadkeys as
-well, for consistency, and add rules to output the accent character by
-typing the key twice.
-
-The Quick French keyboard is now complete. The full source is on the
-next page.
-
-- [Continue with Step 9: The Finished Keyboard](step-9)
-- [Back to Step 7: Testing the Keyboard](step-7)
\ No newline at end of file
+(Replaced by new walkthrough in v19)
\ No newline at end of file
diff --git a/developer/docs/help/guides/develop/tutorial/step-9.md b/developer/docs/help/guides/develop/tutorial/step-9.md
index 03e00a2787..5e2725a24e 100644
--- a/developer/docs/help/guides/develop/tutorial/step-9.md
+++ b/developer/docs/help/guides/develop/tutorial/step-9.md
@@ -1,66 +1,5 @@
---
-title: Step 9: The Finished Keyboard
+redirect: .
---
-## The Quick French Keyboard
-
-Here is the completed keyboard:
-
-```keyman
-c Simplified French Keyboard for Keyman 9.0
-c
-c This keyboard program uses a simplified set of keys
-c for typing French, especially for those who don't know the
-c standard French keyboard.
-c
-c NOTE: This keyboard was created from the Keyman keyboard
-c programming tutorial.
-
-store(&Version) "9.0" c This keyboard is for use with Keyman 9.0
-store(&Name) "Quick French"
-store(&Bitmap) "qfrench.ico"
-store(&MnemonicLayout) "1" c This keyboard uses a mnemonic layout.
-
-begin Unicode > use(Main)
-
-group( Main ) using keys
-
-c Store the upper and lowercase vowels with different accents
-store( plainvowels ) 'a' 'e' 'i' 'o' 'u' 'A' 'E' 'I' 'O' 'U'
-store( acutevowels ) U+00E1 U+00E9 U+00ED U+00F3 U+00FA U+00C1 U+00C9 U+00CD U+00D3 U+00DA
-store( gravevowels ) U+00E0 U+00E8 U+00EC U+00F2 U+00F9 U+00C0 U+00C8 U+00CC U+00D2 U+00D9
-store( circumvowels ) U+00E2 U+00EA U+00EE U+00F4 U+00FB U+00C2 U+00CA U+00CE U+00D4 U+00DB
-store( dresisvowels ) U+00E4 U+00EB U+00EF U+00F6 U+00FC U+00C4 U+00CB U+00CF U+00D6 U+00DC
-
-c Output deadkeys only for the accent keys pressed
-+ "'" > dk(quote) c Quote for acute accent
-+ "`" > dk(bkquote) c Backquote for grave accent
-+ "^" > dk(caret) c Caret for circumflex
-+ '"' > dk(dbquote) c Double-quote for dieresis
-
-c Rules for accented vowels
-dk(quote) + any( plainvowels ) > index( acutevowels, 2 )
-dk(bkquote) + any( plainvowels ) > index( gravevowels, 2 )
-dk(caret) + any( plainvowels ) > index( circumvowels, 2 )
-dk(dbquote) + any( plainvowels ) > index( dresisvowels, 2 )
-
-c Rules for other characters
-dk(quote) + "y" > U+00FD c Acute-accented Y
-dk(quote) + "Y" > U+00DD
-
-dk(quote) + "c" > U+00E7 c C-cedilla
-dk(quote) + "C" > U+00C7
-
-"<" + "<" > U+00AB c Angled quotes
-">" + ">" > U+00BB
-
-c Rules for the accent character itself (type it twice)
-dk(quote) + "'" > "'" c Quote
-dk(bkquote) + "`" > "`" c Backquote
-dk(caret) + "^" > "^" c Caret
-dk(dbquote) + '"' > '"' c Double-quote
-
-c End of keyboard
-```
-
-- [Back to Step 8: Deadkeys](step-8)
\ No newline at end of file
+(Replaced by new walkthrough in v19)
\ No newline at end of file
diff --git a/developer/docs/help/guides/distribute/__index.txt b/developer/docs/help/guides/distribute/__index.txt
new file mode 100644
index 0000000000..807ccfd46b
--- /dev/null
+++ b/developer/docs/help/guides/distribute/__index.txt
@@ -0,0 +1,4 @@
+-install-kmp-android.md
+-install-kmp-ios.md
+-packages.md
+-tutorial
\ No newline at end of file
diff --git a/developer/docs/help/guides/distribute/index.md b/developer/docs/help/guides/distribute/index.md
index 4ffe845c38..f69eee8972 100644
--- a/developer/docs/help/guides/distribute/index.md
+++ b/developer/docs/help/guides/distribute/index.md
@@ -1,10 +1,8 @@
---
-title: Distributing keyboards
+title: Package Tutorial
---
-- [Package development tutorial](tutorial) (Keyman for Windows, Keyman for macOS, Keyman for mobile apps)
-- [Distribute keyboards to Keyman applications](packages)
+In version 19, the Package Tutorial has been replaced by the Keyman
+Developer Walkthrough, which covers all the topics in greater depth.
-## See also
-
-- [Keyman Engine](/developer/engine/)
\ No newline at end of file
+* [The Keyman Developer Walkthrough →](../walkthrough/08-preparing-keyboard-package)
diff --git a/developer/docs/help/guides/distribute/install-kmp-android.md b/developer/docs/help/guides/distribute/install-kmp-android.md
index bdba196c90..5e2725a24e 100644
--- a/developer/docs/help/guides/distribute/install-kmp-android.md
+++ b/developer/docs/help/guides/distribute/install-kmp-android.md
@@ -1,78 +1,5 @@
---
-title: Installing Custom Keyboards to your Android Device
+redirect: .
---
-## Overview
-
-In [Keyman for Android 10.0](/products/android/10.0/), we added the ability to
-easily download/share custom keyboards to your Android device.
-
-## Installing a custom keyboard
-
-To install a custom keyboard, you will need a link to download the
-keyboard package. If you have already copied the kmp file onto the
-Android device, skip to Step 2.
-
-If you want to build and dev your own keyboard, you will need some
-technical skills for this, and can read our full step-by-step
-instructional on how to do this [here](packages).
-
-Once you have a website or email with a link to the keyboard package,
-follow these steps on your Android device to download and install the
-keyboard package into the Keyman for Android application:
-
-## Step 1) Click the link to save your custom keyboard package file
-
-The link in this example is for Khmer Angkor keyboard.
-
-
-
-## Step 2) Add Keyboard from Device
-
-Once the KMP file is on your device, you will need to browse to the KMP
-file and select it. From the Keyman menu, select "Settings". From the
-Keyman Settings menu, select "Add Keyboard from Device".
-
-
-
-The device will launch a file browser where you'll browse to the
-directory of your KMP file. A common places to look is the "Downloads"
-folder.
-
-
-
-Selecting the KMP file should bring you to Step 3)
-
-## Step 3) Grant Keyman for Android access to storage (Android 6.0+ only)
-
-On Android 6.0 (Marshmallow) and higher, mobile apps need to request
-permission to access storage. Keyman for Android needs access to read
-storage for installing the KMP file. At the dialog, select "ALLOW". Once
-authorized, Keyman for Android won't need to ask for storage permission
-again, unless the user revokes or uninstalls the app.
-
-
-
-Older versions of Android grant Storage permissions at app installation
-time, so those users can skip this step.
-
-## Step 4) Keyboard Package welcome screen
-
-Keyman for Android will parse the metadata in the package. If the
-keyboard package includes a "welcome.htm" file, this will be displayed
-at the confirmation to install the keyboard package
-
-
-
-If "welcome.htm" is not included, a generic page with the package ID and
-package version will be shown.
-
-Click the left "Install" button to install the entire keyboard package
-
-## Step 5) The keyboard is successfully installed!
-
-All the keyboards in the package are installed as a group. In this
-example, the package only has the "Khmer Angkor" keyboard, so it becomes
-the active keyboard
-
-
\ No newline at end of file
+(Replaced by new walkthrough in v19)
\ No newline at end of file
diff --git a/developer/docs/help/guides/distribute/install-kmp-ios.md b/developer/docs/help/guides/distribute/install-kmp-ios.md
index de4d3a64cb..5e2725a24e 100644
--- a/developer/docs/help/guides/distribute/install-kmp-ios.md
+++ b/developer/docs/help/guides/distribute/install-kmp-ios.md
@@ -1,53 +1,5 @@
---
-title: Installing Custom Keyboards to your iPhone or iPad
+redirect: .
---
-## Overview
-
-In version 10 of Keyman for iPhone and iPad, we added the ability to easily download custom keyboards to your iOS device.
-
-## Installing a custom keyboard
-
-To install a custom keyboard, you will first need a link to the keyboard
-package on a website or in your email.
-
-If you want to build and dev your own keyboard, you will need some
-technical skills for this, and can read our full step-by-step
-instructional on how to do this [here](packages).
-
-Once you have a website or email with a link to the keyboard package,
-follow these steps on your iPhone or iPad to download and install the
-keyboard package into the Keyman for iPhone and iPad application:
-
-## Step 1) Click the link to your custom keyboard package file
-
-The link in this example is for GFF Amharic 7 keyboard.
-
-
-
-Safari will display an option to open the KMP file with Keyman
-
-
-
-## Step 2) Click Open in "Keyman"
-
-Keyman for iPhone and iPad will parse the metadata in the package. If
-the keyboard package includes a "welcome.htm" file, this will be
-displayed at the confirmation to install the keyboard package
-
-
-
-If "welcome.htm" is not included, a generic page with the package ID and
-package version will be shown.
-
-## Step 3) Click the top right "Install" button
-
-The keyboard from the keyboard package is successfully installed!
-
-
-
-All the keyboards in the package are installed as a group. In this
-example, the package only has the "GFF Amharic 7" keyboard, so it
-becomes the active keyboard
-
-
+(Replaced by new walkthrough in v19)
\ No newline at end of file
diff --git a/developer/docs/help/guides/distribute/packages.md b/developer/docs/help/guides/distribute/packages.md
index 5bc1e7de80..5e2725a24e 100644
--- a/developer/docs/help/guides/distribute/packages.md
+++ b/developer/docs/help/guides/distribute/packages.md
@@ -1,131 +1,5 @@
---
-title: Distribute keyboards to Keyman Applications
+redirect: .
---
-## Overview
-
-Keyboard package files contain one or more keyboards, along with readme
-files, fonts (if your keyboard requires a custom font), and any other
-files you wish to include. You should create a package file to bundle
-your keyboard with fonts and help into a simple, single file that is
-easy for an end-user to install.
-
-Internally, as well as your own files, the package file will contain
-metadata files "kmp.inf" and "kmp.json", which list the details Keyman
-needs to install the package. The package file is a ZIP compatible
-archive.
-
-> ### Tip
-You can distribute keyboards and lexical models in package files, but
-you can't include both in the same package file.
-
-#### Keyman for Windows
-
-Keyman for Windows can install package files, including installing fonts,
-creating Start Menu shortcuts, and adding appropriate registry entries
-for uninstallation.
-
-On Windows, the context menu for a package file has one additional
-entry: "Install".
-
-#### Keyman for macOS
-
-Keyman for macOS can install package files with fonts and keyboards, and
-shortcuts in the package will be available through the keyboard's entry
-in Keyman Configuration.
-
-#### Keyman for Android and Keyman for iPhone and iPad
-
-Keyman mobile applications can install the same package files as Keyman
-for Windows, as long as the package includes keyboards for touch layouts.
-
-## Package file contents
-
-A package can have a variety of different files contained within. The
-following files and file types are recognized by the package installer:
-
-\*.kmx (Keyman for Windows, Linux, and macOS only)
-: Keyboard files. Each of these will be installed. Keyman
- Configuration will not allow installation or uninstallation of a
- single keyboard from a package. They will always be treated as a
- group for installation and uninstallation.
-
-\*.kvk (Keyman for Windows, Linux, and macOS only)
-: On Screen Keyboard files, associated with each keyboard file.
-
-\*.js (mobile only)
-: Touch layout Keyboard files. When Keyman mobile applications install
- a keyboard package, all included keyboards will be installed as a
- group. With Keyman Developer 10, the keyboard version information is
- in kmp.json, and no longer within the JS file names.
-
-welcome.htm
-: Introductory help for the keyboard, HTML format. This will normally
- be displayed when the package is installed by the user, and is also
- the entry point for help when accessed via Keyman's help system or
- Keyman Configuration.
-
-readme.htm
-: Displayed before a package is installed, together with brief
- metadata about the package, to allow the user to determine if they
- wish to continue installation of the package.
-
-kmp.inf (Legacy versions of Keyman)
-: A Windows .ini format file that lists each of the files in the
- package, together with metadata.
-
-kmp.json
-: A JSON format file contains metadata for the keyboard package such
- as package version, keyboard versions, and lists each of the files
- in the package. For more explanation of the structure of the JSON
- file, please read the
- [metadata](../../reference/file-types/metadata) documentation.
-
-\*.ttf, \*.otf, \*.ttc
-: Truetype font files that will be installed with the package, and
- uninstalled when the package is removed. On mobile, these fonts will
- be available only within the Keyman app and the on-screen-keyboard,
- not in other apps.
-
-## Share the keyboard package file
-
-> ### Tip
-Read [Step 2: Organizing the Keyboard Files](../../../keyboards/github/step-2)
-to know which files to include or exclude in the keybord folder.
-
-Once the keyboard package .kmp file is created, you can share them via
-external storage devices (USB drive, SD card, etc). You can also share
-the package file via a cloud storage system (Google Drive, Dropbox or
-similar service), then share the link to your device via text, note or
-email. Alternatively, you can upload the .kmp file to a public facing
-website. For this example, the keyboard package for Khmer Angkor is
-being uploaded:
-
-1. khmer_angkor.kmp (the keyboard package .kmp file)
-
-## Putting the keyboard package on a website
-
-Once all the files have been uploaded, you will need to provide a link
-to the keyboard package .kmp file for your device to download and
-install. This can either be a link on a web page, or a link in an email.
-In this tutorial, a very simple .html web page with a link to the
-khmer_angkor.kmp file is created:
-
-``` markup
-
-
-
-
- Custom Keyboard URL
-
-
-```
-
-The link must be in the format `http://` or `https://`
-
-Upload the web page to your public facing website. Once done, you can
-install the keyboard package onto your mobile devices by following these
-steps:
-
-- [Installing custom keyboards to your iPhone or iPad](install-kmp-ios)
-- [Installing custom keyboards to your Android device](install-kmp-android)
+(Replaced by new walkthrough in v19)
\ No newline at end of file
diff --git a/developer/docs/help/guides/distribute/tutorial/index.md b/developer/docs/help/guides/distribute/tutorial/index.md
index 89bc2eb2a9..7505708ee1 100644
--- a/developer/docs/help/guides/distribute/tutorial/index.md
+++ b/developer/docs/help/guides/distribute/tutorial/index.md
@@ -1,36 +1,5 @@
---
-title: Package Tutorial
+redirect: ..
---
-[Step 1: What do we include?](step-1)
-
-[Step 2: Creating Additional Files for the Package](step-2)
-
-[Step 3: Creating a package and adding files](step-3)
-
-[Step 4: Filling in package details](step-4)
-
-[Step 5: Shortcuts](step-5)
-
-[Step 6: Compiling, testing and distributing a Package](step-6)
-
-## Overview
-
-Welcome! In this tutorial, you will learn how to create a
-[package](../../../reference/file-types/kmp). A package is a collection
-of files, compressed into a single file, just like a ZIP file. It is
-designed to make installation of keyboards, fonts and related
-documentation straightforward for the end user. When done, the package
-can be installed into Keyman for Windows through a simple dialog. Keyman for
-mobile apps can also download and install keyboards through the keyboard
-package.
-
-We will be creating a Khmer Angkor package. You can make your own
-package based on the Quick French keyboard from the [keyboard tutorial](../../develop/tutorial).
-
-### Let's begin
-
-Let's get started! Move on to the next topic to begin the first step,
-choosing what to include in the package.
-
-[Step 1: What do we include?](step-1)
+(Replaced by new walkthrough in v19)
\ No newline at end of file
diff --git a/developer/docs/help/guides/distribute/tutorial/step-1.md b/developer/docs/help/guides/distribute/tutorial/step-1.md
index a18fce49ac..7505708ee1 100644
--- a/developer/docs/help/guides/distribute/tutorial/step-1.md
+++ b/developer/docs/help/guides/distribute/tutorial/step-1.md
@@ -1,35 +1,5 @@
---
-title: Step 1: What do we include?
+redirect: ..
---
-What is the purpose of a package? To make installation of a keyboard,
-fonts, documentation, and on screen keyboard as straightforward as
-possible for the end user.
-
-We need to keep this goal in mind as we work on all the aspects of a
-package.
-
-A good package will:
-
-1. Collect the keyboard and font files together for simple installation
-2. Include Start Menu items for documentation
-
-A great package will also:
-
-1. Include a 'readme' visible before install.
-2. Include a 'welcome.htm' file which is displayed after install.
-3. Include an On Screen Keyboard if relevant.
-4. Include documentation on use of the keyboard.
-
-Packages uploaded to the Tavultesoft website will get basic icon ratings
-reflecting their ease of install/use:
-
--  includes fonts
--  includes documentation
--  includes on screen keyboards
--  includes welcome.htm
-
-In general, the more icons that a package earns, the easier that end
-users will find it to start using.
-
-[Step 2: Creating Additional Files for the Package](step-2)
\ No newline at end of file
+(Replaced by new walkthrough in v19)
\ No newline at end of file
diff --git a/developer/docs/help/guides/distribute/tutorial/step-2.md b/developer/docs/help/guides/distribute/tutorial/step-2.md
index 7ed9aea576..7505708ee1 100644
--- a/developer/docs/help/guides/distribute/tutorial/step-2.md
+++ b/developer/docs/help/guides/distribute/tutorial/step-2.md
@@ -1,127 +1,5 @@
---
-title: Step 2: Creating Additional Files for the Package
+redirect: ..
---
-You should create or select some additional files for a package. Below
-are a list of the typical files that you would create for or include in
-a package.
-
-readme.htm
-
-: A short description of the package, its use restrictions, and what
- it includes. Try to keep the readme under 10 lines long. The readme
- is displayed in the package install dialog and should be an html
- file for optimal formatting.
-
- > ### Tip
- As the package has not been installed at this stage, and you are using fonts that may not yet be available on the target device, you should use CSS @font-face declarations to ensure that the text is readable on all devices.
-
- Create the HTML file in any HTML editor.
-
- > ### Tip
- If using Microsoft Word, choose HTML (clean) when saving to create a smaller file.
-
- Note, if your HTML editor puts images into a subfolder, you will need to edit the HTML source so that all files are in the same folder -- the package builder will not maintain subfolders. You can easily edit the HTML source in Keyman Developer.
-
- Also, if your welcome or readme files use embedded external images, stylesheets, javascript or other files, you will need to add these files to your package as well.
-
-welcome.htm
-
-: When including an introductory help file in your package, you must
- name the file welcome.htm. This file will be detected during install
- and displayed (in a window roughly two thirds of the user's screen
- width) after the package install completes successfully. Make sure
- that you design your HTML file so that it can be resized to fit the
- user's screen - avoid extra wide tables or wide fixed width
- elements.
-
- At this stage of the installation, fonts in the package have been installed, so you can include text that uses those fonts.
-
- Welcome.htm will also be accessible after installation from Keyman Configuration under the Package Options menu, and from the Keyboard Help item and On Screen Keyboard toolbar button.
-
- The intention of welcome.htm is to provide instructions on getting started with your keyboards.
-
- > ### Tip
- Useful information to include in welcome.htm is:
- - key sequences - especially for characters that may not be immediately obvious.
- - names of fonts in the package.
- - names of keyboards in the package.
- - links to additional help on your website or more extensive documentation files in the package.
- - a link to an official distribution site for your package (even
- if it is the Keyman website) - so that users know where to find
- the latest version of your package.
-
- You should avoid including instructions for the use of Keyman
- itself - although a basic "click the Keyman icon and choose Quick
- French" would be helpful.
-
- > ### Tip
- If you want links to your website to open in the user's preferred
- browser, preface the href link with `link:`, e.g.
- `website`
- The `link:` sceheme will open the referred file in the default
- application - that is, a web browser for URLs and links, Notepad for
- .txt files, Adobe Reader for PDFs. You can use `link:` to open any
- of the files in the package, e.g. `link:docs.pdf` will open the file
- docs.pdf in Adobe Reader or the default PDF reader on the system.
-
- To save you the effort of writing a welcome and readme file for the
- Quick French example, we have placed some in the Samples/QFrench
- folder.
-
- If you create documents in other formats, for example PDF or
- printable documentation, you should link to that in the welcome.htm.
-
- > ### Tip
- You can include multiple "welcome.htm" files for different languages
- by appending a hyphen and the BCP 47 language code to the filename,
- for example welcome-fr.htm for French.
-
-Fonts
-
-: A font is the single most important item to include with a keyboard
- – if the characters of the language you are supporting are not in
- fonts included with target operating systems. Installing fonts is
- tedious, so make sure that your users don't have to locate and
- install fonts themselves!
-
- .TTF, .OTF, and .TTC fonts will be installed by the package
- installer, and uninstalled when the package is uninstalled. A list
- of the fonts installed is displayed in the Install Package dialog.
-
-Keyboards
-
-: Add the .kmx compiled Keyman keyboards to the package. You can add
- multiple keyboards to the package, but be judicious.
-
- > ### Tip
- Don't forget to add the On Screen keyboard .KVK file associated with
- your keyboard to the package. KVK files are not compiled into the
- .KMX file -- although the .ICO/.BMP is.
-
- Add the .js compiled Keyman touch layout keyboards to the package.
-
-Documentation
-
-: The two preferred documentation formats are HTML and PDF. You should
- avoid .DOC, .RTF, and other formats -- .DOC files in particular are
- not recommended due to the possibility of macro viruses.
-
- Remember that HTML files can be displayed on any computer without
- additional software. PDF files require Adobe Reader or a compatible
- PDF viewer application. You may choose to include both and HTML
- documentation - PDF documents often print better than HTML
- documents, but HTML documentation is more accessible and translates
- better to on-screen or web use.
-
- > ### Tip
- If you use HTML, don't forget to also add all the included files
- such as images and stylesheets!
-
-Splash Image
-: The splash image is a 140x250 pixel image that is displayed when the
- package is installed, at the left of the Package Install dialog.
- Including a splash image makes your package look more professional
- and polished, so a splash image is recommended!
-
-[Step 3: Creating a package and adding files](step-3)
\ No newline at end of file
+(Replaced by new walkthrough in v19)
\ No newline at end of file
diff --git a/developer/docs/help/guides/distribute/tutorial/step-3.md b/developer/docs/help/guides/distribute/tutorial/step-3.md
index 657f2cd02b..7505708ee1 100644
--- a/developer/docs/help/guides/distribute/tutorial/step-3.md
+++ b/developer/docs/help/guides/distribute/tutorial/step-3.md
@@ -1,31 +1,5 @@
---
-title: Step 3: Creating a package and adding files
+redirect: ..
---
-We are finally ready to open up the Package Editor and create the new
-package.
-
-- In the Project Window in Keyman Developer, click the **Packages** tab, and click **New Package...**. Enter the path and filename of the package you are creating.
-
-> ### Tip
-This tutorial makes a package named `khmer_angkor.kps`, but you could call yours `qfrench.kps`.
-
-A package source file will have the extension .kps, and will be compiled in a file with extension .kmp.
-
-After you click OK, the Package Editor will open with the Files tab visible.
-
-
-
-- In the Files tab, click **Add...** to add
- all the files we discussed in the previous step to the package. You
- can add multiple files at once, and from multiple folders. When the
- package is compiled, all the files will be placed in the same folder
- within the package.
-- If your package includes .js touch layout keyboards, you can
- associate fonts and languages in the Keyboards tab. A valid [BCP 47 language tag](../../../reference/bcp-47) must be set or the keyboard will not install on your mobile device.
-
-
-
-You could stop here. This would be a completely valid package, but it would not be as good as it could be. So let's continue on to the next step, and fill in some descriptions of the package.
-
-[Step 4: Filling in package details](step-4)
\ No newline at end of file
+(Replaced by new walkthrough in v19)
\ No newline at end of file
diff --git a/developer/docs/help/guides/distribute/tutorial/step-4.md b/developer/docs/help/guides/distribute/tutorial/step-4.md
index fcebc042f6..7505708ee1 100644
--- a/developer/docs/help/guides/distribute/tutorial/step-4.md
+++ b/developer/docs/help/guides/distribute/tutorial/step-4.md
@@ -1,63 +1,5 @@
---
-title: Step 4: Filling in package details
+redirect: ..
---
-Click on the Details tab in the Package Editor. You should fill in as
-many details as you can on this page.
-
-
-
-Package Name
-
-: The Package Name will be displayed in the package install dialog,
- and within Keyman Configuration, wherever the package is
- referred to.
-
-Readme File
-
-: Select the readme file from the list of files you added in the
- previous step. Remember that it should be a HTML file for optimum
- clarity.
-
-Version
-
-: A version number for the package is important - it helps the your
- users know that they are using the most recent update of your
- package. The version format you should use is `1.0`. When making a
- major change to your package or keyboards in your package, increment
- the first part and set the second part to, e.g. `2.0`; when making a
- bug fix or a minor update, increment the second part, e.g. `1.1`.
-
-Version numbers should be in the form `major.minor[.subversion]`.
- Subversion is optional but is helpful for small bug fix releases.
- Each of the sections of the version should be an integer. Keyman
- for Windows does integer comparisons on the version numbers, so, for
- example, version `2.01` is regarded as older than version `2.2`.
- Alphabetic or date formats should be avoided as the installer for
- the keyboard cannot determine which version is older reliably.
-
-Copyright
-
-: Enter copyright details for your package and keyboards. Keep this
- reasonably short or it won't be clear for end users.
-
-Author
-
-: Enter your name or the name of your company.
-
-Email
-
-: Enter a contact email address where package users can contact you.
- If you don't want to be contacted via email, leave this field empty
-
-Website
-
-: Enter the name of the website where you will have information about
- this keyboard. If you want to host it on keyman.com, you could enter
- `https://keyman.com/`
-
-Image file
-: Select the splash image file that you created in Step 2 from the
- list of files in your package.
-
-[Step 5: Shortcuts](step-5)
+(Replaced by new walkthrough in v19)
\ No newline at end of file
diff --git a/developer/docs/help/guides/distribute/tutorial/step-5.md b/developer/docs/help/guides/distribute/tutorial/step-5.md
index f8c89fd635..7505708ee1 100644
--- a/developer/docs/help/guides/distribute/tutorial/step-5.md
+++ b/developer/docs/help/guides/distribute/tutorial/step-5.md
@@ -1,49 +1,5 @@
---
-title: Step 5: Shortcuts
+redirect: ..
---
-Click on the Shortcuts tab in the Package Editor.
-
-
-
-While it may be a good idea to include Start Menu shortcuts for your
-package, on recent versions of Windows these are not very visible to end
-users. This means that you should ensure that all instructions are
-available through the **welcome.htm** file as well. The Start Menu
-shortcuts were designed originally for Windows-based keyboard packages
-and work slightly differently in macOS.
-
-You should consider adding the following items to the Start Menu:
-
-- Documentation shortcuts
-- Welcome.htm shortcut
-
-> ### Note
-While Keyman Developer 8.0 and earlier versions of the documentation
-advised including an uninstall shortcut to the package, this is no
-longer recommended. Users should uninstall your package from Keyman
-Configuration. Adding an uninstall shortcut to the package adds
-confusion to the Start Menu search on Windows, and is not compatible
-with macOS keyboards.
-
-Click **New** to add a new shortcut to the
-package. Enter a description for the shortcut, and select the program or
-file to start from the Program list. Four predefined program entries
-(Start Product), (Product Configuration), (Product Help) and (About
-Product) will be translated into the appropriate shortcuts to start
-Keyman for Windows tasks as described.
-
-> ### Note
-In Keyman 6 and earlier, the predefined targets $KEYMAN\keyman.exe and
-$KEYMAN\kmshell.exe were available. These are translated to (Start
-Product) and (Product Configuration), respectively, in Keyman
-7.0 and later versions.
-
-
-
-> ### Tip
-Packages are not listed in the Control Panel Add/Remove Programs applet
-with Keyman 7.0 and later versions. Packages can be uninstalled
-through the Start Menu shortcut or from Keyman Configuration.
-
-[Step 6: Compiling, testing and distributing a Package](step-6)
+(Replaced by new walkthrough in v19)
\ No newline at end of file
diff --git a/developer/docs/help/guides/distribute/tutorial/step-6.md b/developer/docs/help/guides/distribute/tutorial/step-6.md
index 374584c3e1..7505708ee1 100644
--- a/developer/docs/help/guides/distribute/tutorial/step-6.md
+++ b/developer/docs/help/guides/distribute/tutorial/step-6.md
@@ -1,68 +1,5 @@
---
-title: Step 6: Compiling, testing and distributing a Package
+redirect: ..
---
-In the Package Editor, click on the **Compile** tab.
-
-
-
-Click **Compile Package** to compile the
-package into a .kmp file. Compiling takes all the files listed for the
-package, compresses them (using a .ZIP-compatible format) and adds the
-package information, all into a single file. If any files are not
-available, an error will be listed in the Messages window.
-
-After compiling, you can test the package installation in Keyman
-Desktop, by clicking **Install Package**. You
-should test that all the keyboards and fonts install successfully, that
-the Readme and Welcome files are displayed during the install, and that
-the documentation is accessible to the end user. Make sure that the On
-Screen Keyboard installs with your keyboards, and that the shortcuts are
-correctly listed and working in the Start Menu.
-
-> ### Advice
-The distribution model for Keyman keyboards is changing. We now
-recommend distributing source for keyboards through the [Keyman Cloud Keyboard Repository](/developer/keyboards/). The instructions here
-remain, but the binary distribution model is deprecated.
-
-## Distributing a package on the Keyman Cloud Keyboard Repository
-
-Once you have tested the package to your satisfaction, it is time to
-distribute it. We recommend uploading your keyboard package to the
-[Keyman Cloud Keyboard Repository](/developer/keyboards/)
-
-## Distributing a package on your own website
-
-If you distribute a package on your own site, we have the following
-recommendations:
-
-1. Ensure the MIME type on the web server or folder for .KMX and .KMP
- files is set up to application/octet-stream. Without this, .KMP
- files may be recognised as .ZIP files -- this is not helpful to the
- end user as it will be opened in the wrong application. If you can't
- make this change, consider hosting the keyboard package on the
- Tavultesoft website to make things easier for your end user.
-2. Avoid putting the .KMP file in an archive (e.g. .ZIP) or
- self-expanding archive (.EXE) - this makes it harder for end users
- to install. A .KMP file is already compressed (it is actually just a
- ZIP archive file!) and you won't save much space by recompressing
- it.
-3. Include a link to the Keyman download page:
- `http://keyman.com/desktop/`
-
-## Distributing a package by email
-
-Attaching the KMP file directly to an email may be blocked for security
-reasons. As mentioned above, a KMP file is basically a ZIP file and
-mobile keyboard data is in JavaScript, this is a combination that looks
-suspicious to many email servers. You can upload it to a Google drive,
-and email a link for downloading the file
-
-You may need to do some exploring to get your mobile device to load the
-keyboard from the KMP file into Keyman. The device may not open the file
-directly, claiming it is an unrecognized type. If you look for other
-options to open the file, hopefully you can get it to Keyman. For
-example, in iOS, I had to tap on the three dots to the right, then
-choose "Open in" and then I could choose "Copy to Keyman." In Android, I
-had to download the file to my device, then open the KMP file in a file
-manager before I could install it in Keyman.
\ No newline at end of file
+(Replaced by new walkthrough in v19)
\ No newline at end of file
diff --git a/developer/docs/help/guides/index.md b/developer/docs/help/guides/index.md
index 55604780ad..f36d44bbd3 100644
--- a/developer/docs/help/guides/index.md
+++ b/developer/docs/help/guides/index.md
@@ -5,9 +5,8 @@ title: Keyman Developer Guides
Need help using Keyman Developer? You'll find everything you need here, including product documentation, frequently asked questions and tutorials.
- [Introduction to Keyman Developer](intro)
-- [Developing Keyman keyboards](develop/)
-- [Testing Keyman keyboards](test/)
-- [Distributing Keyman keyboards](distribute/)
+- [The Keyman Developer Walkthrough](walkthrough)
- [Developing Keyman lexical models (for predictive text and autocorrect)](lexical-models/)
+- [Testing Keyman keyboards and lexical models](test/)
- [Distributing Keyman lexical models](lexical-models/distribute/)
-- [Keyman Developer command line tools guide](command-line)
\ No newline at end of file
+- [Keyman Developer command line tools guide](command-line)
diff --git a/developer/docs/help/guides/test/keyboard-touch-and-desktop.md b/developer/docs/help/guides/test/keyboard-touch-and-desktop.md
index 9db50afbbb..5e7a9a7575 100644
--- a/developer/docs/help/guides/test/keyboard-touch-and-desktop.md
+++ b/developer/docs/help/guides/test/keyboard-touch-and-desktop.md
@@ -133,17 +133,3 @@ installed, across all apps.
You can test multiple keyboards just by clicking **Test Keyboard on
web** in each keyboard editor.
-## Related articles
-
-Other articles on developing touch layouts:
-
-- [Creating a touch keyboard layout for Amharic - part
- 1](../develop/creating-a-touch-keyboard-layout-for-amharic)
-- [Creating a touch keyboard layout for Amharic - the nitty
- gritty](../develop/creating-a-touch-keyboard-layout-for-amharic-the-nitty-gritty)
-
-You can distribute your keyboard to other users by following the
-instructions in this article:
-
-- [Distribute keyboards to Keyman
- applications](../distribute/packages)
diff --git a/developer/docs/help/guides/test/keyboard-touch-mobile-emulator.md b/developer/docs/help/guides/test/keyboard-touch-mobile-emulator.md
index fb68b11f2b..6c7afc034d 100644
--- a/developer/docs/help/guides/test/keyboard-touch-mobile-emulator.md
+++ b/developer/docs/help/guides/test/keyboard-touch-mobile-emulator.md
@@ -47,15 +47,5 @@ You can now test the keyboard layout and get an idea of how it will feel
on a real touch device. Rotation, or changing device types will require
a page load (F5) in order to render correctly.
-- [Creating a touch keyboard layout for Amharic - part
- 1](../develop/creating-a-touch-keyboard-layout-for-amharic)
-- [Creating a touch keyboard layout for Amharic - the nitty
- gritty](../develop/creating-a-touch-keyboard-layout-for-amharic-the-nitty-gritty)
- [How to test your keyboard layout — touch and
desktop](keyboard-touch-and-desktop)
-
-You can distribute your keyboard to other users by following the
-instructions in this article:
-
-- [Distribute keyboards to Keyman
- applications](../distribute/packages)
diff --git a/developer/docs/help/guides/walkthrough/00-introduction.md b/developer/docs/help/guides/walkthrough/00-introduction.md
new file mode 100644
index 0000000000..0577ecef53
--- /dev/null
+++ b/developer/docs/help/guides/walkthrough/00-introduction.md
@@ -0,0 +1,87 @@
+---
+title: Introduction
+---
+
+
+
+
+## Step-by-Step
+
+The Step-by-Step tutorial starts with an introduction to the Keyman Developer program and instructions on installing it. Then use the link to advance to the next topic and complete the Step-by-Step section there. Continue on through all the topics, completing the Step-by-Step section and moving on to the next topic by using the link at the end of each Step-by-Step section.
+
+If you encounter unfamiliar terms, please consult the [glossary](glossary).
+
+### Introducing Keyman Developer
+
+Keyman Developer is a powerful tool you can use to create custom software keyboards optimized to type in any language you choose. Keyboard authors can distribute their work for desktop, web, tablet and phone, enabling global communities to quickly benefit from keyboards made for their own language.
+
+Keyboards created with Keyman Developer can be used on Windows, macOS, Linux, iOS, Android, and the web.
+
+This tutorial focuses on the Keyman Developer IDE (integrated development environment).
+Currently this software is Windows-only, although the command line tools it uses can run on other platforms (such as Linux and macOS).
+
+### Installing Keyman Developer
+
+Keyman Developer is completely free to download and use. You can download it from [https://keyman.com/developer/download](https://keyman.com/developer/download).
+
+On the downloads page, just click the big green “Download Now” button to get the latest version of Keyman. Once you have it, run the `keymandeveloper-a.b.c.exe` file you’ve downloaded. The numbers following “keymandeveloper” indicate which version of Keyman Developer you are installing; you can also see the Keyman Developer version in the main installer window, or after installation, in the Help/About dialog.
+
+After installing Keyman Developer, you should be able to run it on your computer and begin creating projects immediately.
+
+Note that Keyman Developer is a separate app from Keyman, which is the app that lets you use any keyboard created with Keyman Developer.
+In order to use the keyboard you create with Keyman Developer, you'll need to have the Keyman app installed on your computer or device.
+Keyman is available on the following platforms: Windows, macOS, Linux, iOS, Android, and the web.
+
+The Keyman Developer icon  is a faded version of the Keyman icon .
+
+
+
+---
+
+
+## Engaging with the Keyman Community and Resources
+
+Keyman Developer also has an active community and documentation for each major release of the app. If you need any additional help, be sure to visit the following resources for information:
+
+### Keyman Community Forum
+
+Ask questions and talk with other keyboard authors on the [Keyman Community Forum](https://community.software.sil.org/c/keyman/19)
+
+### Keyman online help
+
+[Keyman Developer Language Guide](https://help.keyman.com/developer/language/guide/)
+
+Information about the general structure and concepts of the Keyman language.
+
+[Keyman Developer Language Reference](https://help.keyman.com/developer/language/reference/)
+
+Reference for keywords and other components of the Keyman language.
+
+[Keyman Developer Training Videos](https://help.keyman.com/developer/videos)
+
+Videos from past Keyman Developer workshops hosted by the team.
+
+### Keyman Blog
+
+Read up on Keyman’s latest releases and patch notes on the [Keyman Blog](https://blog.keyman.com/).
+
+### Keyman GitHub repositories
+
+Keyman uses a number of [Github](https://github.com/keymanapp) repositories to store source code, keyboards, lexical models and documentation.
+There is also a mechanism for reporting problems. [Keyman Bug Reports](https://github.com/keymanapp/keyman/issues)
+
+Report Keyman software bugs and issues here.
+
+> [!NOTE]
+> GitHub issues are not the best place to ask for help or support questions. The Keyman community forum is a better place to ask for help with keyboard development. Think you’ve found a Keyman bug or a problem with a specific keyboard? Describe what you’ve found on the Keyman community forum and ask whether to report a bug.
+
+
+
diff --git a/developer/docs/help/guides/walkthrough/01-creating-keyboard-project.md b/developer/docs/help/guides/walkthrough/01-creating-keyboard-project.md
new file mode 100644
index 0000000000..703163964f
--- /dev/null
+++ b/developer/docs/help/guides/walkthrough/01-creating-keyboard-project.md
@@ -0,0 +1,200 @@
+---
+title: Creating a Keyboard Project
+---
+
+
+
+
+## Step-by-Step
+
+For the Dagbani keyboard, the keyboard planning has been done for you. Follow these steps to create the Dagbani keyboard project:
+
+- Open Keyman Developer and select `New Project` from the `Project` menu.
+- The `Keyman Keyboard` option is selected by default. Click `OK`.
+- A new dialog should pop up with fields for you to fill out:
+
+
+
+- For the Keyboard Name field, enter **Dagbani** (which will also fill in the Keyboard ID field).
+- For the Description field, enter **A keyboard for typing the Dagbani language of Ghana.**
+- For the Author field, you can put in your own name. Note that the Copyright and Full copyright fields are initialized. Since the copyright really belongs to SIL Global, we’ll change those fields for this tutorial. (When you create a real keyboard project, follow the advice in the [Author, Copyright and Full Copyright](#toc-author-copyright-and-full-copyright) section below.)
+- In the Copyright field enter **Copyright © SIL Global**
+- In the Full Copyright field enter **Copyright © 2021-2025 SIL Global** . (The date range goes from the first year that the keyboard was written to the current year. A new keyboard usually just lists a single year.)
+- The Version field defaults to **1.0** and you can accept that default version number.
+- The Target field defaults to **any** (meaning “any and all” of the listed target platforms). This is what will be used for the Dagbani keyboard.
+- The Path field defaults to “Keyman Developer\Projects\” in the user’s “Documents” folder.
+- The Keyboard ID field was initialized to **dagbani** based on the Keyboard Name entered earlier. We will keep this value. The Project filename of …**Documents\Keyman Developer\Projects\dagbani\dagbani.kpj** is displayed for information. It is the Path field plus the keyboard’s project folder (which uses the Keyboard ID field as its name) plus the keyboard project file (which uses the Keyboard ID field as the name with the .kpj file type).
+- Select the `Add` button to add a BCP 47 language tag for the language. In the dialog that comes up, enter **dag** in the `Language tag` field and verify that the Language name field shows as **Dagbani**.
+- Select `OK` to close the `Select BCP 47 tag` dialog.
+- Select `OK` to close the `New Basic Keyboard Project` dialog.
+
+
+---
+
+## Planning a Keyboard
+
+The first step is identifying the language or languages your keyboard will cover. Some keyboards support multiple different languages within the same region. This approach, however, has some significant drawbacks:
+
+- it is difficult to optimize a keyboard for multiple languages since a rarely used character for one language may be a common character for another.
+- it is harder for users to find the keyboard since the name of the keyboard may not relate to the particular language they are researching.
+- it is more difficult for users to select the correct language for during installation, particularly if a keyboard handles many languages. This is particularly important for lexical models for predictive text, as a separate model is needed for each language.
+
+Furthermore, having a keyboard specifically designed for a single language may help with community acceptance.
+
+If you do need to provide keyboard support for a number of languages in a region, consider planning the keyboards together, so that you can make them as similar as possible, but then make a separate keyboard for each language.
+
+Once you have figured out what language your keyboard will support, you will need to familiarize yourself with which characters (including punctuation) are used to write it. You will need to determine what key or key combinations are needed to produce these characters. There may be major benefits in keeping as close as possible to the standard layout for a language of wider communication. On the other hand, repurposing a key from the standard layout may make it easier to type the target language.
+
+## Understanding User Needs
+
+Once you understand what is needed to support the language, you should seek to understand the needs of its speakers.
+A few good questions to start with are:
+
+- Who will use this keyboard?
+- What devices will they use it on?
+- What are the most important keys on the keyboard?
+- What have people been using to type instead?
+
+Understanding the users is the key to designing an effective keyboard. Is it intended for fluent or basic speakers of the language? Are the users familiar with common keyboards already? Have they already learned a certain keyboard format or style of typing? (If you plan to be the primary user of this keyboard, think about how others may want to use it if it turns into a more valuable tool than you anticipated.)
+
+Be sure to look for keyboards that may exist for the language(s) you want to support before beginning work. Although they may not be perfect solutions, if there is a keyboard that your language’s speakers already have and are familiar with, building on its foundation can significantly save time. You might discover a keyboard that already does exactly what you need!
+
+Once you’ve planned the basic premise of your keyboard, you can open Keyman Developer and start filling out your project info.
+
+## Creating a Keyboard Project
+
+Open Keyman Developer and select `New Project` from the `Project` menu.
+
+The `Keyman Keyboard` option is selected by default. Click `OK`. A new dialogue should pop up with fields for you to fill out.
+
+The information that you enter will initialize several files in your keyboard project.
+Making sure that the information is correct at the beginning will avoid having to correct your files later.
+
+### Keyboard Name and Keyboard ID
+
+This is the name of your keyboard project.
+
+Make sure to name your keyboards intuitively. A good standard starts with the name of the language or language group you are developing for, followed by any necessary identifiers such as `Phonetic`, `Mnemonic`, `Latin`, `QWERTY`, etc. in case there are multiple keyboards available for the same language.
+Do not use the word “keyboard” in the name. Adding “keyboard” to the keyboard name is redundant and will not help people find it. Similarly, don’t include “Unicode” in the name.
+
+If you decide to change the name of the keyboard, you’ll need to change it in a number of files: `HISTORY.md`, `README.md`, `readme.htm`, and `welcome.htm`, as well as the `.kmn` and `.kps` files.
+
+Note that the `Keyboard ID` (near the bottom of the dialog) fills in automatically with the name you choose, but formatted like `keyboard_name` (changing uppercase characters to lowercase, and non-English characters and spaces to underscore).
+You can modify the value in this field, though you are limited to the characters a-z, the numbers 0-9 and underscore.
+This value will be used as the base filename of many of your Keyman files.
+
+> [!NOTE]
+> If you decide to change the keyboard ID, you’ll need to change most of the files in the project. This is best done using Keyman Developer’s `Clone local project` feature.
+> • From the `Project` menu, select `New Project` then `Clone local project`.
+> • Use the `Browse` button to navigate to the `.kpj` file of your existing project.
+> • Specify a new `project ID` (and adjust `Destination path` if desired), then select `OK`.
+
+### Description
+
+This brief description of your keyboard is included in all of your information files.
+Try to keep this short but informative, as this is what people will see when searching for your keyboard on the keyman.com website.
+It may be useful to include alternate language names, the script (Latin, Devanagari, etc)
+if the language is written in more than one script, the region where it is used, or other details about the keyboard.
+
+The description field can use [Markdown](https://www.markdownguide.org/cheat-sheet/) for basic formatting and links.
+
+The description is added to `README.md` and the package `.kps` file.
+
+### Author, Copyright, and Full Copyright
+
+Enter your name in the `Author` field.
+Note that the `Copyright` and `Full Copyright` fields will automatically populate with your name as well.
+If you are developing keyboards that will be copyrighted by an organization, make sure to edit the Copyright fields accordingly.
+The Full Copyright field has the date as well as the copyright holder.
+
+The name used in the Copyright fields must be the real name of an individual or of an organization.
+Copyright cannot be assigned to a pseudonym.
+
+The short copyright message is added to `README.md`, `welcome.htm`, `readme.htm`, package `.kps` details, and the [`©right` keyboard system store](https://help.keyman.com/developer/language/reference/copyright) in the `.kmn` file.
+The full copyright message is added to `LICENSE.md`.
+
+### Languages
+
+This table displays the [BCP 47](../../reference/bcp-47) tag (or tags) associated with your keyboard.
+A BCP 47 tag identifies a language and will help users find your keyboard when they search for their language.
+If you don’t know what your language’s tag is, you can search for its name and find the corresponding tag in the [IANA Language Subtag Registry](https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry), which contains all existing BCP 47 tags, the [Glottolog](https://glottolog.org/glottolog/language) (under the ISO-639-3 column), or the [SIL Ethnologue](https://www.ethnologue.com/).
+
+The SIL Ethnologue is the most user-friendly option of the three, if you are unfamiliar with language tags.
+
+In addition to your basic BCP 47 tag, you can add
+[Script](../../reference/bcp-47#toc-the-script-subtag) and
+[Region](../../reference/bcp-47#toc-the-region-subtag) subtags.
+However, you should always use the simplest possible BCP 47 tag to identify your language.
+Only add Script and Region tags if your keyboard is for a script or region that differs from the most commonly used form of the language.
+
+Language information is added to `README.md` and in the package `.kps` file, in the Keyboards section.
+
+### Version
+
+The keyboard version number allows Keyman to tell which of two copies of a keyboard is newer. This allows Keyman to offer users updated versions of keyboards.
+
+The version number consists of two or three integer numbers separated by periods. Don’t use more than three numbers. Don’t use leading zeros. If the third number is absent, it is considered to be zero. Version numbers are compared number by number, so `2.51` is a higher version number than `2.6.1` (since 51 is greater than 6).
+
+New keyboards usually start with version `1.0` (which is equivalent to `1.0.0`).
+Generally the first number is incremented for major changes to the keyboard,
+the second for minor changes, and the third for corrections or bug fixes (this is known as [semantic versioning](https://semver.org); note that Keyman keyboard versions do not allow additional labels).
+
+The most important point is that the new version number be greater than the existing one (as noted above).
+
+The version number appears in the `HISTORY.md` file and the `.kmn` file in the [`&keyboardversion` keyboard system store](https://help.keyman.com/developer/language/reference/keyboardversion).
+It should be updated in both places whenever you distribute a new version of the keyboard.
+
+### Targets
+
+This is where you choose which platforms that your keyboard will be supported on.
+As you can see, Keyman offers support for a wide variety of platforms.
+Although you can pick and choose what formats you wish to develop for, `any` is the best option, because it will automatically generate files to support all formats that Keyman offers.
+If you select `any`, you do not need to (and should not) choose any other options.
+
+It is best practice to support as many devices as possible when creating your keyboard, because it is hard to predict who will use your keyboard in the future. By making your keyboard as accessible as possible, you can help even more people.
+
+If you decide not to include a touch layout, untick the `any` option and select `desktop` and `web` which will allow the keyboard to be used on a web page as well as on Linux, macOS and Windows (the three `desktop` platforms). If you later add a touch layout, you can reverse this process and go back to selecting just `any` in the [`&targets` keyboard system store](https://help.keyman.com/developer/language/reference/targets).
+
+### Path
+
+This is location on your computer where your keyboard project and all associated files will be stored.
+By default, your projects will be stored in a folder with the same name as the `Keyboard ID` value
+and that folder will be placed under the keyboard author's `Documents\Keyman Developer\Projects\` folder.
+
+It’s a good idea to let Keyman handle naming your files, since it uses good naming convention and will make things easier to find in the future. However, if you need to place the project somewhere else, you can click the `Browse...` button beside this field and navigate to the desired folder.
+
+Once you have filled out all of the fields,
+Keyman Developer will create your project and open it in a new window with your project’s `.kpj` (Keyman project) file displayed.
+You can read more about the `.kpj` file type in the [official Keyman documentation](../../reference/file-types/kpj).
+
+## Basing a new Keyboard Project on an existing one
+
+Keyman has a well-maintained [Github repository](https://github.com/keymanapp/keyboards) for keyboards that have been published by the team or community members.
+You can download a keyboard from the repository and use it as the basis for your own project.
+The easiest way to do this is with the `Clone project from Keyman Cloud` feature of Keyman Developer (version 18 and later).
+
+Open Keyman Developer and navigate to `Project` > `New Project` in the top menu bar.
+
+Select the `Clone project from Keyman Cloud` option, then `OK`. A new dialog appears where you can:
+
+- search for a keyboard (by keyboard name, language, script, country, BCP 47 tag)
+- select a keyboard from the search results
+- specify a New project ID
+- optionally move external files into the new project folder
+- optionally navigate to a different destination folder
+
+When ready, select `OK` to download the files, adjust the filenames and open the new project in Keyman Developer.
+
+## Conclusion
+
+Now that you have your project set up, continue to the next section of the tutorial to start developing your first keyboard layout.
+
+
diff --git a/developer/docs/help/guides/walkthrough/02-designing-desktop-layout.md b/developer/docs/help/guides/walkthrough/02-designing-desktop-layout.md
new file mode 100644
index 0000000000..b92794db32
--- /dev/null
+++ b/developer/docs/help/guides/walkthrough/02-designing-desktop-layout.md
@@ -0,0 +1,149 @@
+---
+title: Designing a Desktop Layout
+---
+
+
+
+
+## Step-by-Step
+
+Dagbani uses the characters **ɛ ɔ ŋ ɣ ʒ** and the corresponding capital letters **Ɛ Ɔ Ŋ Ɣ Ʒ**.
+Rather than try to assign each of these characters to a key on the physical keyboard,
+we will use a pair of keys to produce each of these characters.
+We’ll start with the default QWERTY layout and add rules so that typing ; followed by e will produce “ɛ”,
+; followed by o will produce “ɔ”, etc.
+
+This Step-by-Step tutorial won’t be using the visual layout features of Keyman Developer for creating the desktop keyboard.
+
+
+
+---
+
+## Defining a List of Keys
+
+After you have gathered some basic information about the language for which you are creating a keyboard,
+along with the needs of the people who will be using it,
+the next step is to figure out what format will suit the needs of your keyboard’s users and be most familiar to them.
+
+Keyman is available across [many different platforms](https://help.keyman.com/products/), so consider whether you need to design keyboard formats for computer keyboards, phones, or tablets.
+Keyman makes it easy to keep designs consistent across these types, but it is also possible to design each layout individually.
+
+Make a list of all of the characters that your language uses in its written form. For example, the Dagbani language uses the following characters, in addition to a standard A-Z alphabet:
+
+| Name | Character |
+|--------|-------------|
+| Open e | ɛ Ɛ |
+| Open o | ɔ Ɔ |
+| Eng | ŋ Ŋ |
+| Gamma | ɣ Ɣ |
+| Ezh | ʒ Ʒ |
+
+
+This is a simple example. Some languages may have extensive punctuation marks, special glyphs, or use a non-Latin alphabet.
+Be thorough in your list so that you are not missing any keys when you design your keyboard.
+
+Note that Unicode contains some characters that are quite similar, so verify the Unicode values you are using.
+For example, this example uses `ɔ` (`U+0254`) "open o", not `ↄ` (`U+2184`) "reversed c".
+
+## Creating a Visual Layout
+
+Once you know what keys your keyboard will need, it is time to determine how to arrange them.
+The best way to do this varies widely depending on your language.
+If users have been typing with a certain keyboard layout and are familiar with it, that might provide a good starting point.
+Research existing keyboard layouts and build off of them where possible.
+You may want to use the keyboard layout common in the area (QWERTY in English-speaking areas, AZERTY in French-speaking areas, etc.) as a basis for your keyboard.
+
+For visual mapping, this can be done with tools as rudimentary as a pen and paper, but Keyman Developer also offers a handy visual keyboard for design purposes.
+
+Navigate to your `.kpj` file, go to the `Keyboards` tab, and open your `.kmn` file. This is where your keyboard’s information lies, as well as the code that makes it work.
+
+You can read more about the `.kmn` file type in the [official Keyman documentation](../../reference/file-types/kmn).
+
+Inside your `.kmn` file, select the `Layout` tab on the left.
+For a new project, the `Design` tab (at the bottom) should already be selected.
+This is a visual representation of your desktop keyboard.
+Note that once you add rules using the `Code` tab (as, for example, in the Dagbani keyboard developed in the Step-by-Step tutorial),
+Keyman Developer no longer offers the `Design` tab option.
+
+By default, Keyman Developer uses a QWERTY layout, but it is very easy to remap this.
+If you are using a non-QWERTY base keyboard layout, select each key and press the corresponding key on your keyboard.
+This will automatically change the keyboard code to type the key you have selected.
+
+To access the characters needed for your language, you can paste the Unicode characters you need into the two fields at the bottom.
+`Unicode Character Value(s)` is for the Unicode value (for example, `U+0061`) of the character you would like the keyboard to type,
+while `Output character(s)` is for the character the keyboard will produce (for example, `a`).
+Typing in either field will automatically populate the other one with matching information, so it does not matter which one you use.
+
+If a key needs to produce multiple characters (for example, a key that produces `ch`), you can place multiple characters in the `Output character(s)` field.
+
+After some research, you may find that your language has more characters than there are keys on the keyboard.
+This is especially true of languages with many glyphs, combined characters, or diacritical marks on letters.
+In this case, it is especially helpful to follow a default keyboard layout for your base design,
+and plan out special keystrokes so users can type the characters that are not immediately available on the keyboard.
+Try to ensure that the most essential keys (usually the ones used to type the alphabet) are available before worrying about adding less frequent characters.
+
+## Planning Keystrokes
+
+Once you know what you want your keyboard layout to look like, you can begin planning what keystrokes will be needed.
+You can specify rules so that Keyman will transform typed keystroke combinations into the desired characters.
+
+For example, you can use the keystrokes `'` + `e` to produce the character `é` rather than dedicating a separate key to `é`.
+
+When choosing keys to use for characters you are adding to your keyboard, be careful not to block the normal function of those keys.
+In the above example, consider whether there would be a need to allow someone to type an actual apostrophe.
+
+To easily plan keystrokes, you can reference the list you made of the special characters needed for your language. Disregarding the letters and symbols already included in the base layout you designed, how many more do you need to fit onto your keyboard? You can utilize the number row, punctuation characters, deadkeys, and the Right-Alt, Shift, or Shift+Right-Alt modifier keys in your layout. Remember to make them as intuitive as possible for users. If the key combination is too complex, it will slow users down significantly when attempting to type.
+
+Remember to include capital letters in your list! Keyman treats these separately, so you will have to code uppercase and lowercase letters separately.
+
+Here’s an example of how to list your keystrokes. (This can also be reused when you document your keyboard’s layout later!) If you want to be thorough, you can also list the Unicode values for each character to avoid any confusion about which character is used.
+
+| Base | Modifier | Result |
+|------|----------|--------|
+| a | ^ | â |
+| e | ^ | ê |
+| i | ^ | î |
+| o | ^ | ô |
+| u | ^ | û |
+
+Once you have planned the visual layout of your keyboard and determined how to assign the rest of the keys on the keyboard, it’s time to begin coding.
+If your layout is simple enough that you do not need to program additional keys, you do not need to worry as much about the next section.
+In some cases, using Keyman’s visual editor is enough for a desktop keyboard.
+
+> [!NOTE]
+> Once you begin adding multi-part rules, the keyboard becomes too complex to modify with the visual layout tools, so it is best to do any visual layout work first using the `Design` tab, then add the additional rules using the `Code` tab.
+
+### Deadkeys
+
+The Step-by-Step tutorial uses `;` plus another key (`e E o O n N g G z Z`) to produce the ten additional characters (`ɛ Ɛ ɔ Ɔ ŋ Ŋ ɣ Ɣ ʒ Ʒ`).
+When the “;” is typed it appears on the screen.
+When one of the ten keys is typed directly after the “;” then the “;” is replaced by the corresponding additional characters.
+
+In contrast to this approach, the “deadkey” alternative could be used.
+A deadkey produces no display when typed, but modifies the keystroke that follows it.
+To use a deadkey approach for the Dagbani keyboard, we would use a rule to convert the `;` keystroke into a deadkey, which will not display on the screen, but will then be used to create the appropriate additional character when one of the ten characters is typed.
+Some European language keyboards (French, for example) use deadkeys, so users in French-speaking countries may already be familiar with their use.
+
+While useful in some situations, deadkeys can also confuse users.
+In this example, when the `;` key is pressed, it will not produce anything.
+If you include deadkeys in your keyboard, be sure to document them well so that users understand what is happening when they type them.
+
+For more information, see the Keyman documentation for the [`deadkey()` statement](https://help.keyman.com/developer/language/reference/deadkey).
+
+### Reassigning keys
+
+But consider the Dagbani example again.
+Suppose we don’t want to have to type two keys to obtain each of these additional characters (as if they were somehow inferior to the other twenty-six).
+We could choose to design the keyboard so that typing `[ { ] } - _ = + \ |` will produce `ɛ Ɛ ɔ Ɔ ŋ Ŋ ɣ Ɣ ʒ Ʒ`, respectively.
+That could be done with the `Design` mode using the visual layout tools, or by adding rules.
+We would then want to add rules to allow the user to type the characters that were on the ten keys that we repurposed to type the additional characters, for example type the `;` key then the `[` key to get an actual `[` character.
+
+
\ No newline at end of file
diff --git a/developer/docs/help/guides/walkthrough/03-creating-desktop-layout.md b/developer/docs/help/guides/walkthrough/03-creating-desktop-layout.md
new file mode 100644
index 0000000000..f7b1c6cc63
--- /dev/null
+++ b/developer/docs/help/guides/walkthrough/03-creating-desktop-layout.md
@@ -0,0 +1,339 @@
+---
+title: Creating a Desktop Layout
+---
+
+
+
+
+## Step-by-Step
+
+On the “Creating a Keyboard Project” page, the **dagbani** keyboard project was created.
+Keyman Developer displays a tab for the project file `dagbani.kpj` (just below the menu and toolbar).
+There are tabs across the bottom for different steps in the process.
+
+
+
+- Click on the `Keyboards` tab at the bottom of the Keyman Developer window.
+- Then click on the `dagbani.kmn` filename. This will open the dagbani.kmn file (as a second tab along the top, just below the menu and the toolbar) and display a set of tabs along the left side of the Keyman Developer window. Initially the `Details` tab is displayed and you can see some of the items you entered when creating the project.
+- Click on the `Layout` tab from the set of tabs on the left.
+- By default the `Design` view is shown and you can use the Character Map to assign characters to various keys:
+
+
+
+- For this tutorial, however, we’re going to use the `Code` view. At the bottom of the Layout pane, click on the `Code` tab and the Keyman code is displayed:
+
+```keyman
+store(&VERSION) '10.0'
+store(&NAME) 'Dagbani'
+store(©RIGHT) 'Copyright © SIL Global'
+store(&KEYBOARDVERSION) '1.0'
+store(&TARGETS) 'any'
+store(&BITMAP) 'dagbani.ico'
+store(&VISUALKEYBOARD) 'dagbani.kvks'
+store(&LAYOUTFILE) 'dagbani.keyman-touch-layout'
+
+begin Unicode > use(main)
+
+group(main) using keys
+```
+
+- Choose one of the following two options (which produce equivalent results). You can type the lines or copy and paste from the tutorial. The first option lists a separate rule for each character. This may make it easier to understand what the rules do. The second option makes use of features in the Keyman language that allow more compact rules to be written.
+- Option 1: Add the following lines after the `group(main) using keys` line. Each line has the code to generate one character based on “;” and a base key.
+
+```keyman
+";" + "e" > "ɛ"
+";" + "E" > "Ɛ"
+";" + "o" > "ɔ"
+";" + "O" > "Ɔ"
+";" + "n" > "ŋ"
+";" + "N" > "Ŋ"
+";" + "g" > "ɣ"
+";" + "G" > "Ɣ"
+";" + "z" > "ʒ"
+";" + "Z" > "Ʒ"
+```
+
+- Option 2: Add the following lines after the `group(main) using keys` line. The base keys are placed in one `store` (storage area) and the characters to produce are placed in a second store. The third line has a single rule that does the equivalent of the ten rules listed above.
+
+```keyman
+store(basekey) "eongzEONGZ"
+store(output_char) "ɛɔŋɣʒƐƆŊƔƷ"
+";" + any(basekey) > index(output_char,2)
+```
+
+- Select the `Icon` tab on the left side of the window. This icon is displayed by the operating system when the keyboard is active. By default Keyman Developer creates a short abbreviation of the keyboard name (”DAG” in this case). You can use the color palette at the right to select different colors and click on squares in the grid to change their color. For this tutorial we will accept the default.
+- Select the `On-Screen` tab on the left. This is the keyboard image that is displayed when the uses asks for help. As you can see it’s currently blank, which is not so helpful.
+- Tick the `Auto-fill from underlying layout` checkbox at the bottom of the keyboard display.
+- Then select the `Fill from layout` button at the top. Keyman Developer fills in the keyboard. Since we didn’t modify any keys, the display shows up as a normal QWERTY keyboard. This is still useful, since the on-screen keyboard can also be used to enter text and typing on a blank keyboard is difficult!
+- Select the `Build` tab on the left, then the `Compile Keyboard` button. (Alternatively you can use the `Keyboard` menu, `Compile Keyboard` menu item to compile the keyboard. Or you can use the F7 function key as a shortcut.)
+- You should see messages at the bottom indicating `dagbani.kmn built successfully`. If this is not the case, you’ll need to examine the error messages to see what the error is and correct it.
+
+## Interpreting Errors
+
+When compiling your Keyman code, Keyman Developer will report any errors, warnings and hints in the box at the bottom of the window. The message will give a short description of what the compiler found was wrong along with the line number of where the problem was detected. The error, warning or hint has an identifier (“KM02033” for example). This identifier is a link to a more detailed description.
+
+
+
+---
+
+## Using the Visual Editor
+
+At the end of the [Designing a Desktop Layout](02-designing-desktop-layout) topic, an alternative Dagbani keyboard design was mentioned.
+In that approach, typing the
+[ { ] } - _ = + \ |
+keys would produce `ɛ Ɛ ɔ Ɔ ŋ Ŋ ɣ Ɣ ʒ Ʒ`, respectively.
+
+If you wanted to implement such a design, Keyman Developer's Visual Editor would be very useful.
+When the `Layout` tab is selected on the left, Keyman Developer starts off in `Design` mode, displaying the keyboard.
+If the Character Map is not displayed on the right-hand side of the window,
+you can use the `View` menu and the `Character Map` menu item to show or hide it.
+(Shift+Ctrl+C is a keyboard shortcut to accomplish the same thing.)
+
+
+
+To assign the `ɛ` character to the `[` key, locate the desired character in the Character Map and drag it to the desired key.
+If you click on that key, you’ll see it change color and the information about it will be displayed below the keyboard layout.
+
+
+
+On the key cap, this shows:
+
+- `[` the default value from the QWERTY layout
+- `ɛ` the character that the key will produce
+
+Below the key cap, there are two edit fields which allow you to change the character that the key will product:
+
+- `U+025B` the Unicode value(s) that the key will produce
+- `ɛ` the character(s) that the key will produce (the equivalent of the Unicode value)
+
+These two edit fields are linked. If you change one, the other will change.
+
+Clicking on the `Code` tab at the bottom of the window displays the code equivalent of the work in the visual editor:
+
+```keyman
+group(main) using keys
++ [K_LBRKT] > 'ɛ'
+```
+
+Note that `[K_LBRKT]` is how Keyman Developer refers to the left square bracket key (the key just to the right of the “P” key on a QWERTY keyboard).
+It also accepts `'['` or `"["` as equivalent ways to refer to that key.
+
+If you were to continue this example, you would drag the `ɔ` character to the `]` key and repeat the process for the other three lower case characters. Then you would click on one of the two “Shift” keys and repeat the process for the five upper case characters.
+
+## Understanding Keyman Code
+
+Keyman’s Visual Editor (the `Design` mode of the `Layout` tab) is helpful in assigning characters to keys in a consistent manner. For a simple keyboard, it may be all that you need. It’s likely, however, that you’ll need to use the `Code` tab to provide the logic needed for your keyboard.
+
+When you begin an new project (using the “Project” menu, “New Project” menu item), Keyman Developer initializes your `.kmn` file.
+With the `Layout` tab on the left selected, you will see two small tabs at the bottom of the window: the `Design` tab and the `Code` tab.
+When you switch to the `Code` tab, you should see something like the following. (This example is from the Step-by-Step tutorial.)
+
+```keyman
+store(&VERSION) '10.0'
+store(&NAME) 'Dagbani'
+store(©RIGHT) 'Copyright © SIL Global'
+store(&KEYBOARDVERSION) '1.0'
+store(&TARGETS) 'any'
+store(&BITMAP) 'dagbani.ico'
+store(&VISUALKEYBOARD) 'dagbani.kvks'
+store(&LAYOUTFILE) 'dagbani.keyman-touch-layout'
+
+begin Unicode > use(main)
+
+group(main) using keys
+```
+
+The `store()` statements at the top are called the “header” of your file.
+This is where the important information about your keyboard is stored.
+
+A summary of the elements of the Keyman header can be found in the [language guide](https://help.keyman.com/developer/language/guide/headers) and detailed information is in the official Keyman documentation:
+
+- [&version](https://help.keyman.com/developer/language/reference/version)
+- [&name](https://help.keyman.com/developer/language/reference/name)
+- [©right](https://help.keyman.com/developer/language/reference/copyright)
+- [&keyboardversion](https://help.keyman.com/developer/language/reference/keyboardversion)
+- [&targets](https://help.keyman.com/developer/language/reference/targets)
+- [&bitmap](https://help.keyman.com/developer/language/reference/bitmap)
+- [&visualkeyboard](https://help.keyman.com/developer/language/reference/visualkeyboard)
+- [&layoutfile](https://help.keyman.com/developer/language/reference/layoutfile)
+- [&mnemoniclayout](https://help.keyman.com/developer/language/reference/mnemoniclayout)
+
+
+## Writing Keyman Rules
+
+The body of your code begins after the header. This is where the bulk of your keyboard’s functionality will be.
+
+```keyman
+begin Unicode > use (main)
+```
+
+The preceeding line tells Keyman
+
+- to use Unicode encoding when typing characters, and
+- to look for the rules determining what characters should be produced in `group(main)` .
+
+```keyman
+group(main) using keys
+```
+
+is the default group for defining keyboard rules. This is where we will write code to implement the keystrokes you decided to use.
+
+For more advanced uses of the `begin` rule, like defining different rulesets based on typing context, see the [official Keyman documentation](https://help.keyman.com/developer/language/reference/begin).
+
+
+There are a few key terms that you must know when writing rules:
+
+**Context**
+
+The context specifies the conditions that will trigger a rule.
+If the character(s) prior to the cursor match the context of a rule, the rule will be processed by Keyman.
+
+**Key**
+
+The key specifies which keystroke the rule will act upon.
+For more information on keys and keystrokes, read the [official Keyman documentation](https://help.keyman.com/developer/language/guide/virtual-keys).
+
+**Output**
+
+The output determines which characters are produced by a rule. When a rule is processed, Keyman will replace the context with the output.
+
+The Context (which may be empty) is separated from the Key by `+`.
+
+The Key is separated from the Output by `>`.
+
+You can include comments in your Keyman code by typing a plain `c` followed by a space then any text you like afterwards. (If you want the letter “c”, you must surround in in quotes like `"c"`.) This is a good way to document your code and make things easier to read later, both for yourself and others. Comments can be made at the end of a line (with a space before the `c` as well as after) or be on their own line. Any text that follows the `c` through the end of the line will be ignored when the keyboard is compiled.
+
+Writing rules in Keyman is very straightforward for simple key substitutions. Suppose we want circumflex plus “a” to produce the character “â”. The Keyman code is actually very similar:
+
+`"^" + "a" > "â"`
+
+In this example, the **context** is `^`, the **key** is `a`, and the **output** is `â`.
+Whenever Keyman finds the context (`^`) prior to the cursor and the current keystroke is `a`, it will replace the context (and the typed character) with `â`.
+
+Characters written into Keyman code should always be surrounded by single quotes (`' '`) or double quotes (`" "`).
+Either pair will work (as long as they match).
+It is also possible to use the Unicode values of characters directly in the code.
+These are never written with quotes around them.
+
+The previous line of code, when rewritten to use Unicode values, looks like this:
+
+```keyman
+U+005E + U+0061 > U+00E2
+```
+
+While less readable to a human, using Unicode values for uncommon or easily confused characters is often a good idea.
+
+It's possible to use a comment to provide both the Unicode value and the character itself, for example rewriting the above line as:
+
+```keyman
+"^" + "a" > U+00E2 c â
+```
+
+At a glance, this tells you that a circumflex (`^`) combined with `a` will produce the Unicode character `â` (whose value is U+00E2).
+Including a comment at the end of each rule that shows the output character will make reviewing your code significantly easier while still being extremely clear about which characters are used.
+
+Below is an example of useful comments in the SIL EL Ethiopic Latin keyboard explaining a set of rules and each rule’s output:
+
+
+
+Some Keyman rules have no context, that is, a context that is empty. The following line:
+
+```keyman
++ "e" > U+025B c ɛ
+```
+
+is an example of the most basic rule possible. You may have noticed lines like these in your code after using the `Design` tab to edit your keyboard.
+
+Note that rules created when using the `Design` tab use [virtual key codes](/developer/language/guide/virtual-keys#common-virtual-key-codes) rather than the corresponding characters.
+This does not matter unless you are writing a [mnemonic layout](https://help.keyman.com/developer/language/reference/mnemoniclayout) keyboard. Keyman keyboards are positional -- the opposite of mnemonic -- by default, so unless you specify a mnemonic layout in your header, the following two lines of code will produce the same output:
+
+```keyman
++ "e" > U+025B
++ [K_E] > U+025B
+```
+
+### Stores
+
+Stores can be used to write concise rules that apply to a set of characters.
+For example, in the following code, the store called `basekeys` contains the keys for five vowels.
+A second group called `vowels_acute` contains the same five vowels (in corresponding order) with an acute accent.
+And the single rule combines the apostrophe with a base vowel to produce a vowel with an acute accent.
+
+```keyman
+store(basekeys) "aeiou"
+store(vowels_acute) "áéíóú"
+"'" + any(basekeys) > index(vowels_acute,2)
+```
+
+Thus the code above is equivalent to the following five rules:
+
+```keyman
+"'" + "a" > "á"
+"'" + "e" > "é"
+"'" + "i" > "í"
+"'" + "o" > "ó"
+"'" + "u" > "ú"
+```
+
+You can read more about the `store`, `index` and `any` keywords in the [Keyman language documentation](https://help.keyman.com/developer/language/reference/).
+
+### Deadkeys
+
+At the end of the previous topic, an example was given of using the ; key as a “deadkey”. Typing the deadkey produces no output, but it potentially changes the output of the following key. Changing the first two rules from the Step-by-Step example to treat the ; as a deadkey, would result in:
+
+```keyman
++ ";" > dk(1) c Define ";" as a deadkey
+dk(1) + "e" > "ɛ" c deadkey followed by "e" produces "ɛ"
+dk(1) + "E" > "Ɛ" c deadkey followed by "E" produces "Ɛ"
+```
+
+If you follow the instructions for the Debugger, you’ll find that the keystroke log is the same, but in the right-hand side of the display, the “;” is replaced by an indication of the deadkey.
+
+### Groups
+
+Groups can be used in several ways to make your code simpler and more efficient. There are two types of groups:
+
+- groups that process only the context
+- groups that process the context and the keystrokes
+
+You can read more about their uses in the [Keyman documentation](/developer/language/guide/groups).
+
+## Creating an On-Screen Keyboard Layout
+
+An on-screen keyboard (OSK) is a graphic representation of the desktop layout. It is displayed on the computer screen to show where keys are located. In can also be used to input text by clicking on the keys.
+
+Select the `On-Screen` tab on the left to display the layout (one layer at a time).
+You can manually create the OSK by clicking on a key and typing the character that should be displayed there.
+
+It is also possible to create an on-screen layout automatically based on what you have designed and coded on the Layout tab.
+(If you have manually created your on-screen layout information, you should be aware that the following automatic process will overwrite what you have created.)
+
+- Any key that you don’t reassign will have the function of the US English keyboard. If you are relying on this in your keyboard, you should tick the `Auto-fill underlying layout` box below the keyboard image.
+- Select the `Fill from layout` button above the keyboard image
+- Check the results.
+
+The On-Screen Keyboard editor looks very similar to the `Design` mode of the `Layout` tab. Most of the time, the key caps will be the same as in the `Design` mode of the `Layout` tab, but sometimes it might be helpful to display something different than what is actually produced. If, for example, the character being produced is not visible, such as a no-break space or a right-to-left mark, it might be helpful to display `NBSP` or `RTL` or some symbol to remind the user what the key produces.
+
+## Exporting an On-Screen Keyboard Layout
+
+One way to document a keyboard layout is to use images of the keyboard showing the different layers: default layer, Shift layer, Right-Alt layer, etc.
+Keyman Developer provides a way to export such images from the `On-Screen` tab.
+
+Once you have the layout (created either manually or automatically), you can use the `Export` button.
+Then complete the information needed:
+
+- Navigate to the folder where you want to create the files
+- Supply a base filename
+- For the `Save as type` field, select `Image (*.png)`
+- Select `Save`
+- In the `Output Bitmap Parameters` dialog, select `One file per shift state`, `Output Unicode keyboards`, and adjust the width of the image as needed, then select `OK`. Keyman Developer will create one or more files using the base filename plus letters to indicate the shift state plus `.png`. You can reference these files in your welcome.htm file.
+
+
\ No newline at end of file
diff --git a/developer/docs/help/guides/walkthrough/04-using-debugger.md b/developer/docs/help/guides/walkthrough/04-using-debugger.md
new file mode 100644
index 0000000000..42b8de61c4
--- /dev/null
+++ b/developer/docs/help/guides/walkthrough/04-using-debugger.md
@@ -0,0 +1,35 @@
+---
+title: Using the Debugger
+---
+
+
+
+
+## Step-by-Step
+
+- From the `Debug` menu, select the `Start Debugging` menu item. Some extra fields will be shown.
+- Type ;. The Keystroke log will show `;`. The display to the right has two sections. The upper section shows the characters displayed on the screen. The lower section shows a table of characters and their Unicode values. Here the upper section will show `;` and the lower section will show `;` and `U+003B`. (U+003B is the Unicode value for “;”.)
+- Type e. The Keystroke log will show `;` and `E`. The display to the right will show `ɛ` in the upper section and `ɛ` and `U+025B` in the lower section. (U+025B is the Unicode value for “ɛ”.)
+- Type ; then E. The Keystroke log will show `;` `E` `;` `Shift+E`. The display to the right will show `ɛƐ` in the upper section and `ɛ` and `U+025B` then `Ɛ` and `U+0190` in the lower section.
+
+
+
+- From the `Debug` menu, select the `Stop Debugger` menu item.
+
+
+
+---
+
+## Running the Debugger
+
+See the [debugger documentation](../../context/debug) for more information on running the debugger.
+
+
\ No newline at end of file
diff --git a/developer/docs/help/guides/walkthrough/05-designing-touch-layout.md b/developer/docs/help/guides/walkthrough/05-designing-touch-layout.md
new file mode 100644
index 0000000000..acc2f9d6d5
--- /dev/null
+++ b/developer/docs/help/guides/walkthrough/05-designing-touch-layout.md
@@ -0,0 +1,62 @@
+---
+title: Designing a Touch Layout
+---
+
+
+
+
+## Step-by-Step
+
+In the Dagbani keyboard, `;e` was selected as the way to generate the character `ɛ` , but having to type a `;` on a touch screen followed by `e` to get the `ɛ` character would be tedious. It is preferable to assign `ɛ` as a longpress key on the `e` key.
+
+For the Step-by-Step tutorial, the design decisions have been made for you. We will be adding ten longpress keys to the default touch layout.
+
+
+
+---
+
+## Creating a Basic Visual Layout
+
+Adding a touch keyboard layout to your keyboard project allows a user to input text on touch devices, such as tablets and phones.
+
+A desktop keyboard is dependent on the physical keyboard. With a touch layout, you will be displaying the keys on the device for the user to see and interact with.
+
+There is some flexibility in arranging keys, though adding too many keys to a row or too many rows to a layout will make the keyboard difficult to use. Additionally, there are options for activating a key:
+
+- touch, that is touch and release the key
+- longpress, that is touch and hold the key, then select a character from a popup menu
+- flick, that is touch the key and slide in one of eight directions
+- mulitap, that is rapidly touch and release the key: one tap produces the base key, two taps produces the first multi-tap key, three produces the second multi-tap key, etc.
+
+## Planning Keystrokes
+
+You’ll want to plan your touch layout just as you did for the desktop (physical keyboard) layout. There is some value in making the touch layout similar to the desktop layout, but the primary concern is making it easy to use.
+
+Another possibility, if a small number of additional characters are needed, is to give each of them their own keys. This is possible since a touch layout is displayed on the screen.
+
+If you use Keyman Developer’s New Project feature, a touch layout is added automatically.
+
+## Using the desktop layout as a basis for the touch layout
+
+There are advantages to basing the touch layout on the desktop layout.
+Users who switch between the two may benefit from the similarity.
+In addition, your touch layout may be able to take advantage of the logic in the desktop layout code you’ve already created.
+Specifically, if the `ID` field for a key in the touch layout begins with `K_` then Keyman treats the key as the same as the corresponding desktop key (as modified by the active layer of the touch layout)
+according to the rules that are in the .kmn file.
+
+If you establish the desktop keyboard layout and create the On-Screen Keyboard,
+you can switch to the Touch Editor and import from the OSK.
+This will provide a “tablet” layout, with “default” and “shift” layers.
+To switch to a “phone” layout, select the basic template, which rearranges the keys and moves some to a “numeric” layer.
+(For more details, see the next topic.)
+The result will need to be reviewed and tested, but using this approach may save you some time.
+
+
\ No newline at end of file
diff --git a/developer/docs/help/guides/walkthrough/06-creating-touch-layout.md b/developer/docs/help/guides/walkthrough/06-creating-touch-layout.md
new file mode 100644
index 0000000000..e7664fb797
--- /dev/null
+++ b/developer/docs/help/guides/walkthrough/06-creating-touch-layout.md
@@ -0,0 +1,154 @@
+---
+title: Creating a Touch Layout
+---
+
+
+
+
+## Step-by-Step
+
+- Click on the `Touch Layout` tab on the left. The touch layout is shown, with the `q` key selected and details about the selected key shown on the right. Farther to the right is the Character Map which will be used in a later step. If the Character Map is not displayed, use the `View` menu, `Character Map` menu item to turn on the display.
+
+
+
+
+
+- Click on the `e` key to select it and display its information.
+- Click on the `+` button in the `Longpress Keys` section. A new key is added (and the `+` button moved). The new key is given an arbitrary ID (`T_new_103` in this example).
+
+
+
+- Note that information about this key is placed to the right.
+
+
+
+- We’ve added this longpress key to the `e` key. Now we want to make it (1) display `ɛ` so users will see what the key will produce and (2) change the ID so that activating this longpress key will generate `ɛ`. Find the `ɛ` character in the Character Map and drag it to the `Text` field. This will put `ɛ` in the `Text` field, `U+025B` in the `Text Unicode` field and `U_025B` in the `ID` field.
+
+
+
+Note: To find the `ɛ` character in the Character Map, you can use the scroll bar on the right to scroll down to `U+025B`. Alternatively, you can type `25B` in the `Filter by` field at the bottom of the character map.
+
+- Click on the `o` key in the keyboard layout. This will select the `o` key and display its information.
+- Click on the `+` button in the `Longpress Keys` section. A new key is added (and the `+` button moved). The new key is given an arbitrary ID (`T_new_104` in this example). In addition, information about this key is placed to the right.
+- We’ve added this longpress key to the `o` key. Now we want to make it (1) display `ɔ` and (2) change the ID. We could use the same procedure as in the previous steps, but this time we’ll use a different method. Click in the `Text Unicode` field and type `U+0254` (this will also place `ɔ` in the `Text`, but will not change the `ID` field).
+- Click in the `ID` field and replace the generated ID (`T_new_104` in this example) with `U_0254`. (Note that the ID uses an underscore rather than a plus sign.)
+
+
+
+- Add three longpress keys using one of the above methods:
+ - on the `n` key, add a longpress key for `ŋ` = U+014B
+ - on the `g` key, add a longpress key for `ɣ` = U+0263
+ - on the `z` key, add a longpress key for `ʒ` = U+0292
+- You've made these five changes on the `default` layer. Now we need to switch to the `shift` layer. Select the drop-down menu under the `Layer` heading and select `shift`.
+
+
+
+- With the capital letters displayed on the keyboard, add five longpress keys using one of the above methods:
+ - on the `E` key, add a longpress key for `Ɛ` = U+0190
+ - on the `O` key, add a longpress key for `Ɔ` = U+0186
+ - on the `N` key, add a longpress key for `Ŋ` = U+014A
+ - on the `G` key, add a longpress key for `Ɣ` = U+0194
+ - on the `Z` key, add a longpress key for `Ʒ` = U+01B7
+- Select the `Build` tab on the left and then the `Compile Keyboard` button. You should see a `dagbani.kmn built successfully` message. If you don’t, examine the error messages to see where the problem lies.
+
+### Testing the touch layout
+
+Keyman Developer provides a way to test your keyboard in a web browser.
+- On the Build tab, you can select `Test Keyboard on web` followed by `Open in browser`.
+- Select the `Keyboard` drop-down menu, then select the `dagbani` keyboard. You should have a display that looks like:
+
+
+
+- The display defaults to the Windows keyboard. You can type on the computer keyboard or use your mouse to click on the keys. Enter ; e ; o ; g ; z ; n and you should have the following result.
+
+
+
+- Select the `Device` drop-down menu and select `iPhone 5S`. The display will change to show a simulated phone screen with your touch layout. You can use your mouse to click on the keys. To access the longpress keys, click and hold, then slide the mouse to select the letter on the longpress key. Try this with the five longpress keys on `e` `o` `g` `z` and `n`. (There’s a dot in the upper right corner of the key to indicate the presence of at least one longpress key.) The period (full stop) also has a longpress menu that allows various punctuation characters to be entered.
+
+
+
+- If you click on the `Shift` key, the display changes to the `shift` layer and you can enter characters from that layer.
+- When you are finished testing, you can close the browser tab.
+
+
+
+---
+
+## Configuring a Touch Layout
+
+There are a number of items to the left of the keyboard layout that allow you to configure the touch layout and select what portions to display. If you have done the Step-by-Step tutorial for this page, you’ve seen how to choose a different layer from the drop-down menu under the “Layer” heading.
+
+### Template and Import from On Screen buttons
+
+When you are initially creating a touch layout, it may be helpful to start from the On-screen Keyboard you created for the desktop layout and/or from a template. Since using these buttons overwrites the existing touch layout, you’ll only want to use them at the beginning of your touch layout work.
+
+- `Import from On Screen` will create a `tablet` layout with `default` and `shift` layers from the On Screen keyboard for the `desktop` layout.
+- `Template`, then `template-basic` will distribute the keys for a `phone` layout with `default`, `shift` and `numeric` layers.
+- `Template`, then `template-latin` will rearrange the keys for a `phone` layout with `default`, `shift`, `numeric` and `symbol` layers. It includes longpress keys for accented Latin characters. An identical `tablet` layout is also created. See the note under `Choosing the Platform` below.
+- `Template`, then `template-traditional` will distribute the keys for a `phone` layout with `default`, `shift` and `numeric` layers, but also make a `tablet` layout based on the desktop one.
+
+### View Options
+
+By default the list of modifier-based layers is limited to the most commonly used desktop layers
+(`default`, `shift`, `rightalt`, `rightalt-shift`, `caps`).
+Selecting this option will extend that list to include layer names like `rightctrl-rightalt-shift`.
+It doesn’t add these layers to the layout, but merely adds them to the list of predefined names that you could choose to use.
+It’s likely you will never want to choose this option.
+
+You can always choose the `(custom)` option and enter any valid name (limited to A-Z, a-z, 0-9, underscore and hyphen).
+
+### Choosing the Platform
+
+ Options are “phone”, “tablet”, “desktop”
+
+- A “phone” layout typically has four rows (counting the row with the space bar) with ten or eleven keys per row. A “tablet” layout typically has five rows with thirteen or fourteen keys per row
+- Don’t include both a “phone” layout and a “tablet” layout unless those layouts are different. Keyman will use a “phone” layout on a tablet if no “tablet” layout exists and use a “tablet” layout on a phone if no “phone” layout exists. Thus it is twice the work (or more) to maintain identical “phone” and “tablet” layouts.
+- The “desktop” layout option is not currently used. It is intended for Windows touch screens but currently Windows does not make it feasible to support custom touch keyboards.
+
+### Adjusting Keyboard Layers
+
+A keyboard layout generally includes multiple layers. (See description of [Keyboard Layer](glossary) in the glossary.) The Touch Layout editor displays one layer at a time. The “default” layer is the layer that is presented when no key (such as Shift) has been used to activate another layer.
+
+In the Touch Layout editor you switch layers using the drop-down menu described below. In addition, you need to make sure that each of the layer activation keys specifies in the “Next Layer” field which layer is to be activated. For example, on the default layer, the Shift key has “shift” in the “Next Layer” field, and on the shift layer, the Shift key has “default” in the “Next Layer” field.
+
+Under the “Layer” heading you can:
+
+
+
+- choose an existing layer from the drop-down menu to display that layer
+- choose the “+” button to add a new layer (either choosing a name from the “Modifier-based layer” list, or choosing “(custom)” from that list and entering a name in the “Name” field)
+- choose the “-” button to delete the layer whose name is displayed
+- choose the “Edit” button to change the name of the current layer
+
+## Longpress, Flicks and Multitap Gestures
+
+If you completed the Step-by-Step tutorial for this topic, you added longpress keys to certain base keys in the touch layout by clicking on the “+” button in the “Longpress” section and supplying the needed information to define the longpress key.
+
+Similarly, if you wish to add a flick gesture, choose one of the eight “+” buttons in the “Flicks” section — the one that corresponds to the direction that you want to assign for this flick gesture — and click on it. Then supply the needed information to define that flick gesture.
+
+A multitap gesture is defined in a similar way. Click on the “+” button in the “Multitap” section and add the information to define the multitap key. The base key will respond as normal for a single tap, the first multitap key listed will respond to a double tap, the second multitap key to a triple tap, etc.
+
+Use care when combining different kinds of gestures as some of them may conflict.
+
+- Don’t use too many keys in a longpress menu
+- Don’t use too many flicks. For example, NE, N, and NW flicks are easily confused
+- When using north-flicks and longpress, be aware that the north-flick shortcut for the default longpress will be blocked
+- Don’t assign too many multitap keys to the same base key
+
+## Reference
+
+See [Touch layout editor documentation](../../context/keyboard-editor#toc-touch-layout-tab) for more details.
+
+## Testing Touch Keyboards
+
+See the end of the Step-by-Step section above for a description of how to use Keyman Developer to test your touch layout in a browser window. It’s also possible to transfer the .kmp file to a touch device and install the keyboard there for testing.
+
+
\ No newline at end of file
diff --git a/developer/docs/help/guides/walkthrough/07-writing-keyboard-documentation.md b/developer/docs/help/guides/walkthrough/07-writing-keyboard-documentation.md
new file mode 100644
index 0000000000..13d70cb317
--- /dev/null
+++ b/developer/docs/help/guides/walkthrough/07-writing-keyboard-documentation.md
@@ -0,0 +1,113 @@
+---
+title: Writing Keyboard Documentation
+---
+
+
+
+
+## Step-by-Step
+
+- Click on the `dagbani.kpj` tab at the top (just under the menu and toolbar), then click on the `Distribution` tab at the bottom.
+
+
+
+- There are a number of files that provide information about the keyboard. Some are for the keyboard author and for maintainers of the Keyman keyboards repository, some are to help users of the keyboard understand how it works.
+
+
+
+- In the list of files, click on the `HISTORY.md` one to open that file. The file will open in a text editor and show you the information that you entered when setting up the keyboard project, specifically version 1.0, today’s date, and the author’s name. Since this information is correct, you can close this file by clicking on the red “X” on the righthand side of the `HISTORY.md` tab at the top of the text area.
+- Click on `LICENSE.md` to open that file. This has been filled out using the Full copyright information you provided. Close the file by clicking on the red “X”.
+- Click on `README.md` to open that file. This has been initialized for you. Close the file by clicking on the red “X”. (This file provides a place for information about the design of the keyboard that would be useful to a keyboard author wanting to update the keyboard or use it as a basis for a new keyboard. Don’t confuse it with the next item which is information for the keyboard user.)
+- Click on `source\readme.htm` to open that file. This is the information displayed to the user just before the keyboard is installed. It has the description supplied when setting up the keyboard project. Other helpful information can be added, but the file should be kept as short as possible. Close the file.
+- Click on `source\welcome.htm` to open that file. This is the help information that is packaged with the keyboard and available to the user. It should contain enough information so that the user can learn to type with the keyboard. This can be in the form of:
+ - image files referenced by the welcome.htm file, or
+ - a chart (in HTML format) showing how two keystrokes produce a character, or
+ - descriptive text in the HTML file, or
+ - some combination of the above.
+- For this tutorial, we’re going to add one line of instruction. Find the following line:
+
+```
+
+```
+
+- Instead of inserting images, we're going to copy the following HTML text and paste it into the file:
+
+`Type ";" followed by e o n g z E O N G Z to produce ɛ ɔ ŋ ɣ ʒ Ɛ Ɔ Ŋ Ɣ Ʒ
` + +- Close the welcome.htm file. Click “Yes” to save the changes. + + + +## Editing the README.md file + +The `README.md` file contains information about the keyboard useful for other keyboard authors who might revise or adapt the keyboard at some future date. This information is not presented to the end user. + +## Editing the LICENSE.md file + +If you filled out all the information in the New Project dialog, the `LICENSE.md` file should have been set up correctly. +Normally the only thing to change here would be changing the initial date into a date range (from `2026` to `2026-2027`, for example). +Changing the date in this manner is only needed when the keyboard is updated. + +## Editing the readme.htm file + +The `readme.htm` file is displayed as the user begins to install the keyboard. +It should contain a brief description of the keyboard with enough information to reassure the user that the right keyboard has been selected for installation. +Instructions for using the keyboard should be reserved for the `welcome.htm` file. + +## Editing the welcome.htm help file + +The `welcome.htm` file provides the help that is packaged with the keyboard. +This help file is displayed after the keyboard is first installed. +The user can also ask for the help file to be displayed. + +This file should contain enough information that the user can discover all the features of the keyboard. +This could be in the form of +- keyboard images for the different layers, +- a chart of how to type, +- a description of how to type (such as was used in the Step-by-Step tutorial), +- or some combination of these. + +One way to create keyboard images is to use the procedure in the "Exporting an On-Screen Keyboard layout" section of [Creating a Desktop Layout](03-creating-desktop-layout). +These images can be referenced from the welcome.htm file in this fashion: + +```html +Desktop keyboard layout
+Default (unshifted)
+
Shift
+
Right Alt (unshifted)
+