Arrival instruction includes an optional named waypoint

[danpaz]

Issue

Updates compile to accept an optional parameter options.waypointName to use in the arrive instruction. When the new parameter is provided, compile replaces the default arrival instruction You have arrived at your {nth} destination with You have arrived at {waypoint_name}.

For example:

You have arrived at your first destination

becomes

You have arrived at Somewhere

For the localizations, I copied the default arrival instruction and modified it manually to create the new named template. In most languages this was pretty straightforward to do, but for some languages I made an effort but am not 100% confident with the result. I'll highlight these in comments below for feedback from anyone with better knowledge of those languages.

Tasklist

• Add changelog entry
• Review

/cc @1ec5 @lyzidiamond @bsudekum @allierowan @mcwhittemore

[yuryleb]

It's better to change this text and below to "Вы прибыли в пункт назначения, {waypoint_name}". Otherwise currently used form requires prepositional case applying to {waypoint_name} value.

And maybe it's better to publish new strings templates in Transifex first?

[danpaz]

Thanks @yuryleb, does that mean the grammar rules applied on this line will not take care of it for us?

[1ec5]

And maybe it's better to publish new strings templates in Transifex first?

One of the unfortunate aspects of OSRMTI currently is that adding a new string requires immediately adding something in each of the languages, whether that’s a copy of the English string or something hacked together based on preexisting translations. Transifex can only pick up new strings once the initial PR lands.

We could just insert English everywhere as a placeholder, but that would result in a temporary regression in all other languages. Regressing translation coverage isn’t necessarily a big deal, but some languages have taken months to update, even if it’s just a matter of adapting an existing string as this PR does. #84 and #155 track figuring out a better process for adding new strings.

[1ec5]

Thanks! A few comments about specific stopgap translations, but we can always address them in a separate PR once translators get a chance to see these new messages in Transifex.

[1ec5]

The correct token to use here is probably either {waypoint_name:date} or {waypoint_name:accusative}, but I’d defer to @yuryleb. We can also fix this afterwards, once the strings are in Transifex.

[yuryleb]

Actually no, grammar rules work only with street names but waypoint_name could be any name :sad: So it's much easy just to change source strings to force nominal case for names than to extend grammar rules to handle any names.

[1ec5]

Good point, I didn’t really consider how the open-endedness could break the grammar rules’ assumptions. Since the client knows more about the waypoint name’s semantics, it could conceivably call grammarize() depending on whether it’s a street name or something else, but that wouldn’t happen by default. So I agree that putting the name in an appositive, as you suggested in #235 (comment), neatly sidesteps the problem. I think we’ll need to do the same thing for at least one other language anyways.

[1ec5]

“Đến {waypoint_name}” would be better, but I can also fix this up in Transifex after the fact.

[1ec5]

I’m not sure if the 目 is necessary, but we can address this as part of #233 if necessary.

/cc @wingwuyf

[wingwuyf]

@1ec5 目 is not necessary, 目的地 is a single Chinese vocabulary. I think it should be "named": "已到达{waypoint_name}"

[1ec5]

9a6a980 updates the test scripts so that UPDATE=1 also updates any named translations. b9d776e fixes the Simplified Chinese named waypoint arrival translations, per #235 (comment).

[danpaz]

Thanks everyone! I updated the Russian translations per #235 (comment). Planning to merge and cut a release with this feature shortly.