POSIX gettext(): messages catalog lookup when LANGUAGE is set

[Bruno Haible]

https://posix.rhansen.org/p/gettext_draft
Lines 308..309
  "o attempt to locate a suitable messages object..."
   o attempt to retrieve the string identified by msgid from the messages
     object"
and line 342, 344
  "the pathname used to locate the messages object shall be
   dirname/localename/categoryname/textdomainname.mo, where:
   ...
   additional searches of locale names without .codeset (if present),
   without _territory (if present), and without @modifier (if present)
   may be performed"

This text is suggesting that once the first suitable messages object
has been found, the string identified by msgid will be looked up in
this ONE AND ONLY ONE messages object.

Lines 339, 340 on the other hand suggest that when the msgid is not
found in the messages object, the search may continue.


What GNU gettext does, is that if the "attempt to retrieve the string
identified by msgid from the message object" fails, the search continues
with the NEXT suitable messages object.

Why is this important?

The list of directories is important for people who live in communities
which often (but not always) have translations of their own but can read
translations for other locales. For example:

  * A user in Austria prefers translations for Austrian German, but can
    also read German with no problem.

  * A user in Uzbekistan may prefer translations in Cyrillic but can also
    read translations in Latin. [1]

To accomodate, say, the first of these examples:

  * The language identifier 'de' gives rise to the localename part
      de

  * The language identifier 'de_AT' gives rise to the localename parts
      de_AT
      de

The translator for the de_AT locale may choose to translate only messages
that contain words that translate differently to Austrian than to German,
e.g. "potato", "nonsense", "bag", "is possible", and leave the rest to
the German translator. (It would be a waste of human resources if the
Austrian and the German translator did double work on 98% of the messages.
And it would be a complicated workflow if the Austrian translator had to
update their translations each time the German translator send new or
updated translations.)

The de_AT/LC_MESSAGES/textdomainname.mo file will thus contain a few
translations, and the desired behaviour is that for the msgids not
translated in this messages object, the next one
de/LC_MESSAGES/textdomainname.mo, gets used.

Suggestion: Reword it so that
  "o attempt to locate a suitable messages object..."
   o attempt to retrieve the string identified by msgid from the messages
     object"
are no longer separate steps, but such that backtracking occurs when the
messages object does not contain a translation for the given msgid.
This would resolve the apparent contradiction with lines 339, 340.