Opened 7 years ago

Last modified 5 years ago

#886 reopened defect/bug

Ñ and ç missing from keyboard

Reported by: amontero Owned by: KaZeR
Priority: major Milestone: version 0.5.1
Component: core Version:
Severity: trivial Keywords: keyboard, i18n
Cc: amontero@…

Description

Missing keys: Ñ/ñ - A must for Spanish Ç/ç - Catalan / Portuguese / French / ...

Navit for Android 0.5.0 4281 (from Market)

Great app!! Thanks.

Change History (8)

comment:1 Changed 7 years ago by tryagain

I'm thinking to implement a feature (for POI search at first) to remove all diacritical signs from both query text and item attributes when comparing them. So nobody will be obliged to enter search string with correct diacriticals to do a search.

I feel that to be quite useful for non-native speakers. Even native speakers don't always distinguish similary looking diacriticals: http://en.wikipedia.org/wiki/Romanian_alphabet#Comma-below_.28.C8.99_and_.C8.9B.29_versus_cedilla_.28.C5.9F_and_.C5.A3.29

Another step is to do romanization on search string and item attributes, so you'll not have to distinguish between, e.g. similary looking Cyrillic and Latin letters.

Of course, that features will not have any effect on the letters displayed in search results or on the map.

comment:2 Changed 7 years ago by mvglasow (2)

Something like this is already available for town/street search. Entering "Munchen" or "Muenchen" will find "München" and similar.

The code (along with translation table) is in linguistics.c; IIRC the search function calls it indirectly (going through the respective map driver). Maybe you can reuse that code.

It has one advantage over what you propose: it can support multiple (currently up to 2) equivalents for the same accented character, including digraphs (in some languages, e.g. German, the official rule is to use digraphs as substitutes for certain characters which are not available, e.g. ae=ä, oe=ö, ss=ß; others (Latvian) use similar schemes inofficially).

The table in linguistics.c is still incomplete as of r4692, see ticket #917 for an enhancement which should work for most of Europe (Latin alphabets only).

Romanization of Cyrillic should be possible as well that way, though you'd probably be dealing with a couple of options for each letter (a similar-looking Latin one as well as phonetically equivalent ones, which may be more than one).

Last edited 7 years ago by mvglasow (2) (previous) (diff)

comment:3 Changed 7 years ago by korrosa

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

This should be fixed by the patch in #917: http://navit.svn.sourceforge.net/navit/?rev=4706&view=rev.

If the problem persists, please re-open this ticket.

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

  • Resolution fixed deleted
  • Status changed from closed to reopened

Reopening as the POI search does not use the routines in linguistics.c yet. The code for translating is there but we still need to modify the POI search to use it.

Proof: A modified r4710 (with the upcoming second patch for #917) finds Klaipėda when searching for "klaipe" in city search, in street search "klaipe" finds Klaipėdos gatvė in Vilnius, but when searching for POIs (tested in Vilnius) by name, "aib" returns five results (four times Aibė, one time Aibe – apparently misspelled), "aibe" returns only one (the misspelled one).

Last edited 5 years ago by usul (previous) (diff)

comment:5 Changed 5 years ago by usul

  • Keywords keyboard i18n added
  • Milestone set to version 0.5.1

Ok, we need to check this issue on the POI search dialog, too. IMHO there were other Android related tickets, which pointed out, that the POI search widget is handled different, too (there the Android soft keyboard).

Important for international users, so scheduled for 0.5.1 hotfix

comment:6 Changed 5 years ago by tryagain

POI search since r5296 supports diacritic removal with the same algo as is used in the address search.

As for the ticket title, we are probably still missing these keys from our keyboard. But one shouldn't care too much now: just enter the whole search string without diacritics at all and you get your search result. This works both for Latin and Cyrillic based alphabets.

If some diacritics processing still behaves bad, we could fix it.

Should we care to add missing keys to the internal keyboard?

comment:7 Changed 5 years ago by amontero

  • Cc amontero@… added

Agree on search being the main benefit of this ticket. However, special chars can be used also when saving POIs, although I admin that this is a low prio annoyance. +1 to add diacritics. As long as it is clear for the user that entering "c" will match "ç" it is a good compromise. However, if this is not made clear, it is a UX issue, anyway.

comment:8 Changed 5 years ago by usul

  • Severity set to trivial
Note: See TracTickets for help on using tickets.