Deutsche Microsoft-Knowledge-Base considered harmful

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Wed, 08 Oct 2008 07:42:56 +0200

Seit einigen Monaten landet man (von einer deutschen IP-Adresse?) bei der Microsoft-Knowledge-Base auf deutschsprachigen Artikeln. Einige davon sind tatsächlich von einem Menschen übersetzt (wie sie schon seit Jahren optional zur Verfügung stehen), die meisten davon allerdings maschinell.

Vor den maschinell übersetzten Artikeln möchte ich gerne eine eindringliche Warnung aussprechen, denn abgesehen von ihrer Unverständlichkeit führen sie Dich in die Irre.

Microsoft benutzt für die maschinelle Übersetzung einen Babelfish, dessen Übersetzungen in etwa so schlecht sind wie die von Altavistas Babelfish im Jahr 2002. Schon alleine deswegen sind sie also nicht brauchbar. Deswegen klicke ich in der Microsoft-Knowledge-Base eigentlich immer sofort auf den “US English” Button, weil mir das Automatendeutsch einfach zu sehr weh tut. So tat ich das auch neulich.

$KUNDE trennt gerade auf mein Anraten hin seine Clients von seinen Servern, zieht die Clients in ein neues, größeres IP-Netz und hat zwischen Clients und Servern eine (von mir) restriktiv konfigurierte Firewall. Leider benutzt er Exchange, was ja bekanntlich eine von Microsoft “umarmte und erweiterte” RPC-Version benutzt. Diese Umarmung führt dazu, dass die RPC-Connection-Tracking-Module der Firewall nicht greifen, und da ich mich weigere in Abwesenheit dringender Notwendigkeit Allow-Regeln für alle Ports oberhal 1024 zu konfigurieren mussten wir nach jedem Restart des Exchange die Firewall anpassen um den Port freizugeben den der Exchange diese Woche benutzt.

Das ist natürlich auf die Dauer nicht machbar, und so beschäftigte ich mich vor ein paar Wochen mit der Microsoft Knowledge Base und stoße die Exchanger des Kunden auf den Artikel mit der Nummer 154596. Dort sind ein paar Registryeinträge beschrieben, die man setzen muss, um Exchange 2003 dazu zu bringen, sich bei der Auswahl des Ports für seine RPC-Dienste auf einen kleineren Range zu beschränken. Die Exchanger sind kooperativ und setzen die dort genannten Anregungen um.

Aber es funktioniert nicht. Exchange würfelt seine Ports nach wie vor wild aus dem ganzen oberen Bereich. Nach einiger Diskussion lasse ich mir mal von dem zuständigen Exchanger zeigen, was er denn da gemacht hat.

Und das “J” als Wert für den Registry-Key “PortsInternetAvailable” kommt mir dann doch spanisch vor. Aber im mir vom zuständigen Exchange gezeigten Artikel der Microsoft Knowledge-Base steht das wirklich so. Mir kommt ein Verdacht, und ich klicke auf dem Browser des Exchangers auf “US Englisch”, wie ich es immer tue.

Und, genau. Dort steht, dass man den Registry-Key auf “Y” setzen soll.

Einen Reboot später steht fest, dass “Y” auch korrekt ist und der Exchange-Server die Einstellung jetzt auch berücksichtigt.

Einen ähnlichen Klops hat Microsoft vor zehn Jahren schonmal geschossen, als sie die Macrosprache von Excel übersetzt haben und deswegen plötzlich weder Macros von älteren Excelversionen mehr ausführbar waren, noch eine Portabilität von Macros zwischen verschiedensprachigen Excels bestand. Aber damals war das wenigstens offensichtlich. Diesmal war die Geschichte nicht so ganz offensichtlich, weil sie die Namen der Registry-Keys nämlich auch im Deutschen Knowledge-Base-Artikel auf Englisch stehen gelassen haben - sie haben nur die Values, nicht die Keys selbst übersetzt. Das ist schon advanced Irreführung.

Lerninhalt: Deutsche Übersetzungen von IT-Texten sind harmful und gefährlich und gehören verboten. Und ich spreche nachher mal mit dem QM-Beauftragten des Kunden.

Leider hat Microsoft die “War dieser Artikel hilfreich”-Frage am Ende der Knowledge-Base-Artikel abgeschafft. Haben wohl zu viele Leute auf “Nein” geklickt. Wie ich es auch getan hätte, wenn ich noch könnte.

Warum ich Formulare liebe

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Wed, 26 Oct 2005 11:39:35 +0200

Von der Herausforderung, einen Päckchenaufkleber auszufülen

Für Päckchen braucht man - natürlich - ein anderes Formular als für Pakete. Sieht zwar ähnlich aus, ist aber im Detail anders.

Für das Paketformular gibt es auf deutschepost.de eine Ausfüllhilfe. Das ist eine Windows-Applikation, die - natürlich - alle Grundsätze der Softwareentwicklung unter Windows missachtet und zum Beispiel Benutzer B verrät, was für Pakete Benutzer A beschriftet hat.

Für das Päckchenformular gibt es eine solche Ausfüllhilfe nicht. Also probiert man es mit der Paketsoftware.

Das klappt auch ausgezeichnet, die Felder sitzen an derselben Stelle.

Nur leider, ist das Päckchenformular nur “ein drittel A4” und als solches nicht hoch genug für den Laserjet 4050. Das perfekt bedruckte Papier bleibt zwischen Belichter und Fixierer im Drucker hängen, und man kann den Ausdruck grad wieder so vom Formular runterwischen. Mist!

Nächster Versuch: Landscapedruck. Da landet der Ausdruck auf einem A4-Bereich in der unteren rechten Ecke, so dass ein zeitraubendes Ausmessen und Spielen mit den Randeinstellungen nötig wird.

Fazit: Hätte man doch lieber gleich Office genommen. Formular mit der Hand ausgefüllt.

Immer noch gewünscht: Eine allgemein nutzbare Formularausfüll-Software, bei der man das Formular einscanned und es dann maßstabsgerecht als Hintergrund einer Textverarbeitung mit frei positionierbaren Eingabefeldern angezeigt bekommt. Und dann nur das, was man getippt hat, ins Formular ausdrucken kann.

Zugschlusbeobachtungen - non-free software

Deutsche Microsoft-Knowledge-Base considered harmful

Warum ich Formulare liebe