home *** CD-ROM | disk | FTP | other *** search
/ Amiga Developer CD v1.2 / amidev_cd_12.iso / devcon / milan_1991 / devcon91.2 / locale / development / catcomp.doc < prev   
Text File  |  1992-09-01  |  17KB  |  416 lines

  1.  
  2.                    $VER: CatComp_Documentation 1.3 (30.7.91)
  3.                    =========================================
  4.  
  5. CatComp is a program to handle locale.library's message catalog creation and
  6. maintenance. Message catalogs are IFF files read by locale.library. They
  7. contain all the text strings used by an application. By providing several of
  8. these catalog files, an application can use locale.library and transparently
  9. adapt itself to the user's preferred language.
  10.  
  11. CatComp reads and processes two kinds of input files, and produces four types
  12. of output files.
  13.  
  14. The first kind of file read by CatComp is a catalog description file. That
  15. file describes all the strings used by an application. There is one such file
  16. per localized application. In this file, you assign numbers to all the
  17. application strings as well as specify their minimum and maximum lengths.
  18.  
  19. The second kind of file read by CatComp is a catalog translation file. That
  20. file contains all strings from the application translated to one language.
  21. There is one catalog translation file per language supported by a localized
  22. application.
  23.  
  24. CatComp can produce four different kinds of output files. The first is an IFF
  25. catalog. These are regular IFF files. There is one catalog produced for every
  26. catalog text file successfully processed. Catalogs are read directly by
  27. locale.library whenever the OpenCatalog() call is made.
  28.  
  29. The second type of file output by CatComp is an empty translation file. This
  30. is useful when starting a translation. It lets CatComp convert a catalog
  31. description file into a ready to fill-in translation file.
  32.  
  33. The third and fourth type of files output by CatComp are C and Assembly
  34. language programming source files. These are used by application writers to
  35. convert catalog description files into source files that can be directly used
  36. in their applications.
  37.  
  38. Invoking CatComp
  39. ----------------
  40.  
  41. CatComp can only by run from the Shell under Kickstart V37 or beyond. Its
  42. template is:
  43.  
  44.   DESCRIPTOR/A,TRANSLATION,CATALOG/K,CTFILE/K,CFILE/K,ASMFILE/K,VB=VERBOSITY/N
  45.  
  46.   DESCRIPTOR/A
  47.   Specifies the name of a catalog description file. Typically, the file
  48.   extension for catalog description files is .cd
  49.  
  50.   TRANSLATION
  51.   Specifies the name of a catalog translation file. Typically, the
  52.   file extension for catalog translation files is .ct
  53.  
  54.   CATALOG/K
  55.   Specifies the name of the IFF catalog file to produce. When this option
  56.   is specified, a translation file must have been given in the previous
  57.   argument.
  58.  
  59.   CTFILE/K
  60.   Specifies the name of the blank catalog translation file to produce. This
  61.   option only requires a catalog descriptor file be provided, there is no need
  62.   for a translation file.
  63.  
  64.   CFILE/K
  65.   Specifies the name of the C-language source file header to produce. This
  66.   option only requires a catalog descriptor file be provided, there is no need
  67.   for a translation file.
  68.  
  69.   ASMFILE/K
  70.   Specifies the name of the Assembly-language source file header to produce.
  71.   This option only requires a catalog descriptor file be provided, there is
  72.   no need for a translation file.
  73.  
  74.   VERBOSITY/N
  75.   Specifies the amount of information CatComp should output while doing some
  76.   processing. The lower this number, the less CatComp will output messages.
  77.   Not providing this option causes CatComp to output every message it could.
  78.  
  79. Catalog Description Files
  80. -------------------------
  81.  
  82. Catalog description files completely describe the strings used by an
  83. application. The format for these files is basically a series of two line
  84. entries separated by an arbitrary number of comment lines. The EBNF (Extended
  85. Backus Naur Formalism) specification for catalog description files is:
  86.  
  87. {# command}
  88. {; comment line}
  89. <string name> "(" [string id] "/" [min string len] "/" [max string len] ")"
  90. [string]
  91.  
  92. The first line indicates special commands that provide control over the
  93. generation of C and Assembly source files. See the section on C and Assembly
  94. source files below for further information.
  95.  
  96. <string name> is the symbolic name of the string. Following the name comes
  97. three optional numbers enclosed in parenthesis and separated with slashes. The
  98. first number specifies the string's ID value. This is the ID value used to
  99. request this string when using the GetCatalogStr() call in locale.library. The
  100. second number specifies the minimum length for the string, while the third
  101. number specifies the maximum string length.
  102.  
  103. The next line of an entry contains the actual string. Within the catalog
  104. description file, the strings are the same as the default strings built into
  105. the application. The strings can use standard C-language backslash ("\")
  106. escape sequences.
  107.  
  108. Finally, any string entry can be separated from other entries by comment
  109. lines. Comment lines start with a semicolon. There can be any number of
  110. comment lines between two entries. It is not allowed to put comment lines
  111. between the two lines of a same entry.
  112.  
  113. Here's an example of two strings in a catalog description file:
  114.  
  115. MSG_HELLO (0/4/50)
  116. This is a test string for the world to see
  117. ;
  118. MSG_BYE (1/14/47)
  119. This is another test string
  120.  
  121. The first string is called MSG_HELLO, has 0 as ID value, can be as short
  122. as 4 characters and as long as 50. The string actually associated with the
  123. name follows on the next line. Then comes a comment line. Following that is
  124. the definition of the second string called BYE_WORLD_STR that has 1 as ID
  125. value, can be as short as 14 characters and as long as 47.
  126.  
  127. As mentioned above, all three numbers in an entry are optional. If the string
  128. id number is not specified, then the same id as the previous string in the
  129. file plus one is used. If the first string defined has no id value, the
  130. starting id value is 0. If the minimum string length is not specified, it is
  131. assumed to be 0. And finally, if the maximum string length is not specified,
  132. it is assumed to be unlimited.
  133.  
  134. A note on style here. It is relatively important to choose descriptive
  135. symbolic names for the strings. These names will be viewed by the translators
  136. and should be as meaningful as possible. The following conventions are
  137. suggested:
  138.  
  139.   - List all names in capital letters. This will make it clear they are
  140.     constants as this is the convention used in all Amiga include files.
  141.  
  142.   - Prefix each name with the string MSG_. This will make it clear to the
  143.     programmer that a given constant is in fact a string ID value.
  144.  
  145.   - Append the string _GAD to strings that are used for gadget labels.
  146.  
  147.   - Append the string _MENU to strings that are used for menu titles. For
  148.     example, MSG_EDIT_MENU.
  149.  
  150.   - Expand the path leading to a menu item when specifying strings that are
  151.     used for menu items. For example, for the Cut item in the Edit menu
  152.     would be written as MSG_EDIT_CUT.
  153.  
  154. Catalog Translation Files
  155. -------------------------
  156.  
  157. Catalog translation files contain all the strings of an application translated
  158. to a different language than the default. The files look very similar to
  159. catalog description files, except they do not include the string id, minimum
  160. string length and maximum string length specifications. The EBNF specification
  161. for catalog translation files is:
  162.  
  163. {# command}
  164. {; comment line}
  165. <string name>
  166. [string]
  167.  
  168. The first line indicates special commands that describe attributes of the
  169. catalog file. There are currently three supported commands. "version" lets you
  170. specify a 2.0-style version string for the catalog. "language" lets you list
  171. the language that this catalog is in. This string should itself be in the
  172. given language and not in English.
  173.  
  174. For example:
  175.  
  176. MSG_HELLO
  177. Ceci est une chaine test pour être vue
  178. ;
  179. MSG_BYE
  180. Ceci est une autre chaine test
  181.  
  182. On the first line you list the symbolic name of the string, and on the second
  183. line the translated string. The symbolic name is the same as the related entry
  184. in the catalog description file. CatComp uses this name to associate entries
  185. from translation files with entries in description files. It can then validate
  186. the strings in the translation files by ensuring they are of the correct
  187. length, etc.
  188.  
  189. Escape Sequences Supported
  190. --------------------------
  191.  
  192. Regular C-language escape sequences can be specified in strings, along with a
  193. few additions:
  194.  
  195.   \a    inserts an audible bell character (ASCII 7)
  196.   \b    inserts a backspace character (ASCII 8)
  197.   \c    inserts a control sequence introducer (ASCII 155)
  198.   \e    inserts an escape character (ASCII 27)
  199.   \f    inserts a formfeed character (ASCII 12)
  200.   \n    inserts a newline character (ASCII 10)
  201.   \r    inserts a carriage return character (ASCII 13)
  202.   \t    inserts a tab character (ASCII 9)
  203.   \v    inserts a vertical tab character (ASCII 11)
  204.   \xNN  inserts NN, where NN specifies an ASCII code in hexadecimal
  205.   \NNN  inserts NNN, where NNN specifies an ASCII code in octal
  206.  
  207. Formatted Output Commands
  208. -------------------------
  209.  
  210. CatComp parses strings for C-language formatting commands as used in the
  211. printf() function. It ensures that the number and type of such commands are
  212. the same in both the description file and the translation files. This
  213. guarantees that the application stack frame will not be misinterpreted due to
  214. incorrect translations of formatting commands.
  215.  
  216. CatComp warns you if you attempt to use any non-C formatting commands. The
  217. commands that CatComp does understand are:
  218.  
  219.     %b  %c  %d  %e  %E  %f  %g  %G  %i  %o  %p  %s  %u  %x  %X
  220.  
  221. CatComp also knows about the ordering formatting command supported by
  222. RawDoFmt() whenever locale.library runs in the system, or by locale's
  223. FormatString() routine. The ordering command lets you specify formatting
  224. commands within a formatting string in a different order than in the original
  225. string, while still accessing the stack frame correctly. CatComp validates the
  226. ordering information and ensures argument types match. See the documentation
  227. locale.library/FormatString().
  228.  
  229. Specifying the argument position lets the order of the % commands within your
  230. strings without affecting how the program performs. Given a string in a
  231. catalog description file such as:
  232.  
  233. MSG_AVAIL_MEM (//)
  234. FAST: %lU, GRAPHIC: %lU
  235.  
  236. This string could be translated in French as:
  237.  
  238. MSG_AVAIL_MEM (//)
  239. GRAPHIQUE: %2$lU, AUTRE %1$lU
  240.  
  241. Using the first string, the output of the program might look like:
  242.  
  243. FAST: 1234, GRAPHIC: 5678
  244.  
  245. while the translation would output:
  246.  
  247. GRAPHIQUE: 5678, AUTRE: 1234
  248.  
  249.  
  250. Validation
  251. ----------
  252.  
  253. CatComp enforces the syntax of catalog description files and catalog
  254. translation files very strongly. It also ensures that the same number of
  255. C-language % command appear in both the description and the translation file.
  256. This guarantees the integrity of the application stack-frame when using
  257. translated string in printf() statements.
  258.  
  259. Most errors detected by CatComp are fatal and cause the program to abort.
  260. Errors are reported to the console with a descriptive error message, a
  261. filename, and if needed a line and column number. Non-fatal errors (warnings)
  262. and also sent to the console, but they do not cause the program to abort. The
  263. printing of these warning messages can be suppressed using the VERBOSITY
  264. command-line option.
  265.  
  266. Possible Errors
  267. ---------------
  268.  
  269. Here is a list of the errors and warnings that CatComp can produce, along with
  270. an explanation of what went wrong. Most errors indicate the file, line and
  271. column where the error occurred to help in solving the problem.
  272.  
  273. ERROR: string line for token <name> not found
  274.   A given token was not followed by a string
  275.  
  276. ERROR: token not found
  277.   No token was found on a line in a catalog description file. Comment lines
  278.   must start with ";", any other line must have a valid token definition on
  279.   it.
  280.  
  281. ERROR: '(' expected
  282.   There was no number section after a token in a catalog description file.
  283.   The number section must start with a (, followed by three optional numbers
  284.   separated by slashes, and terminated by a ).
  285.  
  286. ERROR: ')' expected
  287.   There was no ) after a number section in a catalog description file.
  288.   The number section must start with a (, followed by three optional numbers
  289.   separated by slashes, and terminated by a ).
  290.  
  291. ERROR: '/' expected
  292.   There was no slash found within a number section after a token in a catalog
  293.   description file. The number section must start with a (, followed by three
  294.   optional numbers separated by slashes, and terminated by a ). So there
  295.   must always be two slashes specified.
  296.  
  297. ERROR: garbage characters after token <name>
  298.   There was no number section after a token in a catalog description file,
  299.   and garbage characters were found instead, The number section must start
  300.   with a (, followed by three optional numbers separated by slashes, and
  301.   terminated by a ).
  302.  
  303. ERROR: <name> is not a valid token
  304.   A token in a catalog description file was composed of invalid characters.
  305.   A token must start with a letter and can be followed by letters, numbers and
  306.   underscores.
  307.  
  308. ERROR: token <name> not found
  309.   A token specified in a catalog description file was not present in
  310.   a translation file
  311.  
  312. ERROR: string too short for token <name>
  313.   A string in a translation file is shorter than the minimum length
  314.   specified in the description file.
  315.  
  316. ERROR: string too long for token <name>
  317.   A string in a translation file is shorter than the minimum length
  318.   specified in the description file.
  319.  
  320. ERROR: negative value for minimum length
  321.   The minimum string length specified for a token must be positive.
  322.  
  323. ERROR: negative value for maximum length
  324.   The maximum string length specified for a token must be positive.
  325.  
  326. ERROR: non-positive value for % ordering
  327.   The position information for a % formatting command must be positive and
  328.   greater than 1.
  329.  
  330. ERROR: % ordering value too large
  331.   The position information for a % formatting command is greater than the
  332.   number of formatting commands provided
  333.  
  334. ERROR: % size incorrect
  335.   The size specifier for a % formatting command in a translation file does
  336.   not match the size in the description file.
  337.  
  338. ERROR: % command does not match
  339.   The type specifier for a % formatting command in a translation file does
  340.   not match the size in the description file.
  341.  
  342. ERROR: token <name> defined multiple times
  343.   A token was defined multiple times in either a description or a translation
  344.   file.
  345.  
  346. ERROR: id <number> already used for token <name>
  347.   An attempt was made to reuse an ID value twice within a description file
  348.  
  349. ERROR: no command found after '#'
  350.   Command lines start with # and are followed by a command.
  351.  
  352. ERROR: <name> is not a valid command after '#'
  353.   A command specified after # is invalid.
  354.  
  355. ERROR: <number> is not a valid codeset value
  356.   An incorrect codeset value was specified for a #codeset command.
  357.  
  358. ERROR: couldn't write catalog <name>
  359.   An error occurred while writing the catalog file
  360.  
  361. WARNING: <name> is an unknown formatting command
  362.   An unknown % formatting command was specified. CatComp knows only of
  363.   C-language formatting commands, anything else will be flagged
  364.   with this warning.
  365.  
  366. WARNING: string for token <name> matches string in descriptor
  367.   A string within a translation file matches exactly the original string
  368.   from the description file. This may mean that the string was not
  369.   translated.
  370.  
  371. C and Assembly Source Files
  372. ---------------------------
  373.  
  374. CatComp has the ability to output C and Assembly language source file headers.
  375. The intent of this is to let application programmers manipulate a single
  376. catalog description file and have source files generated for them
  377. automatically so they can include the strings in their programs.
  378.  
  379. To generate these files, you need to give CatComp a descriptor file, and
  380. either a C or an ASM output file name using the CFILE/K and ASMFILE/K
  381. command-line options. The resulting files will be standard C and/or ASM
  382. sources file headers that be used easily in application code.
  383.  
  384. Sample Use
  385. ----------
  386.  
  387. This section presents sample uses of CatComp with example command-lines.
  388.  
  389. Assume you have a catalog description file for an application called "app.cd".
  390.  
  391.  
  392. To test if this file is a valid .cd file, type:
  393.  
  394.   CatComp app.cd
  395.  
  396. and CatComp will respond with either some error messages, or with a message
  397. saying that 'app.cd' is a valid descriptor file.
  398.  
  399.  
  400. To do a translation of a .cd file, you need a .ct file. Such a file can be
  401. generated by doing:
  402.  
  403.   CatComp app.cd CTFILE app.ct
  404.  
  405. This will create a blank translation file called app.ct. You can then load
  406. app.ct in a standard text editor and proceed to translate the strings it
  407. contains.
  408.  
  409.  
  410. Once a .ct file is done being translated, it must be converted in an IFF
  411. catalog file. This is done by doing:
  412.  
  413.   CatComp app.cd app.ct CATALOG app.catalog
  414.  
  415. This will create a file called app.catalog.
  416.