url consistency (#7)

bauerv · web-flow · commit e4eaa46be2f7 · 2017-01-27T13:55:35.000+01:00
* inclusos for incluso

* Fixed, code seperated line from 123. Line

* A more positive feel for the "Introduction" 

The version "feel somehow left behind" has a strong negative feeling to it. To me (as a coach) this feels problematic/counterproductive when starting off the day with super motivated participants (essentially, I'm "reminding" them about the "fact" that they might be "left behind" instead of, e.g., "courageous" or "engaged"). 

I'm proposing a small correction to soften this feel. However, ideally, I would prefer the tutorial to start off with a friendly and warm welcome (and potentially congratulations that the participant worked up the courage to get herself into this in the first place). Maybe add a dedicated "Welcome" section?

* Added clarification about directory content

On several occasions, we had confusion about the contents of the directory after running the django-admin.py script. The directory tree suggests to show all the contents, but in fact, when following the installation guideline, venv will also sit in the djangogirls directory. This is missing in the pic, so participants sometimes think it is an error and might try to delete it. I suggest a note to fix this.

* Consistency between text and code example

`blog.views.post_detail` is not in the source code example so the explanation in the following paragraph was not consistent with it. From what I understand, it is the URL created by Django, so I added this to the text.
diff --git a/en/extend_your_application/README.md b/en/extend_your_application/README.md
@@ -37,11 +37,11 @@ We will start with adding a link inside `blog/templates/blog/post_list.html` fil
 
 {% raw %}Time to explain the mysterious `{% url 'post_detail' pk=post.pk %}`. As you might suspect, the `{% %}` notation means that we are using Django template tags. This time we will use one that will create a URL for us!{% endraw %}
 
-`blog.views.post_detail` is a path to a `post_detail` *view* we want to create. Please note: `blog` is the name of our application (the directory `blog`), `views` is from the name of the `views.py` file and the last bit – `post_detail` – is the name of the *view*.
+The URL that is created resolves to `blog.views.post_detail` and is a path to a `post_detail` *view* we want to create. Please note: `blog` is the name of our application (the directory `blog`), `views` is from the name of the `views.py` file and the last bit – `post_detail` – is the name of the *view*.
 
 And how about `pk=post.pk`? `pk` is short for primary key, which is a unique name for each record in a database. Because we didn't specify a primary key in our `Post` model, Django creates one for us (by default, a number that increases by one for each record, i.e. 1, 2, 3) and adds it as a field named `pk` to each of our posts. We access the primary key by writing `post.pk`, the same way we access other fields  (`title`, `author`, etc.) in our `Post` object!
 
-Now when we go to http://127.0.0.1:8000/ we will have an error (as expected, since we don't have a URL or a *view* for `post_detail`). It will look like this:
+Now when we go to http://127.0.0.1:8000/ we will have an error (as expected, since we do not yet have a URL or a *view* for `post_detail`). It will look like this:
 
 ![NoReverseMatch error](images/no_reverse_match2.png)
 
