search

steve8x8 / geotoad

Geocaching query tool written in Ruby
https://buymeacoffee.com/steve8x8
Other
28 stars 8 forks source link

Cache type recognition fails when language not English #313

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
Can't filter for traditional Caches. 
command line: geotoad -u XXX -p XXX -N -O -c "traditional" -q coord "4X.XXXX, 
8.XXXX" -y 10km.
filtering for other caches is working.

Original issue reported on code.google.com by Marco.Tr...@googlemail.com on 3 Jan 2015 at 3:08

GoogleCodeExporter commented 9 years ago 
Trying to reproduce - with a -q state query though - and failing, with current 
SVN trunk. There has been no modification to the filtering code for some time.

Which version of GeoToad are you using?

If you say other types are working, did you search for one type at a time as 
well? (The filtering mechanisms are different, and even -c 
traditional:traditional would make a difference.)

Can you re-run with one or multiple -v options set, save the (copious) output 
to a file, and look for lines containing "txfilter"? One of the following lines 
in the debug output should read "Getting results:" with a URL - what happens if 
you c&p that into your browser (while logged in)?

Original comment by Steve8x8 on 3 Jan 2015 at 8:09

GoogleCodeExporter commented 9 years ago 
I’m using the last stable version 3.22.1.
After creating a output file with -v I was able to find the problem. The 
created search string is working well, but the post- filtering is deleting all 
caches.
My preferred language is german. And after changing the preferred language at 
the Geocaching.com to english geotoad is working.

The problem is the name of the cache: 
german „Traditioneller Cache“ —> english: „traditional cache“.

Can I change this somewhere to use german as my preferred language?

Original comment by Marco.Tr...@googlemail.com on 4 Jan 2015 at 7:03

GoogleCodeExporter commented 9 years ago 
Thanks for your investigation. Here's what I had written as an answer to the 
notification email (before I recognized that wouldn't work):

Oh my goodness. I18n striking again (and since I don't speak Finnish fluently, 
and Korean not at all, there's little hope that GeoToad will ever support all 
20 languages).
I'm not sure how to overcome this, but let me summarize:
-c correctly sets the txfilter
a number of nearest.aspx result pages is being read
but afterwards caches are removed because their type as read from the results 
doesn't match the selection

In the first place, the later filtering is unnecessary (bug?) but multiple 
types should he supported as well, which would fail in the same way.

I've got to find out now how to get the English type names out of the results 
HTML code. For the time being, the only workaround is to switch to English in 
the user preferences :( That's what c:geo seems to do as well (and apparently 
for a purpose).

Adding done foreign languages to my set of tests now...

All hope isn't lost yet.

--- snip ---

Of course there's still hope, and there's another source for the cache type 
that isn't language-dependent. Can you use the appended, yet untested, patch to 
make search.rb aware of this, and check whether it cures the issue?

Thanks

Original comment by Steve8x8 on 4 Jan 2015 at 8:45

Attachments:

GoogleCodeExporter commented 9 years ago 
I gave the issue some more testing, and found that images don't always have 
numbers, which makes pattern recognition a bit more tedious. Also, in 
details.rb, some similar thing has to be done. Here's the latest approach, 
again to be patched against (3.22.1 or) latest SVN.

Original comment by Steve8x8 on 5 Jan 2015 at 1:18

Attachments:

GoogleCodeExporter commented 9 years ago 
I tried to patch the files. But unfortunatly it doesn't work. What tool can I 
use. Can you check in the modified files?

Original comment by Marco.Tr...@googlemail.com on 5 Jan 2015 at 3:44

GoogleCodeExporter commented 9 years ago 
On Unixoid systems, it's "patch" (with the -p1 option, to strip off the first 
part of the file path). Don't know about Windows - but IMHO the file structure 
is rather self-explaining ("-" lines to be removed, "+" lines to be added).

I've got to give the patch some more testing - for now, it doesn't break my 
daily routine anymore (as the previous attempt did), but I'm usually have 
English configured as my preferred language.

As soon as some tests with, say, Hungarian and Russian haven't shown anything 
weird, I'll upload to SVN - but no earlier.

Original comment by Steve8x8 on 6 Jan 2015 at 8:17

GoogleCodeExporter commented 9 years ago 
Thanks for explaining the way to patch the files.
After updating the system ist working.

Original comment by Marco.Tr...@googlemail.com on 6 Jan 2015 at 11:53

GoogleCodeExporter commented 9 years ago 
With a small exception you probably didn't notice: Multi-caches aren't properly 
shown by the GPSr, nor does filtering for them work. It's a capitalization 
issue, to be fixed with the commit, of course ("Multi-Cache" should read 
"Multi-cache", if you want to patch it yourself).

While I'm at it, I'd like to handle the "rare cache types" properly as well - 
could someone please provide me with a list (GC codes) or PQ file of: Project 
APE, Groundspeak HQ, Lost and Found (Celebrations), GPS Exhibitions, etc.? It 
seems that an increasing number of cache types isn't represented by a 
"numbered" image anymore :/

Original comment by Steve8x8 on 10 Jan 2015 at 10:06

GoogleCodeExporter commented 9 years ago 
Okay... I think I caught most of them (found/owned lists of GC HQ and 
Moun10Bike helped a lot).
Here's an updated patch against SVN 1674, might even work with the last release.

Further tests pending!

Original comment by Steve8x8 on 10 Jan 2015 at 11:15

Attachments:

GoogleCodeExporter commented 9 years ago 
And yet another take, this time including all known non-number cache type 
images (getting close now, I hope)

Original comment by Steve8x8 on 12 Jan 2015 at 8:40

Attachments:

GoogleCodeExporter commented 9 years ago 
... and uploaded (SVN 1676). Please give this some good testing, also in 
"exotic" languages (but limit your error reports to something I can read 
without using Translate services), thanks! (Planned release 3.22.2 in less than 
two weeks...)

Original comment by Steve8x8 on 12 Jan 2015 at 3:41

GoogleCodeExporter commented 9 years ago 
Supposed to be fixed (at least until new image names get used for standard 
cache types) by 3.22.2, closing

Original comment by Steve8x8 on 23 Jan 2015 at 10:19