Observations, suggestions and errors - SRB maps/app

[ZeljkoBG]

Maps and the application for Serbia were unusable. A few days ago I installed OM and saw that there is now a map in Serbian Cyrillic. The application still has no translation in either Serbian Latin or Cyrillic.

ROUTING
Today, instead of the OsmAnd app, I used OM from Work to Home. And I immediately noticed that it routes better than the OsmAnd app. Bravo!
This is not my final stand. I will test it tomorrow from Home to Work. And also on other rides around the city.

TTS
Text file for SRB TTS has non translated words. So during navigation hear the English word.
This in the app TTS txt, it's not good.
TTS text at this address https://github.com/organicmaps/organicmaps/blob/master/data/strings/sound.txt it's self-edited.
I would like to check out.
I don't know if I need your approval for amending the text. If I have to give them to me.

OSM SRB Cyrillic TAGs
On all OSM tags that show: Place name, destination, directions,... the 'lang:sr' code for the Serbian Cyrillic must be added.
See https://wiki.openstreetmap.org/wiki/Proposal:Destination_details#destination:lang:%3Clanguage_code%3E
OSM map https://www.openstreetmap.org/edit?node=4563470058#map=19/43.967248/19.549378
Examples:
destination:lang:sr
destination:lang:sr:forward
destination:lang:sr:backward
destination:lang:sr:forward
destination:lang:sr:backward
ETC

Without the Cyrillic code, we will get the name in both Cyrillic and Latin (separated with /) as in the picture

All I have to do is help and do it. The app is going in the right direction. Go ahead!

[patepelo]

Hey, thanks for the feedback. If you want to join the volunteer team of translations to SR, please communicate to @biodranik

Are you interested?

[patepelo]

Hey, thanks for the feedback. If you want to join the volunteer team of translations to SR, please communicate to @biodranik

Are you interested?

[ZeljkoBG]

This way https://github.com/organicmaps/organicmaps/blob/master/data/strings/strings.txt the translation of the text is not user-friendly.
If there is a way to translate a text FILE from English to Serbian, then I apply for translation.

I translated TXT for SRB TTS. And I sent to e-mail. I got a reply that I should upload a TXT... so it will be automatically converted to *json... I didn't understand how it was done. I asked them to insert the TXT file for TTS instead of me. They didn't want to and I gave up on translating the app. Imagine that I translate thousands of sentences/sequences and I don't know how to upload them to github. And they won't. So I did everything in vain.

[ZeljkoBG]

@biodranik
I need permission to proofread and translate the text for Serbian TTS.

[patepelo]

Hello, I just saw your email. Please understand there are a lot of things happening in OM.

For translations, you can start with small changes. Please wait to be added to the SR team.

[ZeljkoBG]

@zyphlar @biodranik did you understand the error in Oraganic Maps, which I described in the first post? Nobody answers me. Will the bugs be fixed in the next update?

[dobridabar]

This discussion touches serveral topics. Let me try to address them one by one:

1. App translation to Serbian - this is mostely done and recently merged into master branch, so it will be rolled out with the next release. There are two pending PRs, for Serbian translation of cousines, and F-Droid description in Serbian, but other than I think this is done.
2. Regarding Serbian tags in OSM, a lot of elements in Serbia, already have tags both with and without language specifier, e.g. https://www.openstreetmap.org/way/26491006:
   • destination="Ниш / Niš"
   • destination:lang:sr="Ниш"
   • destination:lang:sr-Latn="Niš"
     So the data is there, and where is missing it is up to mappers to add it. What is Organic maps doing wrong here? My understanding from @ZeljkoBG's description is that it should display destination:lang:sr when map language is "Serbian", but instead it displays destination, which is not ideal, becase direction name is duplicated.
3. Which also brings us to the problems of turn-by-turn navigation in Serbian. When you need to take a turn towards certain destination, city name (in above example "Niš") is read twice. If navigation would read destination:lang:sr instead, it would read it correctly, only once.
4. Also in navigation, there used to be one English word left in Serbian strings ("onto"), but this was fixed (together with other improvements), and already rolled out in the last released version.

So, I would say, points 2. and 3. needs further attention / discussion.

[zyphlar]

@dobridabar thank you! I'm unsure about point 2, I agree it's likely that OM simply displays (and for TTS, definitely just reads) the destination tag without language qualifiers. The assumption is that since OSM specifies this should be what's verifiable on the ground (in America we tag highways like ref=US 99 without words like "Highway" etc, but if the name is literally name=Papago Freeway then we'll tag that as such) that this value will mostly be accurate for most travelers in an area. The language tags then are mostly useful for foreign visitors to the area (how to translate "Papago Freeway" into Japanese? Probably just transliterating the word sounds, but maybe there are other language-specific needs?)

