Swedish, Danish + More Nordic Layouts now Up!

New layouts are on the Blog for Swedish, Finnish, Norwegian, and Danish!

There are no cows on the ice ;). You can get all your characters on a TextBlade now, including Å, Æ, Ø, Ö, Ä and other common symbols.

Comments, suggestions and questions are welcome here.

Danish keys are great news! But I can’t seem to choose the danish layout under the Customize section

ErikIt - yep, working on that. New ones will be up on the selector in a day or so.

Danish and other new layouts now available on the cart page.

Looks ok, however. I am a bit confused how would you use it? Let say you want to write

Å være eller ikke å være;
det er spørsmålet: For hva er en edel ferd?
Å tåle dette regn av stein og piler
en bitter skjebne sender mot oss?

Eller å trekke sverdet mot et hav av sorger
og gjøre slutt på dem? Å dø og sove
ja, bare det. – og se at søvnen slukker
all hjertekval, de tusen plager kjødet
er arvelig til. Hvor inderlig man ønsker
mot denne slutt: å dø, å sove. Sove,
kanskje drømme? Ja, se det er byrden:

(This is the famous passage from Hamlet translated to Norwegian)
The primary question I have is how do you write capital Å with TextBlade?

Å is accessed by holding the SpaceBlade down and tapping the P / Å key.

Likewise, ø is accessed by holding the SpaceBlade and tapping the Æ key.

Since your thumbs are always on the SpaceBlade, this can be done instantly and without any relocation of your fingers. This makes accessing the green layer much easier than our closest reference point: getting capital letters on a legacy keyboard.

The MultiLayer Keys video on our website demonstrates how this works.

Wouldn’t that give me only an ‘å’ and not ‘Å’? Do I need a three key combination to write a capital Å?

1 Like

Superhai –

You don’t have to hold 3 keys. There’s actually several ways to get capital Å.

  1. TextBlade supports tap-shift (works like the iPhone shift key), which capitalizes the next character you type. Our team now usually types capitals this way – we find it’s faster than concurrently pressing shift. So, you tap shift, then access the capital Å.

  2. Hold Spacebar + Shift. Ergonomically, this combo feels very natural. Since your thumb doesn’t change positions, it doesn’t feel very different from a standard shift.

  3. There’s an even faster way to get capital Å, and it’s in our latest patent. We’ll publish how that works after that patent filing is complete. This method is optimized for the fewest actions, and we think you’ll really like it.



I have recently checked out the Danish/Norwegian layout with the TextBlade App.
The layout is more appropriate for Danish than for Norwegian, due to the fact that the rightmost key is made with an Æ-letter rather than the Ø-letter.

On the Norwegian Apple keyboard as well as Microsoft, Logitech, Samsung, SwiftKey are all set out with Ø - Æ - Å**, whereas the Danish are Æ - Ø - Å.

The Norwegian layout is more alike the Swedish/Finnish, except that the Ö is replaced with Ø.

Apple Norwegian Keyboard:

Apple Danish Keyboard:

The erroneous placements of this letter may be irritating for Norwegian touch-typers.

This problem can easily be corrected with the MultiMap option, but setting paperstickers on such a nice keyboard will be sad. Perhaps a new keycap can be produced?

Also the yellow keys on the Apple Keyboards are the diaeresis/diacritic keys - a key used with another key makes up a third, usually ä, ë, ï, ö, ü, etc. (Several other keys have similar functions, Spanish C and N, Frence accent grave and agy.)
Have all these combinations thoroughly been testet?

1 Like

Somewhere they stated that it’ll be possible to get more customized layouts later. Not sure if this’ll be included

From the blog post referred to at the top:

“A special note for our Norwegian customers – literary quote symbols are reversed between Danish and Norwegian.The keys are imprinted with the Danish convention, and you can reverse this to the Norwegian convention by loading the Norwegian map from our cloud library.”

The same is the case for the æøå on the key caps, they are with Danish layout. The keymaps in Multimap 1.0.1 (app store version), also seems to be identical for Norwegian and Danish.

Don’t think this has been tested with any native speaking Norwegians, but both you and I have requested to be part of TREG to specially test this …

I believe that when using the TextBlade with the multimap externtion on iOS, things are quite straight forward.

But when flashing these European maps to the TextBlade, and using them with OS X, Windows, Android, and iOS (without the TextBlade/Multimap extension) things gets more complicated. Then one also have to rely on the different OS’e’s keyboard drivers for the respective languages.

For Colemak and Dvorak it’s simpler, they just require US QWERTY drivers on the host. For Japanese and Korean, I believe it is the othe way around: TextBlade in QWERTY mode and Japanese or Korean driver on the host (please correct me if wrong). With Tibetan for example, one could use the TextBlade with either QWERTY or Colemak, whatever one is most comfortable with.

