Archive for the ‘Localization’ Category


Posted: 2017-01-19 in Localization

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.



Posted: 2017-01-19 in Localization

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.


Posted: 2017-01-19 in Localization

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.