Skip to main content

Many years ago we changed our web-based software to support prompts, menu items, and help to support multiple languages. We did that by using a number for the prompt like 2300 was "Customer Name". Depending on the language you would go to the matching language file to translate the 2300 number to "Nombre cliente" for Spanish and "Nom du client" in French for example.

In the 18 years we have demoed this to United States-based companies nobody expressed any interest until last week. This  client would like to have code files like 

  • Code A1 equals Apple or Pomme in Spanish
  • Code Z1 equals Avacado or Avocat in Spanish

Our Universe database has a file called Fruits in this example. So my questions for those who have done this are:

  • Do you add a field for every language?
  • Do you add a multivalue field for every language?
  • Do you change the value in the file to a number and translate it to a language field?
  • Do you add a file called Fruit_ES for Spanish?
  • Depending on the method chosen, how does a SELECT Fruits work for each language?

Regards,

Doug

Last auto-saved at 09-06-2024 15:06



------------------------------
Doug Averch
Owner
U2 Logic
------------------------------

Many years ago we changed our web-based software to support prompts, menu items, and help to support multiple languages. We did that by using a number for the prompt like 2300 was "Customer Name". Depending on the language you would go to the matching language file to translate the 2300 number to "Nombre cliente" for Spanish and "Nom du client" in French for example.

In the 18 years we have demoed this to United States-based companies nobody expressed any interest until last week. This  client would like to have code files like 

  • Code A1 equals Apple or Pomme in Spanish
  • Code Z1 equals Avacado or Avocat in Spanish

Our Universe database has a file called Fruits in this example. So my questions for those who have done this are:

  • Do you add a field for every language?
  • Do you add a multivalue field for every language?
  • Do you change the value in the file to a number and translate it to a language field?
  • Do you add a file called Fruit_ES for Spanish?
  • Depending on the method chosen, how does a SELECT Fruits work for each language?

Regards,

Doug

Last auto-saved at 09-06-2024 15:06



------------------------------
Doug Averch
Owner
U2 Logic
------------------------------

Hi

We are Working with many language.

Always 'text' are defined like this

F1 mved language codes
F2 mved your text (sometimes subvalued)

Then

1/User is associate with a langage code (common var at login)

2/ We define a dict itype to show/use the value of the user's language code (raise())

Each access are done through the itype

I hope this help
Manu





Manu


Many years ago we changed our web-based software to support prompts, menu items, and help to support multiple languages. We did that by using a number for the prompt like 2300 was "Customer Name". Depending on the language you would go to the matching language file to translate the 2300 number to "Nombre cliente" for Spanish and "Nom du client" in French for example.

In the 18 years we have demoed this to United States-based companies nobody expressed any interest until last week. This  client would like to have code files like 

  • Code A1 equals Apple or Pomme in Spanish
  • Code Z1 equals Avacado or Avocat in Spanish

Our Universe database has a file called Fruits in this example. So my questions for those who have done this are:

  • Do you add a field for every language?
  • Do you add a multivalue field for every language?
  • Do you change the value in the file to a number and translate it to a language field?
  • Do you add a file called Fruit_ES for Spanish?
  • Depending on the method chosen, how does a SELECT Fruits work for each language?

Regards,

Doug

Last auto-saved at 09-06-2024 15:06



------------------------------
Doug Averch
Owner
U2 Logic
------------------------------

Hi Dough, how are you?

  In the Aleph MV Framework, this is solved using a component we name "Enums". Enums are small code-text tables, like order status, item types, etc. The fruits code-text file you mention may fall into this category. With Enums, the framework displays the text (OCONV) but stores the code (ICONV). 

  As every other component of an Aleph web application, Enums can be internationalized. I18N works with Locales. A locale is a country code that defines language and formats for date, currency, etc. You internationalize a web application providing translations for web menu items, forms controls, enums, and messages for all the locales you want to support. A default locale is defined for the application, but users may have customized locales.

  In the example you mentioned, A1 would be displayed as "Apple" in US (Lang=en) but as "Manzana" in Argentina (Lang=sp), but in both cases A1 will be written to the Universe file.

  Hope this helps, and do not hesitate to contact me if you want.

  Saludos,

  Enrique



