+++ This bug was initially created as a clone of Bug #1779814 +++

This bug is for re-implementing the Get Map feature for physical addresses in the address book, which went missing in TB 102. This looks like an obviously useful feature for regular popular consumption - much more convenient than opening the browser, opening the map, and then having to copy all parts of the address from TB into the browser by hand.

Even a basic re-implementation would help, which shouldn't be hard. Here's what we're currently doing afasics:

• only show the Get Map button when there's actual address data.
• concatenate the location information to a space separated or csv search string (should remove commas from empty fields) (string template)
• pass that into the respective query URL strings for Google Maps / Open Street Map (still string template)
• open the URL in a browser

The old URL strings still live here (and still working):
https://searchfox.org/comm-central/rev/9d99b2706b19fa0f9153d922f8234b1107270789/mail/locales/en-US/chrome/messenger-region/region.properties

(In reply to Alessandro Castellani [:aleca] from bug 1779814 comment #3)

The only relevant issue reported here is the missing "Map" feature from the old address book.
We didn't add that back because we need more work and a better integration in order to put that back.

Alex, can you add some hints what you mean with "more work" and "better integration"?
Could we restore a basic version soonish?

Current rudimentary "workaround"

It's not really a workaround because it actually needs significant extra manual work of creating the link beforehand.

(In reply to Anje from Bug 1779814 Comment 4)

I'm only adding this extra comment just in case someone finds this bug - they can use it as temp workaround.
It is possible to insert something like this into 'Web Sites' field.
http://maps.google.com/?q=<lat>,<long> and then enter suitable latitude and longitude data as appropriate.

(In reply to Thomas D. (:thomas8) from comment #1)

Current rudimentary "workaround"

It's not really a workaround because it actually needs significant extra manual work of creating the link beforehand.

(In reply to Anje from Bug 1779814 Comment 4)

I'm only adding this extra comment just in case someone finds this bug - they can use it as temp workaround.
It is possible to insert something like this into 'Web Sites' field.
http://maps.google.com/?q=<lat>,<long> and then enter suitable latitude and longitude data as appropriate.

It does not need that much effort. Copy and paste two bits of data.
In Edit contact, use the 'Web Sites' option because this auto creates http link, so you only need to copy paste : http://maps.google.com/?q=
Open google map - get location right click shows latitude and longitude, highlight over and it gets copied to clipboard, then paste that info after the ?q=
So you get : http://maps.google.com/?q=37.387213609316355,-122.05997015451764

It's not so slick as using the Get Map, but I used for ages before Get Map and currently it's a workaround until Get Map is available.

(In reply to Anje from comment #3)

It does not need that much effort. Copy and paste two bits of data.
It's not so slick as using the Get Map, but I used for ages before Get Map and currently it's a workaround until Get Map is available.

Yes, thanks for the workaround! What I meant is there'll be an extra effort of generating the link on the map, for which you need to enter the address data manually (or copy street, copy place, ...), then to copy the map location back into TB - which is definitely less slick than just hitting the Get Map button and just get to the right spot on the map.

This is not a severe bug.
It's indeed annoying but it's not a major blocker and a workaround with a URL is possible.

We're exploring the possibility to add an integrated map inside the contact view, if the user enables it.
The Address Book is still getting improvements and it will do so across the 114 cycle, but no 102 uplifts for this feature are scheduled.

Setting P3 for backlog as P4 is reported to be as "Do not use, this priority is for web platform test bots". :P
https://firefox-source-docs.mozilla.org/bug-mgmt/guides/priority.html

(In reply to Alessandro Castellani [:aleca] from comment #5)

I'm still wondering how hard it would be to just restore the old Get Maps button using the existing strings as an interim fix...

This is not a severe bug.

That's why I had marked it S3 = (Normal) Blocks non-critical functionality and a work around exists, which still looks like a good fit ;-) As discussed elsewhere, triaged defects should always have an explicit severity set.

It's indeed annoying but it's not a major blocker and a workaround with a URL is possible.

Sure. It's just that first creating the URL online (by manually putting all pieces of address data in) and then copying it back to TB is quite cumbersome, compared to just clicking the Get Map button...

We're exploring the possibility to add an integrated map inside the contact view, if the user enables it.

That's super cool if and when it really happens, however, in the meantime, our users would probably be happy just to have the old Get Maps button back to reduce their workflow suffering from its absence...

Setting P3 for backlog as P4 is reported to be as "Do not use, this priority is for web platform test bots". :P
https://firefox-source-docs.mozilla.org/bug-mgmt/guides/priority.html

Good catch! Not sure why "P4 - ...this priority is for web platform test bots" should be applicable to Thunderbird, but then, you never know and until we have agreed on a Thunderbird priority matrix which matches our release cycles, we can probably just stick to that.

I just realized that the region.properties strings are not exposed in Pontoon at all. It seems to be happening because of a misconfiguration in comm/mail/locales/l10n.toml. Many locales do have the file translated though, and it does show up in omni.ja. I am having second thoughts about resurrecting this feature with those strings though if remaining locales would not be able to translate them.