next »

[Reuben B.]

Using SFMT you can cut down on the number of localized strings required.  Instead of O(m*n) strings, you can use it to have O(m+n) strings.

By using SFMT, the technique also caters for linguistic inversion where the order of terms in a sentence structure may vary between different languages.

Read more at https://4js.com/ask-reuben/ig-80/

[Rene S.]

Good morning Reuben,

You name your way of using localized strings "best practice". This is your personal taste.
I have a different one. It's also personal taste.

The idea of localized string (aka %string-literal) is: have an equivalent to the C's gettext.

Teach yourself man -a gettext.


Typically a C source looks like:
   

Code

#include <libintl.h>
void func1(){
	puts("Good morning"); 		// not localizable
	puts(_("Good morning")) 	// this string will be translated.
	puts(gettext("Good morning")) 	// same as above
}
 

The 4GL equivalent is:

Code

 
FUNCTION func1()
	DISPLAY "Good morning"		-- not localizable
	DISPLAY %"Good morning"		-- this string will be translated.
	DISPLAY LSTR("Good morning")	-- same as above
END FUNCTION
 

Best practice (my personal point of view) of using the string localization is:

   Use the default human visible string as message-id.

This implies:

* your source code remains readable.
* Any program works out of the box without any localization file when using the default language.

What is really missing:
A way for the form compiler to mark automatically any label in a SCREEN or GRID, or a column title (and so on) as localizable.

Example:

Code

SCREEN
{
[l_first_name ][first_name]
[l_last_name  ][last_name ]
}
 
ATTRIBUTES 
	first_name = FORMONLY.first_name;
	last_name = FORMONLY.last_name;
	LABEL l_first_name: TEXT = %"First name";
	LABEL l_last_name: TEXT = %"Last name";
 

This should be enough:

Code

SCREEN
{
First name [first_name]
Last name  [last_name ]
}
 
ATTRIBUTES 
	first_name = FORMONLY.first_name;
   	last_name = FORMONLY.last_name;
 

Rene

[Sebastien F.]

Rene,

There are pros and cons with both solutions.

For ex, your preferred solution implies that the localized string keys depend from the locale charset using during development:

If I code my French application in ISO-8859-15 for ex, with Latin characters like in Forêt, it makes my code and .42m dependent to this locale.

So if I write

DISPLAY %"Dans la forêt"

it produces a localized string key that is charset dependent, and pcode that is dependent to that locale.

And you can't use these .42m modules to run on UTF-8 ...

However, this is not an issue with English, since all chars are typically ASCII-7.


Small texts such as

DISPLAY %"OK"

may need different translations in other languages depending on the context, so in this case one has to use a more precise key such as:

DISPLAY %"common.ok.1"
DISPLAY %"common.ok.2"

Anyway, programmers can choose the solution they want and this is fine.

There are more pros and cons are described here:

https://4js.com/online_documentation/fjs-fgl-manual-html/#fgl-topics/c_fgl_localized_strings_best_practices.html


Discussed a while ago:

What is also missing is to compile .42m in a common locale (UTF-8), and be able to execute in any locale.

1) Code source in ISO-8859-15
2) Compile ISO-8859-15 to get portable .42m in UTF-8
3) Run in UTF-8 or ISO-8859-15

However this has a cost of conversion at runtime so maybe not a good idea.


Seb

[Reuben B.]

Good morning Reuben,

You name your way of using localized strings "best practice". This is your personal taste.
I have a different one. It's also personal taste.
...

I just want to correct you.  I linked to a page whose title was "best practice", I did not name what I suggested best practise. (although if I was starting from scratch a lot of what is there is my starting point)

Anything in Ask Reuben is not a "you must do this" but should be treated as a "you can do this"  and is typically something you should take into your decision making processes and consider the pros and cons for your individual requirements.

With localization you have to consider factors such as ...

readability of code
volume of entries to translate
quality of translated product
functionality of your application

Utilising SFMT will allow you to cut down on entries to translate, and increase the functionality of your application (i.e. allowing you to choose between interchangeable terms e.g. Product/Item/Stock/SKU,  Branch/Warehouse/Store) but that may come at a cost of making the code slightly less readable.

You also tend to be scarred by bad experiences.  I have seen strings file that needed translating that had lots of duplicates because there were entries such as "Password", "Password:", "&Password".  Similarly abbreviations leads to lots of duplicates "Account Closed", "Acct Closed", "Act Closed", "A/c Closed",  "Acct Clsd", "Acct Cl", "A/C Cl" etc.  In both cases the same entries being translated multiple times.  With the m*n cases, I am thinking how can this be m+n entries to translate instead.

A little bit of investment and thought at the beginning can save you down the line.