Problemy z lokalizacją

Metoda CultureInfo.GetCultures() nie zwraca kilku języków. Jak dotąd okazało się, że nie zwraca języka hawajskiego (którego używa 2000 osób) oraz amharskiego (którego używa 34-42 mln ludzi). O ile w pierwszym przypadku można to jakoś zrozumieć, brak wylistowania amharskiego przy takiej dużej populacji osób w nim rozmawiających wydaje się podejrzany podczas gdy język Zulu wspierany jest listowany, chociaż rozmawia w nim zaledwie 35 mln ludzi.

Idąc dalej tym tropem można sprawdzić ustawienia regionalne i dowiedzieć się, że i tam te języki nie występują ani jeżeli chodzi o standardy, ani w ustawieniach klawiatury. Jedyne miejsce gdzie istnieje opcja lokalna to wybór kraju - można wybrać Etopię, czyli kraj w którym się głównie używa języka amharskiego.

Wygląda na to więc, że Windows XP nie uwzględnia języka kraju, który ma przeszło 50 uniwersytetów i koledżów. Więcej o rozwoju technologicznym tego kraju, który napisał własny system operacyjny można przeczytać tutaj:

http://www.unu.edu/unupress/unupbooks/uu19ie/uu19ie0b.htm

Drugi, już mniejszy błąd polega na tym, że w liście prezentowanej przez GetCultures() język białoruski jest w złym rodzaju. Ponieważ “język” w języku białoruskim jest w rodzaju żeńskim, to nazwa języka białoruskiego w języku białoruskim też powinna być w rodzaju żeńskim, a nie jest. Jest w rodzaju męskim. Poprawna forma to: ??????????. Ten sam błąd dotyczy pozycji: Białoruski (Białoruś).

Czytelność kodu

Przeglądając strony o programowaniu trafiłem na taką ciekawą stronę, gdzie autor Ramarao Kanneganti opowiada jak pisać czytelny kod, który każdy inny może przeczytać i zrozumieć łatwo:

http://www.kanneganti.com/technical/readable-code

A może podejść odwrotnie do tematu i znaleźć takie sposoby pisania kodu których trzeba unikać?

Dla mnie podejrzane są na przykład takie konstrukcje:

albo:

Takie warunki ciągnące się przez kilka stron kodu powodują, że się robi całkowicie nieczytelny i trudny do utrzymania, modyfikacji.

Tak samo linie kodu, które są dłuższe niż szerokość ekranu.

Albo kod bez komentarzy. W.w. autor postuluje, że komentowanie każdej linii kodu jest bez sensu i z tym się zgadzam. Natomiast np. blok kodu który w gruncie rzeczy robi jedną rzecz już według mnie powinien być opisany, tym bardziej, jeżeli sposób działania tego bloku może być nieczytelny (jak w pierwszym przykładzie kodu).

Czasem programiści postulują też, że podejście obiektowe na tyle zwiększa czytelność kodu, że metody i właściwości publiczne nie wymagają opisu, posuwając się nawet do tego, że wewnętrzne mechanizmy klasy też nie są opisane.

Silverlight vs Flash

Czy Silverlight stanie się konkurencyjny dla Flash? Już od jakiegoś czasu toczy się dyskusja na ten temat. O ile odpowiedzieć na to pytanie jest jeszcze trudno, można przyjrzeć się mocnym i słabym stronom tych produktów, aby ocenić czy nazwa Silverlight jest adekwatna, czy może określenie Silverbulb byłoby lepsze.

Dostępność

