Updated English and German strings WRT liability and consistency of their wording, mostly unifying the use of "apps" / "applications" to "apps" only

[Olf0]

While I originally intended to create two separate pull requests for the English and German strings, I messed this up in my internal branches, so I had to merge the English language changes into the German ones to avoid manual conflict resolution. Most of the German language fixes and improvements are due to messing them up in a similar manner two days ago, without noticing this early enough. A few improvements originate from the fact, that it is quite helpful to jump back and forth between those two languages, as this helps to have a deeper understanding how to express things concisely.

[JusticeRage]

Thanks! One additional advice I would give you is to try to avoid very small commits, to keep the whole tree more readable. For instance, 41504524b4fc3bed10edebfb4e04cdf4b0a2d2b3 is very small and could easily have been grouped with all the other ones.

[Olf0]

Yes, I know, but "avoiding small commits" is one of the things I still have trouble with:

• I am kind of a "typo / oops king", but this is one thing, which is nice about computers: One can always correct oneselfs oopses.
• This is why I usually start a new local branch, when starting to edit some file. This way I can issue a "squash commit" later on, back into the originally cloned branch. Here I did that when starting to edit the English strings.xml
• But when editing two files in parallel, this scheme fails: If I start a new local branches for each file, trying to merge them, before submitting them upstream, will result in many conflicting commits, because the individual commits on the different files and branches are intertwined with each other.
• So in the case above, I was able to "squash commit" the local "strings-en" branch into the local, cloned "beta" branch: This is why you just received a single commit for that file.
• But when pushing my local beta branch upstream to you (i.e. when creating the pull request for it), there was nothing I can do (but all the individual commits for the German strings were done directly in there). Either "squash commits" are just allowed locally or you disabled them, which would be well understandable, as that allows committers to prevent you from cherry picking individual commits.

So how do I do this better, technically?

[JusticeRage]

I think the best way to proceed would be like this:

• Work locally on your machine with your fork of the repository.
• Write stuff, make typos.
• Commit, but don't push to GitHub yet.
• Find the typos and correct them.
• Commit with the --amend option to merge the new changes in the previous commit.
• Repeat ad libitum.
• Push the single commit to GitHub once you're done. Or a reasonable number of commits anyway, if separating them makes sense.

I'm not very familiar with squashing, but I assume that you're having conflicts because you work from different machines simultaneously. BTW, that's just my personal workflow, it's not an industry standard or anything. Other projects may have different approaches.

[Olf0]

Thanks a lot for your recommendations, --amend was new to me.

But for this "warming up" round with Git / Github, I avoided bullet point 1 yet, "Work locally on your machine ..." in order not to be confronted with too many obstacles at one time. In hindsight it might have been easier to do it properly (thus locally), but initially I considered this to be just a few small changes, which can be easily done in the online editor.

As I have just a single further commit planned for this "warming up" round, which is to introduce the recent changes to README.md into http://apktrack.org, i.e. the gh-pages branch, I will do my best to deliver it in a single pull request, while still editing online.

P.S.: Also astonishing for me to see the changes I carried out in my Github repository to show up here!?! And pulling from your beta branch to mine created an entry "referenced this pull request" here, which appears to be even stranger to me. I guess I am now ready to read a "practical introduction to git", as I know much about its concepts (although with a couple of gaps), but many things look strange to me in practice (which is presumably just a lack of understanding).