Problem with "non English" text in receipt templates

[Eva Cerninakova]

In staff client in receipt template editor I entered a text containing Czech characters (like " Seznam vypůjčených exemplářů a dokumentů") and "saved locally" the template. Next time during the starting Evergreen staff client the message appeared:
Could not js-ify the JSON: SyntaxError: unterminated string literal
and when I opened the receipt template editor, I discovered the templates are set to default (i.e. all my previously locally saved templates vanished).
I tested the problem in Evergreen 2.6.2.
For the sake of completeness:, I suspect the problem occurred in previous versions too - until very recently we used version 2.2 and I am sure no one tested Czech locale from 2.3 to 2.4 (and 2.5 was tested only marginally).

Everything else works fine, i.e., when generating an entry with Czech characters in receipt (staff names, Czech book titles etc.), the characters are printed correct and no problem occurs.

The template that causes error because of the Czech characters (template for item status) and the template that works (without Czech characters) can be found here:
knihovna.jabok.cz/Evergreen/bugs/receipt_templates.zip

[Eva Cerninakova (ece)]

Problem still occurs in Evergreen 2.10.5

[Eva Cerninakova (ece)]

The problem happens in Evergreen 2.12 (version 0master.53150bb)

[Eva Cerninakova (ece)]

When doing some more testing I have foud following:

The error happens only when the non-standard Latin characters are added directly to reciept template. When they are used in the "include" (set in the Library settings editor) no error occurs (tested in cs-CZ)

After the non Latin string is "Saved Locally" in the Receipt template editor, when staff client is being opened again, the pop up error message appear after loging to xul staff. It happes when data are being loaded, exactly at the moment when loading "Default print templates set. This happens no matter what locale is being used.
After clicking OK in the error message window, everything seems to be OK, except the changes made previously in the templates during last staff client session have dissapeared and the templates has been back to default.

When trying replicate the same in Russian locale everythig was identical, except I got the "unhandled error" message (I have no idea, whether it had something to do with my testing o whether it happened just by accident):
FIXME: If you encounter this alert, please inform your IT/ILS helpdesk staff or your friendly Evergreen developers.
Thu Mar 02 2017 20:16:45 GMT+0100
Error during login sequence. The client will logout after this dialog.

Also, yns_alert failed: [Exception... "Component returned failure code: 0x80004003 (NS_ERROR_INVALID_POINTER) [nsIDOMLocation.href]" nsresult: "0x80004003 (NS_ERROR_INVALID_POINTER)" location: "JS frame :: oils://remote/xul/master_sb1/server/util/error.js :: <TOP_LEVEL> :: line 334" data: no]

By my opinion the problem is quite similar to this one: https://bugs.launchpad.net/evergreen/+bug/997284

[Eva Cerninakova (ece)]

This bug is probably related to bug 1674171 and bug 997284

I did some more testing related to bug 1674171 and discovered that the problem does not apply for all non ASCII characters

When receipt containing Čč, Ěě, Ďď had been "Saved Locally" in the Receipt template editor, when staff client was being opened again, the pop up error message appeared after logging to xul staff (see comment above) and the changes made in the receipt has been removed.

When receipt containing á, é, í, ň, ó, ř,š,ť, ú, ů, ý, ž, had been "Saved Locally" in the Receipt template editor, when staff client was being opened again, no error message appeared, however the characters in saved receipt has changed. E.g., the words „Příliš žluťounký kůň úpal ódy“ has changed to: „PYília ~lueounký koH úpal ódy“

[Eva Cerninakova (ece)]

It seems that the problem with extended ASCII has been solved by server environment localization (to Czech).
I would recommend to add piece of information to the documentation about Evergreen installation, that for some languages it necessary to use localized server environment to prevent crashes of some parts of Evergreen interfaces. I'm not sure which particular languages are relevant for this - definitely the languages with extended ASCII characters

See related to bug 1674171 and bug 997284

[Eva Cerninakova (ece)]

I recommend closing this bug as it si related to the XUL client only.

[Andrea Neiman (aneiman)]

Marking won't fix per Eva's comment