Changing form labels to cyrillic 1

[Tom Borgmann]

Hi all

one of our customers is expanding his business to Bulgaria und therefore wants to use our app with a cyrillic interface.

We set up a WinServer2019 Evaluation and installed cyrillic for 64bit as well as 32bit apps
Then I placed the vfp9rrus.dll into our apps directory (right beside the other vfp9 dlls vfp9r, vfp9rdeu, vfp9renu).
For our apps I added CODEPAGE = 1251 into config.fpw and ... nothing happened.

So I wrote a small app for pure testing purposes where I experimented with Themes = .F., FontCharSet = 204, Sys(2300,1251,1), CPCONVERT( 10000, 1251,...)
But no cyrillic letters anywhere. All labels are still shown in their original glory

So, obviously I've taken the wrong path somewhere or as Danny Glover once said: I'm too old for this sh...

Can someone please help me to untie the gordian cyrillic knot in my head?!?!?

TIA




-Tom

https://www.blogger.com/profile/08903165976787522012

 

[Chris Miller]

There's the start switch -L: your.exe -Lvfp9rrus.dll

https://www.vfphelp.com/vfp9/_5wn12p2yq.htm

Without the -L switch the VFP runtimes decide about the resource DLL by the Windows language. So it's picked up automatically if Windows itself is Cyrillic. But having the Cyrillic language pack installed doesn't make Windows Cyrillic, even not when you make Cyrillic the default language. At its core a multi language version of Windows is and stays English, so VFPs runtime defaults to the vfp9renu.dll. The automatic resource file choice is therefore pretty much deprecated.

Not sure if you could guide VFPs runtime to still recognize Cyrillic automatically. But then the -L switch will work in any case.

Chriss

 

[Tom Borgmann]

Hi Chris,

just added -Lvfp9rrus.dll to the desktoplink of the test app

C:\_al\mware10.1_Transa_EN\cyrillictest.exe бВэоз9иикялавв

which should be -Lvfp9rrus.dll hopefully

but this didn't change the labels.

-Tom

https://www.blogger.com/profile/08903165976787522012

 

[Chris Miller]

Maybe you need the fill path.

On the other side, also the Russian ANSI code page has the latin letters...

https://de.wikipedia.org/wiki/Windows-1251

You can check whether you have the vfp9rrus.dll in use by using a function that uses the resource, like CMONTH().

Chriss

 

[Tom Borgmann]

Hi Chris,

I tested by assigning the inputvalue of a textbox to its corresponding label.caption. Ét voilà: And then there was cyrillic....
Jeeez, should have done this last week, already.
Currently it seems, that adding CODEPAGE=1251 to config.fpw and placing vfp9rrus.dll into install directory was enough just as I thought.
It didn't come to my mind, that 1251 also knows latin letters =8-O ... TY for that info

Well, step 1 is done. Now I'll have to look for a solution of making CursorToXml use of 1251 and 1252 on demand. As we store our multilanguage data within XMLs that are read at app start and assigned at form start, my vfp based tool (where I place captions, messages, help und custom strings) knows, which language is currently edited and therefore should create 1251 or 1252 XML header. However, it doesn't. config.fpw codepage is 1251, but the tools saves per se with 1252.

Doing it dirty would manipulating data at app start by using FILETOSRING() to place the XML in a string, use STRTRAN() to change 1252 to 1251 and the do XMLTOCURSOR() to the string.
But somehow I don't feel well about this. Time for more research und testing

Again, thanks for your input

-Tom




-Tom

https://www.blogger.com/profile/08903165976787522012

 

[tomk3]

Hello Tom,

some ideas :

the last parameter, set it to 1024, maybe add an xsd

use cpdbf()

https://social.msdn.microsoft.com/F...-is-encoded-in-utf8?forum=visualfoxprogeneral

replace cursortoxml() with xmladapter or github xml functions

strconv to switch to utf8 and back within xml

regards
tom

 

[Chris Miller]

It didn't come to my mind, that 1251 also knows latin letters =8-O ... TY for that info

