Sorting it all Out

Hi again... I hope there are more people going to suggest a topic or place a question, otherwise I would feel a bit... alone. Maybe you should keep some fake entries in the suggestion list so that some bashful people (like me) don't feel annoying when...you know, suggesting a topic. :-)

Though obviously I did that step, but this is only because I already know you are very kind and cheerful person... and thank you for all your help and extraordinary useful posts and advices!

Well, I've just started learning Tamil at our university. Now I would like to create a document with the individual graphemes (or signs in the unicode naming terminology), like ௌ (0x0bcc) for example. I have no problems with this in notepad, wordpad, or WPF. However, it seems that this is not allowed in any of the Office 2007 applications and neither it is in the Visual Studio 2008 text editor, which require me to type the consonant first (yet pasting the vowel sign from clipboard just works).

Besides the general background about this behavior and its intuitiveness, there are particularly two questions which I am interested in:

As an user - is there any way how to type in the individual vowel signs in the Office applications besides the clipboard/custom keyboard/insert symbol way?  (the Alt+X trick does not work on standard Tamil keyboard either, which, however, does not surprise me at all :))

And as a developer - any chance I could control (or find out) the current behavior? Like do not allow the signs in my WPF window (if I were that kind of person, of course)?

Thanks and wish you lots of good and interesting questions!

Greetings! What references (and advices) would you suggest to someone considering implementing a complex script rendering engine? (on a platform where there is no such available of course :-))

Jan

