Manchmal bin ich pingelig und mich stört so etwas auch. Logindaten egal welcher Art haben in Links und anderen öffentlich zugänglichen Bereichen einfach nichts zu suchen. Das widerspricht auch der Idee das man neben den Login-Namen auch noch zwei andere Namen in seinem Profil angeben kann und auswählen kann welchen Namen man gerne öffentlich verwenden möchte.

Der Workaround

Um das Problem zu lösen gibt es einen Workaround und eine Möglichkeit mit Filtern zu arbeiten. Zuerst der Workaround. WordPress bietet nämlich die Möglichkeit für jeden Autoren eine eigene Autoren-Seite anzulegen. Dieses Template wird zuerst gezogen bevor das allgemeine Template für alle anderen Autoren verwendet wird. Anders ausgedrückt: Existiert für den Autor X ein spezielles Template, wird dieses verwendet. Existiert kein solches Template, dann wird das allgemeine Template verwendet.
Dabei sucht WordPress in folgender Reihenfolge nach einem passenden Template:

1. author-{autor-name}.php
2. author-{autor-ID}.php
3. author.php

Ist der Login-Name des Autoren z.B. “Klaus” und existiert ein Template author-klaus.php, wird zuerst dieses Template verwendet. Dies hilft uns in diesem Fall jedoch nicht weiter, da weiterhin der Login-Name verwendet wird.
Jedoch kann man auch die ID des Autoren verwenden. Existiert ein Template author-12.php und hat der Autor “Klaus” die ID 12, dann wird dieses Template verwendet. Ändert noch nichts daran das im Link immer noch der Login-Name erscheint.
Um dies zu ändern, greift man in das Template ein in dem die Funktion get_author_posts_url() verwendet wird. Das ist von Theme zu Theme leider immer etwas unterschiedlich, je nach dem wo die Metadaten zum Post ausgegeben werden. Diesen Funktionsaufruf ersetzt man nun mit diesem Monster:

str_replace(
  get_the_author_meta( 'user_nicename' ),
  get_the_author_meta( 'ID' ),
  get_author_posts_url( get_the_author_meta( 'ID' ) )
)

Damit ersetzt man den Login-Namen (user_nicename) durch die ID des Autoren. Nun benötigt man noch ein Template author-xy.php wobei xy die jeweilige ID des Autoren ist.

Das ganze ist ein Workaround der nur sehr begrenzt einsatzfähig ist. Man muss jedes mal am Theme rumfummeln, die ganze Sache ist nicht wirklich übersichtlich und am Ende benötigt man auch noch für jeden Autoren ein eigenes Template. Eignet sich also normalerweise nur für Blogs in denen es 1-2 Autoren gibt und die eher selten ihr Theme wechseln.

Im Grunde genommen bedeutet hier aber, dass es nur auf den ersten Blick so einfach zu sein scheint. Wer sich schon mal mit den Thema Übersetzung von Plugins oder Themes beschäftigt hat, der wird früher oder später die vielen kleinen Haken zu spüren bekommen. Einer dieser kleinen Haken ist der, dass WordPress einen grundlegenden Unterschied bei der Einbindung von Übersetzungen macht. load_theme_textdomain() ist, wie der Name vermuten lässt, für Themes zuständig, während load_plugin_textdomain() für Plugins zuständig ist. Es ist schon mal auffällig das es für die gleiche Aufgabe zwei verschiedene Funktionen gibt. Also schauen wir doch mal in die Core-Datei wo der Unterschied bei diesen beiden Funktionen liegt.

