thomfre
+Premium Members-
Posts
571 -
Joined
-
Last visited
Everything posted by thomfre
-
This thread is related: http://forums.Groundspeak.com/GC/index.php?showtopic=337130&st=0&gopid=5563483entry5563483
-
I guess the fact that Groundspeak has been blacklisted has something to do with this: http://mxtoolbox.com/domain/mail03.Groundspeak.com/
-
Strikethrough is not supported by geocaching.com: https://support.Groundspeak.com/index.php?pg=kb.page&id=739
-
Release Notes (Website: Markdown) - February 2, 2016
thomfre replied to Geocaching HQ's topic in Geocaching HQ communications
Thank you for doing something about this But right now, no link is made at all. Can you please make it work so that in [url=http://www.thomfre.net/en/out-caching/us-trip-2015-summary/]Read more about our trip here[/url] , http://www.thomfre.net/en/out-caching/us-trip-2015-summary/ is treated as a link? Edit: typo -
Release Notes (Website: Markdown) - February 2, 2016
thomfre replied to Geocaching HQ's topic in Geocaching HQ communications
If the argument for not converting old logs is that only 3% used formatting, why spend so much time on making a new way to format for those 3%? Why not skip formatting all together? Rendering old logs, for the 97% that doesn't use formatting, as formatted, doesn't make sense at all. -
I still don't buy this argument. How about the description, which is more important than the logs, is still in HTML. If a device doesn't know how to render a log, it shouldn't know how to render the description either. And it is a big problem that a lot of logs are displayed wrong on geocaching.com now, since every 500+ million of them are treated as Markdown, even though only a tiny tiny part of them were actually meant to contain Markdown markup. Even displaying everything as plain text, dropping support for formatting all together, would be better than this.
-
This is what I don't get. HTML is a standard, and renders perfectly well both in GSAK and on my GPSr (Garmin). It also used to render well on geocaching.com. Markdown however, only renders fully on geocaching.com. I don't understand how that is being consistent.
-
Like this one: http://coord.info/GC5TBX0 Why can't the app set the date to the event date automatically when creating the Attended log? That should be a quick fix...
-
Project-GC uses the API, and will get your logs unformatted. Project-GC will still read **FTF**. MyGeocachingProfile requires you to upload your "My Finds" PQ, which also contains unformatted logs. MyGeocachingProfile will still read **FTF**.
-
Release Notes (Website: Markdown) - February 2, 2016
thomfre replied to Geocaching HQ's topic in Geocaching HQ communications
Please change your URL-regex to exclude ], so links don't get that messed up in old logs. -
Yes. I might have been a bit quick here, but GSAK will at least render HTML and BBCode correctly.
-
I would say the only reliable display is a 3rd party tool that respects both old and new logs, like GSAK.
-
I agree that the date should be modifiable, but why should we be allowed to set it to a date prior to when geocaching started?
-
This is going to happen more often. Sending HTML-emails without a text body, especially with images (which is exactly what Gspk does), will increase the score in most spam filters.
-
You could use the map, and filter on events: https://www.geocaching.com/map Or you can use Coming Events on Project-GC: http://project-gc.com/Tools/ComingEvents
-
GSAK has already implemented Markdown, and I would like to quote the release notes: Not only are old logs respected, but you as a user can tweak it the way you want! Why is it so difficult for Groundspeak to respect paying customers and their data? It's been pointed out several times already, thousands (millions?) of people have used thousands of hours to write logs, in the format they have been told they should write in. And suddenly, that format is changed. Not only will the old formatting look ugly, the logs may also change meaning if they happen to contain Markdown markup. So it's not only the 3% that was dumb enough to use something they were told they could use, that gets their old logs destroyed. Its everyone that was dumb enough to write something that Groundspeak's Markdown implementation will treat as markup. Groundspeak, please respect your paying customers. I guess it won't take long before 3rd party tools offer better ways to read logs, that respect old data, or before someone makes a user script to fix this. But that won't help the thousands of people that don't know how to use user scripts.
-
Yes, {*FTF*} is used a lot, at least in Europe. Project-GC and various other tools pick them up.
-
GSAK and Project-GC both access the same API. And none of them can make this work without new functionality in the API.
-
I made this nice test, in Norwegian, but I guess you get the point even if you don't understand Norwegian. On the first line, I start with a date - February 2nd, which is written "2. februar" in Norwegian. That suddenly becomes "1. Februar", the day before. Logical, isn't it?
-
Can you at least make the function that automatically links URLs exclude the old UBB-tags? If you look at the picture below, the link is including way to many characters, making it useless. Instead of linking to http://www.site.tld, it now links to http://www.site.tld/]Text Please fix at least that.
-
Thanks for joining the discussion HiddenGnome! So, you say that you're going to break the existing functionality now, so that you don't have to break it again? I appreciate that you make it testable, but why can't you add the tests first, and then change it? (that's how we do it where I work) What if you use your existing parser to parse all the logs, and store the parsed value as html. Then use a flag to just display those logs without running them through the new parser. You won't have any old logs interpreted as markdown, and none of them will be broken. I understand and appreciate that you want to improve. But you're taking away something that works, and replacing it with something that lacks a lot of features. Not that this is a big problem to me, but does this mean that the much used {*FTF*} will be displayed as {FTF}? I personally think that this change will lead to a lot of logs being wrongly formatted, because people write clear text that happens to be markdown syntax. I think just removing formatting all together would have been better (but keeping the existing would have been the best - as long as HTML is considered safe in the cache descriptions, I don't see how they should not be in the logs...). As an alternative to you doing the change, can you expand the API so that we can use the API to change our logs? Then we could use a GSAK macro, and get it done ourselves.
-
That is very easy to solve. They can just add a flag in the database that lets the system know that this log is using HTML. Just like the flag you have to say that your cache description is using HTML.
-
I agree with NinjaCacher!. I have more than 11 000 finds, and use UBB on many of them. Going through all of them will be a huge job. But why should I do the job of your developers? If you want to change something in our backend, aren't you the ones responsible for migrating the existing data? If we did this with any of our systems where I work, we wouldn't have any customers left. I can understand that you want to improve, and I appreciate that you do! But please be respectful to existing data, and your existing users. When you calculated the percentage of logs affected, did you also count Publish-logs and other logs with no content?
-
This is a normal way to do it. Look at Spotify, they also give you everything on your computer, but you need to pay to save it offline. I like that the people that support the game get something in return for it.
-
Cool thread! I love roadside attractions like this! I have a lot of pictures to post here, I just have to remember which caches to get them from Here's one from New Salem, North Dakota. Salem Sue, the world's largest Holstein Cow (GC1BBR9):