thoun did some code that might be helpful to solve this problem:
http://ultrastardeluxe.xtremeweb-hosting.net/viewtopic.php?f=16&t=133* p602 [^]

function TScreenName.ParseInput(PressedKey: Cardinal; ScanCode: byte; PressedDown: Boolean): Boolean;
var
I: integer;
SDL_ModState: Word;
begin
Result := true;
If (PressedDown) Then
begin // Key Down

SDL_ModState := SDL_GetModState and (KMOD_LSHIFT + KMOD_RSHIFT
+ KMOD_LCTRL + KMOD_RCTRL + KMOD_LALT + KMOD_RALT);

// M key fix
if ScanCode = 109 then Button[Interaction].Text[0].Text := Button[Interaction].Text[0].Text + 'm';
if ScanCode = 77 then Button[Interaction].Text[0].Text := Button[Interaction].Text[0].Text + 'M';

case PressedKey of
SDLK_0..SDLK_9, SDLK_A..SDLK_Z, ...

in lyrics unicode chars also do not work
will look what i could do :)

this is because of the bitmap font.
once we start using true type fonts, then we can tackle this issue better.

under linux some unicode chars in the lyric files displayed in the programm with multiple chars from the png. this is maybe an char-encoding error.

Replying to [comment:1 mogguh]:
> thoun did some code that might be helpful to solve this problem:
> http://ultrastardeluxe.xtremeweb-hosting.net/viewtopic.php?f=16&t=133* p602 [^]
>
> function TScreenName.ParseInput(PressedKey: Cardinal; ScanCode: byte; PressedDown: Boolean): Boolean;
> var
> I: integer;
> SDL_ModState: Word;
> begin
> Result := true;
> If (PressedDown) Then
> begin // Key Down
>
> SDL_ModState := SDL_GetModState and (KMOD_LSHIFT + KMOD_RSHIFT
> + KMOD_LCTRL + KMOD_RCTRL + KMOD_LALT + KMOD_RALT);
>
> // M key fix
> if ScanCode = 109 then Button[Interaction].Text[0].Text := Button[Interaction].Text[0].Text + 'm';
> if ScanCode = 77 then Button[Interaction].Text[0].Text := Button[Interaction].Text[0].Text + 'M';
>
> case PressedKey of
> SDLK_0..SDLK_9, SDLK_A..SDLK_Z, ...

Ohh, sorry. I haven't seen that somebody already worked on the M-key problem because it wasn't assigned to a developer in the sourceforge bug-tracker. The bug is already fixed so I hope you didn't spend too much time on this.

A few things are left to be changed. See:
http://trac2.assembla.com/usdx/ticket/47

Updating tickets (#59, #15, #16, #17, #47, #28, #56)

Updating tickets (#27, #7, #15, #44, #4, #5)

Using ScanCodes is not a good idea. It is very keyboard dependent.
At the moment we use unicode characters which works nice. The problem with this is, that this method does not work if some modifier keys are pressed. If STRG+S is pressed, SDL's unicode field contains a different character than 's'.

So, how to solve this? Go back to virtual key S?

unicode branch merged to trunk - testing phase

Unicode txt files are not recognized

UTF8 txt file does not show jap/chin. char (tried all encodings):
http://ultrastardeluxe.xtremeweb-hosting.net/test/utf8.zip

Test again now. Autodetection of UTF8 added.

Still char and in unicode the whole file is not displayed.
Tested with revision 2038 (15th december 2009)

Canni: our codebase is not the problem. The font we use atm has no support for Japanese and Chinese characters. We may merge another free font with these characters to solve the problem

- UTF8 characters work since the unicode branch was merged into the trunk
- A fallback font was added for Japanese font support

I consider this issue to be fixed.
The CTRL+['A'-'Z'] problem still exists but is not related to i18n. I opened a new ticket for this issue: #112