------------------------------
Enrique Ignacio Murphy
Software Engineer
Aleator Software - RN40 Software
Argentina
------------------------------

Many years ago we changed our web-based software to support prompts, menu items, and help to support multiple languages. We did that by using a number for the prompt like 2300 was "Customer Name". Depending on the language you would go to the matching language file to translate the 2300 number to "Nombre cliente" for Spanish and "Nom du client" in French for example.

In the 18 years we have demoed this to United States-based companies nobody expressed any interest until last week. This  client would like to have code files like 

  • Code A1 equals Apple or Pomme in Spanish
  • Code Z1 equals Avacado or Avocat in Spanish

Our Universe database has a file called Fruits in this example. So my questions for those who have done this are:

  • Do you add a field for every language?
  • Do you add a multivalue field for every language?
  • Do you change the value in the file to a number and translate it to a language field?
  • Do you add a file called Fruit_ES for Spanish?
  • Depending on the method chosen, how does a SELECT Fruits work for each language?

Regards,

Doug

Last auto-saved at 09-06-2024 15:06



------------------------------
Doug Averch
Owner
U2 Logic
------------------------------

Manu,

Just another option, have a multi-flle where each sub-file is for a specific language. Using this technique with a  PRODUCT file you could open and re-use the language-specific sub-file without having langiage-specific code scattered - e.g. "PRODUCT_CODES,FRENCH" or "PRODUCT_CODES,SPANISH" and read the required.data with the same record key.

For example, if the language is FRENCH then the code envelope could be something like:

LANGUAGE="FRENCH"
OPEN "PRODUCT_ NAMES,":LANGUAGE TO F.PRODUCTNAMES ELSE ......
...
...

READV R.PRODUCT.NAME FROM F.PRODUCTNAMES,PRODUCTCODE,1 ELSE.....

in this example the product code is the key to the langiage subfile to be used for all canned text such as the product name, and attribute 1 is the text name.

Regards

JJ



------------------------------
John Jenkins
Thame, Oxfordshire
------------------------------

Manu,

Just another option, have a multi-flle where each sub-file is for a specific language. Using this technique with a  PRODUCT file you could open and re-use the language-specific sub-file without having langiage-specific code scattered - e.g. "PRODUCT_CODES,FRENCH" or "PRODUCT_CODES,SPANISH" and read the required.data with the same record key.

For example, if the language is FRENCH then the code envelope could be something like:

LANGUAGE="FRENCH"
OPEN "PRODUCT_ NAMES,":LANGUAGE TO F.PRODUCTNAMES ELSE ......
...
...

READV R.PRODUCT.NAME FROM F.PRODUCTNAMES,PRODUCTCODE,1 ELSE.....

in this example the product code is the key to the langiage subfile to be used for all canned text such as the product name, and attribute 1 is the text name.

Regards

JJ



------------------------------
John Jenkins
Thame, Oxfordshire
------------------------------

Hi John,

Yes, of course.
It's the method used by  SB+ Multi-Language of the app's texts. 
But for data's texts, we evaluated it much more cumbersome to execute, maintain, copy, transfer, update if all  are multilingual.

There is a many road to go to Rome


With kind regards
Manu 



------------------------------
Manu Fernandes
------------------------------

Hi John,

Yes, of course.
It's the method used by  SB+ Multi-Language of the app's texts. 
But for data's texts, we evaluated it much more cumbersome to execute, maintain, copy, transfer, update if all  are multilingual.

There is a many road to go to Rome


With kind regards
Manu 



------------------------------
Manu Fernandes
------------------------------

Manu,

Very true indeed.

JJ



------------------------------
John Jenkins
Thame, Oxfordshire
------------------------------