So, I’m also a little worried here, if all the European maps really have been tested on OS X, Windows, etc. Have not heard a word about this from the TREGers, or did I miss something?

Example: Normally keyboards are just sending scan codes, and AZERTY or QWERTZ mappings are done by the host’s keyboard driver. But what happens when you flash the TextBlade with either French or German keymaps for use on OS X, Windows, Android or Linux? Remapping of Q-A, W-Z or T-Z on both? Do they then cancel each other?

I guess all this already must have been tested, but asking just in case …

This has been addressed in some other posts, I think a quick search might bring up what you’re looking for.

I believe the idea is that one system want to translate the key codes - not both. So have either the host or the TextBlade do it. Otherwise, you would likely get that “double” translation.

I honestly really like that it’s that flexible, although I think it would be good for non-advanced users to have a “right” or “recommended” way to do it so that there’s no uncertainty about if they’re doing it right. That would likely be a good thing for WayTools to include in the getting started documentation.

Central- FYI - there’s a new control built into the upcoming release that should give you exactly what you need for this.

Kind of a first world problem, but once you like using Jumps, it’s just a natural demand for what’s needed to complete the picture.

Since every host might have it’s own remapping previously installed locally, you want the option of having TextBlade handle all the translations automatically for you, so it just works.

In addition to configuring the Jump slot with a particular map, and also a different OS - this new config feature also let’s you specify the standard that’s resident on the host. If you know what the host is expecting, you can speak its native language. This avoids changing anything on each host.

This turns out to be really useful.

Personalizing our main keyboard for all our unique needs, and making it consistent and portable across all our diverse platforms - this really helps streamline and harmonize the typing experience.

Look forward to comments from TREG once they get this new release.


I’m really looking forward to this - it will address a longstanding complaint that I’ve had – namely, that I don’t want to have my host systems assume that they’re expecting US QWERTY layout. Mine are mostly set in either Dvorak or Japanese QWERTY.

(But when I use the TextBlade Dongler, it will be Dvorak mapped to US QWERTY, since I only ever use that on hosts that are expecting that).


Excellent! So for a novice user you can just put in what the system is set to, and it’ll figure it all out.

And an advanced user has the control they need to address any specific behavior they want.

Sounds awesome to me :slight_smile:

Out of curiosity, does it do this for iOS as well - I know there are several options in iOS settings where you can tell it the type of hardware keyboard that is present. I currently use this to switch (my physically QWERTY keyboard) to Dvorak occasionally.

1 Like

Yes, iOS is supported just like Android, Windows, Linux, OS X, etc.

Basically you have a config screen for each jump slot.

You choose a map, an OS, and the standard which the host is using as input.

The app figures out all the translations automatically, and installs the map-transforms into your TextBlade’s flash memory.

And further, you can define your own custom map with the MultiMap editor.

When you hit the jump, everything is reconfigured in less than a second.

It’s pretty cool.


This sounds super cool.

I am really looking forward to being able to use a single keyboard with my own custom maps on every device. For the computers, I’ve had a program that lets me use the mouse and keyboard attached to one device across all the screens from all computers. But never anything to let me keep the same keyboard across to mobile devices, OS-es, etc…

Thanks for the added details - sounds like a well-thought out design. Seems like it should work for all levels of users without confusing anyone. :smiley:

1 Like

Thanks a lot for detailed info.

One more question though: Are there still only 6 jump slots? So if we want 2 keymaps available on the TextBlade for all hosts, are we then left with only 3 available host positions? Or if wanting 3 maps for all hosts, only 2 hosts?

Also new versions of app and firmware were said to be released this week. Will the the new app version be released on the AppStore? Or just with TestFlight for TREG?

[quote=“rover, post:22, topic:595”]
Also new versions of app and firmware were said to be released this week. Will the the new app version be released on the AppStore? Or just with TestFlight for TREG?
[/quote]I would expect the new version of the app to be sent to TREG users initially as the review process for Testflight releases is much less rigorous (and faster) than that for full releases. That gets tends to be the general approach with most iOS software which have a (beta) test group available as its gets visibility of any issues as quickly as possible.

If there are no issues found then it is possible Waytools may then consider releasing the same build as the general release version as well. but my expectation is that as this is the first version of a significant enhancement there may well be some tweaks needed to get it just right.

I could be wrong about the above, but it does seem reasonable. Having said that I could see some advantage to making the release generally available as well even if it is expected it will be superseded before general release of the hardware as it would give users still waiting for their hardware a view of how the app is progressing.

I guess we will have to wait and see what the official response is?

That makes a lot of sense.

I kind of guessed that you had implemeted a language specific “reverse mapping” (special characters to scancodes) when flashing a map to the TextBlade. That we now also can specify the language expected by the host, makes Multimap even more flexible.

Otherwise (without this feature) if we modified the stock QWERTY map to become AZERTY, for example, we would end up with double translation and multiple confusions :wink: