I know that 5.1 BETA 4 is just the beginning of a new multilingual SQLyog-era. The release notes claims 'support for all European character sets'. I miss latin2 and latin7. They are Central/Eastern Europe and the whole Spanish-speaking world respectively and both are pretty important!

You must also explain how to use the charset selector in connections manager!

I think that I can figure out that if I want to work with some DB's/tables that have the default character set of the server I can choose 'default'. If the DB's/tables have another character set I can now choose that. Is that correct? If it is, then I request a dropdown in program main-windows where one can switsh 'charset_results' too - so that I won't need to reconnect!

I have to say that I'm disappointed to see utf8 missing since that's quickly becoming the universal default.

@jrossiter

Please search the Forums and the FAQ!
A little search would tell you that full unicode compliance is planned for SQLyog 5.2.

Cool down!

Complete support for utf8 and other multi-byte charsets will be available in v5.2. Right now only one-byte charsets will be supported.

I'd have to be hot to cool down. I can make a statement without being upset.

@ritesh

did you consider this discussion in relation to BETA 5 ?

Yes indeed. Previously, we were leaving out couple of charsets but from BETA 5, everything will be in the drop down. Display of the data though will depends whether it is single byte or multibyte. We plan to support display of data which is stored in utf8 but are of one byte in BETA 6. Right now, you cannot display data with utf8 charset even though it contains one byte data.



I will update the docs as soon as I can.

I don't understand this

Yes, I can! See attached! There is one ucs2-column and an utf8-column. With ucs2 all characters are two-byte, with utf8 æ,ø and å are double byte.

Also with utf8 a default for the server I can create databases and tables insert and read multibyte data. However I must select 'latin1' at the connections manager.

One-byte utf8 character are the ASCII-subrange only! Positions 128-255 are not mapped in first byte of the utf8 encoding. All other characters take two bytes (all alphabetic writings) three bytes (fear eastern writing) or four bytes (only some rare historical writing styles).

It's rubbish what your are writing here!

That is exactly what I am trying to say here. Even if one byte data is mapped to utf8, it will not be displayed correctly as the codepoint between latin charsets and utf8 is different. We are not supporting that as of now. You will need to select latin1 in the connection manager.

And ... If I understand correctly .. ,-)

that would also be possible to have special characters displayed when choosing utf8 from connections manager with some future 5.1 release.

You wrote: "We plan to support display of data which is stored in utf8 but are of one byte in BETA 6" Only ASCII characters are one byte only in utf8! :-)

Ok .. let us see what it comes out like!

I plan to implement this in either RC1 or RC2.

No issue ...

Nick's Turkish example was a good exercise. There are a handful of things that must be fixed 'on the road to 5.2'. Exactly in what order is much a matter of planning resources.

Thanks to Nick we can now describe how to handle 'non-latin1' data whether single-byte on multi-byte as long as only 'one set of nationals' are involved. I'll do that in the FAQ when I see the exact implementation of the soon-coming RC(s)