Glenn Fowler wrote:
> I understand the "sparse message catalog" problem to be
> that an ast optget usage string would be treated as
> one string in the message catalog
>
No, what I meant by this is whether or not all output messages are
translated as part of the process of localization. I think normally
commands have *all* of their messages translated. My fear is that by
putting the man pages in line in the binary, it increases the cost of
localizing these commands.
The response made by others was that it would be possible to elide the
translations for the man pages, giving a "sparse" message catalog. (In
retrospect this language is not fully accurate -- what is meant is a
sparse localization.)
Now, I'm not sure about precedent for this, and whether in a given
situation waiving the localization for part of a command would be
acceptable.
- Garrett
> however, this is not how libast::optget() interfaces with
> the underlying message catalogs
>
> almost all of the l10n strings in ast src are
> arguments to libast::error() or libast::optget()
>
> the error() strings are basically printf-style
> strings that are used as keys into the message catalog
>
> an ast layer is provided to map the strings to integral
> indices for native message catalog apis that require indices
>
> optget() breaks down the usage string into smaller
> message catalog strings
>
> the --keys option lists the message catalog strings
> in C-style "..." strings, one per line
>
> e.g.,
> sum --keys 2>&1 | wc
> shows 88 message catalog strings for a total of ~6K bytes
> for the C locale
>
> note that the long option names are also subject to l10n
> for portability the C locale names are visible in all locales
>
> -- Glenn Fowler -- at&t Research, Florham Park NJ --
>
>
