Re: Internatinalization and multiple language support without resource DLLs
- From: Joseph M. Newcomer <newcomer@xxxxxxxxxxxx>
- Date: Wed, 04 Feb 2009 04:56:36 -0500
See below...
On Sat, 31 Jan 2009 10:17:02 +0100, Colin Peters <cpeters@xxxxxxxxxxxx> wrote:
Joseph M. Newcomer wrote:****
Why in the world would anyone write GetDlgItem?
I thought you might rail against that. That's why I wrote:
"The DDX_Control function does something similar in the background.Point
being, that you've got runtime dependencies between discretely
distributable files."
How? I never had an issue with runtime dependencies with controls. Of course, it *is*
possible to create them, but it is easy to avoid creating these dependencies.
****
****
Which you probably didn't read.
All of the debate seems to be over the "I don't want no stinkin' DLLs
in my product" which
I find to be profoundly unhealthy.
I don't know how you reach this conclusion. The argument is really "Do I
have to include dialog resources in a satellite dll?". The answer is
"No, you don't". And depending on your distribution regime it might make
sense not to do this.
There are two positions; "I don't want DLLs in my project, at all, ever" and "I have a
project where I want to do the localization on a per-executable image basis". The
confusion arises when the reason to not use external DLLs is simply because of a distaste
in using DLLs
****
****
perpetuating the myth that copy
a.exe == install a.
And yet this ASP.NET takes exactly this approach. You don't even have to
stop the application.
And what does ASP.NET have to do with native-code MFC applications?
There are some arguments that XCOPY == install can be justified, but the argument that
everything has to be in a single .exe file goes back to the days of putting a single stack
of cards in the card reader. I abandoned that sometime around 1966. I have no idea why
I'd want to go back to it.
joe
****
Joseph M. Newcomer [MVP]
By the way, the problems of version skew within even a single .exe (when multiple
languages were supported...as I indicated, I did this 12 years ago, which predates the W2K
damage that made it stop working) was that we had to keep all the resources up-to-date, in
every language. It worked OK when we were doing German and English, but then when we
added French it got bad, and when we needed to add Italian and Spanish it got out of
control. That's when our European distributor got the program he now uses, so I just
deliver an English-language app and he runs the program and gets other languages out of
it. The program can also do layout changes (extend labels, even extend edit controls,
dropdowns, etc.) but only in one dimension (length), which is why when I do dynamic
controls I never use DBUs (they have no meaning by the time I see the windows), and when I
do dynamic layout I always work relative to the sizes that I find, not what I coded.
All of the debate seems to be over the "I don't want no stinkin' DLLs in my product" which
I find to be profoundly unhealthy. It encourages the kinds of naive failures described,
such as copying the executable but not the DLL, and thus perpetuating the myth that copy
a.exe == install a. We learned early on that our users expected to be able to copy just a
single .exe file, and basically said, "tough, it doesn't work that way, we don't support
it, that's why you have an install program on the distribution disk, use it, don't bother
us if you can't understand that copy != install". After three months of "getting used to
the idea", the customers stopped bugging us. Interestingly enough, sales increased and
our distributor says it was because there was less piracy. I have nothing other than his
opinion to base this on.
The program is still selling well, I'm told, in spite of the fact that we haven't touched
the code in at least six years.
joe
On Thu, 22 Jan 2009 19:13:39 +0100, Colin Peters <cpeters@xxxxxxxxxxxx> wrote:
The problem with resource dlls with dialogs in them is that if youJoseph M. Newcomer [MVP]
update your exe with a new edit field then you have to also have a new
resource dll for the target language at runtime.
Otherwise code like this will fail:
CEdit* pEdit = (CEdit*)GetDlgItem(IDC_NEW_CONTROL);
pEdit->Blabla();
Hands up those people who religeously check the returned pointer for
NULL, always, everywhere. Oh, not many hands there.
The DDX_Control function does something similar in the background. Point
being, that you've got runtime dependencies between discretely
distributable files.
Tom Serface wrote:
There are also some things that are not in the DLLs like localizing
dates, times, number formats, etc. I think Giovanni said OP's required
the ability to add new translations without using Visual Studio and that
makes this pretty tough.
Tom
"Mihai N." <nmihai_year_2000@xxxxxxxxx> wrote in message
news:Xns9B9AC354F4D29MihaiN@xxxxxxxxxxxxxxxx
But localization is about more than strings:
- since strings change size with translation (grow or shrink),
the dialog layout has to change
Designing controls big enough to fit "any language" is not a solution.
They will look ugly for short languages, and it is tough to do "right"
if you want to support something like 35 languages.
Shortening the strings to fit is time consuming and leads to bad
translation quality.
- fonts (and font sizes) must change
- accelerators must change
- bitmaps (in toolbars) and icons might have to change
- alignment and controls flags must change (for languages like Arabic
or Hebrew, for instance)
Every single element that you find in resources is potentially
localizable.
This is why they are in resources, and someone spent the time to have a
resource editor for it.
Yes, there are some solutions for some of these (like using an autolayout
system to solve the resizing needs), but they are not simple, nor
standard.
Sounds like your client want the flexibility to add more languages as
needed.
This also means that there are chances to stumble on a language that
cannot be translated just by changing strings.
He is giving up flexibility for some ease of use.
With some tools the ease of use can be there even for resource dlls.
But if you design a solution with external files that does not allow
changing all the rest, he might run into problems that cannot be
solved without code changes.
If your client (on the other side) wants in fact the contrary,
meaning preventing people from adding a dll toget a localized
application (like others understood), you can still use dlls,
but restrict the ones that are ok to load.
Anyway, DLLs are the standard thing.
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.
- Follow-Ups:
- Re: Internatinalization and multiple language support without resource DLLs
- From: Colin Peters
- Re: Internatinalization and multiple language support without resource DLLs
- From: David Ching
- Re: Internatinalization and multiple language support without resource DLLs
- Prev by Date: Re: Internatinalization and multiple language support without resource DLLs
- Next by Date: Re: How can I trap drag and drop in a CHtmlView?
- Previous by thread: Re: Internatinalization and multiple language support without resource DLLs
- Next by thread: Re: Internatinalization and multiple language support without resource DLLs
- Index(es):
Relevant Pages
|
