Localization
Mario Contestabile -- Mario_Contestabile.UOS__MTL@UOSMTL2.universal.com
Monday, January 13, 1997
Environment: MSVC 4.2b Windows 95
The time has come for me to localize my app into various languages. Fortunately,
my strings are all in resources, I can rebuild linking MFC statically or
dynamically,
and the NT version is UNICODE. At this point I want to choose the best method,
and
I'd like to hear how some of you have gone about doing this.
Firstly, how did your .RC get translated? Is there an applet I can give the
translator,
along with the .RC file, to have him do his work?
Secondly, what are the advantages of storing MY resources into a separate DLL,
(for which I could do a AfxSetResourceHandle(..) in InitInstance()), as opposed
to
keeping localized .RC files lying around (Not having to recompile for every
language
comes to mind; single binary).
Thirdly, MFC. If I understood TN057 correctly, I can link MFC statically using
the appropriate
L* files, (will this cause problems on an English dev. platform/environment? Do
I remove the
/D_AFXDLL define?), or I can link MFC dynamically and have the install ship
MFC40xxx.DLL
(the appropriate LOC language DLL).
WM_ENDSESSION
mcontest@universal.com
Brad P. Exchange -- Brad.P.Smith@Cognos.COM
Tuesday, January 14, 1997
[Mini-digest: 4 responses]
I'll answer out of order. :-)
>>>
>... MFC. If I understood TN057 correctly, I can link MFC statically using
>the appropriate L* files, (will this cause problems on an English dev.
>platform/environment? Do
>I remove the /D_AFXDLL define?), or I can link MFC dynamically and have the
>install ship
>MFC40xxx.DLL (the appropriate LOC language DLL).
<<
>
We've gone through this recently. We ended up with a hybrid. In fact, we
copied the l.* files from out of MSDEV and into our own code stream,
removed the /D_AFXDLL define, link these files into *our* resource DLL,
and use MFC dynamically but *without* its internal resources.
This may seem like a lot of extra work, but we did it for two primary
reasons: Namely our translators weren't impressed with some of the
wording used by Microsoft's translators (no accounting for artistic
license, I guess) and, more importantly, we have to support many more
languages than those provided with MFC, and therefore had to find a
"generic" solution.
>>
... how did your .RC get translated? Is there an applet I can give the
translator, along with the .RC file, to have him do his work?
<<
We insist that the translations firms have MSDev installed. The primary
reason is that translating covers more than just strings. You'll find
most of your dialogs will need to be "massaged" to handle idiosyncrasies
of the languages. Unless your translator *likes* hand-coding dialog
templates, having them use the same tools *you* used to generate them in
the first place makes sense.
>>
... what are the advantages of storing MY resources into a separate DLL,
(for which I could do a AfxSetResourceHandle(..) in InitInstance()), as
opposed
to keeping localized .RC files lying around (Not having to recompile for
every
language comes to mind; single binary).
<<
*And*, with some minor additional tweakery, you could ship multiple
language DLLs with your product, and allow the user to change language
on the fly (well, maybe not *that* easily, but you get the point).
Plus, if you follow the above and have your translators run MSDev, they
can do their own test builds of the DLL, you give them the EXE, and they
can do their own testing. With a separate DLL, you don't need to ship
your app's source all over the place for building eash time.
Brad.
--
Brad P. Smith - Software Designer
Cognos Inc.; 3755 Riverside Dr.; Ottawa, Ontario, CANADA; K1G 4K9
Voice: (613) 738-1440 ext 3702 FAX: (613) 738-0002
Internet: smithb@bpsmicro.com or smithb@cognos.com
-----From: Strhan Mojmir
>>The time has come for me to localize my app into various languages.
>>Fortunately,
>>my strings are all in resources, I can rebuild linking MFC statically or
>>dynamically,and the NT version is UNICODE. At this point I want to
>>choose the best method,
>>and I'd like to hear how some of you have gone about doing this.
Our EXEs & DLLs allways contain resources in basic locale (German-Swiss)
and for each EXE we
have a bunch of resource-only DLLs in locales Italian-Swiss,
French-Swiss, etc. which contain
>localized resources for EXE, our DLLs & MFC DLL. We
AfxSetResourceHandle(..) these DLLs.
>
>>Firstly, how did your .RC get translated? Is there an applet I can give the
>>translator,
>>along with the .RC file, to have him do his work?
For translation we use
http://ourworld.compuserve.com/homepages/werners/rctrans.htm
It's good, but still requires some manual changes in translated .RC. But
I hope that
this will change in near future.
Hope this helps.
Mojmir.
-----From: Mats Haggren
>Secondly, what are the advantages of storing MY resources into a separate
DLL,
>(for which I could do a AfxSetResourceHandle(..) in InitInstance()), as
opposed
>to
>keeping localized .RC files lying around (Not having to recompile for every
>language
>comes to mind; single binary).
>mcontest@universal.com
The great advantage is of course that you won't have to rebuild the
application itself, thus
minimizing the risk of introducing errors.
/Mats
---------------------------------------------------------------------
Mats Haggren phone: +46 (0)13 35 92 69
Intentia R&D AB fax : +46 (0)13 35 91 03
Ottargatan 3 /// home : +46 (0)13 27 46 60
582 78 Linkoeping, Sweden (o o) email: haggren@hem.passagen.se
--------------------------ooO-(_)-Ooo--------------------------------
-----From: "Hemanta Banerjee"
Hi,
>
> The time has come for me to localize my app into various languages. Fortunately,
> my strings are all in resources, I can rebuild linking MFC statically or
> dynamically,
> and the NT version is UNICODE. At this point I want to choose the best method,
> and
> I'd like to hear how some of you have gone about doing this.
I think the best method will be to separate the resources as a separate
DLL and dynamically load the corresponding DLL in InitInstance(), as this
will reomove unnecessary recompilation of code for each language and u
can mix and match the resources (if at all u need it).
As reegards some app to transalate the strings , i don;t know whether such
tool is available and making such a tool is also not feasible as the
semantics differ for each language and a direct dictionary transalation
may convey a completely different meaning.
Hope this helps u,
Hemanta Banerjee.
| Вернуться в корень Архива
|