Mario Ruckh von Kindo, selbst mit Webservice in 17 Sprachen online gegangen. Kindo ist privates soziales Netzwerk, mit Geburtstagen, Fotos, Status, Microblogging usw. für Familien. Stammbäume vom Stars/berühmten Personen wurden öffentlich gemacht. Nicht um Familie kennen zu lernen, sondern für Kontakt von bestehenden Beziehungen/weiter entfernte Verwandte. Mittlerweile übernommen von myHeritage, Stammbaum der Welt. eCommerce-Empfehlungen um Geld zu verdienen z.B. bei Geburtstagen, Hochzeitstagen etc. um Geschenke zu verschicken.

Karte mit Ländergröße nach Internetnutzer, Potentiale der Zukunft sind nicht im nicht-englisch Englischen Sprachenraum, Spanisch und Chinesisch 56% der Weltbevölkerung. Insbesondere für Nischenprodukte sind größere Märkte interessant, je spezieller desto wichtiger ist Internationalisierung. Die technischen Möglichkeiten sind auch schon weit fortgeschritten, fertige Module sind vorhanden. Wenn man selber keine anderen Sprachen anbietet, können andere Services sich in anderen Sprachen etablieren - Wettbewerb.

In Europa wird viel schneller internationalisiert als in den USA weil die Märkte kleiner sind, Internationalisierung ist eine Stärke der europäischen Märkte/Unternehmen.

Herangehensweise: ausprobieren, unterschiedliche Aufnahme testen. Internationalisierung ist einfach und skaliert, deshalb kann man gut ausprobieren. Übersetzer suchen und diese machen ein wenig Werbung, in wichtigen Ländern intensiver Werbung machen.

Nur Sprache oder auch verschiedene Kulturen abbilden, also lokalisieren? Gibt es unterschiedliche Einstellungen z.B. zum Produkt, bei Familiennetzwerk unterschiedliche Verhältnisse zur Familie in unterschiedlichen Kulturen. Schwerpunktmäßig finden von lokalen Partnern oder Partnern, die selbst international sind.

Community-Based Internationalization - Crowdsourcing, bei FaceBook inline Übersetzen - Text anklicken, deutsche Übersetzung eintragen z.B.. In einem halben Jahr 30-50 Sprachen. Mehrstufiger Prozess, jeder kann Übersetzung vorschlagen, dann Bewertung durch die Community, nach Aktivität wird die Übersetzung eingefroren. Am Ende noch einmal redaktionell darüber schauen.

Neue Features eventuell immer erst in allen Sprachen fertig machen?

Plattform für Community-Übersetzungen: transifex.org - freie Software, auch hosted, programmiersprachenneutral. Übesetzerteam, wahlweise auch online, landet in Software oder Website etc.. Python und diverse Script-Sprachen um die Versionskontrollsysteme einzubinden. Standardsätze werden bereits vorgeschlagen.

Usergenerated Content muss eventuell auch internationalisiert werden, bei Kindo weniger Problem, da Familienintern.

Team-Mitglieder übersetzen eventuell besser als Agenturen, da diese besser den Geist der Seite mit Übersetzen können. Agenturen übersetzen weniger frei, finden nicht Entsprechungen, sondern Übersetzungen. Tonalität kann damit eventuell besser herübergebracht werden.

• Von Rechts nach Links schreiben
• Skalierungsprobleme
• AGBs? Anwalt in jedem Land? Eventuell ist es kleinen Unternehmen nicht zumutbar, Lokalisierung von AGBs vorzunehmen. Kommt auch auf Markt an, für den die Seite bestimmt ist, Standort der Daten, Sitz der Organisation
• Länderkürzel - 2- oder 3stellig oder 5stellig - Dialekte werden abgebildet?
• Kulturelle Unterschiede bei der Zusammenarbeit
• bei eCommerce Währung, Zahlungsmethoden
• Länder mit mehreren Sprachen
• Benutzereinstellungen im Browser für Sprachen verwenden
• Anzeige von Kalender - welcher Tag ist links?
• Layoutprobleme wegen Wortlänge, mit einplanen beim Layout
• Pluralformen

Tobias Günther von www.puremedia-online.de spricht über offline-Applikationen im Web-Bereich.

Web-Applikationen können im Vergleich zu Desktop-Applikationen nur online genutzt werden, es sei denn jetzt: Offline-fähige Desktopapplikationen - Offline schließt eine der letzten Lücken zum Desktop!

