@Laurens: We considered doing something like that, which would certainly help. However, as long as we’re doing a preprocessing step, we might as well do as much as we possibly can to improve performance at runtime, and we got a huge boost by dropping regex replacement entirely. TraceMonkey (Mozilla’s new JS engine) currently can’t handle nontrivial regex replacement in an optimal manner, though hopefully this bug will get fixed soon. In our case, converting the replacement operation to a string concatenation made our code about 40x faster in the evaluation step.

@Daniel: Thanks for the offer! As I mentioned above, we don’t have performance-critical regex operations any more. That said, it would be useful to make our l20n “interpreter” faster.

The regex to match our expander syntax looks like this:
/\$\{([^\}]+)\}(i|s)/

It gets used as follows:
complex_string_to_expand.replace(/\$\{([^\}]+)\}(i|s)/g, replacement)

where ‘replacement’ is a function to evaluate expressions and look up entity references that appear inside the curly braces.

If you see any room for improvement, please let me know!