Re: Internationalizing an app

It also creates a massive resource segment, which is hard to manage.

MFC does have some rather naive views of resources; it took until VS.NET to be able to
load string resources from a different DLL on a per-string basis.

I did think it was possible for a user to select which language to use for a session, but
I've never tried any of this. I get this from my Canadian students who have to support
bilingual apps as a matter of course, and on machines used by both Anglophones and
Francophones, interchangeably.

The sublanguage matters to us even with English text, because of the variants in Canada
and England (our biggest non-US English-language markets, so far, nothing in Australia).
We did get complaints about the or/our suffixes and the s/z problems.
joe
On Mon, 4 Dec 2006 08:27:59 -0800, "Tom Serface" <tserface@xxxxxxx> wrote:

The big problem with putting it all in one EXE is that starting with Win 2K
you have to be running the native Windows OS for the language for it to find
it as the "default". When you use satellite DLLs you can, of course, load
any of them you want or simply change the region to get your code to load
the appropriate one automatically.

MFC uses FindResource() which just gets the default resource from the file.
If MFC would have used FindResourceEx() we could have provided and LCID to
tell it which language to use at run time. The only way I know around this
is to write a hook (detour) for the FindResource function and and replace it
with a call to FindResourceEx()... or ... just live with the caveat that the
language works only on the native language OS install (which is my
preference).

Fortunately, we haven't have any complaints about the way we're translating.
Of course that means one of three things:

1. No one uses the translations
2. They are happy enough with the translations so as not to complain
3. Customers are too lazy to take the effort to complain, but are just
complaining to each other during water cooler conversations.

Tom

"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message
news:3ig8n2lb8qm8mfqjuh11qmcq7ujaa08hm8@xxxxxxxxxx
The problem with the sublanguages is that is where a lot of the problems
arise. I have a
friend who discovered her Portugeuse ancestry, and has taken up the
language, has done
several translations of important works for the English-only Portugeuse
communities in the
US, and talks about the differences between the language of Portugal, of
Brazil, and of
the Azores. Sublanguage matters a lot, My Canadian students have trouble
typing
"!analyze -v" because it is spelled wrong. And the difference between the
use of latin
and cyrillic alphabets got people killed in the former Yugoslavia.

I've used both separate DLLs and all-lumped-in-the-.exe approaches, and
I'm not really
sure which one I like best. In my case, it tends to be what the customer
wants. We have
another product where the distributor for that product gets an
English-only .exe, and uses
a "batch" program to edit the resources, and distributes a French-only
.exe, a
Spanish-only .exe, and so on. That's obviously the easiest one for me to
maintain.

In spite of my rusty German, I'm basically monolingual, so when I do the
DLLs I tend to do
"<German> The value is out of range" so I can test, but leave the
translation up to the
customer. In the multilingual ones, if I add strings or resources, I do
the same thing
(for dialogs, I will usually do <German> and if the label is too small, I
lengthen it. Our
distributor says that this guarantees the labels are long enough for the
German words,
most of the time. But sometimes I just do <G>).

One of these days I'll feel confident enough to do a course on
internationalization
issues, but I'm not there yet.
joe

On Sun, 3 Dec 2006 20:37:59 -0800, "Tom Serface" <tserface@xxxxxxx> wrote:

Yeah, I used to include the sub-language as well, but since I have to
manage
all the translations it's not a problem for me. I guess it's just a
different technique for a different distribution model.

The trickiest thing I had to do was a "latest" app that needed all the
languages built into the EXE (can't use DLLs). I got it to work, but it
was
a pain (it used to be easier back on NT).

Thanks for the tips though. I'm noting a few things down for our next
development cycle.

Tom

"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message
news:u546n2he26k27tf9v9rif42da48852g7ac@xxxxxxxxxx
Our problem is that we send a product to our international distributor,
and HE hires the
translators, translates the resources, and distributes it. We were
surprised to learn
that he is now distributing the product in six languages we had no idea
were supported; I
remember that two of them were different dialects of the Cyrillic
alphabet. If I'd
hardwired any knowledge, he'd have had a real problem there. But all he
had to do was
create a DLL with the right 3-letter name and it all worked! I try to
keep all national
knowledge out of such apps (that's why I ended up writing
LocaleExplorer...I got tired of
complex experiments).

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
.

Relevant Pages

  • ANN: Localizer 3.22 release
    ... Localizer is a localization/globalization tool kit for applications written in Borland Delphi or C++Builder. ... Localizer can use standard resource DLLs to store translated resources as well as special "language ... - Language Libraries and Language Repository allow you to re-user your translations in different projects; ...
    (borland.public.delphi.thirdpartytools.general)
  • ANN: Localizer 3.25 - localization/globalization tool
    ... Localizer is a localization/globalization tool kit for applications written in Borland Delphi or C++Builder. ... Localizer can use standard resource DLLs to store translated resources as well as special "language ... - Language Libraries and Language Repository allow you to re-user your translations in different projects; ...
    (borland.public.delphi.thirdpartytools.general)
  • ANN: Localizer 3.40 release (localization tool)
    ... Localizer is a localization/globalization tool kit for applications written in Borland Delphi or C++Builder. ... Localizer can use standard resource DLLs to store translated resources as well as special "language ... - Language Libraries and Language Repository allow you to reuse your translations in different projects; ...
    (borland.public.delphi.thirdpartytools.general)
  • ANN: Localizer 3.41 release (localization tool)
    ... We are glad to announce Localizer 3.41 release. ... Localizer can use standard resource DLLs to store translated resources (like ... Borland's ITE) as well as special "language files" format which is more ... translations in different projects; ...
    (borland.public.delphi.thirdpartytools.general)
  • Re: NRC kwaliteitskrant? Echt niet!
    ... language has borrowed other words or usages from. ... poor translations from English tend to have on other languages. ... Why would native German speakers ...
    (sci.lang)
Loading