Jakub Florczyk - Blog o programowaniu .NET i Android

Programista praktyczny

Category: Visual Studio

Lokalizacja aplikacji w .NET Compact Framework

W kilku krokach i słowach, postaram się wyjaśnić zasadę lokalizacji aplikacji .NET Compact Framework. Wszystko przy uwzględnieniu certyfikowania aplikacji dla Windows Marketplace for Mobile.

Na samym początku pragnę przypomnieć, że lokalizacja opiera się na tłumaczeniu aplikacji dla danego kraju a nie języka! To jest bardzo ważny element z którego nie wszyscy sobie zdają sprawę. Ale później pokaże jak w prosty sposób “oszukać” Marketplace aby nasza aplikacja na jednym języku chodziła na wiele krajów.

Drugim ważnym problemem jest pytanie jakie musi sobie zadać każdy deweloper: w którym momencie lokalizować aplikację? Odpowiedź na to pytanie nie jest prosta. Jeżeli zamawiamy grafiki, piszemy teksty do naszej aplikacji należy o tym pamiętać na samym początku. Ale samą lokalizację sugeruje robić na samym końcu – nawet po testach funkcjonalnych. Ale ta teoria sprawdza się tylko w przypadku aplikacji okienkowych, bo gry warto lokalizować na samym początku, wraz z pisanym kodem. W aplikacjach okienkowych problem sprowadza się do zmian wprowadzanych na poszczególnych formach, które następnie musimy weryfikować na innych wersjach językowych. Dlatego aby uprościć sobie przeklikiwanie się przez kolejne formy i sprawdzanie czy zmiany zostały poprawnie przeniesione, sugeruje lokalizować aplikację na samym końcu.

Lokalizacja kodu.

Tutaj sprawa wygląda dość prosto i całość problemu sprowadza się do poprawnego wyświetlania danych oraz odpowiedniego sposobu konwertowania tychże.

// konwersja
DateTime dateTime = Convert.ToDateTime(xeEntry.Attribute("DateTime").Value, CultureInfo.CurrentCulture);
// wyświetlanie
label1.Text = dateTime.ToString(CultureInfo.CurrentCulture);

Ot co, cała filozofia. Jeżeli używamy Microsoft FxCop – nie omieszka nas o tym poinformować odpowiednim komunikatem.

Lokalizacja okien (Form-ów).

Mój projekt składa się tylko z jednego forma, w którym jest bardzo proste menu (w tym momencie w języku angielskim):
Largo_Form1

Następnie przełączamy się na właściwości forma i zmieniamy Localizable na True oraz Language na Polish:

Largo_Language

Po tej operacji w nazwie okna (na górnym pasku) powinniśmy zobaczyć napis Form1.cs [Design - Polish]. W tym momencie możemy przetłumaczyć menu na język polski:

Largo_Form1_Polish

Kiedy dokonamy pierwszej zmiany w plikach aplikacji zostanie utworzony dodatkowy plik o nazwie Form1.pl.resx. Każde tłumaczenie jakiego dokonamy będzie miało odzwierciedlenie właśnie w tym pliku – poprzez utworzenie odpowiedniego rekordu lokalizacji.

Tak jak pisałem na początku w przypadku okienek warto te kroki zostawić na sam koniec, aby później nie paprać się zbytnio w zmianach na kolejnych formach kiedy zauważymy źle ustawiona kontrolkę lub tym podobny trywialny problem, który po lokalizacji może narastać lawinowo w zależności od ilości krajów.

Lokalizacja zasobów (Resources).

Załóżmy że nasz aplikacja wyświetla MessageBox-a z tekstem “Are you sure?” – np w momencie kliknięcia w Exit (tak na marginesie certyfikacja dla Marketplace zabrania takich praktyk). Tekst przenosimy do zasobów pod nazwą MessageBox_Text. Mamy załatwioną wersję angielską.
Aby utworzyć odpowiednie tłumaczenie w wersji polskiej, musimy utworzyć kopię pliku Resources.resx zmieniając jego nazwę na Resources.pl.resx i dokonując tłumaczenia. Gotowe!

Lokalizacja instalatora.

Aby przenieść i wkompilować wszystkie wersje językowe w jednego CAB-a musimy dodać do projektu instalatora pliki lokalizacyjne. Aby to zrobić klikamy prawym klawiszem na projekcie i wybieramy Add -> Project Output… -> Localized resources.

W tym momencie uzyskujemy jeden plik CAB, który załaduje wersję językową naszej aplikacji w zależności od ustawień regionalnych telefonu użytkownika.

A co na to Marketplace?

Zanim napiszę o Marketplace wrócę do tematu, który z premedytacją pominąłem na początku a dotyczy działania lokalizacji na telefonie. Otóż sam proces jest stosunkowo prosty w działaniu. Windows Mobile odpala program, szukając jednocześnie lokalizacji zgodnej z danym ustawieniem regionalnym. Jeżeli nie dokonamy lokalizacji programu albo nie system operacyjny nie znajdzie odpowiedniej lokalizacji, zostanie załadowana lokalizacja domyślna programu. Jeżeli system odnajdzie odpowiednią lokalizację – zostanie ona załadowana.

