Externe Übersetzungen eigener Add-ons erleichtern

[AA_]

ein add-on besteht immer nur aus einer sprache, weil man nicht verschiedene sprachen in die installations-/updateroutine einbauen kann.
hier müssen nun im nachhinein übersetzungen angefertigt werden für sprachfiles.

das problem ist nun, dass übersetzer nicht zwangsläufig administratoren sind. und selbst wenn man einem benutzer berechtigungen für die sprachenverwaltung geben würde, heisst das nicht, dass jemand was damit anfangen kann. es fehlen im vbulletin schlicht und einfach wesentliche voraussetzungen für eine fehlerfreie übersetzung, weil man den kontext der phrasen nicht kennt oder nur vermuten kann. selbst gestandene und versierte vbulletin-administratoren, dürften damit ein problem haben.

ich habe lange überlegt, wie man aus dieser nummer herauskommt und einem vbulletin-laien die phrasen erklären kann - und das hier ist dabei herausgekommen:

ich binde in die add-on-datei (xml-file) einen externen stylesheet ein und lasse mit diesem das xml transformiert ausgeben. dabei beschränke ich mich auf die wesentlichen informationen, die ein übersetzer benötigt.

der übersetzer ruft dazu über den browser die add-on-datei auf und würde normalerweise die komplette xml-datei im browser angezeigt bekommen. die darstellung ist je nach browser sehr verschieden und nicht wirklich hilfreich. mit einer transformierten anzeige (die datei selbst bleibt unverändert) könnte das dann so aussehen:

4962

anders als im vbulletin werden hier kommentare sichtbar. dies kann man sich zu nutze machen und den kontext der texte so beschreiben, dass ein übersetzer keine fragen mehr stellen muss. und ehrlich gesagt... selbst ich als entwickler weiss nach ein paar wochen nicht mehr genau, wo bestimmte phrasen verwendet werden.

wie funktioniert das ganze?

als erstes erzeugt man sich eine leere datei mit beliebigen namen und der endung xsl. diese datei hat folgenden inhalt:

HTML:
----------
Der Inhalt dieses Abschnitts ist nur für Lizenznehmer sichtbar, Sie werden derzeit jedoch nicht als Lizenzinhaber erkannt.<br />
<br />
Bitte öffnen Sie den <a href="http://members.vbulletin-germany.com/membersupport_priority.php">Kundenbereich</a>, tragen Sie Ihre E-Mail-Adresse ein, mit der Sie sich hier registriert haben und aktivieren Sie die Lizenzüberprüfung für http://www.vbulletin-germany.org.
----------

diese datei ist für alle addons geeignet und sollte vielleicht in einem unterverzeichnis 'xsl' auf dem webserver gespeichert werden, zb. als 'vbulletin_products.xsl'.

jetzt bearbeitet man sein add-on, welches man übersetzen lassen will und fügt dort den link zur externen stylesheet-datei (siehe oben) ein:

HTML:
----------
Der Inhalt dieses Abschnitts ist nur für Lizenznehmer sichtbar, Sie werden derzeit jedoch nicht als Lizenzinhaber erkannt.<br />
<br />
Bitte öffnen Sie den <a href="http://members.vbulletin-germany.com/membersupport_priority.php">Kundenbereich</a>, tragen Sie Ihre E-Mail-Adresse ein, mit der Sie sich hier registriert haben und aktivieren Sie die Lizenzüberprüfung für http://www.vbulletin-germany.org.
----------

der pfad muss natürlich angepasst werden!

ruft man das add-on nun über den browser im web auf (vorausgesetzt natürlich, man hat die add-on-files im web verfügbar :D), sollte zumindest schonmal eine tabelle mit allen phrasen erscheinen, statt dem üblichen xml-kauderwelsch.

sehr wahrscheinlich wird die anzeige der zeichen falsch sein. denn die add-on-datei hat einen zeichensatz, der auf ISO-8859-1 stehen muss, auch wenn man darin unicode-daten gespeichert hat. dieser nonsens ist ein vbulletin-problem und ist nicht allgemeingültig!

je nachdem, mit welcher kodierung man seine add-ons erstellt, muss dann in der xsl-datei der zeichensatz ebenfalls angepasst werden. das ist alles sehr nervig... aber wer einen apache-webserver benutzt, kann hier eine korrekte darstellung erzwingen.

ich habe zb alle add-ons in einem unterverzeichnis namens '/addons' liegen (mit unterverzeichnissen für jedes add-on). in der vhost-konfiguration habe ich für dieses verzeichnis den charset 'UTF-8' für alle dateien mit der endung .xml erzwungen, so dass die merkwürdige encoding-angabe in der xml-datei ignoriert wird:

