- Home
-
Training Materials
- Keyboards and Fonts
- Linguistics
- Literacy
- Oral Translation
- Others
- Scripture Use
-
Translation
- Scripture Forge
- Adapt-It
- OmegaT Translation Memory Tool
-
Paratext
- Paratext 9 Materials
- Paratext 8 Course Manuals
- Paratext 7.5 Course and Handbook
- Paratext 7.1 Basic Training
-
Paratext Tutorials
- Basic Editing
- Language Source Tools in Paratext 7.6
- View menu tutorial
- Basic introduction to USFMs
- Tips and Tricks
- Introduction to Using Notes
- Cookbook for Consultants
- Menus vary by active project
- Vérifications
- Help! Paratext has stopped working
- Help, send and receive is not working!
- Bible Modules
- Which Paratext Tool When
- Paratext-FLEx Integration Tutorial
- Back Translations and Interlinearizer
- Send-receive and backing up your data
- ParaTExt 8 Test Projects
- New features in Paratext 8
- Voice Marking Tools
- Animated introduction to Paratext and the stages of a translation project
- Setting up a Paratext Project for Success
- Import TXT or Word DOC Files into Paratext Using SILAS
- Illustrations and Maps
- Advanced Unicode handling
- Create a Custom Python Script in the Paratext Menu
- Create a Custom Scripture Check in the Paratext Menu
-
Translator's Workplace
- Adding BdT Menu to Logos 10
- Adding TW Menu to Logos 10
- Logos Bible Software
-
Translator's Workplace Logos Edition
- Logos 8 Get Started Manual
- Opening Logos
- Opening a Resource
- Navigating a Resource
- Reading Multiple Versions
- Basic Search
- Bible Search
- Looking for Bible Facts
- Using the Home Page
- Using the Passage Guide
- Using the Exegetical Guide
- Using the Bible Word Study Guide
- Using the Sermon Starter Guide
- Using the Topic Guide
- Studying English Words Using the Bible Word Study Guide
- Studying Hebrew and Greek Words Using the Bible Word Study Guide
- Prepare a Bible Lesson Using the Sermon Starter Guide
- Look for Information on a Topic Using the Topic Guide
- Saving Your Workspace or Layout
- Arranging the Windows
- Study a Word Using a Reverse Interlinear
- Study a Word Using a Morphology Search
-
Logos edition
- Logos 8 Get Started Manual
- Set up TW Logos for Success
- Quickstart Guide
- Advanced Tips
- Scrolling with other Translation Programs
- Transition from TWFolio
- Troubleshooting
- External Resources
- Low Bandwidth Installation and Updates
- Turn off Logos internet use when visiting a low bandwidth area
- Logos for Beginners Video-based Training
- Translation Workplace - Folio edition
-
Consultant Training
-
Regional Workshops
- Africa Kenya Workshops(LTCT)
- 2021 Africa Virtual Workshop
- 2020 Africa Nairobi
- 2019 Africa Nairobi
- 2018 Africa Nairobi
- 2017 Africa Nairobi
-
2016 Africa Nairobi
- Course Objectives 2016
- Course Schedule 2016
-
Course Program 2016
- HearThis Session 4
- FLEx 8 Lexicon Edit
- FLEX 8 Using text to build lexicon
- LTCT2016 FLEx - Export
- Scripture App Builder Day 1
- LTCT2016 WeSay New Projct
- Create a new project from a FLEX Lift File
- LTCT2016 Wesay Wordlist
- LTCT2016 WeSay Collaboration
- Scripture App Builder Day 1B
- Scripture App Builder Day 1C
- Scripture App Builder Day1D
- Scripture App Builder Day 2A
- Scripture App Builder Day 2A
- Scripture App Builder Day 2B
- Scripture App Builder Day 2C
- Scripture App Builder Day 2D
- Scripture App Builder Day 3A
- Scripture App Builder Day 3B
- Scripture App Builder Day 3C
- Scripture App Builder Day 3D
- LTCT2016 RegExp
- LTCT2016 Paratext1
- Evening Sessions 2016
- Morning Sharing Time 2016
- Responsibilities 2016
- LTCT 2016 Evaluation
- 2015 Africa Nairobi
- 2014 Africa Nairobi
- 2014 Africa Kara, Togo
- 2013 Africa Nairobi
-
2012 Africa Nairobi
- Course Objectives 2012
- Course Program 2012
- LTCT2012 Friday Jan 20
- LTCT2012 Thursday Jan 19
- LTCT2012 Wednesday Jan 18
- LTCT2012 Tuesday Jan 17
- LTCT2012 Monday jan 16
- LTCT2012 Saturday Jan 14
- LTCT2012 Friday Jan 13
- LTCT2012 Thursday Jan 12
- LTCT2012 Wednesday Jan11
- LTCT2012 Tuesday Jan 10
- LTCT 2012 Monday Jan9
- LTCT2012 Evaluation
- Proactive Software Training
- Teaching a Workshop
-
Paratext for Consultants
- 1 Arranging your workspace
- 2 Consultant notes
- 3 Searching and Dictionaries
- 4 Send and receive
- 5 Taking notes during checking
- 6 Keeping track of Biblical term renderings
- 7 Using the Biblical terms tool
- 8 Seeing history and comparing versions
- 9 Understanding the vernacular text
- 10 Spell checking
- Video lessons
- Paratext Supporters
- Digital Publishing
-
Regional Workshops
- Webinars
- Resources
-
»
- KDT Session 2
Keyman Developer Tutorial
Modify a Desktop Keyboard
Session 2
This session we will modify a desktop keyboard for the Dagbani language of Ghana.
1. Start Keyman Developer.
2. In the Project menu, point to Recent Projects, click DagbaniTutorial.kpj.
3. In the Project - Keyboard dialog box, click Keyboards. Then click dagbanitutorial.kmn. The Details pane appears.
4. Click Layout. The Layout pane appears. There is a Design tab and a Code tab. The Code tab shows us the code that Keyman compiles to build the keyboard. The Design tab shows a pictorial picture of the keyboard.
If we click Design tab, we get a message indicating the keyboard is too complex to represent and modify visually. If we remove the NCAPS lines (55-183) by cutting them. then the Design tab will display. Be sure to save the NCAPS lines in a text file. Then we will be able to paste them back later. See sample lines below.
5. We will show how to make changes using the Design tab. Click Design tab.
6. In this tab, we see a visual representation of the keyboard. We can change what the keyboard will do when we press a certain key.
Since the q and x characters are not used in the Dagbani language, we could reassign the keys to other characters in the language like open e and open o, the other two vowels in their language.
To change the q key to open e key, click on the q key in the layout to select it. In the Character Map pane, enter open e in the textbox at the bottom of the pane. Highlight the Latin small letter open e character by clicking it. Then double-click it. Note that the Unicode Character Value and the Output character box are updated with open e Unicode codepoint and character respectively.
Note that we can enter in the textbox at the bottom of the pane the Unicode value (e.g. 025B) to bring up the character. Or we could enter a range of Unicode values (e.g. 0620-064F) if we are working with a range of characters.
To change the x key to open o key, in the Character Map pane, enter open o in the textbox at the bottom of the pane. Highlight the Latin small letter open o character by clicking it. Then double-click it. Note that the Unicode Character Value and the Output character box are updated with open o Unicode codepoint and character respectively.
7. We would also need to do this for the capital letters. So first we need to click the Shift key on the keyboard. The Shift key will change colors and the keyboard will change to reflect what happens when we use the Shift key.
To change the Shift-q key to the upper-case open e key, in the Character Map pane, enter open e in the textbox at the bottom of the pane. Highlight the Latin capital letter open e character by clicking it. Then double-click it. Note that the Unicode Character Value and the Output character box are updated with the upper-case open e Unicode codepoint and character respectively.
To change the Shift-q key to the upper-case open o key, in the Character Map pane, enter open o in the textbox at the bottom of the pane. Highlight the Latin capital letter open o character by clicking it. Then double-click it. Note that the Unicode Character Value and the Output character box are updated with the upper-case open o Unicode codepoint and character respectively.
Let's look at the code we generated by clicking Code. Note that we now have four new rules under the group (main).
8. In this case, we do not really to replace the q and x keys, since we may want to use them for borrowed foreign words. Also, we would need more keys for the consonants not on the keyboard. So, we will delete the keys that we just added, by deleting the text in the Unicode Character Value(s) text boxes for the four keys in the Design tab. Or we could delete the keys, by deleting the fours line of generated code in the Code tab
9. We will use a different method for adding those keys. First click the Code tab.
We will want to paste back the NCAPs lines that we save in a text file to their original position.
Now we are ready to add some code to add our special characters. We are going use a semicolon plus a character to enter our special characters. We could add a line for each special character as below, using the keyman rule structure Content + Keystroke gives Output.
Begin Unicode > use(main)
group(main) using keys
";" + "e" > "ɛ"
";" + "o" > "ɔ"
";" + "n" > "ŋ"
";" + "g" > "ɣ"
";"+ "z" > "ʒ"
";" + "E" > "Ɛ"
";" + "O" > "Ɔ"
";" + "N" > "Ŋ"
";" + "G" > "Ɣ"
";" + "Z" > "Ʒ"
By pressing the semicolon key followed by the e key we will get the open e. This same principle applies to the rest of the special characters as above.
But there is a more efficient way to write this code. We can create variables that hold a group of characters. We will create two groups of equal size, and then in the rule, we will tell Keyman to replace a member of the one group with the corresponding member of the other group.
begin Unicode > use(main)
store(basekey) "eongzEONGZ"
store(output_char) "ɛɔŋɣʒƐƆŊƔƷ"
group(main) using keys
";" + any(basekey) > index(output_char,2)
Let's look at this rule.
';' + any(basekey) > index(output_char,2).
This says, “When there is a semicolon in the context and one of the characters in basekey is typed, outputting the character at the same index point for the second argument on the left side of the expression.”
The number 2 in the index is known as the offset. It is not referring to the second character in the index. Instead, it is saying that the index is based on the second argument on the left.
This example will help clarify. If we wanted to produce a special character every time the base character was typed (swapping a ɛ for every e), then we would remove the semicolon context and write the rule this way:
+ any(basekey) > index(output_char).
Now the index defaults to the first argument on the left side of the >. We don’t need to include the offset at the end of the index since 1 is the default.
Now we can enter above into the Code pane as indicated below.
10. Click the Save icon to save our work.
11. We could have use a deadkey for producing our special characters. A deadkey is like a character that is used in the context or output but never appears on the screen. We would use deadkeys like this:
c semi-colon becomes a deadkey
+ ";" > deadkey(semicolon)
c Handle semi-colon
deadkey(semicolon) + any( basekey ) > index( output_char, 2 )
c Handle a single semi-colon
deadkey(semicolon) + ";'" > ";'"
Note that for the sake of convenience, a deadkey can also be written in a short form:
dk(semicolon) c This is identical to deadkey(semicolon)
Typing the three rules above in place of the existing rule %22;%22 + any(basekey) > index(output_char,2) for the semi-colon. If we test the keyboard now, we would find that we would be able to produce the special characters in this way, too. But we've introduced another difference to the keyboard now: the semi-colon is no longer displayed before we type the vowel. This is because we are converting the semi-colon to a deadkey.
Notes
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.
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 us to identify them easily, and keeps them consistent with keyboard programs other people might write.
The keyboard rules section is the most important part: it determines the behavior of the keyboard. The section consists of groups, which in turn contain one or more rules which define the responses of the keyboard to certain keystrokes.
There are two types of groups: groups that process the keys pressed and the context, and groups that process the context only. For simple keyboards, the latter type of group will not be required. A group begins with a group statement, and ends either at the start of another group, or at the end of the keyboard file. An example group statement is given below.
group(Main) using keys
The using keys clause tells Keyman that this group will process keystroke.
Below the group statement there is a series of rule statements. 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.