What we have implemented now (not cast in stone of course) is the numbering scheme mentioned by Christian above. Basically, if you have a piece of text with embedded variables, there are at least two different approaches to consider. The first is to provide one message key for every piece of text between the variables, as illustrated by:
ad_return_complaint
1
"#dotlrn.The_name# $pretty_name
#dotlrn.is_already_in_use#. #dotlrn.lt_Please_select_a_diffe#."
with corresponding catalog entries:
mr en_US dotlrn.The_name {The name}
_mr en_US dotlrn.is_already_in_use {is already in use}
_mr en_US dotlrn.lt_Please_select_a_diffe {Please select a different name}
The other approach is to stuff a whole such text into a message and interpolate variables into it with the numbering scheme, like this:
ad_return_complaint 1 [_ [ad_conn locale] dotlrn.class_may_not_be_deleted "" [list [parameter::get -localize -parameter classes_pretty_name] [parameter::get -localize -parameter class_instances_pretty_plural]]]
which results in only one entry in the catalog file:
_mr en_US dotlrn.class_may_not_be_deleted {Error: A %1 must have <em>no</em> %2 to be deleted}
Note that this approach allows for variable place holders to be re-ordered. We currently don't have any provision for indicating to the translator what is behind these place holders, however, in most cases it should be possible for the translator to look at the message in the web interface and figure that out.
How does this sound?