CODE:
----------
Der Inhalt dieses Abschnitts ist nur für Lizenznehmer sichtbar, Sie werden derzeit jedoch nicht als Lizenzinhaber erkannt.<br />
<br />
Bitte öffnen Sie den <a href="http://members.vbulletin-germany.com/membersupport_priority.php">Kundenbereich</a>, tragen Sie Ihre E-Mail-Adresse ein, mit der Sie sich hier registriert haben und aktivieren Sie die Lizenzüberprüfung für http://www.vbulletin-germany.org.
----------

man kann alternativ auch eine .htaccess-datei in das betreffende verzeichnis legen und dort die zeile hineinschreiben:

CODE:
----------
Der Inhalt dieses Abschnitts ist nur für Lizenznehmer sichtbar, Sie werden derzeit jedoch nicht als Lizenzinhaber erkannt.<br />
<br />
Bitte öffnen Sie den <a href="http://members.vbulletin-germany.com/membersupport_priority.php">Kundenbereich</a>, tragen Sie Ihre E-Mail-Adresse ein, mit der Sie sich hier registriert haben und aktivieren Sie die Lizenzüberprüfung für http://www.vbulletin-germany.org.
----------

hm, wieso werden bei mir keine kontext-texte angezeigt wie auf dem screenshot?

die texte, die oben im screenshot oberhalb der phrasen stehen, sind kommentare aus der add-on-datei. diese kommentare kann man leider nicht mit dem phraseneditor von vbulletin erzeugen, sondern nur in der datei selber:

HTML:
----------
Der Inhalt dieses Abschnitts ist nur für Lizenznehmer sichtbar, Sie werden derzeit jedoch nicht als Lizenzinhaber erkannt.<br />
<br />
Bitte öffnen Sie den <a href="http://members.vbulletin-germany.com/membersupport_priority.php">Kundenbereich</a>, tragen Sie Ihre E-Mail-Adresse ein, mit der Sie sich hier registriert haben und aktivieren Sie die Lizenzüberprüfung für http://www.vbulletin-germany.org.
----------

ja, richtig! der kommentar steht innerhalb des elements und nicht darunter oder darüber, sondern genau wie im beispiel!

beim importieren der datei (also beim installieren oder updaten eines add-ons) werden diese kommentare ignoriert und nicht importiert.

vielleicht kann ja jemand mit dieser idee was anfangen :)

[AA_]

noch ein nachtrag bezüglich der charset-einstellungen: ich habe oben das UTF-8 als beispiel genannt, weil ich add-ons per default mit UTF-8 entwickle und diese dann später beim veröffentlichen automatisch während des downloads umkonvertiere.

der nachteil ist, dass man trotzdem den charset iso-8859-1 in das add-on schreiben muss. das führt dann dazu, dass browser beim aufruf der datei falsch darstellen, wenn der zeichensatz nicht passt zum eigentlichen inhalt.

um dieses problem zu umgehen, erzwinge ich das senden des charset-headers per webserver. wer alles in iso-8859-1 entwickelt, muss allerdings den charset der xsl-datei anpassen, denn dort steht UTF-8 drin ;)

wer mit dem ganzen hier so gar nichts anfangen kann, hier (http://geb.german-elite.net/addons/vbsoccer/src/index.php?lang=en) und hier (http://geb.german-elite.net/addons/pm_ssl2/pm_ssl.xml) gibt es noch je ein live-beispiel einer transformation mithilfe der xsl-datei.
beide dateien sind die entwicklerversionen von veröffentlichten add-ons, wobei in einem add-on die kommentare nicht transformiert werden, weil sie schlicht nicht vorhanden sind.

wer sich die quelltexte ansieht, wird etwas verwirrt sein, wenn das thema neuland ist. denn der quelltext ist in wirklichkeit das originale add-on-xmlfile. ganz oben findet sich in beiden dateien noch die angabe der doctypes 'product'. mit dieser DTD lassen sich add-ons validieren - hm, aber das ist wieder ein ganz anderes thema *g*

falls jemand noch eine idee hat, wie man das ganze verbessern oder irgendwie nutzbar machen kann, her damit :)

[Cosmo]

Wäre das nicht Wert, es direkt ins vBulletin zu integrieren? Da würde sich doch auch das Add-on von Andreas (Produckt Translation Tool) prädestinieren dafür, also eine Integration (IMHO), und wäre auch so nicht auf ein externes Tool unbedingt angewiesen.

