Subject Re: [IBO] Suggestions for 4.0
Author Daniel Rail
Hi Jason,

I'm currently using Multilizer for multilingual applications. It
reads all the properties that are Strings and TStrings. Then the strings
are placed in a dictionary where you manipulate all the languages that you
want in your application and use the interface components to load the file
and switch languages on the fly.
Your idea of a centralized dictionary is wonderful. Take a look
at Infopower's TwwIntl component, it does this for all Infopower's
non-visual components, since all the visual components already have the
properties visible to modify. I know that you might have some error
messages coded in and it would be nice to have access to them as well to
Just keep in mind that there are a lot of ways to create a
multilingual application. Keep your interface to the strings simple so
that those that use an external multilingual tool can easily work with your
If you have any questions, don't hesitate.

Have a nice day.

Daniel Rail
Senior System Engineer
ACCRA Group Inc. (
ACCRA Med Software Inc. (

At 2000-12-01 04:38, you wrote:
>The whole multi-language aspect of IBO needs to be re-thought out. I would
>like to do something along these lines.
>At the foundation level of IBO there is a Session and then an IB_Component
>that has an IB_Session property. I would like to make it so that the session
>level has a language property and then if a person wants multiple languages
>for an application they just include the additional units with the
>translations in it. There would be some sort of event that would trigger
>each IB_Component that the language changed and all controls, forms, etc.
>could respond to this event and recalculate their strings based on the
>Each language unit compiled into the EXE would register itself to a global
>list during initialization that the session could build a list of languages
>to chose from. Of course if nothing was added English would be the only
>The hard part of this is to decide how to handle the resolving of the
>language strings. Do I make one massive array where each unique message
>string is accessed as an array element. Then, if someone wants to write an
>additional language add-in for IBO is all they would have to do is supply
>the translation for each array item. I would Allow blank to go to the
>default (English) so that as new items are added I can simply add blank
>entries until the translators get a chance to fill in where I wasn't able
>Also, rather than have one massive array I think I would break it up to
>error messages, captions, hints, etc. so that it would be a little more
>organized by category.
>How does this sound to you folks out there that are using international
>I could also allow it to hook into an external DLL as well...
>Jason Wharton
>CPS - Mesa AZ
>----- Original Message -----
>From: "Kaputnik" <ibolist@...>
>To: "IBObjects List" <>
>Sent: Wednesday, November 29, 2000 12:05 PM
>Subject: [IBO] Suggestions for 4.0
> > Hi Jason,
> >
> > one suggestion from me for the next version:
> >
> > The IB_connection can hold much pre-prepared stuff for the Datasets like
> > Displaylabels, Alignment and so on.
> > As I always work with custom hints for my datasets (I have stringlists for
> > two languages for my dual-language-apps) it would be a great help, if I
> > could define custom hints (for the IBOBars and so on) at the
> > connection-level. For now, i have to replace the stringlist for every
> > Dataset in my app, when the user changes the language, what can be very
> > cumbersome. A centralized repository for the hints to be used as default
> > when the hints of the dataset are empty would be really cool.
> > I know, that I can change the hints in the Constants.pas, but that won't
> > help me for multi-lang-apps.
> >
> > Thanx for the attention and
> > CU, Kaputnik
> > (Nick Josipovic)
> >
> > nick@...
> > kap@...
> > -----------------------------------------------------------------------
> > superior Client/Server programming:
> >
> > a nice Tool for Interbase:
> >
> >
> >
> >
> >
> >