-----------
Ich habe auch dieses Problem gehabt. Die Lösung war relativ einfach.
Ich habe die Datei setup/inc/osticket-v1.6.sql in einem guten Texteditor aufgemacht (Notepad++, kostenlos). Dort habe ich dann die Kodierung auf "UTF-8 ohne BOM" gestellt. Sie war vorher auf ANSI.
Danach waren sämtliche Umlaute unleserlich. Ich habe sie alle mit dem richtigen Umlaut übertippt. Danach habe ich diese Datei mit der neuen "UTF-8 ohne BOM"-Kodierung gespeichert und auf den Server geladen.
Danach musste die Installation nocheinmal durchgeführt werden. Dazu die Datei include/ost-config.php mit der ursprünglichen Datei aus dem Installations-Ordner überschreiben und dann das Installations-Skript im Browser aufrufen wie bei der Erst-Installation.
Achtung, alle Konfigurationsdaten werden dabei gelöscht.
Aber so hat alles geklappt und die Texte sind nicht mehr abgeschnitten.
Im Anhang die von mir so bearbeitete Datei osticket-v1.6.sql (gezippt)
NB. Anscheinend ist die gefunden Lösung generell auch auf andere beobachtete Umlautprobleme anwendbar.
Ich habe im Moment die Dateien install.php und setup.inc.php ebenfalls in UTF-8 ohne BOM"-Kodierung umgewandelt, und in den Dateien sämtliche "&xuml;"-Definitionen mit den jeweiligen Umlauten ä,ö,ü usw ersetzt.
Auch somit werden die Installations Logs und ersten Tickets korrekt angezeigt.
Die in "UTF-8 ohne BOM"-Kodierung umgewandelten Dateien hänge ich ebenfalls an. (das .txt einfach dann entfernen)
Ohne hier jemanden zu Nahe treten zu wollen (Hochachtung vor der getanen Arbeit), aber leider ist die Qualität der 'deutschen' Bearbeitung bzw. die Übersetzung alles andere als Besonders.
Abgesehen davon dass beinahe alle Dateien in der falschen Codierung (ANSI) anstatt UTF-8 (ohne BOM natürlich!) gespeichert wurden, hackt es zudem beinahe bei allen übersetzen Texten.
Die hier angesprochenen Probleme sind dann eine logische Folge der falschen Dateicodierung.
Da aktuell osTicket noch ein generelles Problem mit der Mehrsprachigkeit (sprich kann es einfach - noch - nicht) hat, sind die Texte ein sehr vielen Dateien 'hard-codiert'.
Das betrifft beinahe alle php-Dateien da Übersetzungen fast überall notwendig sind.
Daher müssen schlußendlich auch alle Dateien als UTF-8 - ohne BOM - gespeichert werden!
Ein weiterer grober Fehler der aktuellen 1.6 ST Version ist, das 'open_short_tags' aktiviert sein müssen.
Letzlich beinhaltet der aktuelle Code (1.6 ST) absolut keinen validen XHTL-Code, zudem stimmen etliche HTML-Tags einfach nicht bzw. deren Anordnung (z.B. keine innerhalb usw.).
Schlussendlich sind etliche - mitterweile schon lange - veraltete HTML.Tags im Code vorhanden.
Die Summe all dieser Fehler führen tw. zu recht unerwarteten Ergebnissen in der Ausgabe.
Falls jemand interessiert ist, ich habe mir erlaubt die 1.6 ST als Basis zu nehmen, alle o.a. Fehler bereinigt.
Und stelle sie gerne zur Verfügung.
Gleichzeitig würde ich gerne weitermachen und das System für Mehrsprachigkeit ergänzen (nebst etlichen Anderem das auszubessern wäre).
Interessierte sind herzlichst willkommen.
