next »

[Huy H.]

I found a toping in FourJs document on how to localize system runtime messages:

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

My problem with this approach is that the localization files have to be inside the $FGLDIR somehow.  If each time we update the BDL, the resources need to be copied/symlink somehow.  Has anyone found a way to do this without touching $FGLDIR? 

My preference if this somehow works like the regular localization files by using the $FGLRESOURCEPATH environment variable.

[Sebastien F.]

Hello!

We have a long-standing FGL ticket for that:

     https://4js.com/support/issue/?id=FGL-03825#startissue

One of the solution I suggested is based on localized strings, by using reserved string identifiers based on the .msg message number.

You could translate / customize messages in your .str/.42s file(s):

"fgl.dialogMessage.error:-1205" = "Invalid month"

That would only apply to error messages displayed by dialogs (an invalid month used in a LET statement with a DATE variable would still produce the FGLDIR/msg message)

Would that fit your expectations?

Seb

[Huy H.]

Hi Seb. That is exactly what we're looking for.

While the steps provided in the documentation works, but it is not ideal for a couple of reasons:

1. We have to modify and manage the $FGLDIR/msg directory
2. We have to set LANG=fr_CA
 
We have always run our application using LANG=en_US, and any localization thus far has been done via FourJs standard localization standard.  Moreover, our application is bilingual (English and French), having to switch LANG just to support localization can lead.  My worry of setting LANG=fr_CA could introduce other undesirable results.
 

[Sebastien F.]

Hello!

We have an internal debate about the naming convention to use for the string keys for these dialog error messages:

Naming Convention A: Use localized string key that matches the English text of the FGLDIR/msg message:

"Invalid month in date." = "Invalid month in date."
"Error in field." = "Error in field."
"This field requires an entered value." = "This field requires an entered value."

Pros:
- Simple to read / understand / translate

Cons:
- You must define the key with the exact same text as in the default .msg message: Note the dot at the end of "Error in field." ...
- Risk to clash with existing user-defined localized strings: ANY localized string in the application with such key would be translated with the defined text - you could not distinguish dialog error messages in the context of dialog, from application messages/texts.
- That would use a new FGL-system messages convention for keys (we have already string key names in FGLDIR/src/default.str):
    "fgl.helpViewer.title" = "Help"


Naming Convention B: Use a strict-formatted key name, using the fgl.dialogMessage.error: prefix and the error number (as described in the previous answer):

"fgl.dialogMessage.error:-1204" = "Invalid year in date."
"fgl.dialogMessage.error:-1205" = "Invalid month in date."
"fgl.dialogMessage.error:-1206" = "Invalid day in date."

Pros:
- Unique FGL-specific localized string key value, that cannot clash with existing user-defined localized strings.
- This is consistent with existing FGL-system localized strings of FGLDIR/src/default.str:
    "fgl.helpViewer.title" = "Help"

Cons:
- More cryptic key name (needs indirection to .msg error definition for translations)
  However, there are not many error/info messages.


If a localized string is not defined for dialog messages, the legacy .iem error messages from FGLDIR/msg will be used.


Note that these localized string keys would only be used in dialog instructions:
Compilation and runtime errors like
  -1338 "The function '%s' has not been defined in any module in the program."
are not concerned by this mapping.

Can you please tell us what would be your preferred localized string key naming convention?

Any feedback is welcome.

Seb

[Rene S.]

Hello, It's mostly a question of personal taste.

That's why: This answer reflects my personal taste.

My recommendation/best practice: The key is always the default text. As posted by Sebastien's "Convention A".

In best case: the program runs completely using the default language without any string mapping file.

BTW: teach yourself like other software is doing. Example: Wordpress (the sources are public). The very huge of localization mappings is using "Canvention A". The source code contains the English default.

Rene

[Sebastien F.]

Hello Rene,

I am convinced we should do convention B for the FGL dialog error messages to avoid any conflicts, and let customers use A or B as they wish.

Seb

[Leo S.]

Another vote for option A.
It's tedious to invent a rather cryptic key if the error message can be described already in a natural source language (english in this case).
Regards, Leo

[Rene S.]

Hello Rene,

I am convinced we should do convention B for the FGL dialog error messages to avoid any conflicts, and let customers use A or B as they wish.

Seb

I wonder: dialog error messages using localized strings - that's new to me. Why do you discuss a POC of a bugfix/feature fix here?
Rene

[Huy H.]

Appreciate the thought that goes into implementing something like this.  As Rene has alluded to, it comes down to personal taste...

With our application, we've been using convention B for most of our localization.  So from the consistency point of view, this is our preferred choice.  The Pros with this as well is that it matches the .msg definition, providing some level of consistency.

Having said that, if we can do it all over again, I would properly prefer option A -- as that would make things alot more readable in the code.

[Reuben B.]

BTW: teach yourself like other software is doing. Example: Wordpress (the sources are public). The very huge of localization mappings is using "Canvention A". The source code contains the English default.

I think most sources have localization as an after thought and "Convention A" is the path of least resistance to go from a code base that had no original intent of being localized to one that is.

In the 90's we added localization to our 4gl application by taking any strings in the code we wanted translated and did this by adding special tokens to indicate translation should occur e.g. "Product Code" became "{ProductCode}" and a pre compilation step in our makefiles found strings of the form "{...}" to do the translation at compile time.  A lot of this could be scripted.  (and then when we went to Genero, scripts transformed "{ProductCode}" to %"ProductCode"

Implementing Convention B would have required more manual effort and thus been more costly in terms of time and dollars to change the existing sources.

I don't think you can say Convention A is best because you see other sources that use Convention A. You don't know what factors led to them getting there.

Convention A has its own issues in terms of how to handle near duplicates and abbreviations e.g. (ACCOUNT CODE vs Account Code vs Acct Code vs Acc Code vs Acc Cd vs A/C vs AC etc) , long blocks of text (do you give it a short token?, if so what is the cutoff length), what if text has special characters (what is delimiter, how do you delimit the delimiter),  how to handle changes in text (do you change just the translation or token as well, how do you find all instances). 

Personally if starting from scratch I would go down Convention B but using meaningful and structured tokens

"error.type.date.invalid.year" = "Invalid year in date"
"error.type.date.invalid.year" = "Invalid month in date"
"error.type.date.invalid.year" = "Invalid day in date"

or even better (see https://4js.com/ask-reuben/ig-80/ for why)

"error.type.date.invalid" = "Invalid %1 in date" 

but we aren't going from scratch.

Reuben

[Sebastien F.]

Hello,

It's interesting to get all these opinions about convention A or B, thanks.

To me, Genero programmers are free to use A or B, that's all in your hands.

But keep in mind that the initial problem is to simplify the localization of error messages that can be displayed during a dialog, such as "Error in field." .
Without affecting existing code.

I am still convinced we go the wrong path if we use convention A for these dialog error messages.

I don't see the problem to have some cryptic string key names for these, when it guaranties that these cannot enter in conflict with user-defined application messages, that may already exist.

About the default text, if the localized strings are not defined: Of course it would fall back to the regular .msg/.iem (English) messages.

Seb