Subscribe for automatic updates: RSS icon RSS

Login icon Sign in for full access | Help icon Help
Advanced search

Pages: [1]
  Reply  |  Print  
Author Topic: Ask Reuben 80 - Localization Inversion  (Read 463 times)
Reuben B.
Four Js
Posts: 834


« on: June 18, 2021, 05:29:36 am »

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/

Product Consultant (Asia Pacific)
Developer Relations Manager (Worldwide)
Author of https://4js.com/ask-reuben
Contributor to https://github.com/FourjsGenero
Rene S.
Four Js
Posts: 95


« Reply #1 on: June 18, 2021, 12:52:29 pm »

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
  1. #include <libintl.h>
  2. void func1(){
  3. puts("Good morning"); // not localizable
  4. puts(_("Good morning")) // this string will be translated.
  5. puts(gettext("Good morning")) // same as above
  6. }
  7.  
The 4GL equivalent is:

Code
  1.  
  2. FUNCTION func1()
  3. DISPLAY "Good morning" -- not localizable
  4. DISPLAY %"Good morning" -- this string will be translated.
  5. DISPLAY LSTR("Good morning") -- same as above
  6. END FUNCTION
  7.  

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
  1. SCREEN
  2. {
  3. [l_first_name ][first_name]
  4. [l_last_name  ][last_name ]
  5. }
  6.  
  7. ATTRIBUTES
  8. first_name = FORMONLY.first_name;
  9. last_name = FORMONLY.last_name;
  10. LABEL l_first_name: TEXT = %"First name";
  11. LABEL l_last_name: TEXT = %"Last name";
  12.  
This should be enough:

Code
  1. SCREEN
  2. {
  3. First name [first_name]
  4. Last name  [last_name ]
  5. }
  6.  
  7. ATTRIBUTES
  8. first_name = FORMONLY.first_name;
  9.   last_name = FORMONLY.last_name;
  10.  

Rene
Sebastien F.
Four Js
Posts: 465


« Reply #2 on: June 18, 2021, 02:31:50 pm »

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.
Four Js
Posts: 834


« Reply #3 on: June 28, 2021, 02:53:03 am »

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.

 





Product Consultant (Asia Pacific)
Developer Relations Manager (Worldwide)
Author of https://4js.com/ask-reuben
Contributor to https://github.com/FourjsGenero
Pages: [1]
  Reply  |  Print  
 
Jump to:  

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines