+- GridTalk.de (https://www.gridtalk.de)
+-- Forum: Showcase (https://www.gridtalk.de/forumdisplay.php?fid=5)
+--- Forum: Projektvorstellung (https://www.gridtalk.de/forumdisplay.php?fid=33)
+--- Thema: Mannis Firestorm Viewer (/showthread.php?tid=5128)
Mannis Firestorm Viewer - Manfred Aabye - 17.08.2025
Meine Anpassungen am Firestorm Viewer
Ich habe begonnen, den Firestorm Viewer zu modifizieren.
Bisher habe ich folgende Änderungen vorgenommen:
✅ Logos hinzugefügt für WebRTC und OpenAL.
✅ Deutsche Übersetzungen verbessert (z. B. "Blinn-Phong" zu "Standart-Texturen" (Std-Texturen).
Geplante Änderungen:
? Singularity-Skin-Anpassungen:
• Der Viewer aktualisiert sich erst, wenn der Singularity-Skin ausgewählt wird.
• Ich möchte das "Datei"-Menü aus Singularity wiederherstellen, das alle Upload- und Download-Optionen enthält.
• Dabei soll die Optik des Standard-Firestorm weitgehend erhalten bleiben.
Fragen an euch:
❓ Was haltet ihr von den Änderungen?
❓ Gibt es etwas, das eurer Meinung nach fehlt oder verbessert werden sollte?
RE: Mannis Firestorm Viewer - Bogus Curry - 17.08.2025
Moin Manni ;D
Könnte man den Viewer auch modular aufbauen ? Also zum Beispiel, wenn jemand überhaupt gar nicht bauen möchte und daher den Editor gar nicht braucht, einfach ihn zu deaktiveren. Oder die Webbrowser ein wenig verbessern und evtl. Console intrigieren, so das man aus dem Viewer herraus, auch Regionen restarten kann.
Sind halt Vorschläge, die mir so spontan einfielen ;D
RE: Mannis Firestorm Viewer - Manfred Aabye - 17.08.2025
Daran habe ich auch schon gedacht:
Das gesamte Menü für Bauen, Chat, Avatar und Ähnliches ein- und ausblendbar zu machen,
sodass man einzelne Bereiche je nach Bedarf aktivieren kann – einfach, um mehr Übersicht zu schaffen.
Dafür müsste man allerdings rund 780 Dateien pro Sprache ändern.
Im Menü Welt - > Region/Grundbesitz - > Debug - > Region neu starten --- gibt es ja bereits.
Phoenix-FirestormOS WebRTC_AVX2 7.2.0.78895
Meine erste Version, die im Sourcecode verändert wurde.
https://github.com/ManfredAabye/phoenix-firestorm/releases/
Ach so, vergessen zu erwähnen: Inworld Restart ist wirklich nur der Region Restart nicht der Simulator Restart.
Wenn ihr in den Konfigurationen Restart in Shutdown ändert, dann geht der aus bis er automatisch neu gestartet wird, wenn ihr ein Skript verwendet wie osmtool.sh und deren Restartmechanismus verwendet.
RE: Mannis Firestorm Viewer - Manfred Aabye - 17.08.2025
Ich verstehe auch nicht warum die XUI XML Daten nicht beim Aufruf von Schlüsselworten mit gettext übersetzt werden.
Warum die Idee Sinn ergibt
Vorteil ----------------------- Beschreibung
• Zentrale Übersetzung - Alle Texte landen in .pot/.po/.mo – keine verstreuten Klartexte
• Kleinere XML-Dateien - Nur Schlüsselworte wie ui_menu_build, nicht „Bauen“, „Build“, „Construire“ etc.
• Einfachere Lokalisierung - Übersetzer müssen nur .po-Dateien bearbeiten, keine XMLs anfassen
• Dynamische Sprachumschaltung - gettext kann zur Laufzeit die Sprache wechseln
• Weniger Redundanz - Ein XML-Satz für alle Sprachen – kein Duplizieren pro Sprache
RE: Mannis Firestorm Viewer - Manfred Aabye - 18.08.2025
Phoenix-FirestormOS WebRTC_AVX2 7.2.0.78899
Inoffizielles Quell-Repository für den Firestorm Viewer.
Bitte verwenden Sie nicht die Build Instructions diese funktionieren nicht.
Da Phoenix-FirestormOS genauso gut mit den gleichen Fehlern funktioniert und ich das eh als Release erstelle, mache ich ab jetzt keine pre-release Ankündigungen mehr.
https://github.com/ManfredAabye/phoenix-firestormOS/releases/
RE: Mannis Firestorm Viewer - Pius Noel - 18.08.2025
(18.08.2025, 11:45)Manfred Aabye schrieb: Phoenix-FirestormOS WebRTC_AVX2 7.2.0.78899Ist das jetzt die letzte Version mit deinen Anpassungen oder einfach nur die aktuellste Beta Version der Quelldateien auf GitHub, aber von dir kompiliert?
Inoffizielles Quell-Repository für den Firestorm Viewer.
Bitte verwenden Sie nicht die Build Instructions diese funktionieren nicht.
https://github.com/ManfredAabye/phoenix-firestorm/releases/
RE: Mannis Firestorm Viewer - Pius Noel - 18.08.2025
(17.08.2025, 20:55)Manfred Aabye schrieb: Ich verstehe auch nicht warum die XUI XML Daten nicht beim Aufruf von Schlüsselworten mit gettext übersetzt werden.Ich denke, dass das vor allem historisch bedingt ist und man das heute anders machen würde.
Warum die Idee Sinn ergibt
Vorteil ----------------------- Beschreibung
• Zentrale Übersetzung - Alle Texte landen in .pot/.po/.mo – keine verstreuten Klartexte
• Kleinere XML-Dateien - Nur Schlüsselworte wie ui_menu_build, nicht „Bauen“, „Build“, „Construire“ etc.
• Einfachere Lokalisierung - Übersetzer müssen nur .po-Dateien bearbeiten, keine XMLs anfassen
• Dynamische Sprachumschaltung - gettext kann zur Laufzeit die Sprache wechseln
• Weniger Redundanz - Ein XML-Satz für alle Sprachen – kein Duplizieren pro Sprache
Systeme wie XUI haben aber auch den Vorteil, dass sie durch die Trennung vom Code eine hohe Flexibilität gewährleisten. Sie erlauben es, nebst dem Text auch UI-Eigenschaften wie Größe, Position oder Sichtbarkeit von Elementen direkt in der XML-Datei zu definieren und müssen nicht im Code gepflegt werden. Im Gegensatz dazu müsste bei einem reinen gettext-Ansatz die UI-Logik im Code festgelegt werden.
Auch wenn das für einen Secondlife/OpenSim-Viewer vielleicht weniger eine Rolle spielt, so kann das unter Umständen auch für die Lokalisierung wichtig sein, da es durchaus auch kulturelle Aspekte gibt, die nicht überall gleich gehalten werden. Vor 25 Jahren gab es noch relativ wenig Erfahrung mit solchen Projekten und ein Ansatz wie XUI konnte sich in einem Projekt wie Secondlife, wo die Offenheit zur Gestaltung der Benutzeroberfläche von grosser Wichtigkeit war, bestimmt gut durchsetzen.
Ich denke, dass die Organisation der XUI-Dateien nach Skin und nach Sprache auch die Verteilung und das Laden vereinfacht.
Ich kann jetzt nicht sagen, mit wievel Aufwand das verbunden wäre. aber ich könnte mir zwei Ansätze zur Loslösung der Texte aus den XML-Dateien vorstellen ohne das XUI-System zu verlassen. Das hätte bestimmt den Vorteil zur Vereinfachung der Übersetzungen.
1) Für jedes Element gibt es nur noch eine Sprache. Der Text wird durch einen eindeutigen Text-Schlüssel ersetzt. Der Code wird so angepasst, dass beim Einlesen der Daten der Textschlüssel in den zur Sprache passenden Text ausgetauscht wird.
Ich weiss nicht, wie gross der Aufwand dafür wäre. Gettext wird im Code überall gebracht, aber nicht im Zusammenhang mit dem UI.
2) Ein ähnliches System, aber man belässt den Code zu 100% wie er ist, aber man erzeugt nach Änderungen die XML-Dateien mit einem Generator. Zu jedem XUI-Element gibt es ein XML-Template, das als Vorlage dient. Das würde vor allem auch bedeuten, alle XML-Dateien zu studieren. Die sind nämlich, aus welchen Gründen auch immer, nicht für jede Sprache gleich. Der Aufwand diese dann anzupassen wäre lediglich noch eine Fleissarbeit.
Soweit meine Gedanken dazu. Ich persönlich werde das Projekt nicht angehen, obwohl ich es im Rahmen meiner Fähigkeiten füt machbar halte. Aber letztendlich sehe ich nicht ein wozu, zumal sich noch die Frage stellt, wie lange das noch dauern wird bis die KI das eh übernimmt!
RE: Mannis Firestorm Viewer - Manfred Aabye - 18.08.2025
# Du arbeitest mit den **XML-Übersetzungsdateien im Viewer**, und willst `gettext()` **dazwischen schalten**, sodass die Übersetzung **zur Laufzeit** passiert, **ohne die Originaldaten zu verändern**
(Mit Zuhilfenahme von Github Copilot Pro)
Es wird zum Beispiel geladen:
```xml
Code:
<map>
<key>Name</key>
<string>people and body</string>
<key>Category</key>
<string>people & body</string>
</map>Daraus muss das folgend mit gettext verändert werden, Beispiel Deutsch:
```xml
Code:
<map>
<key>Name</key>
<string>people and body</string>
<key>Category</key>
<string>Menschen & Körper</string>
</map>---
## ? Ziel im Kontext des Second Life Viewers
- Die Viewer-Engine lädt XML-Dateien (z. B. UI-Layouts, Kategorien, Inventargruppen etc.).
- Diese Dateien enthalten Strings wie `"people & body"` in `<string>`-Elementen.
- Du willst, dass **beim Zugriff auf diese Strings** automatisch `gettext()` verwendet wird.
- Die Übersetzung soll **nicht beim Laden**, sondern **beim Auslesen** passieren.
- Die Lösung muss **transparent** sein: Der Viewer-Code soll sich **nicht ändern müssen**.
---
## ✅ Lösung: Hook oder Wrapper für XML-Zugriff
In Second Life wird XML oft über die `LLXMLNodePtr` oder `LLSD`-Strukturen verarbeitet. Du kannst eine **Wrapper-Funktion oder Hook** einbauen, die:
1. Den Originalwert aus dem XML liest.
2. Prüft, ob er übersetzt werden soll (z. B. durch `<translatestring>` oder Schlüsselname).
3. `gettext()` aufruft.
4. Den übersetzten Wert zurückgibt.
---
## ? Beispiel: Wrapper-Funktion für LLSD oder LLXMLNode
Angenommen, du hast:
```cpp
Code:
std::string getTranslatedString(const std::string& raw) {
return gettext(raw.c_str());
}Dann kannst du in der Viewer-Logik (z. B. beim UI-Parsing) statt:
```cpp
Code:
std::string label = node->getValue();einfach:
```cpp
Code:
std::string label = getTranslatedString(node->getValue());Oder du baust es direkt in die `LLXMLNode::getValue()`-Methode ein, wenn du Zugriff auf die Quelle hast.
---
## ? Sprachwechsel zur Laufzeit
Second Life unterstützt bereits Sprachumschaltung über die Locale. Du kannst also:
```cpp
Code:
setlocale(LC_ALL, "de_DE.UTF-8");
bindtextdomain("secondlife", "/path/to/locale");
textdomain("secondlife");Und alle `gettext()`-Aufrufe liefern automatisch die neue Sprache.
---
## ? Erweiterungsidee: Automatische Markierung
Wenn du `<translatestring>` verwenden willst, kannst du beim XML-Parsing gezielt danach suchen:
```cpp
Code:
if (node->getName() == "translatestring") {
std::string raw = node->getValue();
std::string translated = gettext(raw.c_str());
// Weiterverarbeiten
}Oder du baust eine generische Funktion:
```cpp
Code:
std::string getLocalizedValue(LLXMLNodePtr node) {
if (shouldTranslate(node)) {
return gettext(node->getValue().c_str());
} else {
return node->getValue();
}
}---
## ? Fazit
Du brauchst:
- Eine **Zwischenschicht**, die `gettext()` beim Zugriff auf XML-Werte aufruft.
- Optional: Markierung im XML (`<translatestring>`) oder Schlüsselprüfung (`Category`, `Label`, etc.).
- Keine Änderung der Originaldaten.
- Sprachwechsel über `setlocale()` und `bindtextdomain()` jederzeit möglich.
RE: Mannis Firestorm Viewer - Manfred Aabye - 18.08.2025
Das Problem ist, zuerst muss Second Life das ganze ändern, sonst wird beim Firestorm nichts geändert.
Fazit: Ich glaube nicht, dass sowas zu meiner Lebenszeit noch möglich ist, wenn sie schon 16 Jahre für GLTF brauchten und es nicht einmal ganz eingefügt haben (GLTF Modell Import Export fehlt).
RE: Mannis Firestorm Viewer - Pius Noel - 19.08.2025
Das sehe ich leider auch so
