Localization [examples]

Define the codepage for the App
set codepage to "utf-8"


Define the codepage for data
set codepagedata to utf-8


Column constraint to prevent code page translation for character and memo fields

ALTER TABLE customer;


Convert a codepage encoded App, database, file or table to its UTF-8 equivalent
convertutf8 app myapp
convertutf8 database mydatabase
convertutf8 table mytable 
convertutf8 file mygreekfile.txt codepage "Windows-1253"
convertutf8 file mygreekfile.txt codepage 1253

Convert a codepage encoded character expression to its UTF-8 equivalent
cGreek = filetostr("mygreekfile.txt")
? cGreek
? strconv(cGreek,1253)
? strconv(cGreek,"Windows-1253")


transtext.prg) to handle the translation, so my delegate just calls the script, passing it the default message (‘arg’ passed to the delegate procedure) and any additional parameters, here ‘it’.

// Event delegate for 'texttranslator' event
function z_transtextjs_texttranslator(arg)
	return Lianja.evaluate("transtext('"+arg+"','it')");

The equivalent Lianja/VFP delegate procedure for desktop only Apps would be:

// Event delegate for 'texttranslator' event
proc z_transtext_texttranslator(arg)
	return transtext(arg,'it')

And here is my transtext.prg in the Library:

// transtext.prg
parameter cText2Trans, cLang
if pcount() < 2
	cLang = "fr"
//if isserver()
//	// These are message titles in the web/mobile client
//	// you may want to handle these differently
//	if inlist(cText2Trans,"Error","Information","Message","Success")
//		return cText2Trans
//	endif
do case
case len(cLang) = 2
	return keylookup("translations!messages_&cLang","original",alltrim(cText2Trans),alltrim(modified),cText2Trans)
case cLang = "annoying"
	return cText2Trans + "...just sayin'")
	return cText2Trans
// end of transtext.prg

The main case statement:

return keylookup("translations!messages_&cLang","original",alltrim(cText2Trans),alltrim(modified),cText2Trans)

uses the KEYLOOKUP() function (for an SQL equivalent, use SQLLOOKUP()) to look up the default message in the index of a table in the translations database that I have created. Since the cLang parameter received the value ‘it’, the table is messages_it, which I have created with the following values for sample messages from the desktop and web clients:

Record #  id          original                       modified

        1  0000000001 Success                        Riuscito
        2  0000000002 Information                    Informazione
        3  0000000003 Error                          Errore
        4  0000000004 Message                        Messaggio
        5  0000000005 Record was updated.            I dati sono stati aggiornati.
        6  0000000006 Record was added.              I dati sono stati inseriti.
        7  0000000007 Record was updated             I dati sono stati aggiornati
        8  0000000008 Record was created             I dati sono stati inseriti

The KEYLOOKUP() function uses an index on the table, so I have also created an index tag (create it in the Command Window):

index on original tag original

I’ve created a similar table, messages_fr and its original index tag to be used when the cLang is ‘fr’ as shown in the screenshot earlier.

If the message is not found in the table, the KEYLOOKUP() function just returns the original message passed (cText2Trans).




I’ve just migrated to Lianja 2.0, but I’ve some problem with some char… à, °…
also if I rewrite it, after reload the app, there are wrong..
Did you convertutf8 app <appname> and set your Lianja App Builder shortcut to include the –utf8 command line switch?

in my app, I call a RSP page:

<%@ Language=VFP %>
<Meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

        if (typeof window.parent !== 'undefined' && typeof window.parent.Lianja !== 'undefined')
                window.Lianja = window.parent.Lianja;

        private lnI
        lnI = 0
        public rspbusy
        rspbusy = .T.

        set macros on
        set fixed on

From this RSP page, I return a value, selected by user.
The Value is “Rosè“, but from code, I get “Ros?”.
How can I convert to UTF-8?
recommend that all apps should be developed and deployed as utf-8.

Tip: To convert a string containing codepage characters to UTF-8, use the strconv( string [,codepage] ) function. By default the “codepage” used will be your locale codepage.



What is the map and format of the config.db ?
The map (C:\lianja\cloudserver\tenants\public\) is still empty.
config.db is not present in the lianja-structure.
I tried “set currency to ..” in just one page in an init-event.
But of cours, it belongs in a config or setting-screen..
For development purposes you can create a config.db in the .\Lianja\conf\ directory and put your SET commands there.

Each database has a different way of handling the character collating sequence which is one of the reasons Lianja uses unicode/utf-8 which is the recommended encoding for apps that need to share data between desktop and web/mobile apps.

Lianja does not support changing the collation sequence in the scripting language.
VFP does not support unicode/utf-8 but uses the rather old style of windows codepages.

The SET COLLATE “GENERAL” is primarily for US and Western European characters and will not work correctly with DBCS or unicode/utf-8.
So, if you want to query data using SQL then convert the string literals

I can put a “set date to german” by the Console and it works ok in DeskView.
But how and where I must write it in Javascript UI?
Dates in the Web Client are displayed in ANSI format so to be independent of the locale of the user.
The format is:
yyyy-mm-dd or yyyy-mm-dd hh:ii:ss

in WebView (report) it’s displayed ok (e.g. “German”)…
the WebView report is generated server side using a dynamic server page which is why it can display an alternative date format to ANSI.

