meikel

Nein.

Mister Ad

Chriz

AGB-Server heißt das Ding hier schon seit Urzeiten, ist natürlich nur ne PHP-Anwendung ..

Und wie setzt du die Versionierung um? Da hast du scheinbar noch kein wirkliches Konzept entwickelt, die Versionierung wird aber am schwierigsten.

Meiner Meinung nach reicht das auch aus. Der Fall, dass eine alte AGB herausgekramt werden muss wird zwar sicherlich irgendwann vorkommen, rechtfertigt aber sicherlich keine größere Entwicklung im Backend.

Es gibt ja verschiedene Paragraphen (Punkt 1, Punkt 1.2, Punkt 1.2.10, ..). Man könnte sagen, dass die Tiefe wirklich gering ist, und keine aufwändige Baumstruktur rechtfertigt (stattdessen eine flache Struktur mit "depth"-Feld zum Einrücken), aber bei uns kamen gleich von Anfang an neben AGBs, Impressum, Datenschutz auch noch Spielregeln dazu und wer weiß was später noch für Dokumente dazukommen, die dann vielleicht wirklich eine richtige Baumstruktur benötigen.

Das musst du mit deinem Vorgesetzten ausmachen. "Vorerst" klingt ja schon verdächtig, aber der Mehraufwand für die Lokalisierung ist schon nicht gering und das müsste dann wohl der Auftraggeber schon erfahren. Ggf. kannst du es andenken und die Struktur schon darauf vorbereiten.

Der Anwender kennt üblicherweise keine Zeichensätze und es interessiert ihn auch nicht. Außerdem kannst du gar nicht feststellen, ob ein Textdokument UTF-8 ist. Du kannst höchstens feststellen, ob es sich nicht um UTF-8 handelt (anhand ungültiger Bitkombinationen). Du musst eben schon sicherstellen, dass der Editor, mit dem das Textdokument erstellt wurde, die Datei in UTF-8 abspeichert. Dafür brauchst du dann aber professionelle Übersetzungssoftware, Excel scheisst dich da an wo es nur geht (nicht nur bei Zeichensatzzeug übrigens, aus Punkt "1.2." wird dann der erste Februar und so Spässe).

Sehr problematisch, da die Formatangaben bei Änderungen oder Übersetzungen ja beibehalten werden müssen. Du musst also ein System wählen, das auch für Dummies verständlich ist. BBCode wäre möglich, wir haben uns dazu entschlossen das sprachunabhänige Textelement mit einem Flag (allow_html) zu erweitern. Ist meiner Meinung nach nicht optimal, da dann auch wirklich sichergestellt sein muss, dass der restliche Text frei von gefährlichen Zeichen ist, aber das war die bequemste Lösung.

Ich weiß halt überhaupt nicht, wie groß eure Firma ist und ob so ein Aufwand bei euch lohnt. Evtl. reicht es ja, wenn ein Mann die AGB ins HTML presst und dann rausspeichert.

Und wichtig: Mach dir klar wer das Tool später benutzen soll, ob du oder die Rechtsabteilung - entsprechend musst du die Oberfläche und Prozesse anpassen.

__________________
"Nuschel ich?" - "Was?"

hausl