Notably, this assumption is totally false in India. OSM users there have decided that names should always be in English (one of the few common/official languages due to colonization) and local language names should be in their respective sub-tags. This means that unfortunately OSM in India is unusable by a huge percentage of residents in India, because they don't actually speak English (or often even Hindi!) so the language support feature you're talking about is very important and some work is being done there both for written text in OM and in the future for TTS.

It would be helpful to review any other issues/discussions for language support in Organic Maps' text, because I know it's an issue but I'm not involved in the fixes.

As for TTS point 3 "onto" and repeating "highway" etc, let's move that discussion to one of these places. I still need to design what the next version of TTS will look like but it's clear it needs to support a lot more complexity than is currently possible. We'll need to discuss specific strings in TTS in order for me to figure out how to reliably generate such strings across all languages, and a big question is how many languages are super complex like Hungarian and Dutch, and how many need some tweaking but can generally stay as-is (Japanese for example has complex "backwards" grammar but I'm told they prefer very short computer-y instructions anyway so it may not matter.) This helps determine if we need a new localization system/format, or just additional language-specific logic for a few languages.

Please review:

https://github.com/orgs/organicmaps/discussions/9702

#8412

Once discussion is moved to the appropriate places for points 2 and 3 then maybe this discussion can be closed?

[ZeljkoBG]

Let's forget the problem of "onto" and TTS because it is not related to this topic. Currently, the DISPLAY in the Cyrillic tags application needs to be solved. Circled in red in the picture. And these are the tags:
destination:lang:sr
destination:lang:sr:forward
destination:lang:sr:backward
ETC

OsmAnd had the same problem and they solved it immediately with my post. So it can be done.

[zyphlar]

The TTS system and the "next turn" display for navigation actually uses the same objects and code path, so if we solve on we'll solve the other.

Can you link me an OSM highway junction object that exhibits this problem so I can do some testing?

[ZeljkoBG]

this
https://www.openstreetmap.org/way/938210189
https://www.openstreetmap.org/way/286260826

this is a great example, for Destination Signs - https://www.openstreetmap.org/way/1205914973

[dobridabar]

It can also be slightly more complicated:

https://www.openstreetmap.org/way/33812392
https://www.openstreetmap.org/way/23721107
https://www.openstreetmap.org/way/9852936

First two example combine Serbian cyrillic and Serbian latin for multiple places in the same direction.

Last example combile Serbian cyrillic with English.

[zyphlar]

Ah I see. So because Serbia uses Cyrillic and Latin, many names are written repeated twice with a slash / ?

This is actually a somewhat big problem, because of how OSM considers multiple values. Are the signs on the street written with slashes too?

  destination
  	Сурчин / Surčin;Земун / Zemun
  destination:lang:sr
  	Сурчин;Земун
  destination:lang:sr-Latn
  	Surčin;Zemun

[ZeljkoBG]

No '/' on signs. Slash / - It is an agreement of the OSM community of Serbia, to separate the Latin alphabet from the Cyrillic alphabet when inscribed in the tag.

The map of Serbia in OM is in Cyrillic. Then the application should read map Serbia the tag destination:lang:sr (Сурчин;Земун) and no destination: . And on the maps of other countries to read the standard tag destination:
Thus, text will appear on the display only in Cyrillic and TTS will read only Cyrillic.
I already wrote that OsmAnd solved that problem exactly as I wrote.

[dobridabar]

Here is the photo of that particular sign:

https://www.mapillary.com/app/?pKey=919941705463662&lat=44.819984510406&lng=20.403940125545&z=17&focus=photo

[ZeljkoBG]

Is the photo and post intended for me?

[dobridabar]

No, it was intended to @zyphlar, to understand how typical highway sign in Serbia looks like.

[zyphlar]

Iiiinteresting. Looks like Serbia really is a special case. So we need to check if there is an existing issue for using the user's chosen language in the Destination ("nextStreet") display, and if not we need to make one and link this discussion there.

This will automatically take care of the TTS issue, since TTS just announces whatever nextStreet value is displayed.

It's possible some Serbia-specific logic will be required since we probably never want to show or announce the "/" destination value and only want to show/announce either the user's chosen language or sr or sr-Latn. Maybe it's only used when there's no other option, and in that case maybe we want to only show (or announce?) the part before the "/" (though that needs some testing since sometimes that is a valid character)