I18N, L10N …? Ein Interview mit Marcel Becker

I18N und L10N sind nicht etwa Codenamen für geheime Flugzeuge, sondern Kurzformen für Prinzipien im Software-Design. I18N steht für „Internationalization“ („I“, 18 Buchstaben, „N“), „L10N“ für „Localization („L“, 10 Buchstaben, „N“). Der AOL Usability Newsletter sprach mit Marcel Becker, bei AOL LLC als Technical Manager International Portal & Products.

Michael Hatscher (MH): Marcel, beschreib uns doch bitte kurz Deine neue Tätigkeit.

Marcel Becker (MB): Ich habe zwei große Aufgaben: die Internationalisierung von Produkten und die technische Leitung der internationalen Portalentwicklung. Die beiden Tätigkeiten lassen sich nicht klar voneinander abgrenzen und gehen Hand in Hand. Bei der Internationalisierung geht es darum, die Teams dazu zu bringen, dass sie Client- und Backend-Produkte so bauen, dass sie lokalisierbar sind, d.h. in die jeweiligen Landessprachen (und dazugehörigen Schriften) übersetzbar sind. Beim Portal ergibt sich die zusätzliche Aufgabe, im neuen Publishing-System dafür zu sorgen, dass es möglichst für alle Länder eingesetzt werden kann, und seien es nur Komponenten des Systems für kleinere Portale. Zusätzlich bin ich Dev Lead und führe andere Dev Leads und Architekten, die dann die eigentliche Entwicklungsarbeit koordinieren.

MH: Welche besonderen Herausforderungen siehst Du in Deiner neuen Aufgabe auf Dich zukommen?

MB: Die größte Hürde dürfte darin liegen, bei den Kollegen in den USA die Awareness dafür zu schaffen, dass sie nicht nur für ihren lokalen Markt entwickeln, sondern für die ganze Welt. Dieses Bewusstsein ist noch nicht in allen Teams angekommen. Es geht darum, ein Grundverständnis zu schaffen und Mitarbeiter schnell auf das Thema aufmerksam zu machen. Also eine klassische Evangelisten-Tätigkeit.
Angehen werde ich das Thema zunächst über Dokumentation und Checklisten. Gemeinsam mit den Kollegen in Dublin habe ich hier schon die erste Version einer Checkliste definiert. Außerdem dokumentieren wir in einem Wiki das Vorgehen und worauf man achten muss. Die erste Version der Checkliste ist auch bereits online.
In Mountain View haben wir auch schon ein erstes Survey durchgeführt – wir haben die Kollegen nach einer eigenen Einschätzung und nach ihrem Verständnis bezüglich Internationalisierung gefragt, um einen ersten Eindruck und Status zu bekommen und um Defizite aufzudecken. Das Feedback aus dem Survey werden wir nutzen, um das Survey und die Dokumentation weiterzuentwickeln. Dieses soll dann in die Software-Pflichtprozesse eingebunden werden, die die diversen Review-Boards nutzen.
Es handelt sich bei meiner Stelle um eine neue Position – bislang war diese Aufgabe verstreut auf verschiedene Teile der Organisation (z.B. auf das Team in Dublin, das aber immer nur produktbezogen Feedback geben konnte und am Ende des Entwicklungsprozesses stand). Aufgehängt ist die Stelle im Bereich Audience Technology; ich berichte direkt an den VP Lu Lu.

MH: Worauf muss man besonders achten, wenn man Produkte für eine internationale Audience gestaltet?

MB: Das wichtigste überhaupt ist, die Applikations- und die Präsentationsschicht voneinander zu trennen. Das ist nicht nur wichtig für I18N, sondern insgesamt für Wartung, um eine höhere Flexibilität zu bekommen etc. Auf dem Präsentationlayer wiederum sollten Inhalt und Gestaltung getrennt sein, also Strings, Konfiguration, Verhalten, Inhalte. Dieser modulare Ansatz ermöglicht es, Anwendungen schneller und flexibler zu bauen. Zum Beispiel kann man so Komponenten ausschalten, wenn man sie nicht benötigt, ohne eine neue Anwendung bauen zu müssen.
Sinnvoller Weise muss jede Funktion diesem Prinzip folgen – sie müssen konfigurierbar sein, die gleiche Präsentationsschicht nutzen etc. Nur dann kann man die Vorteile, die in diesem Ansatz liegen, voll ausschöpfen.

MH: Gibt es Tools oder Prozesse, mit denen Du gute Erfahrungen gemacht hast?

MB: Bei I18N und L10N geht es mehr um ein Prinzip, um eine Haltung, die die Entwicklungsweise bestimmt. Es ist wichtig, dass sich die Entwicklung an etablierte Standards hält. Wenn man an Legacy- oder Nicht-Standard-Ansätzen festhält, muss man sich darüber im Klaren sein, dass man einen Tradeoff eingeht: Man muss dann später Zeit einsetzen, um auf die älteren Systeme Schnittstellen zu bauen, die es dann wieder ermöglichen, mit Standard-Systemen darauf zuzugreifen.

MH: Hast Du noch Empfehlungen für Interessierte, wo diese sich weitere Informationen besorgen können?

MB: Ja – es gibt ein sehr gutes Buch von Microsoft: „Developing International Software“ von Nadine Kano (ISBN 1556158408). Außerdem noch „Programming for the world“ von Sandra Martin (ISBN 0137221908). Darüber hinaus hat Apple die I18N Guidelines offengelegt, in denen nahezu alles ausführlich dokumentiert ist.

MH: Marcel, vielen Dank für das Gespräch und viel Spaß und Erfolg in der neuen Rolle.