ну вот и нет времени со всем этим разбираться. правильно все сделали, нужно только продебагить.
например, такая конструкция:
("sch", "щ", $val)
ну и как ему оббратно в кирилицу перекодировать, если встретится сочетание "sch"? считать отдельными буквами? он так и делает, умница. откуда ему знать, что это сочетание?
вот и нужно продебагить.
Например есть входной текст в URL НоутбукNoutbukНоутбукNoutbuk в транслит->NoutbukNoutbukNoutbukNoutbuk обратно из транслита->НоутбукНоутбукНоутбукНоутбук как данное обстоятельство обойти?
интересный вопрос, а заодно и новая вводная. "в лоб" ничего не выйдет - транслит всю кирилицу сольет в латиницу, и, соответственно, данный объект не найдет.
по чистому транслиту почему-то не работают 4 буквы - З, Щ, Ъ и Э.
теперь с новой вводной надо со всем разбираться заново.
интересно, а в других шопах это как работает? они, правда, там всю фразу целиком транслитерируют, а не по букве. может, в этом все дело?
p.s. можно попробовать сделать так, чтобы русские и английские названия были допустимы, но только чтобы название целиком было либо на русском, либо на английском - делать проверку: если после транслита страница не найдена, то еще раз прогонять без транслита, и только потом выдавать сообщение о том, что страница не найдена. как вариант...
p.p.s. проверил, как другие эту проблему решают. очень просто - дополнительным полем в базе, по которому и идет обращение к товару или категории. в isc же такого поля нет, поэтому транслит идет в обе стороны. как оказалось, с этим много проблем. так что пока наилучшим представляется хак, предусматривающий изменеие базы.
для себя я пока погожу это делать, нехай остается кракозябрами, пусть гугль с этим мучается