Opened 12 years ago

Closed 9 years ago

#771 closed task (fixed)

using android keyboard: (german) umlaute not accepted

Reported by: kaamikaze Owned by: zoff99
Priority: minor Milestone: version 0.5.1
Component: port/android Version: git master
Severity: Keywords: input, i18n


When using android keyboard by long pressing the menu button and typing letters, navit ignors umlaute. But navit is capable of handling this umlaute since its own keyboard has a button to switch from normal characters to umlaute.

Found this behaviour when searching for the german city Lübeck.

navit version used: 3941 on Samsung Galaxy i9000

Change History (6)

comment:1 Changed 12 years ago by zoff99

  • Owner changed from cp15 to zoff99

comment:2 Changed 12 years ago by thomasah

I can confirm this with svn r4376 on Motorola Defy. But searching for "Luebeck" works fine, too.

comment:3 Changed 12 years ago by thomasah

  • Cc added

comment:4 Changed 10 years ago by mvglasow (2)

Still an issue in r5187, CyanogenMod? 7.2.0 on Nexus S.

This affects all kinds of special letters, including German umlauts and Baltic special characters (tested with ė).

Substituting these letters with plain ones will work in most cases (town and street search) due to the internal search logic. AFAIK this is not implemented for POI search, so POI names must match exactly. See also #917.

comment:5 Changed 10 years ago by usul

  • Keywords input i18n added
  • Milestone set to version 0.5.1

I think the Android keyboard emulates keystrokes, so I guess navit has problems in handling this special keycodes?

As this is might confuse users and they think that navit has a general problem with the city data, we should fix it in the next minor relase.

comment:6 Changed 9 years ago by tryagain

  • Resolution set to fixed
  • Status changed from new to closed

Actually, Android software keyboard is emulating keystrokes, but it does it in a few different ways. Also, it's not compatible to count on keystrokes from sw keyboard at all.

With svn 5633, we accept the whole range of unicode characters from sw keyboard. We even accept voice input now.

Next step improving compatibility with Android keyboard would be switching to use [a hidden] EditText? control instead of key events processing.

Note: See TracTickets for help on using tickets.