Mozilla:Sunbird:Lokalizacja z przepakowywaniem

Polski Sunbird metodą "zrób to sam"

UWAGA: opis opiera się na wersji 0.3a2. W innych może być inaczej. We wcześniejszych - jest inaczej.

1. Ściągamy angielską wersję ZIP lub tar.gz. Rozpakowujemy ją do dowolnego katalogu - oznaczam go dalej jako $KS. W $KS powinniśmy zatem mieć katalog o nazwie sunbird.

UWAGA: nie uruchamiamy Sunbirda z $KS/sunbird!!! Inaczej potworzy nam śmieci, które nie powinny się znaleźć w dystrybuowanej paczce.

2. Szukamy plików calendar-en-US.jar i en-US.jar w katalogu $KS/sunbird/chrome

3. Rozpakowujemy je w katalogu roboczym (dalej oznaczanym $KR), calendar-en-US.jar do $KR/calendar-en-US, a en-US.jar do $KR/en-US. Powinniśmy mieć taką strukturę katalogów:

$KR
 |-calendar-en-US
 | |-locale
 |   |-en-US
 |     |-calendar 
 |       |- tutaj pliki *.dtd i *.properties
 |-en-US
   |-locale
     |-branding
     |-en-US
       |-autoconfig
       | |- tutaj pliki *.dtd i *.properties
       |-global
       ... itd.

4. Robimy kopie tych 2 katalogów i nazywamy je odpowiednio $KR/pl i $KR/calendar-pl.

5. W tych skopiowanych katalogach zmieniamy wszelkie en-US w nazwach podkatalogów na pl - tzn. mamy np. $KR/calendar-pl/locale/pl/calendar, $KR/pl/locale/pl/global itp.

6. Tłumaczymy pliki *.dtd, *.properties i ew. inne (*.xhtml, *.rdf). WAŻNE: Polskie znaki kodujemy w UTF-8 bez BOM.

Zamiast tłumaczyć od zera, można (a nawet powinno się) przenieść pliki ze starszej wersji i używając diff i compare-locales.pl odpowiednio je zaktualizować.

Zawartość pl - czyli lokalizację toolkitu - można wziąć żywcem z katalogów dom, toolkit i security z CVS-l10n, należy tylko zwrócić uwagę na inną strukturę katalogów. Ewentualnie można wziąć zawartość pl.jar prosto z równoległego nightly Thunderbirda - ale NIE z Firefoksa, Firefox ma część plików nadpisanych.

Jeśli nie tłumaczymy od zera, tylko bazujemy na poprzedniej wersji, compare-locales pokaże nam, co trzeba dodać i usunąć z naszej lokalizacji.

Użycie compare-locales w tej sytuacji wygląda tak:

cd $KR
compare-locales.pl calendar-en-US/locale/en-US/calendar calendar-pl/locale/pl/calendar
compare-locales.pl en-US/locale/en-US pl/locale/pl
compare-locales.pl en-US/locale/branding pl/locale/branding

Brakujące stringi tłumaczymy, nadmiarowe usuwamy. Należy pamiętać, że brakująca encja objawi się czerwonym komunikatem o błędzie i uniemożliwi korzystanie z danego okna XUL, dlatego dbamy o przetłumaczenie wszystkich stringów.

Po przetłumaczeniu koniecznie ponownie porównujemy lokalizację polską z angielskim źródłem. Tym razem compare-locales.pl nie ma prawa wykazać żadnych brakujących ani nadmiarowych encji i własności!

Uwaga: pliki, których ten skrypt nie jest w stanie sprawdzić, należy sprawdzić samemu. Nie jest ich dużo, a i zmiany w nich zachodzą rzadko (pliki rdf, xhtml i inne).

Jeśli jest potrzeba, naprawiamy wskazane przez ten skrypt błędy i ponownie dokonujemy sprawdzenia. Jeśli jest już OK, przechodzimy do punktu 7.

