Implemented requested changes

Implemented changes requested by @Vogel612 in pull request #6100

Author: Rsge

Rubberduck.Resources/Inspections/InspectionInfo.de.resx

@@ -464,18 +464,18 @@ Falls der Parameter 'null' sein kann, bitte dieses Auftreten ignorieren. 'null'
     <value>Das Standard (Public) Interface einer Modul-Klasse sollte nicht die Implementierung anderer Interfaces oder Ereignishandler offenlegen.</value>
   </data>
   <data name="PublicEnumerationDeclaredInWorksheetInspection" xml:space="preserve">
-    <value>Das Kopieren eines Arbeitsblattes, das eine öffentliche Enummerationsdeklartion enthält, wird auch eine Kopie der Enummerationsdeklaration anlegen. Diese Kopie wird einen 'Ambiguous name detected'-Kompiler-Fehler auslösen. Die Deklarationm von Enummerationen in Standard- oder Klassenmodulen vermeidet ungewollte Duplikate einer Enummerationsdeklaration.</value>
+    <value>Das Kopieren eines Arbeitsblattes, das eine öffentliche Enumerationsdeklartion enthält, wird auch eine Kopie der Enumerationsdeklaration anlegen. Diese Kopie wird einen 'Ambiguous name detected'-Kompiler-Fehler auslösen. Die Deklaration von Enumerationen in Standard- oder Klassenmodulen vermeidet ungewollte Duplikate einer Enumerationsdeklaration.</value>
   </data>
   <data name="PublicControlFieldAccessInspection" xml:space="preserve">
-    <value>MS Forms legt UserForms Steuerelemente als öffentlichen Felder an. Der Zugriff auf diese Felder außerhalb der UserForm-Klasse bricht die Kapselung und verursacht unnötigen Code mit speziellen Formularsteuerelementen. Überlege, die gewünschten Werte in eine eigene 'Modell Klassen' zu kapseln und Ereignishandler innerhalb des Formulars zu verwenden, diese "Modelleigenschaften' zu ändern. Der Code kann dann die  gekapselten Werte anfragen anstatt der Formularsteuerelemente.</value>
+    <value>MS Forms legt UserForms-Steuerelemente als öffentliche Felder an. Der Zugriff auf diese Felder außerhalb der UserForm-Klasse bricht die Kapselung und verursacht unnötigen Code mit speziellen Formularsteuerelementen. Überlege, die gewünschten Werte in eigene 'Modell-Klassen' zu kapseln und Ereignishandler innerhalb des Formulars zu verwenden, um diese 'Modelleigenschaften' zu ändern. Der Code kann dann die gekapselten Werte anfragen anstatt der Formularsteuerelemente.</value>
   </data>
   <data name="SuspiciousPredeclaredInstanceAccessInspection" xml:space="preserve">
-    <value>Während eine zustandsbetonte (stateful) Standardinstanz eventuell gewünscht ist, ist diese eine beliebte Quelle von Fehlern und sollte vermieden werden. Nutze die 'Me'-Auszeichnung, um die aktuelle Instanz explizit anzusprechen und Zweideutigkeiten zu vermeiden.</value>
+    <value>Obwohl eine zustandsorientierte (stateful) Standardinstanz eventuell gewünscht ist, ist diese eine beliebte Quelle von Fehlern und sollte vermieden werden. Nutze die 'Me'-Auszeichnung, um die aktuelle Instanz explizit anzusprechen und Zweideutigkeiten zu vermeiden.</value>
   </data>
   <data name="ReadOnlyPropertyAssignmentInspection" xml:space="preserve">
     <value>Normalerweise fängt der VBE Editor diesen Fehlertyp und bricht das Kompilieren ab. Allerdings gibt es einige wenige Szenarien, in denen dieser Fehler übergangen und ein Laufzeitfehler ausgelöst wird. Um den Laufzeitfehler zu vermeiden, sollte die fehlende Property oder Subroutine implementiert werden.</value>
   </data>
   <data name="IIfSideEffectInspection" xml:space="preserve">
-    <value>Alle Argumente eines Funktions-/Prozedursaufrufes werden immer evaluiert, bevor die Funktion aufgerufen wird, so dass ihre Werte als Parameter übergeben werden. Allerdings führt die 'IIf'-Funktion manchmal zu einer Fehlinterpretation, dass entweder nur der 'Wahr-Teil' oder nur der 'Falsch-Teil' auf der Basis des ersten Argumentes ausgewertet wird. Somit kann die 'IIf'-Funktion eine Quelle von unvorhergesehen Nebeneffekten und Fehlern sein, wenn der Nutzer den Umstand nicht vor Augen hat, dass immer beide Argumente, 'Wahr-Teil' und 'Falsch-Teil', ausgewertet werden.</value>
+    <value>Alle Argumente eines Funktions-/Prozeduraufrufes werden immer evaluiert, bevor die Funktion aufgerufen wird, so dass ihre Werte als Parameter übergeben werden. Allerdings führt die 'IIf'-Funktion manchmal zu einer Fehlinterpretation, dass entweder nur der 'Wahr-Teil' oder nur der 'Falsch-Teil' auf der Basis des ersten Argumentes ausgewertet wird. Somit kann die 'IIf'-Funktion eine Quelle von unvorhergesehen Nebeneffekten und Fehlern sein, wenn der Nutzer den Umstand nicht vor Augen hat, dass immer beide Argumente, 'Wahr-Teil' und 'Falsch-Teil', ausgewertet werden.</value>
   </data>
 </root>

Rubberduck.Resources/Inspections/InspectionNames.de.resx

@@ -460,7 +460,7 @@
     <value>Implementierungen von Interfaces und Ereignis-Handlern sollten Private sein.</value>
   </data>
   <data name="ReadOnlyPropertyAssignmentInspection" xml:space="preserve">
-    <value>Nur Lesen (Read only) Eigenschaftzuweisung</value>
+    <value>Schreibgeschützt-Eigenschaftzuweisung</value>
   </data>
   <data name="PublicEnumerationDeclaredInWorksheetInspection" xml:space="preserve">
     <value>Public Enumerations Deklaration innerhalb eines Arbeitsblattes</value>

Rubberduck.Resources/RubberduckUI.de.resx

@@ -684,9 +684,9 @@ Import abgebrochen.</value>
     <value>(keine Anmerkungsbeschreibung oder -attribut)</value>
   </data>
   <data name="PeekDefinitionCommandText" xml:space="preserve">
-    <value>Vorschaudefinition</value>
+    <value>Vorschau</value>
   </data>
   <data name="CommandDescription_PeekDefinitionCommand" xml:space="preserve">
-    <value>Vorschaudefinition</value>
+    <value>Vorschau</value>
   </data>
 </root>