RFC: Description Translation

The current architecture keeps the miscellaneous descriptions (MARC fields and subfields, System Preferences) directly in the database.

This prevents the user to get those descriptions in its selected language.

This RFC is about moving the descriptions out from the database, or at least adding a way to dynamically retrieve descriptions from an external ID-to-String map structure (file?).

The IDs could be manage in 2 different ways.

1. A new field DescriptionID can be added to the database
   • Advantage: Remembers the developer to add a new DescriptionID in the map structure
   • Disadvantage: Make the database bigger
2. We can use the data already in the database for ID generation.
   • MARC Field Description: marc_tag_structure.tagfield Ex: 100
   • MARC Subfield Description: marc_subfield_structure.tagfield$marc_subfield_structure.tagsubfield Ex: 100$a
   • System Preferences: systempreferences.variable ex: IndependantBranches
   • Advantage: Nothing new to add to the database.
   • Disadvantage: A new ID must be entered in the external file when someone add a new field/subfield/system preference

In both case, we could get rid of the current “description” field in the database. If we want to keep it, it could contains a default (english?) description.

Note from Galen Charlton

I support the goal of this RFC, which I view as separating structures (e.g., the system preference list) from the labels used to describe it. The tricky part will be the implementation.



To make it easier for the translators, we should make sure that the same translation management interface can be used for both the HTML templates and the sysprefs and MARC frameworks, regardless of whether the translated strings remain in an external file or (for the sake of speed) get stored in the database.