Purpose

Translatable Text comes from language *.mo files compiled from the translated empty.po files named according to your language. Strings in database tables that populate drop-down boxes and some labels do not get translated from the *.mo files without code change and .mo file re-compilation with all such strings.

All the user interface is subject to translation, so FA user sending out an invoice in Germany can have messages in German. The document printout language is defined on target basis (e.g. for invoices you can set document language per customer branch). But unfortunately FA does not natively support multi-language texts stored in database, so e.g. item names will not not be translated.

The Chart of Accounts script should have been translated from the beginning in the table itself.

Refer Forum Post

Procedure

All the strings in database are user defined, so we cannot add them to *.po/*.mo file, because we don't know what the content of your database tables are. You can do it yourself if you have enough time for it:

  1. Add the strings from your database tables you want translated to all *.po language files you like
  2. Translate them into the *.po files and generate *.mo files
  3. Find all places in sources where the strings displayed need to be translated, and add _() calls over respective variable/expression.
  4. Encapsulate the translated texts with sprintf() using s (strings) as place holders for non translated parts.

Some files that contain such translatable texts coming from database tables are:

  • manage/gl_account_types.php
  • includes/ui/ui_lists.inc

If the translated text is empty, the entire .mo file gets returned! Hence do an empty check like: 

    label_cell($empty(trim($parent_text)) ? "" : _($parent_text));//   here the _() is put

Combo Box Translation

Example: includes/ui/ui_lists.inc Lines 187-194: 

		while ($contact_row = db_fetch($result)) {
			$value = $contact_row[0];
			$descr = $opts['format']==null ?  $contact_row[1] :
				call_user_func($opts['format'], $contact_row);
			$sel = '';
 		 	if (get_post($search_button) && ($txt == $value)) {
 		 		$selected_id[] = $value;
 		 	}

can become: 

		while ($contact_row = db_fetch($result)) {
			$value = $contact_row[0];
			$contact_row[1] = _($contact_row[1]);   //   this line is added
			$descr = $opts['format']==null ?  $contact_row[1] :
				call_user_func($opts['format'], $contact_row);
			$sel = '';
 		 	if (get_post($search_button) && ($txt == $value)) {
 		 		$selected_id[] = $value;
 		 	}

The entries for the first 2 entries in the chart_types table can be translated for example into Norwegian in the .po file like: 

#: from table chart_types
msgid "Current Assets"
msgstr "Omløpsmidler"

#: from table chart_types
msgid "Inventory Assets"
msgstr "Anleggsmidler"

and compiled into .mo file and used.

Possible Method for Direct Integration into FA

To fix this you need to introduce a country table and add the different translations to the appropriate tables so that these messages can be written in the language of the user.