>Anyway, I've succeeded in one thing: I run
>regedit \w95\cp1250.reg

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.

You use static translation, disadvantages:

1. Source code is required to tranlate into other languages
2. Re-booting or changing program is required if other
language user sits into computer.
3. Multi-language reports, forms etc. cannot use your
translation: you must translate the same word over and over.
4. Multi-language debugging and layout testing is difficult,
requires re-compiling and re-booting.
5. For each language there must be different program.

Better use dynamic translation so we can discuss those questions
further, I will never switch back to static method. Use

create table STRINGS ( sourcelanguage c(70), ;
destlanguage1 c(70), destlanguage2 c(70), .... )
index on sourcelanguage tag srcl

function I
parameter prmLANG
select STRINGS
loca for prmLANG==sourcelanguage
return destlanguage1

To fill the STRINGS table rapidly, put STRINGS content
into your homepage, register this page in Altavista and use
Altavista translation system to translate it
into other languages.
Alternately, translation servers can be used during program
setup allowing language selection by y end user, thus allowing
to support languages not known at design time.

Coding translation in forms:

possibility ONE: design-time translation

in for designer, put expressions to properties:

.tooltip = I("Mytooltip")
.caption = I("Mycaption")
.fontname = m.myfontname && memory variable set in program init

Pros: This allows to see different language forms even in form designer
Cons: causes layout problems on right-aligned labels.
cannot be used in prg classes
requires form re-design

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

> 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.

??? Windows uses system codepage always in window captions when
you set system codepage during windows setup by selection regional
settings.
I use back-translation: I replace cyrillic letters with latin
equivalents in form captions and wait windows's. Looks nice.