As I guessed the bug with the >100% comes from countries that aren't
countries anymore. They are removed from the list with the hourly
update, but if you got your list open while this happens you can still
mark it as ok. so we got a country that only exists in this language -
and more than 100% ok :)
I removed those countries and included a fix in the ajax-script that
handles the mark-ok-request that checks for the existence of this
country in the list.
Namely they are http://www.openstreetmap.org/browse/node/424313867
which are both
islands now. By the way i added
(Alderney) which was
The other bug is a hard one. As long as I'm not able to reproduce it, i
can't fix it.
I'm feeling sorry about having these bug in this tool. It was just an
experiment, hacked together in three or four nights - so no clear
structure in the programming nor the database. I know I can do better
(I'm doing every day at work) but this was my first tool on a
toolserver, my with first tool working with geo-data and my first tool
using the osm-api, so please perceive it just as an hacky experiment -
not fully worked-out tool, and thus be gently with me :)
Just had to say that.
I think there was a bug introduced during resorting of the list or
during the transition from
zh-classic -> zh-classical. The list behaves strange. Once I noticed
that when i changed a
country name in one language, the status of the same country name in
changed also. I cannot verify or nail down any bug from remote.
Please see also the image attached which shows a 100.43% progress for
translation of the
Arabic country names.
It reaches 100% when /Tromelin Island /is set to not-ok.