Ein paar Neuigkeiten zur Veröffentlichung von Gladys 4 RC!
Hallo, ein kleiner Aufruf an die Entwickler:
Ich versuche, an dem Thema der Server-Übersetzung zu arbeiten, insbesondere weil ich nach den Tests und der Sortierung im Netatmo-PR wieder etwas aufgenommen habe, es gibt viele Funktionen, deren Namen eine Übersetzung benötigen. Ich dachte, ich würde eine PR dafür machen.
Es funktioniert gut, aber:
Erster Punkt:
Ich habe diesen Fehler bei ESLint. Bei der ersten Zeile verstehe ich nicht, warum, denn ich habe i18n direkt unter
/server installiert. Ich dachte, es würde weitergegeben werden… Haben Sie eine Idee (es ist das erste Mal, dass ich eine Abhängigkeit installiere…)?Für die folgenden Zeilen verstehe ich, dass ESLint diese Zeichen einfach verbietet. Können wir ihm manuell neue Regeln zuweisen? Dürfen wir das? Und wenn ja, könnten Sie mir den Weg weisen?
Zweiter Punkt:
Für die Übersetzungssprache standardmäßig « EN », dann verwende ich die Sprache des ersten Benutzers, der beim Start von Gladys erstellt wurde. Derzeit (ich vermute, dass wir es nicht so machen werden, wenn es fertig ist), verwende ich user.update und user.updateBySelector, um die Sprache (falls nötig) von i18n zu aktualisieren. Neue Geräte, die erstellt werden, werden dann in der neuen Sprache erstellt.
Um die Diskussion also wieder aufzunehmen, was halten Sie von der Methodik? Wie strukturiert man das?
Derzeit habe ich gemacht:
Config-Ordner:
Datei /server/api/index.js:
Dateien user.updatexx:
Beispiel für die Verwendung:
Dokumentation i18n: i18n - npm
@pierre-gilles, Ideen?
@Terdious meiner Meinung nach braucht man dafür keine Bibliothek, eine JSON-Datei mit Schlüssel/Wert-Paaren pro Sprache wie im Frontend wird völlig ausreichen!
Man sollte es nicht unnötig kompliziert machen, je einfacher, desto besser 
Übrigens, falls es um eine Integration geht, denke ich, dass man das direkt in der Integration machen sollte und nicht im Core-Code.
Wenn du Gerätenamen übersetzen musst, erstellst du einen Ordner mit einer en.json und fr.json Datei und das erledigt den Job 
Du lädst deine Dateien, wo du sie brauchst, und fertig!
Danke für die Antwort @pierre-gilles,
Wir sind uns einig, dass es nicht der Gerätename als solcher ist, den wir übersetzen wollen, normalerweise sind diese bereits in der API benannt, aus der wir die Geräte beziehen. Für den ersten Anwendungsfall, den ich sah, geht es eher um die Funktionen, die nach ihrer Kategorie/Art benannt werden. Alle Integrationen benennen in der Datenbank die Funktionen als « [Name] - Ein/Aus », « [Name] - Luftfeuchtigkeit », « [Name] - Farbtemperatur », « [Name] - Leistung », usw. Daher sind viele dieser Übersetzungen identisch? Welchen Sinn hat es, die Dateien für jede Integration zu duplizieren?
Genau, ich habe die Funktionsweise und Logik des Frontends mit i18n übernommen… Es hat nur 10 Minuten gedauert, das einzurichten, das erschien mir überhaupt nicht kompliziert und vor allem:
Wenn wir eine Sprache hinzufügen, müssen wir dann alle Dateien durchgehen, die eine Übersetzung aufrufen? Das stört mich nicht, aber diesmal nehmen wir die Entwicklungsfreundlichkeit heraus.
Da bin ich mal mit @Terdious einer Meinung, wir sollten die Feature-Übersetzungen zentralisieren.
Nein, wenn es sich um dieselben Übersetzungen handelt, kann man die Frontend-Dateien im Backend verwenden oder umgekehrt. Ich wusste nicht genau, wie dein Anwendungsfall aussieht!
Nein, nein, die Idee ist, einfach ein Übersetzungsobjekt zu haben, das du bei Bedarf einbindest, und wenn du eine Sprache hinzufügst, musst du nichts anpassen.
Ich sprach nur von der Hinzufügung von Bibliotheken, die im Backend nicht unbedingt nötig sind, ein einfaches JS-Objekt erledigt den Job, es ist eine Schlüssel-Wert-Struktur.
Allerdings habe ich deinen Pull Request nicht gelesen, also weiß ich nicht, wie weit deine Entwicklung geht
Oki super!! Noch besser, wenn wir die vom Frontend wiederverwenden können!! Du bestätigst das später über die PR, wenn du Zeit hast.
Ok, aber um deine Idee zu testen, habe ich das Erfordernis durch die Sprachdatei getestet, aber dann muss es wohl nicht das Richtige sein, denn in meinem Test mit meinem Verständnis deiner Aussagen rufe ich die beiden Dateien auf, indem ich
const tradFr = require('../../../config/translate/fr.json')
const tradEn = require('../../../config/translate/en.json')
in jeder Datei, die benötigt wird. Daher müsste man im Falle einer Sprachergänzung jede Datei erneut bearbeiten!! Also, wo machst du dein Erfordernis in deiner Idee? (Antworte mir auf GitHub, wenn du Zeit hattest, es noch einmal zu lesen ^^ wir werden es dann besprechen ^^)
Du erstellst eine Datei i18n.js (Beispielname, kann alles sein), die enthält:
const fr = require('./fr.json');
const en = require('./en.json');
module.exports = {
en,
fr
};
In allen deinen Dateien machst du:
const i18n = require('../../config/i18n/i18n.js');
Und wenn du eine Übersetzung benötigst:
const myTitleExample = i18n[lang][key];
Das ist nur ein Beispiel aus einem Forenbeitrag, wenn man etwas Komplexeres will, kann man eine Funktion in i18n exportieren, um Fehler zu behandeln, usw.
Vielen Dank,
Ich arbeite daran!^^