Geocoding doesn't work for my places.
Although all places had been geocoded before the red needles are not shown when I choose the mapping function.

When I enter a "Edit Place" window, the fields for longitude and latitude are highlighted with pale red. After closing the "Edit Place" window by clicking "ok", the values for longitude and latitude have disappeared.

When I enter a "Edit Place" window, the fields for longitude and latitude are highlighted with pale red. After closing the "Edit Place" window by clicking "ok", the values for longitude and latitude have disappeared.

If they are highlighted with pale red they are not a recognized format for Rootsmagic, What I would do is click the GEOCODE button when in the Edit Place window and let Rootsmagic sort it out.

Any Places RM cannot resolve will be thrown up in the Gazetteer for your manual selection.

I did click the "Geocode" button, but after I close the window the data is lost.

I should have opened RM first, I was referring to the Geocode button on the top bar of the Place List window and not the Edit Place individual button.

I'm not sure how this has happened as I can't get RM to accept "non recognized" data in both latitude and longitude boxes. Was this something that just happened or just noticed, were the red needles showing up in RM Mapping and then suddenly stopped?

Geocoding/mapping does only work if Windows regional and language options are set to "English"I changed the Windows regional and language options from "German (Germany)" to "English (United States)" and it worked.

I am not keen on changing my regional and language options every time I work with RootsMagic. Please fix this bug.

We support multilingual or uni-coding, but the translation of the program is probably what you're referring to. We are waiting for the rewrite that will include the Mac version of RM to happen first before translation begins.

The geocode for place detail in a non US Windows environment doesn't work. I would kindly suggest to remove the word probably in your answer of March 13 and add it to the bug list (with as far as I am concerned considerable priority ).

The only reason I use probably is because if it was a designed to work a specific way and its not, then it's a bug. If it was not designed to support something then it goes on the enhancement request list.The big problem we have over here is we only use the US English version of Windows. We need to get other copies of Windows to develop to and test some of these issues. I'm not sure what category that "problem" goes under. I put it under a bug but it may not be one.

We support multilingual or uni-coding, but the translation of the program is probably what you're referring to. We are waiting for the rewrite that will include the Mac version of RM to happen first before translation begins.

Hello Renee,

is there a timeline when the rewrite for Mac version should be finished? You also have announced to write a direct import from TMG. Because TMG is used in many languages, it would be very good to have RM translated. So many users can migrate their TMG data to RM and use it in their native language.Is there also an expected date, when translation of RM will be finished?

No time frames for releases to be reported. That's because people get mad when we set dates and then can't meet them on time. The update with TMG direct import would have already been released by now if we didn't keep finding bugs to fix. I'm sure people would much rather have something that works then something thrown out there to meet a deadline.