L20n app workflow?

Hi,

My interest in L20n seems to increase every time I'm thinking about this 
technology - I guess that's a good sign ;-)

What I wondered about though is how exactly the workflow of a 
L20n-enabled app looks like (I think that's needed to get to a stage 
where it can be implemented).

Current Mozilla L10n has two possibilities, depending on where strings 
are used (using descriptive language here):

1) "the XUL workflow":
    - specify L10n file(s) for a given file
      (all strings get loaded into a single "namespace" [of entities],
      beware of string ID clashes)
    - reference the string ID only where the string is used

2) "the stringbundle workflow"
    - load one stringbundle per L10n file
      (one "namespace" [stringbundle] per L10n file)
    - reference stringbundle + string ID where the string is used

gettext usually does it the following way:

3) "the gettext workflow"
    - load a "textdomain" (with a base path), which gettext resolves to
      to an L10n file per language
      (all strings are in the "namespace" of their respective textdomain)
    - define a default textdomain/"namespace"
    - reference either only the original string (if in the default
      textdomain) or textdomain + the original string where the string is
      used

What is the plan for a workflow used by L20n?

Additionally, how is L20n supposed to find its files for a specific 
language as well as the files for fallbacks?
The current Mozilla infrastructure does language selection on the chrome 
registry level, but that doesn't provide for falling back to a different 
language for non-defined strings (object IDs). Gettext uses a strictly 
defined subdirectory architecture to be used so it can locate PO files 
for the language to be used and any possible fallbacks.
Which approach do we take there for L20n?

If we want to test the concept with simple implementations written in 
any languages we like, we need those concepts to build on in addition to 
the file format and other logical concepts we already have in place.
(In addition, we'll one time need to define guidelines or rules for the 
function names to be used for retrieving stuff from the L20n library, 
but I guess that can wait a bit longer.)

I'd really like to do some crude testing implementation for PHP just to 
see if L20n is really as good as I imagine it currently. From what I 
know currently, the L20n concepts also make dev work much easier for me 
in PHP (not needing to implement plural selectors in the code itself in 
many places, leave that up to the localization layer, for example - and 
of course getting rid of long original strings mixed into the code).
Would be cool to be able to test some of that ;-)

Robert Kaiser