Beiträge von msi

Ja, theoretisch kann man das Problem umgehen, indem man den Parameter nutzt und den String quasi selbst übergibt. Das würde funktionieren. Aber die Vorgabe darf eben keine Funktion sein.

Ich hatte ein Ticket aufgemacht. Jemand vom WP-Team hat meinen Code ein wenig verändert, aber ich würde mal sagen, dass das in einer der nächsten Revisionen dann drin sein wird.

PS: Ab Revision 8547 ist die Änderung drin. Künftig kann "the_content()" auch leer (ohne Parameter) aufgerufen werden, und es wird funktionsintern ein übersetzbares "(more...)" verwendet. Jetzt müssen bloß noch die Kubrik-Änderungen rein, und der Ordner "default_DE" gehört auch der Vergangenheit an. ;)

Die beiden Themes können ausnahmsweise nichts dafür. Der Fehler liegt bereits in der Funktion "the_content", weil der Parameter "(more)" als fester String übergeben wird

function the_content($more_link_text = '(more...)', $stripteaser = 0, $more_file = '') {

Fixen könnte man das zurzeit nur so:

function the_content($more_link_text = '', $stripteaser = 0, $more_file = '') {
    if ( strlen( $more_link_text ) === 0 ) {
        $more_link_text = __('(more...)');
    }
    $content = get_the_content($more_link_text, $stripteaser, $more_file);
    // ...

Dann spart man sich den Parameter bei "the_content", und trotzdem wird der Text übersetzt angezeigt. ;)

PS: Streng genommen müsste man das dann auch bei "get_the_content" machen.

Zitat von jottlieb

Wurde behoben...war diesmal nur die comments.php von Kubrick.

Ich hoffe, das WP-Team lässt mit sich reden. Meinen Patch für Kubrik habe ich schon längst online gestellt. Wenn die das reinnehmen, dann spart ihr euch künftig die Anpassung, weil die Strings dann in der Sprachdatei auftauchen. Das finde ich persönlich effizienter. ;)

In welchem Ordner hast du denn das Plugin? In "wp-content/plugins/wp-ban"? Dann sollte es so wie von mir gezeigt gehen. Wenn dein Ordner irgendwie anders aussieht, musst du den zweiten Parameter anpassen.

Das kann ich bestätigen. Die entsprechenden Zeilen stehen in "wp-admin/edit-pages.php", fehlen aber in der hiesigen Sprachdatei.

Robert, nix für ungut, aber ich nutze nicht diese POT-Vorlage. Ich lasse die PHP-Dateien bei jedem svn-Checkout neu scannen, und damit habe ich das Problem in meiner Sprachdatei nicht.

Könnt ihr den Titel dieses Beitrags so ändern, dass er sich jetzt auf die Sprachdatei von WP 2.6 bezieht? Dann muss man keinen neuen Beitrag für Fehler usw. erstellen. ;)

Kleine Anmerkung, da ich auf Grund dieses Beitrags eure Sprachdatei verwende: In den Einstellungen/Schreiben steht

Zitat

Um einen Artikel in WordPress mit einem Desktop-Blogging-Programm zu erstellen das das Atom Publishing Protocol oder eine XML-RPC-Schnittstelle benutzt musst du die unten aktivieren.

"die unten" was? Und nach erstellen und benutzt fehlt jeweils ein Komma.

Kann ich nicht nachvollziehen. Ich habe die Sprachdatei des Teams hier mal eben heruntergeladen und in meinen lokalen Blog kopiert, und die Rollen werden übersetzt angezeigt.

Zitat von Urgixgax

Woran sehe ich, dass die Datei, vielleicht nur de_DE heisst, aber nicht deutsch ist?

Das habe ich nicht gemeint. In deiner "wp-config.php" sollte der Eintrag "de_DE" als Sprache stehen, und die WordPress-Sprachdatei sollte dann eben auch "de_DE.mo" heißen. Der Name der Sprachdatei für Plugins bildet sich nämlich aus der jeweiligen Sprachdomain und dem Sprachkürzel (eben de_DE); eben "wp-ban-de_DE.mo".

Zum PHP-Code, ich denke, dass hier das Problem zu suchen. Probier's mal so

function ban_textdomain() {
      load_plugin_textdomain( 'wp-ban', 'wp-ban' );
//    if (!function_exists('wp_print_styles')) {
//        load_plugin_textdomain('wp-ban', 'wp-content/plugins/wp-ban');
//    } else {
//        load_plugin_textdomain('wp-ban', false, 'wp-ban');
//    }
}

Die Originalzeilen bitte nur auskommentieren.

Sinn der Sache, die neue Syntax der Funktion. Wie gesagt ist der zweite Parameter ein relativer Pfad, ausgehend von WP_PLUGIN_DIR. Und der setzt sich in der Standardeinstellung (wenn man es in "wp-config.php" nicht ändert!) zusammen aus

define( 'WP_PLUGIN_DIR', WP_CONTENT_DIR . '/plugins' );

Du brauchst also nur noch den Ordner des Plugins.

Ich kenne das Plugin nicht, und Nein: ich will es auch nicht testen. Aber es gibt nur zwei Möglichkeiten.

