Danke für Deine Unterstützung! Aber warum übersetzt Du nicht (einfach) das bereits vorhandene Plugin? Dafür gibt es ja die Rolle des "Übersetzers". Stattdessen ein neues Plugin einzustellen macht meiner Meinung nach wenig Sinn.....
In dem Segment "Übersetzungen hochladen" bin ich nun mal ein Anfänger!
Ich wollte zuerst nur die Sprachdataien ersetzen und habe dann festgestellt, dass im Ordner ./inc(plugins/myarcade für den Adminbereich die *.xml auch übersetzt dazu gehören.
Nebenbei: In den meisten Erweiterungen müssen in der Datei ./inc/plugins/plugin_name.php auch deutsche Anpassungen durchgeführt werden.
Wenn mir jemand sagt, wie ich das mit den reinen Sprach- sowie PlugIn-Dateien einpflegen musss, tue ich es selbstverständlich gerne.
Vielleicht sind meine Anregungen der Anstoß das mal ein Tutorial für die korrekte Vorgehensweise bei Übersetzungen zur Verfügung gestellt wird.
Sollte ich der Ansicht sein helfen zu können biete ich Hilfe(n) an! ...ich bitte jedoch nicht darum helfen zu dürfen! Tools◀ [Unixzeit ⇔ Realzeit] ♦ [BOM-Finder] ♦ [SQL-Prefix-Changer] ♦ [USV-Rechner] ♦ [PlugIns]
Es gibt in einem Plugin, das noch nicht übersetzt wurde einen Link, über den eine Übersetzung einzureichen ist (siehe Anhang). Alles weitere ist dann ähnlich zu dem, wenn man ein neues Plugin zu den Erweiterungen hinzufügt.
In der Plugin-Datei Anpassungen bzgl. Übersetzung vorzunehmen (z.B. bei den Einstellungen), das würde ich mit Vorsicht betrachten. In so einem Fall müssten alle Anwender des ursprünglichen Plugins dasselbige erst einmal deinstallieren und erneut installieren, damit die Übersetzungen der Einstellungen greifen. Das bedeutet aber u.U. auch, dass Daten verloren gehen.
Was Fragen bzgl. der generellen Vorgehensweise bei Übersetzungen angeht, da könnte man auch den Thread verwenden, in dem man sich als Übersetzer beworben hat.....
(16.06.2020, 13:28)Jockl schrieb: In der Plugin-Datei Anpassungen bzgl. Übersetzung vorzunehmen (z.B. bei den Einstellungen), das würde ich mit Vorsicht betrachten. In so einem Fall müssten alle Anwender des ursprünglichen Plugins dasselbige erst einmal deinstallieren und erneut installieren, damit die Übersetzungen der Einstellungen greifen. Das bedeutet aber u.U. auch, dass Daten verloren gehen.
Also das PlugIn "deaktivieren", Dateien "hochladen" und wieder "aktivieren" hat bisher immer ausgereicht. Eine "deinstallation" war zu keiner Zeit erforderlich. (Ich habe mir bereits einige PlugIns übersetzt).
Sollte ich der Ansicht sein helfen zu können biete ich Hilfe(n) an! ...ich bitte jedoch nicht darum helfen zu dürfen! Tools◀ [Unixzeit ⇔ Realzeit] ♦ [BOM-Finder] ♦ [SQL-Prefix-Changer] ♦ [USV-Rechner] ♦ [PlugIns]
(16.06.2020, 15:21)Gerti schrieb: Also das PlugIn "deaktivieren", Dateien "hochladen" und wieder "aktivieren" hat bisher immer ausgereicht. Eine "deinstallation" war zu keiner Zeit erforderlich.
Das kann Zufall sein.
Man muss im Plugin immer sehen, unter welcher Funktion die (ACP)-Settings ausgeführt werden.
Das kann ..._info, ..._activate oder auch ..._install sein.
Ich gehe hier aber insofern mit, dass zu einer deutschen Übersetzung auch die ACP-Settings gehören.
Sollte die ACP-Settings-"Sprache" hardcodet sein, wie soll dann im günstigsten Fall verfahren werden??
17.06.2020, 08:07 (Dieser Beitrag wurde zuletzt bearbeitet: 17.06.2020, 08:09 von itsmeJAY.)
(16.06.2020, 16:15)Schnapsnase schrieb:
(16.06.2020, 15:21)Gerti schrieb: Also das PlugIn "deaktivieren", Dateien "hochladen" und wieder "aktivieren" hat bisher immer ausgereicht. Eine "deinstallation" war zu keiner Zeit erforderlich.
Das kann Zufall sein.
Man muss im Plugin immer sehen, unter welcher Funktion die (ACP)-Settings ausgeführt werden.
Das kann ..._info, ..._activate oder auch ..._install sein.
Viel wichtiger ist zu überprüfen, unter welcher Funktion die entsprechenden Einstellungen wieder aus der Datenbank gelöscht werden. Wenn es nämlich unter deactivate ist, wäre ein deaktivieren des Plugins gleichbedeutend mit dem Deinstallieren.
Soweit ich weiß, können Settings nicht Multi-Lingual sein. Die Settings können zwar auch in language Dateien übersetzt werden, werden aber so oder so hard-coded in die Datenbank geschrieben. Wenn also z. B. Einstellungen im Plugin selber hard-coded sind, dann kann man die zwar übersetzen aber dies setzt immer eine Deinstallation und anschließende neue Installation vorraus. Die von Gerti erwähnte Variante mit dem deaktivieren stimmt schlichtweg einfach nicht.
(17.06.2020, 08:07)itsmeJAY schrieb: Soweit ich weiß, können Settings nicht Multi-Lingual sein. Die Settings können zwar auch in language Dateien übersetzt werden, werden aber so oder so hard-coded in die Datenbank geschrieben.
Das ist etwas unverständlich.
Sobald für die ACP-Settings Sprachvariablen in unterschiedlichen Sprachdateien vorhanden sind, wird dies doch auch übersetzt.
Was ist daran für Dich nicht Multi-Lingual?
(17.06.2020, 08:07)itsmeJAY schrieb: Soweit ich weiß, können Settings nicht Multi-Lingual sein. Die Settings können zwar auch in language Dateien übersetzt werden, werden aber so oder so hard-coded in die Datenbank geschrieben.
Das ist etwas unverständlich.
Sobald für die ACP-Settings Sprachvariablen in unterschiedlichen Sprachdateien vorhanden sind, wird dies doch auch übersetzt.
Was ist daran für Dich nicht Multi-Lingual?
Nope, hatte ich oben erklärt. Guck dir die Daztenbank doch an. Es wird hard-coded rein geschrieben. Da ist nichts mit Sprachvariablen.
17.06.2020, 09:43 (Dieser Beitrag wurde zuletzt bearbeitet: 17.06.2020, 09:45 von itsmeJAY.)
Ja die klappt beim Eintragen in die DB. Aber was passiert, wenn du das ACP jetzt auf Englisch umstellst? Dann kriegst du weiterhin die Deutsche Übersetzung angezeigt. Das meinte ich mit "Nicht wirklich multi lingual".
(17.06.2020, 09:43)itsmeJAY schrieb: Ja die klappt beim Eintragen in die DB. Aber was passiert, wenn du das ACP jetzt auf Englisch umstellst? Dann kriegst du weiterhin die Deutsche Übersetzung angezeigt.
Nein, definitiv nicht! Ich habe es vor 10 min getestet.