Windows Marketplace for Mobile zakłada, że każdy certyfikowany program może zawierać nieograniczoną ilość lokalizacji o ile znajdują się one w jednym pliku CAB. Jeżeli lokalizacja znajduje się w oddzielnym pliku CAB niż “oryginał” cały proces certyfikacji musi zostać wykonany ponownie za co zapłacimy 100$. W pierwszym wypadku zapłacimy tylko 9.99$ za każdy kolejny kraj. Jednym słowem warto kompilować CAB-y z wieloma lokalizacjami.

Wracając do tematu “oszukania” Marketplace. Z mojego punku widzenia istnieje Polska i reszta świata, która mówi w języku angielskim. W Marketplace reszta świata mówiąca po angielsku sprowadza się do następujących krajów: Australia, Kanada, Indie, Irlandia, Nowa Zelandia, Singapur, Wielka Brytania, Stany Zjednoczone. Aby nie komplikować sobie sprawy z lokalizacjami sugeruję utworzyć “domyślną” lokalizację w języku angielskim a tłumaczenie w Polskim. Chodzi o to, że zamiast tworzyć osiem lokalizacji, tworzymy tylko jedną.

Poprawny .NET Compact Framework CAB w kilku krokach

Na początek przyznam się, że zawsze miałem problemy z projektami instalacyjnymi. Dlatego chciałbym w kilku krokach przybliżyć wam mój sposób tworzenia poprawnego CAB-a dla Compact Framework, do którego doszedłem po wielu testach i próbach.

Projekt do którego tworzę CAB-a nazywa się Largo.

Krok pierwszy – tworzymy “Smart Device CAB Project”:

Smart_Device_CAB_Project

Ja przyjąłem standard nazewnictwa [Nazwa projektu].Cab. Ale jako tako nazwa ta nie ma większego znaczenia.

Krok drugi – zmieniamy nazwę pliku wyjściowego (prawy klik na projekcie i wybieramy Properties):

Na początek mała uwaga, kliknięcie Properties z menu kontekstowego przywołuje inny ekran niż wybór Properties z Properties Window.

Property_Pages

Domyślna nazwa zbudowana jest według zasady “Debug\[Nazwa projektu CAB].cab” dlatego w naszym przypadku będzie to “Debug\Largo.Cab.cab”. Wystarczy usunąć przyrostek .cab aby nazwa wyglądała poprawnie (“Debug\Largo.cab”).

Krok trzeci – zmiana nazwy produktu i firmy (wybieramy Properties z Properties Window):

Properties_Window

Manufacturer – zmieniamy na nazwę naszej firmy / imię nazwisko lub nick. Ta nazwa pojawi się tylko i wyłącznie podczas instalacji w momencie kiedy Windows Mobile pyta nas czy chcemy zainstalować program “[Manufacturer] [ProductName]“. Według mnie nazwa ta jest odrobinę zbędna ale np. Windows Marketplace for Mobile wymaga aby nazwa ta zgadzała się z nazwą firmy / dewelopera który jest zgłoszony do sklepu.

ProductName  – zmieniamy na nazwę naszego programu. Domyślnie jest to nazwa projektu CAB. W tym punkcie warto pamiętać, że pod taką nazwą pojawi się katalog z naszą aplikacją w “Program Files”.

Krok czwarty – usuwamy z “File System” folder o nazwie “Program Files Folder” (prawy klik na katalogu i wybieramy Delete):

Program_Files_Folder_remove

W większości przypadków ten katalog jest zbędny dlatego spokojnie można go usunąć.

Krok piąty – dodajemy “Primary Output” (prawy klik na projekcie Add -> Project Output… ):

Primary_Output

To jest zestaw podstawowych plików naszej aplikacji, który zawiera plik exe oraz załączone biblioteki.

Krok szósty – utworzenie katalogu “Programs Folder” (prawy klik na lewym panelu Add Special Folder – > Programs Folder):

Programs_Folder

Krok siódmy – utworzenie skrótu do programu (rozwijamy w lewym panelu wcześniej utworzony “Programs Folder” i w prawym panelu, prawy klik “Create New Shortcut”):

Create_New_Shortcut

Następnie pojawi się okno wyboru elementu do którego tworzymy skrót:

Select_Item_In_Project

Wybieramy “Application Folder” a następnie “Primary output from [Nazwa projektu] (Active)”:

Primary_Output_From_Largo

Nazwa która się pojawi od razu zmieniamy na “Largo” (albo jakakolwiek inna). Ta nazwa pojawi się w menu Start.

I to zasadniczo wszystko. W siedmiu krokach udało nam się utworzyć podstawowy projekt CAB. Ze swojej strony chciałbym tylko dodać kilka porad co do późniejszej pracy z takim projektem:

  • Jeżeli dodajemy do oryginalnego projektu jakieś biblioteki warto po kompilacji kliknąć na katalogu “Detected Dependencies” i wybrać “Refresh Dependencies”. Czasami Visual Studio zapomina je odświeżyć i dlatego warto zrobić to ręcznie.
  • Jeżeli używamy plików z ustawionymi atrybutami “Build Action” na “Content” pamiętajmy o tym aby je dołączyć do CAB. Wystarczy prawy klik na projekcie Add -> Project Output -> Content Files i pliki znajdą się w instalatorze.
  • Podobnie jak powyżej dodajemy pliki lokalizacyjne Add -> Project Output -> Localized resources.