Textänderung mit automatischen  

  • Hallo!

    Mehrfach entsteht nach Text (Eingaben oder) Änderungen statt einem Leerzeichen ein geschütztes Leerzeichen ( ). Dies hat negative Folgen in den veröffentlichten Seiten.


    In welchem Zusammenhang diese nicht erwünschten geschützten Leerzeichen statt einem normalen Leerzeichen generiert werden ist mir noch nicht klar.
    Geschützte Leerzeichen haben eine Sonderfunktion und sollten in "normalem Text" nicht vorkommen.


    Ich verwende Layout Flat Responsive mit der Einstellung für manuelle Silbentrennung.

  • Drücken Sie während der Eingabe des Leerzeichens ggf. noch eine Zusatztaste wir z.B. "Alt"?

  • Nein, aber werde es noch besser beobachten. Kann erst am Abend zusätzlich gezielt testen.
    Vielleicht hat es mit Text ausschneiden/einfügen STRG+X/V zu tun.

  • Neue Erkenntnis

    Gezielte Tests ergaben folgendes Ergebnis:


    Wird in einem Text ein vorhandenes Wort durch anderen Inhalt ersetzt, wird vor den neuen Inhalt statt dem normalen Leerzeichen ein geschütztes Leerzeichen eingefügt.


    Detailierter Testablauf:

    1. Seite mit Text Widget
    2. Text geschrieben und bestätigt
    3. Quelltext kontrolliert = alles noch OK
    4. Text Widget geöffnet
    5. zu ersetzendes Wort markiert (im Beipiel das Wort Teil)
    6. neues Wort eingegeben (im Beispiel das Wort Absatz)
    7. zur Kontrolle auf Quelltext umgeschaltet (=Screenshot aus Beispiel)
    8. vor dem neuen Wort ("Absatz") ist statt dem Leerzeichen ein unerwünschtes  

    Anmerkung: ganzen Absatz (von oben) kopieren hatte davor fehlerlos funktioniert.


    Screenshot Dokumentation:



    = vor der Änderung



    = zu änderndes Wort markiert


    = nach der Wortänderung

    Getestet mit:
    https://hosting.zeta-producer.com/4863801496/testseite.html

  • Hallo,


    vielen, vielen Dank für den detaillierten Test. Ich habe das Schritt für Schritt nachgemacht (ZP 14, Windows 7), aber mit einem anderen Ergebnis. Weder kopierte Worte noch ersetzte Worte haben bei mit das Einfügen eines   verursacht. Kann das jemand anderes so reproduzieren? Wenn nicht, müsste wohl irgend eine Komponente auf Ihrem System dieses Verhalten provozieren.

  • Hallo,

    bei mir ist es reproduzierbar und tritt leider oft auf, so dass ich nun nach jeder Textänderung zur Sicherheit mit Quelltext Anzeige kontrolliere und ausbessere. Aber so kann man schlecht auf Dauer arbeiten.

    Vielleicht hat es mit meiner Einstellung "manuelle Silbentrennung" zu tun, die ich beibehalten möchte. Das habe ich noch nicht getestet.

  • Wir versuchen noch ob wir es irgendwie nachgestellt bekommen.

    In "Extras > Optionen > Aktionen" gibt es übrigens eine Aktion "Alle geschützten Leerzeichen entfernen". Ggf. hilft das erstmal die unerwünschten Folgen schnell zu beseitigen.

  • Im Editor selbst gibt es per Rechtsklick und dann "Erweitert" ebenfalls eine Option um geschützte Leerzeichen zu entfernen.


    Nach meiner jahrelangen Erfahrung ist das ein Fehler im Internet Explorer, den wir im Hintergrund als zugrunde liegenden Editor verwenden.

  • Hallo,


    jetzt konnte ich es reproduzieren. Entscheidend hierbei ist, wie man das Wort markiert.


    Ich hatte das Wort immer per Doppelklick markiert. Dadurch wird das Wort inkl. nachfolgender Leerstelle markiert. Wenn man es dann überschreibt entsteht kein  .

    Wenn man das Wort aber manuell per ziehen der Maus vom 1. Zeichen bis einschl. letzten Zeichen des Worts markiert und es dann überschreibt, dann entsteht der  .


    Da wir für den Editor externen Komponenten einsetzen, können wir noch nicht sagen, ob wir den Fehler beheben können.


    Da nun aber die Ursache klar scheint, lässt sich ja hoffentlich um den Fehler herum arbeiten.

  • Hallo,


    ich hatte das Problem auch des öfteren wie von Herrn S. beschrieben hängt das mit dem ziehen der Maus über das Wort zusammen. Ich habe jedesmal alle Texte im Quelltexteditor geöffnet und nachbearbeitet. Um den Code sauber zu halten ist es meines Erachtens wichtig im Quelltexteditor die letzten Feinheiten zu verbessern. Ebenfalls kann man auch versehentlich gemachte Leerzeichen und insbesondere die Codes von Tabellen verbessern.

    Auch passieren schnell Fehler wenn eine Fettdarstellung mittels Maus-Markierung wieder rückgängig gemacht wird, denn man weiß nie ob man auch ein Leerzeichen als Fett miteinbezogen hat, folglich sind dann im Quelltext Codes, die gelöscht werden sollten z.B: <b></b>, <i></i>....

  • Danke für die zusätzlichen Informationen!

    Habe alle unerwünschten &nbsp; entfernt. Aber bei jedem neuen Text oder nach jeder Textänderung über die Funktion Quelltext die richtige Speicherung kontrollieren zu müssen, ist auf Dauer nicht sinnvoll. Geschützte Leerzeichen haben eine Sonderfunktion und sollten auch nur an dafür gezielt eingesetzten Stellen vorkommen, also nicht automatisch generiert werden.



    Da wir für den Editor externen Komponenten einsetzen, können wir noch nicht sagen, ob wir den Fehler beheben können.

    Ich Hoffe, Sie finden wie erfolgreich für viele andere Probleme, auch dafür eine Lösung.


    Ich habe jedesmal alle Texte im Quelltexteditor geöffnet und nachbearbeitet.

    Für Sonderfälle, wie das von Ihnen beschriebene Beispiel, eine hilfreiche Information. Danke!
    Aber für keine Profis, wie mich, kann es nicht Ziel und Notwendigkeit sein, jeden Text über Quelltext nachträglich kontrollieren zu müssen. Welchen Eindruck würde das hinterlassen, wenn das als Anforderung im ZP-Handbuch stünde.



    Zu ersetzende oder zu ändernde Textabschnitte mit der Mouse markieren ist möglich und sicher nicht so selten verwendet. Ich mach das lieber als mit Tastaturfunktionen.

  • Ich hoffe noch immer auf eine automatisierte Problemlösung.

    Laienhafter Vorschlag/Idee:
    Die in #8 von Uwe Keim erwähnte Sonderfunktion zur nachträglichen Umwandlung geschützter Leerzeichen, ohne zusätzlich notwendige Bedienschritte, automatisch nach Bestätigung erfasster oder geänderter Texte auf den bestätigten Text im aktuellen Widget anwenden.

    Dass dieses Problem "im Verborgenen" auf vielen ZP-Seiten schlummert ist auch in diesem neuen Beispiel beschrieben:
    Linkbox - Textinhalt - Boxlänge/-Breite

  • Möchte an eine Lösung des &nbsp Problems erinnern.

    Beispiel in einem Textartikel von heute:

  • Hallo Walter,


    für mich ist da eher die Frage, wie den Zeta "automatisch" erkennen soll, ob es sich um ein gewünschtes oder ein unerwünschtes "Geschütztes Leerzeichen" handelt. Die einzige Möglichkeit ist eine Benutzerabfrage nach "OK": "Dieser Text enthält geschützte Leerzeichen. Sind diese beabsichtigt oder sollen sie entfernt werden?". Das würde die Bedienung des Programms viel mehr verlangsamen als der Klick auf "zusätzliche Aktionen".


    Wenn ich das richtig sehe, werden ja geschützte Leerzeichen nur dann erzeugt, wenn diese mit der Maus markiert und eine gesonderte Formatierung rückgängig gemacht wurde, was nur bei Markieren mit der Maus passiert.


    Ich habe jetzt mal die Aktion "geschützte Leerzeichen entfernen" bei unserer Homepage gemacht (236 Seiten, 44.000 Wörter) bei unserer Homepage angewandt. Gefühlt hat das Ganze unter 3 Sekunden gedauert.


    Was mich an Deinem Beispielfoto etwas irritiert, ist die <h3> Definition im Text. Ich verwende in solchen Fällen zwei Textartikel, 1 x nur mit "Irrweg" in der Überschrift als <H2> und 2 x mit "Moderne" in der Überschrift <H3> mit Textinhalt.

  • Wenn ich das richtig sehe, werden ja geschützte Leerzeichen nur dann erzeugt, wenn diese mit der Maus markiert und eine gesonderte Formatierung rückgängig gemacht wurde, was nur bei Markieren mit der Maus passiert.

    Dazu dürfte ein Zusammenhang bestehen, aber nur das allein kann es nicht sein. Habe heute extra darauf geachtet, anders als ich es gewöhnt bin, nur über Tastatur zu ändern ohne die Maus zu benutzen. Das Ergebnis ist ein ungewolltes &nbsp;



    Was mich an Deinem Beispielfoto etwas irritiert, ist die <h3> Definition im Text. Ich verwende in solchen Fällen zwei Textartikel, 1 x nur mit "Irrweg" in der Überschrift als <H2> und 2 x mit "Moderne" in der Überschrift <H3> mit Textinhalt.

    Passt zwar nicht zum Thema, aber will ich gern erklären.
    Das ist so von mir beabsichtigt und hat einen "für mich" entscheidenden Vorteil. Der Untertitel ist wie in einem Zeitungsartikel untrennbar mit dem Übertitel verbunden. Das ergibt im Widget Artikelübersicht auch nur einen zusammengehörenden Artikel und sieht in diesem Beispiel dort dann so aus:

    Ich verwende das auf meiner Seite http://www.mondseelandler.at/neue-artikel.html


    für mich ist da eher die Frage, wie den Zeta "automatisch" erkennen soll, ob es sich um ein gewünschtes oder ein unerwünschtes "Geschütztes Leerzeichen" handelt.

    Das ist praktisch unmöglich und bitte meine Antwort #12 nicht zu vergessen.

    Die vorhande ZP Sonderfunktion um alle geschützten Leerzeichen zu ersetzen ist zwar gut gemeint (war wohl vor meiner ZP Zeit schon ein Thema für die Entwicklung), aber praktisch nur schwer anwendbar. Denn es gibt durchaus sinnvolle Textstellen für geschützte Leerzeichen. Diese werden von der ZP Sonderfunktion ungewollt mit zerstört. Die vorhandene Sonderfunktion bringt also nicht nur Vorteile, sondern auch Nachteile die vielleicht nicht immer so schnell erkannt werden.


    Meine Wunschvorstellung wäre eine bestenfalls über Funktionstaste schaltbare Option "Geschützte Leerzeichen automatisch ersetzen (ein/aus)" die sich auf alle aktuellen Texterfassungen bzw. Textänderungen auswirkt.


    So könnte die automatische &nbsp; Ersetzung als übliche Einstellung fast immer aktiviert sein und nur für besondere Texte auf einfache Weise vorübergehend ausgeschatet werden.


  • Hallo,


    wie unser Entwickler ja bereits mal bemerkt hatte, nutzen wir hier eine Funktion von Microsoft. Diese enthält den Fehler und da sind wir dann leider selbst von einem entsprechenden Bugfix von MS abhängig.

  • Ich hoffe noch immer auf eine Lösung des @nbsp; Fehlers.


    Meine Wunsch bleibt eine schaltbare Option „Geschützte Leerzeichen automatisch ersetzen (ein/aus)" die sich auf alle aktuellen Texterfassungen bzw. Textänderungen auswirkt.


    Da mir dieses "von vielen Zeta Anwendern unerkannte" Problem bekannt ist, schalte ich bei allen neuen und geänderten Texten mühsam zur Kontrolle auf Quelltext um und korrigiere so abschließend ungewollt entstandene geschützte Leerzeichen.

    In einem Widget mit "Normaltext" Feld ist das zwar umständlich, aber mit wenigen Schritten möglich.


    Aber dieses aktuelle Beispel zeigt gut versteckte und nicht so leicht korrigierbare Inhalte:


    Das ist die automatisch als "title" übernommene Bildbeschreibung zu einem Bild in Bild-Widget mit @nbsp; Fehler.


    Bild Widget

    Im Feld "Alt-Text" fehlt die Möglichkeit auf Quelltext umzuschalten und nachträglich zu kontrollieren.
    Das unsichtbare und ungewollte geschützte Leerzeichen kann nicht einfach ersetzt werden. Bei Text Neuerfassung ist man nie sicher ob sich dieser Fehler (wieder) darin versteckt.


    Im Feld Bildbeschreibung kann über Rechtsklick im (versteckten) Zusatzmenü über "Erweitert" die Anzeige "HTML-Quelltext" ausgewählt werden.
    Das sind lästige und mühsame Kontrollwege.


    An dieser Stelle ist auch "Geschützte Leerzeichen ersetzen" als Funktion angeboten. Das kann doch schon ein Teil einer automatisierbaren (generell schaltbaren) Problemlösung sein?



    Auch wenn dieser Fehler ursächlich eine Microsoft Fehlfunktion ist, sollte Zeta Producer das für die Anwender oft unerkannte oder über Zufälle erst spät entdeckte Problem mit einer automatisierten Korrektur lösen.