Summary: | Use LANG authorised values for language facet | ||
---|---|---|---|
Product: | Koha | Reporter: | Julian Maurice <julian.maurice> |
Component: | Searching | Assignee: | Julian Maurice <julian.maurice> |
Status: | In Discussion --- | QA Contact: | Testopia <testopia> |
Severity: | enhancement | ||
Priority: | P5 - low | CC: | anne-cecile.bories, bgkriegel, marjorie.barry-vila |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
See Also: |
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12017 https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29256 |
||
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 25376: Use LANG authorised values for language facet |
Description
Julian Maurice
2020-05-05 12:05:09 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 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? (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 ? 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. 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. 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 ? 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. (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. (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 (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? |