Description Translations RFC
From Koha Wiki
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.
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