Drop "Expand abbreviations" feature?

[westnordost]

Maybe you knew, or maybe you didn't know, but in the road name quest in particular, you are able to write (for the English name) e.g.

Church Rd

and when you then either type a dot ., space or press the ⏎ key on the keyboard, then this will automatically expand to

Church Road

This works on many road abbreviations, the data for this is maintained in this repository in /app/src/commonMain/composeResources/files/abbreviations/, e.g. for English it looks like this.

This is a very old feature, it has been around since the road name quest was first implemented, i.e. before StreetComplete v1.0. There is a hint for this feature above the input fields, it says "as written on the street sign, abbreviations are expanded:". I noticed, however, that in several languages it has been slightly mis-interpreted by translators, e.g. the German translation mentions that "abbreviations are to be expanded" rather than that they "are expanded" (automatically).

---

But I am now considering to drop this feature (after I meticulously re-implemented it for compose & multiplatform in #6403 😮‍💨), because...

1. as any crowd-translation-thingy, it is incomplete, i.e. for some languages maybe all common abbreviations are mentioned, for others, some or all are missing. Hence, a user can not blindly rely on this feature. (This is just a point that diminishes its usefulness)

2. for users who know this feature, the effort saved by automatically expanding e.g. "Rd." to "Road" seems pretty negligible. (Another point that diminishes its usefulness)

3. also, not all abbreviations are included. There is this huge wiki page on Abbreviations and their expansions, for English alone, it includes hundreds of more abbreviations and it is not clear how common each of those are (on street signs), after all, we absolutely want to avoid any automatism that turns out to add wrong data sometimes, e.g. if "Arc" was always auto-expanded to "Arcade" but maybe there is actually a road named "Something-something Arc". So, maintenance-wise, this is a bit of a bottomless pit, and depending on what is suggested quite hard to judge whether any proposed abbreviation expansion is common enough that it should be included or not.

4. Lastly, the expansion of abbreviations is pretty aggressive. The text is expanded while the user types and directly replaces the previously written word. On a desktop computer, one might know this UX where the suggested expansion is shown highlighted and one could apply it with ↹, but there is no tab key on smartphone keyboards anyway. The smartphone equivalent of a UX like that would be the use of this "suggestion bar" but the app cannot tell the IME what that space should contain.
   So, if the user doesn't want to apply the expansion, he's gonna have a really hard time, it's basically not possible.

As a counter point, auto-expanding abbreviations somewhat solves the "answerable by anyone" requirement when in a foreign country with foreign language and asked to "please always write the full name, not abbreviations" by the app. On the other hand, that's not a feature the user can always rely on and in case the user really doesn't know the expansion for a particular abbreviation, it does no damage to add the name with abbreviation anyway and let others correct it afterwards while wrongly auto-expanding a name would cause damage.

So, the status quo, with the quite limited set of abbreviations is probably not causing any problems currently, but maintenance might, and I am asking myself if it is even worth maintaining given the potential issues and the seemingly small convenience benefit.

What do you think, @mnalis @peternewman @matkoniecz @FloEdelmann @Helium314 ...?

[peternewman]

This works on many road abbreviations, the data for this is maintained in this repository in /app/src/commonMain/composeResources/files/abbreviations/, e.g. for English it looks like this.

As an aside, would it be worth pulling out to https://github.com/streetcomplete/countrymetadata or a language specific version? So others can more easily reuse it?

There is a hint for this feature above the input fields, it says "as written on the street sign, abbreviations are expanded:". I noticed, however, that in several languages it has been slightly mis-interpreted by translators, e.g. the German translation mentions that "abbreviations are to be expanded" rather than that they "are expanded" (automatically).

Can you fix the translation issue with a translation hint (and staling the translations)?

But I am now considering to drop this feature (after I meticulously re-implemented it for compose & multiplatform in #6403 😮‍💨), because...
2. for users who know this feature, the effort saved by automatically expanding e.g. "Rd." to "Road" seems pretty negligible. (Another point that diminishes its usefulness)
4. Lastly, the expansion of abbreviations is pretty aggressive. The text is expanded while the user types and directly replaces the previously written word. On a desktop computer, one might know this UX where the suggested expansion is shown highlighted and one could apply it with ↹, but there is no tab key on smartphone keyboards anyway. The smartphone equivalent of a UX like that would be the use of this "suggestion bar" but the app cannot tell the IME what that space should contain.
So, if the user doesn't want to apply the expansion, he's gonna have a really hard time, it's basically not possible.

As a counter point, auto-expanding abbreviations somewhat solves the "answerable by anyone" requirement when in a foreign country with foreign language and asked to "please always write the full name, not abbreviations" by the app. On the other hand, that's not a feature the user can always rely on and in case the user really doesn't know the expansion for a particular abbreviation, it does no damage to add the name with abbreviation anyway and let others correct it afterwards while wrongly auto-expanding a name would cause damage.

There are definitely signs in the UK with the abbreviated form ( https://shadycharacters.co.uk/2020/06/miscellany-88-street-signs/ ) and the wiki is also pretty clear that abbreviations shouldn't be used ( https://wiki.openstreetmap.org/wiki/Abbreviations although I find slightly interesting given it breaks ground verifiability). There are also clearly people not expanding when they should ( https://taginfo.openstreetmap.org.uk/keys/name#values ).

As a compromise, and a safety net for four, and maybe a nudge for when it sometimes won't work, would adding a modal dialogue help? If I enter "High St" it could pop up a dialogue saying "Abbreviations shouldn't be used, did you mean High Street?" or similar, where you can choose to accept the abbreviation, or reject it and keep what you typed?

To make better use of the data, and if you can't override the suggestions bar, what about also adding a row of buttons below the text input field (like the building height favourites, which could list the most popular or most recent words as abbreviations, and auto-fill with the full name. So I could type "High" then press St and it turns it into "High Street". Which would also mean less typing, I have to type "Boulev" before my phone offers me Boulevard for example, and even "Clos" before I get Close.

3. also, not all abbreviations are included. There is this huge wiki page on Abbreviations and their expansions, for English alone, it includes hundreds of more abbreviations and it is not clear how common each of those are (on street signs), after all, we absolutely want to avoid any automatism that turns out to add wrong data sometimes, e.g. if "Arc" was always auto-expanded to "Arcade" but maybe there is actually a road named "Something-something Arc". So, maintenance-wise, this is a bit of a bottomless pit, and depending on what is suggested quite hard to judge whether any proposed abbreviation expansion is common enough that it should be included or not.

FWIW, the "full" list is also problematic in that you'd need country specific versions of English for example, as according to that, Ctr converts to both Centre or Center depending on which side of the pond you live. Or I guess more practically a base common English list, and then en-GB/en-US variants etc.

[mnalis]

pl.TL;DR: I personally would not find it a big loss if that autocorrect is gone. But for many, showing that "please expand any abbreviations" popup dialog might still be quite useful to train users to enter full names when possible. But autocorrect is more problems then it's worth IMHO.

---

as any crowd-translation-thingy, it is incomplete, i.e. for some languages maybe all common abbreviations are mentioned, for others, some or all are missing

Yeah... For me, I was not even aware of that feature. In fact, I was one of those who translated it incorrectly, led on by my own experience of SC:

• for Croatian, the database is not very good (to say the least). So I never noticed that particular feature even existed.
• In fact, only now after I was made aware this feature exists have I been able to find one abbreviation that works ("ul." for "ulica" meaning "street" -- None of the other common cases e.g. "av." for avenija/avenue, "sv." for sveti/saint, "dr." for doktor/doctor, "pl." for plemenitog, "odv." for odvojak, etc. actually auto expanded... Update after checking the code: yeah, there is really only that one abbreviation for Croatia 😄)
• But there is that other popup window which detects strings with "." in the name and warns to expand them, so when translating I assumed it was talking about that feature (which I did notice but very rarely)

For my use:

• I find unskippable auto-correct extremely annoying generally. While for that particular one case of autocorrect that I've found I didn't have a need to keep "ul." in that form, I would not be amused if I had a need to battle it. Of course, a preference to disable autocorrect would fix that particular issue for me, but I know SC does not like preferences (and for a reason).
• also, if I'm being in some other country (like e.g. Hungary) I would likely have absolutely no idea if the expanded abbreviation is correct or wrong; I could only type what is on the sign...
• for Croatian, I would find most keyboard autocorrect/autocomplete would work just as fine (if not better) as replacement for shorter typing¹

---

As a compromise, and a safety net for four, and maybe a nudge for when it sometimes won't work, would adding a modal dialogue help? If I enter "High St" it could pop up a dialogue saying "Abbreviations shouldn't be used, did you mean High Street?" or similar, where you can choose to accept the abbreviation, or reject it and keep what you typed?

Yeah, that might work maybe. Note that similar modal dialog but with just detection is already there (whether it detects "Rd" in USA is another issue; for Croatia in detects abbreviations e.g. "sv.", but then again we always end abbreviations with ".", so it is is trivial for us).
Current dialog does not offer semi-automatic-correction though -- that might be more problematic to implement, esp. if there are multiple abbreviations or if it is positionally dependent - e.g. with "St Peter Rd":

• "St" might be "Street", or it might be "Saint" (I guess). You need at least positional checks so appropriate expansion if offered. But current use of Regex should probably be good enough for most if not all cases. (e.g. "^St" vs "St$" vs "\bSt\b").
• it that example, there should be two modal dialogs shown one after another here: one for expanding "St" to "Saint" and another for expanding "Rd" to "Road". That situation at least seems somewhat common (at least in Croatia), and there might be cases where even more dialogs then two might pop up 🤷

That might be busy and problematic. I don't know if autocorrect part of the modal dialog would be worth it 🤷‍♂️

I mean, after few warning dialogs, users might found out that typing "Road" is actually much easier (and less error prone) than typing "Rd" + reading the modal dialog to find out what is being corrected and then clicking on appropriate answer. More likely users will just train to blindly click on "I accept the change" without reading, which ain't that good a result.

So, Even just detection as currently² done works best for me, as I can say I'm sure and I want to leave it as is, or I can go back and correct it. (But, as usual, my preference is "warn mapper about potential problems; but let them make a final decision", so whatever fits that is fine with me).

The disadvantage of that suggestion however is that all this code, tests, complexity, need to maintain it etc. still remain (which I suppose @westnordost would like to get rid of - if it is not going to be missed) -- and there also is a need for someone to curate those abbreviation databases. (esp. for languages which abbreviate things in non-trivially detectable ways)

Which would also mean less typing, I have to type "Boulev" before my phone offers me Boulevard for example

That sounds like a keyboard problem to me (or at least its configuration; if it has custom user dictionary support); at least on Android (where keyboards are replaceable; I don't know about iOS) there are many options to choose from.

Footnotes

1. even if I myself do not use them but prefer to type the thing myself -- because it is not much slower, and even if I make a typo, it is would be much easier to detect (i.e. misspelled word, instead of completely wrong but correctly spelled word), and it helps train me being more precise which I find preferable to being trained by piece of software to become more error prone and lazy at the same time 😅 ↩

2. of course if detection does not work for other countries, it should be fixed then; for Croatian it seems to work fine. ↩

[matkoniecz]

I have no real feelings about this feature.

On one hand I am also suspicious about such "smart" features, on the other it has decent chance to cleanup data.

But what is the risk of mangling data here?

Either way, if feature stays something should be done about mangled translation.