Forum .LRN Q&A: Translatable text in APM parameters

How should we treat translatable text in APM parameters? I have gone
through all parameters in dotLRN and propose the following:

Site wide translatable text parameters to remove from APM and move into a dotlrn message catalog:

departments_pretty_name, departments_pretty_plural, classes_pretty_name, classes_pretty_plural, class_instances_pretty_name class_instances_pretty_plural, clubs_pretty_name, clubs_pretty_plural, dotlrn_main_portlet_pretty_name, subcommunities_pretty_name, subcommunities_pretty_plural, dotlrn_admin_pretty_name non_member_page_name admin_page_name user_portal_pretty_name class_instance_portal_pretty_name

Embedded translatable text in APM parameters, keep in APM, but replace the translatable text parts with message keys with syntax #foo#:

class_instance_pages_csv club_pages_csv subcomm_pages_csv user_portal_pages_csv

As an example, the default value of class_instance_pages_csv is currently:

Class Home,Simple 2-Column;Calendar,Simple 1-Column;File Storage,Simple 1-Column

and the multilingual new version would become:

<span>#</span>dotlrn.class_home_page#,Simple 2-Column;<span>#</span>dotlrn.calendar_page#,Simple 1-Column;<span>#</span>dotlrn.file_storage_page#,Simple 1-Column


Posted by Lars Pind on
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?


Posted by Lars Pind on
I talked to Ben today, and he favors Peter's suggestion above. We'll go with that, then. What a lucky coincidence that that's what we already did :)