Locale aus mehreren Quellen?

Ich bin mir zwar recht sicher, nix überlesen zu haben, aber vielleicht gubt es ja noch eine Möglichkeit

Es gibt ja die Möglichkeit, die Übersetzung von Texten via locale.json zu parametrieren, diese Datei ist ja Modul-spezifisch

Aber ich habe aber immer einen bestimmten Teil der Texte, die eigentlich für die ganze Library gelten (also für alle „Sub-„Module - zB sowie für die IO- also auch Device-Modul).
Verschärfend kommt hinzu, das meine zentrale Bibliotheken auch bestimmte Texte enthalten, die eigentlich dann für alle meine Module gleich erforderlich sind.

Mein jetziger Weg ist klar, alle diese Texte in alle lovale.json-Dateien eintragen. Geht natürlich, ist aber nicht schön bzw. fehleranfällig.

Gibt es irgend eine interne Funktion, mit der ich die locale.json „ergänzen“ / dynamisch erzeugen kann?
Wenn nein, ist da etwas denkbar oder sogar in Planung?

Die Frage habe ich mir auch schon gestellt.
Teilweise kommt bei mir noch Vererbung von PHP-Klassen dazu, wo dann auch die Form durch GetConfigurationForm dynamisch entsprechend der PHP Klassen zusammengebaut wird.
Da vereinfacht diese Funktion die Arbeit, aber bei der Lokalisierung muss ich jede Datei einzeln füllen.
Workaround wäre jetzt die Translate Mehtode zu überschreiben und selbst jede local.json zu Parsen.
Dann muss man aber die ConfigForm auch gleich übersetzt ausliefern :see_no_evil:
Eine SDK-Funktion wie GetLocalJson, ähnlich wie GetConfigurationForm, wäre vielleicht eine Lösung.
Bei jeden Aufruf von Translate, im Modul oder durch die Konsole, wird das JSON benutzt welches GetLocalJson liefert.
Michael

ja, an so etwas hatte ich auch gedacht, wobei ich sagen muss, das sich Anforderungen für noch etwas komplexer darstellen weil die Übersetzungs-Informationen nicht aus einer alternativen Quelle stammen sondern aus mehreren (locale.json des Moduls, locale-Informationen aus libs und zusätzlich locale aus Submodule(n) etc.

Mittels der von dir vorgeschlagenen GetLocaleJson könnte mir das aber schon vorstellen, die verschiedenen Quellen zu laden und zu mergen.
Alternativer Vorschlag: in GetConfigurationForm neben „status“, „elements“ und „actions“ auch noch „locale“ zu liefern

Das geht jetzt schon.
Aber es betrifft dann aber nur die Form.
Zusätzlich müsste man dann noch Translate entsprechend selbst überschreiben und selbst aus allen Quellen den korrekten String zurückliefern.
Michael

Ich wollte heute eigentlich ein Beispiel liefern, wie das funktionieren könnte - Hab es zeitlich aber nicht geschafft.

Wie @Nall-chan schon sagte, musst du es leider in 2 Teile trennen:
→ GetConfigurationForm liefern den Teil für die Konsole
→ Überschriebene Translate Funktion liefern den Teil für Module intern

paresy

ok, wenn ihr da nichts in Planung habt, werde ich mich mal dran begeben.

Trotzdem noch folgende Fragen:

  1. den Satz verstehe ich nicht so ganz

bedeutet das, das ich die Übersetzungs-Informationen mit zurück liefern kann oder bedeutet das, das ich die Formulare in der übersetzt Version liefern muss? Dann alle Elemente „caption“ bzw. „label“?

  1. damit ich mich da „synchron“ zu IPS verhalte: woher bekomme ich die Information, was ich verwenden soll? ich hätte da locale_get_default() im Sinn.

Nein, es reicht wenn du das local mit auslieferst.
Schau dir einmal die Symcon Form Dateien für die built-in Module an.
Michael

Du meinst in /usr/share/symcon/forms? Da finde ich nur ganz normale forms.json-Dateien (also elements, actions, status).

sorry, ich stehe etwas auf dem Schlauch

Nachtrag #1:
ich glaube, ich habe was gefunden

.store/de.paresy.homekit/HomeKitBridge/module.php (element “translations“)

und

$language = explode('_', IPS_GetSystemLanguage())[0];

dann werde ich mal basteln …

Nachtrag #2:
Ok, ich habe gebastelt…

Leider funktioniert das (noch) nicht wirklich zufriedenstellend.

Ich habe ein GetConfigurationForm(), das das Array-Element translations mit allen relevanten Übersetzungen liefert, vereinfacht ausgedrückt aus dem eigentlichen Modul-Verzeichnis (TestModuleDevice/locale.json) sowie libs/locale.json.

Es wird aber nur TestModuleDevice/locale.json zur Übersetzung verwendet.

Sobald ich aber TestModuleDevice/locale.json lösche/umbenenne funktioniert es, die Anzeige der Maske verwendet die in GetConfigurationForm() gelieferten translations.

Daraus muss ich schliessen, das eine Module-lokale locale.json Vorrang hat und translations dann ignoriert wird.

Da es aber nicht zulässig ist, in einem Modul-Verzeichnis beliebige Dateien abzulegen, könnte ich die Modul-spezifische Übersetzungsdatei nicht einfach benennen (also z.B. TestModule/translations.json) oder überinterpretiere ich da Struktur — IP-Symcon :: Automatisierungssoftware?

@paresy: hast Du noch irgend eine Idee?

Nachtrag #3:
bei IPS_SetVariableProfileAssociation() wird auch kein Translate von Name mehr durchgeführt, das muss man selber machen - an sich kein Problem, ich frage mich nur ein bisschen, an welchen Stellen das dann noch zuschlägt

Beachte, dass IPS_GetSystemLanguage erst ab der 6.1 verfügbar ist :slight_smile:

Hier ein vollständiges Beispiel wie so etwas aussehen könnte:

paresy

1 „Gefällt mir“

ja prima, so in etwas habe ich das auch gemacht, d.h. das mit .ocale.json hatte och richtig beobachtet

ok, in früheren Versionen (ab 6.0) behelfsweise per Environment LANG?

$lang = '';
if (isset($_ENV['LANG']) && preg_match('/([^\.]*)\..*/', $_ENV['LANG'], $r)) {
    $lang = $r[1];
}

danke
demel

Sehr cool :smiley:
So hatte ich mir das auch gedacht.
Blöd wenn man gerade keine Zeit für Symcon hat.
Michael

1 „Gefällt mir“

Wichtig ist nur zu wissen, dass man kein IPS_Translate oder (new IPSModule($id))->Translate verwenden kann, da dies immer auf die statische locale.json geht.

paresy