Not logged in. · Lost password · Register
Page:  1  2  3  4  next 

All posts by bliddi (51)

topic: Link auf Mediamanager entfernen  in the forum: Non-English Discussion German discussion
Avatar
bliddi #1
Member since Feb 2008 · 51 posts · Location: Esslingen
Group memberships: Members
Show profile · Link to this post
Danke LMS23 - ganz einfach, wenn man es weiß ;-)
topic: Link auf Mediamanager entfernen  in the forum: Non-English Discussion German discussion
Avatar
bliddi #2
Member since Feb 2008 · 51 posts · Location: Esslingen
Group memberships: Members
Show profile · Link to this post
Subject: Link auf Mediamanager entfernen
Hallo zusammen,
im DokuWiki-Standard-Template wird rechts oben unterhalb des Suchfelds ein Link auf den MediaManager angezeigt.
Wie kann ich den am einfachsten/elegantesten entfernen?

Danke und viele Grüße
Jörg
topic: PDF Export  in the forum: Non-English Discussion German discussion
Avatar
bliddi #3
Member since Feb 2008 · 51 posts · Location: Esslingen
Group memberships: Members
Show profile · Link to this post
In reply to post ID 44840
Hallo Gamma,

hatte die Beschreibung zu Kopf-/Fußzeilen und zu Seitennummerierung auf der dw2pdf-Pluginseite irgendwie übersehen. Jetzt ist einiges klarer. Werde damit mal rumspielen. Zumindest die PDF-Ausgabe sollte damit schon weitestgehend ok sein.

Gruß Jör
topic: PDF Export  in the forum: Non-English Discussion German discussion
Avatar
bliddi #4
Member since Feb 2008 · 51 posts · Location: Esslingen
Group memberships: Members
Show profile · Link to this post
In reply to post ID 44782
Hallo gamma,

Quote by gamma on 2014-07-21, 09:39:
a) mit dw2pdf oder siteexport kann man über entsprechende Auszeichnungen im Template ...


Ok, spannend! Danke, das wusste ich bisher nicht. Bin für etwas weitergehende Infos/Beispiele sehr sehr dankbar. Ich bin kein Programmierer, tu mich also etwas schwerer mit Anpassungen "hinter der Oberfläche". Werde mir aber die Doku zu mpdf mal angucken.

Quote by gamma on 2014-07-21, 09:39:
b) Kunden umerziehen ;)

Das wäre die eleganteste Lösung. Aber als freier Redakteur ist das mühsam bzw. unmöglich. Meine Kunden und vor allem die Endkunden (oft Großunternehmen) spielen in einer Liga, in der ich nur mitarbeiten aber nicht viel mitreden darf ;-) Ich muss aber auch zugeben, dass Word-Dokumente innerhalb eines Office-orientierten Betriebs auch Vorteile in der weiteren Verwendung haben. Ich bin im Sondermaschinenbau (Produktionmaschinen) tätig, da ist alles etwas konservativer als z.B. in der SW-Branche.

Zum Thema Übersetzung:
Translation-Plugin ermöglicht mir den Zugriff auf Sprachvarianten. Kein Problem damit. Mein Problem ist die Übersetzung an sich. Agenturen verwenden Translation-Memory-Systeme, freie Übersetzer arbeiten in den entsprechenden Editoren und sämtliche Analysen u.a. zur Kostenkalkulation usw. laufen darüber ab. Für viele tausend Worte umfassende Dokus in mehreren (auch exotischeren) Sprachen und ständigen Änderungen (Versionen/Varianten) ist Plain-Text schlicht unmöglich.
 
Zur Bedienoberfläche:
Natürlich ist ein Texteditor grundsätzlich ok, Kunstwerke bauen wir auch keine in Word. Gefrikkel muss nicht sein, bei professioneller Anwendung läuft das sauber, sicher und wirtschaftlich. Auch bei mehreren hundert Seiten! Das Problem ist der deutlich erhöhte Zeitbedarf z.B. bei komplexen Beschreibungen mit viel Text-Bild-Bezug. Du siehst im kleinen Text-Editor-Fenster einfach zu wenig Inhalt, nur wenige Zeilen, keine Bildinhalte usw. Außerdem sind manche Inhalte wie z.B. normgerechte Sicherheitshinweise oder auch komplexere Tabellen im Wiki nur mühsam umsetzbar. Die WYSIWYG-Editoren und z.B. das WRAP-Plugin helfen da schon ein wenig, aber so richtig flüssig ist es halt doch nicht.

