Why does Message Centre have to convert decimal points into clickable links?

[+barefootjeff]

I know this is discussed previously, but geeze this "feature" is annoying. Don't the people who created MC realise that decimal points are frequently used in "coordinates"; you know, those funny sets of numbers some of us use to locate caches with. Like this when I was trying to explain to someone why there is no "E" in the formula for my AL bonus cache coordinates:

 

 

27.DAC isn't a URL, nor is 26.CDB. Why oh why do these have to be converted into clickable links? MC isn't social media, it's a tool for helping people find caches and I'd wager it's far more likely that something with a period in it is going to be part of a set of coordinates than it's going to be a link to some viral YouTube video or whatever. Even if someone does have some obscure reason for wanting to include a URL into a message, why does it have to be made clickable anyway? Are people now incapable of copying a URL into a browser? I really wonder where this game is heading.

[+Viajero Perdido]

This should be embarrassing. Text like "forecast...better" (to borrow an example from real life) can't possibly be a valid URL, even in the foreseeable future. 

 

Edited June 17, 2022 by Viajero Perdido

[+arisoft]

5 hours ago, barefootjeff said:

Why oh why do these have to be converted into clickable links?

 

I have some difficulties to understand what are you asking. I think that you already know why this is happening.

 

Are you trying to ask why this is happening always? If so, you may have an idea how to filter unwanted links.

 

For our convenience, HQ has already decided that TLD must contain letters only. For example, S 33° 32.754 E 151° 16.162 generates no links.

 

If you add a trailing zero (for example, S33 27.DAC0) it will not be converted to a link.

[+barefootjeff]

46 minutes ago, arisoft said:

 

I have some difficulties to understand what are you asking. I think that you already know why this is happening.

 

Are you trying to ask why this is happening always? If so, you may have an idea how to filter unwanted links.

 

For our convenience, HQ has already decided that TLD must contain letters only. For example, S 33° 32.754 E 151° 16.162 generates no links.

 

If you add a trailing zero (for example, S33 27.DAC0) it will not be converted to a link.

 

I was trying to explain to someone how to solve the bonus cache for one of my ALs, but adding a trailing zero would be confusing because there's no trailing zero on the cache page. I'd likely then get asked, "How do I find the value for O?" Or are we now supposed to put trailing zeros on all coordinate formalae in multis and mysteries?

 

I wasn't even aware it was going to convert my copy-and-paste from the cache page into links because that doesn't happen until AFTER you click Send and by then it's too late.

 

I really would like to know why it's so necessary to convert everything that vaguely looks like part of a URL into a clickable link. Can people no longer copy-and-paste a plain text URL into a browser? Does everything have to be spoon-fed to them? I'm now starting to wish there was a way to just opt out of MC.

Edited June 17, 2022 by barefootjeff

[+arisoft]

53 minutes ago, barefootjeff said:

I really would like to know why it's so necessary to convert everything that vaguely looks like part of a URL into a clickable link.

 

We are used to enter only the domain name when using internet. Instead of typing a full URL as https//www.geocaching.com, we just type the domain part geocaching.com and that's it. Your 27.DAC is syntactically a domain name as GEOCACHING.COM and because the computer can not distinguish them from each other without additional steps, they are both handled the same way.

 

It is not necessasy to convert every domain name into a clickable link, but even the current link filtering by the TLD part of the domain is already failing by not creating a clickable link for any numeric URLs. For example, http://192.168.1.1 does not create a link despite the fact that it is a full URL and easily recognized.

[+Isonzo Karst]

I expect this is a built in feature of the software package Geocaching uses in the Message Center

 

It was part of one of the logging text package for a while.  changed from the old BBC code to mark up (mark down?)  Anyway, that bit was removed from the logging module. 

It can produce some very odd, but real links (some pornographic). I'm way too lazy to hunt for those old threads.

 

I haven't seen enough complaints about it as part of the Message Center to think they'll try to remove it. May not be possible. 

 

S 33 27. DAC

E 151 26. CDB

This won't link. I've added a space between the . and the letters   It scans okay to the eye, and ought to work. 

[+arisoft]

1 minute ago, Isonzo Karst said:

This won't link. I've added a space between the . and the letters   It scans okay to the eye, and ought to work. 

 

The next problem is that the coordinate checker can not parse coordinates correctly with an extra space. It just states "Those coordinates are not correct." without warnings.

[+TeamRabbitRun]

5 hours ago, arisoft said:

 

The next problem is that the coordinate checker can not parse coordinates correctly with an extra space. It just states "Those coordinates are not correct." without warnings.

 

That IS the warning.

 

Exact formatting required. You're talking to a basic computer program, not something AI-ish like google.

[+Hügh]

6 hours ago, arisoft said:

The next problem is that the coordinate checker can not parse coordinates correctly with an extra space. It just states "Those coordinates are not correct." without warnings.

 

Are you sure?

 

 

When I removed that space between the "." and the "2" it accepts as the correct coordinates.

[+arisoft]

1 hour ago, Hügh said:

Are you sure?

 

I am sure because I tested it forehand. With spaces it may try to convert the result to minutes and seconds.

Did you add space to both decimals?

Edited June 17, 2022 by arisoft

[+Hügh]

35 minutes ago, arisoft said:

 

I am sure because I tested it forehand. With spaces it may try to convert the result to minutes and seconds.

Did you add space to both decimals?

 

Oh, you know what, that's probably getting parsed as degrees minutes and seconds instead of the usual decimal minutes. Which is why it is parsing without complaint but not agreeing. The developers probably forgot to check if minutes/seconds < 60. 

 

Try navigating to https://www.geocaching.com/api/geocode?parse=N 60°... and look at the results. 

Edited June 17, 2022 by Hügh

[+thebruce0]

On 6/17/2022 at 1:25 PM, TeamRabbitRun said:

Exact formatting required. You're talking to a basic computer program, not something AI-ish like google.

 

It's actually quite simple to parse and attempt to recognize a variety of text formats in a script. No AI needed, no precise formatting needed. I've done it, and other websites do it. Parsing of coordinate text is done both strictly and loosely (but well) on gc.com already. One of the checkers does it well.  A string of text just needs a minimum for required formatting, and the rest can be assumed. 

 

For the URLs, I think the question is really more along the lines of does every single possible url NEED to be turned into a clickable link?  On mobile these days it's relatively easy to tap and select a 'word' (full url) to copy.

 

An alternative could be what social media platforms do, and not auto-sense-while-typing URLs, but do a URL check when posting/saving where the result of a request is tested, and if nothing comes back, don't treat it as a valid link.  FB for example also allows a user to remove link details (thumbnail/preview), so, another alternative could be allowing the message center to remove formatted links, or just choose to not auto-format them. That'd be a welcome option I'm sure.

 

But again, all that stuff may require a lot more custom programming if this functionality is part of an existing messaging package not developed by HQ.

Edited June 20, 2022 by thebruce0

[worrellsquirrel]

Our engineers are aware of this issue and are currently looking into a fix. Thanks for your patience in the meantime.