This content has been marked as final. Show 14 replies
You can override the base error messages in the translat.ini file, however this is not recommended for two reasons:
1) The base error messages may not provide the same inputs as your custom error message, and as such you would not be able to get a meaningful message
2) Similarly, your custom error message may not provide the same outputs as the base message, and you may have difficulty when contacting Oracle Support.
Can you post your custom translat.ini entries, and let us know what base rule you are using in 11.5 that you wish to modify?
Thanks for your reply. However, we are not overriding messages that already exist in the file. We are just making addition to the file to include our custom error code messages. For example we have added the 50000 range in the translate.ini for our custom error codes, which applies to our custom rules that we have written. In the base translat.ini file the 50000 range doesn't exists.
Sorry for not being very clear on my question. See if I can explain it better. I have a custom rule that we have written and added to the system. We will call this custom rule, CUSCustomerRule1. In this rule I have the following
if ((ptr2 = GENStrDelimMatch(ptr)) == NULL)
RPErrorProc(pRPS, (WORD)EMIT_ERROR, (DWORD)53002,
The error code you see above, 53002, is our custom error code. We add the translated message to the translat.ini file. In 11.3 this code does get translated if the "IF" condition in true. In 11.5, eventhough we have added the translated message for 53002 to the translat.ini file, i get the following message:
"Message number 53002 not specified in translation file."
No matter where I place the translat.ini file it will not recognize my entry.
I believe the 11.5 system is using some other file to translate the error code into a readable message.
Already verified that. My path to translat.ini file is correct. One experiment I just did was delete all occurrences of the translat.ini file from my computer, ran a sample cycle, and looked in the error file and saw that Oracle base codes were still being translated iinto the readable message. Where did the system get this if I had no translat.ini file on my computer.
You should see these errors when your translat.ini is missing:
[03:22:16PM] Error: Company - LOB - Transaction
[03:22:16PM] Error: Message number 12041 not specified in translation file.
[03:22:16PM] Error: Company - LOB - Transaction
[03:22:16PM] Error: Message number 12126 not specified in translation file.
[03:22:16PM] Error: An error occurred during processing.
My fsisys.ini has the followings (also make sure your fsiuser isn't overriding this entry)
[ Data ]
TranslationFile = translat.ini
I did a little poking around in support files and it turns out they've done some work in the area of globalization for error messaging. You'll want to check out chapter 7 of this document http://download.oracle.com/docs/cd/E16256_01/rp_book.pdf if you haven't already.
Finally, you may want to have a look at the SysInternals tool procmon http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx You can set it up with a filter on Process Name starts with GEND and Path contains translat.ini, and then execute your Documaker run. It will tell you which translat.ini is being pulled in.
I spoke with some folks in Product Development and Documaker now uses a DLL provided by Oracle for multiple language support. There is a utility provided by Oracle that will translate the translat.ini (sorry about the pun) into a MMP file which is used by the DLL. I will get more information on this utility and repost here when I get it.
Edited by: Andy Little on Aug 12, 2010 9:40 AM
Thanks very much Andy.
I looked in the document you referenced and found the following note. I am posting it here to be useful to other people.
Note: The TRANSLAT.INI file was designed to let you to translate output messages. Beginning with version 11.5, this file is being migrated to work through the Oracle national language support (NLS) interface. As a part of this migration, the TRANSLAT.INI file is now compiled into a message binary file (.MSB), which is stored in the \Lang subdirectory of your executables directory. The English US translation is in the XLTUS.MSB file. As demand warrants, output messages from the TRANSLAT.INI will be translated into additional languages and compiled into additional .MSB files. The expected format of NLS messages differs slightly from the format of messages within the TRANSLAT.INI file. To complete the interface, the TRANSLAT.MNP file is used to internally map the message parameters.
Also, when you find this utility to compile the Translat.ini file into the message binary file please let me know. I will definitely need this since we have many custom error codes\messages we need to add.
Under 11.5, Documaker uses Oracle's globalization standards for messaging. The translat.ini file isn't strictly used at runtime, rather, a compiled binary version that is language-specific is used instead. To generate the compiled binary version, there are some steps to be followed.
The first thing you will need is the LMSGEN utility from Oracle's NLSRTL package. Currently this is distributed with Oracle database SDKs. I don't have any more specific information than that right now. Here is a bit more info on this utility http://download.oracle.com/docs/cd/B19306_01/server.102/b14225/ch10oci.htm#i1007610
Once you have LMSGEN installed and ready, you need to convert your translat.ini into an intermediary MSG and MMP files. You can create a script that will translate your translat.ini file and create these files for you. It's a relatively simple process:
1000 = &E&: Error: Requested library <&LIB&> not available or cannot be loaded.
1001 = &E&: Error: Use of rule or function <&NAME&> requires a printer classification of <&CLASS&>.
1000, 42, "%1: Error: Requested library <%2> not available or cannot be loaded."
1001, 42, "%1: Error: Use of rule or function <%2> requires a printer classification of <%3>."
The MMP file is a token/parameter mapping file, since the old translat.ini uses tokens, and Oracle's globalization framework uses parameters. Note the top line in the translat.msg file -- this is required!
The format of the INI file:
msgNumber = &TOKEN&: Message with &TOKEN&
The format of the MSG file:
msgNumber, msgType [42=Error,0=Info], "Message with %1 parms"
Format of the MMP file:
Once you have the MSG file, then use the LMSGEN utility from Oracle's NLSRTL package to converts that into an MSB file. The MSB file is a compiled binary version of the message file, and this is what is used to generate the actual messages. There will be a different MSG file for each language your system should support. In addition, the MSB files are platform dependent and must be compiled on the platform where they are intended to be used.
One thing to keep in mind when running it is that Oracle's messaging libraries are built around the notion of each product having its own separate directory under the Oracle home directory (identified by the ORACLE_HOME environment variable). Each product may in turn have its own separate component or "facility" with its own set of message files. Oracle manages this by having a separate directory under ORACLE_HOME for each product, and then a "mesg" directory under that where the message files for every component are placed. When you run the lmsgen utility, it already expects there to be an Oracle base directory and an ORACLE_HOME environment variable that points to it. In addition it expects there to be a sub-directory for the product under the Oracle directory, and a "mesg" subdirectory under the product directory. When you run the lmsgen routine, it expects you to give it the name of the msg file, the name of the product, and the name of the facility. It uses the product name to locate the "mesg" subdirectory, and it uses the "facility" name as the base name of the msb file that it generates (the filename is suffixed by the language). So, to run lmsgen you will need to have a directory which has some directory underneath with a "mesg" directory under it. So for example (assuming you don't have Oracle code already installed somewhere) you could do the following:
lmsgen translat.msg Documaker xlt
and lmsgen would write a file name "xltus.msb" to the "C:\Documaker\mesg" directory. (The msg file has a code in the first line identifying the language that it is written in, which is how it knows to name it with a suffix of "us". Documaker currently doesn't use the "ORACLE_HOME" method of locating the file, but as far as I know, you do need to have an ORACLE_HOME defined to run lmsgen.exe.
Since we don't use the ORACLE_HOME method, you would need to provide command-line options to override input and output paths.
lmsgen translat.msg Documaker xlt us -i .\ -o .\
The -i identifies the input directory to location the MSG file. The -o indicates the output directory to use as a destination for the compiled MSB file.
Finally, move the MSB and MMP file to the \dll\lang folder inside your Documaker installation.
One further update: be aware that some versions of the translat.ini may contain duplicate message numbers, such as this:
+10141 = &E&: Error in RCBOpenPrintBatchFiles(): Unable to RCBRestartBatch().\n+
+10141 = &E&: Error in RCBOpenPrintBatchFiles(): Unable to VMMAppendElem().\n+
When you process this through lmsgen, you'll see an error message like this:
NLS Binary Message File Generation Utility: Version 126.96.36.199.0 - Production
Copyright (c) Oracle 1979, 2004. All rights reserved.
CORE 188.8.131.52.0 Production
Messages NOT sorted!; see line 2140
You will have to ensure you don't have duplicate messages in the translat.ini file before beginning your conversion, either by correcting or removing duplicates. And, since you're going to ask, the only way I'm sure of to correct duplicates is to contact support to find out what the correct error numbers should be. I've asked Product Development to include the MSG file in the shipping product so you won't need to perform intermediate translation and you can add your messages to the MSG and MMP files directly.
Thanks for all the info.
Does the system allow the option to use the Translat.ini file instead of the binary message file you have been referring to? For example, instead of following the procedure to try and add my customer error messages to the binary message file, can I set an INI setting to use the translate.ini file instead?