diff --git a/src/main/resources/de/jsilbereisen/perfumator/i18n/perfumes/copyConstructor_de.properties b/src/main/resources/de/jsilbereisen/perfumator/i18n/perfumes/copyConstructor_de.properties
index 19837f4..fabd7f3 100644
--- a/src/main/resources/de/jsilbereisen/perfumator/i18n/perfumes/copyConstructor_de.properties
+++ b/src/main/resources/de/jsilbereisen/perfumator/i18n/perfumes/copyConstructor_de.properties
@@ -1,4 +1,4 @@
 name=Kopier-Konstruktor
-description=Es gibt verschiedene Ansaetze, um Objekte in Java zu kopieren. Die Java Standardbibliothek bietet etwa die "Cloneable" Schnittstelle (Interface) an, welches Klassen implementieren können, um Kopien von sich zu erzeugen. Wie jedoch Joshua Bloch in seinem Buch "Effective Java" (Kapitel 3.4) erklaert, ist beim implementieren dieses Interfaces Vorsicht geboten, da sich im Bezug auf Vererbung mehrere Gefahren verbergen. Er schlaegt daher als saubereren Weg, um Kopien von Objekten zu erzeugen, einen Kopier-Konstruktor vor: ein Konstruktor, der ein Argument desselben Typs nimmt, und welcher dann die Felder der Klasse kopiert ("deep"-copy, also alle veraenderbaren Referenztypen "tief" zu kopieren). Dieser Weg sichert den korrekten Laufzeittyp der Kopie und ist nicht so fehleranfaellig wie "Cloneable" zu implementieren. Obwohl es keine definierte Regel dafuer gibt, markiert das IntelliJ IDEA Plugin "SonarLint" von SonarSource das Implementieren von "Cloneable" ebenso aus diesem Grund als Code Smell.
+description=Es gibt verschiedene Ansaetze, um Objekte in Java zu kopieren. Die Java Standardbibliothek bietet etwa die "Cloneable" Schnittstelle (Interface) an, welches Klassen implementieren koennen, um Kopien von sich zu erzeugen. Wie jedoch Joshua Bloch in seinem Buch "Effective Java" (Kapitel 3.4) erklaert, ist beim implementieren dieses Interfaces Vorsicht geboten, da sich im Bezug auf Vererbung mehrere Gefahren verbergen. Er schlaegt daher als saubereren Weg, um Kopien von Objekten zu erzeugen, einen Kopier-Konstruktor vor: ein Konstruktor, der ein Argument desselben Typs nimmt, und welcher dann die Felder der Klasse kopiert ("deep"-copy, also alle veraenderbaren Referenztypen "tief" zu kopieren). Dieser Weg sichert den korrekten Laufzeittyp der Kopie und ist nicht so fehleranfaellig wie "Cloneable" zu implementieren. Obwohl es keine definierte Regel dafuer gibt, markiert das IntelliJ IDEA Plugin "SonarLint" von SonarSource das Implementieren von "Cloneable" ebenso aus diesem Grund als Code Smell.
 source#1=J. Bloch: Effective Java, Kap. 3.4
 additionalInformation=Eine andere Option, um "Cloneable" zum Kopieren von Objecten zu vermeiden, waere etwa eine (statische) Kopier-Methode oder ein eigenes Interface, welches einen Kopier-Mechanismus vorschreibt.
\ No newline at end of file
diff --git a/src/main/resources/de/jsilbereisen/perfumator/i18n/perfumes/useTryWithResources_de.properties b/src/main/resources/de/jsilbereisen/perfumator/i18n/perfumes/useTryWithResources_de.properties
index 7bf39eb..24c3f2f 100644
--- a/src/main/resources/de/jsilbereisen/perfumator/i18n/perfumes/useTryWithResources_de.properties
+++ b/src/main/resources/de/jsilbereisen/perfumator/i18n/perfumes/useTryWithResources_de.properties
@@ -1,8 +1,2 @@
 name=Ressourcen-Management in Try-catch
-description=Um beim Benutzen eines try-catch-statements sicherzustellen, dass benutzte Ressourcen zuverlaessig \
-  geschlossen werden,\nbietet Java das \"try-with-resources\" Konstrukt. Dieses zu benutzen ist Best-Practice,\num \
-  Ressourcen-Leaks zu vermeiden. Anfaenger begegnen diesem Konstrukt etwa bei ersten Uebungen zum Lesen oder schreiben \
-  von Dateien\nund beim Nutzen von I/O Streams. Sie sollten fuer das Nutzen dieses Idioms belohnt werden, da es den \
-  geschriebenen Code simplifiziert\nund die Alternative, also nicht-benutzen von Try-with-resources, sie in der Gefahr \
-  laesst, dass Ressources nicht geschlossen werden.\nDieses Perfume ist ein Loesungsmuster, inspiriert durch den \
-  \"Try-with-resources should be used\" Code Smell von SonarSource.
\ No newline at end of file
+description=Um beim Benutzen eines try-catch-statements sicherzustellen, dass benutzte Ressourcen zuverlaessig geschlossen werden, bietet Java das \"try-with-resources\" Konstrukt. Dieses zu benutzen ist Best-Practice, um Ressourcen-Leaks zu vermeiden. Anfaenger begegnen diesem Konstrukt etwa bei ersten Uebungen zum Lesen oder schreiben von Dateien\nund beim Nutzen von I/O Streams. Sie sollten fuer das Nutzen dieses Idioms belohnt werden, da es den geschriebenen Code simplifiziert und die Alternative, also nicht-benutzen von Try-with-resources, sie in der Gefahr laesst, dass Ressources nicht geschlossen werden. Dieses Perfume ist ein Loesungsmuster, inspiriert durch den \"Try-with-resources should be used\" Code Smell von SonarSource.
\ No newline at end of file