Komplette statische Seiten können einfach gespeichert werden, Applikationen nicht so einfach, da Datenquelle nötig ist. Sinnvoll für wackelige/instable Verbindungen, aber auch unterwegs, im Flugzeug, beim Kunden… Nicht jede Web-Applikation muss offline-fähig sein. Auch Performance kann ein Kriterium sein.

Beispiele: Google Reader, GearPad, Remember The Milk, Google Docs, Mail Client, CRM, Projektmanagement-Tools, Kalender…

Das Problem ist nicht neu, es gab Dojo Storage, Derby/JavaDB, Zimbra (Derby-based). Heute: Adobe AIR (früher: Apollo), Joyent Slingshot, Apple iPone, Google Gears, Google Gears Mobile.

Adobe AIR: Wirklich eigene offline-Anwendungen in eigener Runtime (muss jeweils installiert werden), damit echte Applikationen ohne Browser. Entwicklung in Flash/Flex oder HTML/Javascript. Vorteile: Zugriff auf Systemresourcen, Taskbar, Autostart…

Joyent Slingshot (Ruby on Rails) - einheitliche und gewohnte Entwicklungsplattform, ansonsten wie Adobe AIR.

Apple iPhone - JavaScript-API (Webkit/HTML5 Spec) - mit Datenbank, Transaktionen…

Weitere/Bald: Mozilla Prism, Microsoft Silverlight (mobile Endgeräte, dann offline-Support), Webkit (Safari) und Firefox 3 eigene Schichten, HTML5 Working Draft WHATWG - “Client-side database storage”

Ist ein Browser-Plugin für Firefox und Internet Explorer, vermutlich bald auch in Opera und Safari. Google Gears ist OpenSource. Motivation von Google Gears ist, dass Google Apps offline nutzbar ist. Ziel: single industry standard, in allen Browsern verfügbar mit einheitlicher API.

Benötigt insgesamt keine echte Installation, kann schnell installiert werden, niedrige Hürde. Alles bleibt bei Google Gears im Browser, alles ist gleich. Auch bei der Entwicklung werden Standardtechnologien eingesetzt, nur JavaScript ist ein wenig erweitert. Schwerpunkt ist die offline-Nutzung, aber keine sonstige Erweiterung der Browser-Funktionalität.

Google Gears besteht aus drei Komponenten, einem LocalServer (eine Art Webserver), eine Datenbank (SQLite) sowie ein Workerpool für Hintergrundprozesse (ein threading-Modell für JavaScript).

Liefert definierte Ressourcen aus einem lokalen Cache aus, egal ob offline oder online. Es gibt eine Variante, die automatisch aktualisert, bei einer anderen muss man manuell aktualisieren. Resourcen müssen definiert werden im JSON-Format.

Echte Datenbank mit allen Features, auch mehrere Datenbanken nutzbar. Sandbox-Modell, d.h. man kann nur auf die eigene Datenbank zugreifen. Nichts neues, aber gut.

Für ressourcenhungrige Prozesse, das Benutzerinterface bleibt benutzbar. Man kann allerdings nicht auf das DOM zugreifen. Einsatzbereich: Synchronisation, auch für online-Applikationen interessant.

Seit 2-3 Monaten auch mobil (Windows Mobile 5&6) nutzbar, exakt gleich wie auf dem Desktop, aber das Gerät hat natürlich Einschränkungen. Mittlerweile gibt es relativ gute Browser auf mobilen Endgeräten, damit können Web-Technologien genutzt werden.

Mobile Applikationen sind oft offline, Performance nicht so groß, große Datenmengen sind schwierig, Gears hilft, um die wiederholte Übertragung großer Datenmengen zu vermeiden.

Desktop-API: Shortcut Icon, fortsetzbare Uploads, GeoLocation API, noch nicht: ImageManipulation API, Audio API, …

Hängt von der Anwendung/Philosophie ab. Adobe AIR eher auf den Desktop konzentriert, erfordert aber eine aufwändige Installation, während Google Gears auf den Browser konzentriert ist und eine einfache Installation bietet. AIR bietet eine sehr reichhaltige Umgebung, ist aber closed source, während Google Gears weniger Funktionen bietet, aber Open Source.

Standard: Dojo offline gibt es, Synchronisation ist aber unglaublich individuell, keine fertige Strategie, bleibt dem Entwickler überlassen.