staging.inyokaproject.org

Noch nicht so komplett ohne Transitional-Mörtel | (Google Translated), aber meiner Meinung nach schon sehr schön wiederverwendbar.

Das mag jetzt Off-Topic klingen, aber ich versuche "immer" so nah wie möglich am "Use Case Objekt" wie jetzt gerade diesem Wiki-Ausschnitt hier zu arbeiten. Deshalb meine Frage: Gibt es eine DTD für das Uu-de Wiki mit deren Hilfe ein Eingabezwang zur "Qualitätssicherung" umgesetzt werden könnte? Also als Use Case heißt das, das ich diese derzeit "fiktive" DTD für das Uu-de Wiki mir herunterlade, in einen beliebigen XML-Editor hinterlege, mit diesem XML-Editor "o.ä. befähigt" den Uu-de-Wikibeitrag schreibe und dann irgendwie in das Uu-de Wiki "git-commit-e"?

Was hat das mit snap zu tun?

Gruß, noisefloor

noisefloor schrieb:

Was hat das mit snap zu tun?

Skusi ba mucho, ich verstehe nicht, was du in meinem Posting nicht verstehst. Da ich mich auch verantwortlich fühle, wenn jemand etwas nicht versteht wie ich es "gerne verstanden hätte", bin ich jetzt gerade etwas ratlos was ich dazu antworten soll. Oder geht es hier dir jetzt lediglich darum Rechtfertigungszwang gegenüber mir etwas von dir nicht im Detail Unverständlichen "aufzubauen" und mein Anliegen näher darzulegen? Würde ich gerne machen. Dazu brauche ich aber als "Vorlage" auch passende Fragen von dir dazu. Soweit dir jetzt wirklich an einer "Klärung des Sachverhaltes" liegen sollte. Ohje, Jura-Doiche. Bitte vielmals um Verzeihung 😉

Oder anders: Mir ist jetzt deine Kommunikationsabsicht mit der Frage "Was hat das mit snap zu tun?" komplett unklar.

Danke für Aufklärung.

Grüße, wren

Hallo,

wie sollte der Eingabezwang denn aussehen? Bzw. wie würdest du ihn gestalten wollte, dass er a) ein fixes Schema hat und b) auf alle aktuell 6774 Artikel gepasst hätte, wenn der Eingabezwang zum Zeitpunkt derer Erstellung schon existiert hätte?

Ansonsten ist die Idee zwecks Qualitätssicherung natürlich brillant - XML als strukturiertes Datenformat, was sicherlich bei einer Vielzahl der Nutzer äußerst hochgradig beliebt ist kombiniert mit dem wahrscheinlich populärsten VCS der Welt, was ja auch quasi jeder nutzt. Ein Win-Win-Win Situation.

Hast du schon mal drüber nachgedacht, dich beim Webteam zu bewerben, um das ganze für Inyoka zu Implementieren? Nach Jahren der nur kleinen Fortschritte wäre das endlich mal wieder ein epischer Schritt vorwärts.

Gruß, noisefloor

noisefloor schrieb:

Ansonsten ist die Idee zwecks Qualitätssicherung natürlich brillant - XML als strukturiertes Datenformat, was sicherlich bei einer Vielzahl der Nutzer äußerst hochgradig beliebt ist kombiniert mit dem wahrscheinlich populärsten VCS der Welt, was ja auch quasi jeder nutzt. Ein Win-Win-Win Situation.

Von brilliant habe ich nirgendwo etwas geschrieben bzw. behauptet das es so sein könnte. Der o.a. Satz von dir erscheint mir zwar etwas ungleichmäßig ausbalanciert, gar sarkastisch durchmischt; wahrscheinlich eine eklatante Fehlwahrnehmung von mir für den Moment, aber so im Großen und Ganzen schwimmt dit Ding aber ganz gut im nächtlichen Wellengang, also meiner frei diskutierbaren Meinung nach, soweit ich das im dunstigen Mondlicht vom Strand aus sehen kann.

Ja, pfff, "Mädyen-Kompetenz, ahoj" tät ich mal so rapide spontan antworten, dann klappts auch ... oft, ... aber selten nicht auch nicht immer 😉

noisefloor schrieb:

Hast du schon mal drüber nachgedacht, dich beim Webteam zu bewerben, um das ganze für Inyoka zu Implementieren? Nach Jahren der nur kleinen Fortschritte wäre das endlich mal wieder ein epischer Schritt vorwärts.

