Сделал в первом приближении.
У конвертера два новых ключа:
–target-lang - на каком языке хотим карту
–default-lang - язык, на котором в исходнике записаны теги без указания языка
./osm2mp.pl --default-lang ru --target-lang en moscow.osm -o moscow.mp
сделает карту на английском
Конвертация между языками пока не сделана (пока не совсем понятно, где и как её описывать), есть только финальный фолбек на Text::Unidecode
ИМХО, удобнее (для пользователя) сделать возможность задавать порядок “нужности” языков.
По принципу “Хочу на русском, но если нет русского, то на украинском, если нет украинского, то на английском, если нет английского, то на дефолтном или транслитом с дефолтного (ибо дефолтным может быть какой-то иероглифический язык. который не понимает навигатор)”.
И, это… надо бы как-то всё-таки сделать функцию получения нужных названий улиц (для адресной базы) из name:lang отрезков улиц.
Потому что не везде привязка домов к улице сделана релейшенами.
И ещё… Можно нескромный вопрос: почему выбран Perl, а не какая-нибудь СУБД с программой-оболочкой? По принципу “перегнали карта.osm в базу данных, перелопатили как нам нужно, сделали экспорт в польский формат”.
Всё задумано гораздо круче 
Хотя такое тоже возможно, как один из вырожденных случаев.
По историческим причинам 
Хотя скорее всего он и сейчас был бы выбран.
Пока оснований для возражений/дополнений нет.
Сначала хотелось бы узнать, что такое “совместимый” язык (я полагаю, целевой - тот, на котором нужно получить карту) и что такое преобразование - как оно работает и на основании чело задается таблица (или какой-другой нетабличный принцип) соответствия?
Совместимый - это тот, для которого есть описанное преобразование в целевой.
А работать оно может как угодно, пока планирую сделать через плагины.
Думаю, что преобразование имен всех проблем не решает.
Например, Красная площадь - если она в Москве, то Red Square, а если Переславле Залесском - то Krasnaya Square.
Правильно, для таких случаев и есть языковые теги, которые смотрятся в первую очередь.
А для остальных случаев - преобразование
Тогда я не понял описанного алгоритма работы.
Вернемся к основным определениям.
Что в предложенной схеме подразумевается под словом “тег”? Является он самостоятельной сущностью или лишь атрибутом другой сущности?
name=“Красная площадь” - это тег или нет?
Да, в контексте осмоданных это тег.
А в контексте мультиязычности “тегом name” нужно считать весь бранч осмотегов <name, name:{lang}>, как значение одного и того же ключа name на разных языках. Когда это значение явно задано для целевого языка - используется оно, когда не задано - пытаемся хитрыми способами вывести его из других языков.
Доделал поддержку языковых преобразователей (через плагины).
В качестве proof-of-concept там есть транскриптор с украинского на русский 
Можно заценить: ./osm2mp.pl --default-lang uk --target-lang ru lviv.osm -o lviv.mp
А вообще можно хоть Google Translate присобачить, если будут желающие проспонсировать (он платный).
Или Яндекс.Перевод.
Еще бы расширить функционал в сторону возможности использования old_name.
Не надо ничего расширять, old_name по-старому подключается через таглисты
Да, смешно наверное получается:)
А почему
?
Вопрос:
Что будет в результате работы плагина? Подхватится ли name:ru на оба участка или для второго будет “улица Лэрмонтова”?
Не подхватится, конечно.
Вернее, может подхватиться, но для этого нужен хитро настроенный релейшен.
И на дома с addr:street=“вулиця Лермонтова” тоже не подхватится?
Если нет - то это ведь вроде несложно добавить, поскольку скрипт изначально устанавливает всем значение City(верно?) - соответственно по city+name+name:ru и city+addr:street можно делать перевод addr:street.
это ж транскрипция 
вы же не будете с английского транскрибировать? оставьте щ в покое
Для домов то же самое - может подхватиться только через релейшен.
И вопрос тут не в том, сложно это или нет (оно хоть и не сложно, но ресурсоёмко), а в том, что так неправильно. Такие вещи должны задаваться явно. А если явно они не заданы, то гадания “а вот надо поискать что-то неподалёку, у чего есть какие-то теги, а другие теги с чем-то совпадают, и взять у него третьи теги, а потом это повторить для каждого уровня” - это очень плохая практика.
Если есть таблица получче - давайте.
Ничего в этом плохого нету. Ну разве что ресурсоёмко.
Вы когда задаете name для улицы и такой же addr:street для дома то разве это неявно не привязывает дом к улице? Многие даже считают что это наиболее красивая/коректная схема, а привязки через отношения - плохо.
А если уже привязались по name<->addr:street то почему бы не взять name:** оттуда где оно есть?
Без перевода addr:street proof-of-concept, ломающий адресацию, имхо бесполезен.
Эти многие считают неправильно.
Я не первый год смотрю на осм в качестве пользователя данных, поэтому когда говорю, что такие вещи должны быть заданы явно, - это не взятая с потолка фраза, а выстраданная горьким опытом. Практика-с
addr:street переводится по тем же правилам