1. Du hast geprüft, dass deine Spracheinstellung auch tatsächlich "de_DE" ist, denn sonst wird das mit dieser Sprachdatei nichts:

Zitat von Urgixgax

wp-ban-de_DE.*

2. Das Plugin ist noch nicht für WP 2.6 ausgelegt. Die Funktion, mit der man Sprachdateien in Plugins lädt, hat sich nämlich verändert und kennt jetzt 3 Parameter.

function load_plugin_textdomain($domain, $abs_rel_path = false, $plugin_rel_path = false)

Der erste ist nach wie vor die Sprachdomain (also "wp-ban" in deinem Fall). Der zweite bezieht sich auf den neuen Pfad, ausgehend von WP_PLUGIN_DIR (neue Konstante in 2.6), und der dritte ist quasi die alte Version, ausgehend von ABSPATH.

Du solltest also nach einem Update des Plugins schauen, oder du änderst die Datei entsprechend um. Sprich: Editor öffnen und in der PHP-Datei nach der o.g. Funktion "load_plugin_textdomain" suchen.

Zitat von Alphawolf

Wo bleibt die Sprachdatei für 2.7! :neutral:

So, die "wp-includes/version.php" wurde angepasst. Mein WordPress meldet sich damit bereits als 2.7-bleeding. :mrgreen:

Ein Ticket für das Kubrik-Thema inkl der Patchdatei habe ich übrigens gestern auch aufgemacht. Schau'n wir mal.

Zitat von Monika

übersetzen dauert

Ich weiß, denn ich nutze ja meine eigene Sprachdatei.

Zitat

stell Dir vor die neue Versionierung ist nicht korrekt übersetzt...

Also, wie das schon passiert ist. *grinsendaufdiesprachsparteguck* :mrgreen:

Ich wollte eigentlich nur darauf hinaus, dass ich persönlich es als unsinnig empfinde, wenn ihr euch die Mühe macht, ein komplettes Thema zu übersetzen, nur weil die Entwickler zu (sorry!) faul sind, es gleich übersetzbar zu gestalten. Damit spart ihr künftig Zeit und habt diese dann fürs Übersetzen und Kontrollieren.

Mir persönlich ist es egal, denn ich nutze sowieso die englische SVN mit meiner eigenen Sprachdatei. Ich muss auf niemanden warten. ;)

Alphawolf: Hast du einen eigenen Server mit den passenden Tools auf deinem Rechner? Dann nimm dir die aktuelle Sprachdatei für 2.6 (sofern sie bereits existiert), checke ab und zu das SVN aus, prüfe mit poEdit nach neuen Textstellen und übersetze sie selbst.
So habe ich das damals ab Version 2.5 gemacht, weil die offizielle Sprachdatei für 2.3.x war und diverse Texte meiner Version nicht enthielt.

Zitat von jottlieb

Kubrick ist mittlerweile auch (komplett?) gettexted.

Nicht die Version, die ich in den letzten Tagen via SVN gezogen habe, und die sich seit heute morgen als "2.6" meldet (ohne bleeding, beta usw. ;)). In der ist das normale Kubrikthema nach wie vor mit nicht übersetzbaren Strings drin.

Wenn du eure aus der DE-Version meinst, dann mag es zwar sein, dass ihr die inzwischen komplett übersetzt habt. Nur der Nachteil ist, dass man eben auf eure Version warten muss (so man sie denn nutzt), weil ihr zumindest kontrollieren müsst, ob sich im Code nicht doch etwas verändert hat.

Und an dem Punkt fände ich es sinnvoller, gleich beim WP-Team einen Patch für das Originalthema einzureichen, so dass ihr euch eigentlich nur noch auf die Übersetzung konzentrieren müsst. Oder notfalls mache ich ein Ticket auf. Ich habe eine 40k große Patchdatei, die die Strings in den Themendateien auf die entsprechenden Funktionen umstellt, so dass man sie dann auch übersetzen kann.

Eigentlich ist es doch nur das Default-Thema, das nicht übersetzbare Texte enthält, oder? Wenn du das nicht verwendest, dann kannst du auch die englische Version + passende Sprachdatei verwenden. So mache ich das, und bei mir läuft WP 2.6 schon eine Weile.

Ich verstehe allerdings auch das hiesige deutsche Team nicht. Anstelle mühsam das Default-Thema zu übersetzen, sollte man die Texte doch einfach übersetzbar gestalten und das ganze dann an die WP-Entwickler weiterreichen. Dann spart man sich für künftige Version eine Menge Arbeit und muss ggf. nur die Sprachdatei anpassen.

Die Meldung deutet darauf hin, dass poEdit nichts mit den Pluralfunktionen anfangen kann. Pluralfunktionen bei Wordpress sind Funktionen, die abhängig von der Anzahl eines Wertes eben Singular oder Plural anzeigen. Als Beispiel:

_ngettext( 'Du allein', 'Die Benutzer', $anzahl_benutzer);

Typische Funktionen sind:

__ngettext:1,2
__ngettext_noop:1,2