Würde gerne erst mal wieder die ganzen Dita-Sachen aktualisieren wollen. Müßte mich auch noch weiterbilden wegen XML versus JSON Daten-Langzeitarchivierung bzw. wie die OASIS das Ganze "empfehlend" einschätzt.

Von einer eventuell möglichen Implementierung her, vielleicht in der Art eines RTE? Z.B. LibreOffice im Browser?

Die nächste Version der freien Office-Suite LibreOffice läuft dank des vom W3C definierten offenen Standards WebAssembly (WASM) bereits jetzt experimentell direkt im Browser. Standardmäßig mit Chrome, Firefox, Edge und Safari ausgeliefert, soll WebAssembly die Browserversion zum festen Bestandteil von LibreOffice machen. LibreOffice lokal im Browser nutzen

Die Entwickler der The Document Foundation planen bereits seit längerem, die freie Office-Suite um eine Browserversion zu erweitern. Eine erste experimentelle Version dieses Ablegers wurde jetzt in Zusammenarbeit mit den Softwareentwicklern der Allotropia Software GmbH mit Sitz in Hamburg veröffentlicht.

LibreOffice im Browser soll in der finalen Version über folgende Eckdaten verfügen:

• Basierend auf WebAssembly (WASM)

• Umgesetzt mit dem Emscripten-Toolchain von LLVM

• C und C++ in JavaScript und WebAssembly übersetzt

• LibreOffice 7.4 inklusive GUI direkt im Browser

• WebAssembly System Interface (WASI)

• Backend auf Basis von Qt

Die noch sehr experimentelle Testversion, die bereits für jedermann verfügbar ist und im Firefox, den diversen Chromium-Browsern und Browsern auf Basis von Apples Webkit lauffähig ist, basiert schon auf dem Code der nächsten Hauptversion LibreOffice 7.4, die noch im Laufe des Jahres vorgestellt werden soll und als erster möglicher Kandidat für eine Browserversion gehandelt wird.

Alternative zu LibreOffice Online

Anders als LibreOffice Online und dem darauf aufbauenden Collabora Online, das sich primär an Unternehmen und Cloud-Provider richtet, wird die Browserversion von LibreOffice lokal ausgeführt und bietet daher konzeptionell mehr Datenschutz und Privatsphäre.

Die WebAssembly-Portierung lädt beim ersten Start rund 300 MB des Anwendungscodes und benötigt daher eine gewisse Zeit, bis sie einsatzbereit ist.

wren schrieb:

[…] Das mag jetzt Off-Topic klingen

Das war es.

[…] Gibt es eine DTD für das Uu-de Wiki […]?

Nein, so etwas gibt es nicht.

Dagegen gibt es:

1. Eine für Kenner der deutschen Sprache leicht verständliche Anleitung, wie man im Wiki arbeitet: Wiki/Benutzung

2. Eine Spezifikation, wie Wiki Artikel aufgebaut und inhaltlich gestaltet werden: Wiki/Referenz

3. Einen speziellen Editor, welcher die Erstellung/Änderung eines Wiki-Artikels offline ermöglicht: InyokaEdit

Wenn Du eine Dokumenttypdefinition für das UbuntuUsers-de-Wiki erstellen möchtest, achte bitte darauf, dass diese auch mit frei (im Sinne von Freiheit und von Freibier) verfügbaren Werkzeugen benutzbar ist.

Hallo,

wren schrieb:

Von brilliant habe ich nirgendwo etwas geschrieben bzw. behauptet das es so sein könnte.

Sag ja auch keiner. "Brilliant" habe ich geschrieben. Wenn du etwas vorschlägst und jemand anders das toll findet, dann musst du halt auch damit klar kommen...

Wenn Du eine Dokumenttypdefinition für das UbuntuUsers-de-Wiki erstellen möchtest, achte bitte darauf, ...

Und achte darauf, dass die direkt auch einen Parser schreibst, der aus dem uu.de XML einen Wikiartikeln rendern kann. Das XML alleine nützt ja (noch) nichts.

Gruß, noisefloor

noisefloor schrieb:

wren schrieb:

Von brilliant habe ich nirgendwo etwas geschrieben bzw. behauptet das es so sein könnte.

Sag ja auch keiner. "Brilliant" habe ich geschrieben. Wenn du etwas vorschlägst und jemand anders das toll findet, dann musst du halt auch damit klar kommen...

