WordPress speichert beim Anlegen eines neuen Beitrages dessen URL (natürlich) in der Datenbank – in der Form http://www.meineseite.de/?p=1
Wordpress nennt das die guid, die mittlerweile nicht mehr als Permalink(-ersatz) zu verstehen ist, sondern lediglich ein „Link zum Post“, der Blogposts eindeutig identifizierbar machen soll.

guid 

(string) A link to the post. Note: One cannot rely upon the GUID to be the permalink (as it previously was in pre-2.5), Nor can you expect it to be a valid link to the post. It’s mearly a unique identifier, which so happens to be a link to the post at present.

Function Reference/get post

Das ist dumm, wenn man später einmal auf eine andere Domain umzieht, denn Plugins nutzen sie immer noch als Permalinkersatz. Dann muss man die guid aller Posts händisch ändern – in der Datenbank. In der WordPress-Administration sieht man diese guid gar nicht.

In der Datenbank selbst muss man folgende Anweisung nutzen:

update [table_name] set [field_name] = 
replace([field_name],'[string_to_find]','[string_to_replace]');

Für unser Beispiel also:

update wp_posts set guid = 
replace(guid,'www.meineseite.de','www.meineneueseite.de');

So auch nachzulesen im WordPress Codex: Domain Name Change. Wer sich die Arbeit sparen will, kann auch ein Script wie dieses nutzen: WordPress Scripts

Persönliche Notiz:
Für mich leider wieder einmal eine Eigenschaft von WordPress, die mir sauer aufstößt – was in letzter Zeit eindeutig zu oft passiert.

Da ich gerade selbst darüber gestolpert bin: Widgetizing Themes

Wie kann ich Widgets in meinem WordPress Theme nutzen?

Gehen wir von folgendem Sidebar-Code aus:

<ul id="sidebar">
 <li id="about">
  <h2>About</h2>
  <p>This is my blog.</p>
 </li>
 <li id="links">
  <h2>Links</h2>
  <ul>
   <li><a href="http://example.com">Example</a></li>
  </ul>
 </li>
</ul>

Mit zwei kleinen Änderungen aktivieren wir Widgets in unserer Sidebar:

<ul id="sidebar">
<?php if ( !function_exists('dynamic_sidebar')
        || !dynamic_sidebar() ) : ?>
 <li id="about">
  <h2>About</h2>
  <p>This is my blog.</p>
 </li>
 <li id="links">
  <h2>Links</h2>
  <ul>
   <li><a href="http://example.com">Example</a></li>
  </ul>
 </li>
<?php endif; ?>
</ul>

Hier die zwei Zeilen noch einmal:

<?php if ( !function_exists('dynamic_sidebar')
        || !dynamic_sidebar() ) : ?>
[...]
<?php endif; ?>

Wenn nun in den Theme-Einstellungen Widgets hinzugefügt werden, werden diese angezeigt, ansonsten die statische Sidebar.

Wollen wir aber unsere komplizierte Sidebarstruktur behalten, die uns eben ganz bestimmte Inhalte in ganz bestimmten Bereichen (Seiten, Blogbereich oder Archiven; siehe Conditional Tags) ausgeben, dann nutzen wir diese zwei Zeilen einfach an einer beliebigen Stelle innerhalb unseres Kontrukts.
Mein Beispiel: Mein Blogbetreiber hat verschiedene inhaltliche Bereiche, die jedesmal mit anderen Sidebarinhalten zusammen gehören. Uns an einer einzigen Stelle (in normalen Blogbetrieb) will er eigenen HTML-Code anzeigen.

Beachte: Wenn wir Widgets nutzen wollen, müssen wir dies in der functions.php unseres Themes aktivieren. Siehe Widgetizing Themes

So, nach langem Suchen habe nicht ich die Lösung gefunden, sondern wieder einmal der toocan.

Problem: Wer mehrere Sprachen in einem WordPress-Blog verwenden möchte, landet früher oder später bei Polyglot (wie ich) oder Language Switcher. Dann müssen aber Templates angepasst werden, damit der Besucher eben alles in seiner Sprache lesen kann. Das geht zum einen über gettext und ist verdammt aufwendig (immerhin müssen die Sprachdateien und die Ausgaben im Template angepasst werden…. bäh)

Oder man nutzt die Polyglot-interne Möglichkeit eines Filters: polyglot_filter()

Will man also in der Sidebar alle Kategorien anzeigen lassen und hat dazu den Titel „Kategorien“ vorgesehen, benötigt aber dasselbe für englischsprachige Besucher, dann könnte das so aussehen:

polyglot_filter('[lang_de]Kategorien[/lang_de][lang_en]Categories[/lang_en]')

Das kommt einfach ins Template an die Stelle, an der nachher die Liste mit den Kategorien erscheinen soll, also irgendwo vor wp_list_categories().

Übrigens:
Das funktioniert nicht nur in Themes, sondern auch in Plugins, die Daten aus der Datenbank holen und eben nicht für die Mehrsprachigkeit vorbereitet haben, sondern sie fein mit den bekannten polyglotschen eckigen Klammern zur Sprachzuordnung anzeigt. Das ist nicht nur hässlich, sondern auch verwirrend.

Nun, aber fein ans Übersetzen.