Silverlight podobnie jak Flash jest dodatkiem do przeglądarki. Przy czym Flash można używać obecnie pod Windowsem, pod Linuxem, MacOS-em. Pod Solarisem na razie tylko MX 2004. Flash jest obecnie standardem animacji na stronach WWW (około 97% użytkowników Internetu ma zainstalowanego Flasha). Producenci Flasha skupiają się przede wszystkim na kompatybilności z systemami Windows, co może utrudnić rozwój Silverlighta. Z drugiej strony Microsoft może szybko rozpowszechniać SL na platformy Windows przez automatyczne aktualizacje. Tylko w ten sposób nie zdobędzie znaczącej przewagi nad konkurentem, który obsługuje przecież inne systemy. Chociaż twórcy SL zapowiadają wsparcie dla Linuxa na zakończenie prac nad wersjami dla Windowsa i MacOS-a, wydaje się to bardzo odległe. W związku z tym twórcy projektu Mono już zaczęli pracę nad wersją alfa odpowiednika Silverlighta pod nazwą Silvermoon.

Reasumując SL obsługuje obecnie Windows XP SP2 i Vistę, a na nich przeglądarki: IE i Firefoxa, natomiast na MacOs przeglądarkę Firefox i Safari.
Flash obsluguje na Windows XP, Vistę, a na nich przeglądarki: IE, Firefox, Mozilla, Opera i Netscape, pod NT, 95 i 98 obsługuje w.w. przeglądarki też, ale w wersji Flash 7, na Macintoshu też w.w. przeglądarki, na Linuxie wersja 9 obsługuje Mozillę, SeaMonkey i Firefoxa, a na Solarisie Firefoxa w wersji Flasha 7.

Oprogramowanie

Istnieje ogromna grupa programów do tworzenia animacji, gier w technologii Flash i nie są to tylko produkty firmy Adobe i Macromedia. Natomiast chociaż jak deklarują twórcy, SL może być tworzony przez dowolny język programowania oparty o .NET, to na razie do dyspozycji mamy tylko Expression Blend i VS8.0.

Wydajność

Pliki SWF są przesyłane strumieniowo - zanim zostaną w całości ściągnięte z Internetu już są przetwarzane, natomiast Silverlight oparty jest na XML-u. Zanim zostanie uruchomiony musi być ściągnięty w całości i sparsowany, dopiero potem można go renderować.

Alexey Gavrilov przygotował na stronie bubblemark.com prosty test wydajności Flasha i Silverlighta, dzięki któremu każdy może przekonać się, który z nich jest lepszy w czasie działania. Okazuje się, że Silverlight jest wyswietla większą liczbę klatek, ale kosztem o wiele większego zużycia czasu procesora.
Niestety w czasie pisania tego artykułu nie udało mi się skorzystać z w.w. strony (nie chce się załadować). Ale udało mi się znaleźć wyniki porównawcze Silverlighta i Javy. Na komputerze z procesorem Dual Xeon 2.4 GHz Silverlight wyświetla 100 klatek, Java (na Swingu) tylko 64 klatki czyli prawie dwa razy mniej. Jednak Java zużywa 1% czasu procesora, a Silverlight 64%. Odpowiedzią na takie różnice w wydajności ze strony teamu Silverlighta jest wczesna faza projektu, kiedy nie przykładają wagi do wydajności ale do poprawnej implementacji.

Na koniec polecam jeszcze tą stronę, na której google od razu daje nam odpowiedź kto wygra tą bitwę klonów:
http://www.googlefight.com/index.php?lang=en_GB&word1=silverlight&word2=flash

pozdrawiam

Globalizacja aplikacji - nowy kierunek

Od jakiegoś czasu zajmuję się ogólnie pojętą globalizacją. Jako, że jestem programistą moje zainteresowanie skupia się przede wszystkim na tłumaczeniu aplikacji (chociaż nie tylko - zainteresowanych odsyłam do Branżowego Forum Tłumaczy).

Trudno pogodzić jednak nonkonformistyczny postulat mówiący o tym, że każdy program powinien być dostępny w każdym języku, z stanem zaawansowania prac nad tłumaczeniem automatycznym, którego kierunek statystyczny rozwija się dzisiaj dość intensywnie (m.in. Google, BabelFish).