(muss so in poEdit eingetragen werden, unter Katalog/Optionen/Schlüsselwörter). Und damit poEdit weiß, was das soll, muss unter Katalog/Optionen/Projektinfo im Feld "Pluralformen"

nplurals=2; plural=n != 1;

rein.

Dann sollten die Fehler verschwunden sein.

Zitat von Erin

uff... also bleibt nichts anderes als das per Hand zu editieren? :???:

Du machst das nur ein einziges Mal. Wenn du die reparierte SQL-Datei dann wieder importierst, werden die Umlaute in Zukunft korrekt gespeichert. Du solltest aber auch sicherstellen, dass deine "wp-config.php" die passenden Einträge enthält. In früheren Versionen war das nicht so, deswegen wurden meine Tabellen als latin1_irgendwas angelegt. Als Beispiel, so sah meine Kommentartabelle mal aus:

CREATE TABLE `wp_comments` (
  ... 
  `comment_author` tinytext collate latin1_german1_ci NOT NULL,
  ... 
) ENGINE=... DEFAULT CHARSET=latin1 COLLATE=latin1_german1_ci ... ;

und nach der Anpassung sieht sie so aus:

CREATE TABLE `wp_comments` (
  ...
  `comment_author` tinytext NOT NULL,
  ...
) ENGINE=...  DEFAULT CHARSET=utf8 AUTO_INCREMENT=... ;

Du lässt also das ganze COLLATE-Gedöns verschwinden und achtest darauf, dass der Zeichensatz auf UTF-8 steht. Dann reparierst du die Umlaute, importierst die Datei zurück in den Blog, und fertig.

Ich hatte das gleiche Problem. Ich habe die Tabellen per phpMyAdmin exportiert und dann in der SQL-Textdatei alle Verweise auf andere Zeichensätze gelöscht bzw. durch UTF-8 ersetzt. Danach habe ich die Umlaute repariert und das ganze Ding wieder importiert.

Du wurdest gefragt, welches Thema du nutzt. Kubrik ist es offenbar nicht.

Vielleicht könntest du dich stattdessen mit dem Autor in Verbindung setzen und ihm vorschlagen (ggf. mit ihm gemeinsam) das Thema zu "internationalisieren". Dabei werden die Standardtexte mit speziellen Funktionen umschlossen, bspw

$none = __( 'Comments Off' );

und mit Hilfe einer Sprachdatei kann das dann bequem übersetzt werden, ohne dass man die Originaldateien muss, und ohne, dass ein Update das alles wieder zunichte macht.

Zitat von marX

Du hast hier schon mal einige Plugins vergessen. ;-)

Nein! Ich nutze offen gesagt nur selbst geschriebene bzw. von mir erweiterte Plugins, die alle nichts mit der ID zu tun haben. Das einzige unveränderte Plugin ist der Page Link Manager, aber lässt sich nach der Anpassung der ID via Oberfläche natürlich auch wieder festlegen, welche Seiten ausgeblendet werden sollen.

Insofern passt das schon. ;) Ich bin sowieso jemand, der nicht alle Funktionen von WordPress nutzt. Das ist mir zuviel Kram dabei, den ich noch nie gebraucht habe. Leider (ist zwar etwas off-topic, sorry!) legen die Entwickler zuviel Wert auf neue Funktionen und kümmern sich nicht um eine Verschlankung und Absicherung der bestehenden Codebasis.
Aber ich habe schon eine Alternative im Auge. Die muss nur noch etwas bequemer und komfortabler werden, und dann bin ich fort. Von WordPress.

Zitat

(Nebenbei: es gibt noch andere Datenbanken als MySQL und nicht alle behandeln gelöschte Datensätze gleich. Unter Umständen kann dir deshalb auch irgendwann mal ein Backup auf den Kopf fallen, wenn eine "gelöschte" ID plötzlich durch das Backup wieder vorhanden ist. Aber das nur am Rande.)

Ich bin nicht sicher, ob deine Vermutung zutrifft. Ich schrieb hier, dass ich meine Backups mit phpMyAdmin mache. Meine SQL-Datei enthält auch den DROP TABLE-Befehl (kann man beim Exportieren auswählen), und sie speichert auch den zum Zeitpunkt des Backups gültigen AUTO_INCREMENT.
Selbst wenn ich also ein altes Backup nehme, in dem die Artikel-IDs noch nicht angepasst waren, passiert nichts. Die vorhandene Tabelle würde gelöscht, neu erstellt und neu befüllt werden.

Aber wie gesagt, um das Thema dann mal abzuschließen:
KINDER, MACHT DAS BITTE NICHT ZUHAUSE NACH! :mrgreen:

Ich nutze die WP-Export- und Importfunktion überhaupt nicht. Ich exportiere mit phpMyAdmin die Datenbank bis auf die "wp_options"-Tabelle. Das liegt daran, dass ich lokal natürlich eine andere Domain verwende, usw.
Lokal habe ich den Blog einmal installiert (Einstellungen, Plugins aktiviert), und dann habe ich die exportierte SQL-Datei ebenfalls mit phpMyAdmin importiert.

Absolut kein Problem: eine 1:1-Kopie der Liveseite.

Welches Thema nutzt du denn?