>>You posted this reg file to me some month ago it UT.
>>I prefer
>>to run windows setup again and select other regional settings.
>>This does the same thing but requires a bit more time.
>
>Actually, I should have included the regional settings into the .reg
>file, I guess it should work OK then.

Windows setup will extract the correct MS Sans Serif font from .cab files, for example. If You play with register settings the font files will
not get updated and cyrillic letters are not available in
window captions !?

>>You use static translation, disadvantages:
>>
>>1. Source code is required to tranlate into other languages
>
>Well, it covered well for the case where we needed it; we used only
>two languages, and so far haven't needed more; it's just the two
>codepages used here (8 bit 1250/852 and 7 bit yuscii, which uses
>[]\@^ for ©ÆЮÈ, really ugly), and the English and cyrillic versions
>that need it. Still, translating into another languages doesn't go
>as straightforward, because of the order of words in a sentence.
>Imagine this situation:
> "You already have printed invoice "+invoiceno+"."
> "A "+invoiceno+" számu számla már nyomtatva van."
>The second one is in Hungarian - if I used English as the source
>language, I'd have probably some twenty messages which would consist
>of a single period in the source; OTOH, there's probably another
>twenty sentences which would translate into a single "A "
>(equivalent of "The ") in Hungarian. Static transcripts handle these
>cases far better, since the transcript is local to the routine, ergo
>context-sensitive. Really, how would you handle this case in the
>Strings.dbf table?

You must re-write the hungarian sentence so that there is no separate "A "
translation in design time. Prepare for translation during design time.

>>3. Multi-language reports, forms etc. cannot use your
>>translation: you must translate the same word over and over.
>
>Actually, I have single-language reports; I'd probably end up
>putting reports into subdirectories, one per language, but then the
>maintenance would be a nightmare.

So you must switch to Markus genrepox and use its I() driver.

>strings within an app) I think the dynamic approach won't suit me -
>there are too many short strings which translate differently in
>different contexts, so I can't rely on dynamic translation in cases
>like that. For tooltips, it's OK, for captions yet it may not work
>as it should - same two words may have different meanings in two
>forms.

Divide the strings into separate shorter sentences and translate them searately.

>
>>Pros: This allows to see different language forms even in form designer
>>Cons: causes layout problems on right-aligned labels.
>
>The labels should be made sufficiently large, and not autosizing.
>I've actually found some buggy behavior with autosizing labels,
>which I can't reproduce.
>
>>possibility TWO: see other language in run time only:
>>
>>in form init, use code like
>>
>>for i=1 to thisform.controlcount
>>thisform.controls[i].tooltip = I(thisform.controls[i].tooltip)
>>.... right alignment correction
>>endfor
>
>Why do you have the right alignment problem? Maybe some of your
>labels are too short for some languages?

I have form of type

Label1 Field1
LabelTwo Field2

For labels, autosize must be true, because i want to invoke
a hyperlink when user clicks in label. If label is wider than
text, then user can invoke hyperlink by clicking in empty space which
is not desired!
alignment property for labels is set to right. Unfortunately,
when changing label
caption width in init time, right alignment is destroyed, form
appears like this:

Label1 Field1
Label2 Field2
LabelThree Field3

This is the problem you asked for.

>>> What doesn't work is form's caption -
>>>there's simply no way to tell W95 to use any particular codepage for
>>>this, and it obviously doesn't use system's codepage.

>I've forgot to include regional settings, else it should work with
>..reg file, too.

I think that form caption uses system font which is extracting
from cab files in win 95 init time based on selected regional settings.
So if you will not play with reg files, but re-install windows,
this seems to be no problem.

>>I use back-translation: I replace cyrillic letters with latin
>>equivalents in form captions and wait windows's. Looks nice.
>
>Your language also has both cyrillic and latinic? Lucky we. Of
>course, when I fill up the other language strings, I do type only
>the Hungarian and English, and for Serbian I simply programmatically
>fill up the cyrillic and yuscii versions.

There are no language with cyrillic and english character sets.
The back-translation is an attempt to display something useful
in windows caption when program itself works with cyrillic
letters. Form captions are somewhat user-changerable
in my accounting application so i cannot let them untranslated
because user enters data with cyrillic letters and those letters
cannot be used in form captions so i must replace them.
I have replaced messagebox() with my own font-changerable routine
when programs codepage!=cpcurrent()

The same problem occurs with wait window and define popup caption.

I have not found a good routine to replace wait window command,
Steve's msgsvc wait window is not in the upper right corner, maybe
i change it or try to find some other routinge or a way
to change wait window font. i have time to wait for tahoe and
then get final desicion.