At 01:09 PM 6/25/01 +0500, Vlad Harchev wrote:
>On Mon, 25 Jun 2001, Andrew Dunbar wrote:
>> So is there a good reason we separate localized menus from the rest
>> of the localized strings?
>
> Dunno - probably there was one. Now it's decided that supplying menu
>translations in .strings file is a Good Thing (tm), but nobody volunteered
>to implement this (it's hard due to portability of AW).
Andrew,
When Jeff designed the menu and toolbar layout mechanisms, he was under the
impression that we'd need to localize more than just the strings. In
particular,
1) the artwork for certain toolbar buttons *does* change, and
2) it's conceivable that for certain locales we might want to
omit or disable certain functions entirely because they're
totally irrelevant.
Thus, he designed a mechanism which would allow pretty much everything about
the menus and toolbars to be customized on a locale-specific basis.
Currently all of that flexibility is enabled for each locale by having the
translator directly edit the contents of a single big macro-driven
locale-specific table. However, that table is in a header file, so it
requires a recompile to test. (This is a bigger issue for translators on
Windows, since the necessary compilers are even more expensive than the OS.)
I suppose you could move the strings out of those tables and load them back
at runtime. (This is probably much easier than Vlad suggests.) Doing so
would certainly help with charset issues, since the strings mechanism is
already plugged into iconv. (hand wave, hand wave)
What would happen with the layouts, though? The existing mechanism just has
a single bulky table (containing layout + strings) for each locale in the
data segment of the app, and I assume we still want that level of
flexibility.
I don't think anyone's given much thought to how to move that *layout*
flexibility out of the app in ways which don't confuse translators. I'm
sure it can be done, though.
Want to give it a whirl?
Paul
