Bug 14063 - Implement language overlay for authorised values
Summary: Implement language overlay for authorised values
Status: RESOLVED DUPLICATE of bug 14100
Alias: None
Product: Koha
Classification: Unclassified
Component: I18N/L10N (show other bugs)
Version: Main
Hardware: All All
: P3 enhancement
Assignee: Marc Véron
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-04-26 05:03 UTC by Marc Véron
Modified: 2015-10-16 20:20 UTC (History)
5 users (show)

See Also:
Change sponsored?: ---
Patch complexity: Trivial patch
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:


Attachments
Bug 14063 - Implement language overlay for authorised values (4.05 KB, patch)
2015-04-26 05:38 UTC, Marc Véron
Details | Diff | Splinter Review
Bug 14063 - Implement language overlay for authorised values (4.10 KB, patch)
2015-04-28 08:32 UTC, Marc Véron
Details | Diff | Splinter Review
Bug 14063 - Implement language overlay for authorised values (4.10 KB, patch)
2015-04-28 12:14 UTC, Mirko Tietgen
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Marc Véron 2015-04-26 05:03:14 UTC
There is an urgent need to make authorised values translatable in mulitlingual installations. For the examples I take English (en), French (FR-fr and German (de-DE).

Example:
OPAC (Public interface)
- Set syspref 'suggestion' to: [Allow] patrons to make purchase suggestions on the OPAC.
- Select English
- OPAC: Log in, go to Purchase suggestions > Create a new suggesion
- The dropdown "Reason for suggestion:" shows the authorised values from OPAC_SUG, e.g. "The copy on the shelf is damaged" and "Upcoming title by popular author"
- Select German
- The dropdown "Begründung" shows the same (English) values.

Intranet (Staff client)
- Go to Home > Acquisitions > Suggestions management > New purchase suggestion
- Switch between languages, the dropdown "Reason for suggestion" changes the label, but the values are not ranslated.
- Same with the detail view of a suggestion

There are more places with similar problems. The only (poor and ugly looking) possibility is to have multilingual text in the same entry, e.g.
"Damaged | Beschädigt | Abîmé"
"Upcoming title by popular author | Neuer Titel eines populären Autors |Oeuvre ...." - oh, that gets very long for one line in a drop down...

I propose a solution that implements a language overlay for authorised values. It is minimal invasive and can immediately be used in production.
Patch follows.
Comment 1 Marc Véron 2015-04-26 05:38:12 UTC Comment hidden (obsolete)
Comment 2 Marc Véron 2015-04-26 06:18:26 UTC
Related to this bug:

Bug 14064 Implement language overlay for item types

Bug 7789 (2012-03-22): 
shows Mockups for a more sophisticated administration interface for language overlays.

Bug 13952 - Import and export of authority types
would be helpful to manage language overlays as well (export existing - edit to add language overlays - import)

Bug 14057 - Inventory is painfully slow
would need a $query_mapping that is aware of language overlays (maybe to be moved to a sub in C4:Koha.pm / could be re-used at other places)

Bug 10363 - There is no package for authorised values
I tested this patch on top of Bug 10363, no problems detected.
Comment 3 Marc Véron 2015-04-28 08:32:52 UTC Comment hidden (obsolete)
Comment 4 Mirko Tietgen 2015-04-28 12:14:21 UTC
Created attachment 38603 [details] [review]
Bug 14063 - Implement language overlay for authorised values

This patch implements a language overlay for authorised values.

To prepare tests
- Have an installation with e.g. English, French and German languages
- Set syspref 'suggestion' to: [Allow] patrons to make purchase suggestions on the OPAC.
- Verify that you have a authorised values for OPAC_SUG (bestseller, damaged)

- Open OPAC, log in, go to Purchase suggestions > Create a new suggesion
- The dropdown "Reason for suggestion:" shows the authorised values from OPAC_SUG, e.g. "The copy on the shelf is damaged" and "Upcoming title by popular author"
- Select German
- The dropdown "Begründung" shows the same (English) values.
- Same with French

- Open Intranet (Staff client)
- Go to Home > Acquisitions > Suggestions management > New purchase suggestion
- Switch between languages, the dropdown "Reason for suggestion" changes the label, but the values are not ranslated.
- Same with the detail view of a suggestion

To test:
- In Staff client, go to Home > Administration > Authorized values
- Add a new category OPAC_SUG-de-DE (add language code)
- Create new translated values 'bestseller' and 'damaged' for this category.
- Do the same for French (OPAC_SUG-fr-FR) or other installed languages
- Go to OPAC > Purchase suggestions > Create a new suggesion
- Switch between languages, the values in the dropdown 'Reason' should display in selected language
- Got to Staff client > Home > Acquisitions > Suggestions management > New purchase suggestion
- Switch between languages and verify that the values in the dropdown 'Reason' display in selected language
- Display a suggestion's detail view, switch languages. Text for 'Reason' should change as appropriate.

Bonus test:
- Create language overlays e.g. for category 'DAMAGED' (DAMAGED-de-DE and DAMAGED-fr-FR), authorised values 0 -> 'No' and 1 -> 'Damaged'

Signed-off-by: Mirko Tietgen <mirko@abunchofthings.net>
Comment 5 Jonathan Druart 2015-04-29 12:55:29 UTC
I think we need to implement something more generic.
We have this translation issue for item types (as you noticed, cf bug 14064) but also for sysprefs (i.e. OPACMySummaryHTML, OPACMySummaryNote, OpacNav*, etc.), the library names, etc. (something else?)
We could imagine a table in DB with columns "type" column (will contain "authorised_values", "item_types", "sysprefs", etc.) and "lang" ('fr-FR', 'de-DE', etc.).
The complexity will be to implement an ergonomic view to edit the different translation.
Comment 6 Marcel de Rooy 2015-07-03 07:18:19 UTC
(In reply to Jonathan Druart from comment #5)
> I think we need to implement something more generic.
I agree that if we are adding similar "overlay code" here and there, we will not improve the code. It is a workaround.

If you would pick your translations from a new table, we would still be working on separate roads (translation table and PO files).
Could we use the Koha::I18N approach here? This modules was pushed some time ago but without actual use.
We should need two things at least:
[1] add calls to gettext( $authvalue )
[2] add all authvalues to the PO creation process in misc/translator

A similar approach could be used for item types etc.
What do you think?
Comment 7 Marcel de Rooy 2015-07-03 07:22:13 UTC
(In reply to Marcel de Rooy from comment #6)
> [1] add calls to gettext( $authvalue )

Hm. Not dynamic enough?
Comment 8 Jonathan Druart 2015-07-03 08:18:23 UTC
(In reply to Marcel de Rooy from comment #6)
> A similar approach could be used for item types etc.

I had a try on bug 14100.
Comment 9 Katrin Fischer 2015-07-03 11:23:06 UTC
Hope I understood Marcel's comment correctly:

I feel like the po process is not flexible enough for the values stored in the database. If you enter a new itemtype, you'd have to do 'server side' things first in order to get your additional translation show up. I think something in the GUI would be better here.
Comment 10 Marc Véron 2015-07-05 15:46:28 UTC
Jonathan proposed a Proof of concept for a more generic solution: 
Bug 14100 - Generic solution for language overlay

I tested the proof of concept. It works as described and I think it is the way to go.
Comment 11 Marc Véron 2015-10-16 20:20:06 UTC

*** This bug has been marked as a duplicate of bug 14100 ***