Koha Test Wiki MW Canasta on Koha Portainer

Test major Koha Wiki changes or bug fixes here without fear of breaking the production wiki.

For the current Koha Wiki, visit https://wiki.koha-community.org .

Description Translations RFC

From Koha Test Wiki MW Canasta on Koha Portainer
Jump to navigation Jump to search

RFC: Description Translation

Status: unknown
Sponsored by: no-one
Developed by: no-one
Expected for: unknown
Bug number: <bugzilla number> Bug <bugzilla number>
Work in progress repository: link(s) to currently published work on this RFC
Description: === Status ===

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

Problem

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?).

IDs management

The IDs could be manage in 2 different ways.

  • 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
  • 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.


Notes/Comments

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.