GenoPro Support Forum

2) and the other way round:

This is because the system picks up the error data from within the Dic selected for the Rep Lang.
To avoid this, i.e. to keep a consistant Lang for these Log Msgs, I suggest to move/transfer the 28 <Error.../>, the 5 <Warning.../> and the 6 <Parameters.../> elements from the Dic(s) to the Genopro Lang pack(s).
JC

Edited: Friday, May 9, 2008 by jcguasp

I think this may be prove to be a little restrictive. I would be difficult to introduce new report revisions or new reports between GenoPro versions.

I suggest that Dictionary.xml files are renamed Dict<langcode>.xml (e.g. DictEN.xml) and be moved to a sub-folder called say Config. Then all available dictionaries for a report can be held in the one folder. If GenoPro makes available a new Property ReportGenerator.BaseLanguage that returns the GenoPro language then the report script can choose the appropriate language. This will be easier if the Dictionary methods are extended to have a 'version' param. that can be set to 'base' or 'skin' ('skin' is default) . Then we can write:

The property ReportGenerator.SkinLanguage was designed for that purpose, allowing a script to make runtime decisions about the selected language.  Most of the time fetching the text from Dictionary.xml is enough, however sometimes the script may need to perform extra processing for a language.

The current architecture of the report generator must be upgraded to handle multiple languages.  The report generator of GenoPro 2007 uses an architecture written in 2004, which is far superior to its previous report architecture written in year 2000 (introduced with GenoPro 1.90).  Back in year 2004, I was considering scrapping the report generator because of the amount of work involved and the delay of "GenoPro 2.0" (for those who remember the name).  The goal was using a scripting language such as VBScript or JavaScript to make it easier for users to customize their report, since there is no need to document the syntax of those well known scripting languages.  I had no idea how and where the report generator would go.  Thanks to Ron, GenoPro now provides incredible reports, which has stimulated the need for further improvements, including the need for localization and providing storage for parameter configuration settings.

This problem described above is somewhat similar as Wrong language for Configuration Setting popup menu.  What GenoPro will have is an .xml file for each language...

Edited: Friday, May 9, 2008 by GenoProSupport

Having reread the other post relating to this issue, it appears to me that text displayed whilst generating a report, such errors, warnings and comments must be stored separately to the text used in the report itself, as suggested by jcguasp. I now suggest that they be stored along with the config parameter descriptions, perhaps in a section GenerationMessages. Then GenoPro should localize these texts in a similar way to that proposed for configuration parameter descriptions and help tips. The report generator will require new method(s) to access these, or modify the existing Report.LogError/Warning/Comment. The message content can be either plain text or a Report Generator phrase with arguments, and so the method(s) need to cater for this.