Można przyjąć, że za kilka, kilkanaście lat tłumaczenia automatyczne będą na tyle dobre, żeby móc je stosować do tłumaczenia. Jednak na razie nie jest to dobre rozwiązanie i jedynie może być pomocne do dalszego tłumaczenia ręcznego (opcja taka jest dostępna np. w WordFast).

W jaki sposób zatem przetłumaczyć aplikację na inne języki? Wynająć tłumaczy? Owszem - takie rozwiązanie ma wiele zalet - mamy pewność, że tłumaczenie zostało wykonane profesjonalnie. Ale jakie koszty pociągnełoby tłumaczenie nawet prostej aplikacji na powiedzmy 15-20 najbardziej popularnych języków na świecie?

Większość producentów rezygnuje więc z takiego podejścia i współpracuje z ludźmi chętnymi do tłumaczenia. Są to zazwyczaj użytkownicy, którzy chcą używać programu w swoim języku, albo zrobić to dla swoich znajomych. O ile w Polsce dużo ludzi, w tym szczególnie młodych, zna języki obce - angielski i często też drugi np. niemiecki, francuski, rosyjski. To w innych krajach ludzie nie czują takiej potrzeby nauki obcych języków (odsyłam do innego wątku na blogu, gdzie znajdują się statystyki dot. Europy). W takiej sytuacji potrzeba tłumaczenia aplikacji na inne języki nie jest już tylko kwestią dodatku, “bonusa”, który oferujemy użytkownikowi.

Aplikacje wielojęzykowe świadczą o szacunku autora dla użytkowników z innych krajów. Jeszcze kilka lat temu przewidywano, że dzięki internetowi język angielski stanie się językiem uniwersalnym, teraz można już te poglądy zweryfikować. Internet się lokalizuje, ludzie korzystają z zasobów w ich języku, a dopiero w ostateczności sięgają po obcojęzyczne źródła. Sytuacja ta może dla programistów nie jest tak odczuwalna, ponieważ ten zawód podobnie jak inne zawody informatyczne wręcz wymaga znajomości języka angielskiego (przynajmniej na poziomie czytania dokumentacji, chociaż i to nie zawsze jest prawdą).

Wracając do meritum. Tendencja dzielenia się Internetu względem języka współgra z innymi procesami, które ostatnio zostały nazwane, a istnieją już od dawna. Chodzi między innymi o nurt nazwany szumnie Web 2.0. Społeczności tworzące wspólnie wartość często utożsamiane są z serwisami wideo, z serwisami społecznościowymi. Jednak takie społeczności istniały już wcześniej, chociaż może mniej znane i rozreklamowane: twórcy aplikacji Open Source są jakby prekursorami całego nurtu o którym dzisiaj każdy mówi.

Dlaczego o tym piszę? Globalizacja aplikacji jest nurtem, który może niedługo nabrać nowego znaczenia. Przecież prawie każdy użytkownik komputera znający język angielski jest w stanie przetłumaczyć aplikację w mniejszym lub większym stopniu na swój język.

Zatem co stoi na przeszkodzie, żeby każda aplikacja była przetłumaczona na każdy język?

Wydaje mi się, że przyczyna tkwi w dostępności narzędzi do szybkiego tłumaczenia.
Wyobraźmy sobie taką sytuację: Użytkownik znajduje aplikację, którą chciałby używać w swoim języku. Język ten nie jest dostępny. W takiej sytuacji zgłasza się do autora programu na ochotnika do wykonania tłumaczenia. Proces tłumaczenia w takiej sytuacji może potrwać od kilku dni do nawet kilku miesięcy.

Proces tłumaczenia aplikacji można przyśpieszyć. Można sprawić, żeby wszystkie skomplikowane mechanizmy, na które się składa tłumaczenie aplikacji były dla tłumacza przezroczyste.

Na stronie Polishwords, której adres znajdziecie w linkach na tym blogu postanowiłem wypróbować to podejście. Przyjęte rozwiązanie jest krokiem w kierunku pełnej globalizacji aplikacji.

