Bug 7108

Summary: Lists of "Similar" languages break display across multiple lines in both Opac and Intranet
Product: Koha Reporter: Martin Renvoize <martin.renvoize>
Component: TemplatesAssignee: Martin Renvoize <martin.renvoize>
Status: CLOSED FIXED QA Contact: Marcel de Rooy <m.de.rooy>
Severity: normal    
Priority: PATCH-Sent (DO NOT USE) CC: chris, m.de.rooy, oleonard, paul.poulain
Version: 3.6   
Hardware: All   
OS: All   
See Also: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7644
Change sponsored?: --- Patch complexity: ---
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
Attachments: Screenshot of Problem
Proposed Patch
Signed-off patch
Patch for Intranet
Bug7108: Intranet Language Menu Display Patch

Description Martin Renvoize 2011-10-27 17:23:31 UTC
Created attachment 6081 [details]
Screenshot of Problem

For the quick description see screenshot attached.

Detailed Description

If multiple similar languages (i.e: fr-FR, fr-CS or en, en-GB) are installed and  the opaclanguagesdisplay preference is set to allow patrons to choose a language then at each occurrence of a language with multiple options the display is the selector splits across multiple lines breaking the display.
Comment 1 Martin Renvoize 2011-10-27 17:47:13 UTC Comment hidden (obsolete)
Comment 2 Owen Leonard 2011-10-27 18:35:08 UTC
I can't reproduce this problem in IE8 on Windows 7. I see the problem in Chrome (14), but this patch doesn't correct it. What OS and versions are you testing in?
Comment 3 Martin Renvoize 2011-10-28 11:09:17 UTC
Hi Owen, 

I'm currently testing on Linux running Chrome 15, have also testing in various versions of chrome on both Windows 7 and Ubuntu linux. All seem to have the problem, and all seemed to be fixed by the patch,.. as long as you did a hard refresh as chrome caches way too much.

IE, I was using IETester on Windows 7 to test for versions 5.5 onwards.  Version 5 behaves badly in all sorts of ways, but I haven't tried to cater for it in my patch. I was seeing problems in IE 6 and 7, but they appear to have cleared up without the patch. So maybe it's just a Chrome problem.
Comment 4 Martin Renvoize 2011-10-28 11:30:07 UTC
Silly question regarding a possibly reason you can't see the fix in chrome. Did you apply the patch and then re-install the translations?  My patch only patches the file's within en, so to get it to apply to each translation installed you'll need to re-install the translations.  (I just found this after spending a number of hours getting confused to why it had stopped working for me.. I had en-GB installed and it was defaulting to that instead of en and therefore ignoring my changes.)

Martin
Comment 5 Owen Leonard 2011-10-28 12:40:38 UTC
Created attachment 6088 [details] [review]
Signed-off patch

> I had en-GB installed and it was defaulting to that instead of en and
> therefore ignoring my changes.

You're exactly right. I didn't expect my browser to pick en-GB on its own! I can confirm now that the problem exists in Chrome (and Safari, so it must be a WebKit thing). I still can't reproduce the problem in IE (even in IETester), but the patch doesn't seem to have any negative impact on any browser so I'm happy to sign off.

Looks like we'll need a similar fix for the staff client. Have we been so negligent in testing in WebKit browsers, or did the rendering engine get revised?
Comment 6 Martin Renvoize 2011-10-28 13:41:32 UTC
Cheers Owen, I think the bugs been in webkit for quite some time without being spotted. 

I'll have a bash at producing something similar for the staff interface, as the bug is actually worse there, hiding some languages all-together as the div is fixed to the bottom of the browser.

as a note, should I create a new bug for that and post a patch to that (possibly linking to this too) or just add the patch here? Still getting my head around koha procedure.
Comment 7 Owen Leonard 2011-10-28 14:00:00 UTC
> as a note, should I create a new bug for that and post a patch to that

Either way is fine. The problem is similar enough that you could put it here too and update the title of the bug. If you'd prefer to track them separately that's an option too.
Comment 8 Martin Renvoize 2011-10-28 14:46:20 UTC Comment hidden (obsolete)
Comment 9 Chris Cormack 2011-11-03 02:54:21 UTC
Created attachment 6158 [details] [review]
Bug7108: Intranet Language Menu Display Patch

Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Comment 10 Marcel de Rooy 2011-11-28 09:48:07 UTC
Owen, 
Did you test the languages_loo.plural case?
I did not test it, but wonder if the | comes at the right place in that situation?
Should it be: Lang1 | Lang2a Lang2b | Lang3 ?
And wouldn't it become now: Lang1 | Lang2a | Lang2b Lang3 ?
Comment 11 Owen Leonard 2011-11-30 17:38:24 UTC
I tested with these languages enabled: en, en-GB, en-NZ, fr-FR, fr-CA, & cs-CZ
Comment 12 Marcel de Rooy 2011-12-01 07:40:02 UTC
Thanks for responding. Tested it myself now too.
Marked as Passed QA.
Comment 13 Paul Poulain 2011-12-06 11:00:03 UTC
patch pushed, please test
Comment 14 Paul Poulain 2011-12-06 11:08:56 UTC
hey ! man ! you're 160th (just added in history.txt) !!! (http://git.koha-community.org/gitweb/?p=koha.git;a=commit;h=914d4d43529b83fa7318ea261398e16306790364)
Comment 15 Martin Renvoize 2011-12-06 11:18:53 UTC
That's kinda cool.. :)  Great to see we've got so many contributors!

I'll have to start patching more often now I've worked out the procedure.

Cheers
Comment 16 Jared Camins-Esakov 2012-05-23 23:55:00 UTC
This was incorporated into the 3.6.x branch prior to 3.6.4.
Comment 17 Martin Renvoize 2021-03-30 08:08:14 UTC
10 years later and I'm still hacking on Koha.. :)