Issue #1 resolved

Move storage into database

Christoph Mewes
created an issue

It's bad for cloud environments to have the translations inside a static file in data/translator. We need to move this into the database, so it gets properly backupped and deployed.

The schema doesn't need to change, it should just be mapped 1:1 to the database. Entries shall still be grouped and have multiple translations for each of them.

On the other side, the generated language files (data/translator/de_de.yml) should stay and be re-generated whenever neccessary. But they should be viewed as a cache, not a primary storage.

Comments (2)

  1. Christoph Mewes reporter

    Nach einiger Diskussion sieht der aktuelle Entwurf wie folgt aus:

    • Die Keys der Übersetzungs-Elemente werden in YAML vom Entwickler vorgegeben. Dabei kann er zu jedem Key jeweils einen optionalen Beschreibungstext sowie einen optionalen Standardwert vergeben.
    • Die Übersetzungen liegen in der Datenbank.
    • Die Übersetzungs-Elemente können wie bisher in Gruppen eingeteilt werden. Dabei sollte die momentane Struktur der YAML-Datei (_database.yml) nicht übernommen werden. Stattdessen sollte sich hier an der Art und Weise, wie Metainfos definiert werden, orientiert werden.
    • Admins bzw. Nutzer mit dem nötigen Recht (gibt es bereits) können im Backend für den Notfall ebenfalls noch neue Elemente anlegen, bei denen dann der Key, Beschreibung, Default und Übersetzung in der DB stehen.
    • Ist ein Key bereits in YAML definiert, kann er natürlich im Backend nicht neu vergeben werden.
    • Ist ein Key bereits in der Datenbank vorhanden und wird dann erst vom Entwickler in der YAML-Datei definiert, so hat der vom Entwickler vergebene Key mit seinen Übersetzungen Vorrang (Das hängt hier stark von der Datenstruktur ab, inwieweit man die doppelten Keys dann verwaltet oder mergt).

    Die YAML-Datei könnte wie folgt aussehen:

    my.translation.key:
       description: 'Dieser Key hat eine Beschreibung.'
       default: 'Mumblefoo'
       group: 'Meine Gruppe'
    my.other.key:
       description: 'my.other.key.description'  # <- Derartige Konstrukte müssen möglich sein, allerdings nicht beliebig rekursiv (eine Ebene reicht)
       group: 'Meine andere Gruppe'
    my.other.key.description:
       description: 'Dieser Key enthält den Hilfetext für my.other.key.'
       group: 'Meine andere Gruppe'
    there_is_no.defined-format_for.keys:
       description: 'Allerdings sollten wir uns auf die Notation "foo.bar.world" einigen. Aus Sicht des AddOns sind die Punkte im Key jedoch irrelevant.'
    

    Der Großteil des Backends kann wohl bestehen bleiben, aber die Implementierung wird sich wohl zu 80% ändern müssen. Das sehen wir dann im Laufe der Entwicklung.

  2. Log in to comment