Re: Internatinalization and multiple language support without resource DLLs
"Serge Wautier" <serge@wautier.nospam.net> wrote in message
news:%23rcH699fJHA.1252@TK2MSFTNGP03.phx.gbl...
Or they could use the freely redistributable appTranslator Translator
Edition to see exactly what they need to translate, then build the
resource DLL without any need of an external resource compiler and/or
linker.
Sorry for throwing my app again. Simply couldn't resist ;-D
Actually Serge, a couple years ago I was looking for a localization tool for
MFC apps, and examined yours and a few others. Your app seems really good.
:-) But ultimately my client decided to outsource the effort... sorry! :-(
Also, a few years ago I was thinking of creating localization products,
similar to yours but more skin based and allowing more flexible UI's than
the .RC format can accomodate. I still think there is a market for those,
as the world has grown beyond what can easily be specified in a .RC file.
That's my point of this thread - though Mihai is correct that the .RC file
gets the localization points done right, the need for external tools (even
your app) to use it is limiting. As well, the UI that can be specified in a
..RC file is also so limited, people have long ago abandoned it and have
turned to custom UI specification. We should not be criticized for moving
beyond the .RC file when our clients demand a more attractive interface
(even when those same clients seem not to care as much about localization,
font size readability, color blind people, etc.)
This is not a problem with modern frameworks which expect a format string
containing %1 or {1} or some other placeholder that does not specify the
type.
Though I can perfectly accept that people don't want to live with resource
DLLs although it's not good for my business ;-), I have to agree with
Mihai about this. Type consistency is not the only potential problem: What
happens if an argument is removed from the format string but the satellite
dll doesn't know it? System.FormatException at best!
Since the parameters are passed cdecl, isn't the (now unused) parameter just
ignored? Perhaps you are referring to .NET... perhaps it does throw a
FormatException.
Thanks,
David