I don't know if you expected English, German, French or other latin caption to turn into Cyrillic letters without meaning but looking like Russian like real Russian text. I haven't looked, but expect latin letters are part of all the ANSI codepages VFP supports. Otherwise you'd have a really hard time writing VFP code in those codepages.

I second tomk3 to use UTF8 in the general case and convert to the ANSI locale, that should have the least complications and allows multi-language data, too. On the other side codepage-specific XML would also only take 1 byte for Cyrillic letters, so when data in the locale is all that matters to customers of that locale, it would mean no need for double byte characters.

I tested by assigning the inputvalue of a textbox to its corresponding label.caption

Okay, but then you only check whether the codepage is active, how about checking whether vfp9rrus.dll is used by displaying CMONTH(), for example? Or a Messagebox with Yes/No buttons in Russian?

Chriss

 

[TamarGranor]

Changing the application's language isn't as simple as changing the Windows language. You should take a look at

http://www.stevenblack.com/intl/.

This is a tool for producing multi-lingual applications;it's now open source. It was created by Steve Black, the guy who created and still operates the VFP Wiki.

Tamar

 

[Tom Borgmann]

@Chris
Yes, the messagebox show cyrillic letters for Yes, No, Abort, a.s.o

@Chris and TomK
I'll give it a try to change the XMLs to UTF-8. This might even help using them from our non-VFP Apps. We'll see

@Tamar
I know about Intl Toolkit since one of my first visits to German VFP DevCon decades ago. But I won't make such a change to a VFP based app that we are currently replacing with new software written in C#/DevXpress. The already existing multilanguange functionality is more than efficent enough to stay with it.

BTW, when talking about a VFP based app this means
~500 VFP .app/.exe files
~300 web based apps and services created with (DLE)
and a growing number of DevXpress Apps for desktop and web

So, currently I'm only taking a bit care for an old horse 'til it retires

-Tom

https://www.blogger.com/profile/08903165976787522012

 

[Chris Miller]

Good to hear, then the resource DLL is taken into account.

Are there still problems with no Bulgarian language appearing? By the way, Bulgarian uses the Cyrillic alphabet but the texts that exist in vfp9rrus.dll are obviously Russian, not Bulgarian. Another large portion of text embedded in the vfp9rrus.dll are the VFP error messages. So an error log that logs Message() will now log russian error messages.

I guess you're just starting to have the translation data to apply to labels, for example. Or is it mainly entering and storing Cyrillic text? The vfp9rrus.dll won't interfere with that at all. Only the codepage of DBFs, not only of XML files, matters, and the one used for display. But you could always have any codepage DBF and binary memo fields. I always wonder what it really means, as ANSI codepage memos will also need to allow any byte 0-255, it'll just be displayed with the characters of the codepage, but that'll be more dominantly determined by the current UI codepage, for example for whatever is output in the _screen with ? and for any label or textbox value, etc. At least there won't be an implicit codepage translation even if you store UTF-8 into a normal memo of a dbf that has a specific codepage.

Sounds like a decent application with 500 app/exe files, very modularized, I guess.

Chriss

 

[Tom Borgmann]

Hi @all,

just wanted to give some feedback on my progress.

currently it seems, after some additional testing, that all I have to do is changing the way of creating my language XMLs.
So changing my testcode from

CURSORTOXML( [crsCyrillic] , FULLPATH( CURDIR() ) + [crsCyrillic.xml] , 1 , 0+2+8+32+512 , 0 , [1] )

to

LOCAL lcXmlString as String
CURSORTOXML( [crsCyrillic] , [lcXMLString] , 1 , 0+2+8+32 , 0 , [1] )
STRTOFILE( STRCONV( lcXmlString , 9 ), FULLPATH( CURDIR() ) + [crsCyrillic.xml] )

does the trick.

Well, this and adding vfp9rrus.dll to the app directory and setting the 1251 Codepage in config.fpw is 'all' that had to be done so far.

Well, working with VFP will make you learn something new every day, even after 25 years

Again TY @all for your help!


-Tom

https://www.blogger.com/profile/08903165976787522012