Resource Localization

I have an application that needs to eventually be translated into several languages.

I have used Stefan Kuhr's article from CodeGuru
(http://www.codeguru.com/misc/scribml.shtml) to break my resources out to a DLL. But when I use the Microsoft RLTools to try to process this file, I get a generic dialog box with the Stop icon and the text "Memory Allocation".

The RLTools work great with the Scribble example, but not mine. My application has about 30 dialog boxes and about 300 strings. My RES file is 100K and the resulting DLL is 304K. When I tried deleting all of the resource bitmaps the RES size shrunk to 91K with the DLL size falling to 104K.

Possible accepted solutions would be...
- How to get RLTools to work with my app.
- Alternative localization tools.
LVL 2
GleasonGuyAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

GleasonGuyAuthor Commented:
Edited text of question.
0
mikeblasCommented:
If you ask me, using a localized DLL is the wrong way to go for most applications.

Please check out the LANGLOAD.ZIP sample at http://www.nwlink.com/~mikeblas/samples/ (which will soon, someday, move to http://www.mooseboy.com/ ).

..B ekiM
0
GleasonGuyAuthor Commented:
I'm not against this approach, but I'm looking to keep my end of the localization process to as little as possible. Won't this also require duplicating the dialog resources?
With my 30+ dialogs, this could be painful.

Correct me if I'm wrong, but my AfxFormatStringX() and CString::Format()calls will not need to be modified since they eventually use LoadString().
0
Cloud Class® Course: Microsoft Exchange Server

The MCTS: Microsoft Exchange Server 2010 certification validates your skills in supporting the maintenance and administration of the Exchange servers in an enterprise environment. Learn everything you need to know with this course.

MensanaCommented:
I faced, somehow, the same kind of problem lately. Here is how I solved it:
I created a second resource file including only a string table. You can define multiple strings having same ID. The only restriction is that those strings must be defined in a different language section. I had a string table defined in the English-US section of my main resource file and then I had a second string table (Greek) defined in a separate resource file (which can be a Unicode text file so that it can store all kind of funny characters). The same way you can define other resource files, one for each language. Than you can link all those files into your project. Even though the strings have same ID (IDs must be defined in the “resource.h” file) there won’t be any compiling errors because your strings are defined in separate language sections and each section starts with some pre-compilation macros that links correctly all those parts.
Now you don’t have to modify your code. You just use the unique ID for a pair of strings. Based on the locale for your machine, the app will select the right string to display it on the screen. Change the locale and start the app again. Your screen will be drawn accordingly.
The down side is that you have to load each string, title, caption, message, etc. from  the string table. If you’ll take a look at Mike’s example (LANGLOAD) you’ll be able to create a function that’ll allow you to switch to a different language (using an accelerator, eventually). I’ve done such thing. If you want more details just give me a shout.
Hope this will help you,
Eddie.
0
GleasonGuyAuthor Commented:
I definitely think I could get this to work. It just seems to me that there is a lot more effort on my part.

For every language that we will support there needs to be a resource for it. Every time that I add a new message, I will have to add one for each language. In the short term, we will only be doing a German version, but over time we will be doing Japanese, Spanish, plus some others.

Plus, with my 30+ dialog boxes, I would have to do a LOT of string loading to get them translated.

I liked how RLTools worked with the example, but it's too bad it didn't work for my app. I'm not sure why there isn't an updated version of RLTools.

I'm looking into the possibility of Corel CATALYST. It looks slick, I'm just trying to make sure it will do what we want it to.
0
MensanaCommented:
I know what you’re trying to say. For our purpose I developed a tool (called String Table Translator) that has a friendly user interface. It pairs all the strings sharing the same ID allowing me (actually it won’t be me) to edit/modify a translation. With few efforts it can be adapted so that can deal with multiple languages. I define an English string using the resource editor that comes with the VC++ IDE. I use the ID of that string in my code. Later I only have to call the guy-that-speaks-greek and ask him to translate all the strings within my app. From your project perspective, you still have the problem of creating a LoadStrings function for all your 30+ dialogs.

Regards,
Eddie.
0
mikeblasCommented:
> Won't this also require duplicating the dialog resources?

Yep.  (But so does having a localized resource DLL.)  Any you'll probably have to do it anyway, since most languages (especially German and Japanese) use more or less space to express the same information. Unless you want the localized layout to look goofy, you'll want to tune each dialog.

 > calls will not need to be modified

Correct.

..B ekiM
0
GleasonGuyAuthor Commented:
> using a localized DLL is the wrong way to go for most applications.

I get the impression that there is probably a long list of reasons for you to say this, but why?

Is having all of an app's resources in a DLL and then using something like RLTools or Corel Catalyst to modify a copy of that DLL for a specific language considered a "Bad Thing" too?

I would rather just make one set of resources and then let our foreign offices handle the translation. That would let me work on a new project and not rehashing this old one.

RLTools and Catalyst look like they allow the user to change the size of the dialogs to handle issues of word length and character size. Is this bad?

0
GleasonGuyAuthor Commented:
I hope I'm not coming off as ungrateful or stubborn. I'm just trying to find a balance between the work I do, the work the translator does, and any future work the software maintainers will have to do.

I'm also trying to fully understand the decision before I make it.

Thanks for your help.
0
GleasonGuyAuthor Commented:
We are leaning towards using Corel Catalyst to localize app. We don't have the resources (time or manpower) to do the translations in house. Using Catalyst will allow us to build and distribute one app and add in the DLLs appropriate for the locale.

Mike,
I'll give you the points if you explain why "using a localized DLL is the wrong way to go for most applications" or why using Catalyst would be bad. If you don't think the points are appropriate enough for this info, I can increase them.

0
mikeblasCommented:

 > I'll give you the points if you explain why
 > "using a localized DLL is the wrong way to go for
 > most applications"

A localized DLL requires that you implement a pretty elaborate mechanism for loading the DLL and then finding the resources. MFC has this built-in, but it was built-into MFC before MFC was ported to Win32. MFC kept the mechanism to help budget MFC's memory footprint.

This mechanism additionally falls short because (starting in Windows NT 4, but very readily in Windows 2000), the user can change the locale at runtime. MFC can't react to such a change when you have a resource DLL.

If you stamp your resources with the LANGUAGE directive, you'll take advantage of Window's handling of locales. You can have default resources that load, even if you've not provided a locale for Windows.

 > or why using Catalyst would be bad.

I haven't used Catalyst, so I can't comment on it.

 > If you don't think the points are appropriate enough
 > for this info, I can increase them.

Sorry; it's just that I've become very busy over the last few weeks.

..B ekiM
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
GleasonGuyAuthor Commented:
Thanks. I see what you mean now. I keep forgetting that my industrial kiosk application probably falls outside of the "most applications" category. There are a lot of things that we do that we wouldn't do if we were writing a "normal" desktop app.

I've successfully implemented on-the-fly language transitions using LoadLibrary() and AfxSetResourceHandle(), then reloading menus and toolbars. So far it seems to work flawlessly with the demo version of Catalyst.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
System Programming

From novice to tech pro — start learning today.