Banlilst : Name with accent not shown correctly

[TotoIsBack]

I understand that for the regex, the accent are not shown correctly and you need a lib that is kinda big for it.
(even if i'm kinda surprised that you can't handle accent other than using a lib that is 19MB big....)

But, what i don't understand is that the banlist window (just the window showing all the bans) looks like to be a QTableView or am I wrong here ? Even if it's not, it's just a window showing text.

What i do not understand is, why the "print" process of the accent can't be handled in the banlist window for normal text use (not regex use) ? in what is this banlist window so different from the rest of the teamspeak programm where everywhere else accent are correctly interpreted and shown ?

[Peter]

Hmm let me put it this way:

Of course we can display unicode characters in the ban list dialog. But there are NONE! Why are they none? Because the server intentionally does not allow unicode characters in the banlist, since they wouldn't work (because the regexp lib doesn't understand them). The server automatically converts any invalid character (aka unicode character) to it's ascii escape sequence. It is important that you see the server did this, since it can change the meaning of a regexp (see the Я* vs &#NUMBER;*
example below. It is NOT the same thing). Obviously we *could* have the client ui display all the "&#NUMBER;" sequences as unicode character instead, but you then could not understand why the heck "Я*" is banning people called "Я;;;;;;;;;;;;;;;;;", so it just shows the bans as they really are seen to the server, to allow you to understand them too

[TotoIsBack]

Oh ok, now i understand.
But, why wouldn't you show them correctly for fixed string and like now only for wildcard and regex ?
Or does fixed string use regex in background too ?

Anyway, this system can confuse alot of people like i was before your explanation...

Another suggestion, why not keep the name column in the banlist and add another new one that would show the real string like now ?
I really thing that this could avoid alot of confusion and have a better visibility of the banlist

[florian_fr40]

My little 2 cent on this topic.

Ok for the explaination, but I guess there is another little problem on some Operating system with a poor behavior with the characters.

Example with this nickname : poké moi

So I select this "string" and copy/paste into a new ban rule.
With TotoIsBack no problem, but on a Windows XP pro (SP3) we get this :

poké moi

We have the é for the é, here no problem.
But we also have the space with his code.
And the problem is this ban rule doesn't work. We have to remove the space code. (same with FixS, Wil, RegX)

[Peter]

Oh ok, now i understand.
But, why wouldn't you show them correctly for fixed string and like now only for wildcard and regex ?
Or does fixed string use regex in background too ?

The fixed/wildcard/regexp options are only valid when adding/editing bans, every ban that is in the ban list is a regexp.

Another suggestion, why not keep the name column in the banlist and add another new one that would show the real string like now ?
I really thing that this could avoid alot of confusion and have a better visibility of the banlist

I can understand it would be nice to see a graphical representation of these characters somettimes so you get an idea what on earth this is, maybe we can add it without making things awkward, we will discuss internally.

I guess there is another little problem on some Operating system with a poor behavior with the characters.

Example with this nickname : poké moi

So I select this "string" and copy/paste into a new ban rule.
With TotoIsBack no problem, but on a Windows XP pro (SP3) we get this :

poké moi

We have the é for the é, here no problem.
But we also have the space with his code.
And the problem is this ban rule doesn't work. We have to remove the space code. (same with FixS, Wil, RegX)

There are different spaces out there, many of them, the regular ascii space, the non breaking space you mention (unicode 160) and at half a dozen more... So the ban system is correct to differenciate these two and to ban only poke moi with a non breaking space if that is what you paste into the ban field. Now there might be a problem where a "regular space" in nickname gets converted to a non breaking space in some display widget and you then copy and paste the name from there getting a different space than the one you expected. This would be a bug. If you are sure the name contains a regular space please tell us exactly from which widget you copy&pasted the name and we can look into it.

[TotoIsBack]

Peter, i must say i love you !
At least with you we can really talk and understand the problematic and have a solution/answer that really helps.
I really hope that you will make something about this and find a solution internally, that would just be totally awsome ! Thank you !

[TotoIsBack]

Ok just saw your reply about the bug.

We reproduced it like this :