Yoh. Ich mach mal ein Ticket für den "Sarkasmus-Parser" auf. Das geht "besser" 😉

Wenn Du eine Dokumenttypdefinition für das UbuntuUsers-de-Wiki erstellen möchtest, achte bitte darauf, ...

Und achte darauf, dass die direkt auch einen Parser schreibst, der aus dem uu.de XML einen Wikiartikeln rendern kann. Das XML alleine nützt ja (noch) nichts.

Gemach, gemach, das ist mir schon klar, das dazu natürlich auch eine SSP-Umgebung gehört. Ob sich das DITA Open Toolkit für Uu-de "umbiegen" läßt, das ist jetzt natürlich die Frage. Das Original scheint entweder schon perfekt zu laufen oder als Projekt eingeschlafen zu sein.

Ich recherchiere da die ganzen Links gerade durch. Insbesondere wo der Tech Support hingewandert ist. Die Yahoo Groups sind ja leider abgeschalten worden.

Es gibt einiges zu recherchieren und auf "Lebendigkeit" zu überprüfen bei diesem Thema. S.a. dazu von der Idee her den Hype-Zyklus. Ich fange da erst mal bei den kostenpflichtigen State-of-the-Art Help Authoring Tools (HAT) z.B. den Oxygen XML Editoren an und versuche Hinweise auf FOSS herauszufinden. Es wird dauern sich da eine Meinung dazu zu bilden, also Hype und Praktikabilität (nachgewiesene Best-of-Practice) zu trennen und dann irgendwo hoffentlich am passenden "Software-Platz" bzw. wohl eher "Software-Stückwerk-Kombination" zu landen.

kB schrieb:

Wenn Du eine Dokumenttypdefinition für das UbuntuUsers-de-Wiki erstellen möchtest, achte bitte darauf, dass diese auch mit frei (im Sinne von Freiheit und von Freibier) verfügbaren Werkzeugen benutzbar ist.

Danke für deine Hinweise. Okay, nur um den Verdacht auszuräumen: Ich bin weder beruflich noch in der Freizeit im "Product Placement Bizz" tätig, "... aber man tut was man kann. ..."

noisefloor schrieb:

wie sollte der Eingabezwang denn aussehen? Bzw. wie würdest du ihn gestalten wollte, dass er a) ein fixes Schema hat und b) auf alle aktuell 6774 Artikel gepasst hätte, wenn der Eingabezwang zum Zeitpunkt derer Erstellung schon existiert hätte?

Von der Verwaltung einer möglichen QS-Initative zum Thema Transitionaler Uu-de Text, in welchem "prominenten Help-Authoring-Tool-Format" (HAT) das dann auch sein möge: Transitional, also 1:1 wiederverwendbare & wartbare "Dokumentationsschnipsel" (Dita-like?) ohne "blindwütige Kopieren & Einfügen Matschepampe", also wiederum qualitätsgesichert, zertifiziert, vorgeprägter Text mit Sphinx, das wäre natürlich der Knüller. In der (Open)BSD Community ist es angeblich Best Practice fehlende Dokumentation als Bug (also Bug-Tracker-Ticket) zu behandeln, was von der Sicherheit gesehen natürlich Sinn macht. Was nicht dokumentiert ist, das ist nun mal ein Angriffsvektor.

Ohne Wiederwenden wird es meiner Meinung nach nicht gehen bzw. umsetzbar sein. Auch wenn es vielleicht ein stark beeinflußtes Industrie-Konsortium ist, aber das werden die OASIS-Leutkens schon ausführlich kreuz-&-quer durchevaluiert haben. S.a. OpenDocument o.a. Maschinenbaurichtlinie o.a. S1000D. Aber ja klar, es ist eine Entscheidung für ein Dokumentationskonzept was ein Investment an Ressourcen & Pooling benötigt. Und ich will hier im Uu-de auch nicht die "Temporäre Deutungshoheit clinchen", weil das schlicht und einfach kreativen Stillstand bedeuten würde den ich aber sehr wichtig finde.

Hallo,

schön, dass du eine Masterplan hast. Wann ist die Umsetzung fertig? Wie ist die Timeline, wann gibt's eine Alpha-Version, wann das Beta?

Gruß, noisefloor

noisefloor schrieb:

schön, dass du eine Masterplan hast. Wann ist die Umsetzung fertig? Wie ist die Timeline, wann gibt's eine Alpha-Version, wann das Beta?

wenn es fertig ist

Grüße, wren