Ok schade, dann wirds wohl bei der von nikosch beschriebenen Variante (#19) bleiben (müssen).

LG

__________________
Keine Zahl != ein Zeichen das keine Zahl ist

meikel

Der Kunde muß die AGB ohne Zusatztools einsehen können. Wird das nicht beachtet, hat der Kunde das Recht, vom Kauf zurückzutreten. Jut, hat er ja eh aufgrund des Fernabsatzgesetzes, aber der Anbieter tut sich keinen Gefallen, wenn der Kunde deshalb vom Kauf zurücktritt, weil er sich zum Lesen des Kleingedruckten erst noch ne Software besorgen und installieren muß.

Auch wichtig, falls AGB als HTML und PDF angeboten werden: es darf keine Unterschiede geben.

Wer auf Nummer sicher gehen will, der bietet die AGB als HTML in einem neuen TAB so an, daß es ausgedruckt werden kann und trotzdem noch gut aussieht.

php.de

Da gibt es - wenn ich mich richtig erinnere - bei AGBs eindeutige Gesetze, die beschreiben, welche Texte speziell hervorgehoben werden müssen.
Das ist mein Hauptproblem. Liese sich ganz leicht lösen, indem man eine XML-Datei hochlädt, woraus dann automatisch HTML-Code und eine PDF generiert wird. Nur gibt es bei dieser Variante die Unschönheit, dass diese XML-Datei "programmiert" werden muss. Es müssen also korrekt Tags gesetzt werden. XML-Tags für die XML-Kodierung und schließlich noch Tags für u. a. Fettschrift, ....
Und natürlich ist es unumgänglich, dass nach der Erzeugung des HTML-Textes und der PDF-Datei beide Sachen nochmals von einem Juristen kontrolliert wird. D. h.:

1) Der Jurist verfasst den Text.
2) Der Programmierer schreibt es in XML-Text um und lädt die Datei hoch.
3) Der Jurist überprüft HTML-Text UND die PDF-Datei.

Das mache ich vorerst übrigens nur für mich alleine privat.

drsoong

Wie sieht's denn aus mit einem PDFtoHTML-Converter.

Der spröde Rechtsanwalt wird ja sicherlich nicht mit irgend einem "Fancy-Formatting" daher kommen, oder?!

Also, dann bastelt der RA die PDF-Datei mit seinen rechtlich vorgeschriebenen drucktechnischen Hervorhebungen zusammen. Evtl. kannst Du ihn sogar dazu abrichten,
den Convert-Now Button im Konvertierer zu drücken und schwups ist beides fertig.

__________________
Es ist schon alles gesagt. Nur noch nicht von allen.

nikosch

Erstens heißt es (die) AGB_ und zweitens würde mich so eine Vorschrift mal interessieren. Wobei ich zu bezweiflen wage, dass rechtsverbindliche Texte nur unter bestimmten Formatierungen gültig sind (objektive Lesbarkeit mal außen vor).
Das gilt aber gleichermaßen für HTML. Denn das HTML was ein Office ausspuckt ist mitnichten einfaches Standard-HTML, sondern mit jede Menge kryptischem Style-Foo unterfüttert. Zum zweiten impliziert die XML-Idee, dass der Algorithmus zur Generierung fehlerfrei ist. Was gerade bei PDF-Generierung mehrseitiger Dokumente auch fragwürdig ist.

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

php.de

Meines Wissens nach müssen bei AGBs die Punkte "Gewährleistung" und "Widerrufsrecht nach Bestimmungen des Fernabsatzrechts" speziell hervorgehoben werden. Weiter will ich aber nicht darauf eingehen. Das ist OffTopic. Zudem bin ich kein Jurist, um hier ins Detail gehen zu können.

drsoong

Ist aber de facto so. Widerrufsbelehrungen z. B. müssen drucktechnisch, also fett mit deutlich Platz drumherum, hervorgehoben werden, ansonsten muss sich der Verwender (der AGB) im Ernstfall entgegenhalten lassen, dass eine Belehrung nicht erfolgt ist - da nicht erkennbar genug -und eine Widerufsfrist demnach nicht zu laufen begonnen hat, weswegen der Kunde dann auch noch Wochen später widerrufen kann, weil er (angeblich) erst dann auf die Widerrufsmöglichkeit aufmerksam geworden ist und die Frist erst ab Kenntnisnahme zu laufen beginnt. Im Verbraucherbereich ist das AGB-Gesetz und entsprechende Rechtsprechung teilweise schon sehr anspruchsvoll für den Verwender.

__________________
Es ist schon alles gesagt. Nur noch nicht von allen.