BG Translation Project [under construction]
Manuel
Member Posts: 199
Hi Leute,
http://tlk.dotnull.de/index.php
Name: testuser
Password: test123
Leider hab ich noch nicht viel Sichtbares geschafft. Man kann die Strings laden und auch speichern, und man kann TRA-Dateien importieren (bitte erstmal lassen). Ansonsten muss ich die meisten Features noch umsetzen. Die Datenbank ist schon fertig modelliert, es fehlt jetzt nur noch stupide Programmierarbeit.
Der Testuser hat Admin-Rechte, was momentan nur bedeutet, dass er alle Translations sehen kann. Er soll jetzt erstmal nur zum Angucken und Testen genutzt werden. In der Datenbank ist momentan das englische Original und der deutsche Text-Patch, also noch keine für die EE überarbeiteten Strings. Ist zwar noch recht simpel alles, aber ihr könnt mir ja mal schreiben, was ihr euch wünschen würdet.
Geplant:
- Kommentar-Funktion (kommt beim Editieren rechts daneben)
- History
- Drafts, also persönliche Entwürfe von Strings.
- Kontext-abhängige Strings nachladen
- Glossar
- Import CSV
- Export TRA und CSV
Das umzusetzen dauert noch ein zwei Tage. Ich muss jetzt erstmal schlafen...
http://tlk.dotnull.de/index.php
Name: testuser
Password: test123
Leider hab ich noch nicht viel Sichtbares geschafft. Man kann die Strings laden und auch speichern, und man kann TRA-Dateien importieren (bitte erstmal lassen). Ansonsten muss ich die meisten Features noch umsetzen. Die Datenbank ist schon fertig modelliert, es fehlt jetzt nur noch stupide Programmierarbeit.
Der Testuser hat Admin-Rechte, was momentan nur bedeutet, dass er alle Translations sehen kann. Er soll jetzt erstmal nur zum Angucken und Testen genutzt werden. In der Datenbank ist momentan das englische Original und der deutsche Text-Patch, also noch keine für die EE überarbeiteten Strings. Ist zwar noch recht simpel alles, aber ihr könnt mir ja mal schreiben, was ihr euch wünschen würdet.
Geplant:
- Kommentar-Funktion (kommt beim Editieren rechts daneben)
- History
- Drafts, also persönliche Entwürfe von Strings.
- Kontext-abhängige Strings nachladen
- Glossar
- Import CSV
- Export TRA und CSV
Das umzusetzen dauert noch ein zwei Tage. Ich muss jetzt erstmal schlafen...
2
Comments
Spontan fallen mir folgende Vorschläge ein (weitere folgen):
- Signaturen (für verschiedene Phasen der Korrektur)
- Zugriffsrechte und Möglichkeit Strings zu sperren (falls keine Wiederherstellungsfunktion geplant ist)
Was das "große Ganze" betrifft haben kangaxx und du selbst ja schon einige Dinge genannt. Darum beschränke ich mich auf einige Kleinigkeiten (eigentlich ziemlich vernachlässigbar, aber mir mir fällt so etwas komischerweise grundsätzlich auf):
- Beim Klicken in das Textfeld mit der String-Nummer sollte die Zahl vielleicht nicht direkt beim Klicken komplett verschwinden, sondern nur markiert werden. Das vereinfacht die Benutzbarkeit (falls man beispielsweise nur eine Ziffer ändern möchte).
- Buttons für "Go First"/"Go Last" und "10 zurück"/"10 vor" (am besten ein-/ausblendbar, damit es nicht zu überladen wirkt)
- Eine Anzeige, die zuverlässig darüber informiert, in welchem String man sich momentan befindet, fehlt. Das oben angesprochene Textfeld erfüllt diese Funktion in der jetzigen Form nur bedingt, wie folgendes Szenario zeigt:
> man befindet sich in String 9375
> man will oben z.B. "12641" eingeben.
> man wird nach "126" unterbrochen (bestätigt die Eingabe nicht!), macht also z.B. 10 Minuten Pause
> Danach kehrt man zurück, kann aber nicht erkennen, in welchen Streing man sich nun befindet (okay, man geht ein vor und ein zurück, dann ist die Anzeige wieder korrekt, aber das ist suboptimal)
Ich hatte auch schon parallel an einem Glossar gearbeitet, habe aber damit aufgehört, als ich gehört habe, dass Du dieses Projekt in Angriff nehmen willst. Ich würde mir diesbezüglich (langfristig!!!) z.B. folgende Funktionen wünschen:
- Einen Eintrag zum Glossar hinzufügen (also englischer Begriff, zulässige deutsche Übersetzungen, Beschreibung; gilt auch für die nächsten beiden Punkte)
- Einen Eintrag aus dem Glossar löschen
- Einen Eintrag "kopieren" (bei strukturell ähnlichen Begriffen sinnvoll)
- Einen Eintrag ändern (z.B. eine zulässige Übersetzung hinzufügen [mitunter sind ja mehrere Varianten zulässig])
- Jedem Eintrag einen Typ zuordnen (das erleichtert die Suche), z.B. "Ortschaft", "Zauberspruch", "Person" etc.
- Andere Tags/Flags ("Vorkommen in anderen, verwandten Projekten (j/n) ?", "Diskussionsbedarf (j/n)", ...) definieren/setzen
- String-Nummer des ersten/letzten Vorkommens; Gesamtanzahl aller Vorkommen; Liste aller Vorkommen (jeweils für e+d)
- entsprechende Strings einblenden (jeweils für e+d)
- Auf Wunsch alle oder eine Teilmenge der Eintrag (z.B. alle Personen) in Text selbst kenntlich machen (unterstreichen, farblich, andere Formatierungen, ...) und die Erklärungen als Tooltip angezeigen.
Ich würde zwar auch gerne daran mitarbeiten, allerdings beschränken sich meine praktischen Kenntnisse im DB-Bereich auf VBA und Access/Java als Frontend.
Was haltet ihr denn davon die Entwickler und die anderen Teams gleich von Beginn an mit einzuspannen? Gerade in der Anfangsphase kann möglichst breitgestreuter Input nützlich sein. Man muss ja nicht alles implementieren.
Was hältst du davon, @Manuel? Würde das deine Arbeit negativ beeinflussen? Ich würde vorschlagen, wir richten uns da nach dir.
Was ich damit meine, ist, dass wir im besten Falle auch schon die Formatierung und das Layout sehen, ohne das Spiel starten zu müssen.
Soweit ich weiß, gibt es ja eine ganze Reihe von verschiedenen Möglichkeiten, wie die Strings dargestellt werden können, z.B.
- Tooltip
- Dialogfenster unten mitte
- Text von Items/Zaubern etc.
- Text in Menüs
- etc.
Was man im Grunde genommen braucht, wären die Daten für jedes UI-Element, z.B. Zeilenlänge etc.
Was meint ihr?
Unabhängig davon, ob es im Endeffekt für das deutsche Team oder für "alle" programmiert werden soll, denke ich wie folgt darüber:
Man sollte meiner Meinung nach alle künftigen Anwender (jedenfalls Vertreter der verschiedenen Gruppen) in jeden Schritt des Entwicklungsprozesses mit einbeziehen. Ich halte das ehrlich gesagt für erforderlich (und je mehr Leute das System verwenden sollen, desto zwingender ist das in meinen Augen). Denn sonst hat man später eine Heidenarbeit, wenn nicht einbezogene Anwender dann unzufrieden sind und diverse, möglicherweise gravierende, Änderungswünsche an einem bereits größtenteils fertigprogrammierten System äußern (Änderungen eines bestehenden Systems sind i.d.R. sehr aufwendig und verursachen u.U. unvorhersehbare Seiteneffekte).
Es beginnt schon bei der Plattform. Je nachdem, wie viele Leute gleichzeitig Zugriff auf das System haben könnten, eignen sich einige Systeme (schon rein aus Performancegründen) besser oder schlechter als andere für dieses Projekt.
Ich wäre dafür, dass wir alle Beteiligten ins Boot holen und danach zusammen einen Anforderungskatalog erarbeiten. Große Teile der Programmierarbeit sollten erst danach beginnen (eine gewisse Rumpfprogrammierung ist hiervon ausgenommen).
Das ist allerdings nur ein Vorschlag. Im Endeffekt will hängt es natürlich von Manuel ab.
Ok, mal eins nach dem anderen. Was ich jetzt mache:
Account-Funktionalitäten mit Zugriffsrechten, Ameldung, Passwort ändern, Double Opt-In per E-Mail. Ich habe momentan folgende "Rollen" vorgesehen:
- Admin: darf alles und sieht alles
- Coordinator: darf alles innerhalb einer Translation
- Translator: darf übersetzen aber keine Rechte vergeben
Proofreader und Rule Police kann jeder machen, indem er den String entsprechend signiert.
Danach: Kontext-Strings nachladen.
Die Kleinigkeiten wie zusätzliche Buttons und so kommen zum Schluss.
Gruß Jarl
Ich werde nachher das BGTP auf den neusten Stand bringen, dann kann sich jeder schonmal dort anmelden usw.
Folgendes kommt hinzu: Account-Funktionalitäten, Kontext-Strings nachladen, Kommentar-Funktion, Signieren und History.
Das Nachladen der Kontext-Strings wird wie folgt funktionieren: Man kann mit jedem String den vorangehenden String oder die folgenden Antworten manuell verknüpfen. Ich hatte erst vor, wie damals beim WMTP die D-Skripte zu importieren, habe mich dann aber dagegen entschieden. Es muss jetzt jemand, der die Skripte lesen kann, die entsprechenden Verknüpfungen im BGTP anlegen, wobei man Fehler sehen und flexibler reagieren kann.
Das Signieren beschränkt sich momentan auf "signed as proofreader" und "signed as rule police", was jeder kann, und "protected", was nur ein Coordinator kann. Man kann auch im Rahmen der Kommentare einen String als "debatable" markieren. Reicht das aus, oder brauchen wir noch mehr Schritte?
Die History wird nur wiedergeben, wann welche Aktionen an einem String durchgeführt wurden und durch wen. Die Strings selbst werden nicht gesichert. Stattdessen wär's mir lieber, wenn regelmäßig Backups per Export gezogen werden, dann bläst sich die Datenbank nicht so auf (bei 16 Sprachen und zigtausenden Strings schon so kein kleiner Happen).
Ein nächtliches Backup der gesamten Datenbank kann und sollte natürlich auch eingerichtet werden. Das wär dann Sache der Server-Admins. Wenn die Seite in produktiven Betrieb übergeht, dann aber nicht auf meinem Server, das würde ich aus Sicherheitsgründen lieber Beamdog überlassen.
Hast du Fortschritte bei der Entwicklung deines Tools gemacht?
Einem produktiven Einsatz steht eigentlich nichts mehr im Weg. Ich habe momentan die englischen und deutschen Strings aus der aktuellen Beta drin, allerdings ohne die neuen Strings, die kommen erst nach dem Release rein.
Das Glossar ist noch recht rudimentär, erfüllt aber seinen Zweck. Man muss immer erst den englischen Begriff eintragen und zu diesem dann die Übersetzungen hinzufügen. Sollten mal mehrere Übersetzungen möglich sein, sollte die meistgenutzte eingetragen und die anderen Varianten in der Beschreibung erwähnt werden.
Was ich noch geplant habe:
- Suche im Glossar soll auch die Beschreibung durchsuchen
- Suchmöglichkeit, um alle Strings einer Übersetzung zu durchsuchen
- Anzeige der Änderungen seit der letzten Aktivität
- Schwarzes Brett
Ich werde mich jetzt aber wieder bis zum Release auf die Spreadsheets konzentrieren, damit die Übersetzung rund wird. Danach kann man sich ja dem BGTP zuwenden und schauen, dass man alle Sprachen importiert, die Kontextdaten aus den Dialogskripten einträgt usw.
Das Ziel ist, mit dem Tool eventuelle weitere Enhanced Editionen sowie Mods zu übersetzen. Es können damit beliebig viele Übersetzungen abgefrühstückt werden. Ach ja, eine Download-Seite für fertige Übersetzungen ist auch noch geplant.
http://tlk.dotnull.de/index.php?page=glossary&term=Abyss
Also einfach die Begriffe per / trennen. So hat man es auf einen Blick und ich brauche die Suche nicht erweitern. Komplizierter mach ich's erstmal nicht, es soll ja nur ein Nachschlagewerk für Übersetzungen sein und kein Wiki.
Ich habe übrigens Cameron angeboten, das BGTP auf einen Beamdog-Server zu packen, und er hat ja gesagt. Die neuste Version geht in den nächsten Tagen online, und dann können wir mit der Nachkorrektur von BG1 und vielleicht auch schon mit der Vorbereitung für BG2 anfangen.