Translate classes to english

[Sternbach-Software]

I had to change some Gradle stuff to get the project to compile. I appended Activity and Fragment to classes as appropriate, because this is the convention, and makes code easier to read. I wasn't 100% sure about some of the translations, such as Anagrafe to RegistryOfficeFragment, or Fabuloso to SpeechBubble. I tried to read the comments and code, and see what the class was trying to do. I used Google Translate heavily, but didn't make a change without thinking about it first. See also #61 .
I am starting by translating the classes, then by translating the methods, then the variables, then the comments.

[hannesa2]

It's super easy. Remove root cause on master

git checkout master
git reset --hard 4fb42233a6cebcd9fb581fb1daef5
git push -f

--> merge PR
git cherry-pick 4fb42233a6cebcd9fb581fb1daef5 -> fix conflicts just once

[michelesalvador]

@Sternbach-Software I suppose the first option should be the best now.

@hannesa2 I will try to understand your suggestions.

[michelesalvador]

@Sternbach-Software I just terminated to resolve a lot of conflicts on sternbach-translation branch: the renaming of files, 4 spaces indentation and more. App is now compiling correctly. I pushed.
Obviusly if I pull now from your repo it's a mess of conflicts again.
Should I merge sternbach-translation on my master?
And then open a pull request on your fork?

@hannesa2 But with git reset --hard 4fb42233a6cebcd9fb581fb1daef5 will I loose all the manual resolving I've done until now (five days of work)?

[Sternbach-Software]

I have finished translating the codebase (except the XML ids)! I pulled your changes to master into my master, and merged translate-code-to-english into my master.

[Sternbach-Software]

I am resolving the conflicts now. I would like to discuss something: function naming. The Java convention is to name functions with a verb/action, not a noun. That means, for example, F.displayImageCaptureDialog() instead of F.mediaAppList(). The first clearly describes what happens when the function is called. The second assumes that you know the significance of the noun it is named after, but the name does not explicitly say what it does with that noun.

I am OK changing names (I - along with the greater Java community - generally prefer longer but more descriptive names, over short and less descriptive names, but understand the convenience of shorter names). Can we compromise at F.displayMediaAppList()?

I will take a hint at your name choices and continue merging conflicts by combining your noun function names with an action.

[hannesa2]

But with git reset --hard 4fb42233a6cebcd9fb581fb1daef5 will I loose all the manual resolving I've done until now (five days of work)?

Yes, but you apply it after the merge again. As outcome you only re-order of merge.
Your 5 day merge will be pointless, with this you'll reduce merge conflicts enormous. But you can do what you want.

[Sternbach-Software]

I suggested F.exportGedcomToZip() and you wrote F.exportZippedGedcom(). May we compromise on F.exportGedcomAsZip()? "exportZippedGedcom" implies that the gedcom is already zipped, and the function simply exports it. There is no implication in the adjective "zipped" of a verb "zipping" - that would need to be a participle. Hence, I suggest a compromise of exportGedcomAsZip, which is how it is phrased in most places I have seen (e.g. Google Docs "export as PDF", etc.).

[Sternbach-Software]

Another point, from the official guide to writing Java documentation:

Use 3rd person (descriptive) not 2nd person (prescriptive).
The description is in 3rd person declarative rather than 2nd person imperative.
Gets the label. (preferred)
Get the label. (avoid)

[michelesalvador]

I am resolving the conflicts now.

You are my hero.

Thank you for the explanation, I see the advantage of prefixing a verb to method names.
F.displayMediaAppList() it's perfect to me.

My F.exportZippedGedcom() was not against your F.exportGedcomToZip(), I translated it before, in 4fb4223.
F.exportGedcomToZip() it's better.

OK for the 3rd person.

@hannesa2 I thought I've got it, but not really.
git reset --hard 4fb4223 does not delete 4fb4223, right?
So how can I add it later with cherry-pick?

[hannesa2]

I thought I've got it, but not really.
git reset --hard 4fb4223 does not delete 4fb4223, right?
So how can I add it later with cherry-pick?

That's right, it's preserved in local history. And as long as you don't push you can do what you want. There are several ways back.
And even after push it's preserved in local history