Unser neuer TranslationManager wurde Mitte 2020 releast und löst den alten TranslationManager ab, der mit einem Googlesheet gearbeitet hat.
Backend-Techniken
Der Translation-Manager hat „behind the scenes“ zwei Environments. Jede Language hat für jeden TranslationString (z.B. „misc.description“) und jedes Environment eine eigene Entity.
Das ermöglicht es uns nur portioniert auf live zu releasen – das heißt, dass wir zum Beispiel nur 5 von 10 Strings wirklich releasen wollen – der Rest bleibt auf dev.
Release auf Dev
Bei einem Release auf Dev wird auf mehrere Riddle-Instanzen gleichzeitig gepublished. Das lässt sich auch in der .env erweitern – die Ladezeit wird davon nicht groß beeinflusst, da alle Requests auch asynchron ablaufen.
Vorteil: Nicht jeder Entwickler muss immer die Translations auch flushen – also sind die Translations auf jeder Dev-Instanz zu jedem beliebigen Zeitpunkt frisch.
Release auf Live
Auf Live betrifft es immer nur www.riddle.com. Vor dem Release sieht man noch alle Strings, die sich in dev & live unterscheiden. Will man einen String noch nicht releasen, so hakt man ihn nicht ab und die alte Version des Strings wird immer noch auf riddle.com sichtbar sein. Sobald bestätigt, ist der Release in binnen von maximal einer halben Sekunde fertig und die Strings sind geupdated.
Das Build-System
Schon oft ist es vorgekommen, dass mal falsche Strings oder gar Strings gepublished wurden, die Riddle gecrasht haben. Um sowas schnell zu beheben, gibt es jetzt ein Fallback bzw. Build-System. Jeder Push auf jede beliebige Instanz wird in der Datenbank geloggt und die dazugehörigen Strings werden in der Entity mitgespeichert. Das heißt, dass wir zu jedem beliebigen Build uns zurückversetzen können und so sehr flexibel sind falls etwas kaputt geht bezüglich Strings.
Notiz: Das Ganze ist nur per Konsole mit Symfony-Commands möglich, da es sonst doch zu verlockend wäre 🙂