#
# limits.txt
#   Description:
#      This file describes the limitations of two of the major
#      existing standards for internationalization, as perceived
#      by the author of this document. The standards are known as
#      gettext from GNU, and catgets from X/Open.
#   Author:
#      Grant Mongardi
#   Creation Date:
#      10/19/2001
# ================================================================

Summary:
    After a thorough going-over of the gettext utilities from GNU
    and the catgets utilities from X/Open, I have come to the
    conclusion that neither is the correct solution. IMHO, I
    believe that both systems are somewhat shortsighted in their
    respective implementations. This document attempts to describe
    the limitations of each system.

Common Limitations:
    Both systems are not easily extensible. They have expectations
    of what can and cannot be in the catalog file and offer no way
    to work around it.

    Neither systems catalog file libraries can be easily converted
    to the other's format. In other words, to write a tool to do
    the conversion automatically would be difficult, if not
    impossible without human input. The catgets() version would be
    simpler than gettext() version, however.

    Both systems have licenses that presently do not encompass the
    same general rules that we wish to apply to Parrot/Perl.

Gettext Limitations (in addition to the above):
    gettext() only can reference strings by the untranslated version
    of the strings. I believe that Parrot would benefit from being
    able to emit either symbols or symbol references (integers), and
    gettext() would not be able to do this directly (think CORBA
    messages, or messages between the TIL/JIT and Parrot). I can however,
    see the interest in being able to reference a lookup by it's
    untranslated english component, however this is not what I myself
    am used to. (Shouldn't gettext() return the string "NULL" rather
    than the symbolic constant NULL on failure? ;-)

    gettext() catalogs can contain numerous entries for the same
    purpose. For instance, one developer might enter a string like
    "No memory available" and another might have "Out of Memory".
    This could also happen for a symbol or integer based system,
    however I think it is less likely.

    gettext() seems rather strange in it's support of dialects. It
    references language sets from ISO 639, which fails to describe
    specific dialects within a country (i.e, Cantonese, Mandarin, and
    French Canadian are not listed). This means that the implementor
    must design their own way to describe dialects. I'm not positive
    about my assessment of this one, so correct me if I'm wrong.

Catgets Limitations (in addition to the above):
    catgets() references all lookups by symbolic constants. This is
    OK in the sense that the symbols can be standardized, however the
    use of symbolic constants does not allow one to perform string-
    lookups, which may be useful in that they could offer a fallback
    string more easily should a catalog not be available (I'm
    grasping here, but I really don't know of any serious flaw in
    using symbolic constants as identifiers).

    catgets() catalogs appear to not require the retention of the
    initial untranslated string in the non-native catalogs. This
    definitely makes it more difficult to perform manual translations,
    as the translator must have two files open at once.

    catgets() breaks the 8.3 file naming limitation for catalog file
    names. This would not work on some of Parrots target platforms.

    X/Open also appears to be somewhat POSIX-centric. Although I don't
    think that this is necessarily a bad thing, I think it might send
    a message that the user may not want to hear.