Showing Foreign Letters in Apex DC++

[cobra98 0]

Hello

how can i make the foreign letters

like

russian and chinese visible?

They are shown as:

[MiRaGe 0]

maybe installing the cyril characters in windows solves this, but correct me if i'm not right. but that should do it.

[Zlobomir 3]

Yes, Control Panel >> Regional and Language Options >> Advanced >> 21025. I have some additional checked too...

[cobra98 0]

Hm, I activated all codepages, rebootet the Pc, still:

[21:07:47] <-CORE-> Current date is: 2007-05-06

[21:07:47] <-CORE-> Current time is: 22:28:58

[21:07:47] <-CORE-> Your IP is: 80.109.194.47

[21:07:47] <-CORE-> Our forum is www.hub-volia.com

[21:07:47] <-CORE-> Support: admin@hub-volia.com

[21:07:47] <-CORE->

[21:07:47] <-CORE->

[dagoburd 0]

I think you must try ot set up all the menus in regional and languages settings to match russian (in regional options and advanced tab).Then Apply and restart your machine and i think that everything must be fine :)

[Zlobomir 3]

Also, you might want to check the box "Apply to the default user profile as well". Another aspect, if you have ever installed a so-called "cyrillization" program, even if removed it later, your code pages are badly f* up (happens in Bulgaria with Flextype and similar). Or maybe this evil happened to the host PC, on which the hub is running... Just guessing. But the fact I am reading normally the cited hub is a good clue that the problem should be in your box. You are probably using KOIR-8, mine is on 1251, but shouldn't have influence on DC.

[07.05.2007 01:39:39] <[BG]ZloboMi®> Ð

[cobra98 0]

I changed at advanced "Deutsch

[Zlobomir 3]

Please try these as well...

[Pedja 0]

This is not a good solution, just a quich workaround. Applicatin should support unicode. This way, user can alternatively use just one codepage other than english.

[balder 1]

the protocol dosn't support unicode so it is not possible to modify the client for this functionality.

[Pedja 0]

That is strange. I do not see how protocol can limit unicode? It's just sending bytes over the connection. It is all about clients if they can interpret those bytes properly.

For instance, you can introduce new option to ApexDC++ for users to set prefered codepage (including unicode), so if two users set the same codepage they can send messages with no problem. Internaly client could always use unicode for maximum compatibility.

Also, each message snet could start with small header that shows which codepage is used for sending message, so receiving client could adjust accordingly.

However, all users should be be advised to use unicode only, sicne that means they all can exchange messages no matter of language.

The last thing that should be, is that user must set his Windows to speciifc codepage to be able to exchange messages writeen using that codepage, as it was advised in this topic.

[Zlobomir 3]

Yes Pedja, it is just that when you make smth more convenient, it usually becomes more complex, then usually becomes worse. That's why i use BG with Latin letters in chats, where this "uglification" is not permanently written. On the other hand, afaik specifically for BG lang all problems started even with the first "assistance" we Bulgarians provided IBM. F. ex. "ОТТУК НАСАМ" cannot be determined easily by PCs... more for it on http://injinera.bgplus.com/na4alo.htm It is on Bulgarian.

[balder 1]

That is strange. I do not see how protocol can limit unicode?

the protocol dictates how data is transported from client to client and from hub to hub. the protocol dose not support utf-8 and therfore hubs and clients do not expect to recive data in this format. if apex started to send it in this format then it could break client to hub communication and clicnt to client communication unless both clients where the newest version of apex.

It's just sending bytes over the connection. It is all about clients if they can interpret those bytes properly.

exctly most clients and hubs (to my knowlage no client or hub supports utf via nmdc) dont expect data in utf format.

For instance, you can introduce new option to ApexDC++ for users to set prefered codepage (including unicode), so if two users set the same codepage they can send messages with no problem. Internaly client could always use unicode for maximum compatibility.

yes this would be usefull but it means changing the underlying protocol so all clients could do this, ome type of backwards ompatability would also need to be built in. note adc asumes all clients are using utf-8 i also doubt that it will be introduced to nmdc.

[Zlobomir 3]

I hope this will be no issue in ADC.

[balder 1]

no adc is utf-8 as stanndard so there should be no probllem

[Noctis 0]

Have you set the appropriate charsystem in your client? (Textstyle)

[Pedja 0]

ApexDC++ is not utf-8 aware application. If it is there would not be need to set default langguage and codepage in Windows. Also, when I use cyrillic characters in ApexDC++ they are shown ok whle I write, but when I send it, it shows as questionmarks even localy, within application.

AL I am saying is that APex should be utf8 aware, and it shuld send bytes exactly as they are. If other site is utf8 aware, it would display them correctly. Otherwice it would display questionmarks or garbage, is it does now. So we can just get something better, it cannot be worse.

