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.
Created attachment 14697 [details] [review] Proposed patch See commit message
Thank you for the detailed test plan. However, I cannot produce the problem. I see correct characters before and after the patch.
(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 ?
Some nonsense constructions: Ļōŝŧ for a lost authorized value, and Čhauncey for a library name.
(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é' ?
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.
QA: Looking at this one now..
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.
Bug 8215 has introduced new template plugins with utf8 encoding.
(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.
This bug is obsolete due to Bug 8215 integration. *** This bug has been marked as a duplicate of bug 8215 ***