Hi Klaus,
Could you add a new option in Make.config for specifying the charMap-variable in menuitems.c?
This would be handy, because the map that's specified in menuitems.c lacks support for eg. Scandinavian characters like å, ä and ö and some other special characters. Also the character é is missing :-)
For now i patched menuitems.c like this:
--- menuitems.c.orig 2006-01-27 04:11:38.000000000 +0200 +++ menuitems.c 2006-01-27 04:15:54.000000000 +0200 @@ -245,7 +245,7 @@ pos = -1; insert = uppercase = false; newchar = true; - charMap = tr(" 0\t-.#~,/_@1\tabc2\tdef3\tghi4\tjkl5\tmno6\tpqrs7\ttuv8\twxyz9"); + charMap = tr(" 0\t-.#~?!':;,/_@1\tabcåä2\tdefé3\tghi4\tjkl5\tmnoö6\tpqrs7\ttuvü8\twxyz9"); currentChar = NULL; lastKey = kNone; Set();
Regards,
René
Rene Hertell wrote:
Hi Klaus,
Could you add a new option in Make.config for specifying the charMap-variable in menuitems.c?
This would be handy, because the map that's specified in menuitems.c lacks support for eg. Scandinavian characters like å, ä and ö and some other special characters. Also the character é is missing :-)
For now i patched menuitems.c like this:
--- menuitems.c.orig 2006-01-27 04:11:38.000000000 +0200 +++ menuitems.c 2006-01-27 04:15:54.000000000 +0200 @@ -245,7 +245,7 @@ pos = -1; insert = uppercase = false; newchar = true;
- charMap = tr("
0\t-.#~,/_@1\tabc2\tdef3\tghi4\tjkl5\tmno6\tpqrs7\ttuv8\twxyz9");
- charMap = tr("
0\t-.#~?!':;,/_@1\tabcåä2\tdefé3\tghi4\tjkl5\tmnoö6\tpqrs7\ttuvü8\twxyz9"); currentChar = NULL; lastKey = kNone; Set();
How about adjusting this in i18n.c instead? ;-)
Klaus
Klaus Schmidinger wrote:
How about adjusting this in i18n.c instead? ;-)
Well, no, because I use my VDR with the English menus (I don't like to use localized equipment and software...), and this way those characters would be lost..
That could of course be in the i18n.c too, but a global variable would not hurt in this case.. :-)
René
Rene Hertell wrote:
Klaus Schmidinger wrote:
How about adjusting this in i18n.c instead? ;-)
Well, no, because I use my VDR with the English menus (I don't like to use localized equipment and software...), and this way those characters would be lost..
That could of course be in the i18n.c too, but a global variable would not hurt in this case.. :-)
Well, i18n.c is there for internationalization, and the character map apparently needs to be localized, so it's in there. I don't want to make this another Make.config option, so I'm afraid you'll have to either fully switch to a localized language version, or live with your patch.
Klaus
Klaus Schmidinger wrote:
Well, i18n.c is there for internationalization, and the character map apparently needs to be localized, so it's in there. I don't want to make this another Make.config option, so I'm afraid you'll have to either fully switch to a localized language version, or live with your patch.
What about letting that be an special option for those who want to do it this way, like an #ifdef..?
René
Rene Hertell wrote:
Klaus Schmidinger wrote:
Well, i18n.c is there for internationalization, and the character map apparently needs to be localized, so it's in there. I don't want to make this another Make.config option, so I'm afraid you'll have to either fully switch to a localized language version, or live with your patch.
What about letting that be an special option for those who want to do it this way, like an #ifdef..?
I don't see how an #ifdef would help here.
Besides, you would have the same problem with the " abcdefghijklmnopqrstuvwxyz0123456789-.#~,/_@" string.
Klaus
Klaus Schmidinger wrote:
I don't see how an #ifdef would help here.
Well, I dont know enough about C, but somehow i guess that there should e a way in specifying variable somewhere, and that would be used instead for the defaut..
Besides, you would have the same problem with the " abcdefghijklmnopqrstuvwxyz0123456789-.#~,/_@" string.
Yup, that string occurs a few times :-) But in my case I just adjusted it for the character map used on the numeric keys. I havent checked what the other string was for..
René
On 1/28/06, Rene Hertell linuxtv@hertell.com wrote:
Klaus Schmidinger wrote:
I don't see how an #ifdef would help here.
Well, I dont know enough about C, but somehow i guess that there should e a way in specifying variable somewhere, and that would be used instead for the defaut..
Besides, you would have the same problem with the " abcdefghijklmnopqrstuvwxyz0123456789-.#~,/_@" string.
Yup, that string occurs a few times :-) But in my case I just adjusted it for the character map used on the numeric keys. I havent checked what the other string was for..
René
Just a idea but why don't put it in i18n.c like Klaus suggest and you make a new entry called "Norwegian with English menu" with good char map etc, then you just need to put your own i18n file at each new vdr release.
bob321 wrote:
Just a idea but why don't put it in i18n.c like Klaus suggest and you make a new entry called "Norwegian with English menu" with good char map etc, then you just need to put your own i18n file at each new vdr release.
Yeah, but then the i18n.c file has always be checked against any changes when a new verison arrives. In this case it would be easier to just patch menuitems.c.. (maybe I have to learn sed and create a script that fixes that for me... ? :-)
René
Klaus Schmidinger wrote:
Well, i18n.c is there for internationalization, and the character map apparently needs to be localized, so it's in there. I don't want to make this another Make.config option, so I'm afraid you'll have to either fully switch to a localized language version, or live with your patch.
hi, I think i is time to think about splitting up internationalization and localization. it is a matter of fact that most projects have these two seperated. I vote for a file l10n.c in future relases.
I am aware, that this requires code changes, but i would lead to a more universal vdr.
carsten
Carsten Presser wrote:
hi, I think i is time to think about splitting up internationalization and localization. it is a matter of fact that most projects have these two seperated. I vote for a file l10n.c in future relases.
I am aware, that this requires code changes, but i would lead to a more universal vdr.
I vote +1 for this! :-)
René
-
bob321 -
Carsten Presser -
Klaus Schmidinger -
Rene Hertell