Quote by gamma on 2014-07-21, 09:39:
Die Verwendung eines Wikis stellt einen bei technischer Dokumentation grundsätzlich vor neue Herausforderungen.

Ja klar, aber ich sehe die gleichen oder ähnliche Vorteile wie Du auch. Sonst würde ich mich nicht seit langer Zeit damit beschäftigen. Nur benötigt man saubere Lösungen für individuelle Aufgabenstellungen. Im Moment sehe ich deshalb eher Lösungsansätze durch eine bidirektionale Schnittstelle zu Word.
So ließen sich Texte z.B. in Word komfortabel erfassen und dann ins DW einspielen. Durch einen geeigneten Export und Import wäre das Thema Übersetzung erledigt. Und auch die Weiterverarbeitung außerhalb DW wäre gesichert.
Tja, sowas fehlt mir echt noch zum uneingeschränkten DW-Glück.
 
Freue mich über spannende Diskussionen zum Thema und alle Tipps/Tricks

Gruß Jörg
topic: PDF Export  in the forum: Non-English Discussion German discussion
Avatar
bliddi #5
Member since Feb 2008 · 51 posts · Location: Esslingen
Group memberships: Members
Show profile · Link to this post
In reply to post ID 44253
Ich nutze genau dazu das Include-Plugin. Es gibt m.E. zwei ganz wesentliche Gründe dafür:

1. Die Option für linkonly, weil man so recht flexibel ist in der Ausgabe! Online-Angebot (mit Links) und PDF (Inhalte inkludiert) sollen ja aus einer Quelle kommen.

2. Die Anpassung der Überschriftenebenen!

Zu 2.
In der Regel ist der Titel einer Seite als H1 ausgezeichnet. Wenn aus verschiedenen Seiten ein Buch mit hierarchischer Kapitelstruktur entstehen soll, dann bilden ja die Titel die jeweiligen Überschriften. Würden die alle als H1-Auszeichnung (wie im Quelltext angegeben) bleiben, dann wäre die Hierarchie nicht mehr erkennbar. Include wandelt die Hx entsprechend der Schachtelung der includes in die korrekte Ebene.

Wird eine Seite mit H1-Titel in eine andere mit ebenfalls einem vorangestellten H1 inkludiert, dann macht Include (oder besser gesagt Michael) aus dem H1-Titel der inkludierten Seite eine korrekte H2-Überschrift.


Eine weitere m.E. interessante Möglichkeit ist der Umweg über Epub (siehe Plugin) und z.B. Calibre.
 

Vier generelle Probleme gibt es aber für mich noch in Bezug auf die Anwendung in der Technischen Doku:

a) Aus dem DokuWiki kommt kein fertiges Buch mit Kopf- und Fußzeilen mit Seitenzahlen, TOC mit Seitenzahlen usw.
b) Meine Kunden wollen meist (aus welchen Gründen auch immer) ein DOCX-File, d.h. eine in Word zu verarbeitende Datei. Ein sauberer Export nach Word ist schwieriger als man denkt.
c) Der Übersetzungs-Workflow mit Übersetzungsagenturen ist schlicht nicht vorhanden.
d) Jeder Editor im Wiki ist einer Textverarbeitung deutlich unterlegen, d.h. der zeitbedarf bei der Texterfassung steigt.

Zumindest für die ersten 3 Probleme ist für mich i.M. kein Lösungsansatz erkennbar.
Alle Ideen und Tipps zur Lösung sind willkommen.

Gruß Jörg
topic: [gelöst]Translation Plugin - klare Namespace Struktur (Struktur, jede Sprach in eigenem Namespace)  in the forum: Non-English Discussion German discussion
Avatar
bliddi #6
Member since Feb 2008 · 51 posts · Location: Esslingen
Group memberships: Members
Show profile · Link to this post
In reply to post ID 41423
Hallo dalerno,

