Automatically choose preposition-article contraction in Portuguese

[1ec5]

Issue

In #283 (review), @xendez and @jppcel contributed new translations for Portuguese and pointed out that certain names would need a different preposition-article contraction depending on the grammatical gender of the name. This PR adapts the French grammatical system that @yuryleb implemented in #252.

I came up with the list of rules and tests by querying OpenStreetMap for name tags on highway ways in Lisbon and Rio de Janeiro. (I’m not sure if those two cities are representative of road type designations elsewhere in Lusophone countries, but we can always manually add more road type designations.) I isolated the road type designations but stripping all but first word of each multiword name, then removing duplicates, given names, and acronyms. Finally, I looked up the grammatical gender of each word in the English and Portuguese Wiktionaries and identified a limited set of lexical patterns. (Hopefully my limited Spanish didn’t bias the final rules in any way.)

Because I started with road names, these rules are somewhat unlikely to have great results against the place names that one would see in the destination and waypoint_name variables. But again it’s just a start.

A starter list of abbreviations has also been added based on some common abbreviations I found on street names in Lisbon and Rio de Janeiro.

Before merging, it’d be great to get feedback on the following:

• Does it make sense to apply these rules to all instances of “em” and “a” followed by destination, junction_name, way_name, or waypoint_name?
• What prepositions should we fall back on when we’re unable to determine the grammatical gender lexically? (There seems to be a lot of ambiguity in Portuguese due to etymology that isn’t obvious from the spelling.)
• Are there any cases where a particular road type designation shouldn’t be preceded by an article?
• Are there any adjectives that can be either gender and commonly precede the road type designation (akin to “gran” in Spanish)?

Tasklist

• Collect road type designations
• Look up grammatical genders
• Devise grammar rules
• Add changelog entry
• Test with osrm-frontend (?)
• Review

Requirements / Relations

Depends on #283.

/cc @danpaz

[yuryleb]

And maybe also item for "generic" Portuguese 'pt': abbreviationsPt,?

[1ec5]

This PR copies the abbreviations object to two keys for consistency with the translation files, but the client is expected to perform some sort of locale matching. Even if we were to set pt, the environment’s locale may be something else like pt-AO or even pt-US. There are plenty of libraries that can perform locale matching, such as locale-utils.

I’m not necessarily opposed to setting the language-only locale, but I think we’d want to do so consistently for all languages and resource types, and I’m not sure that would be feasible for a situation like zh.

[yuryleb]

Actually I don't see the problem with this grammar use for all Portuguese dialects - grammar expressions will match only Portuguese street names even if pt-US will be used in US with English names. Or there is a difference in Portuguese articles usage inpt-BR and pt-US?

[1ec5]

Right, I think abbreviations and grammar rules should be available regardless of the specific Portuguese locale in use, but it should be up to the client to choose a country to default to. For now the two locales share the same abbreviations and grammar rules, but that wouldn’t necessarily be the case in the future for all languages, so I’d be hesitant to create an expectation that clients can look up grammars without performing locale matching first, which they have to do when getting a translated instruction.

If it’s a major inconvenience for clients to perform locale matching themselves, then we could have this library depend on locale-utils, but there are larger libraries with more robust locale matching and I wouldn’t want to force clients to use the more rudimentary logic in locale-utils.