User talk:Emka/new OSB

Multilingual

a multilingual interface would be good.

Done. See locale/ folder in the source code for translations. --emka 07:40, 10 October 2009 (UTC)

Synchronization

Is synchronisation between old and new OSB in oneway or from each to each system?

Are there already plans to shut down the old service with a redirection to the new service, or take over the new code to the old website?

--Stephan75 11:43, 5 June 2009 (UTC)

Updated: old service is now old interface + proxy to new service API

The long term idea is to integrate the bug interface into the main website, but at the moment I have other priorities. My goal was getting better access to the data (GPX export and dumps). --emka 16:13, 5 June 2009 (UTC)

Properly escaping HTML in GPX output

This is an example waypoint in the GPX output:

<wpt lon="11.104500" lat="47.492900"><desc>viele Straßen des Ort fehlen noch ganz [NoName]<hr />Fein, dann laufe sie einfach ab und trage sie ein ... Von nichts kommt nichts;-) [alegrie6208, 01.06.09 22:53:43 CEST]<hr />Das Gröbste sollte nun erledigt sein -> Übergang zu Bugtracing. Die Walddefinitionen sind relativ vage [alegria6208, 10.06.09 19:17:47 CEST]</desc><extensions><closed>1</closed><id>63477</id></extensions></wpt>

This means that the XML element <desc> contains an element <hr>, which makes the GPX file invalid. Furthermore, it makes adding the content of the <desc> element to an OpenLayers FramedCloud harder, as the AJAX XML response in JavaScript contains no innerHTML values that you can add as contentHTML to the popup. The easiest fix would be to enclose the value of the <desc> element in CDATA blocks. This would be line 82 of /api/0.1/getGPX:

print "<wpt lon=\"%f\" lat=\"%f\"><desc><![CDATA[%s]]></desc><extensions><closed>%s</closed><id>%s</id></extensions></wpt>" % c

--Candid Dauth 19:51, 12 June 2009 (UTC)

Thanks, I used your solution now. For the record: RSS feeds had the same problem, it was solved by replacing "<hr/>" by " | " there (also on Appspot).

I also had a look at your map tool and it seems you got great Javascript skills. Are you interested in improving the OSB client? Server side could be changed too if necessary. --emka 13:11, 13 June 2009 (UTC)

Thanks for fixing that so fast. I do in fact have an interest in improving the client side, especially in making it reusable by other applications. You can contact me via my OSM user profile. --Candid Dauth 20:38, 13 June 2009 (UTC)

Problems importing non-ASCII chars like German umlauts etc.

The imported data are probably encoded wrong. German umlauts like ä,ö,ü,ß are displayed wrong. --Eliasp 11:04, 14 June 2009 (UTC)

Could you please provide an example? I can only find correct encoding. --emka 11:41, 14 June 2009 (UTC)

It seems like this bug has a wrong encoding. I do not know how to find the reason, my guess is that the client sent this weird character. --emka 07:41, 30 June 2009 (UTC)

RSS feeds delivering open bugs?

• Is it possible to get an RSS feed delivering just the open (and not the closed) bugs for a certain area? I noticed that this is already available for the gpx export method (by appending "&open=yes"). Appending "&open=yes" to the rss feed address seems not to do the job. :-) --SB79 10:05, 28 July 2009 (UTC)

  Yes, it is possible, noted on my todo list, just need time...

  Thanks emka, good to know! I really appreciate what you're doing! :-) --SB79 13:39, 20 August 2009 (UTC)

  Done. Sorry for the delay. --emka 23:09, 21 September 2009 (UTC)

  Thank you very much! :-) --SB79 08:04, 22 September 2009 (UTC)

Closing bugs

How do I close a bug? On the old version I clicked the bug on the map and changed the status to closed. On the new one if I click on the bug marker it wants me to add a new report. I had to use the old app to close two bugs at the weekend. --EdLoach 09:55, 12 October 2009 (UTC)

The interface is asking for an (optional) comment when you close a bug. Just leave the comment field empty if the reason for closing is obvious. --emka 10:38, 12 October 2009 (UTC)