finde ich gut, dass Du hier von der Problemlösung eine Zusammenfassung schreibst.
Großes Lob und danke

Gruß Jörg
topic: Translation of pages via Translation Memory System  in the forum: General Help and Support Features and Functionality
Avatar
bliddi #7
Member since Feb 2008 · 51 posts · Location: Esslingen
Group memberships: Members
Show profile · Link to this post
Subject: Translation of pages via Translation Memory System
Hello,
we have to translate the contents of a wiki by an agency. A Translation Memory System (SDL Trados) is used. The Trados-System has no filter for DokuWiki syntax.
I need an export and subsequent an import to and from a format such as XML for example.
Does anyone have an idea?

Thanks a lot and best regards
Jörg
topic: Terminologieverwaltung in DW  in the forum: Non-English Discussion German discussion
Avatar
bliddi #8
Member since Feb 2008 · 51 posts · Location: Esslingen
Group memberships: Members
Show profile · Link to this post
In reply to post ID 39238
Hallo Flam,

dank Dir für Deine Antwort.

Ich möchte tatsächlich "einfach" Benennungen (i.d.R. einzelne Wörter!) zu Begriffen (Denkeinheiten) erfassen, diese mit ein paar Attributen und etwas Klartext (Definition) beschreiben und denen einen Status geben (z.B. erlaubt/nicht erlaubt). Zu jeder Benennung in der Originalsprache (Deutsch) gibt es dann erlaubte/nicht erlaubte Übersetzungen in den jeweiligen Sprachen.
Die Benennung, deren Definition, die Metadaten und die Übersetzungen bilden einen "Datensatz", im Wiki im Idealfall vielleicht eine Wikiseite. Zum Beispiel siehe http://de.wiktionary.org/wiki/Bank. Fast genau so.

Aber: Dort stecken im Datensatz "Bank" leider verschiedene Bänke, im konkreten Beispiel 5 Stück (siehe Abschnitt Bedeutungen). Daten zu diesen werden nun durch Indizes [1]...[5] beschrieben.

Datentechnisch sauberer wäre es, wenn man 5 Datensätze/Wikiseiten hätte und zu jedem definierte Attribute und die entsprechenden Übersetzungen erfassen könnte.