Lianja is all UTF8 if you put the –unicode command line switch on the desktop shortcut.
This is auto detected for Chinese, japanese, korean, russian and other locales.

App has a page with id “Catalogo_de_Almacenes” containing spanish characters.
That is the “id” NOT the “caption“.

In the app directory look for the file with a .lianja extension then search for that name and remove the accented character.
You cannot use accented characters for the id or any of the UI elements.
you have –utf8 on the app builder command line switch but that particular app had been saved with a codepage locale set.

It is much better to use Unicode UTF8 as this works better in web and mobile apps too.
You cannot use accented characters in page, section or formitems id. They can be used in captions and other attributes.

(Gant chart) When I type any text that has an accent (i.e. “cámara”) in any text label or text box it doesn’t recognize the letter and it changes it by a ? symbol.
Set the Locale on your Lianja App Builder and desktop Lianja App Center to utf-8.

You can use the Command Line Switches –locale or –utf8, e.g.

C:\lianja\bin\lianja.exe --utf8
C:\lianja\bin\lianja.exe --locale utf-8


C:\lianja\bin\lianjaruntime.exe --utf8
C:\lianja\bin\lianjaruntime.exe --locale utf-8

.rsp page that generates the Gantt chart probably needs to have the following in the <head>
<meta charset=”UTF-8″>
File is graph_gantt.rsp in the Library.


VFP does not support unicode/UTF-8. It uses windows specific code pages which is discouraged now.
Lianja uses Unicode/UTF-8 to represent data if the command line switch –locale utf-8 is specified on the desktop shortcut. Lianja will auto-detect many locales that use double byte characters and automatically use Unicode/utf-8 internally.
The standard character encoding for web browsers is UTF-8.
If you want to import your VFP data that you have stored via a codepage you must add –codepagedata to the desktop shortcut for Lianja App Builder and Lianja App Center.
Lianja/VFP has a set of functions that operate on double byte characters. LENC() being one of them. There is a list on the development roadmap that we have implemented. These are:
These are the correct functions to use when working with Unicode/UTF-8 characters.

UTF-8 is the standard for double byte character sets and Lianja stores and retrieves data in UTF-8 format so as to make your data interoperable across desktop and web apps. It also is code page independent so you can display Korean, Chinese, Japanese, english and other characters without any concern for collating sequences or code pages.
One of the great advantages of UTF-8 is that the characters are represented in the correct collating sequence order. The disadvantage is that it uses more space to represent the characters.
When building Web and Mobile Apps no matter what locale the user is in that is working with your App and Data then the characters will be correctly displayed.
So to summarize.
LENC() will return 1 for a Korean character NOT 2 and not 3.
LEN() will return 3 as this is the UTF-8 character encoding for a Korean character.
So if you want to perform string manipulation use the functions listed above.

In v1.3 I have added SET CURRENCY TO “EURO” or SET CURRENCY TO “€” which are both handled when used with the currency() function.

in v1.3 you can specify the desktop shortcut with –unicode or –utf8 also which is the same as –locale utf-8

Note that since Lianja v1.2 unicode/UTF-8 is automatically used for recognized DBCS such as chinese, Japanese, and Korean.
If you want to share data and/or apps between desktop apps and web / mobile apps it is recommended that you use unicode/utf-8.

In the desktop shortcut you need to add
–locale TIS-620
In the next version v1.1.6 I have also added an environment variable which you can specify the locale.
Then that works also without having to change the shortcut.

The following locales can be specified but will need tested by other developers as we don’t have all these keyboards available.
Apple Roman
IBM 850
IBM 866
IBM 874
ISO 2022-JP
ISO 8859-1 to 10
ISO 8859-13 to 16
Iscii-Bng, Dev, Gjr, Knd, Mlm, Ori, Pnj, Tlg, and Tml
JIS X 0201
JIS X 0208
Windows-1250 to 1258

In v1.2.4 I have added the ability to override the month and day names in the popup date picker in Web Apps. Note that in Mobile Apps such as iOS or Android Apps the native date picker is used.
Full localization is planned for v2.0. This is an interim solution for those complaining about the date picker using english words.
You need to specify a two character locale name e.g. de for Germany, fr for France etc.
This causes the date picker to display with localized text in Web Apps.

Dates are always displayed in ANSI standard format so that the server does not have to understand the locale of the user. Here is an example using ‘de’ for German.

In v1.2.4 I have added “RightToLeft” as a caption position in Form and Canvas sections for both desktop and web to better support RTL languages such as Arabic.

Yes Lianja works with Unicode/UTF-8 by default in arabic locale.
If you have existing VFP data that is not in unicode/UTF-8 you need to specify –codepagedata on the “Lianja App Builder” and the “Lianja App Center” desktop shortcut so that Lianja will read the arabic characters via the codepage without trying to convert them to/from Unicode/UTF-8.

All you need to do is specify –locale utf-8 on the desktop shortcut. This should now work with Japanese and Russian also. Let me know if you have any issues.

I append 2 screenshots with Russian content (Version 1.2):
– field caption o.k.
– field content before beeing stored o.k. and after that wrong (only ???????)
– section header (Фамилия и имя = name and prenome) wrong

You also need to install Russian language fonts on your computer for this to work.