Skip to content

BG Translation Project [under construction]

ManuelManuel Member Posts: 199
edited September 2012 in [Archive] German Team
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...

Comments

  • ManuelManuel Member Posts: 199
    Ach ja, mit Opera funktionieren die Buttons noch nicht, keine Ahnung woran das liegt. Schau ich mir später an. Firefox/Chrome/IE funktionieren.
  • JarlJarl Member, Translator (NDA) Posts: 101
    Das sieht ja schon hervorragend aus :)
  • kangaxxkangaxx Member Posts: 681
    Ausgezeichnet, @Manuel!

    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)
  • NeoDragonNeoDragon Member Posts: 169
    Wirklich sehr gute Arbeit. Einfach, nicht überladen und zweckmäßig. Gefällt mir ausgesprochen gut.

    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.
  • kangaxxkangaxx Member Posts: 681
    edited September 2012
    Der Vorschlag von @Manuel ist, dieses Tool erstmal zu entwickeln und im deutschen Team zu testen.
    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.
  • kangaxxkangaxx Member Posts: 681
    Was auch nützlich sein könnte, wäre die entsprechende Ausgabe eines jeden einzelnen String im UI zu simulieren.

    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?
  • NeoDragonNeoDragon Member Posts: 169
    edited September 2012
    kangaxx said:

    Der Vorschlag von @Manuel ist, dieses Tool erstmal zu entwickeln und im deutschen Team zu testen.
    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.

    Das ist ein sehr wichtiger Punkt wie ich finde.

    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.
  • ManuelManuel Member Posts: 199
    Puh, ich weiß nicht. Hab das Gefühl, wenn wir jetzt alle ins Boot holen, bricht ein mittleres Chaos aus, was Wünsche und Meinungen angeht. Hab auch aus beruflicher Sicht eigentlich immer die Erfahrung gemacht, dass es effizienter ist, den Leuten, die noch nicht wissen, was sie wollen, etwas Fertiges zu präsentieren. Man muss nicht auf jede eventuelle Unzufriedenheit eingehen, solange das System grundsätzlich das macht, was es soll. Ist ja jetzt auch nicht so komplex, also man muss auch nicht übertreiben. "Einfach, nicht überladen und zweckmäßig", dabei sollten wir bleiben.

    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.
  • kangaxxkangaxx Member Posts: 681
    @Manuel: In Ordnung, dann folgen wir deinem ursprünglich vorgeschlagenen Plan und testen das erst mal nur innerhalb des Deutschen Teams.
  • JarlJarl Member, Translator (NDA) Posts: 101
    Kann es sein, dass alle Strings um eine Position verschoben sind, da die Datenbank nicht bei 0, sondern bei 1 anfängt?

    Gruß Jarl
  • kangaxxkangaxx Member Posts: 681
    @Jarl: Korrekt, die IDs und Strings stimmen nicht überein: Alle Strings sind um eine ID nach hinten verschoben.
  • ManuelManuel Member Posts: 199
    Die verschobenen IDs werden noch korrigiert.

    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).
  • kangaxxkangaxx Member Posts: 681
    Manuel said:


    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).

    Regelmäßig Backups anlegen ist auf jeden Fall notwendig. Das sollte mindestens einmal täglich geschehen. Wie können bestimmte Strings denn wiederhergestellt werden? Wird die gesamte Datenbank und alle 16 Sprachen mit einem Mal exportiert/importiert?
  • ManuelManuel Member Posts: 199
    Man zieht sich einfach regelmäßig per Export die TRA-Datei der Übersetzung, an der man arbeitet, und wenn mal was verloren geht oder überschrieben wird, muss man den String aus dieser Datei nehmen und erneut abspeichern. Sowas wie "letzte Aktion rückgängig machen" gibt es nicht, das war mir zu viel Aufwand.

    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.
  • kangaxxkangaxx Member Posts: 681
    @Manuel

    Hast du Fortschritte bei der Entwicklung deines Tools gemacht?
  • ManuelManuel Member Posts: 199
    edited November 2012
    In der Tat. Es gibt nun ein Glossar, man kann endlich exportieren, Strings werden blockiert während man daran arbeitet, es gibt zusätzliche Optionen, man kann sein Passwort ändern, Bugfixes hier und da, etc.

    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.
  • ManuelManuel Member Posts: 199
    Ok, im Glossar machen wir das mit den Varianten so wie hier:

    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.
  • ManuelManuel Member Posts: 199
    Aktueller Plan: In den nächsten Tagen noch ein paar Features umsetzen und den aktuellen Stand einspielen, dann hoffentlich endlich umsatteln und die nervigen Spreadsheets hinter sich lassen.
  • NeoDragonNeoDragon Member Posts: 169
    Falls niemand was dagegen hat, mache ich das Glossar zu meiner persönlichen Baustelle. Schließlich habe ich eine halbwegs vollständige Liste hier, die "nur" noch übertragen werden muss (das Google Drive - Sheet spiegelt nicht den aktuellen Stand wider).

  • kangaxxkangaxx Member Posts: 681
    Du bist der Richtige dafür, @NeoDragon. Nimmst du dann unser Glossar-Spreadsheet?
  • ManuelManuel Member Posts: 199
    @NeoDragon: Hab natürlich nix dagegen. Ich habe mich übrigens doch noch für Typen (Gebiete, Waffen etc.) im Glossar entschieden, ist einfach übersichtlicher.

    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.
Sign In or Register to comment.