Translation explanation.

[ReinisSprogis]

Page Link

No response

Documentation is ...

Missing/Needed

Please Explain in Detail:

Hi. It is slightly hard to understand what each translation is for and that makes it difficult to translate.

Your Proposal for Changes:

Could add explain each section with example of how it will be used and how it will look when translated or used.
An example could be in English something like this.

"numerals": {
            "1": "1st",
            "2": "2nd",
            "3": "3rd",
            "4": "4th",
            "5": "5th",
            "6": "6th",
            "7": "7th",
            "8": "8th",
            "9": "9th",
            "10": "10th"
        },
        
Used to indicate what exit to take in roundabout. 
Example: Enter the roundabout and take the 5th exit.
Numerals are only used in context of roundabouts. 

I am not sure if it is used only in context of roundabouts. That would be useful if there was an explanations for translation file and probably fairly easy to do.
Thanks for consideration.

Forum Topic Link

No response

[koebi]

Hey,
thanks for the idea - unfortunately, it is not super straight forward to do so, since the *.resources-files are all JSON, and JSON doesn't have comments natively.
One would have to resort to a _comment-object, and check that this doesn't break anything or exclude it from resource-parsing.

In the meantime, is there some translation you are working on where this is unclear or you need help?

[ReinisSprogis]

Thanks for swift answer!
I might have not explained it correctly. I meant to add this info on website not in JSON.
contributing -> contributing-translations
https://giscience.github.io/openrouteservice/contributing/contributing-translations

I am currently working on Latvian and Lithuanian translations implementation. We have already translated files. I myself translated to Latvian, and asked our Lithuanian branch to do translation. I was told, that it is hard to understand context to provide best translation. And that plurar might not make sense. It would be good, if it was l10n for more customized translations. But I don't know yet. Now I will test Latvian out to see how it looks. But I suspect some might not work out correctly.
For example keep straight would work, but keep left translation would not make mush sense. However turn left would translate correctly. It seems like all turn_maneuvers translations would not work for all cases. As well we mainly don't use for navigation directions as north south west and east ... If navigation tells me go west, do I need a compass for that? :D

"pt" was bit confusing as well. Then I realized that it is public transport. But some might not. So explanation would be helpful on website. plurar for street names also might depending on instruction. I think not the street names, but word street itself.
street in Latvian translates to iela.
However if I am prompted to take a turn on some street, it would be "Pagrieztes pa kreisi uz Vlademāra ielas" So iela becomes ielas.
I am not sure what {name} is and {headsign}
Change to buss headed to name of some place?

Language is fairly complex with all the plural stuff going on. I'm no expert linguistic to know all edge cases. But translation options are not as flexible as with l10n .arb files for example. In arb files description of translation can be added, what would explain what this translation means and how it is used. But I suspect, changing .resources to .arb would be far from straight forward.

[ReinisSprogis]

I successfully added them both to my project and tested diving-car. And indeed plural is incorrect. I mean, it is probably better than not having language at all for those who understand only native. So I suspect Lithuanian will have similar problems. I'm not sure how to explain for non Latvian speaker.
It's feels similar like this would feel in English.
"Me got three child, it love play."

I tested out directions on Google maps, and they have the same or similar problems.
In goggle maps it starts with "Virzaties uz uz dienvidiem pa Gulju iela" They have few mistakes. By some reason they have extra "uz" what translate to "to" and "iela" should be "ielu" meaning street.

While in ORS now testing

"Dodies dienvidi uz Gulbu iela"
Should be "Dodies uz dienvidiem pa Gulbju ielu"
This one is fixable. Google using "Virzaties" word here. "Dodies" I used is also correct.
But the street names and word "street" itself is a bit complex part. And not always instructions has it. Then street name changes word ending itself.
We have these word ending a,s,u based on context. Perhaps I could do in on client side with some regex and try to make it better based on conditions. But not sure if this is the way.
Actually thinking now it might not be too bad. It is just bit hard to figure out all edge cases. Would be nice if there was some helper tool where we can upload language.resources file. Select country to get some random street names and see list of all edge cases how they will translate. Edit, and download edited file. This would help significantly to make translations. Now I am trying to request some routes that will include these instructions. I could contribute to making it. I could make it relatively fast in a day or two with flutter, but would need a little help from ORS providing all edge cases and API to get street names. Free tier from ORS should be more than enough as it's not like thousands of people will make translations every day. Could make a translations companion app or web app. Perhaps. I don't even need API to get street names. I could enter street name myself and show it in all edge cases.

[koebi]

Hey,

adding that to the documentation is a great Idea, that can definitely be done.
I don't know whether a helper for this little translation is worth the effort - probably a comprehensive list of (short) routing examples that include all the possible translations is good enough?

If the example was short enough and just included the one instruction in question, that would probably also help people to be able to find more examples in whatever region they are looking at.

[ReinisSprogis]

Thanks!
Improving documentation will help others to do translation and I will be able to go back and check if I can improve one I did. Examples as you mentioned would be much appreciated.

If the goal would be to get translations for as many languages as possible, then online tool would be helpful. But not a critical feature. I think that people who use ORS in their country and don't have language support they need will be the ones who will contribute most. With some online forms tool non developers would contribute as well. But improved documentation would be a good start!

Meanwhile I will do these two languages as good as I can and can submit pull request. Then can improve them when documentation will be updated.

[koebi]

We were planning to introduce an online translation tool like weblate or crowdin at some point, for all of the different services HeiGIT provides.

I guess that would suffice to get people on board, but since context/explanations would help there as well, that is indeed a good point for getting started.

[sfendrich]

Hey, thanks for the idea - unfortunately, it is not super straight forward to do so, since the *.resources-files are all JSON, and JSON doesn't have comments natively. One would have to resort to a _comment-object, and check that this doesn't break anything or exclude it from resource-parsing.

Maybe we should switch to yaml here, too?