Another option is to not store these things as parameters. A couple comments:
First, the strings are only used for initialization. After that, they're stored in other places in the database, like portal headers, package instance names, etc., and if you want to change them, you change them there.
Perhaps writing a simple setup wizard where you ask for the preferred locale and setting (university, project collaboration, whatnot) on page one, and then lets you customize the words as looked up from the message catalog on page two, would be a much better solution?
Second, a message catalog is very much like string apm_parameters, except you can't vary them on a per package instance level. If we could, then these kinds of parameters could be completely replaced by the message catalog.
So should we implement an optional package instance scoping to the message catalog? Would it be possible to do that without hurting performance too much? Is there a real need for this?
/Lars
