Re: Internatinalization and multiple language support without resource DLLs

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.