Re: Substituting the main menu bar(s)

Swapping languages on the fly usually implies either switching the locale so that the
alternate language is selected from your master resource set, or putting all the resources
in separate DLLs. I haven't done the former, only the latter. To do this, I actually
used the 3-letter NLS code (e.g., ENU for English) and had DLLs with names like
MYAPP-ENU.DLL. The only problem I recall was forcing the menu to reload, and this project
is far enough in the past I've forgotten the trick, but I spent a lot of time reading MFC
code to figure it out. Then I turned the whole thing over to the client, who undertook to
create the other DLLs (I tested with a French DLL because one of the client's programmers
was from Quebec and therefore was able to give me a translated DLL to work with. Of
course, as I added features, I butchered his work with menus like "Le Debug" or "Le
Search", but I presume they fixed that...)

I realize today that localization is a whole lot more complicated, but as a
not-quite-first-attempt it wasn't bad. Today, I'd probably avoid the STRINGTABLE
resources in favor of MESSAGETABLE resources.

One of the more serious problems I see is in switching CFormView views or modeless dialogs
from one language to another; we didn't have to do that. I might be inclined to create a
second view after a language switch, position it exactly as the original view, and then
destroy the original view, but I've not tried this. Perhaps someone who has more
experience can suggest a better approach, but this is the only one I can think of (to
switch CFormViews, you have to have an OnUpdate handler with an lhint value that says
"save all your data to the document" and another that says "load all your values from the
document"--and this is easy, I've done this many times)
joe

On Tue, 6 Jun 2006 12:32:17 +0200, "KMA" <kma@xxxxxxxxxxxxxxx> wrote:

We looked at and used such a product for a while, but we found the following
drawbacks.

Our software consists of a suite of about 50 exes, many of which are similar
and share the same dialogs. We would either have to restructure the suite or
make a new translation project for each exe and administer that.

Translation products that work on the exe (by stripping out the resources,
changing them then relinking) produce exes which are good for one language
only. We wanted to swap language at runtime depending on the preferences of
the user. Our product runs on a shared PC environment where users of the
same nationality often have different language preferences. We could
circumvent the multi exe problem by placing resources into dlls, but this
creates a distribution headache if we need to send out patches or cutting
edge functionality enhancements - we don't want the exe to try to use
resources that aren't in the local resource dll. Of course, better
programming and release discipline would eliminate much of this bother, but
if we have to work in an environment where we don't have such discipline
then there seems no point in shackling yourself to a system which is bound
to fail. Far better to design some localisation policy that, whilst not
producing 100% thorough results, is nonethless workable and produces a
result which is satisfactory and cost efficient.

"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message
news:jsu382lpk7pa61veu8go97jr4m0spq8ffo@xxxxxxxxxx
There are relatively inexpensive products for sale in Europe that do this;
they take a
database of "base language"=>"other language" mappings and simply work
directly on the
.exe file. They have additional features that allow you to fiddle with
control widths so
you can accomodate longer label sizes or edit controls (apparently Danish
is one of the
worst languages to translate English dialog boxes into, because the words
are all much
longer). We have one distributor who uses such a program to translate our
product into
French, German, Italian, Spanish and Dutch (at least that many languages).
If I add
something, such as a new control, he has to make a new entry in his
"translation database"
(I occasionally get email forwarded where I have to explain what a certain
phrase means,
because he's a distributor, not a technical guy, and while his command of
technical
English is excellent, it isn't as deep in some problem domains as a native
speaker's is).
So I know it was being used as of two years ago. And I recall it was
relatively
inexpensive, less than $100 U.S. if I recall our conversation of about
eight years ago.
joe

On Fri, 2 Jun 2006 00:16:53 +0100, "David Webber"
<dave@xxxxxxxxxxxxxxxxxxx> wrote:


"KMA" <kma@xxxxxxxxxxxxxxx> wrote in message
news:e5mvgi$k2u$1@xxxxxxxxxxxxxxxxxxxx

Alternatively, you could leave your English(?) menu where it is but just
change the strings for each item at runtime based upon the current
language regime. Not as tricky as you might think, and has the advantage
that you don't have to edit n menus each time you add a feature. Then
take
the feature out. Then decide to add it again. Then move it to a
different
place in the order.

Glad to see you're sticking with the localisation. Be interesting to
hear
if you found and good tips or pitfalls.

After our discussion a while back (which I found enormously helpful -
thanks) I proceeded in a slightly different way from your method (but
nevertheless inspired by it).

1. I have tab-separated-value table of strings maintained with Excel, with
a
column for each language. These include string-table items, strings from
dialogue templates, strings from menus,...

2. I wrote a translation application* which takes as input:

the table of translations
the english rc file

and outputs

an rc file in each language.

All it does is replace the strings according to the translation table.

3. I have a resource-only DLL project for each foreign language, which
uses
the generated rc files.

4. I also have a batch file which calls the translation app, and then
invokes the compiler on each resource-only DLL project. I can thus add a
new translated string and run the batch file very quickly.

There are two disadvantages to this:

a) My application knows to look in the selected language DLL for the
resources. Selecting a new language works immediately for everything
except
the menus as these are loaded at the start and remembered by the
application
framework. To get the new language on the menu, I currently have to exit
the app, and go in again, so that the new language menus are picked up by
th
InitInstance stuff. That's why I wanted to replace the menus which the
AFX
stuff knows about.

I want to click on the "present program in French" button, and tell the
AFX
to replace the two menus it knows about with two from the French language
resource-only DLL. This seems to involve puting ones hands deep into the
engine of MFC :-(

b) Dialogue strings can easily get too big for the available space. This
just requires care. One thing I am moving towards is purely iconic
dialogue buttons with tool tips explaining what they do this gets round
the
space problems very elegantly, but isn't possible everywhere.

But the advantage over your method is that I don't have to program every
menu and dialogue class to load strings for all its controls. (I have
nothing against that in principle but the program was first released in
1994
and by now there are a LOT of them!)

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

Loading