There is no need for backward compatibility with anythin, just vbecaouse tehre is nothing to be compatible wiht. NOw, no client supports any codepage, so any nonlatin character is shown as garbage. Introducing support for utf-8 would not change it, but would allow that utf8 aware applications can read and present any text as needed. If ApexDC+ is theonly one utf8 aware, than it is just another reason for people to chose it.

There is no need for any fancy protocol for utf8 support. Just look how Windows deals with utf8 text files. There are two bytes at the begining of the file that show it is utf-8.

how it works now: if two people want to talk in russina they both have to set windows to russian, and it works. This means that DC protocol does not limit communication on foreign character sets. But, if one want to use other language at the same time to talk with someone else, he has a problem, beause he cannot use two codepages at the same time.

Intruduction of utf-8, solves that problem. Insted of characters being sent in user selected codepage, they should ba always converted to utf-8 and sent that way. Receiving clined should accept utf8, and convert it to apropriate codepage to present it. If applciation is utf8 aware, it would not need to convert at all, but simply display what it receives. This allows us to use as many different languages at the same time. And limitatin is not a protocol, which obviously can transfer any codepage, but non utf-8 aware clients.

[Greg 0]

ApexDC++ is not utf-8 aware application. If it is there would not be need to set default langguage and codepage in Windows. Also, when I use cyrillic characters in ApexDC++ they are shown ok whle I write, but when I send it, it shows as questionmarks even localy, within application.

AL I am saying is that APex should be utf8 aware, and it shuld send bytes exactly as they are. If other site is utf8 aware, it would display them correctly. Otherwice it would display questionmarks or garbage, is it does now. So we can just get something better, it cannot be worse.

There is no need for backward compatibility with anythin, just vbecaouse tehre is nothing to be compatible wiht. NOw, no client supports any codepage, so any nonlatin character is shown as garbage. Introducing support for utf-8 would not change it, but would allow that utf8 aware applications can read and present any text as needed. If ApexDC+ is theonly one utf8 aware, than it is just another reason for people to chose it.

There is no need for any fancy protocol for utf8 support. Just look how Windows deals with utf8 text files. There are two bytes at the begining of the file that show it is utf-8.

how it works now: if two people want to talk in russina they both have to set windows to russian, and it works. This means that DC protocol does not limit communication on foreign character sets. But, if one want to use other language at the same time to talk with someone else, he has a problem, beause he cannot use two codepages at the same time.

Intruduction of utf-8, solves that problem. Insted of characters being sent in user selected codepage, they should ba always converted to utf-8 and sent that way. Receiving clined should accept utf8, and convert it to apropriate codepage to present it. If applciation is utf8 aware, it would not need to convert at all, but simply display what it receives. This allows us to use as many different languages at the same time. And limitatin is not a protocol, which obviously can transfer any codepage, but non utf-8 aware clients.

What the client sends is defined by the NMDC protocol. A protocol is effectively a set of rules, you are asking us to break some of the fundamental rules on which the protocol is design. If we do this it will cause incompatibilities with all other clients. I highly doubt we will be implementing any such changes in the near future. I understand your frustration, but you are going to just have to wait until the ADC protocol comes into effect and is more widely used/accepted.

If you have any disagreements with what I'm saying, or would like any further explanation, by all means go ahead/ask.

[Foobar 0]

Pedja is correct. (He already explained it quite well.)

This whole "fixed character set" issue is maybe a fault in DC++ itself, and not directly ApexDC++ related.

Just like in IRC, a DC client should include an option to choose the character set to be used, because the used protocol (DC) does not define it in any way. For example Valknut has this option.

[Kulmegil 1]

But I'm thinking that some ...let's call it that... negligence was made in the past. Why don't we just define something new like $utf8 - something optionally sent by the hub at the very beginning when user is connecting (much like $HubTopic). It say that utf-8 encoding should be used on this hub. It's incompatible? SO WHAT!? Obviously all saying that ADC is next door and it will support utf-8 and it's gonna be cool are right... but if it would be implemented when first Unicode aware DC++ showed up, I'm pretty sure we would be living in Unicode version NMDC today. A shame imho.

There are obviously more fields where breaking some compatybility could lead to better DC world already today.

But the good thing is since that damn ADC is really close much of it will be solved at last.

[balder 1]

Foobar can you please show me how to use utf-8 in valknut. I find no options for this in the settings and i am unable to get hold of the source.

[Foobar 0]

Balder, click with 2nd mouse button on any chat window and choose Text Encoding for input and output. There are several character sets available. (I'm talking about the Linux version, I'm not sure if it's the same in Windows.)