Add i18n branch to Development

[haiqu]

Many new files, all converted to UTF8.

[ManfredKarrer]

Thanks for the PR, but I am not sure if it is a good idea to add so many files because the base file needs to get cleaned up (many entries are not used anymore) and many (90%) of strings are not supported there. So I think its better to have first a clean base file in english and then go for translations, otherwise the maintainance for changes need to be applied to all those new files.

[haiqu]

So what this needs is all the English text in the program to exist in one big file? OK, I'll look into that.

[ManfredKarrer]

Yes we need to add keys for all strings appearing in the app (namespace keys like I used in the CrateOfferView class and in the current file
E.g.: createOffer.fundsBox.totalsNeeded.prompt). There are duplicates as well, and some contains variables, but that is supported by the resourceBundle (createOffer.fundsBox.paymentLabel=Bitsquare trade with ID {0}).

Name spaces should be reflecting areas/view classes in the UI (CreateOfferView -> createOffer). Though some might overlap because of duplicate usage. So that needs some parent category...

Once we have all strings moved to the i18n file in english we have a solid base to start translations. And from then on all string need to be added to the properties file and not anymore in the java code.

I would prefer then to checkout a web tool like transiflex and use that. Only when we have a language complete we should add it to the app otherwise users get it mixed with english which does not look professional IMO.

We need to check also layout as some languages have longer words and might break existing layout.

So all in all that is quite a big task. If you could take that, would be great!
Most strings are in the view classes (should be) but I think a few not (should be refactored then...).

[haiqu]

I'm all over it. But we might have a difference of opinion on the way it has to be translated.

My opinion is that Google translate is fine for a first draft. Why? Because otherwise it will never get done, just like HaikuOS. If something looks wrong the foreign language user will complain and tell us, you can be sure of that. But before, with no translation at all, he wasn't a user. So with a half-assed machine translation we are in a better position to find native speakers who will delight in "correcting our awful French/Latvian/Whatever".

I once held a text conversation with a native French speaker using only Google translate, and after about 15 minutes he asked if I was Canadian. It must have been pretty good.

[haiqu]

Also we should have a displayStrings_en.properties file. That way someone can overwrite displayStrings.properties with their own local language for distribution in a foreign country. But it still allows English to be selected again from a menu.

[ManfredKarrer]

Yes I understand your point of view and u might be right. I just get a negative impression if I am on a webpage with bad geramn translation, I prefer english then....
But I hope also we get the DAO on track soon so we might have better incentive to offer to translators, so to get a professional translation should be not a big problem as well.

First step would be to get all strings extracted, then we can discuss which direction is better, a mix might be ok as well.

[haiqu]

It's a lot easier to find an editor than a translator, that's all I'm saying. Costs less too. :)

[haiqu]

Ref #157

[haiqu]

Super, danke. Ich gebe Ihnen die Aufgabe, die deutsche Übersetzung der Vollendung ... ;)

[ManfredKarrer]

Haha... google translate?

[haiqu]

ButOfCourse!