Wow, that's great. I'll have to try that out for sure. In fact, I should
One of the other reasons why appTranslator is your friend: Every time you
build the translated resource DLL, it scans your original exe for changes
in the resources and patches the translated resources accordingly. So you
simply need to rebuild the resource dlls to make sure you don't have a
missing control in the trzanslations.
And if you want to be really sure you don't forget to rebuild these DLLs,
just add a postbuild step in Visual Studio to let appTranslator build the
resource DLLs each time you build your EXE.
Serge.
http://www.apptranslator.com - Localization tool for your MFC applications
"Colin Peters" <cpeters@coldmail.com> wrote in message
news:4978b756$1_2@news.bluewin.ch...
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@yahoo.com> wrote in message
news:Xns9B9AC354F4D29MihaiN@207.46.248.16...
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.