Cross domain scripts may fail to load over slow links, reducing functionality and impacting user experience.
Indian libraries on Koha ILS often use the
GoogleIndicTransliteration setting to provide Indian language search support to the OPAC search. The feature works by having your Koha sending a request to the Google’s servers to dynamically load the API code into the OPAC page and execute it, so that it is ready to translate what you type into the language you have selected for transliteration into. So basically you must have an active Internet connection on the system from which you are using the OPAC if you want transliteration to work. However as it turns out, that may not exactly be enough!
Yesterday Sujan Saha messaged me asking if the
GoogleIndicTransliteration setting was somehow missed out during setup of a particular OPAC instance. The screenshot collage above shows what he expected (on the left) versus what he got (on the right). Nope! the setting was very much there, so what was the case?
NOTE: If you are on Google Chrome, you can find it under More tools -> Developer tools option on the menu.
In this case, the console clearly shows the following warnings:
So basically a slow network link combined with a couple of cross origin parser blocking script (the Transliteration API code) is the reason why he saw no option for transliteration.
Quod erat demonstrandum!
Converting a batch of multi-lingual bibliographic records stored in a MS-Excel worksheet to .mrc using MarcEdit? Be sure to check your charset is set to UTF-8 while saving the spreadsheet or its CSV export.
Naveed Bhatti, a fellow Koha ILS user from neighboring Pakistan pinged last week over a problem he was facing. He had multi-lingual bibliographic data stored in an MS Excel worksheet. He wanted to use MarcEdit 6’s Delimited Text Translator tool available under the “Add-ins” menu to convert this file into an Unicode (UTF-8) encoded MARC21 (.mrc) file so that he could import the records into Koha.
However, when he attempted to generate the .mrk file (MarcEdit’s intermediate MarcBreaker mnemonic format before export to .mrc) instead of seeing the Arabic script, he saw a bunch of “?????? ????? ???” wherever there was text in the Arabic script in the spreadsheet. Naveed thought he must be missing something small but crucial, perhaps a setting.
I had a hunch, but I wanted to check the data before commenting. So I asked for a few sample records, which he sent over the next day. I checked and found it was a simple case of charset conversion glitch at the spreadsheet end of things. I could easily generate both the incorrect as well as the correct output (see above) with a simple change of the charset filter. I was using LibreOffice Calc on Windows 8.1 and the default export charset was *not* set to Unicode (UTF-8). The case being, with the default export charset the exported / saved file did not contain the correct Unicode codepoints in the data for the non-Latin data. As a result, at MarcEdit’s end, it became a simple case of garbage-in-garbage-out instead of receiving the correct non-Latin data.
The screenshot below shows the correct filter to use if you are using LibreOffice Calc. If you are using MS-Office, you should see something similar.