With Dr. International (http://blogs.msdn.com/drintl/) being inactive for years - who's gonna write "Developing International Software, Third Edition" now? I think there is still some stuff missing:

- localized size units (French "octets") to cover...

- the Japanese (and Korean) path separators...

- more information on registry keys and paths translated in localized OSes...

Cheers,

Michał

Hi. Here's a little program. I know it's not unicode, but the product I'm working on is 14yrs old, so it's just too late for that.

#include <iostream>

void info()
{
  char line[1024];
  printf("\n Input via gets() ");
  gets(line);
  printf(" Echo via printf() %s\n",line);
}

int main(int argc, char** argv)
{
  info();
  setlocale(LC_CTYPE,"");
  info();
  return 0;
}

So, on my dos console, built from visual studio 98, this works just fine, but built from visual studio 2008 the characters no longer round-trip.

For example, after the setlocale call, ALT+252 shows SUPERSCRIPT LATIN SMALL LETTER N as expected from cp437. And the byte from gets is xFC as expected. But when you give xFC to printf, it displays as LATIN SMALL LETTER U WITH DIAERESIS as would be expected from cp1252.

Now I realize that I can work around this by using  ReadConsole/WriteConsole instead, but isn't is a little insidious that on a completely default system, using basic calls like gets/printf/setlocale, simple IO doesn't round-trip?

Maybe I'm missing something, but it seems like someone has intentionally gone out of their way to make me suffer.

I'd love to know why.

Thanks.

P.S. why call setlocale? Because we always have, and they're scared of what will happen to the database drivers, etc. if we change it.

P.S. why care about non-ascii? Because many apps talk to our db and all latin1 is legal. We've already gone to a lot of trouble to avoid best-fitting when printing to the console, and the new behaviour destroys that.

Hello,

I am currently trying the Windows 7 Beta and decided to play around a little with the Regional and Language Options. So I set the negative sign symbol for numbers to U+2212 MINUS SIGN, instead of U+002D HYPHEN-MINUS. I just wanted to try how far I would get with that until I see misbehaving software.

So far, so good, I headed over to the Currency tab where you can select a negative currency format. However, neither the sign use for negative currencies is customizable, nor is the sign set in the numbers tab used. It always shows U+002D (except for the variants where the number is simply put into parentheses.

Is that kind of unlinking number and currency formats intentional? If so, why exactly? Is there a locale where the number negativity sign is different from that for currency?

Regards,

Johannes

Hi Michael,

I would like to ask/or suggest as a topic something about the Uyghur (PRC) locale in Windows 7.

This is a new locale that has been supported by Windows since Windows Vista as you might know.  The current default code page of this locale is set to Arabic (Windows-1256) but this code page cannot fully support the script of Uyghur since it lacks some essential Uyghur-specific characters (ې ,ۈ ,ۇ ,ۆ ,ە).  These characters are five out of eight vowel letters in Uyghur, not providing support for these five letters means it does not make any sense for Windows-1256 to be the default code page.  Does it have to be the default for the Uyghur (PRC) locale anyway?

And there's another issue with this locale.  This locale doesn't provide support for GBK (ANSI/OEM 936).  The major reason we need for the support for GBK is that most of the applications in PRC are/were written in GBK/GB2312-80.  If the system default locale is set to Uyghur (PRC) then the default code page will be Arabic (Windows-1256) and if we try to run GBK/GB2312-80 applications, there will be a messy characters on the UI of the applications since the locale doesn't provide any support for these code pages.

So I'm wondering:

1. why Arabic (Windows-1256) must be set to the default code page for the Uyghur (PRC) locale while this kind of applications are rarely used in the People's Republic of China;

2. if and how the Uyghur (PRC) locale can provide support for GBK/GB2312-80 applications in order to correctly run applications based on these code pages.

I've been playing around with Microsoft Locale Builder to see if the 2nd item is feasible but I didn't make it =P

Hello Michael, and thanks ever so much for sharing insights about the workings of the Windows layout routines!

I hope you're the person to ask about this, or if you aren't, that you could tell me who might be?

In these days I'm very portable, and happily so. I 'take my digital life with me' by USB flash drive, and this allows me to work comfortably on computers where I have no installation rights. That's nice!

When it comes to the keyboard layout however, I'm not yet fully satisfied. I've used MSKLC to make an enhanced layout (Unicode, some keys moved around etc) that I'm very fond of. I can use the freeware script PortableKeyboardLayout to take that with me, but this solution is imperfect because it's too slow at times (it's written in a scripting language) and doesn't always play 100% nice with the input stream. (It has other virtues, but that's another matter.)

So what I'd really like would be to be able to code or script an analogue to the LoadKeyboardLayout API, that instead of looking in the registry and system folders could take its values from a specified file and an MSKLC-made install! (I hope I'm right in thinking that what the MSKLC installer does is detect the architecture and then simply copy the right .dll and some registry values to where the system expects them to be?)

That way, I could run a script or program that loaded and activated a layout from my USB drive, without installing anything to the local hard drive! Any tips/ideas whether this is doable and if so, how?

Hi Michael,

I have created a keyboard for the Iñupiaq language using MKLC. In the properties I named it Iñupiaq, not Inupiaq. If I hover my mouse over the .dll the context menu says it is the "Iñupiaq US Keyboard Layout," etc. However, when I install it in the US version of Vista or XP the Language Bar displays its name as "Inupiaq," without the ñ. If I go into "Add or Remove Programs" in Control Panel it is correctly listed as "Iñupiaq". It appears the system will use the ñ in some places, but not in others. Is there a way to get the Language Bar to show the ñ?

Thanks,

Gene

I read what I could find about fonts installed in the system not being installed in IE, but I could not find anything about how to solve the problem.  I would assume registry hacks?

Hi, glad to see you back, Michael!

Actually I've already tried twice to post the following question some time ago, but it did not go through. However, I know how you like sorting topics, so I thought I might try it once more… here we go:

Say I have a web page, and I'm providing the content in several languages. Now the question is, what do you thing is the best way to present the languages available, in which language and the most interesting – in which order?

I've told to myself – okay, let's see how the MSDN does it. If I open the MSDN web, I see "Česká Republika - Česky" in the top right corner. Hmm well, if you happen to not know the Czech language, I guess you have no idea this is the language selector. Anyway, here is the list expanded:

Argentina (Español)

Australia (English)

Brasil (Português)

Canada (English)

Canada (Français)

中国 (简体中文)

Colombia (Español)

Deutschland (Deutsch)

España (Español)

France (Français)

India (English)

México (Español)

Perú (Español)

Россия (Pусский)

United Kingdom (English)

United States (English)

What is the reason for listing the country first and then the language? I also see both country and language are displayed in the native language, which prevents you discovering the selector if the page is displayed in a language you are not familiar with. Now after couple of your posts about sorting, I see this list is sorted neither by language, nor by country (the non-Latin characters would go down, right?). So my first guess is that the list is sorted by country language in English – an item not in the list – a bit confusing, especially if you don't know the English names – though quite interesting idea for me. And now, what sort is used? Assuming the 中国 thing is China, it seems to be sorted using English rules, because in Czech (in which the web is shown), this would go after Colombia. Wasn't it me to whom did you advised to use the sorting expected by the user? Funny is that if you click to display more languages, the combo box is sorted different way, I would say by native country names (non-Latin at the bottom), accent insensitive (Česká republika before Chile) using English rules (Chile before Colombia) – at least that page is in English only. Though for me, looking for Česká republika in the middle of 'C' names is really weird.

Looking at another sites, I see everyone implemented it differently. So...I wonder, do you have any thoughts what could be the most correct way?

Thanks!

Hi Michael,

any idea why the locale identifier is missing for Corsican at http://msdn.microsoft.com/en-us/library/ms776260(VS.85).aspx ? I already left a note at the bottom of the page, saying that it should be 0x0483 as according to http://msdn.microsoft.com/en-us/library/dd318693(VS.85).aspx .

Also, what additional locales does Windows 7 have over Vista?

Michael,

Here's the deal: I'm loving the new IMEs installed with the East Asian language packs for Office 2007 (running under XP Pro). They are a significant improvement over past offerings.

The Chinese (Traditional) New Phonetic IME in particular is wonderful for me because it includes the whole CJK range, including Extensions A and B (well, presumably those characters within that range for which the Unicode database has Mandarin readings, at least using phonetic input).

There is a significant issue in how the IME displays characters for selection. After including CJK Extensions A & B (in the properties dialog, under General -> Character set), the whole range is available to input -- I think. See, what happens, so far as I can tell, is this: the IME candidate window shows basic CJK characters in black, Extension A characters in green, and Extension B characters in red. But on my system at least, the green characters show up only as those nasty character-not-found boxes. The Extension B ones appear quite nicely (so there's a bunch of black characters and a bunch of red ones, with the green boxes in the middle).

I've checked and do have fonts that support both ranges, but a different set for each and none that covers both fully. I've also noticed that, while the older version of MingLiu supplied with XP does not have the Extension A characters, the newer version that comes with Vista does--could that be what the IME is looking for?

Any ideas about what might be going on?