Switching Localization

One user experience (UX) developers seek to emulate is to allow the user to switch language by clicking on a small flag icon. If you click on the French flag, then field labels, column headers, window titles, error messages etc will be in French. Click on the German flag, field labels, column headers, window titles, error messages etc will be in German etc.

By using the Localized Strings feature in Genero you can translate all your field labels, column headers, window titles, error messages etc to different languages. There is one key point to understand when it comes to adding the ability for the user to switch languages at will.

Genero applications are what is known in the web community as a single page application.  The web pages you see with those small flag icons that allow you to switch languages are typically not single page applications.  They have the model that each time the user clicks a link/button etc, a new page is loaded. So for these multiple page applications, the user chooses a new language, this choice is written to a cookie or something like that, and that language selection is sent back with every request for a new web page. For these multiple page applications, there is no matching application running on the back-end, each page request can be served by a process that is independent of the process that served the previous page request, and so the response can be completely in the new selected language.

With Genero and its single page application architecture there is a fglrun process running in the backend for the lifetime of your web application.  Consider this code in a Genero application

LET foo = upshift(%”hello.world”)
DISPLAY foo TO field1
CALL choose_language()
DISPLAY foo TO field2

If in the choose_language() function, the user selected French, would you expect foo to contain “HELLO WORLD”, or “BONJOUR LE MONDE”?. Answer is foo would contain “HELLO WORLD”.

Similarly would you expect “HELLO WORLD” or “BONJOUR LE MONDE” to be displayed to field1 and field2. Again “HELLO WORLD” would be displayed to field1 and field2.

In that first line the expression upshift(%”hello.world”) is evaluated and the result (“HELLO WORLD”) assigned to the variable foo and then displayed to field1 and field2.

Whilst we could on selection of a language, change what we can identify as static text in forms, we could not change the dynamic text on forms, or the data held in the underlying programs variables that has already been evaluated.

What Genero does have is a method that allows you to switch language at the BEGINNING of a program. The base.Application.reloadResources method will overwrite the search path defined by FGLRESOURCEPATH . So any time after that, when a localized string file is loaded, the new path will be used. At the beginning of an application you can therefore  …

• explicitly prompt the user what language they would like to use
• OR use a frontcall to determine the language. The feInfo front-call with the userPreferredLang argument will query the front-end for the users preferred language as indicated somewhere on the front-end (varies between desktop, web, mobile)
• OR pass in the preferred language via parameter/header/cookies etc

… and then call base.Application.reloadResources() to switch FGLRESOURCEPATH so that future loads of the string .42s files are from the appropriate directory.  Just note that the module that has the base.Application.reloadResources() will already have been loaded so this module and any other modules loaded at this point  should be kept to a minimum.

In summary don’t expect to be able to switch language mid application.  Consider adding the ability to switch language at beginning of program by having a small module at the start that then calls base.Application.reloadResources based on the users selected language before the bulk of the program is loaded.  If you have a main menu or portal you may put the language selection there so that applications are launched with the desired language.  You could if you like experiment with code that changes static labels in forms but there would still be the problem of what about variables in memory that have already been evaluated and dynamic labels on forms.