[AA_]

wenn sich die kontext-beschreibung (auf welche weise auch immer) durchsetzen würde, wäre das ein grosser schritt. allerdings ist der aufwand auch enorm.

darüber hinaus ist die einbindung eines stylesheets in die produktdatei zur darstellung von phrasen nur eine von vielen möglichen anwendungen. beispielsweise könnte man installationsanweisungen, add-on beschreibungen und vieles mehr damit realisieren.

ein ganz neuer ansatz wäre auch noch die modularisierung der produkt-dateien! dann nämlich hätte man nur noch eine kern-datei und könnte beliebige sprachen integrieren über externe dateien. soll heissen, der kern wäre in einer beliebigen sprache (mastersprache) und über dynamische includes könnten dann teile des produktes ausgetauscht oder ausgelagert werden. dieses aufteilen gibt es bereits für die installation (einstellungen, admin-hilfe, sprachen). leider wurden dort die root-elemente anders bezeichnet, als sie in der produkt-datei vorkommen.

[Tyran]

Also im grunde werden die phrasen nur abgezeigt und nichts übersetzte ??

Eine automatische Übersetztung wäre dahin gegend GENIAL !!

[AA_]

Also im grunde werden die phrasen nur abgezeigt und nichts übersetzte ??

Eine automatische Übersetztung wäre dahin gegend GENIAL !!

ja, es ist ja nur eine einbindung eines stylesheets zur darstellung der datei. nur dass sich mit xml und xslt gegenüber dem css bei html richtige transformationen durchführen lassen.

die xsl-datei ist quasi wie ein text-prozessor, der anweisungen enthält, welche texte aus dem gesamtdokument in welcher form dargestellt werden sollen.

ich habe dazu gerade soviele flausen im kopf, dass ich das unmöglich alles aufschreiben kann. aber mit hilfe dieser technik (xml, xslt, etc.) kann sich jeder entwickler eine eigene entwicklungsumgebung für add-ons aufbauen.

"einfaches" beispiel:

ich nehme eine add-on-datei als grundgerüst, schreibe aber statt den übersetzbaren bestandteilen (i.d.R. phrasen) nur verlinkungen auf externe dateien hinein, die sprachenabhängig sind. das ganze dann in verbindung mit einer steuerdatei in php. diese datei liefert dann je nach parameter die richtige sprachversion des kompletten add-ons, indem es die verschiedenen module der xml-datei zu einer neuen datei zusammenfügt. dabei kann man gleich ganz nebenbei das encoding mit steuern. der "endbenutzer" - also der nutzer des add-ons - bekommt nach wie vor seine xml-datei wie er es kennt. nur der weg dorthin ist etwas optimierter.

denn wer kennt das nicht: man hat 2 oder mehr sprachversionen eines add-ons und muss bei jeder kleinen änderung des add-ons alle sprachenbestandteile mit ändern. manche machen das mit extra-sprachfiles und manche machen das mit verschiedenen add-on-sprachversionen.

ich hab einfach keinen bock auf jeweils unterschiedliche versionen des gleichen add-ons (sprachen, encoding).

xml ist weitaus mächtiger, als man denkt. was in vbulletin integriert ist, darf man getrost als rudimentär bezeichnen. da geht noch einiges mehr, ohne das prinzip dabei über den haufen werfen zu müssen.

das anzeigen der texte in einem add-on ist für mich sehr wichtig, wenn ich mich nicht auf die übersetzung eines sehr speziellen textes von einem einzelnen mitarbeiter verlassen will. mit hilfe der technik hier, kann ich zb in meiner community die datei zeigen, damit die interessierten mitarbeiter nicht nur blöde phrasen sehen, wo man meistens nicht weiss, wo die angezeigt werden. gerade das thema fussball (wie oben im beispiel) ist ein heisses eisen bei übersetzungen. da kann ganz schöner dummfug rauskommen, wenn man sich da auf einen übersetzer verlässt der keine ahnung von fussball hat ;)

[AA_]

jetzt kommt mir doch glatt ne ganz perverse idee...
ich kann in die xsl-datei auch ein formular einbauen, so dass die texte bearbeitet und/oder übersetzt werden können (beliebige sprachen!). die müssten dann natürlich jeweils in einer neuen datei gespeichert werden (das kann ein sprachfile sein). somit könnte man ganz easy ein übersetzungstool für die community anbieten, wo man verschiedene revisionen integrieren kann.

