This is the bug/patch tracker for Rockbox. Click here for more information.
Quick links: Bugs · Patches · Rockbox frontpage
FS#9538 - tagnavi search condition opperator supports for non lattin alphabet
Attached to Project:
Rockbox
Opened by Yoshihisa Uchida (Uchida) - Sunday, 09 November 2008, 08:54 GMT+2
Opened by Yoshihisa Uchida (Uchida) - Sunday, 09 November 2008, 08:54 GMT+2
|
DetailsThe search condition of tagnavi (eg. =, >, ^,...) doesn't return a correct search result to characters other than the Latin alphabet.
For example; 1) artist ^ "A" Neither "Ándre" nor "ándre" appear to the search result. 2) artist = "Ándre" Neither "Andre" nor "andre" appear to the search result. My patch file solves such a problem. Because it doesn't test enough. There is still a possibility that the search result is not correct according to the character used. Please report. About performance The search time is slow than before. I will improve this in the future. About patch Please execute make zip (or make fullzip) after applying the patch to the source file. There is uni.mt(or unimini.mt) in .rockbox/codepages folder when rockbox.zip is unziped, and copy this file onto your player's .rockbox/coepages. (The search result doesn't correct if there is no uni.mt(or unimini.mt)). About search result 1) It is considered that the character that is the difference of the uppercase, titlecase and the lowercase is the same. eg. A = a, Ω = ω 2) It is considered that the character with the pronunciation sign (accent, umlaut, etc.) is the same as the character to which these are not attached. eg. A = Á 3) The combination character is considered to be a character that divides into each character. eg. Œ = O E 4) Only Japanese: the Hiragana, the halfwidth Katakana are considered to be the same character as the fullwidth Katakana. eg. あ = ア, ｱ = ア 
tagnavi_search.patch
(114.4 KiB)
tools/Makefile | 6 tools/configure | 2 tools/buildzip.pl | 3 tools/code_mapping_tables.c | 3615 +++++++++++++++++++++++++++++++++++++++++++ tools/code_mapping_tables.h | 31 tools/mkmappingtable.c | 168 + apps/tagcache.c | 55 apps/tagtree.c | 5 firmware/export/unistring.h | 29 firmware/unistring.c | 190 ++ firmware/SOURCES | 1 firmware/include/rbunicode.h | 2 firmware/common/unicode.c | 186 ++ 13 files changed, 4244 insertions(+), 49 deletions(-) |
This task depends upon
- It's not clear to me that 1) is a problem, and I think that 2) is actually desired behaviour (i.e. if I explicitely ask for an accent, I want to get it)
- Such tables need to be language dependent for them to work properly in all cases (Have a look at e.g. I,i in Turkish, but I think that the problem is likely to be more general)
- How do you handle things like ue vs ü? Again, this is language dependent (I'm not called Gevärts)
- This is going to add a significant chunk to the core RAM usage
One complication with all the language-dependedness is that it's also not always clear if it depends on the UI language or the tag language.
My patch file was updated.
changes:
- The usage of the memory was changed to an efficient method.
- It was corrected that the user was able to select the mapping rule.
Settings > General Settings > Database
New menu "Tag string mapping rule" add.
- "Ignore diacritial mark"
If you select "Yes", then it is considered that à = a. (default)
If you select "No", then à != a.
- "Umlaut mapping mode"
If you select "ä -> ä", then it is considered that ä != a, ae, ë != e, ee, ï != i, ie, ü != u, ue, ö != o, oe.
If you select "ä -> a", then it is considered that ä = a, ë = e, ï = i, ü = u, ö = o. (default)
If you select "ä -> ae", then it is considered that ä = ae, ë = ee, ï = ie, ü = ue, ö = oe.
The mapping rule of each language was not prepared.
It is because the music file written in the language in various countries is obtained, and there is a possibility of hearing it with Rockbox.
A lot of mapping rules might come out. It will think about another method again at that time.
Moreover, please give the comment to me when there is a noticed point.