Thanks for the list, Bill. We're going to have to prioritize, clearly
:-).
"Bill Tutt" <rassilon@lyra.org> writes:
> Indeed. Just to show how complicated il8n can becomes. Win32
> applications have to pay attention to lots of il8n details. Without
> further ado, here's that list:
>
> * System Locale:
> Determines which bitmap fonts, and OEM, ANSI, and MAC code pages are
> defaults for the system. This only affects applications that are not
> fully Unicode.
> API Name: GetSystemDefaultLangID
> * User Locale:
> Determines which settings are used for formatting dates, times,
> currency, and numbers as a default for each user. Also determines the
> sort order for sorting text.
> API Name: GetUserDefaultLangID
> * Thread Locale:
> Determines which settings are used for formatting dates, times,
> currency, and large numbers for a thread. Also determines the sort order
> for sorting text. Defaults to User Locale.
> API Name: GetThreadLocale
> This isn't as applicable for UI applications, but it's kind of required
> for service run apps.
> * Input Locale:
> A pair consisting of language and a method of input.
> API Name: GetKeyboardLayout
> * System UI Language:
> Determines the default language of menus and dialogs, messages, INF
> files, and help files.
> API Name: GetSystemDefaultUILanguage
> * User UI Language:
> Determines the language of menus and dialogs, messages, and help files.
> API Name: GetUseDefaultUILanguage
>
> Of course just to be annoying, you can't infer anything from all of the
> above returned locales for formatting date/time/currency for UI
> applications, since the Control Panel can override the default value of
> all of the above.
>
> Indeed, life is still annoying in UI il8n land for just of the few
> following reasons, and believe me this is only a small subset of the
> issues that can come up:
> * Bi-directional text (lots of fun stuff here, UI issues with mirroring
> coordinate spaces, and other odd things)
> * Fonts:
> Do not hard code font face names
> Do not assume a given font is installed
> Do not assume selected font supports the desired script
> * Local Calendar Systems: Hebrew, Buddhist, Hijri, etc..
> * Win32 Console Applications:
> The 8-bit console I/O functions use the OEM code page whereas all other
> 8-bit functions use the ANSI code page by default. To avoid conflict in
> code page conversions and to allow multilingual computing, your console
> output should be encoded as Unicode whenever possible.
>
> Tips and considerations:
> * use WriteConsole to output Unicode strings. Note that this API works
> only on console handles and can not be used for a redirection to a disk
> file.
> * If the output is being redirected to a disk file, use WriteFile with
> the current console code page that can be retrieved by
> GetConsoleOutputCP (the console code page might be different from the
> currently selected OEM code page!).
> * Complex scripts (Arabic, Hebrew, Thai, ...) are not supported in
> console.
> * Always create your log files with UTF-8 encoding.
> * When doing text alignment (e.g. %1!-14s! %2!-14s! %3!-16s!), either
> allocate the width of columns dynamically or truncate text wider than
> the columns' width.
> * To make sure that your multilingual resources are displayed properly
> in the console window, always set your console thread locale according
> to console output code page by using SetThreadUILanguage.
>
> * String Comparisons:
> If your string comparisons are not locale proof: e.g.: Using a locale
> dependent case insensitive string compare on "GIF". (Doesn't work for
> Turkish)
>
> Etc.... You get the idea.
>
> Bill
> ----
> Do you want a dangerous fugitive staying in your flat?
> No.
> Well, don't upset him and he'll be a nice fugitive staying in your flat.
>
>
> > -----Original Message-----
> > From: Karl Fogel [mailto:kfogel@newton.ch.collab.net]
> >
> > Changing the locale is not even what we want to do here.
> >
> > Just because my log message text is in Big5, doesn't mean I don't
> > still want Subversion's error and other messages printed in the
> > dominant system locale (non-Big5).
> >
> > What I was thinking of was not a --locale option, but simply an option
> > (long opt only, no short equiv) that says "my log message is in
> > encoding FOO", like this:
> >
> > --log-message-encoding=FOO
> >
> > The main purpose of this is for other programs to pass the option,
> > though a human is perfectly free to do so.
> >
> > I don't have a problem "cluttering" the long-option space. It's the
> > short opt space where we need to be ultra conservative.
> >
> > -K
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> > For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jun 5 17:23:43 2002