AutoOpts includes its own .pot file for inclusion with your project's .pot files. Additionally, the translatable strings embedded in the AutoOpts generated source are wrapped in _(...) macros so they can be extracted for translation at run time.

NB:

long option names are considered "translatable" meaning a program localized to Spanish, for example, could accept "--ayuda" as the long option for "--help".

By default, an AutoOpt-ed project will not have a translatable usage text. This is because the usage text is constructed by gathering together words and phrases to construct the message at run time. This gluing process results in a very stilted or even incomprehensible translation. You may now avoid this by specifying the "full-usage" and "short-usage" attributes in the option definition file.

• Unspecified is the default. The usage text will be computed at run time and it will be difficult to translate.

• If the attributes are provided but empty, the AutoOpts templates will generate the usage text. It will be inserted into the generated .c file and referenced by the option descriptor structure. The libopts run time will see that reference and print it out in preference to computing the usage text itself.

• If the attributes text look like a variable name, then that variable name will be inserted into the option descriptor structure and be handled the same way. That variable should be resolved by the compiler into the address of the first byte of the usage text.

• If the attributes text looks like a block of text, then that text is presumed to be the full or short usage text in its entirety. It will be emitted into the generated .c file and referenced in the option descriptor structure.

However you do it, if those character pointers in the structure point to something and if the generated .c file is compiled with ENABLE_NLS defined for the preprocessor in some way, then gettext() (or whatever the _(...) macro maps to) will be called to find the translation for the usage text.