Errors when using non ASCII characters in Organization Unit Name or Organization Unit Policy Code

[Eva Cerninakova]

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_browser.library_menu_init():
"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

[Eva Cerninakova (ece)]

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.

[Jane Sandberg (sandbergja)]

Thanks for all your research on this, Eva. I know that this was from years ago, but are you able to share any documentation/procedures you have on how to successfully localize the server environment?

[Eva Cerninakova (ece)]

The server environment localization just means adding Czech (or other) locale to Debian configuration - as root run:

     dpkg-reconfigure locales

and choose desired locale - in our case it was cs_CZ.UTF-8 UTF-8 and en_US.UTF-8 UTF-8

Then it is possible to chose one of the two available UTF-8 encoding.

We are running a few Evergreen installations and din't came across previously encountered errors until now - we use any characters in organizational unit names (e.g. Člověk v tísni, containing "č" and "ě") but we avoid using extended ASCII characters in organization unit policy code (just in case).

However, I guess the encoding problems described in this and related bugs might be bound to XUL client only. We are planning to test the issue again in detail after a new version of Evergreen is available and check if using the localized server environment is still necessary in "XUL client free" Evergreen version.