Bug 14063

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.

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>

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.

(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?

(In reply to Marcel de Rooy from comment #6)
> [1] add calls to gettext( $authvalue )

Hm. Not dynamic enough?

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

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.

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.

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