Zur Semantik: Es gibt natürlich Begriffssysteme, d.h. Begriffe die zueinander in Beziehung stehen. Die kann man auch abbilden. Dazu gibt es spez. Datenbanken (z.B. http://www.iterm.dk) die solche Begriffssysteme in Ontologien abbilden und viel viel mehr können, als ich jemals benötige.

Mir geht es i.W. darum, dass sich das Wiki zu einer Plattform für die Diskussions- und Abstimmprozesse entwickeln kann und gleichzeitig die Terminologiesammlung dort einigermaßen sauber verwaltet werden kann.

Beim Data-Plugin habe ich i.M. noch das Problem, dass jeder Eintrag eine eindeutige ID bekommen muss. Das ist natürlich nicht die Benennung, denn die ist ja nicht eindeutig (Bank/Bank = 2 Einträge, die gleich heißen). Wie bilde ich diese ID? Außerdem: wenn sich 2 Benennungen auf ein und denselben Begriff beziehen (z.B. Antrieb/Motor), dann besteht zwischen diesen eine Beziehung (Synonym). Diese im Data-Plugin abzubilden ist vielleicht nicht so einfach (nicht technisch, sondern vom Handling her).

Vielleicht können die Data-Spezialisten noch Tipps geben oder es gibt eine ganz andere Lösung.
 
Viele Grüße

Jörg
topic: Terminologieverwaltung in DW  in the forum: Non-English Discussion German discussion
Avatar
bliddi #9
Member since Feb 2008 · 51 posts · Location: Esslingen
Group memberships: Members
Show profile · Link to this post
Subject: Terminologieverwaltung in DW
Hallo zusammen,

mal eine Frage in die Runde: Hat sich schon jemand mit einer Terminologieverwaltung in DW beschäftigt?

Siehe dazu auch das bekannte "Wiktionary", das aber datentechnisch nicht ganz so ideal aufgebaut ist (Stichwort "benennungsorientiert" statt "begriffsorientiert").

Es geht mir um die strukturierte Erfassung und Beschreibung von Benennungen sowie deren Übersetzungen in verschiedene Landessprachen. Ich dachte zunächst daran, jeder Benennung eine Seite im Wiki zu spendieren. Problem: Benennungen werden durchaus auf verschiedenste Begriffe angewendet, was dann zu ganz unterschiedlichen Beschreibungen und Übersetzungen führt.

Beispiel:
Bank (Geldinstitut) --> bank
Bank (Sitzgelegenheit) --> bench

Natürlich kann man das nun alles in einer Seite "Bank" unterbringen, im Freistiel beschreiben und einen alphabetisch sortierten Index bilden und damit leben. Aber das ist datentechnisch (Stichwort Datenbank-Normalisierung) und auch in Bezug auf die Pflege und Suche/Verlinkung nicht so wirklich gut. Beide "Bänke" oben sind Benennungen. Ideal wäre es, wenn jede Benennung autonom abgelegt wird und man die Verwendung und Übersetzung unabhängig definieren kann.
 
Hintergrund zur Anwendung: Die Suche und Abstimmng einheitlicher Benennungen z.B. für Komponenten eines Produkt ist eine Teamaufgabe, die durchaus Diskussionen verursacht. Natürlich gibt es spezielle Terminologiedatenbanken, aber meines Erachtens passt die Aufgabe hervorragend zum kollaborativen Charakter eines Wikis. Allerdings fehlt es mir i.M. an der technologischen Umsetzung. Das DATA-Plugin könnte ein Ansatz sein, evtl. auch Bureaucracy für das Formular zum Erfassen/Editieren.

Freue mich über alle Hinweise, Tipps, Ideen.

Viele Grüße und vielen Dank

Jörg
topic: epub and include  in the forum: General Help and Support Plugins
Avatar
bliddi #10
Member since Feb 2008 · 51 posts · Location: Esslingen
Group memberships: Members
Show profile · Link to this post
In reply to post ID 37013
Hello Myron and Michael,

Quote by turnermm:
The epub plugin has only limited support for the include plugin.

Having to use the full namespace path doesn't seem like much of a problem if you know you are going to be adding the include to an ebook.


first of all I would like to thank you for your plugins and the lively
debate regarding my questions.

If one knows that the entire paths must be indicated in {{page>...}}, then
it is relatively simple to do.

I use the include function to define documents (books!).
A chapter consists of several included pages; a book consists of several
included chapters.

Individual pages are used repeatedly in books, also with different context.
In the individual pages the page titles are defined as H1 (======).
Via include I achieve a correct hierarchy of the headings.

Alle files are stored in a namespace, e.g. "product1".
I have written the links already as relative instructions
({{page>.:ns:wikipage1}}), due to the fact that I use parts of it (above all
the higher-ranking chapter pages with the include commands) also as a copy in
other namespace, e.g. "product2". With complete pathnames I would have to adapt them always.

Important: I use this system independent of epub, however would like to
establish now also an e-book since the nice plugin is already available for
it.

Maybe you will find a solution and you can implement it eventually.
Otherwise I must indicate the complete paths.


Explanation for the hierarchical adaptation of the titles and headings:

Two pages ...
====== Title of page1 ======
Content of page1 ...

====== Title of page2 ======
Content of page2 ...

... and a higher-ranking chapter with includes ...
====== Heading of the chapter ======

===== Heading of a subchapter =====

BlBlaBlaBla

{{page>page1}}


{{page>page2}}

===== Another subchapter =====

The result in dokuwiki with Include-plugin:

====== Heading of the chapter ======

===== Subchapter =====

BlBlaBlaBla

==== Title of page1 ====
Content of page1 ...

==== Title of page2 ====
Content of page2 ...

===== Another subchapter =====

Thanks Jörg
topic: epub and include  in the forum: General Help and Support Plugins
Avatar
bliddi #11
Member since Feb 2008 · 51 posts · Location: Esslingen
Group memberships: Members
Show profile · Link to this post
Subject: epub and include
Hi,

the epub-Plugin performs the include-function
{{page>...}}
.

I must always write the whole path, so that the pages are included.
Example: All douments in namespace  :document:test.

This does not work with the E-Book output. In normal wiki output it's ok.
{{page>subpage1}}
{{page>subpage2}}

With an absolute path-declaration the pages are included in the E-Book:
{{page>:document:test:subpage1}}
{{page>:document:test:subpage2}}

Next problem: The include-plugin adapt the hierarchy of the headings. Include a page with an heading 1 in an other page with heading 1 above. The included heading is adapted to heading 2. In the epub the included heading is still heading 1.

Thanks a lot for all tipps and solutions

Jörg
topic: Versionen verwalten  in the forum: Non-English Discussion German discussion
Avatar
bliddi #12
Member since Feb 2008 · 51 posts · Location: Esslingen
Group memberships: Members
Show profile · Link to this post
In reply to post ID 36939
Hallo Lothar,



Quote by LGeyer:
An den "alten" Texten ändert sich in der Regel immer etwas -

Wie fast immer- ich kenn das. Technische Doku kann richtig fies sein,  wenn man es richtig machen wil.

Ich arbeite so:
  • Die Doku besteht aus einzelnen Modulen, jedes als Wikiseite umgesetzt.
  • Jedes Modul ist in sich geschlossen, kann also unabhängig von anderen verwendet werden.
  • Dokumente entstehen aus Inludes
  • Jede Seite hat eine ID gemäß einem sprechenden Schlüssel und einen Seitentitel (H1)
  • Die einzelnen Seiten der Dokumodule lagen bisher noch in einem (1) Namensraum, aber ich stelle gerade um auf eine Ablage in mehreren Namensräumen. Die Erfassung geschieht ansatzweise über Bureaucracy-Formulare.

Wenn sich "alte" Inhalte aufgrund einer neuen Version ändern, dann ordne ich sie der neuen Version zu. Ist es eine Änderung eher im Sinne einer Korrektur/Ergänzung, die keinen Bezug zur neuen SW-Version hat, dann ändere ich das alte Modul. Dann ist ja eine Rückverfolgbarkeit über eine Seiten-ID nicht so entscheidend. Über die History in DW hat man aber den Zugriff auf die älteren Versionen. Problematisch wird es dann, wenn in einer Doku der "ganz alte" und der überarbeitete Stand verfügbar bleiben müssen. Aber das ist dann ja kein Versions- sondern Variantenmanagement.

Dann sind wir schnell beim Zusammenstellen der Dokumentation für eine Version/Variante. Das gefällt mir hier bei mir noch nicht so. Dabei muss ich sagen, dass ich auch eine Druckausgabe des gesamten Dokuments benötige, d.h. eine linearisierte Version mit definierter Abfolge der einzelnen Inhalte. Ich experimentiere da noch u.a. mit "epub" (siehe Pluginbeschreibung) und mit Richards externer Lösung rum (siehe https://forum.dokuwiki.org/post/35616 und auch mit XML-Export.

Quote by LGeyer:
Abgesehen davon: beim Kopieren des Namensraums müssten alle internen Links angepasst werden - und dafür gibt es meines Wissens kein funktionierendes Plugin. Oder bin ich da flasch?

Alles steht und fällt mit einer sauberen Struktur der Datenablage. Du hast doch eine Einstiegsseite in die Doku, von der Du als Leser in die Tiefe vordringst. Leg die doch gleich in den versionsspezifischen Namensraum und versehe die Links auf und zwischen die einzelnen Seiten nicht mit einer absoluten sondern relativen Adresse.

Absolut:
[[:softwaredoku:typa:version1:startseite]]
Auf der Startseite:
  * [[:softwaredoku:typa:version1:funktion-abc:beschreibung]]
  * [[:softwaredoku:typa:version1:maske-xyz:datenerfassung]]
  * ...

Relativ:
[[:softwaredoku:typa:version1:startseite]]
Auf der Startseite:
  * [[.:funktion-abc:beschreibung]]
  * [[.:maske-xyz:datenerfassung]]
  * ...

So ändert sich nur der Verweis zur Startseite, wenn Du die gesamte Version, d.h. den Namensraum //:softwaredoku:typa:version?) kopierst.

[[:softwaredoku:typa:version2:startseite]]
Auf der Startseite kann alles wie in Version 1 bleiben:
  * [[.:funktion-abc:beschreibung]]
  * [[.:maske-xyz:datenerfassung]]
  * ...

Wie beim guten alten DOS. 1 Punkt verweist auf das Verzeichnis/den Namensraum, in dem Du gerade bist, 2 Pnkte auf den darüber.

Achte auf eine saubere und gut durchdachte Media-Ablage, wenn Du viele Bilder einsetzt.

Fragen an Dich:
  • Wie publizierst Du Deine Doku, lieferst Du eine druckfähige Ausgabe? Wenn ja, wie?
  • Übersetzt ihr euere Doku in andere Lamdessprachen? Wenn ja, kannst Du mir bitte kurz den Workflow beschreiben.

Danke und viele Grüße

Jörg
topic: Dokuwiki für Kundendokumentationen  in the forum: Non-English Discussion German discussion
Avatar
bliddi #13
Member since Feb 2008 · 51 posts · Location: Esslingen
Group memberships: Members
Show profile · Link to this post
In reply to post ID 36758
Hallo Michael,

vielen Dank für Dein Interesse an der Aufgabenstellung.
 
Quote by Michitux on 2013-01-26, 10:16:
Was genau sollte denn so eine flexible formularbasierte Dokumentation können?

Ich bin die nächsten Tage unterwegs und habe leider keine Zeit, meine Visionen in konkrete Vorschläge zu formulieren. Ich hoffe Dir wird es nicht langweilig ;-) Ich melde mich hier mit entsprechenden Infos im Laufe der nächsten Woche. Vielleicht kommen hier ein paar Vorschläge und Lösungsansätze zusammen.
topic: Dokuwiki für Kundendokumentationen  in the forum: Non-English Discussion German discussion
Avatar
bliddi #14
Member since Feb 2008 · 51 posts · Location: Esslingen
Group memberships: Members
Show profile · Link to this post
In reply to post ID 36429
Hallo Matthias,

Quote by mpeter on 2013-01-09, 13:49:
... schneide ich mir dann aber nicht alle freien Eingaben ab, wenn also z.B. eine Info hinterlegt werden muss, die kunden- oder gerätespezifisch ist und damit nicht im Template vorgesehen wurde?

Vor genau diesem Problem stehe ich auch und habe noch keinen guten Lösungsansatz. Ich träume immer noch von der flexiblen formularbasierten Dokumentation. Ich fürchte, das bleibt noch eine ganze Weile ein Traum  ;-).
Vielleicht kommt ja mal hier im Forum ein Lösungsansatz.

Flam: Vielen Dank für Deine Erläuterungen vom 09.01.2013.

Viele Grüße
Jörg
topic: Data-Plugin und XAMPP 1.8.1  in the forum: Non-English Discussion German discussion
Avatar
bliddi #15
Member since Feb 2008 · 51 posts · Location: Esslingen
Group memberships: Members
Show profile · Link to this post
In reply to post ID 36652
Subject: Erledigt! Data-Plugin und XAMPP 1.8.1
Hallo Michael,

Quote by Michitux on 2013-01-21, 14:14:
... Ich denke, die einfachste Lösung dürfte sein, eine ältere XAMPP-Version zu verwenden

Dank Dir, so habe ich es gemacht. Mit 1.7.7 funktioniert es gut.

Viele Grüße Jörg
Close Smaller – Larger + Reply to this post:
Special characters:
Page:  1  2  3  4  next 
Special queries
Go to forum
Imprint
This board is powered by the Unclassified NewsBoard software, 20150713-dev, © 2003-2015 by Yves Goergen
Current time: 2019-12-14, 08:19:26 (UTC +01:00)