adds stat and type efficacy changelog and some german translations

[Kampfmoehre]

I am currently building a WinPhone App (just for fun and for just me) and I am using your data in an sqlite database. There is some data that I need so I added them to your database and I thought I'd share it.

Some stats where changed in 2nd and 6th generation. I added Pokémon stats for older generations and a new Stat "Special" which was SpecialAttack and SpecialDefense in first generation. Also there were some type efficacy changes in 2nd gen. I also provided some german translations.

Stat source: http://bulbapedia.bulbagarden.net/wiki/List_of_Pok%C3%A9mon_by_base_stats_%28Generation_I%29 http://bulbapedia.bulbagarden.net/wiki/List_of_Pok%C3%A9mon_by_base_stats_%28Generation_II-V%29

[magical]

Thanks for the pull request! It looks like you've combined several unrelated changes; it would be helpful if they were separate pull requests.

1. German translations. We love translations! I'd be happy to merge these, especially the prose translations. I'm curious what source you used for official game text.
2. Type efficacy changelog. I think the long-term plan is to add a generation column to type_efficacies, since we'd actually like to get rid of changelogs (see https://github.com/veekun/pokedex/issues/107 and https://github.com/veekun/pokedex/issues/58), but i suppose i could accept this as a stopgap.

3. Stat changelog. Same story as the type changelogs. Also, we usually like to use better sources than Bulbapedia.

   We never really decided how we wanted to handle the Gen I Special stat split (see https://github.com/veekun/pokedex/issues/8). The solution you've chosen is probably the least bad option. I don't think the Special stat should be marked is_battle_only, though.

   I'm not sure how spline-pokedex will be affected by adding a new stat; it would probably need to be updated.

4. Mega evolution height. Looks good.
5. It looks like you deleted a bunch of lines from pokemon_moves? Perhaps a bad merge?

Lastly, a general nitpick: some of the lines in the csv files are out of order; you should run pokedex load followed by pokedex dump to get the canonical order.

[Kampfmoehre]

Hello and thanks for the reply and feedback.

You are right, it is better to split translations into another pull request. Let me answer your questions.

1. I will say something to every table. ability_changelog_prose, ability_prose - The translations for abilities (there are more to come) I did for myself. Its somewhat difficult but I try to use the same phrases whenever possible. item_category_prose, item_flag_prose, item_fling_effect_prose, item_pocket_names, move_battle_style_prose, move_meta_ailment_names, move_meta_category_prose - Same goes for them, I translated them myself berry_firmness_names, characteristic_text, contest_type_names, pal_park_area_names, pokeathlon_stat_names, pokemon_habitat_names - I used pokewiki.de (the german bulbapedia) for them but I would love to rip them from a game - more to that later. They are in fact equal to the official names, at least for the actual generation. There were some changes to official text for characteristics over the games and even a contest category was beeing renamed in Gen 6.
2. I read about the generation/versiongroup columns, unfortunately after I submitted this request. I am a while now about building my own Pokémon program, I started (and I am a little bit ashamed about that now) some years ago with building my own database by hand (meaning I would enter all data myself without programming help) with MS SQL Compact. Back then I had different tables for version groups like Pokemon_Gen1, Move_Gen1, Pokemon_Move_RBY and so on. This was a lot of duplicated data and it means you could not just get data by query but you must decide in the application which table to use. The approach you take with version, versiongroup and generation columns is much better in my opinion, though it can be a little bit messy having to use version_group_id and generation in the same query.
3. You are totally right, the Special stat should not be marked is_battle_only, that was a mistake. Again I can only tell you what my older (and shaming) approach was. As I had Pokemon tables for each generation storing special in database was no problem at all, the pokemon_gen1 table simply had a Special column, rather than SpecialAttack and SpecialDefense. In my application however, I stored the Special stat in the SpecialAttack property, leaving SpecialDefense empty (nullable) which left me with nasty null checks every time I had to deal with it. The approach I used here is far from perfect, cause of the Special Stat has it's own ID the join will somewhat not get the values from the changelog table. Maybe there is some elegant approach - I am far away from beeing a SQL expert - but I was missing it.
4. From my work I am used to rebase the master branch frequently into my work branch if it exists for a longer time, this is why I've done this here. I will close this request an open some new with the data separated and without commits from other requests.

As I hinted earlier I would love to rip official game text as well as Gen 2 locations but unfortunately I have no glue about how to do that. If you have some good references how to rip GBC roms I would love to extract some data into this database.