Something is wrong with the longitude field in the Places-Edit-Screen. It always shows in red, and editing sets the value to 0. To reproduce the bug you can do the following:
The found coordinates are correct, but the corresponding longidutde field shows in red and can’t be changed (will be set to zero). I get the same effect for all places in all my databases.
I think it could be due the separator character that is being used by the OS.
As a test can you enter the coordinate values with a period rather than a comma?
Update:
See this post Manually adding latitude and longitude - odd behaviour
Thanks, you are right. As discussed in the other thread, changing the comma to a period doesn’t work, but changing the system settings fixes it. Probably a bug in the input validation code of the field.
Of course, changing the system preferences is NOT a solution because it will break other applications. I have no problem using a dot as a decimal separator in an application with an English GUI, if only it would work.
Probably not. Coding fixes of this type are typically available by the next version update. Perhaps it is just English only (not internationalized) input compatible.
Perhaps it is just English only (not internationalized) input compatible.
That would be fine for me. I’d just enter a dot. Unfortunately, the input field doesn’t accept numbers with a dot as a separator. And when RM geocodes a location, it displays the coordinates as localized (i.e., with a comma as the separator) and interprets the localized number correctly, but flags it as an error, preventing editing.
If the input field didn’t flag localized numbers as wrong, or accepted English numbers, everything would be fine.
It’s a system setting for using comma’s or periods. RM only recognizes the English version using the period in the case.
@rzamor1 Thanks a lot for answering.
As mentioned above, it is not an option to change my windows settings since this would generate a lot of other issues (csv files, wrongly displayed excel numbers etc).
Are you planning to fix this bug?
I can’t really speak to plans, but its not considered a bug. We would need language support.
Thanks for the information. Not what I wanted to hear, but it is not that important. I can always enter those numbers directly into the database.
Funny, I never thought that dealing with international number formats was still a thing in the 21st century. I haven’t seen such problems for about 20 years. But it is what it is, lets move on.
