Metadaten-Chaos: Komplette Topics filtern

Der Dating DITA-Vortrag kommt mir gerade wieder in den Sinn, wo ich mich Metadaten beschäftige. Und da stehen mir wirklich die Haare zu Berge – das ist das erste Mal, dass ich DITA wirklich, wirklich unpraktisch finde und noch keine gute Lösung habe, wie ich da in Zukunft verfahren soll.
Wie man komplette Topics nicht rausfiltert
Nehmen wir mal an, ich generiere aus einer Map einen User-Guide und einen Admin-Guide. Viele Inhalte überschneiden sich, aber einige sind exklusiv nur für eine der Zielgruppen gedacht.

Bisher dachte ich mir das so: Wenn ich von einem kompletten Topic weiß, dass es nur audience=“user“ ist, dann setz ich das Attribut auf das Root-Element, also so:
<task id="123" product="wundertuete2" audience="user">...

Dann wird doch dieses Topic, auf diese Weise attributiert, nun beim Generieren des Admin-Guides bestimmt nirgends verlinkt bzw. gar nicht erst generiert.

Weit gefehlt. Das Topic wird generiert und zwar leer (und damit nicht valide). Alle Verlinkungen, sprich: alle Topicrefs, sind auch im Output existent, führen aber natürlich ins Leere.

Wie man komplette Topics wirklich rausfiltert
Um zu verhindern, dass etwas überall verlinkt wird, muss man das Attribut auf jeden Topicref setzen!
<topicref id="123" product="wundertuete2" >
<</topicmeta></topicref>

Und zwar auf wirklich jeden, auch die in den Relationship tables. Und das in allen Maps in denen das Topics vorkommt. Wenn ich da an zentrale, so gut wie immer gültige Attribute wie audience oder product denke, wird mir übel. Wie soll man das denn anständig pflegen oder gar mal aktualisieren? So müsste jeder Redakteur für jedes Topic erneut prüfen, welche Gültigkeit es hat und es auch wieder in der Map hinterlegen. Und darauf hab ich eigentlich überhaupt keine Lust.

(Im Übrigen gilt das Prinzip nicht nur für Topicrefs, sondern auch für den Einsatz anderer interner Verlinkungsarten wie xref oder related-links)

Zudem ist es sehr inkonsistent, dass es hier plötzlich ein eigenes Element audience gibt, zusätzlich zum gleichnamigen Attribut. Um die Verwirrung zu komplettieren, kann man beides gleichzeitig auf einen einzelnen Topicref beziehen.

<topicref id="123" product="wundertuete2" audience="user">
<topicmeta></topicmeta></topicref>

Eine passende Diskussion auf der Yahoo-Group hab ich schon gefunden, aber eben leider noch keine Lösung. Und sowas muss ich kurz vor dem Wochenende rausfinden 🙁

Lokalisierung für Anfänger

Hach, auch ein Global Player wie Hasi und Mausi kann ins Fettnäpfchen treten. Da widme ich mich über die Feiertage dem angenehmen Online-Shopping, als mir die neue Kampagne ins Auge springt. Allerdings weniger wegen der Shirts:

Eingabe? Wieso Eingabe? Was soll ich denn da eingeben? Moment, dem erfahrenen Software-Dokumentar fällt sofort die Eingabe-Taste ein. Und wie heißt die in Englisch? Genau: Enter.

Ne, ne, liebe Leute, auch die 100%-Matches in einem TMS sollte man überprüfen 🙂

Hier die UK-Variante, die etwas mehr Sinn macht!

Realitätscheck

Der Dilbert von gestern hat mich an das erinnert, was ich einst als schmerzlichen Bruch zwischen der idealen Welt an der Hochschule und der realen Welt im Arbeitsalltag erfahren musste.

Dilbert.com

Auf der einen Seite lernt man, wie bspw. ein idealer Entwicklungsprozess aussieht, von der Konzeption über die Entwicklung bis hin zur Dokumentation. Auf der anderen Seite, also im echten Leben, ist eigentlich meistens für jeden dieser Schritte zu wenig Zeit. Und genau da fängt der Teufelskreis an, der uns arme Redakteure oft hilflos macht.

Teufelskreis – der Teufel steckt im Konzept

Wie oft hab ich mir in meinem Redakteusenleben erlebt, dass eine Softwareoberfläche viel zu kompliziert gestaltet war, was dann dazu führte, dass ich diese Kompliziertheit irgendwie einfach beschreiben sollte. Naja, und wie erklärt man dem Nutzer, dass manche Sachen einfach blöd gelaufen sind?

Ich hatte beispielsweise mal den Fall, dass ich für eine Software eine neue Funktion dokumentieren sollte, die ich abgewandelt beschreibe: Der Nutzer konnte für bestimmte Ereignisse Filterregeln definieren und entscheiden, wann dieser Filter angewandt werden sollte. Zum Beispiel: eine E-Mail soll erst nach dem Lesen in die anderen E-Mail-Ordner sortiert werden oder schon vor dem Lesen. Man musste also entscheiden, ob man einen Vor-Filter oder einen Nach-Filter definierte. Für mich wären das auch genau die richtigen Benennungen gewesen, da sie dem Benutzer genau sagen, was passiert (es wird gefiltert!) und wann (vorher! nachher!) es passiert. Aber nein, die beiden Filter bekamen 2 völlig unterschiedliche Namen, die man nie in Zusammenhang sehen würde, so etwa wie: Leseregeln und Sortieroption. Und nein, das konnte auch nicht mehr geändert werden, da das Marketingmaterial bereits im Druck war.

Und am Ende musste ich dem Nutzer erklären, dass die Sachen eigentlich dasselbe machen, bloß zu unterschiedlichen Zeitpunkten. Argh!  Wie sich das schon liest!

Die Leseregel ist praktisch gesehen dasselbe wie die Sortieroption. Sie wird nur nach dem Ereignis angewandt anstatt davor. D.h. bei der Anwendung auf E-Mails werden diese erst nach dem Lesen in die jeweiligen Ordner sortiert.

Kurz: wenn die Konfusion schon in den Anfängen steckt, kann sich das fast nur noch multiplizieren. Noch besser wäre es gewesen einfach keinen Unterschied zu machen, sondern den „Filtern“ einfach nur die Optionen „Vorher/nachher“ mitzugeben…

Und in solchen Momenten… Ja, da such ich mir manchmal auch „my special place“.


Membrane

Nachdem ich bei den Kollegen von manualBLOG allerlei Lustiges rund um Lokalisierung/Übersetzung gelesen habe, muss ich einfach mal meinen alten Schatz zeigen.

Ich habe vor Jahren einmal eine sehr, sehr, sehr billige Tastatur erworben. Nach dem Auspacken stellte ich fest, dass sie wirklich billig war und beschloss sie wieder einzupacken und umzutauschen.

Dabei stach mir dieser Text auf der Verpackung ins Auge und ich bekam ein kleines bisschen Mitleid mit diesem „Übersetzer“ 😉