7. Tworzymy calendar-pl.jar - zipując $KR/calendar-pl/locale tak, żeby katalog locale był na pierwszym poziomie ZIPa (czyli, żeby ogólna struktura była identyczna jak w calendar-en-US.jar:

cd $KR/calendar-pl
jar -cvMf ../calendar-pl.jar locale

Można użyć też normalnego ZIPa, narzędzi Gnome/KDE albo windowsowego "Wyślij do > Folder skompresowany" lub czegokolwiek innego zgodnego z ZIP-em( pliki JAR to ZIP-y z innym rozszerzeniem, nic ponadto).

Ja używam JAR-a, bo ma dla mnie wygodniejszą składnię, zbliżoną do tara. ;-)

8. Analogicznie, tworzymy pl.jar - zipując $KR/pl/locale tak, żeby locale było na pierwszym poziomie naszego ZIP-a:

cd $KR/pl
jar -cvMf ../pl.jar locale

Plik ten powinien mieć zatem taką samą strukturę jak en-US.jar, oczywiście z innym kodem języka w nazwach wszelkich katalogów.

9. Przechodzimy do $KS/sunbird/chrome. Usuwamy en-US.jar i calendar-en-US.jar. Dorzucamy na ich miejsce nasze pl.jar i calendar-pl.jar

10. Plikowi $KS/sunbird/chrome/en-US.manifest zmieniamy nazwę na pl.manifest, otwieramy go w edytorze i zmieniamy wszystkie wystąpienia "en-US" na "pl".

11. Analogicznie, plikowi calendar-en-US.manifest zmieniamy nazwę na calendar-pl.manifest, otwieramy go w edytorze i zmieniamy wszystkie wystąpienia "en-US" na "pl".

12. Zipujemy wszystko z powrotem:

• dla Windows:

cd $KS
jar -cvMf sunbird-NR.WERSJI.pl.win32.zip sunbird

• dla Linuksa:

cd $KS
tar -cjvf sunbird-NR.WERSJI.pl.linux-i686.tar.bz2 sunbird

13. Paczki są gotowe. Trzeba tylko sprawdzić, czy program działa. ;-)

14. Rozpakowujemy paczkę do osobnego katalogu testowego $KT lub kopiujemy do niego $KS/sunbird (Uwaga: nie wolno nam uruchamiać Sunbirda z $KS/sunbird, jeśli na jego bazie planujemy kiedykolwiek robić paczkę!!!).

15. Uruchamiamy kopię Sunbirda z $KT/sunbird. Bawimy się nim przez kilkanaście minut i patrzymy, czy wszystko gra. Jeśli jest OK, możemy paczki wrzucić na serwer (warto obok dorzucić sumy MD5).

Jeśli coś wymaga poprawy, cofamy się do odpowiedniego punktu powyżej. Jeśli Sunbird w ogóle się nie uruchamia, a oryginalny build chodzi dobrze, znaczy, że coś naprawdę schrzaniliśmy. :)

Mac OS X

Na Makach robimy dokładnie to samo, trzeba tylko pamiętać, że:

• to, co widzimy jako ikonkę "Sunbird" jest w rzeczywistości zwykłym katalogiem "Sunbird.app". Wewnątrz Sunbird.app, w katalogu MacOS mamy analogiczną strukturę katalogów jak pod Linuksem.
• dodatkowo plikowi English.lproj zmieniamy nazwę na pl.lproj
• wszystko pakujemy do postaci obrazu dmg, obraz dmg można utworzyć narzędziem Disk Copy (w /Applications/Utilities) lub innymi narzędziami

Pakiet językowy

Opis kiedyś będzie. ;-)

Krótko: powinno wystarczyć wziąć poprzedni langpack, podmienić calendar-pl.jar i pl.jar na nowe wersje, ustawić odpowiednie numery wersji Sunbirda w install.rdf i upewnić się, że ścieżki w chrome.manifest są poprawne.