We've just internationalized/localized the Curriculum package on a local machine (and translated it to Swedish). However, before I commit the changes and catalog files to cvs HEAD I'd like to discuss a problem that arose.
Several terms in the workflow spec needed to be translatable so we flanked these words with temporary translation tags (<#_ Word#>) and had the i18n scripts do their thing. The end result would then look something like this:
ad_proc -private curriculum::workflow_create {} {
Create the 'curriculum' workflow for curriculum.
} {
set spec {
curriculum {
pretty_name {[_ curriculum.Curriculum_1]}
package_key curriculum
object_type cu_curriculum
callbacks {
curriculum.CurriculumNotificationInfo
}
...
Further down in the same proc the actual workflow creation call was changed from:
set workflow_id [workflow::fsm::new_from_spec -spec $spec]
to this:
set workflow_id [workflow::fsm::new_from_spec -spec [subst $spec]]
We used "subst" so that the "_" translation proc would be evaluated and not passed on as a string ...
To cut to the chase ... This method works fine - the terms do get translatable. The problem is the workflow spec is only processed at package installation. This means the locale you had selected for your system while installing Curriculum will be "locked" forever as far as workflow is concerned. That is, the various workflow-related phrases in the package will stay in the locked language although you've changed the language in the package at large.
Would a solution to the problem be to skip our "subst" part and actually pass on the "_" key lookup call to the workflow, which then gets executed on the fly when invoked from the "case log" code?
Thoughts, anyone?
/Ola
