Re: Internatinalization and multiple language support without resource DLLs

See below...
On Wed, 04 Feb 2009 21:53:51 +0100, Colin Peters <cpeters@xxxxxxxxxxxx> wrote:

See below...

Joseph M. Newcomer wrote:

See below...
On Wed, 04 Feb 2009 18:19:21 +0100, Colin Peters <cpeters@xxxxxxxxxxxx> wrote:


Joseph M. Newcomer wrote:

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.
****

The dependency would be between a (for example) recently added CEdit
class in the exe that will try to attach to a EDIT control in a dlg
resource in a localised dll.

****
But how could that arise? It could only arise if there was a version skew between the
DLLs and the .exe, and that wouldn't happen except by accident, and, of course, this would
all be tested before release. It isn't rocket science to get this right. Version skew
merely demonstrates sloppy testing or deployment. Sure, I've had this happen during
development, but we apply thorough testing before release (in the one project we used
multiple resources, it was tested under every language. Today, I'd consider using either
a tool like appTranslator or writing a program that compared resource structures). If the
separate distribution of a DLL had some incompatible change, then this points out a
failure to handle version management. These are easily-solved administrative problems,
and given they have easy solutions, they should not preclude using a technology.
*****


You can call it sloppiness, unprofesionality, herecy and blasphemy, but
you've just highlighted how it can happen. And there's not much you can
do to prevent it. Now, tell me how you could get version skew when the
resources are in the same executable as the code?
****
Isn't it screamingly obvious? I have an English set of resources, a German set of
resources, a French set of resources, etc., and I failed to update all the languages
consistently. This can happen whether they are in a single resource segment or scattered
in several resource-only DLLs. It's an editing problem. Editing problems don't go away
because of how you partition your program.
****
(Note that I write
executable rather than exe; it'd be perfectly valid to have both
contained in a dll, like an ocx. The problem I'm trying to get across is
that when you split the code and dependent resources across separate
files then the potential for mismatch can't be removed. When they're
contained in the same file then it takes some serious effort to dislodge
them. In which case someone is trying to break your program rather than
breaking it by accident).
****
No, it takes a failure to remember to update one or more of the languages. I got to the
point that in later projects, I loaded the captions for the controls (static, button,
etc.) from the STRINGTABLE so I had only one dialog resource, and one repository of
language information that was much more easily compared (that came about when I did a
project that had 35 dialogs, and I knew it would be unmaintainable if we had to support 35
dialogs in six languages. But supporting six STRINGTABLEs was much easier)
****


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
****

But nobody said don't use dlls ever. Just that you don't have to use
them always. The title of the original post pretty much sums up the
issue. We're taking about resource dlls, not code dlls.

****
Back in Win16, I used resource-only DLLs to distribute a compressed database. In addition
to holding the database, it provided for localization. All that was required was some
simple management to make sure we didn't have a version skew.

For resource DLLs, I just wrote a trivial program that read the version from the
VERSIONINFO data. We had the file version and the program version. All resource files
had ot have the same file version (which indicated the weekly database update) and the
program version had to be consistent with the .exe file's program version.

(The reason for using resources for a "database" was that it was a simple two-table
database that took more space than the laptops of that era had, but my compressed version
was about 10 times smaller)

The argument seems to be "because it is possible to screw something up by poor testing or
deployment practices, the technology that enables this must not be used".
joe
****

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?

They're both frameworks. One's on the ascendency and the other isn't. I
don't claim that the install policy is the only reason, but the folks at
ASP-HQ clearly thought that copy=install would be a feature that might
be popular.


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
****



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 you
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.


Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.

Quantcast