Просто в большинстве случаев, система транслитерации/романизации составляется таким образом чтобы преобразование было более-ли менее днозначным (что в общем то понятно), мне же однозначность не сильно нужна, мне важнее варианты практического написания.
Так мне кажется, что задача-то обратная. Не из кирилицы получать латиницу, а наоборот. Из вольно написаной латиницы получить кирилицу, и не один вариант.
Так задача то в чём?
Отобразить карту для латиноязычных пользователей? Тут годятся одни подходы.
Или сделать нечёткий поиск? Тут подходы нужны совершенно другие.
Для последнего - мне очень нравится система поиска у TomTom, вот с кого надо брать пример.
Там как раз решены эти проблемы, объекты индексируются и ищутся по звучанию, а не по написанию. Соответственно можно вводить как хочешь (хоть латиницей, хоть кирилицей) и с ошибками - поиск всё равно находит.
А у томтома один движок поиска в онлайн и офлайн версии один?
т.к. http://routes.tomtom.com меня не порадовал:
Екатеринбург - не нашел
Yekaterinburg - нашел то что нужно
Ekaterinburg - нашел дорогу Tumen - Ekaterinburg
Мне кажется тебе в самом деле нужен нечеткий поиск, чтобы искалось даже Jekaterinburg/Iekaterinburg, хотя ни в одной нормативной таблице такого варианта нет.
Mlodsc, Karadordevica. Другой латиницы у меня нет)
Нечеткий поиск который отловит Yekaterinburg/Iekaterinburg/katerinburg у меня есть.
Но это не серебряная пуля, чем ближе ты угадал возможные варианты ввода транслита - тем всеравно лучше.
Нет, разные.
Только что попробовал на андроидной версии - эти 3 варианта находит.
Правда эта версия чувствительна к некоторым ошибкам написания, iekaterinburg находит, а ikaterinburg уже нет.
Когда-то юзал версию под symbian, там и такие влёт находило.
Можно и так и так.
Можно ввести просто Ленина 46 - выведет ближайшие по текущему местоположению с сортировкой по дистанции.
Можно найти Екатеринбург, выбрать его, затем искать улицу.
А можно просто подряд набрать “екатеринбург ленина 46” - найдёт соответствующий дом.
Результаты показываются сразу, в процессе набора, можно до конца не набирать, а выбрать вариант из списка.
Тоесть ты Никит предлагаешь детектировать транслит на этапе разбора запроса от пользователя, потом восстанавливать оригинал и искать по вариациям того что запросил пользователь?
Это конечно тоже вариант, но вот этап определения языка, тоесть генерации описания для этих:
"EN-RU-1"
"EN-RU-2"
"EN-RU-3"
"EN-RU-4"
"SE-RU"
мне видится столь же трудоемким как и описание транслитерации и сбора вариантов практически применяемого транслита.
Опять же, если я сделал описание для “EN-RU-2”, “EN-RU-3” и т.д. то зачем мне их потом определять на уровне разбора запроса, мне дешевле индексировать сразу несколько вариантов записи а на уровне запроса ограничится ошибкой с дистанцией Левеншьтейна (ну или Н-грамный индекс построить).
В общем то я пытаюсь найти популярные и часто употребимые “языки”.
Базу (которая http://cldr.unicode.org) я посмотрю, там вроде в основном то что я уже видел (для кириллицы).
Тут было бы очень полезно отыскать наборы транслитерированных текстов, только транслитерированных пользователями при вводе, а не автоматом по одному из принятых стандартов.
Так просто можно статистику копить как люди искали и что (особенно если они не бросали после первой неудачи)
Если проанализировать последовательность запросо, то можно как-то прикинуть каких подстаново не хватает при поиске.
Ескали Ikaterenburg - не нашли, тут же искали Еkaterenburg нашли и успокоились, значит мена E на I вполне нормальное у пользователя явление и т.п.
Ну а какие тексты? СМСки латиницей уже мало кто набивает, разве забугорные соотечественники.
Вообще-то там надо искать такие тексты, мне приятели так и в скайпе отвечают и по мылу, ибо чаще всего у них на работе нет на клаве русских букв
Статистика конечно была бы сильно в помошь, но это у Яндекса или Гугла - статистика, а у меня с посещаемостью в 2 десятка человек/день - не статистика, а смех один.
Посмотрел логи, нашел топ 10 сканирований на уязвимые сервисы. Ищут PHPMyAdmin, jmx, SQLitePHPAdmin
По логам не очень понятно на сколько пользователь остался удовлетворен, но это повод более лучше следить за пользователями. Транслитом правда не ищут пока ничего.
Чтобы понять с чем ты столкнулся предлагаю сделать два шага назад. Почему это всё происходит:
у пользователя пальцы-сосиски и он промахивается на тачпаде
чёртов стиб джобс и его очередная поделка
чёртов дизайнер всея руси “буква Х - для лохов”
чёртовы википедисты “буква X - не буква”
пользователи у которых мизинец слабо двигается
пользователи у которых клавиатура дебильная и они часто промахиваются по кнопкам
пользователи которые привыкли печатать на одной клавиатуре, а им всучили другую
у меня в системе только язык ZYX, верните мой XYC!!!
“ошибки” “транслитерации”:
зависят от пользователя
зависят от конкретного устройства которым он делает запрос
зависят от уровня начитанности в каком-то языке или сленге (Ъ - не буква)
Выходы:
пытаться создать “правила” которые опишут это действо
скормить прорву данных фильтр Байеса и он сам научится лучше всех говорить
Пояснение:
Десять медиков-специалистов могут вылечить пациента 50% правильно, но экспертная система имеющая доступ к мировому банку данных сделает 60% правильный ответ. Ссылку забыл.
Кто круче: Байес или ручные “правила” нужно постоянно мониторить/реваулировать.