Bis man es geschafft hat eine Feed Datei zu erzeugen, die Google Base ohne wenn und aber akzeptiert, vergeht meist eine ganz erhebliche Zeit. Aber nur weil Google Base jetzt endlich die Artikel eingelesen hat, heißt das noch lange nicht, dass die Daten auch wirklich optimal aufbereitet sind. Das gilt insbesondere im deutschsprachigen Raum, wo Google sich ja überlegt hat, die relevanten Datenstrukturen ins Deutsche zu übersetzen.

Glücklicherweise liefert Google Base dann doch noch ein passendes Werkzeug, auch wenn es eher versteckt ist und bei einem automatischen Import selten zum EInsatz kommt. Verborgen ist dieses ‘Juwel’ sowohl auf der Seite “Aktive Artikel” als auch auf der Seite “Inaktive Artikel”, versteckt hinter dem Punkt “Bearbeiten…”. Wechselt man hier auf die “Artikel bearbeiten” Seite, so zeigt einem Google Base den jeweiligen Artikel an.

Dabei heißt es jetzt genau hinzuschauen: Felder die von Google Base bei Import als “bekannte Attribute” erkannt wurden, werden unveränderlich angezeigt. Felder bei denen man den Namen in der Maske verändern kann wurden von Google Base als “Custom Attribute”, also als vom Benutzer beliebig zu definierendes Attribut erkannt. Es ist wohl selbstredend, dass solche Felder in der Relevanz hinter den “bekannten Attributen” zurückstehen.

Als Beispiel soll hier das früher verwendete Attribut ‘description’ dienen, welches ja heute ‘g:beschreibung’ heißt. Sollte die Maske ein Eingabefeld mit dem Text “description” enthalten, so ist diese Attribut z.B. nicht optimal exportiert, denn die Beschreibung sollte eigentlich unter “Beschreibung” erscheinen.

Die meisten Leute machen sich sicherlich keine Gedanken darüber, woher die Daten kommen, wenn ihnen bei einer Google-Suche auch Produkte mit dazugehörigen Preisen angeboten werden. Die Antwort darauf heißt Google Base. Nun scheinen die Entwickler von Google Base jedoch ein etwas seltsames Völkchen zu sein, wie wäre sonst folgendes zu erklären?

Google Base ist ein Produkt das weltweit Betreibern von eCommerce Systemen zur Verfügung steht. Als Schnittstelle dient ein Datei-basierter Datenabgleich der entweder CSV Dateien oder eben auch RSS-basierte XML Dateien erwartet. Nun haben sich die Jungs von Google gerade bei letzterem etwas sehr Interessants ausgedacht: sie haben die XML Tags lokalisiert, d.h. XML Elemente die im englischen Original noch <g:price> heissen müssen für einen deutschen Shop auf <g:preis> geändert werden. Das erschwert nicht nur die Entwickling von Modulen die überall eingesetzt werden können, es scheint auch die Google Entwickler etwas zu verwirren. Schließlich definiert das RSS Format bereits einige Elemente, diese jedoch auf Englisch. Ein entsprechnder Block für einen Artikel sah also bis vor kurzem so aus:

<item>
    <id>123</id>
    <title>Mein Arikel</title>
    <g:preis>1.95</g:preis>
</item>

Seit rund zwei Wochen funktioniert das so jedoch nicht mehr, der Import solcher Dateien schlug einfach fehl und Google hüllte sich in Schweigen. Zum Glück wurde aber mittlerweile herausgefunden, wie man das Problem lösen kann. Ich denke der Mitstreiter aus dem Google Base Forum hat sicherlich einige Zeit gebraucht um die folgende Lösung des Problems zu finden:

<item>
    <id>123</id>
    <title>Mein Arikel</title>
    <c:titel>Mein Arikel</c:titel>
    <g:preis>1.95</g:preis>
</item>

Der Trick ist das Hinzufügen von <c:titel>, also der deutschsprachigen Variante des Titels. Bei dem “c” Namespace handelt es sich eigentlich um den Namespace für “Custom Attribute”, also solche Felder die vom Betreiber der eCommerce Seite definiert werden können. Mir scheint als wäre das Einlesen der Daten auf Google Base somit a) nicht Namespace fähig und b) erschreckend wenig robust und ungetestet.

Moral von der Geschichte: Lokalisierung von Datenformat ist mindestens genauso unsinnig wie der Übersetzung von Programmiersprachen.

(Update: Ein paar weitere Tipps gibt es noch in meinem Post “Importierte Google Base Feeds überprüfen”)