Errors when using non ASCII characters in Organization Unit Name or Organization Unit Policy Code
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Evergreen |
New
|
Undecided
|
Unassigned |
Bug Description
1) When non ASCII characters is used for Organization Unit Policy Code or Organization Unit Name (or its translation to locale language) Holding Maintenance interface crashes and results in empty list of libraries, call numbers or copies.
Error message:
cat.copy_
"Could not js-ify the JSON: SyntaxError: JSON.parse: bad control character in string literal"
2) This applies not for all extended ASCII characters. When some of the characters are used, the Holding Maintenance interface opens normally and no error message appears (and the libraries, call numbers and copies are listed correctly). However in the "Limit to" field for the library selection some of these charracters are displayed incorrectly in the organization units list, see attached image.
I have tested the characters using sentence containing all special Czech characters: "příliš žluťoučký kůň úpěl ďábelské ódy" for organization unit name.
Finally I discovered that Holding Maintenance interface crashes when following characters are used:
č, ď, ě
(unfortunately "č" is used in the word "český" which means "Czech" and is used in the name of every other institution in the Czech Republic)
When following extended ASCII characters are used:
á, é, í, ň, ó, ř,š,ť, ú, ů, ý, ž,
the Holding Maintenance interface dose not crash, but in some cases the characters above are not displayed correctly (see image). I have tested the behaviour using Czech words "příliš žluťounký kůn úpal ódy". This happens with some of the special French characters too.
I believe this problem is related (or analogical) to bug 997284 and bug 1365581
With a new version of our test server (2.12.4) we tried to localize the server environment to Czech (we used English environment until recently). It seems that the problem has been solved by server environment localization. So far we didn´t came across any evidence that the Czech environment would have a negative impact on any other Evergreen feature or the English localization.
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 (probably the Czech is one the worst when it comes to extended ASCII).
The same solution applies as well to the related bugs:
bug 997284 and the bug 1365581.