Bug 25376 - Use LANG authorised values for language facet
Summary: Use LANG authorised values for language facet
Status: In Discussion
Alias: None
Product: Koha
Classification: Unclassified
Component: Searching (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Julian Maurice
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-05-05 12:05 UTC by Julian Maurice
Modified: 2021-10-15 19:35 UTC (History)
3 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:


Attachments
Bug 25376: Use LANG authorised values for language facet (3.00 KB, patch)
2020-05-05 12:11 UTC, Julian Maurice
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Julian Maurice 2020-05-05 12:05:09 UTC
Instead of relying on language_descriptions table, on which users have no control, use LANG authorised values
It will give more control to users which will be able to add new languages or change descriptions (for instance to translate them in their own language)
Comment 1 Julian Maurice 2020-05-05 12:11:55 UTC
Created attachment 104360 [details] [review]
Bug 25376: Use LANG authorised values for language facet

Instead of relying on language_descriptions table, on which users have
no control, use LANG authorised values
It will give more control to users which will be able to add new
languages or change descriptions (for instance to translate them in their
own language)

Test plan:
1. Do a search that return values for the language facet
2. Check that if you change a description in LANG authorised values, it
   changes the displayed facet
Comment 2 Katrin Fischer 2020-05-05 20:00:09 UTC
But unlike the database tables this doesn't allow for translations and every library will have to maintain the list. The LANG authorised value is empty and not used by default for MARC21 installations at the moment. I'd prefer the current model - could this be made a choice?
Comment 3 Julian Maurice 2020-05-06 06:48:12 UTC
(In reply to Katrin Fischer from comment #2)
> could this be made a choice?

I'd prefer not to (too much sysprefs already). What if we add LANG authorised values for MARC21 installations, and wait for authorised values to be translatable (bug 20307 or bug 24977) ? Would this patch become acceptable ?
Comment 4 Katrin Fischer 2020-05-06 06:55:16 UTC
I am torn, maybe we should ask for some other opinions.

Having the list in the database will always require maintenance. If a code or description in the standard changes, we cannot update existing installations assuming they have made changes. There might be a constant need of maintenance for the libraries to do.

And even if we make them translatable via the database - the list is LONG (see http://www.loc.gov/marc/languages/language_code.html) We will still put the translation work on the individual users instead of shipping with all the translations they might need or install.

I feel such "standard" things are better as hardcoded lists to be honest and change the few you might want to change with other means (jquery comes to mind). 

Also see how we do it for XSLT with MARC21 (including a script to do the updating) on bug 20364.
Comment 5 Katrin Fischer 2020-05-06 06:57:03 UTC
That said: our db based solution is not super great and only supports a few languages, moving into the direction of the XSLT solution might be another thing to think about.
Comment 6 Julian Maurice 2020-05-06 07:10:08 UTC
We could take out the list of languages from database. For instance we can have all languages codes and descriptions listed in a Perl module, and translations would be possible through current PO files.
How does that sound ?
Comment 7 Katrin Fischer 2020-05-06 07:39:38 UTC
Hi Julian, I think that might be the right direction to take - I think Bernardo was working on somehing a while ago, linking the bug 12017 and Bernardo.
Comment 8 Bernardo Gonzalez Kriegel 2020-05-06 13:36:15 UTC
(In reply to Julian Maurice from comment #6)
> We could take out the list of languages from database. For instance we can
> have all languages codes and descriptions listed in a Perl module, and
> translations would be possible through current PO files.
> How does that sound ?

(In reply to Katrin Fischer from comment #7)
> Hi Julian, I think that might be the right direction to take - I think
> Bernardo was working on somehing a while ago, linking the bug 12017 and
> Bernardo.

I guess Bug 12017 tried to accomplish too much and that's why it was never tested, but it used to work fine in my tests :)

I still think the language descriptions should be outside the database, with the work on Bug 20364 they wouldn't even have to be translated again and the listing might be the same.
In my case the template was repeated in opac and intranet, since it is necessary in both, it would be good to have a common space for all interfaces (I remember writing something about that.)
But for now it would be enough with the intranet, I suppose.
My personal preference is a solution based on a template file, not in perl code. But I don't care about the solution as long as it works and is maintainable.
Comment 9 Julian Maurice 2020-05-06 13:48:39 UTC
(In reply to Bernardo Gonzalez Kriegel from comment #8)
> My personal preference is a solution based on a template file, not in perl
> code. 

Can you explain why ?
Genuinely curious, as I really don't see the benefits of using a template file here.
You already said that we would have to duplicate the list to be able to use it in both interfaces, and I think it is easier to use a Perl structure into templates, than it is to use a "structured template file" (whatever it is) into Perl code
Comment 10 Bernardo Gonzalez Kriegel 2020-05-06 14:51:27 UTC
(In reply to Julian Maurice from comment #9)
> (In reply to Bernardo Gonzalez Kriegel from comment #8)
> > My personal preference is a solution based on a template file, not in perl
> > code. 
> 
> Can you explain why ?
> Genuinely curious, as I really don't see the benefits of using a template
> file here.

Just a personal preference, maybe it is the option with which I feel most comfortable, after all I'm an old man and sometimes I don't like changes :)

> You already said that we would have to duplicate the list to be able to use
> it in both interfaces, and I think it is easier to use a Perl structure into
> templates, than it is to use a "structured template file" (whatever it is)
> into Perl code

You are right, and something in a common namespace is preferable.
How do you think a solution would be?