custompropertysets

[Rob Cozens]

Hi Ron,

>I am setting up an application that can display dialogs, menus etc in a
>variety of languages based on the user's choice. There seem to be several
>ways to go about this and I would appreciate input based on your experience
>and insight. Klaus uses a text file and then reads in the whole file to a
>single userprop in the stack and then calls the needed item of that userprop
>through judicious use of an itemdel. If I've understood Rob correctly, he
>doesn't use userprops at all in his multi-lingual app. (thanks guys for your
>input)

I think the basic mechanism Klaus & I use is the same: store all 
messages, prompts, and labels in a single location, and pull out each 
line (or item) as needed.  Klaus stores his list in a custom 
property, I store mine in three places: an external text file, a 
field, and a global.  The text file is there so the user can modify 
messages with a text editor (although the Library includes a 
translation screen that can be used also), the field (could be a 
custom prop instead like Klaus uses) stores all messages in the stack 
so they don't have to be loaded on openStack, and the global is used 
for real-time lookup of runtime messages.

>My thought is to set up a custompropertyset in the main stack for each
>language. Then set up a key for each necessary btn name, dialog etc. The
>keys would then be referenced on open cd or open wd of the substacks.

This means all text for all languages you support must be stored in 
the stack, even though only one language is needed at any time.

>This would avoid setting up custompropertysets and keys for each object
>(which seems redundant and difficult to maintain) and would not create
>another file to keep up with on the HD(easy enough to maintain but the small
>possibility of having the file misplaced). [Rob's note: In my 
>design, the app works fine without the text file...it simply 
>disables the "Load Message File" and "Translate Message File" 
>menuItems.] But I wonder how hard my approach
>would be to maintain and update/correct? Also, any memory issues concerning
>reading the file after startup being better than including the data as part
>of the app.?

If you have a lot of controls and messages, it can be tedious; but 
it's quite straightforward.  You can make the job easier by replacing 
text labels with icons.  This frees one from having to be concerned 
whether a label field is wide enough to display the translated label. 
The amount of text remains the same whether it's in the stack 
initially or loaded from a text file, except (as noted earlier) using 
an individual external file for each language supported means only 
one language's text is resident in a stack at any time.

One final note: Translation is not a daily activity.  It may never be 
used by most users, and if used, only once.  For that reason it makes 
sense to me to load all labels, tool tips, names, etc. when the 
language is changed than to do some translation every time a card is 
opened.

Oops!: a second final note...don't forget translation also implies 
changing date & number display formats.
-- 

Rob Cozens
CCW, Serendipity Software Company
http://www.oenolog.com/who.htm

"And I, which was two fooles, do so grow three;
Who are a little wise, the best fooles bee."

from "The Triple Foole" by John Donne (1572-1631)