Moving charMap from menuitems.c to Make.config

  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:

   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é