Easy translation

[Egor]

I started translation SugarCRM lang files into Russian and found out that I had to repeatedly translate identical strings (for example, Contacts, Accounts, etc.) again and again in different lang.php files in different module directories. Being a pretty tired of typing the same words a lot of times I wonder if there is “an easy way” to make a translation. I think this could be done by using an utility that searches files in directories recursively for given string and replaces it into what user wants. Can somebody recommend such utility if exist? Are there any similar utility under Windows of Linux (windows version more preferred)?

[clint]

I use the "Advanced Search and Replace" utility for Windows. It's very powerful and makes the task you just outlined very simple.

You can find it at http://www.abacre.com/afr/

By the way, starting with v2.5 coming out this week, all language pack files need to be saved in UTF8 file encoding. Our new charting engine built in Flash technology and coming out in 2.5 needs the UTF8 encoding in order to properly display characters from every char set.

For instance in Windows Notepad, when I click Save As, I'm given an Encoding dropdown of different char set encodings. For all lang pack files, you will need to select UTF8.

Regards,

[Egor]

Thanks, clint!

[gremln007]

I use the "Advanced Search and Replace" utility for Windows. It's very powerful and makes the task you just outlined very simple.

You can find it at http://www.abacre.com/afr/

By the way, starting with v2.5 coming out this week, all language pack files need to be saved in UTF8 file encoding. Our new charting engine built in Flash technology and coming out in 2.5 needs the UTF8 encoding in order to properly display characters from every char set.

For instance in Windows Notepad, when I click Save As, I'm given an Encoding dropdown of different char set encodings. For all lang pack files, you will need to select UTF8.

Regards,

Clint

Are you guys getting away from GD for the charting?

Jonathan

[clint]

Yep. The GD library is no longer required for 2.5. The new charting engine is entirely client-side and uses Flash.

Regards,

[slipjack]

Yep. The GD library is no longer required for 2.5. The new charting engine is entirely client-side and uses Flash.

Regards,

Hello Clint,

I'm new to Sugar CRM, but I heard it might have what I need. I am most likely going to be building some Real Estate tools, and Sugar may be a way to get started.

I was planning on using Flash for my chart/graphing. How flexible will the Flash part be in Sugar?

Thanks!

[malcolmh]

Hi,

are there any plans to move the language components (selection items as well as normal text) out of the files into database tables? I don't know what performance implications if any this would have. Would this be possible using PHP?

I have made some modifications to the german language version and foresee quite a bit of effort when migrating from version 2.0 to version 2.5.

With a database/table approach it would be easier to select and modify identical text strings and if designed correctly would not kill any local site modifications. A suggested table structure could look something like this (although it is a long time ago since I did any programming or DB design work) :

Language Code
Module Code
Field Name
Field Type
Active Code (whether field is to be displayed or not)
Text Index (for selection boxes, check boxes etc.)
Text Original
Text Current (if text current available use this, otherwise use text original)
Default Value (for selection fields)

With a few additional admin screens for modifying the values, this would make translations and general customizing effort a lot easier. What do you think ?

Cheers Malcolm

[clint]

Hi Malcolm -

We hadn't been considering any changes to our language pack mechanism as we thought it was working well for everybody.

Were you aware of the <prefix>.lang.override.php mechanism? Whenever we load a lang file, we also load the override file to load in any modifications made to the language pack. You can safely put any changes into the override file and we will never stomp on those override files as we release patches and major revisions.

For instance, you want to modify the US English drop down list of case statuses from the out of the box values to include a new status of "In Review".

• The original values are set in include/language/en_us.lang.php and are:
  'case_status_dom' =>
  array (
  'New' => 'New',
  'Assigned' => 'Assigned',
  'Closed' => 'Closed',
  'Pending Input' => 'Pending Input',
  'Rejected' => 'Rejected',
  'Duplicate' => 'Duplicate',
  ),
• To safely modify these values, create a new file called include/language/en_us.lang.override.php and set its contents to be:
  <?php
  $app_list_strings['case_status_dom'] =
  array (
  'New' => 'New',
  'Assigned' => 'Assigned',
  'Review' => 'In Review',
  'Closed' => 'Closed',
  'Pending Input' => 'Pending Input',
  'Rejected' => 'Rejected',
  'Duplicate' => 'Duplicate',
  );
  ?>

Note that you can add or remove drop down values and that the key stored in the database (in this case "Review") does not need to match the display value ("In Review").

And as stated above, these changes will carry forward from release to release as we never will distribute a en_us.lang.override.php file.

Regards,

[malcolmh]

Hi Malcolm -

We hadn't been considering any changes to our language pack mechanism as we thought it was working well for everybody.

Were you aware of the <prefix>.lang.override.php mechanism? Whenever we load a lang file, we also load the override file to load in any modifications made to the language pack. You can safely put any changes into the override file and we will never stomp on those override files as we release patches and major revisions.

For instance, you want to modify the US English drop down list of case statuses from the out of the box values to include a new status of "In Review".

• The original values are set in include/language/en_us.lang.php and are:
  'case_status_dom' =>
  array (
  'New' => 'New',
  'Assigned' => 'Assigned',
  'Closed' => 'Closed',
  'Pending Input' => 'Pending Input',
  'Rejected' => 'Rejected',
  'Duplicate' => 'Duplicate',
  ),
• To safely modify these values, create a new file called include/language/en_us.lang.override.php and set its contents to be:
  <?php
  $app_list_strings['case_status_dom'] =
  array (
  'New' => 'New',
  'Assigned' => 'Assigned',
  'Review' => 'In Review',
  'Closed' => 'Closed',
  'Pending Input' => 'Pending Input',
  'Rejected' => 'Rejected',
  'Duplicate' => 'Duplicate',
  );
  ?>

Note that you can add or remove drop down values and that the key stored in the database (in this case "Review") does not need to match the display value ("In Review").

And as stated above, these changes will carry forward from release to release as we never will distribute a en_us.lang.override.php file.

Regards,

Hi Clint,

thanks for the hints for ensuring that text modifications are carried over from one version to another. I will give it a try. As Egor points out though, multiple files need to be found and changed, this process needs to be simplified. Maybe Vers. 2.5 offer some functionality here.

To be successful SugarCRM needs to appeal to a much wider audience, who have very little if any programming knowledge.
With this aim in mind, field and module customizing/enhancing, language customization/enhancing needs to be simplified. Various competitors offer such functionality, especially the hosted CRM solutions.

I feel after Version 2.5 has been released, this question needs to be addressed to the community and a wider audience.

Keep up the great work!

Cheers Malcolm

[clint]

Here's a screenshot of the new dropdown editor coming in 2.5.