Es gibt KEINE Default-/Standardregeln. Der Junkfilter fängt bei Null an, wenn man die Trainingsdaten gelöscht hat.
Beiträge von Thunder
-
-
Ah, okay. Ich hatte das als Alternative in Betracht gezogen, war aber letztlich so oder so nicht sicher, wie Du es nun meinst.
Ist natürlich einerseits ein Rückschritt, wenn man nicht mehr in dem Dialog direkt neue Ordner erstellen kann. Andererseits gehört es da auch irgendwie nicht so richtig hin. Wer wirklich viele Filter erstellt, sollte doch eh vorher das ganze etwas planen und die Ordner im Vorraus erstellen. Das hilft Dir nun nicht wirklich weiter - ist mir klar. Aber ich finde es okay, wenn es da weggenommen hat.
-
Wie, keine neuen Ordner? Soll der Filter automatisch neue Ordner erstellen? Ansonsten kann man selbstverständlich neue Ordner erstellen, auch wenn Filter existieren.
-
Der Ordner "_Spellcheck" ist ein beliebiger Ordner im Wust meiner sämtlichen Ordner rund um die Arbeit an Thunderbird. Der Ordner könnte auch "Mein_erster_Ordner" heißen. Sie müssen mit dem Dialog die heruntergeladene Wörterbuch-Datei "... .xpi" suchen und auswählen.
-
Mhh, bei mir scheint es bei einem Test momentan zu funktionieren. Ich nutze diese Funktion aber nicht alltäglich kann daher keine "Langzeit-Aussage" machen.
-
Zitat von "Arran"
Danke. Das wars, was ich befürchtet habe.
Na ja, was nicht ist, könnte noch werden...
Mache Dir nicht zuviel Hoffnung. Dazu wäre es notwendig, dass man den Textpassagen die verschiedenen Sprachen zuordnen kann (so wie in guten Textverarbeitungen oder DTP-Programmen). Ich glaube nicht, dass dies je in Thunderbird möglich wird, da es über den Bedarf von fast allen Anwendern hinaus geht. Es gibt viel wichtigere Dinge, die integriert werden (sollten).
-
Man kann NICHT für mehrere Sprachen gleichzeitig prüfen lassen. Man muss nach und nach zwischen den Wörterbüchern umschalten und dann halt jeweils für die entsprechenden Absätze/Sprachen prüfen lassen.
-
Zitat von "edgar"
...mein Anliegen wäre, dass nach dem Klick auf Suchen, auf der Resultate Seite, der Suchstring (Suchbegriffe) im Suchfeld stehen bleibt.
Erlaube dem Webbrowser die Inhalte von Formular-Feldern zu speichern (im Cache). Dann sollten die ersten Buchstaben ausreichen, um wieder den passenden String im Suchfeld stehen zu haben.
Ich bin kein ausgesprochener Webprogrammierer, daher kenne ich keinen Weg, um den String zu "erhalten" - zumal ich auf die angebotenen Möglichkeiten der Sitelevel-Suche angewiesen bin (somit scheidet PHP schon mal aus).
-
Ihr habt alle Ambitionen, aber hinterher habe einzig und alleine wieder ich die Arbeit, da sich bisher so gut wie jeder nach kurzer Zeit verkrümelt hat.
Es wird von meiner Seite kein Wiki und im Großen und Ganzen keine neuen Unterforen geben.
Sorry Leute
-
Das Problem fängt doch mal wieder schon im Englischen an. Für mail / mailnews sind kaum Einstellungen dokumentiert. Die "Browser-Fraktion" hat es da deutlich einfacher, da man oftmals nur aus dem Englischen übersetzen muss.
Wer's nicht glaubt, kann sich mal diese Seite anschauen:
http://preferential.mozdev.org/preferences.html -
Es ist wohl nicht Sinn der Sache, die Prüfung gleich ganz aus zu schalten.
Leider wird das Verfassen-Fenster nicht immer korrekt aktualisiert. Manchmal bleiben auch einfach die roten Linien stehen und der Text verschwindet scheinbar vorübergehend...
-
Ein weiterer BugZilla-Eintrag zu dem Problem:
https://bugzilla.mozilla.org/show_bug.cgi?id=309566 -
Tests, die ich mit Thunderbird 1.5 gemacht habe, haben (zumindest bei mir) ergeben, dass Thunderbird 1.5 jetzt etwas anders reagiert. Die Mails verschwinden nicht mehr komplett, sondern man hat hinterher evtl. quasi 2 Mails: einmal nur die Kopfzeilen und einmal die komplette Mail.
-
Ich habe jetzt mal BugZilla, das LXR und ein paar RFCs bemüht:
1) Es gibt in Thunderbird eine versteckte Pref mit deren Hilfe man das Problem beheben kann. Diese Pref beeinflusst, ob und wie die Namen der Attachments in den Source eingetragen werden.
Sucht in Thunderbird 1.5 nach dieser Pref in Extras > Einstellungen... > Erweitert > Konfiguration bearbeiten:
Die Pref darf die Integer-Werte 0,1 oder 2 haben.0 war scheinbar bei Tb 1.0.x Standard. Bei Tb 1.5 ist jetzt 2 Standard - soweit ich das in LXR bei Mozilla.org finden kann.
Setzt man den Wert wieder auf 0, dann läuft alles wieder ohne Probleme - ich habe es mit Erfolg getestet.
2) Es gibt einen Bug dazu:
https://bugzilla.mozilla.org/show_bug.cgi?id=317972Das ist die Standardpref-Zeile in Thunderbird 1.5:
Man wird auf die beiden entsprechenden RFCs verwiesen:http://www.faqs.org/rfcs/rfc2047.html
http://www.faqs.org/rfcs/rfc2231.htmlMir scheint, dass einige Programme nicht mit dem neueren RFC 2231 zurecht kommen (bisher).
-
Also OE hat tatsächlich ein Problem mit dem Attachment aus Thunderbird. Ich habe dann nochmal aus OE das gleiche Attachment verschickt und mir hinterher die SourcCodes der Mails angesehen/verglichen:
Gesendet aus Thunderbird:
Code
Alles anzeigenContent-Type: application/pdf; name*0*=ISO-8859-15''Verschl%FCsselung%20und%20digitale%20Unterschrift%20f name*1*=ormatiert.pdf Content-Transfer-Encoding: base64 Content-Disposition: inline; filename*0*=ISO-8859-15''Verschl%FCsselung%20und%20digitale%20Unterschrift filename*1*=%20formatiert.pdf JVBERi0xLjQKJcDIzNINCjEgMCBvYmoKPDwKL1RpdGxlIChWZXJzY2hsXDM3NHNzZWx1bmcg dW5kIGRpZ2l0YWxlIFVudGVyc2NocmlmdCBmb3JtYXRpZXJ0LmRvYykKL0F1dGhvciAoUGV0 ...
Gesendet aus OE:
Code
Alles anzeigenContent-Type: application/pdf; name="=?iso-8859-1?Q?Verschl=FCsselung_und_digitale_Unterschrift_formatiert.pdf?=" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="=?iso-8859-1?Q?Verschl=FCsselung_und_digitale_Unterschrift_formatiert.pdf?=" JVBERi0xLjQKJcDIzNINCjEgMCBvYmoKPDwKL1RpdGxlIChWZXJzY2hsXDM3NHNzZWx1bmcgdW5k IGRpZ2l0YWxlIFVudGVyc2NocmlmdCBmb3JtYXRpZXJ0LmRvYykKL0F1dGhvciAoUGV0ZXIpCi9D ...
-
Nun habe ich auch noch an GMX und Web.de gesendet. Von beiden Konten jeweils mit Tb 1.5 und Opera 8.5 abgerufen --> jeweils alles in bester Ordnung mit den Attachments und deren Namen - inkl. Umlaut.
Wenn ich bei GMX über die Weboberfläche gehe, dann wird dort ein Fantasiename für das Attachment vergeben.
Im E-Mail-Header bzw. Source scheint mir aber alles stimmig zu sein mit dem Attachment. Der Name des Attachments ist als ISO-8859-15 kodiert, genau wie die Mail selbst. Dabei ist es egal, ob der Mailtext Umlaute enthält oder nicht.
-
Ich habe gerade mal eine Mail an mich selbst gesendet: Ein PDF mit "ü" im Namen. Es kam von Thunderbird 1.5 zu Thunderbird 1.5 ohne Fehler an.
EDIT:
Und gerade mal noch mit Opera abgerufen: auch der normale, korrekte Dateiname des Attachments mit dem "ü" wird mir gezeigt. -
Im Grunde ist eine lokalisierte Seite nicht notwendig, da die Themes ja weitgehend sprachunabhängig sind.
Wenn alle Extension-Autoren willig wären, alle locales zu integrieren, dann bräuchte man auch nur noch bedingt eine lokalisierte Erweiterungen-Seite. Aber z.B. Enigmail oder ContactsSidebar werden von den Autoren prinzipiell nicht mit mehreren locales angeboten.
-
Zitat von "allblue"
Noch ein Problem:
In diesem Forum befinden sich hunderte Links auf Erweiterungsseiten innerhalb dieser Website.
Nur mal ein aktuelles Beispiel in folgendem Beitrag:
https://www.thunderbird-mail.de/forum/viewtopic.php?p=77873#77873Das ist leider übel für alle Neulinge hier.
Könntest du nicht (bitte) für alle solchen Links eine Seite zwischenschalten, in der erklärt wird, dass die Erweiterungen hier nicht mehr hier sind und die Besucher sich die entsprechende Erweiterung bei erweiterungen.de raussuchen?
Ich habe eigentlich schon Weiterleitungen für alle Erweiterungen angelegt. Aber die greifen momentan nur, wenn sie mit Backslash oder mit /index.php enden. Evtl. werde ich das aber auch komplett anders mit einer speziellen Fehlerseite machen, die den Hinweis enthält.
Zitat von "allblue"Das gleiche gilt für Links im Forum zu der ehemaligen Seite: "Wie installiere ich Erweiterungen?" Hier wäre es evtl. sogar möglich, eine Weiterleitung auf die analoge Seite bei erweiterungen.de zu legen.
Diese Seite bleibt natürlich erhalten. Es ist ja Teil der Hilfe.
-
Ich werde mir was einfallen lassen...