Obecnie każdy użytkownik może w bardzo prosty sposób włożyć swój wkład w rozwój programu przez przetłumaczenie prostego skryptu na jego język jeżeli nie jest on dostępny. Natomiast jeżeli aplikacja jest już przetłumaczona na jego język dostaje taką informację od razu, w opisie aplikacji. Nie musi ściągać jej i instalować, aby dowiedzieć się tej podstawowej informacji.

pozdrawiam,
Tomasz

Re: Jak zrobić dobre pierwsze wrażenie

Re: Jak zrobić dobre pierwsze wrażenie, czyli:

Jak zrobić dobre ostatnie wrażenie

Poniższe porady są odpowiedzią na film “Jak zrobić dobre pierwsze wrażenie” Dr. Neila Roodyna, który jest dostępny tutaj:
http://channel9.msdn.com/ShowPost.aspx?PostID=299519#299519

Zapraszam do lektury:

1. Długi proces instalacji

Instalator korzysta ze skomplikowanych metod kompresji, które na wolniejszych komputerach powodują wydłużenie procesu do kilkunastu minut, a nawet przeszło godziny.
2. Weryfikacja warunków instalacji

Nic tak nie robi dobrego ostatniego wrażenia jak sprawdzanie warunków instalacji w połączeniu z długim procesem instalacji. Użytkownicy szybko rezygnują z instalacji, która po godzinie pracy informuje, że np. system operacyjny jest zły dla tej wersji instalacji.

3. Geniusz twórcy

Twórcy aplikacji często popełniają błąd nie dając użytkownikowi możliwości nie umieszczania skrótu na pulpicie. Jest to błacha sprawa, ale co jeżeli instalator pozwala zainstalować aplikację tylko w jedyne słuszne miejsce gdzie niestety nie ma miejsca, podczas gdy na innym dysku jest go w nadmiarze?

4. Domyślny folder tymczasowy

Tak, to jest chyba najbardziej uciążliwe, jeżeli instalator najpierw rozpakowuje swoje pliki do jedynego słusznego folderu (najcześciej na dysku systemowym), aby później przenieść je w miejsce docelowe. A co jeżeli użytkownik nie ma na tym dysku miejsca albo praw dostępu?

5. Zbędna integracja

Czy każdy program jest tak ważny, żeby umieszczać go w autostarcie, w pasku systemowym, na pulpicie, w menu start, menu kontekstowym i pasku szybkiego uruchamiania bez zgody użytkownika?

Jeżeli program umożliwia otwieranie określonych plików, powinien wiązać je ze sobą przy każdym uruchomieniu bez zbędnego nękania użytkownika pytaniami.

6. Tajemnicze błędy

Nic tak nie irytuje jak błąd na sam koniec kilkunastominutowej instalacji pt.: “wystąpił błąd”, a jedynym wyborem jest przycisk OK, który wycofuje całą instalację.

7. Odinstalowanie z menu start.

Skoro program jest ważny, to użytkownik niech się namęczy żeby go usunąć! Skrót do odinstalowywania w menu start jest niepotrzebny.

8. Instalator bez opisu

W dobie Internetu można ściągnąć program w dowolnej chwili z dowolnego miejsca. Na stronach ze ściąganiem są opisy, więc po co umieszczać je z instalatorem? Jak użytkownik po roku znajdzie instalkę naszej aplikacji na dysku i nie pamięta do czego służy “gfs.msi” to znaczy, że nie szanuje naszej radosnej twórczości.

9. Program samowyjaśniający

W programie może być nawet 12 przycisków, ale żaden z nich tak naprawde nie potrzebuje opisu - użytkownik sam będzie wiedział do czego one służą i jak z nich korzystać. A nawet jeśli nie - odkrywanie do czego służą jest wielką przygodą.
10. Instrukcja obsługi

Instrukcje obsługi powinny być dostępne tylko na stronie internetowej twórcy. W ten sposób użytkownik ma dostęp do najświeższej wersji, oczywiście jeżeli ma dostęp do Internetu.