Bug 9425 - Template plugins are missing utf8 encoding
Summary: Template plugins are missing utf8 encoding
Status: RESOLVED DUPLICATE of bug 8215
Alias: None
Product: Koha
Classification: Unclassified
Component: Templates (show other bugs)
Version: Main
Hardware: All All
: P5 - low minor (vote)
Assignee: Fridolin Somers
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-01-18 14:50 UTC by Fridolin Somers
Modified: 2013-05-30 16:08 UTC (History)
1 user (show)

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


Attachments
Proposed patch (2.51 KB, patch)
2013-01-18 14:58 UTC, Fridolin Somers
Details | Diff | Splinter Review
[SIGNED-OFF] Bug 9425: Template plugins are missing utf8 encoding (2.84 KB, patch)
2013-02-06 16:12 UTC, Owen Leonard
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Fridolin Somers 2013-01-18 14:50:12 UTC
Koha custom template plugins KohaAuthorisedValues and KohaBranchName are missing UTF-8 encoding.
When they render a value with diacritical characters, those characters are replaced by a <?> sign.
Comment 1 Fridolin Somers 2013-01-18 14:58:11 UTC Comment hidden (obsolete)
Comment 2 Owen Leonard 2013-02-05 17:49:44 UTC
Thank you for the detailed test plan. However, I cannot produce the problem. I see correct characters before and after the patch.
Comment 3 Fridolin Somers 2013-02-06 13:13:02 UTC
(In reply to comment #2)
> Thank you for the detailed test plan. However, I cannot produce the problem.
> I see correct characters before and after the patch.

What string did you use ?
Comment 4 Owen Leonard 2013-02-06 13:41:47 UTC
Some nonsense constructions: Ļōŝŧ for a lost authorized value, and Čhauncey for a library name.
Comment 5 Fridolin Somers 2013-02-06 15:46:26 UTC
(In reply to comment #4)
> Some nonsense constructions: Ļōŝŧ for a lost authorized value, and Čhauncey
> for a library name.
Can you test with a simple diacritic like 'losté' ?
Comment 6 Owen Leonard 2013-02-06 16:12:48 UTC
Created attachment 15111 [details] [review]
[SIGNED-OFF] Bug 9425: Template plugins are missing utf8 encoding

Koha custom template plugins KohaAuthorisedValues and KohaBranchName are
missing UTF-8 encoding. When they render a value with diacritical
characters, those characters are replaced by a <?> sign.

Test plan :

For KohaAuthorisedValues :
- Edit a value of LOST authorized values to have a description with a
  diacritical character
- Edit a biblio to have an item using this authorized value in
  items.itemlost
- Go to OPAC detail page of this biblio => Lost description must be
  correctly encoded

For KohaBranchName :
- Choose a serial subscription
- Edit its branch to has a diacritical character in name
- Go to subscription details : serials/subscription-detail.pl
=> Library name must be correctly encoded

Signed-off-by: Owen Leonard <oleonard@myacpl.org>

I was finally able to reproduce the problem in the OPAC, but still not
in the staff client. However, since it's obvious the patch corrects
problems in some situations and doesn't seem to have an adverse effect
I'm signing off.
Comment 7 Marcel de Rooy 2013-03-26 13:56:05 UTC
QA: Looking at this one now..
Comment 8 Marcel de Rooy 2013-03-26 14:06:42 UTC
Can reproduce your problem in staff, but have doubts on your solution.
You encode the data while we are still processing in perl; this is theoretically incorrect but works since we still not activated utf8 in template processing. We should do that however; please see bug 6554.
Bug 6554 (adjusted) will solve your problem; I am inclined to mark your solution non-future-proof.
Comment 9 Fridolin Somers 2013-05-30 13:29:03 UTC
Bug 8215 has introduced new template plugins with utf8 encoding.
Comment 10 Marcel de Rooy 2013-05-30 13:36:54 UTC
(In reply to comment #9)
> Bug 8215 has introduced new template plugins with utf8 encoding.

With the revert of bug 6554 we are just messing around with encoding..
If you feel that this report now functions well, please set the status back to Signed off.
Comment 11 Fridolin Somers 2013-05-30 16:08:00 UTC
This bug is obsolete due to Bug 8215 integration.

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