Description Translations RFC

From Koha Wiki

Jump to: navigation, search
Home > Development > RFCs
Home > Development > RFCs > Koha components for RFCs > Aspects of multiple components RFCs > Internationalisation, Localisation, and Globalisation RFCs
Home > Development > RFCs > Koha version targeted RFCs > RFCs not targeted at a particular Koha version
Translation

Contents

RFC: Description Translation

Sponsored by no-one and developed by no-one, expected for/deadline: unknown

See also <bugzilla number> Bug <bugzilla number>.

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. 

Can someone please explain 'Discharge'? I don't think this is the correct term for this function. in a library context discharge most commonly means 'return a book from loan' The description appears to be 'remove a patron plus extra functionality.