SPECS: locale-rules-pl.txt (NEW) - initial, needs translation

[ankry]

Author: ankry                        Date: Sat Dec 10 11:54:48 2005 GMT
Module: SPECS                         Tag: HEAD
---- Log message:
- initial, needs translation

---- Files affected:
SPECS:
   locale-rules-pl.txt (NONE -> 1.1)  (NEW)

---- Diffs:

================================================================
Index: SPECS/locale-rules-pl.txt
diff -u /dev/null SPECS/locale-rules-pl.txt:1.1
--- /dev/null	Sat Dec 10 12:54:48 2005
+++ SPECS/locale-rules-pl.txt	Sat Dec 10 12:54:43 2005
@@ -0,0 +1,52 @@
+Na co zwrócić uwagę w zasobach językowych:
+
+1. W miarę możliwości staramy się używać dwu-/trzyliterowych (trzyliterowe
+   kody języków dotyczą języków "rzadszych", o mniejszej ilości zasobów) nazw
+   plików/katalogów zawierających zasoby językowe. Dlaczego?
+   - Jeśli mamy np. zasoby francuskie, i użyjemy nazwy je "fr" a nie
+     "fr_FR", to mogą one być użyte także przy innych ustawieniach locale
+     (np. fr_CA czy fr_BE).
+   - Unikamy niepotrzebnego mnożenia bytów (mniej katalogów, mniej plików)
+   Oczywiście mogą wystąpić wyjątki od tej zasady. Najczęstsze to:
+   - pt_BR - mam wątpliwości, czy pod nieobecność zasobu pt/pt_PT nie
+     powinny być one uwspólnione jako pt.
+   - zh_CN, zh_TW - tu jest sytuacja specyficzna. Te dwie odmiany chińskiego
+     używają innego zestawu znaków (inne "kodowanie", ale też inne
+     odwzorowanie w Unikodzie). O ile przekodowanie big5(TW) -> gb2312(CN)
+     jest w zasadzie jednoznaczne, o tyle w drugą stronę jest mało
+     wiarygodne (tzn. da się pewnie przeczytać, ale niekoniecznie będzie to
+     poprawny "tradycyjny" chiński. Ponadto o ile iconv potrafi jakoś
+     przekodowac big5 <--> gb2312, to big5 -> utf-8 -> gb2312 (i w drugą
+     stronę już nie. A to poważna przypadłość. Z tego powodu używanie kodu
+     "zh" prowadzi do niejednoznaczności i nie ma sensu.
+
+4. Dwu-/trzyliterowe kody są też zalecane w klauzuli %lang(...) sekcji
+   %files speca. Poza w/w wyjątkami.
+
+3. Katalogi na zasoby językowe znajdują sie we wspólnych pakietach, takich
+   jak: FHS czy glibc-misc. Dodanie nowego języka wymaga poprawienia tych
+   pakietów. (Katalogi "bezpańskie" mogą mieć nieokreślone uprawnienia co
+   skutkuje bezużytecznością ich zawartości w przypadku typowej instalacji.)
+
+4. Czasami zdarzają sie w pakietach niepoprawne oznaczenia języków
+   - przestarzałe
+     no, zastępujemy no -> nb,
+     ven -> ve
+   - pomyłki
+     gr -> el,
+     ar -> es_AR [ale uwaga: ar jako arabski też jest poprawne],
+     ee -> et [jeśli chodzi o estoński, a nie ewe],
+     se -> sv
+   - swobodna twórczość autorów
+     sp -> sr,
+     a3 -> az,
+     ph -> fil
+     sw jako szwabski (Shwabbish) - powinno być chyba de at Shwabbish albo coś
+       podobnego - szwabski nie ma własnego kodu ISO, a do suahili jest mało
+       podobny ;)
+
+5. Do znajdowania standardowo zlokalizowanych zasobów językowych używamy
+   makra %find_lang. Ale uwaga: wywoływany przez nie skrypt pomija "puste"
+   pliki tłumaczeń, jako nic nie wnoszące śmieci. Czy cos zawierają, można
+   sprawdzić np. za pomoca polecania:
+      file plik.mo
================================================================