>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. >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? >2. Re-booting or changing program is required if other >language user sits into computer. This really is a problem, but we never had it - we never really designed for multi-linguistic users. Though, this can be solved by not #defining the string constants, but variable or form properties instead, so the language gets resolved in the form's .load, so all the .inits of other controls can handle it properly. >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. >4. Multi-language debugging and layout testing is difficult, >requires re-compiling and re-booting. Yes, but it's more a GUI design matter, and less of a programming issue - i.e. if a text is #defined via a builder or whatever, the builder, once well tested, is sure to make proper formatting and no syntax errors and to have inter-language symmetry, i.e. if it works in one language, it will work in others. It's just that you must take care of not saying something stupid, and specially take care of string lengths - a good translator may be able to make it short and clear enough at the same time, but sometimes it's just not possible. Luckily enough, we have more screen and report room than before, we aren't confined to 80x25 anymore. >5. For each language there must be different program. Actually no, with the changes I've proposed in previous paragraphs, but as it is now, you only recompile in a different language. >Better use dynamic translation so we can discuss those questions >further, I will never switch back to static method. >) You seem pretty convinced, besides, the choice is yours. I'll work my way and you work yours, we'll probably meet somewhere. I'm not considering writing multilanguage apps at the moment, I have other things to do with much higher priority at the moment, but I still use the static method for my system routines, and from the problems I've already had (while searching for all the possible 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. >create table STRINGS ( sourcelanguage c(70), ; >destlanguage1 c(70), destlanguage2 c(70), .... ) >index on sourcelanguage tag srcl I do have such a table, though I have memo fields instead (some of the strings may get unreasonably long), and index on crc of the first word plus the crc of the whole string, and I use it for the builder routines - the actual transcription ends up in a subdirectory - .scx, .frx and .prg files. For system routines, I use another approach, I search for strings and ask for transcripts in all the available languages, then the routine inserts the #defines, and replaces the strings within the routine with appropriate c_constant names. This does require more work, I'm sure I have translated some things several times, but then it's all under control. >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. I've seen what this translator does, it's really mighty, but wouldn't satisfy me, nor some of my customers. I object even to "Windows has performed", I feel it should say "Windows have performed..." :) >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 I set fontname in app.init to be equal to _screen.fontname, so users have it the way they are used to have it - we seem to have come to the same idea. >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. >cannot be used in prg classes Why not? The i() function is evaluated at compile time in this case, no matter what you compile, a .prg or .vcx or .scx - but then, I'd rather move it into each control's .init method, so it fires at instantiation time, and in the PEM I'd leave Space(xx), where xx would be big enough for the longest version. >requires form re-design Any language version requires form redesign, at least some bits at some places, if you want to do it properly. >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? >> 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've forgot to include regional settings, else it should work with ..reg file, too. >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.