RtoL interface problem in Win32 (translation; UI turnaround)

[Karl Kleinpaste <karl+gtk kleinpaste org>]

I'm project admin for Xiphos, an application using webkit-driven panes
inside a GTK UI.  We have a problem where, in our single codebase, Linux
builds run perfectly but Win32 builds have serious problems with RtoL
languages.  I'm looking for input on this list because, as far as we can
see, the problem is buggy behavior specific to Win32, and I'm wondering
what prospects exist for help in this Win32 world, which I understand is
not your emphasis.

Basically, Xiphos has localizations for a couple dozen languages, among
them Hebrew, Farsi, and Arabic, all RtoL.  When we invoke Xiphos with
the right environment, on Linux it works exactly as intended; however
our Win32 world is not so fortunate.

Right: http://karl.kleinpaste.org/xiphos/xiphos-linux-farsi-right.png
Wrong: http://karl.kleinpaste.org/xiphos/xiphos-win32-farsi-wrong.png

We invoke with LC_ALL=fa_IR (Farsi/Iraq) and the Linux build is happy as
can be.  The problem with the Win32 build's display is two-fold:

- half the translation occurs
- the UI is not RtoL-inverted.

"Half the translation" means that dynamic content driven by the app,
e.g. the sidebar category list and the button selectors above the
sidebar, is properly translated.  Static content, including the main
menu as well as all dialogs e.g. preferences, is not translated.  And as
you can see, the interface did not turn itself around for fa_IR.

(The font failures [hex boxes] appear to be nothing more than a font
coverage problem, not yet something we're concerned about with regard to
GTK.)

I know nothing of consequence of GTK/GLib internals, so I'm at a loss to
grasp where I might go looking for how Win32 specificity would result in
two classes of really big failures.

Might anyone offer a clue as to why Win32 is alone in this nightmare?