Beide Funktionen finden wir in wp-includes/l10n.php. Beide Funktionen erwarten bei ihren Aufruf die Übergabe einer Domain und eines Pfades. Im Falle von load_plugin_textdomain() können sogar zwei verschiedenen Arten von Pfaden angegeben werden, wobei der absolute relative Pfad veraltet ist und nicht mehr verwendet werden sollte.
Bei genauerer Betrachtung fällt aber auf, dass load_theme_textdomain() bei der Pfadangabe deutlich toleranter ist als load_plugin_textdomain(). Ist kein Pafd angegeben, so verwendet load_theme_textdomain() das Verzeichnis des aktuellen Templates als Pfad. Ansonsten könnte man den Pfad auch sonstwohin zeigen lassen, es würde noch funktionieren.
load_plugin_textdomain() ist da etwas strikter. Egal ob man einen Pfad angibt oder nicht, es wird auf jeden Fall WP_PLUGIN_DIR, also der Pfad zum Plugin-Verzeichnis, im Pfad eingefügt.
Mit load_theme_textdomain() könnte man also auch eine Sprachdatei benutzen die in wp-content steht. Mit load_plugin_textdomain() wäre dies unmöglich.

Nun sind Pfadangaben in WordPress eine Sache für sich an die man sich gewöhnen und mit denen man umzugehen lernen kann. Deutlich mehr Kopfschmerzen bereitete mir in der Vergangenheit ein Umstand, den ich irgendwie nicht verstehe. Und zwar das Format nach dem die Sprachdateien benannt werden müssen.
load_theme_textdomain() erwartet das die Sprachdatei lediglich aus der Locale und der Endung .mo besteht. Also z.B. de_DE.mo oder en_EN.mo. load_plugin_textdomain() hingegen erwartet zu der Locale noch zusätzlich die Domaine als Teil des Dateinamens. Die Datei muss also das Format domain-locale.mo haben.
Für mich recht unverständlich und letzten Endes kann dies auch zu Problemen führen. Denn ändert sich im Plugin die Domaine, z.B. nach einem Update, dann können auch die (alten) Sprachdateien nicht mehr geladen werden. Man müsste also entweder alle Domainen im Plugin ändern oder alle Sprachdateien umbennenen.

Aber man sollte auch immer die Vorteile im Auge behalten. Durch die Verwendung der Domaine im Dateinamen der Sprachdatei kann man auf recht einfache Weise z.B. zwischen der Du- und der Sie-Form wechseln. Etwas was für deutsche Übersetzungen ja nicht ganz unerheblich ist.
Dazu legt man einfach z.B. eine Sprachdatei mit den Namen pluginname_du_form-de_DE.mo und eine mit den Dateinamen pluginname_sie_form-de_DE.mo an. Im Plugin selber kann man mittels define('MeinePluginDomain', 'plugin_xx_form'); eine Konstante definieren die dann in den Übersetzungsfunktionen verwendet wird (z.B. __('This example text', MeinePluginDomain)). Je nachdem ob xx nun ‘du’ oder ‘sie’ ist, schaltet man zwischen Du- und Sie-Form um.

Jetzt hat man aber ein Problem mit Sprachen die nicht zwischen Du und Sie unterscheiden. Mit Englisch zum Beispiel. Denn man müsste nun für jede Sprache zwei Sprachdateien anfertigen. Einmal plugin_du_form-en_EN.mo und einmal plugin_sie_form-en_EN.mo.
Das ganze gestaltet sich an diesen Punkt als etwas zu aufwendig um schön zu sein. Es gibt aber auch eine Lösung für das Problem. Wir benötigen ja eigentlich nur eine Funktion die in einem Verzeichnis nachschaut ob es eine Sprachdatei nach dem Format domaine-locale.mo gibt und diese lädt. Gibt es eine solche Sprachdatei nicht, wird halt eine Sprachdatei nach den Format locale.mo geladen. Gibt es diese auch nicht, wird halt nichts übersetzt.
Nebenbei erledigt sich mit solch einer Funktion das leidige Pfad-Problem. Die Sprachdateien können nun quasi an einen beliebigen Ort abgelegt werden. Ob dies Sinn macht, sei an dieser Stelle mal dahin gestellt.

Hier erst einmal die Funktion:

