Path: utzoo!yunexus!hydroesm!jtsv16!torsqnt!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!cs.utexas.edu!sdd.hp.com!ucsd!usc!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!rws
From: rws@EXPO.LCS.MIT.EDU (Bob Scheifler)
Newsgroups: comp.windows.x
Subject: Re: More about "Composite widgets and translations"
Message-ID: <9005291312.AA11832@expire.lcs.mit.edu>
Date: 29 May 90 13:12:26 GMT
Article-I.D.: expire.9005291312.AA11832
References: <9005272002.AA16605@uk.ac.oxford.prg.boothp1>
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 22


    It would appear to be the case that, for a child of a composite widget, you
    can either setup translations from the applications fallback_resources or
    you can have translations in your .Xdefaults but not both!

It isn't specific to a child of a composite widget.  For any widget, and
any resource for that widget, at most one entry from the multitude of
possible resource files (and pseudo-files like the server property and
the fallback resources) will be applied to that resource.  You need to
think of it this way: all of those resource files first get merged together
(newer additions replacing older entries), and then lookups are made.
Now, in the case of translation tables, with #override/#augment specifiers,
it would seem reasonable that the resource entries should "cascade" in some
way, rather than just "newest wins".  But the resource manager doesn't
know anything about translation tables; at the resource database level
they're just strings, like any other strings.

This is one of several deficiencies that we've identified with resource
management in X.  We (MIT) have some proposed solutions to these problems,
including a solution to cascading translation tables, but we're a ways from
having working prototypes or having the solutions formally reviewed and
blessed by the X Consortium.