The flow of control in the proposed L20n architecture differs from current approaches by encapsulating the processing of string composition and parameter substitution into the l20n library.
A UML-inspired diagram on how things usually work today would be
As you can see, the processing of parameters is done by the application. There is no way to add additional knowledge on the parameters from inside the localization data, nor is there a way to get a different string template (except one for plurals in gettext). As laid out in L20n:Background, that is not enough for a plethora of use cases, and thus we standardize the parameter processing and put it into the library part.
An additional benefit of this approach is that the format of parameters is independent of the programming language the application was written in and will easy parameter checking and localization.
If you have good diagramming skills, I'm happy to take some more appropriate graphs.