When connecting using the nickname "poké moi" in the connecting window using simply our space key on the keyboard.
Then connect to the server.
Then with the admin account, copy the nickname from the server chat tab.
Then go on the banlist, click the "add" button and past the name in the name field.
Apply and voilà ! (btw, you can use wildcard, fixed string or regex, this doesn't matter).

The only thing is, this work always on Win XP, but not on Win 7 where it is random (I had this only once and couldn't reproduce it).

But, the other thing is, that even if now i understand how your banlist works, i had the problem, that randomly the ban system will not ban the nickname with an accent or special char in it.

I can't reproduce it but i had the problem (and if you look some replies befor this one, you'll see that i was not the only one).

So looks like we have a copy/past problem like you said it could be + sometime the ban system not correctly interpreting a nickname with special char in it on windows 7.

[Edit] I just tested it again and could reproduce it on Windows 7 too !

[Edit2] Looks like the problem comes from the chat tab (server one in this case).
If i just write manually "poké moi" in the add field then the space is converted correctly.
But, if i copy/past from the server chat tab the nickname, then i will have the none braking space added in it instead of the normal space.

So it looks like that my bug report, was not so non-buggy at all at the end....

[Peter]

Couple Questions:

(1) Tell us the exact client version on the client that show this problem (you can see it in help->about)
(2) You say you copy it from server tab, do you copy it from one of the informational messages? Please show us one of the exact messages from where you copied so we know where exactly you copied from.
(3) Does this work with any nick name that contains a space, or is the accent important? Try a name like "test 123" or so please.

[TotoIsBack]

Client : V3.0.5 (same for Florian) Bug is reproducible on windows XP/Seven/Linux
Server : V3.0.2 (Linux)

You were right, the nickname is copied from the following informational messages :

- Connect
- Disconnect
- Ban
- Server Group Assignment
- Private chat
- Information about the client (on the right side of Ts)
- Switch
- etc...

[Edit]But, if the user poké moi for example write me a private message saying "poké moi" and i copy/past from there (the normal chat message text) the space is normally interpreted.

Tested with "test 123" it is exactly the same thing.

Looks like everywhere it is shown it will use unbreakable spaces
(Sound like a nice little general bug )

[Edit2] Wait, wait, wait.... i found some more bugs !
I suppose this can be related to the problem showing the accent or not in the banlist.
As you can see in this screen, i have 2 times the same ban name added.
In one of them, the client was connected, so i have the "last name" field with his nickname shown WITH the accent :
The second one, i just copied/pasted the name and added it to the ban list.
This time there ISN'T "last name" field shown :

So, now i tried to search in the banlist the nickname with "pok" and i saw both of them :

But i search with "poké" and here is the glitch, i only see the first one that was added and that has the "last name" field. :

So, i'm not sure about the bug itself but i'm supposing the following :

The search function don't convert the accent in the "&#NUMBER;" format and thus don't search correctly and don't match the result. But it also (or only ?) search in the "last name" field.

But, if i search the terms : "poké moi" it will show both of them.

So, the accent thing looks like to be a real pain in the ass at the end

[Edit3] I found another bug that is directly concerned with the accent problematic.
I added the name "poké moi" in the ban list.
It is shown as "poké moi" in the ban list.

So, if i connect with the client, that use "poké moi" as name, it will be correctly ban.
BUT, if when i'm connecting, i use as nickname "poké moi" i will aslo be banned !
So this is totally not logical as the name field shouldn't interpret the "é" value but just use it as standard text and i should be able to connect.
I hope this is clear enough, if not i'll make some screenshots and co to better explain it.

[Peter]

[Edit2]As you can see in this screen, i have 2 times the same ban name added.
In one of them, the client was connected, so i have the "last name" field with his nickname shown WITH the accent :
The second one, i just copied/pasted the name and added it to the ban list.
This time there ISN'T "last name" field shown :

This looks like it is working as expected, the last name is just available when you ban a uniqueID, then the client asks the server what the last name of the client with this UID is. One of your bans had a UID, so it was showing last name...the other did not. Working as expected.

[Edit3]It is shown as "poké moi" in the ban list.

So, if i connect with the client, that use "poké moi" as name, it will be correctly ban.
BUT, if when i'm connecting, i use as nickname "poké moi" i will aslo be banned !

This is also expected behavior, it doesn't seem to be such a big problem because people don't use &#NUMBER; in their names much . It is what I listed in my first post to this thread as "Problems to this solution" in (2). The server does not know the difference beween " é" and "&#NUMBER;" as nick name.

[dante696]

[Edit]But, if the user poké moi for example write me a private message saying "poké moi" and i copy/past from there (the normal chat message text) the space is normally interpreted.

We can reproduce it and we also see this as a problem.
Client 3.0.6 will replace tall spaces with a normal space instead.

Internal Ticket ID: TS-908

[TotoIsBack]

This looks like it is working as expected, the last name is just available when you ban a uniqueID, then the client asks the server what the last name of the client with this UID is. One of your bans had a UID, so it was showing last name...the other did not. Working as expected.

Ok, i understand this, but this is kinda "not cool".
I mean, if un ban a user with name tététiolo for exemple, and after some time i want to search it in the banlist to remove it, do you really think that 99% of the ppl will search with tététiolo in the search field ? Once again, don't forget there are much languages used with special chars (like german ^^)
So, why not use simply UTF8 instead of ASCII ? Would it be so hard to modify the regex mechanism to be able to use UTF8 ? (as QT provide function to convert easily in UTF8 as far as i know).

This is also expected behavior, it doesn't seem to be such a big problem because people don't use &#NUMBER; in their names much . It is what I listed in my first post to this thread as "Problems to this solution" in (2). The server does not know the difference beween " é" and "&#NUMBER;" as nick name.

Yeah i agree with you, not much are using it, but it shows the limit of the ban system actually used

[Peter]

Ok, closing this thread for now, the bug dante mentioned is in our tracker, and we are still discussing any "visualisation" of non ascii characters to help understand bans. Thank you for your help.