so in etwa hätte ich mir auch die übersetzung des vbulletins selber vorgestellt. ein echtzeitübersetzungs-tool mit möglichkeit des korrigierens und auscheckens für jedermann - allerdings immer mit der option, dass irgendwer eine phrase für endgültig erklärt, wenn alle damit einverstanden sind.

[Tyran]

Na das hört sich wirklich gut an!

[Andreas]

Nette Idde, aber ohne dich demotivieren zu wollen:
Es wird (so gut wie) niemand nutzen, allein schon weil der Aufwand viel zu groß ist.

[AA_]

jetzt habe ich endlich eine möglichkeit gefunden, addons so zu modularisieren, dass ich mit einem mausklick das gleiche add-on in mehreren sprachen exportieren kann (erstellung der zipdatei).

ganz nebenbei entfallen beim entwickeln alle phrasen in der produkt-datei. stattdessen werden echte language-files erzeugt, die sich später auch einzeln exportieren lassen als das was sie sind.

dazu schreibe ich in die produkt-datei nur noch ein leeres element <phrases>.

in der regel schreibt man die phrasen ja während der entwicklung immer nur in einer sprache und übersetzt es später oder lässt es übersetzen. dazu erzeuge ich während der entwicklung eine sprachdatei, wie man sie von vielen add-on-übersetzung mit extra-sprachfiles kennt und bearbeite diese datei.

der aufwand mag absurd erscheinen, lohnt sich aber dann, wenn man add-ons übersetzen will oder die übersetzung erleichtern will. man macht das gesamte add-on also sprachenunabhängig und "includiert" dann die gewünschte sprache in den oben genannten leeren <phrases>-block.

live-beispiele mit dem fussball-tippspiel:
produkt in englisch (http://geb.german-elite.net/addons/vbsoccer/src/index.php?lang=en)
produkt in deutsch (Sie) (http://geb.german-elite.net/addons/vbsoccer/src/index.php?lang=de-sie)
produkt in deutsch (Du) (http://geb.german-elite.net/addons/vbsoccer/src/index.php?lang=de-du)

da ich einen downloader habe, um alle notwendigen dateien des add-ons in ein zip-archiv zu packen und vorher notfalls die datei-kodierung anzupassen, kann ich mit hilfe dieser technik per klick gleich 6 varianten des add-ons erzeugen (3 sprachvarianten * 2 dateikodierungen).

der trick, den inhalt einer vbulletin-sprachendatei in eine produkt-datei hineinzuzaubern, ist mit ein paar zeilen php-code realisierbar:

PHP:
----------
Der Inhalt dieses Abschnitts ist nur für Lizenznehmer sichtbar, Sie werden derzeit jedoch nicht als Lizenzinhaber erkannt.<br />
<br />
Bitte öffnen Sie den <a href="http://members.vbulletin-germany.com/membersupport_priority.php">Kundenbereich</a>, tragen Sie Ihre E-Mail-Adresse ein, mit der Sie sich hier registriert haben und aktivieren Sie die Lizenzüberprüfung für http://www.vbulletin-germany.org.
----------der aufruf der 3 live-beispiele arbeitet genau diesen code ab.

beim exportieren eines add-ons rufe ich also diesen mechanismus auf und erhalte meine produktdatei, die ich dann anschliessend noch für einen anderen zeichensatz aufbereite.

um zurück zu meinem ausgangspost zu kommen: jetzt kann ich zb in einem forum um mithilfe bei der übersetzung bitten und dann dort die entsprechende sprach-variante als link posten.

übernehme ich eine übersetzung in das sprachfile, dann setze ich ein zusätzliches attribut "translated" im phrasen-tag. mit hilfe der xsl-transformation kann ich dieses attribut abfragen und dann den eintrag in der darstellung entsprechend hervorheben, damit man sieht, was noch zu übersetzen ist. in der beispielausgabe für englisch kann man sich das ansehen (icon vor der übersetzten phrase).

ich hab keine ahnung, wie es auf vbulletin-germany.com gemacht wird beim downloaden. aber ich denke, dass sich mit meiner technik der modularisierung von phrasen während der entwicklung zum zwecke des vereinfachten exports produktionsprozesse vereinfachen lassen.

denn durch die trennung des plugin- und installationscodes von den phrasen, erreicht man u.a., dass man bei einer codeänderung nicht alle sprachvarianten einzeln ändern muss. auch muss man keine sprachfiles später selber erstellen, weil man die ja schon von anfang an hat und auch getrennt exportieren kann. da spart man sich ne ganze menge arbeit :)