function flexible_loadtextdomain( $path = false, $domain = 'default' ){

  if( ! $path || ! is_dir( $path ) )

    return false;

  global $l10n;

  $local = get_locale();

  $mofile = $path . $domain . '-' . $local . '.mo';

  // try to find a matching translation

  // first try domain-locale.mo

    if( ! file_exists( $mofile ) ){

    // if not found, try only locale.mo

    $mofile = str_replace( $domain . '-', '', $mofile );

      if( ! file_exists( $mofile ) ){

        // if even this failed, throw an error or do something wired

        return false;

      }

    }

  load_textdomain( $domain, $mofile );

  return isset( $l10n[ $domain ] );

}

Die Funktion erwartet zwei Parameter. Zum einen eine Pfadangabe und zum anderen den Namen der Domain. Die erste If-Abfrage sorgt dafür das überhaupt ein Pfad übergeben wird und das es auch ein Verzeichnis ist. Anstatt einfach nur false zurück zu geben, kann man hier natürlich noch weitere Spielereien unter bringen indem man z.B. einen Pfad vorgibt (WP_PLUGIN_DIR oder get_template_directory).
Der Rest ist das was ich oben schon beschrieben habe. Erst domain-locale.mo suchen, wenn nicht gefunden locale.mo suchen, wenn das auch nicht gefunden irgendwas verrücktes machen, zum Beispiel false zurück geben.
In der letzten Zeile wird dann noch geprüft ob die Domain erfolgreich geladen wurde. Ab WP 3.0 kann man dies durch return load_textdomain(...) abkürzen. In älteren Versionen muss man diesen kleinen Umweg gehen da load_textdomain keine Erfolgsmeldung zurück gibt.

Der Code der Funktion ist ein wenig abgespeckt. Will man es ganz sauber programmieren, dann würde man noch ein paar Sachen anders machen, z.B. nicht $locale = get_locale(); verwenden, sondern $locale = apply_filters( 'xyz', get_locale(), $domain ); (xyz = theme_locale oder plugin_locale, je nachdem ob man die Funktion in einem Theme oder Plugin verwendet).

Vielleicht ist dieser Beitrag ja eine kleine Anregung für alle die Themes oder Plugins schreiben.

Der Codex schweigt sich allerdings ein wenig darüber aus wie man es hin bekommt den ersten Menüpunkt anders zu benennen. Anscheinend gibt es auch keinen “offiziellen” Weg um dies zu bewerkstelligen. Mit einen kleinen Kniff geht es dennoch.
Dazu muss man die Variable $submenu global verfügbar machen und kann dann darüber seine Menüpunkte beeinflussen:

global $submenu;
add_menu_page( $page_title, $menu_title, $capability, $menu_slug, [...] );
$submenu[$menu_slug][0][0] = 'My first Menuoption';

$submenu ist ein Array in dem verschiedene Informationen über das Menü gespeichert sind. Es lohnt sich dieses Array mal ausgeben zu lassen und zu schauen welche Informationen man darin findet.

In Bezug auf die Menüs ist $menu ein weiteres interessantes Array. Bei der Masse an Plugins die im Umlauf sind, kommt es nicht selten vor das auch dementsprechend viele Plugins ein zusätzliches Menü einrichten. Da möchte man vielleicht sein eigenes Menü ein wenig von den anderen abgrenzen. Nichts leichter als das, sogar mit Zusatzwert. Man fügt einfach einen Menü-Seperator ein:

global $menu;
$menu[] = array( '', 'read', '', '', 'wp-menu-separator' );

Damit wird ein Seperator eingefügt mit dem man die Menüleiste auf- und zuklappen kann. Steht der Code vor add_menu_page(), wird der Seperator vor dem eigenen Menü eingefügt. Steht er dahinter, wird der Seperator dementsprechend dahinter eingefügt.
Mit count($menü) lässt sich recht einfach feststellen wie viele Menüs bereits existieren und ggf. ein Seperator einfügen. Allerdings werden auch sämtliche bereits vorhandenen Seperatoren mitgezählt, dies sollte man beachten und diese ggf. raus rechnen.
Mit 'wp-menu-separator-last' erzeugt man übrigens einen “leeren” Seperator, also einen Seperator ohne Pfeil wie am Ende des Standard-Menüs von WordPress zu finden ist.