Improve regex to extract the city names from the filename

[dirkschumacher]

This handles the "neu-ulm" case.
neu-ulm => Neu-Ulm.

However: "frankfurt-am-main" would result in "Frankfurt-Am-Main".
#23

[johnjohndoe]

First thing which comes to my mind: we should start writing tests for the Javascript magic.

[dirkschumacher]

Yes! But not as part of this PR :)
Maybe open an issue to set up a testing system.

[torfsen]

How about putting the city's display name into the city's meta data? I don't see the point of having a very complex automatism to turn city IDs into display names if we have the meta-data system in place already.

[johnjohndoe]

This solution was inspired by the thought not to store city names in multiple places (file names, README.md, and now metadata). This might get annoying in terms of maintenance.

[dirkschumacher]

I would still opt for a specific meta-data file where all cities are named. This leads to double entries, but it removes the problem with querying the github api and doing some filename transformation.

We could write an automated test that checks if all .json files are in the cities.json meta-data list.

[torfsen]

I, too, like the idea of not repeating the information too often. One possibility would be to generate the ID from the display name instead of the other way round:

1. Use the full city name with proper capitalization as the filename, but replace spaces with underscores: Frankfurt_am_Main.json.
2. From these filenames, generate a city's ID by conversion to lowercase and replacement of _ by -: frankfurt-am-main.

The IDs can be generated when we load the city list.

However, I think it's still worth to simply have a separate cities.json file that lists the available cities. While it would make maintenance slightly more cumbersome it saves us a request to the GitHub API which makes the app portable. In addition the only time that you need to touch that information is when you add a new city. I think that's OK. That would be a separate PR, though.

[johnjohndoe]

The argument to make the app portable by not depending on the API of GitHub convinces me.
+1 for a refactoring.