Mozilla PL -- poszukiwany koordynator tłumaczenia
Marcin Jagodzinski
przeglądarki Mozilla. Ze względu na obciążenie obowiązkami zawodowymi nie
jestem w stanie go kontynuować.
Mozilla została w dużym stopniu zlokalizowana przeze mnie. Od strony
technicznej lokalizacja jest dość prosta i nie wymaga wiedzy
programistycznej. Potrzebny jest edytor pracujący w UTF-8. Przydaje się
Perl. Plusem jest podstawowa znajomość XML-a. Środowisko pracy: MS Windows
lub Linux. Bardzo wskazane jest doświadczenie w tłumaczeniu software'u.
Wymagania:
* dobra znajomość języka angielskiego i doskonałe wyczucie językowe w
języku polskim.
* dokładność, cierpliwość i precyzja.
* pomysłowość i umiejętność rezygnacji z własnych pomysłów.
* trochę czasu (kilkanaście godzin raz na 2 miesiące -- jeżeli lokalizowane
będą tylko Milestone Builds)
Lokalizacja powinna zostać udostępniona społeczności internetowej na
licencji GPL.
Ze swojej strony dostarczę to, co już zostało zlokalizowane (zresztą pliki
są dostępne: http://portfolio.art.pl/mozilla/). Mogę także podesłać kilka
prostych programików perlowych bardzo ułatwiających lokalizację (niestety,
będzie trzeba je trochę przerobić: zmieniła się struktura katalogów
Mozilli) oraz podzielić się doświadczeniami.
Przemyślane zgłoszenia proszę nadsyłać na adres: mar...@portfolio.art.pl
Marcin Jagodzinski
(or compatible)
Tomasz Kłoczko
> Poszukuję osoby, która doprowadziłaby do końca projekt lokalizacji
> przeglądarki Mozilla. Ze względu na obciążenie obowiązkami zawodowymi nie
> jestem w stanie go kontynuować.
> Mozilla została w dużym stopniu zlokalizowana przeze mnie. Od strony
> technicznej lokalizacja jest dość prosta i nie wymaga wiedzy
> programistycznej. Potrzebny jest edytor pracujący w UTF-8. Przydaje się
> Perl. Plusem jest podstawowa znajomość XML-a. Środowisko pracy: MS Windows
> lub Linux. Bardzo wskazane jest doświadczenie w tłumaczeniu software'u.
Tak baj de łejem .. czy nikt z pracujacych nad mozillą nie wpadł na pomyśł
żeby przerobić wszystko na gettext ? Pzrecież to sie daje używać na
wszystkich unices, Windows i Mac-ach.
Całe to szykowanie tłumaczeń byłoby dzieki temu tak z kilka razy prostrze
(przecież).
kloczek
--
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: klo...@rudy.mif.pg.gda.pl*
Marcin Jagodzinski
wrote:
>Marcin Jagodzinski <pisz_na_adre...@webcorp.com.pl> wrote:
>Tak baj de łejem .. czy nikt z pracujacych nad mozillą nie wpadł na pomyśł
>żeby przerobić wszystko na gettext ? Pzrecież to sie daje używać na
>wszystkich unices, Windows i Mac-ach.
>Całe to szykowanie tłumaczeń byłoby dzieki temu tak z kilka razy prostrze
>(przecież).
>
Nie wiem, co to jest gettext, ale mimo to nie wydaje mi się, żeby dało się
jeszcze znacząco uprościć lokalizację. Jest ona bowiem naprawdę prosta.
Masz pliki DTD (są też pliki .properties, ale 90% jest w DTD)
<!ENTITY div.walletdataonsystem.label "The following form data is
being saved for you.">
<!ENTITY treehead.schemaname.label "Select a field name">
<!ENTITY treehead.entries.label "Values for ">
<!ENTITY treehead.synonyms.label "Synonyms for ">
<!ENTITY treehead.synonymsoff.label "Select a value above to see
its synonyms">
<!ENTITY button.remove.label "Remove">
<!ENTITY button.addschema.label "Add New Field ...">
<!ENTITY button.addentry.label "Add New Value ...">
<!ENTITY button.addsynonym.label "Add New Synonym ...">
<!ENTITY windowtitle.label "Stored Form Data">
Które sobie dowolnym edytorem tłumaczysz. Ważne, żeby wynik był w UTF-8
(możesz użyć odpowiedniego edytora, możesz konwertować). Nie ma w tym nic
trudnego. Dodatkowo jest kilka programów, które to wspomagają. Ja sam
napisałem parę skryptów, które robią coś w rodzaju diffa (lista terminów do
tłumaczenia, lista terminów usuniętych).
Możesz to robić na dowolnej platformie, ale podałem Windows i Linuxa, gdyż
buildy dla tych platform ukazują się najszybciej. Mac odpada z innych
względów,
Pozdrowienia
Marcin Jagodzinski
(or compatible)
Tomasz Kłoczko
> On 10 Sep 2000 02:50:54 GMT, Tomasz Kłoczko <klo...@rudy.mif.pg.gda.pl>
> wrote:
>>Marcin Jagodzinski <pisz_na_adre...@webcorp.com.pl> wrote:
>>Tak baj de łejem .. czy nikt z pracujacych nad mozillą nie wpadł na pomyśł
>>żeby przerobić wszystko na gettext ? Pzrecież to sie daje używać na
>>wszystkich unices, Windows i Mac-ach.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [1]
>>Całe to szykowanie tłumaczeń byłoby dzieki temu tak z kilka razy prostrze
>>(przecież).
>>
> Nie wiem, co to jest gettext
To bardzo nieładnie. Proponuję jak najszybciej zupełnić ów brak. Polecam:
$ info gettext
Jest to mechaniz zaimplementowany na poziomie już glibc 2.x znany ca. od
1995 roku. W wersji standalone libintl ma koło 20KB segmentu text. Po kiego
grzyba mi parser XML na wykonanie czegoś co jest trywialne ? Czy ten parser
jest na pewno tak dobrze wyttwstowany jak obsługa gettext ? Czy jest mniejszy
(w rozmiarze kodu) od libinlt ?
Proponuję wziać źródła dowolnych kilku programów i przejrzeć te w których
znajduje się katalog /po. Tam znajdziesz pliki .po które zawieraja
tłumaczenie i także plik .pot który zawiera template pliku który powinien być
używany o ile chciałbyś zrobić tłumaczenie wszystkich komunikatów do danego
programu o ile jeszcze nie ma takowego w języku jaki używasz nativ.
[..]
> Które sobie dowolnym edytorem tłumaczysz. Ważne, żeby wynik był w UTF-8
> (możesz użyć odpowiedniego edytora, możesz konwertować).
Wybacz ale po kiego groma mi obsługa UTF skoro mogę użyć konkretnego
transfer enkodingu ? Jak znam życie to jeszcze zapewne obsługę UTF
mozilla/netscape ma włąsną (jakbyś nie wiedzieł to glibc ma wsparcie do
obsługi róznych enkodingów w tym i UTF). W przypadku języka polskiego będzie
to oczywiście iso-8859-2. Tworząc plik pl.po z polskimi tłumaczeniami do
jakiegoś programu oczywiście mogę też użyć UTF ale jest to
niepotrzebne/bardziej skomplikowane niż w przypadku najporstrzym może być.
> Nie ma w tym nic trudnego. Dodatkowo jest kilka programów, które to
> wspomagają. Ja sam napisałem parę skryptów, które robią coś w rodzaju
> diffa (lista terminów do tłumaczenia, lista terminów usuniętych).
Jeszcze jeden argument za gettext. gettexta używa się praktycznie wszędzie
(w ten sposób jest umiędzynarodowionych kilka jeśli nie kilkanaście tysiecy
dostępnych programów, a sumująć to do z pomocą gettext jest zrobione w np.
Solarisie bezie tego kilkadziesią tysiecy). W kilku jeszcze miejscach używa
się catgets (też jest wsparcie w libintl/glibc 2.x i przypadku używania
catgets możnaby policzyć już te przypadki na palcach obu rąk), a tłumaczenie
w oparciu o XML jakie znasz jest prawktycznie robione w _jednym_ programie
(mozillę i netscape traktuje tu jako jeden i ten sam produkt co w tym
wypadku dużym zaokrągleniem nie jest).
Jeszcze jedno pytanie: w ilu plikach masz obecne tłumaczenia do mozilli ? bo
gdybyś miał to w gettex to byłby to pojedynczy plik tekstowy.
> Możesz to robić na dowolnej platformie, ale podałem Windows i Linuxa, gdyż
> buildy dla tych platform ukazują się najszybciej. Mac odpada z innych
> względów,
Widać nie przeczytałeś uważnie tego co napisałe. Zerknij jeszcze raz na [1].
Dodatkowo gettext załatwia także Mac-a.
Lubię taką zasadę .. KISS się to nazywa (Keep It Simple Stupid). Widać
programiści z Netscape których dokonania są teraz kulą u nogi w mozilli nie
znali tej zasady. Ale ja niemniej się pytałem (tak czy inaczej) o to czy
śledząć (zapewne) dyskusje na devel listach mozilli nie zauważyłeś żeby ktoś
_wreszcie_ zauważył, że mozilla pod względem szykowania tłumaczeń jest
niczym czana owca (?) i że wyp* na zbity pysk całego obecnego wsparcia i
zrobienie tego po ludzku do i18n w mozilli niewątpliwie uprościłoby ten
program. Jeżeli przez dwa lata pracy nad mozillą nikt na to nie wpadł t ow
asadzie można już postawić duuży krzyżyk na mozilli (bo będzie to oznaczać,
że nad mozillą pracuja dyletanci którzy nie mają pojęcia o pewnych
podstawach których omijanie jest czystej wody głupotą).
I tak jeszcze dalej bajdełejem .. zauważyłeś może jak paskudnie jest pisany
kod do mozilli ?
Może pewien mały eksperyment na lugu z kompilacji jaką ostanio robiłem
(który trzymam sobie cały czas):
$ wc -l mozilla.spec.build.log; grep warning mozilla.spec.build.log | wc -l
17313 mozilla.spec.build.log
3834
czyli tak na mniej wiecej co czwary co trzeci plik (a moze nawet wiecej bo
sporo tam plików np. w XML) źródłowy w C/C++ przypada jedeno ostrzezenie (w
logu tym około połowę linii to komunikaty make). To o M17. W M16 było tego
ponad 4K na około 16K linni. Zapewne jakby posiedzieć już tylko nad
pousuwaniem tych ostrzeżeń to stabilność mozilli wzrosłaby odczuwalnie.
Wogóle kolejna sprawa, że strzelanie do czegoś takiego jak przeglądatka http
z C++ to kolejny absurd i zapewne i to też dość mocno komplikuje konserwację
tego porojektu (jak zresta każdego innego większego pisanego w C++).
Grzegorz Staniak
[...]
>Lubię taką zasadę .. KISS się to nazywa (Keep It Simple Stupid). Widać
>programiści z Netscape których dokonania są teraz kulą u nogi w mozilli nie
>znali tej zasady. Ale ja niemniej się pytałem (tak czy inaczej) o to czy
>śledząć (zapewne) dyskusje na devel listach mozilli nie zauważyłeś żeby ktoś
>_wreszcie_ zauważył, że mozilla pod względem szykowania tłumaczeń jest
>niczym czana owca (?) i że wyp* na zbity pysk całego obecnego wsparcia i
>zrobienie tego po ludzku do i18n w mozilli niewątpliwie uprościłoby ten
>program. Jeżeli przez dwa lata pracy nad mozillą nikt na to nie wpadł t ow
>asadzie można już postawić duuży krzyżyk na mozilli (bo będzie to oznaczać,
>że nad mozillą pracuja dyletanci którzy nie mają pojęcia o pewnych
>podstawach których omijanie jest czystej wody głupotą).
Skoro produkt już jest i jest taki a nie inny, nie uważasz, że można docenić
czyjś wysiłek włożony w jego spolszczenie, zamiast objeżdżać "w imię zasad"?
Czy ktoś Ci każe się Mozillą zachwycać? A jeśli nie podoba Ci się mechanizm
lokalizacji, kto Ci broni ją zgettextować? Źródła są publicznie dostępne.
[...]
>kloczek
--
Grzegorz Staniak <gsta...@zagiel.pl>
Miros/law `Jubal' Baran
> On 11 Sep 2000 00:18:06 GMT, Tomasz Kłoczko wrote:
> [...]
[zachwyty nad narzędziem, ciach, nieistotne]
> Skoro produkt już jest i jest taki a nie inny, nie uważasz, że można docenić
> czyjś wysiłek włożony w jego spolszczenie, zamiast objeżdżać "w imię zasad"?
> Czy ktoś Ci każe się Mozillą zachwycać? A jeśli nie podoba Ci się mechanizm
> lokalizacji, kto Ci broni ją zgettextować? Źródła są publicznie dostępne.
Nie mówiąc już o tym, że jedyną zaletą `gettext' jest to, że istnieje.
Bo pomyślany jest ostro dodupnie...
Jubal
PS. Kłoczku, czy ktoś Ci już mówił, że TY nie powinieneś zajmować się
tłumaczeniami od strony językowej?
--
[ Miros/law L Baran, baran-at-knm-org-pl, neg IQ, cert AI ] [ 0101010 is ]
[ BOF2510053411, makabra.knm.org.pl/~baran/, alchemy pany ] [ The Answer ]
God does not play dice with the universe. -- Albert Einstein
Sławomir Białek
>Jest to mechaniz zaimplementowany na poziomie już glibc 2.x znany ca. od
>1995 roku. W wersji standalone libintl ma koło 20KB segmentu text. Po kiego
>grzyba mi parser XML na wykonanie czegoś co jest trywialne ? Czy ten parser
>jest na pewno tak dobrze wyttwstowany jak obsługa gettext ? Czy jest mniejszy
>(w rozmiarze kodu) od libinlt ?
>Wybacz ale po kiego groma mi obsługa UTF skoro mogę użyć konkretnego
>transfer enkodingu ? Jak znam życie to jeszcze zapewne obsługę UTF
>mozilla/netscape ma włąsną (jakbyś nie wiedzieł to glibc ma wsparcie do
>obsługi róznych enkodingów w tym i UTF). W przypadku języka polskiego będzie
>to oczywiście iso-8859-2. Tworząc plik pl.po z polskimi tłumaczeniami do
>jakiegoś programu oczywiście mogę też użyć UTF ale jest to
>niepotrzebne/bardziej skomplikowane niż w przypadku najporstrzym może być.
Stojąc zupełnie z boku, nie będąc zachwyconym, ani XMLem, ani UTFem,
ani gettextem (jakieś pojęcie o tym wszystkim mam, ale jestem
prostym programistą i używam jak potrzebne, ale raczej w prosty sposób
i szczerze mówiąc i bez tego wszystkiego też bym sobie dał radę, tak więc
znam to dosyć powierzchownie) mam pytanie.
Nie opowiadając się za jednym, ani za drugim rozwiązaniem
chciałem zapytać z praktycznego punktu widzenia.
Skoro XML w mozilli jest i tak potrzebny oraz UTF w mozilli jest również
potrzebny z powodów innych niż tłumaczenie to wykorzystanie tych dwóch
elementów do lokalizacji nie kosztuje nic. Co więc daje przejście
na gettexta poza tym, że trzeba się będzie go nauczyć i dołączyć
bibliotekę? Co jest złego w XML+UTF poza tym, że to nie jest gettext?
I zasadnicze pytanie - jak wygląda sprawa unicodu w gettext?
Jednak imho lepiej jest napisać wszystkie tłumaczenie w jednym
kodowaniu, niż każdy inny i potem przy wyświetlaniu komunikatów
jeszcze bawić się z obsługą wielu kodowań.
--c
Tomasz Kłoczko
> [...]
Grzesiek ja się pytałem tylko to czy ktoś o tym myślał. Reszta to tylko
oprawka mająca uzmysłowić to dlaczego się pytam i dlaczego odpowiedź na to
pytanie może być istotna.
Grzegorz Staniak
[...]
>Grzesiek ja się pytałem tylko to czy ktoś o tym myślał. Reszta to tylko
>oprawka mająca uzmysłowić to dlaczego się pytam i dlaczego odpowiedź na to
>pytanie może być istotna.
Ja z kolei nie chciałem zaczynać wojny, ale Twój list był taki... dość
emocjonalny. Nie wiem pewnie o gettext tyle co Ty, ale myślę, że względy
przenośności mogły mieć udział w decyzjach Mozilla Team.
Artur Skura
> Wybacz ale po kiego groma mi obsługa UTF skoro mogę użyć konkretnego
> transfer enkodingu ?
Pozdrawiam,
Artur
Tomasz Kłoczko
[..]
> PS. Kłoczku, czy ktoś Ci już mówił, że TY nie powinieneś zajmować się
> tłumaczeniami od strony językowej?
I nie próbuję tego tykać .. za mocno.
Tomasz Kłoczko
> On 11 Sep 2000 10:00:43 GMT, Tomasz Kłoczko wrote:
> [...]
>>Grzesiek ja się pytałem tylko to czy ktoś o tym myślał. Reszta to tylko
>>oprawka mająca uzmysłowić to dlaczego się pytam i dlaczego odpowiedź na to
>>pytanie może być istotna.
> Ja z kolei nie chciałem zaczynać wojny, ale Twój list był taki... dość
> emocjonalny. Nie wiem pewnie o gettext tyle co Ty, ale myślę, że względy
> przenośności mogły mieć udział w decyzjach Mozilla Team.
Odpowiednie narzędzia do gettext pod Win32S powstały niecałe trzy lata temu
(Cygnus to majstrował). Myślę, że to było raczje przyczyną (netscape jest
troche starszy).
Niemniej pójście w XML w tym wypadku nie było IMHO czymś co pracę nad
projektem za bardzo upraszczało.
Tomasz Kłoczko
[..]
> Stojąc zupełnie z boku, nie będąc zachwyconym, ani XMLem, ani UTFem,
> ani gettextem (jakieś pojęcie o tym wszystkim mam, ale jestem
> prostym programistą i używam jak potrzebne, ale raczej w prosty sposób
> i szczerze mówiąc i bez tego wszystkiego też bym sobie dał radę, tak więc
> znam to dosyć powierzchownie) mam pytanie.
> Nie opowiadając się za jednym, ani za drugim rozwiązaniem
> chciałem zapytać z praktycznego punktu widzenia.
> Skoro XML w mozilli jest i tak potrzebny oraz UTF w mozilli jest również
> potrzebny z powodów innych niż tłumaczenie to wykorzystanie tych dwóch
> elementów do lokalizacji nie kosztuje nic. Co więc daje przejście
> na gettexta poza tym, że trzeba się będzie go nauczyć i dołączyć
> bibliotekę? Co jest złego w XML+UTF poza tym, że to nie jest gettext?
To co jest wielokrotnie używane to sam parser ale to co z tego
parsara wylatuje jest troche inaczej wykorzystywane. Musze odszczekać
inforeramacje o tym w ilu programach jest używany XML Drugi taki to AbiWord.
Program niemniej chory niż mozilla.
> I zasadnicze pytanie - jak wygląda sprawa unicodu w gettext?
W nagłówko pota wstawiasz, że całość jest w UTF i całość tłumaczonego tekstu
wstawiasz w UTF. Sama obsługa gettext w glibc jest robiona juz na poziomie
gconf() i modułów służących do konwersji z jednego enkodingu na inny (jest
ich kilka MB w /usr/lib/gconv).
> Jednak imho lepiej jest napisać wszystkie tłumaczenie w jednym
> kodowaniu, niż każdy inny i potem przy wyświetlaniu komunikatów
> jeszcze bawić się z obsługą wielu kodowań.
Wogóle IMHO lepiej trzymać tłumaczenai w możliwie małej ilości kawałków. W
tym sensie gettext jest optymalny. Same narzędzia do gettext do konserwacji
zasobów po zmianach w tłumaczonych tekstach też są IMHO już tak prosto
zrobiomne, że już prościej chyba się nie da.
Tomasz Kłoczko
> Tomasz Kłoczko a écrit :
>> Wybacz ale po kiego groma mi obsługa UTF skoro mogę użyć konkretnego
>> transfer enkodingu ?
> W tekstach wielojęzycznych?
Zwykle tłumaczy się z angielskiego na jakiś konkretny język. Czyli w
przypadku tłumaczenia zasobów do apliakcji raczej jednak masz do czynienia z
dwujęzycznością.
Krzysztof Krzyżaniak
wiadomość z adresu <klo...@rudy.mif.pg.gda.pl> i powiedziała:
[..]
>> I zasadnicze pytanie - jak wygląda sprawa unicodu w gettext?
>
>W nagłówko pota wstawiasz, że całość jest w UTF i całość tłumaczonego tekstu
>wstawiasz w UTF. Sama obsługa gettext w glibc jest robiona juz na poziomie
>gconf() i modułów służących do konwersji z jednego enkodingu na inny (jest
>ich kilka MB w /usr/lib/gconv).
Na makach, windowsach, solarisie, *BSD, Iriksie, digital, hp-ux, hurd, beos
też?
>> Jednak imho lepiej jest napisać wszystkie tłumaczenie w jednym
>> kodowaniu, niż każdy inny i potem przy wyświetlaniu komunikatów
>> jeszcze bawić się z obsługą wielu kodowań.
>
>Wogóle IMHO lepiej trzymać tłumaczenai w możliwie małej ilości kawałków. W
>tym sensie gettext jest optymalny. Same narzędzia do gettext do konserwacji
>zasobów po zmianach w tłumaczonych tekstach też są IMHO już tak prosto
>zrobiomne, że już prościej chyba się nie da.
Tyle, że przy Mozilli gdzie większość kodu interfejsu jest opisana w plikach
tekstowych IMHO gettext miałby kiepskie zastosowanie.
eloy
--
Krzysztof `eloy' Krzyżaniak | "Miłość to potrawa jarska
<el...@transilvania.eu.org> : A nie sztuka kominiarska."
http://3276979202/~eloy/ .
Pawn Hearts Member . Jan Sztaudynger
Artur Skura
>
> Artur Skura <art...@linuxpl.org> wrote:
> > Tomasz Kłoczko a écrit :
> >> Wybacz ale po kiego groma mi obsługa UTF skoro mogę użyć konkretnego
> >> transfer enkodingu ?
> > W tekstach wielojęzycznych?
> Zwykle tłumaczy się z angielskiego na jakiś konkretny język. Czyli w
> przypadku tłumaczenia zasobów do apliakcji raczej jednak masz do czynienia z
> dwujęzycznością.
istnieje li tylko w mojej wyobraźni ;-)
A już chciałem zawzięcie walczyć o UTF-a ;-) (kiedyś napisałem mini
słownik polsko francuski dla DOS-a i chciałem go przenieść na Linuksa,
co okazało się nie być takie łatwe, jak mi się na początku wydawało...).
Pozdrowienia,
Artur
Zbigniew Okoń
> Grzegorz Staniak <gsta...@inka.zagiel.pl> wrote:
> > Skoro produkt już jest i jest taki a nie inny, nie uważasz, że można docenić
> > czyjś wysiłek włożony w jego spolszczenie, zamiast objeżdżać "w imię zasad"?
> > Czy ktoś Ci każe się Mozillą zachwycać? A jeśli nie podoba Ci się mechanizm
> > lokalizacji, kto Ci broni ją zgettextować? Źródła są publicznie dostępne.
>
> Grzesiek ja się pytałem tylko to czy ktoś o tym myślał. Reszta to tylko
> oprawka mająca uzmysłowić to dlaczego się pytam i dlaczego odpowiedź na to
> pytanie może być istotna.
Być może myślał i prawdopodobnie wyszło mu, że to bez sensu.
1. Moilla jest łatwa do sportowania, maksymalnie niezależna od platformy
systemowej i istnieje niemal pod wszystko, co się rusza (unices z QNX
włącznie, BeOS, Mac, Windows, nie wiem jak z Amigą, ale nawet dopalona
może być odrobinę zbyt wolna). To jeden z celów mozilla-team. W takim
układzie uzależnianie sie od mechanizmów gettext było by tylko kamieniem
u nogi (TSD - pisałeś, że narzędzia okołogettextowe zostały sportowane
pod Windows przy użyciu Cygwina czy wymagają jego bibliotek do
działania?)
2. Interfejs Mozilli jest pisany w XUL, aplikacji XML. Ma to swoje wady,
ale ma też i zalety (np. może umożliwiac ciekawe funkcjonalnie
rozwiązania w rodzaju swoistej integracji witryny z przeglądarką). XUL
nie zastosowano po to, by umożliwić działanie mechanizmom i18n, a
własnie ze względów funkcjonalnych. Dopiero w takich warunkach można się
zastanawiac nad i18n, a stosowanie do tego gettexta jest bez sensu
(strony w HTMLu też gettextyzujesz?).
3. Jak ci się nie podoba rozwiązanie z XUL, to od tego jest właśnie
gecko, żeby można było napisać alternatywny interfejs. Takie już
powstały -- choćby Galeon pod L czy K-Meleon pod Windows. I to w ich
przypadku można się zastanawiac nad gettextem.
4. Doceniam to, co robisz dla OSS w ogólności a Linuxa w szczególności.
Ale bardzo nie podoba mi sie opierdalanie "w imię zasad" po pierwsze
mozilla-team, a po drugie Marcina, który cokolwiek się przy
tłumaczeniach narobił i którego tłumaczenia są używane. Święte wojny są
tym, co może skuteczniej załatwić cały ruch OSS niż jakikolwiek FUD ze
strony MS. Ponadto przydało by się mniej linuxocentryzmu.
Pozdrawiam -
--
Zbigniew Okoń ok...@fnet.pl
_______________________________________________________________________
Prawo i komputery http://prawo.fnet.pl
Marcin Jagodzinski
wrote:
>To co jest wielokrotnie używane to sam parser ale to co z tego
>parsara wylatuje jest troche inaczej wykorzystywane. Musze odszczekać
>inforeramacje o tym w ilu programach jest używany XML Drugi taki to AbiWord.
>Program niemniej chory niż mozilla.
ROTFL! To naprawdę wszystkie, które znasz? ;-)
Marcin Jagodzinski
(or compatible)
Marcin Jagodzinski
wrote:
>Grzesiek ja się pytałem tylko to czy ktoś o tym myślał. Reszta to tylko
>oprawka mająca uzmysłowić to dlaczego się pytam i dlaczego odpowiedź na to
>pytanie może być istotna.
>
Jak jest istotna, to zadaj ją ludziom, którzy Ci mogą jej udzielić. Proste?
Marcin Jagodzinski
(or compatible)
Marcin Jagodzinski
wrote:
>Tyle, że przy Mozilli gdzie większość kodu interfejsu jest opisana w plikach
>tekstowych IMHO gettext miałby kiepskie zastosowanie.
>
Nie w plikach tekstowych, tylko w XML. Dlatego właśnie teskty też są w XML.
Boże, co za akademicka dyskusja. Ja tylko chciałem maintainera znaleźć. Nie
dlatego, że sobie nie radziłem. Naprawdę, tłumaczenie Mozilli od strony
technicznej. Nawet Kłoczek by sobie poradził ;-) [1]
Marcin Jagodzinski
(or compatible)
[1] Od strony technicznej, powiadam ;-)
Marcin Jagodzinski
wrote:
>> Nie wiem, co to jest gettext
>
>To bardzo nieładnie. Proponuję jak najszybciej zupełnić ów brak. Polecam:
>
>$ info gettext
Popatrzę.
>Jest to mechaniz zaimplementowany na poziomie już glibc 2.x znany ca. od
>1995 roku. W wersji standalone libintl ma koło 20KB segmentu text. Po kiego
>grzyba mi parser XML na wykonanie czegoś co jest trywialne ? Czy ten parser
>jest na pewno tak dobrze wyttwstowany jak obsługa gettext ? Czy jest mniejszy
>(w rozmiarze kodu) od libinlt ?
Parser (expat Clarka) jest bardzo dobrze przetestowany (wchodzi w skład
standardowych modułów do obsługi XML m.in. Perla, Pythona i paru innych
produktów). AFAIK to ok 30KB. Parser XML przydaje się, ponieważ cały
interfejs Mozilli jest zapisany w XUL (aplikacji XML). Komunikaty są tylko
jego częścią. Dodatkowo parser XML jest standardową częścią przeglądarki (z
wiadomych względów).
>Proponuję wziać źródła dowolnych kilku programów i przejrzeć te w których
>znajduje się katalog /po. Tam znajdziesz pliki .po które zawieraja
>tłumaczenie i także plik .pot który zawiera template pliku który powinien być
>używany o ile chciałbyś zrobić tłumaczenie wszystkich komunikatów do danego
>programu o ile jeszcze nie ma takowego w języku jaki używasz nativ.
Wiesz, to nie ja pisałem ten kod. Podejrzewam, że twórcy Mozilli znają ten
system. Na razie nie widzę w tym nic rewelacyjnego.
>[..]
>> Które sobie dowolnym edytorem tłumaczysz. Ważne, żeby wynik był w UTF-8
>> (możesz użyć odpowiedniego edytora, możesz konwertować).
>
>Wybacz ale po kiego groma mi obsługa UTF skoro mogę użyć konkretnego
>transfer enkodingu ? Jak znam życie to jeszcze zapewne obsługę UTF
>mozilla/netscape ma włąsną (jakbyś nie wiedzieł to glibc ma wsparcie do
>obsługi róznych enkodingów w tym i UTF). W przypadku języka polskiego będzie
>to oczywiście iso-8859-2. Tworząc plik pl.po z polskimi tłumaczeniami do
>jakiegoś programu oczywiście mogę też użyć UTF ale jest to
>niepotrzebne/bardziej skomplikowane niż w przypadku najporstrzym może być.
Podejrzewam, że i w Mozilli da się do zrobić. Nie jest to wcale prostsze, a
zalecenie jest, by używać UTF-8. Ponieważ nie sprawiło mi to kłopotu, więc
używałem go.
>> Nie ma w tym nic trudnego. Dodatkowo jest kilka programów, które to
>> wspomagają. Ja sam napisałem parę skryptów, które robią coś w rodzaju
>> diffa (lista terminów do tłumaczenia, lista terminów usuniętych).
>
>Jeszcze jeden argument za gettext. gettexta używa się praktycznie wszędzie
>(w ten sposób jest umiędzynarodowionych kilka jeśli nie kilkanaście tysiecy
>dostępnych programów, a sumująć to do z pomocą gettext jest zrobione w np.
>Solarisie bezie tego kilkadziesią tysiecy). W kilku jeszcze miejscach używa
>się catgets (też jest wsparcie w libintl/glibc 2.x i przypadku używania
>catgets możnaby policzyć już te przypadki na palcach obu rąk), a tłumaczenie
>w oparciu o XML jakie znasz jest prawktycznie robione w _jednym_ programie
>(mozillę i netscape traktuje tu jako jeden i ten sam produkt co w tym
>wypadku dużym zaokrągleniem nie jest).
Przejdź na http://mozilla.org i zgłoś swoje propozycje. Szczerze mówiąc
wątpię, by Cię wysłuchano, ale spróbuj.
>Jeszcze jedno pytanie: w ilu plikach masz obecne tłumaczenia do mozilli ? bo
>gdybyś miał to w gettex to byłby to pojedynczy plik tekstowy.
Mam w tylu, w ilu są wersje angielskojęzyczne. Zresztą co to ma za
znaczenie?
>> Możesz to robić na dowolnej platformie, ale podałem Windows i Linuxa, gdyż
>> buildy dla tych platform ukazują się najszybciej. Mac odpada z innych
>> względów,
>
>Widać nie przeczytałeś uważnie tego co napisałe. Zerknij jeszcze raz na [1].
>Dodatkowo gettext załatwia także Mac-a.
Przestań mnie pouczać. I raczej Ty przeczytaj, to co napisałem. Ponieważ
wątpię, byś zrozumiał, tłumaczę: lokalizacja działa na wszystkich
platformach, na których działa Mozilla. Windows/Linux to wg mnie optymalne
platformy do jej _dokonywania_.
>Lubię taką zasadę .. KISS się to nazywa (Keep It Simple Stupid). Widać
>programiści z Netscape których dokonania są teraz kulą u nogi w mozilli nie
>znali tej zasady. Ale ja niemniej się pytałem (tak czy inaczej) o to czy
>śledząć (zapewne) dyskusje na devel listach mozilli nie zauważyłeś żeby ktoś
>_wreszcie_ zauważył, że mozilla pod względem szykowania tłumaczeń jest
>niczym czana owca (?) i że wyp* na zbity pysk całego obecnego wsparcia i
>zrobienie tego po ludzku do i18n w mozilli niewątpliwie uprościłoby ten
>program.
Jeżeli czarną owcą nazywasz program, który tłumaczony jest na:
Afrikaans
Arabic
Bengali
Bosnian (bs-BA)
Bulgarian
Catalan
Cherokee
Chinese - Simplified (zh-CN)
Chinese - Hong Kong (zh-HK)
Chinese - Traditional (zh-TW)
Croatian
Czech
Danish (da-DK)
Dutch (NL)
English (en-UK)
Esperanto
Estonian
Finnish
French
Galician
Georgian
German
Greek
Hawaiian
Hebrew
Hungarian
Indonesian
Italian
Japanese
Korean
Malay (ms-MY)
Norwegian (Bokmal)
Norwegian (nynorsk)
Plautdietsch (Mennonite Low German)
Polish
Portuguese (pt-BR; Brazil)
Portuguese (pt-PT
Romanian
Russian
Serbian
Slovak
Slovenian
Spanish (es-ES)
Swedish (sv-SE)
Thai
Turkish
Ukrainian (uk-UA)
Welsh
... to nie mam więcej pytań.
>Jeżeli przez dwa lata pracy nad mozillą nikt na to nie wpadł t ow
>asadzie można już postawić duuży krzyżyk na mozilli (bo będzie to oznaczać,
>że nad mozillą pracuja dyletanci którzy nie mają pojęcia o pewnych
>podstawach których omijanie jest czystej wody głupotą).
No comments.
>I tak jeszcze dalej bajdełejem .. zauważyłeś może jak paskudnie jest pisany
>kod do mozilli ?
Nie.
>ponad 4K na około 16K linni. Zapewne jakby posiedzieć już tylko nad
>pousuwaniem tych ostrzeżeń to stabilność mozilli wzrosłaby odczuwalnie.
Myślę, że to dobry pomysł, posiedź.
Marcin Jagodzinski
(or compatible)
Piotr Sieklucki
:Miros/law `Jubal' Baran <ba...@hell.pl> wrote:
:[..]
:> Jubal, nie cierpiący gettexta.
:
:Że sie głupio spytam: a czego Ci brakuje w gettext ?
Jako współpracownik d/s tłumaczeń pewnego projektu odpowiem tak: RFC 1925,
punkty 3 i 10, a szczególnie 12.
Chociaż w przypadku Mozilli nie wypowiadam się, bo to tak jakby inna skala
projektu.
--
Piotr Sieklucki IA UW student UIN: 3141856 Registered Linux User #134868
_______________________________________________________________________________
Drink Canada Dry! You might not succeed, but it *is* fun trying.
Grzegorz Staniak
>Grzegorz Staniak <gsta...@inka.zagiel.pl> wrote:
[...]
>Odpowiednie narzędzia do gettext pod Win32S powstały niecałe trzy lata temu
>(Cygnus to majstrował). Myślę, że to było raczje przyczyną (netscape jest
>troche starszy).
>
>Niemniej pójście w XML w tym wypadku nie było IMHO czymś co pracę nad
>projektem za bardzo upraszczało.
Nie jestem pewien, czy to _miało_ być proste. Dla prostych zastosowań został
wypuszczony Gecko, którego wreszcie (sam nie wiem dlaczego tak późno) zaczynają
wykorzystywać inni developerzy. Mozilla, niezależnie od tego czy nam się to
podoba czy nie, powwstaje jako platforma, nie browser. Już w tej chwili jest w
tej technologii implementowane wizualne IDE dla języków skryptów i
wielojęzyczny czytnik/translator książek elektronicznych. Przy takich
założeniach zarówno gettext przestaje mieć sens, jak i interfejs budoowany
z XMLa zaczyna mieć sens.
Tomasz Kłoczko
> Tomasz Kłoczko wrote:
>> Grzegorz Staniak <gsta...@inka.zagiel.pl> wrote:
>> > Skoro produkt już jest i jest taki a nie inny, nie uważasz, że można docenić
>> > czyjś wysiłek włożony w jego spolszczenie, zamiast objeżdżać "w imię zasad"?
>> > Czy ktoś Ci każe się Mozillą zachwycać? A jeśli nie podoba Ci się mechanizm
>> > lokalizacji, kto Ci broni ją zgettextować? Źródła są publicznie dostępne.
>>
>> Grzesiek ja się pytałem tylko to czy ktoś o tym myślał. Reszta to tylko
>> oprawka mająca uzmysłowić to dlaczego się pytam i dlaczego odpowiedź na to
>> pytanie może być istotna.
> Być może myślał i prawdopodobnie wyszło mu, że to bez sensu.
> 1. Moilla jest łatwa do sportowania, maksymalnie niezależna od platformy
> systemowej i istnieje niemal pod wszystko, co się rusza (unices z QNX
> włącznie, BeOS, Mac, Windows, nie wiem jak z Amigą, ale nawet dopalona
> może być odrobinę zbyt wolna). To jeden z celów mozilla-team. W takim
> układzie uzależnianie sie od mechanizmów gettext było by tylko kamieniem
> u nogi (TSD - pisałeś, że narzędzia okołogettextowe zostały sportowane
> pod Windows przy użyciu Cygwina czy wymagają jego bibliotek do
> działania?)
Powiedzmy sobie tak, że jeżeli ktoś by pomyślał to nawet jeżeli rózne pliki
źródłowe musiałby być użyte wprzy kompilacji na róznych systemach to
komunikaty i inne teksty oddzieliłby w pliki nagłówkowe (tak jest np.
robione w kilku znanych mi programach w tym np. w tgif).
> 2. Interfejs Mozilli jest pisany w XUL, aplikacji XML.
Też kolejna bzdura. Dzieki temu pracuje to tak jak pracuje. Że też
coponiektórzy nie wuiedzą co to makra w C czy inne wynalazki.
[..]
> 4. Doceniam to, co robisz dla OSS w ogólności a Linuxa w szczególności.
> Ale bardzo nie podoba mi sie opierdalanie "w imię zasad" po pierwsze
> mozilla-team, a po drugie Marcina, który cokolwiek się przy
> tłumaczeniach narobił i którego tłumaczenia są używane. Święte wojny są
> tym, co może skuteczniej załatwić cały ruch OSS niż jakikolwiek FUD ze
> strony MS. Ponadto przydało by się mniej linuxocentryzmu.
Zbyszek po pierwsze nie opierdalam nikogo. Po drugie wytykam błędy i robie
po to żeby dodać tła to pytania jakie zadałem (na nie akurat nie padłą
jeszcze odpowiedź). Po tzrecie: nie mam zamiaru nikogo obrażąć. Po czwarte:
nie mam zamiaru umniejszać niczyjej roli i doceniam to Marcin zrobił i
zagadnąłem go tylko w tym sensie, że gdyby może poparł osoby które o ile są
w zespole mozilli, a które myślą o gettext to jego czy też jego naspców
praca byłaby bardziej efektywana, a produkt końcowy lepszej jakości. Mówiąc
inaczej nie mam zamiaru powyższym wjeżdzać na niczyje osobiste podwórko czy
też kogolowiek się czepać - poruszam wyłącznie strone trechniczną tego
projektu.
Tomasz Kłoczko
[..]
>>Lubię taką zasadę .. KISS się to nazywa (Keep It Simple Stupid). Widać
>>programiści z Netscape których dokonania są teraz kulą u nogi w mozilli nie
>>znali tej zasady. Ale ja niemniej się pytałem (tak czy inaczej) o to czy
>>śledząć (zapewne) dyskusje na devel listach mozilli nie zauważyłeś żeby ktoś
>>_wreszcie_ zauważył, że mozilla pod względem szykowania tłumaczeń jest
>>niczym czana owca (?) i że wyp* na zbity pysk całego obecnego wsparcia i
>>zrobienie tego po ludzku do i18n w mozilli niewątpliwie uprościłoby ten
>>program.
> Jeżeli czarną owcą nazywasz program, który tłumaczony jest na:
[..]
> ... to nie mam więcej pytań.
[kloczek@cenzor SPECS]$ ls -1 /usr/X11R6/share/locale | xargs
af bg bg_BG.cp1251 br ca cs cy cz da de dk el el_GR en en_GB en_UK eo es
es_DO es_ES es_GT es_HN es_MX es_PA es_PE es_SV et eu fi fr ga gd gl gv he
hr hu id is it ja ko kw lt mk nl nn no pl pt pt_BR pt_PT ro ru ru_RU se sk
sl sp sr sr_YU sv tr uk wa zh zh_CN zh_CN.GB2312 zh_TW.Big5
[kloczek@cenzor SPECS]$ ls -1 /usr/X11R6/share/locale | wc -l
69
Co prawda nie mam w tej chwili programu który miałby tłumaczneia na
wszystkie powyższe ale takie które maja ponad 30 wersji jezykowych jest juz
kilka, a znaleźć taki który ma 20 nie jest cieżko. Po co ja to wymieniam ?
Ano po to żeby Ci uświadomić, że osiagnięcie mozilli na tle innych projektów
OSS w tej dziedzinie nie jest niczym szczególnym.
Miros/law `Jubal' Baran
>> 2. Interfejs Mozilli jest pisany w XUL, aplikacji XML.
> Też kolejna bzdura. Dzieki temu pracuje to tak jak pracuje. Że też
> coponiektórzy nie wuiedzą co to makra w C czy inne wynalazki.
Kłoczku, nie pucharyzuj.
Jubal, nie cierpiący gettexta.
--
[ Miros/law L Baran, baran-at-knm-org-pl, neg IQ, cert AI ] [ 0101010 is ]
[ BOF2510053411, makabra.knm.org.pl/~baran/, alchemy pany ] [ The Answer ]
``You don't have to explain something you never said''
-- Calvin Coolidge
Marcin Jagodzinski
wrote:
>[kloczek@cenzor SPECS]$ ls -1 /usr/X11R6/share/locale | xargs
>af bg bg_BG.cp1251 br ca cs cy cz da de dk el el_GR en en_GB en_UK eo es
>es_DO es_ES es_GT es_HN es_MX es_PA es_PE es_SV et eu fi fr ga gd gl gv he
>hr hu id is it ja ko kw lt mk nl nn no pl pt pt_BR pt_PT ro ru ru_RU se sk
>sl sp sr sr_YU sv tr uk wa zh zh_CN zh_CN.GB2312 zh_TW.Big5
>[kloczek@cenzor SPECS]$ ls -1 /usr/X11R6/share/locale | wc -l
> 69
>
>Co prawda nie mam w tej chwili programu który miałby tłumaczneia na
>wszystkie powyższe ale takie które maja ponad 30 wersji jezykowych jest juz
>kilka, a znaleźć taki który ma 20 nie jest cieżko. Po co ja to wymieniam ?
>Ano po to żeby Ci uświadomić, że osiagnięcie mozilli na tle innych projektów
>OSS w tej dziedzinie nie jest niczym szczególnym.
>
A czy ja coś takiego twierdziłem? (Choć jeżeli osiągnięciem jest 30 przy
stabilnej wersji, to myślę, że Mozilla będzie miała > 50)
Ty natomiast twiedziłeś, że produkt, który na etapie alfa/beta ma projekty
tłumaczenia na 48 języków to czarna owca wśród projektów OSS.
Marcin Jagodzinski
(or compatible)
Marcin 'Qrczak' Kowalczyk
> Jubal, nie cierpiący gettexta.
Przydałoby się zaprojektować odpowiednik gettexta dla Haskella.
Dlatego się pytam: jakie są alternatywy o funkcjonalności podobnej do
gettexta, żeby nie wymyślać koła na nowo niepotrzebnie? Chodzi mi nie
tyle o gotowe implementacje, co o pomysły interfejsu i formaty zasobów.
--
__("< Marcin Kowalczyk * qrc...@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
Tomasz Kłoczko
Że sie głupio spytam: a czego Ci brakuje w gettext ?
kloczek
Tomasz Kłoczko
>>wszystkie powyższe ale takie które maja ponad 30 wersji jezykowych jest juz
>>kilka, a znaleźć taki który ma 20 nie jest cieżko. Po co ja to wymieniam ?
>>Ano po to żeby Ci uświadomić, że osiagnięcie mozilli na tle innych projektów
>>OSS w tej dziedzinie nie jest niczym szczególnym.
Nie, nie twierdziłeś ale też wymieniłeś tylko to jako kontrargument, a ja
starałem sie pokazać, że waga tego argumentu nie moze być rozstrzygajaca.
Powyższe popierłeś już tym "co już o tym myśłisz" .. i niczym innym. Gdy
Tymczasem to o czym myślisz o tym mnie nie interesuje lub jak wolisz nie
mogę zajrzeć do Twojej głowy żeby mieć szansę z tym polemizować.
> Ty natomiast twiedziłeś, że produkt, który na etapie alfa/beta ma projekty
> tłumaczenia na 48 języków to czarna owca wśród projektów OSS.
Zauważyłeś to, że spora część tych tłumaczeń (zapewne większość) w różnych
formach była dostępna i dawa lata temu. Mozilla nie powstała niczym Feniks z
popiołów.
Policz ile innych prokjektów OSS aktywnie rozwijany może się pochwalić
dwuletnim okresem bycia w stadium alfa. Może w tedy przynajmniej nieco
inaczej zaczniesz patrzeć na sformułowanie "czarna owca" także z powodu nie
tylko na sposób robienia wersji narodowych zasobów.
Nie chcę wnikać za mocno w naturę statusu mozilli (nie interesuje mnie to i
nie to jest ttym co mnie interesowało od oczątku tego wątku). Co najwyżej
interesuje mnie zasadność stosowanai takich, a nie innych rozwiązań
technicznych. Powyższe (bycie czarna owcą) to tylko stwierdzenie faktu.
Faktem jest także to, że pojawienie sie źródeł mozilli dało dużego kopa
innym projektom. Np. w różnych rzeczach z GNOME od samego początku
posiłowano się tym jak obsługiwać ORB wąłsnie tym jak to było zrobione w
mozilli i kilka osób zamieszanych w te modyfikacje jawnie przyznaje się od
inspirowania tymi źródłami i że im znacznie te prace te źródłą ułatwiły.
To wszystko nie zmienia faktu, że netscape w zasadzie _permamentnie_ ma
sporo błędów. Zapewne część w nich wynika właśnie z tego, że netscape jest
"broken by design". Mozilla nie mogła niedzidiczyć tego bagażu.
Powiedziałbym, że to że netscape pod postacią mozilli stało się apliakcją
OSS w zasadzie usuwanie tego typu błędów będzie wogóle umożliwiać (i juz
zapewne umożliwiło w przypadku tych które zostały usunięte). Gdyby było
możliwe rozstrzygniecię zakładu o to czy słaba jakość samego projektu
ułatwiła wręcz to, że Netscape udało się przekonać do tego żeby udostępnili
publicznie źródła tego programu to zapewniam Cie że _zrobiłbym to_. Reszta w
tym w i obecna forma mozilli jest już tylko konsekwencją duużo
wcześniejszych wydarzeń. Tak czy inaczej jeżeli jeszcze tego nie zauważasz -
powysze nie dotyka w najmniejszym stopniu Ciebie, a z racjie tego że sam
próbujesz coś zmieniać .. wręcz odwrotnie.
Tomasz Kłoczko
>> Miros/law `Jubal' Baran <ba...@hell.pl> wrote:
>> [..]
>>> Jubal, nie cierpiący gettexta.
>> Że sie głupio spytam: a czego Ci brakuje w gettext ?
> Funkcjonalności. Dostosowania do języków z nieregularną fleksją, u
> licha, _w ogóle_ dostosowania do języków fleksyjnych.
Wybacz ale kompletnie nie rozumię co ma fleksyjniość tego czy innego
języka do tego czym gettext jest, a czym nie jest.
> Mniejszej C-zależności.
Przecież to jest kompletnie niezależne od C. To, ze w podstawowym zestawie
_narzędzi_ masz to co jest Ci potrzebne do obróbki C to jest zupełnie inna
para kalocszy. MAsz wsparcie do gettext na poziomie shalla (polecenie
gettext), mnasz to w php, masz odpowiednie nzrzędzia do pythona, perla.
Brak Ci jeszcze jakiegoś jezyka to dorób narzędzia ale zauważ, że dorabiając
je nie beziesz musiał nic zmieniać w tym co już jest i jeżeli to zauważysz
to pzrestaniesz zapewne mówić o jakimś dostosowaniu do jezyków fleksyjnych
czy zalezności od C.
> Do tego drażni mnie, że zacytuję samego siebie z innego forum: ,,fakt, że
> liczba wyspecyfikowanych zmiennych musi się zgadzać we wszystkich wersjach
> językowych'', co nadal uważam za ,,błąd w założeniach, [popełniony] przy
> projektowaniu biblioteki''
Chyba jakiś kolejny błąd tu popełniasz.
Tomasz Kłoczko
> Pewnego dnia, a było to 12 Sep 2000 18:16:31 GMT przyszła do mnie
> wiadomość z adresu <klo...@rudy.mif.pg.gda.pl> i powiedziała:
> [..]
>>> 2. Interfejs Mozilli jest pisany w XUL, aplikacji XML.
>>
>>Też kolejna bzdura. Dzieki temu pracuje to tak jak pracuje. Że też
>>coponiektórzy nie wuiedzą co to makra w C czy inne wynalazki.
> Jej, Kłoczko I Nieomylny. Otóż wyobraź sobie, że programy w C będą traciły
> na znaczeniu. Wchodzą inne techniki.
Gdzieś już taki test widziałam ale to chyba jakieś dziesięć lat temu.
Marcin Jagodzinski
wrote:
>Marcin Jagodzinski <pisz_na_adre...@webcorp.com.pl> wrote:
>[..]
>>>Co prawda nie mam w tej chwili programu który miałby tłumaczneia na
>>>wszystkie powyższe ale takie które maja ponad 30 wersji jezykowych jest juz
>>>kilka, a znaleźć taki który ma 20 nie jest cieżko. Po co ja to wymieniam ?
>>>Ano po to żeby Ci uświadomić, że osiagnięcie mozilli na tle innych projektów
>>>OSS w tej dziedzinie nie jest niczym szczególnym.
>
>Nie, nie twierdziłeś ale też wymieniłeś tylko to jako kontrargument, a ja
>starałem sie pokazać, że waga tego argumentu nie moze być rozstrzygajaca.
>Powyższe popierłeś już tym "co już o tym myśłisz" .. i niczym innym. Gdy
>Tymczasem to o czym myślisz o tym mnie nie interesuje lub jak wolisz nie
>mogę zajrzeć do Twojej głowy żeby mieć szansę z tym polemizować.
To był kontrargument na "czarną owcę". Skuteczny jak sądzę.
>> Ty natomiast twiedziłeś, że produkt, który na etapie alfa/beta ma projekty
>> tłumaczenia na 48 języków to czarna owca wśród projektów OSS.
>
>Zauważyłeś to, że spora część tych tłumaczeń (zapewne większość) w różnych
>formach była dostępna i dawa lata temu. Mozilla nie powstała niczym Feniks z
>popiołów.
Trudno to ocenić. Choćby polska wersja powstaje niezależnie od Sylaby
(chyba, że zaraz ktoś powie, że uzus sankcjonuje użycie słowa "wprzód"). Co
do innych -- nie wiem.
>Policz ile innych prokjektów OSS aktywnie rozwijany może się pochwalić
>dwuletnim okresem bycia w stadium alfa. Może w tedy przynajmniej nieco
>inaczej zaczniesz patrzeć na sformułowanie "czarna owca" także z powodu nie
>tylko na sposób robienia wersji narodowych zasobów.
Niestety, nie jestem kompetentny, żeby to oceniać. Starałem się dołożyć
jakąś swoją cegiełkę do całości. Niech inni pracują jak najlepiej. Nie
oceniam ich.
>Nie chcę wnikać za mocno w naturę statusu mozilli (nie interesuje mnie to i
>nie to jest ttym co mnie interesowało od oczątku tego wątku). Co najwyżej
>interesuje mnie zasadność stosowanai takich, a nie innych rozwiązań
>technicznych. Powyższe (bycie czarna owcą) to tylko stwierdzenie faktu.
>Faktem jest także to, że pojawienie sie źródeł mozilli dało dużego kopa
>innym projektom. Np. w różnych rzeczach z GNOME od samego początku
>posiłowano się tym jak obsługiwać ORB wąłsnie tym jak to było zrobione w
>mozilli i kilka osób zamieszanych w te modyfikacje jawnie przyznaje się od
>inspirowania tymi źródłami i że im znacznie te prace te źródłą ułatwiły.
To miłe.
>To wszystko nie zmienia faktu, że netscape w zasadzie _permamentnie_ ma
>sporo błędów. Zapewne część w nich wynika właśnie z tego, że netscape jest
>"broken by design". Mozilla nie mogła niedzidiczyć tego bagażu.
Nie dziedziczy. To "dwa lata w fazie alfa" wynika z tego, że jest pisana od
nowa.
Marcin Jagodzinski
(or compatible)
PS. Ale pewnie wprowadza nowe błędy ;-)
Krzysztof Krzyżaniak
wiadomość z adresu <klo...@rudy.mif.pg.gda.pl> i powiedziała:
[..]
>> 2. Interfejs Mozilli jest pisany w XUL, aplikacji XML.
>
>Też kolejna bzdura. Dzieki temu pracuje to tak jak pracuje. Że też
>coponiektórzy nie wuiedzą co to makra w C czy inne wynalazki.
Jej, Kłoczko I Nieomylny. Otóż wyobraź sobie, że programy w C będą traciły
na znaczeniu. Wchodzą inne techniki.
eloy
--
Krzysztof `eloy' Krzyżaniak | "Polska A Polsce B
<el...@transilvania.eu.org> : Każe się całować w D."
Krzysztof Krzyżaniak
wiadomość z adresu <qrc...@knm.org.pl> i powiedziała:
>12 Sep 2000 19:30:03 GMT, Miros/law `Jubal' Baran <ba...@hell.pl> pisze:
>
>> Jubal, nie cierpiący gettexta.
>
>Przydałoby się zaprojektować odpowiednik gettexta dla Haskella.
>Dlatego się pytam: jakie są alternatywy o funkcjonalności podobnej do
>gettexta, żeby nie wymyślać koła na nowo niepotrzebnie? Chodzi mi nie
>tyle o gotowe implementacje, co o pomysły interfejsu i formaty zasobów.
A ma haskell tablice haszujące (asocjacyjne)?
eloy
--
Krzysztof `eloy' Krzyżaniak | "Naga - to ona nie była wcale,
<el...@transilvania.eu.org> : Miała pończochy i korale!"
Miros/law `Jubal' Baran
> Miros/law `Jubal' Baran <ba...@hell.pl> wrote:
> [..]
>> Jubal, nie cierpiący gettexta.
> Że sie głupio spytam: a czego Ci brakuje w gettext ?
Funkcjonalności. Dostosowania do języków z nieregularną fleksją, u
licha, _w ogóle_ dostosowania do języków fleksyjnych. Mniejszej
C-zależności. Do tego drażni mnie, że zacytuję samego siebie z innego
forum: ,,fakt, że liczba wyspecyfikowanych zmiennych musi się zgadzać
we wszystkich wersjach językowych'', co nadal uważam za ,,błąd w
założeniach, [popełniony] przy projektowaniu biblioteki''
pozdrawiam,
Jubal
--
[ Miros/law L Baran, baran-at-knm-org-pl, neg IQ, cert AI ] [ 0101010 is ]
[ BOF2510053411, makabra.knm.org.pl/~baran/, alchemy pany ] [ The Answer ]
IOT trap -- mos dumped
Marcin 'Qrczak' Kowalczyk
> >Przydałoby się zaprojektować odpowiednik gettexta dla Haskella.
> >Dlatego się pytam: jakie są alternatywy o funkcjonalności podobnej do
> >gettexta, żeby nie wymyślać koła na nowo niepotrzebnie? Chodzi mi nie
> >tyle o gotowe implementacje, co o pomysły interfejsu i formaty zasobów.
>
> A ma haskell tablice haszujące (asocjacyjne)?
Ma.
Krzysztof Krzyżaniak
wiadomość z adresu <qrc...@knm.org.pl> i powiedziała:
>13 Sep 2000 08:20:22 GMT, Krzysztof Krzyżaniak <el...@pawnhearts.eu.org> pisze:
>
>> >Przydałoby się zaprojektować odpowiednik gettexta dla Haskella.
>> >Dlatego się pytam: jakie są alternatywy o funkcjonalności podobnej do
>> >gettexta, żeby nie wymyślać koła na nowo niepotrzebnie? Chodzi mi nie
>> >tyle o gotowe implementacje, co o pomysły interfejsu i formaty zasobów.
>>
>> A ma haskell tablice haszujące (asocjacyjne)?
>
>Ma.
No to może się na tym oprzeć? Jeśli można je indeksować wyrazami (najlepiej
zapisywanymi w unikodzie) to rozwiązywałoby sprawę zapisu zasobów.
Oczywiście teoretyzuje, ale wydaje mi się to dobrym rozwiązaniem.
eloy
--
. . . , . ,
| _ __. _.|_| |_| Krzysztof "eloy" Krzyżaniak <el...@pawnhearts.eu.org>
|(_) /_(_] | | Oficjalna strona kabaretu Loża 44 http://loza44.topnet.pl/
Wieczie - cziuroń to jest taka old polish folk-tradycja...
Grzegorz Staniak
[...]
>To wszystko nie zmienia faktu, że netscape w zasadzie _permamentnie_ ma
>sporo błędów. Zapewne część w nich wynika właśnie z tego, że netscape jest
>"broken by design". Mozilla nie mogła niedzidiczyć tego bagażu.
Mozilla nie ma w zasadzie nic wspólnego ze źródłami Netscape'a. Spora część
tego dwuletniego (zbyt długiego, jak wielu twierdzi) okresu powstawania została
zmarnowana przez początkową decyzję oparcia się na otwartych wcześniej źródłach
Netscape'a, a tak naprawdę postępy zaczęły się od decyzji przepisania całości
od podstaw.
>Powiedziałbym, że to że netscape pod postacią mozilli stało się apliakcją
>OSS w zasadzie usuwanie tego typu błędów będzie wogóle umożliwiać (i juz
>zapewne umożliwiło w przypadku tych które zostały usunięte). Gdyby było
>możliwe rozstrzygniecię zakładu o to czy słaba jakość samego projektu
>ułatwiła wręcz to, że Netscape udało się przekonać do tego żeby udostępnili
>publicznie źródła tego programu to zapewniam Cie że _zrobiłbym to_. Reszta w
>tym w i obecna forma mozilli jest już tylko konsekwencją duużo
>wcześniejszych wydarzeń. Tak czy inaczej jeżeli jeszcze tego nie zauważasz -
>powysze nie dotyka w najmniejszym stopniu Ciebie, a z racjie tego że sam
>próbujesz coś zmieniać .. wręcz odwrotnie.
>
>kloczek
--
Grzegorz Staniak <gsta...@zagiel.pl>
Marcin 'Qrczak' Kowalczyk
> Dostosowania do języków z nieregularną fleksją, u licha, _w ogóle_
> dostosowania do języków fleksyjnych.
Jak by to mogło wyglądać zrobione dobrze?
> Do tego drażni mnie, że zacytuję samego siebie z innego forum:
> ,,fakt, że liczba wyspecyfikowanych zmiennych musi się zgadzać
> we wszystkich wersjach językowych'', co nadal uważam za ,,błąd w
> założeniach, [popełniony] przy projektowaniu biblioteki''
A tutaj?
Miros/law `Jubal' Baran
> 13 Sep 2000 08:38:50 GMT, Miros/law `Jubal' Baran <ba...@hell.pl> pisze:
>> Dostosowania do języków z nieregularną fleksją, u licha, _w ogóle_
>> dostosowania do języków fleksyjnych.
> Jak by to mogło wyglądać zrobione dobrze?
Hm, dla polskiego i języków słowiańskich wystarczyłoby natywne wsparcie
dla takiego prostego faktu, że dopełniacz liczby mnogiej może mieć
kilka form w zależności od ilości... Bo zwykle w komunikatach potrzebne
są: lp, lmn + dopełniacze -- ale szczegółowe rozwiązania trzeba by
jeszcze uzgodnić z użytkownikami bardziej skomplikowanych języków... W
tej chwili, o ile pamiętam, osiąga się to przez mniej lub bardziej
porąbane protezowanie...
>> Do tego drażni mnie, że zacytuję samego siebie z innego forum:
>> ,,fakt, że liczba wyspecyfikowanych zmiennych musi się zgadzać
>> we wszystkich wersjach językowych'', co nadal uważam za ,,błąd w
>> założeniach, [popełniony] przy projektowaniu biblioteki''
> A tutaj?
A tutaj dobrze byłoby mieć możliwość pominięcia niektórych danych z
tekstu oryginalnego lub też zmiany ich kolejności (co do drugiego, nie
mam pojęcia czy to nie jest możliwe, ale podejrzewam, że raczej nie...)
pozdrawiam,
Jubal
--
[ Miros/law L Baran, baran-at-knm-org-pl, neg IQ, cert AI ] [ 0101010 is ]
[ BOF2510053411, makabra.knm.org.pl/~baran/, alchemy pany ] [ The Answer ]
Be free and open and breezy! Enjoy! Things won't get any better
so get used to it.
Marcin 'Qrczak' Kowalczyk
> No to może się na tym oprzeć? Jeśli można je indeksować wyrazami
> (najlepiej zapisywanymi w unikodzie) to rozwiązywałoby sprawę
> zapisu zasobów.
Takie podstawowe sprawy to nie problem. Problemy mogą być takie:
- Zakładając, że kluczami są teksty po angielsku, używane kiedy nie
znaleziono tłumaczenia (jak w gettekście), może być tak że dany napis
tłumaczy się nie zawsze tak samo.
Można to obejść dodając do klucza i tłumaczeń przedrostek, który
się odetnie od wyniku tłumaczenia, ale może ktoś wpadł na bardziej
elegancki pomysł.
- Różne języki mogą wymagać różnych form rzeczowników albo
przymiotników stojących przy liczbach. Każdy język może wymagać
osobnych algorytmów na różne sytuacje. Trzeba do tego dopasować
przechowywanie tłumaczonych tekstów w zasobach.
- Sam format zasobów. Może można użyć formatu gettexta; nie wiem,
jak łatwo jest się do niego dobrać samemu. Wolałbym nie uzależniać
programów od dodatkowych bibliotek.
Z drugiej strony, przyda się możliwość użycia gotowych narzędzi
do edycji zasobów. Nie wiem, co oprócz gettexta ma wsparcie np.
w Emacsie, albo narzędzia ułatwiające aktualizację tłumaczeń kiedy
program się zmienia (wyciągnięcie napisów do tłumaczenia jest
oczywiście zależne od języka programowania, ale to nie wszystko).
- To powinno być przenośne, na Windowsy też.
- W Haskellu naturalny sposób wypisania tekstu zawierającego wstawione
dane osobno określa fragmenty tekstu między tymi danymi - bez
formatu w jednym kawałku, jak by to było w przypadku printfa. To się
niestety gorzej tłumaczy: wyrwane z kontekstu fragmenty tekstu mogą
częściej powodować kolizje wymagające różnych tłumaczeń, poza tym
różne języki mogą domagać się różnej kolejności danych.
Funkcja wstawiająca fragmenty w ponumerowane miejsca formatu zajmie
kilkanaście linijek, to żaden problem, ale to jest tworzenie kolejnej
konwencji. Wolałbym użyć czegoś gotowego na format formatu, o ile
coś będzie się nadawać.
Konwencja printfa niezbyt się nadaje. Jedynym użytym formatem byłby
"%s" bez parametrów w stylu szerokości pola, a samo określenie
pozycji w glibcowym printfie nie wygląda najładniej: "%7$s".
Bardziej pasuje mi coś w stylu $7 (na parametry 1-9) i ${14}
(na więcej niż 9), zawsze z numerami pozycji.
- Różne moduły mają własne teksty do tłumaczenia. Trzeba opracować
jakiś sposób postępowania, żeby składać zestawy tłumaczeń modułów
użytych w programie. Może ktoś gdzieś zastosował jakieś ciekawe
pomysły dystrybucji tłumaczeń.
- Haskell nie ma jeszcze innych elementów obsługi locale
(np. pokazywanie czasu). To też by się przydało zrobić.
Jeśli chodzi o zestawy znaków, to Haskell wewnętrznie używa Unikodu
(co od ponad dwóch lat jest zapisane w standardzie, ale do niedawna
było rzeczywistością tylko w jednej implementacji na cztery mi
znane; teraz staje się rzeczywistością w drugiej). Mechanizmy
konwersji zestawów znaków, niezbędne dla wejścia-wyjścia, to osobna
historia. To też trzeba zaprojektować i zaimplementować. Na razie idzie
mi to dość sprawnie, prototyp działa, ale mam wątpliwości. Z tych
niezależnych od języka największym problemem jest dostanie
się do "domyślnego lokalnego kodowania" i konwersja między
nim a Unikodem. Pod Linuksem są na to różne metody, a każda ma
wady; pod innymi systemami jeszcze mniej wiem, jak to najlepiej
zrobić. Ale nie wszystko naraz.
Tomasz Kłoczko
> Also sprach Tomasz Kłoczko:
> :Miros/law `Jubal' Baran <ba...@hell.pl> wrote:
> :[..]
> :> Jubal, nie cierpiący gettexta.
> :
> :Że sie głupio spytam: a czego Ci brakuje w gettext ?
> Jako współpracownik d/s tłumaczeń pewnego projektu odpowiem tak: RFC 1925,
> punkty 3 i 10, a szczególnie 12.
He .. :_)
No dobra a co w takim razie możesz powiedzieć wa sprawie "tłumaczenia
pewnego projektu" ? Czyli jakie Twoim zdaniem są te konsekwencje związane z
RFC 1925 punkt 10 ? (bo temat IMHO jdnak wymaga rozwinięcia, bo inaczej
tenże punk w tym wypadku pozostanie tylko hipotezą którą należałoby
udowaodnić :)
Miros/law `Jubal' Baran
> Miros/law `Jubal' Baran <ba...@hell.pl> wrote:
>> PT Tomasz Kłoczko pisze:
>>> Miros/law `Jubal' Baran <ba...@hell.pl> wrote:
>>> [..]
>>>> Jubal, nie cierpiący gettexta.
>>> Że sie głupio spytam: a czego Ci brakuje w gettext ?
>> Funkcjonalności. Dostosowania do języków z nieregularną fleksją, u
>> licha, _w ogóle_ dostosowania do języków fleksyjnych.
> Wybacz ale kompletnie nie rozumię co ma fleksyjniość tego czy innego
> języka do tego czym gettext jest, a czym nie jest.
Wybacz, zaiste trudno oczekiwać od Kłoczka, aby rozumiał słowo pisane.
Zwłaszcza po polsku, a nie w Jedynie Słusznym Języku Programowania. Ale
spróbuję: fakt, że gettext jest niedostosowany do istnienia języków
fleksyjnych z nieregularną fleksją powoduje konieczność protezowania
gettexta dla różnicy między mianownikiem l.mn. dla np. dwóch i pięciu
marek (por. `mamy tu dwie marki', `mamy tu pięć marek'). Czy teraz
mniej więcej jasne?
>> Mniejszej C-zależności.
> Przecież to jest kompletnie niezależne od C. To, ze w podstawowym
> zestawie _narzędzi_ masz to co jest Ci potrzebne do obróbki C to jest
> zupełnie inna para kalocszy. MAsz wsparcie do gettext na poziomie
> shalla (polecenie gettext), mnasz to w php, masz odpowiednie
> nzrzędzia do pythona, perla. Brak Ci jeszcze jakiegoś jezyka to dorób
> narzędzia ale zauważ, że dorabiając je nie beziesz musiał nic
> zmieniać w tym co już jest i jeżeli to zauważysz to pzrestaniesz
> zapewne mówić o jakimś dostosowaniu do jezyków fleksyjnych czy
> zalezności od C.
Kłoczku; mówiąc C-zależność nie miałem na myśli tego, że zmusza do
wykorzystywania języka C. Mówiąc C-zależność miałem na myśli, że
gettext został zaprojektowany dla języka C i w związku z tym zawiera
konstrukcje dla języka C specyficzne. Jasne, czy mam opłacić tłumacza?
>> Do tego drażni mnie, że zacytuję samego siebie z innego forum:
>> ,,fakt, że liczba wyspecyfikowanych zmiennych musi się zgadzać we
>> wszystkich wersjach językowych'', co nadal uważam za ,,błąd w
>> założeniach, [popełniony] przy projektowaniu biblioteki''
> Chyba jakiś kolejny błąd tu popełniasz.
O, o. Wykaż poprzednie, skoro mówisz ,,kolejny'', Mistrzu. Polecam
uprzednie zapoznanie się z <2000062714...@free.buy.pl> (lista
tłumaczeń p...@li.org).
Jubal, lekko zirytowany.
--
[ Miros/law L Baran, baran-at-knm-org-pl, neg IQ, cert AI ] [ 0101010 is ]
[ BOF2510053411, makabra.knm.org.pl/~baran/, alchemy pany ] [ The Answer ]
She is not refined. She is not unrefined. She keeps a parrot.
-- Mark Twain
Piotr Sieklucki
:> :Że sie głupio spytam: a czego Ci brakuje w gettext ?
:
:> Jako współpracownik d/s tłumaczeń pewnego projektu odpowiem tak: RFC 1925,
:> punkty 3 i 10, a szczególnie 12.
:
:He .. :_)
:No dobra a co w takim razie możesz powiedzieć wa sprawie "tłumaczenia
:pewnego projektu" ? Czyli jakie Twoim zdaniem są te konsekwencje związane z
:RFC 1925 punkt 10 ? (bo temat IMHO jdnak wymaga rozwinięcia, bo inaczej
:tenże punk w tym wypadku pozostanie tylko hipotezą którą należałoby
:udowaodnić :)
Chodzi mi o to, że gettext, jaki by nie był, jest artylerią dość ciężkiego
kalibru. O ile w projektach klasy/wielkości Mozilla [1] jego użycie nie
stanowi problemu (typu nad techniczną stroną tłumaczen spędza się więcej
czasu, niż nad tłumaczeniami[2]), to w małych programach [3] jest to
IMVVHO overkill -- wystarczą czyste pliki tekstowe z tłumaczeniami [4]
parsowane (via zmienne) i podawane do generatora komunikatów. KISS.
[1] Abstrahując od celowości użycia gettexta w Mozilli jako takiej, jeśli
niezbędne elementy już są i tak zawarte w programie.
[2] Poza tym jest (?) konkretna osoba odpowiedzialna tylko i wyłącznie za
tłumaczenia, ma nad tym jakąś kontrolę, zna gettexta etc.
[3] Chwilowo jakieś 20k linii kodu.
[4] Szczególnie że chwilowo robimy wsparcie dla angielskiego i polskiego,
więc wystarcza nam iso8859-2; jeśli będzie potrzeba więcej, to zapewne użyje
się unicode.
--
Piotr Sieklucki IA UW student UIN: 3141856 Registered Linux User #134868
_______________________________________________________________________________
Universe, n.: the problem.
Tomasz Kłoczko
> Also sprach Tomasz Kłoczko:
> :> :Że sie głupio spytam: a czego Ci brakuje w gettext ?
> :
> :> Jako współpracownik d/s tłumaczeń pewnego projektu odpowiem tak: RFC 1925,
> :> punkty 3 i 10, a szczególnie 12.
> :
> :He .. :_)
> :No dobra a co w takim razie możesz powiedzieć wa sprawie "tłumaczenia
> :pewnego projektu" ? Czyli jakie Twoim zdaniem są te konsekwencje związane z
> :RFC 1925 punkt 10 ? (bo temat IMHO jdnak wymaga rozwinięcia, bo inaczej
> :tenże punk w tym wypadku pozostanie tylko hipotezą którą należałoby
> :udowaodnić :)
> Chodzi mi o to, że gettext, jaki by nie był, jest artylerią dość ciężkiego
> kalibru. O ile w projektach klasy/wielkości Mozilla [1] jego użycie nie
> stanowi problemu (typu nad techniczną stroną tłumaczen spędza się więcej
> czasu, niż nad tłumaczeniami[2]), to w małych programach [3] jest to
> IMVVHO overkill -- wystarczą czyste pliki tekstowe z tłumaczeniami [4]
> parsowane (via zmienne) i podawane do generatora komunikatów. KISS.
Niestety mylisz się. Twoje pliki tekstowe i ich obsługiwanie zeżre Ci
*dużo* więcej energi i czasu niż dołożenie wsparcia do gettext. Z kilkoma
narzędziami które są dołączane do zestawu narzędzi możesz wręcz
automatycznie modyfikować źródła w celu oznaczenia tego co powinno podlegać
tłumaczeniom (post factum co najwyżej jeszcze się to koryguje ręcznie).
Dołożenie wsparcia do automake/autoconf zajmie następne pięć minut (co
oszcżedi kolejna porcje czasu na preparowanie wąłsnych Makefile), a dalsze
modyfikacja ac/am do gettext (dołożenie jednego makra i jednej zmiennej)
następne dwie minuty. Do tego dochodzi dołożenie w main() wywołanie kilku
linijek z zainicjowaniem całości. W sumie może się okazać, że w przypadku
małego programu składajacego się z paru plików źródłowych już po parunastu
minuttach zajmujesz się już niczym innym tylko preparowaniem tłumaczeń. Sam
takie rzeczy robiłem już wielokrotnie i jeżeli nie wierzysz to pokażę Ci
logi z cvs.pld.org.pl w których na podstawie czasów między kolejnymi
modyfikacjami będzies mógł sam zobaczyć ile to trwało w konkretnych
przypadkach, i że czas parunastu minut jest tu jaknajbardziej realny. Robiąt
w plikach tekstowych (po swojemu) zakład, że będziesz to robił conajmniej
kika(naście) razy dłuzej. Po drodze zdążysz jeszcze zrobić kilka błędów.
Mówiąc inaczej - to że mówisz, ze gettext jest typowym overkill świadczyć
raczje moze, ze tak naprawdę nie wiesz o czym mówisz i/lub sam takich
operacji jak przystosowanie do gettexta nie robiłeś (i Twój pogląd wynika li
tylk oz niewiedzy, a zapewne jakbyś to poznał to byś zmienił zdanie).
Wbrew pozorom gettext jest mocno nieskomplikowanym mechanizmem (możnaby
rzecz, że jest raczej niesamowicie prymitywny) i daletego pytałem się
ewentualnie czego komuś może w tym zwierzaku brakować.
Tomasz Kłoczko
> Zwłaszcza po polsku, a nie w Jedynie Słusznym Języku Programowania. Ale
> spróbuję: fakt, że gettext jest niedostosowany do istnienia języków
> fleksyjnych z nieregularną fleksją powoduje konieczność protezowania
> gettexta dla różnicy między mianownikiem l.mn. dla np. dwóch i pięciu
> marek (por. `mamy tu dwie marki', `mamy tu pięć marek'). Czy teraz
> mniej więcej jasne?
Wiesz nie obraziłeś mnie. Obraziłbyś mnie gdybyś podał jakieś inne logicze i
funkcjonujące rozwiazanie powyższego (ilość możliwych form w różnych
tłumaczeniach jest na tyle duża w odniesieniu do języków do których
miząłoby być to stosowane, że zagadnienie do dzisiaj w zasadzie nie ma
jasnego rozwiązania). Nie ma rozwiązania -> ergo nie ma sensu zderzać się z
nim wprost i co też jest doładnie praktykowane. Dokładnie z takiego
załozenia wyszli twórcy gettexta (co zreszta znajdziesz w dokumentacji do
gettext).
[..]
>> Przecież to jest kompletnie niezależne od C. To, ze w podstawowym
>> zestawie _narzędzi_ masz to co jest Ci potrzebne do obróbki C to jest
>> zupełnie inna para kalocszy. MAsz wsparcie do gettext na poziomie
>> shalla (polecenie gettext), mnasz to w php, masz odpowiednie
>> nzrzędzia do pythona, perla. Brak Ci jeszcze jakiegoś jezyka to dorób
>> narzędzia ale zauważ, że dorabiając je nie beziesz musiał nic
>> zmieniać w tym co już jest i jeżeli to zauważysz to pzrestaniesz
>> zapewne mówić o jakimś dostosowaniu do jezyków fleksyjnych czy
>> zalezności od C.
> Kłoczku; mówiąc C-zależność nie miałem na myśli tego, że zmusza do
> wykorzystywania języka C. Mówiąc C-zależność miałem na myśli, że
> gettext został zaprojektowany dla języka C i w związku z tym zawiera
> konstrukcje dla języka C specyficzne. Jasne, czy mam opłacić tłumacza?
Echem .. jednak się mylisz. Pierwsza implementacja powstała dla języka C ale
sam mehaniz i spsób operowanai na frazach z C nie ma mniej więcej taki
związek jak chodzące stopy z trampkami (równie dobrze możesz chodzić w
walonkach albo i wogóle bez obuwia .. używając np. w shellu i to dowolnym
polecenia gettext; taki bash gettexta wspiera wręcz wprost bez używanai
gettext). Jeżeli lubisz drewniaki czy inne takie to nic nie stoi na
przeszkodzie żeby je założył na nogę i poszedł gdzie Cie oczy poniosą .. ot
i cała magia.
>>> Do tego drażni mnie, że zacytuję samego siebie z innego forum:
>>> ,,fakt, że liczba wyspecyfikowanych zmiennych musi się zgadzać we
>>> wszystkich wersjach językowych'', co nadal uważam za ,,błąd w
>>> założeniach, [popełniony] przy projektowaniu biblioteki''
>> Chyba jakiś kolejny błąd tu popełniasz.
> O, o. Wykaż poprzednie, skoro mówisz ,,kolejny'', Mistrzu. Polecam
> uprzednie zapoznanie się z <2000062714...@free.buy.pl> (lista
> tłumaczeń p...@li.org).
Z kilkanaście razy tyle programów zupełnie samopas istnieje po za tą listą.
[1] - polecam przyjrzenie sie rc-scripts z PLD (skrypty startowe). Cały
zestaw skryptów w POSIX sh potrafiący gadać po polsku po przestawieniu
jednej zmiennej w konfiguracji - wygląda to conajmniej zabawnie i przyznam,
że i także dość przyjemnie dla oka :)
Miros/law `Jubal' Baran
[duże ciach, nie mam siły tłumaczyć.]
[nastęne ciach, nie mam siły tłumaczyć.]
Wiesz, nie zawadziłoby, żebyś przeczytał, co napisałem, bo mówię o
czymś innym. A jak tak dalej pójdzie, znowu zaproponujesz przepisanie
TeXa w C... ;-/
>>>> Do tego drażni mnie, że zacytuję samego siebie z innego forum:
>>>> ,,fakt, że liczba wyspecyfikowanych zmiennych musi się zgadzać we
>>>> wszystkich wersjach językowych'', co nadal uważam za ,,błąd w
>>>> założeniach, [popełniony] przy projektowaniu biblioteki''
>>> Chyba jakiś kolejny błąd tu popełniasz.
>> O, o. Wykaż poprzednie, skoro mówisz ,,kolejny'', Mistrzu. Polecam
>> uprzednie zapoznanie się z <2000062714...@free.buy.pl> (lista
>> tłumaczeń p...@li.org).
> Z kilkanaście razy tyle programów zupełnie samopas istnieje po za tą listą.
Proponuję jednak przeczytać list, który zacytowałem w postaci MsgID.
> [1] - polecam przyjrzenie sie rc-scripts z PLD (skrypty startowe). Cały
> zestaw skryptów w POSIX sh potrafiący gadać po polsku po przestawieniu
> jednej zmiennej w konfiguracji - wygląda to conajmniej zabawnie i przyznam,
> że i także dość przyjemnie dla oka :)
A co to ma do rzeczy? I.e. do tej dyskusji?
Jubal
--
[ Miros/law L Baran, baran-at-knm-org-pl, neg IQ, cert AI ] [ 0101010 is ]
[ BOF2510053411, makabra.knm.org.pl/~baran/, alchemy pany ] [ The Answer ]
Fast ship? You mean you've never heard of the Millennium Falcon?
Tomasz Kłoczko
Że gettext nie jest zwiazany z C lub ten zwiazek jest taki sam jak z
dowolnym innym jezykiem.
Miros/law `Jubal' Baran
> Miros/law `Jubal' Baran <ba...@hell.pl> wrote:
> [..]
>> A co to ma do rzeczy? I.e. do tej dyskusji?
> Że gettext nie jest zwiazany z C lub ten zwiazek jest taki sam jak z
> dowolnym innym jezykiem.
Używanie standardowych oznaczeń zmiennych z C (%s, %d etc.) to
oczywiście tylko złudzenie apteczne... Jak również owo ograniczenie, o
którym pisałem, a które -- bez sprawdzenia -- nazwałeś moim błędem.
Jubal
--
[ Miros/law L Baran, baran-at-knm-org-pl, neg IQ, cert AI ] [ 0101010 is ]
[ BOF2510053411, makabra.knm.org.pl/~baran/, alchemy pany ] [ The Answer ]
Offering a unicorn a worthless piece of glass might prove to be fatal!
Piotr Sieklucki
:Mówiąc inaczej - to że mówisz, ze gettext jest typowym overkill świadczyć
:raczje moze, ze tak naprawdę nie wiesz o czym mówisz i/lub sam takich
:operacji jak przystosowanie do gettexta nie robiłeś (i Twój pogląd wynika li
:tylk oz niewiedzy, a zapewne jakbyś to poznał to byś zmienił zdanie).
Przystosowania do gettexta nie robiłem, prawda. Ja patrzę z punktu widzenia
osoby robiącej samo tłumaczenie, a nie jego obsługę -- mi po prostu
wygodniej obsługiwać czyste pliki tekstowe, niż babrać się z gettextem. Żeby
nie było: gettexta też używam (w innym projekcie), więc wiem o czym mówię.
Sprawa zapewne wygląda inaczej ze strony osób zajmujących się wsparciem dla
tłumaczeń, ale to już nie moja działka. Ja chciałem tylko zauważyć, że
chrzanienie się z gettextem przy małych programikach to przesada.
--
Piotr Sieklucki IA UW student UIN: 3141856 Registered Linux User #134868
_______________________________________________________________________________
Most people's favorite way to end a game is by winning.
smarkacz
[...]
Czy możesz przetłumaczyć swoją wypowiedź na polski?
--
*** smarkacz (smar...@anathema.eu.org) -- Jacek P. Szymański
Zaszłości historyczne. Rozszerzenie jest ważniejsze niż nagłówek.
-- Karol Michalak na pl.comp.os.advocacy
Tomasz Kłoczko
> PT Tomasz Kłoczko pisze:
>> Miros/law `Jubal' Baran <ba...@hell.pl> wrote:
>> [..]
>>> A co to ma do rzeczy? I.e. do tej dyskusji?
>> Że gettext nie jest zwiazany z C lub ten zwiazek jest taki sam jak z
>> dowolnym innym jezykiem.
> Używanie standardowych oznaczeń zmiennych z C (%s, %d etc.) to
> oczywiście tylko złudzenie apteczne... Jak również owo ograniczenie, o
> którym pisałem, a które -- bez sprawdzenia -- nazwałeś moim błędem.
Oczywiście używanie printfa to tylko domenna C :>
Tomasz Kłoczko
> Tomasz Kłoczko <klo...@rudy.mif.pg.gda.pl> wrote:
> [...]
> Czy możesz przetłumaczyć swoją wypowiedź na polski?
Ten tekst pisałem mając głowę tam gdzie tyłek, a tyłe tam gdzie zwykla ma
się głowe siedąc na krześle. Żeby to swobodnie odczytać musisz usadowić się
w mniejwięcej podobnej pozycji (dużo łatwiej się czyta wtedy takie teksty).
Marcin Wieczorek
>>> Do tego drażni mnie, że zacytuję samego siebie z innego forum:
>>> ,,fakt, że liczba wyspecyfikowanych zmiennych musi się zgadzać
>>> we wszystkich wersjach językowych'', co nadal uważam za ,,błąd w
>>> założeniach, [popełniony] przy projektowaniu biblioteki''
>> A tutaj?
>A tutaj dobrze byłoby mieć możliwość pominięcia niektórych danych z
>tekstu oryginalnego lub też zmiany ich kolejności (co do drugiego, nie
>mam pojęcia czy to nie jest możliwe, ale podejrzewam, że raczej nie...)
W Delphi jest funkcja Format przyjmująca stringa i listę parametrów o
zmiennej długości. Nie ze wszystkich parametrów trzeba skorzystać a w
stringu sekwencje sterujące mogą wybrać dowolny z nich. Sądzę, że takie
rozwiązanie by wystarczyło.
Format('There are now %d records in the table', [N,K]);
Format('There are now %2:d records in the table', [N,K]);
W pierwszym wypadku wstawione będzie N w drugim K.
--
Marcin Wieczorek ( T-1000 ) DELPHI FAQ http://delphi.koti.com.pl
________________________________________________________________
Programista to człowiek, który myśli, że komunikat "record has been locked by another
session" jest zrozumiały dla księgowego.
Marcin Wieczorek
<slrn8rupuk...@qrnik.knm.org.pl>:
>wady; pod innymi systemami jeszcze mniej wiem, jak to najlepiej
>zrobić. Ale nie wszystko naraz.
Pod Windows NT każda kontrolka systemowa ma odpowiednik Unikodowy. Pod
Win95 nie jest już tak różowo.
--
Marcin Wieczorek ( T-1000 ) DELPHI FAQ http://delphi.koti.com.pl
________________________________________________________________
Simon says: don't be so suggestible.
Marcin 'Qrczak' Kowalczyk
> >nim a Unikodem. Pod Linuksem są na to różne metody, a każda ma
> >wady; pod innymi systemami jeszcze mniej wiem, jak to najlepiej
> >zrobić. Ale nie wszystko naraz.
>
> Pod Windows NT każda kontrolka systemowa ma odpowiednik Unikodowy.
> Pod Win95 nie jest już tak różowo.
Tym będzie się martwił ten, kto będzie pisał interfejs do WinAPI
(pewnie zrobi #ifdefy i w razie potrzeby tekst będzie konwertowany).
W każdym razie na podstawowym poziomie jest potrzebna m.in. konwersja
między Unikodem a "domyślnym lokalnym bajtowym zestawem znaków"
(jako domyślne kodowanie wejścia-wyjścia i domyślne tłumaczenie
napisów przy wołaniu funkcji w C). Zakładam, że z tym pod Windowsami
nie będzie problemów. Python używa MultiByteToWideChar i na odwrót.
Czy to jest polecana metoda? Bo mbrtowc z ISO/ANSI C ma taką wadę,
że wchar_t to nie w każdym systemie musi być Unikod, i eksperci
polecają mi zamiast tego użycie iconva, dołączając jego "przenośną"
implementację kiedy nie ma go w systemie.
Miros/law `Jubal' Baran
>>> Że gettext nie jest zwiazany z C lub ten zwiazek jest taki sam jak
>>> z dowolnym innym jezykiem.
>> Używanie standardowych oznaczeń zmiennych z C (%s, %d etc.) to
>> oczywiście tylko złudzenie apteczne... Jak również owo ograniczenie, o
>> którym pisałem, a które -- bez sprawdzenia -- nazwałeś moim błędem.
> Oczywiście używanie printfa to tylko domenna C :>
Jeszcze raz, a jak nie pomoże, wezmę większy młotek. Jeśli masz
angielski tekst: "Kills %d, first name %s, last name %s", i zechcesz go
przetłumaczyć tak, żeby wyszło: "Zabójstw %d, nazwisko: %n", nie
możesz tego zrobić. Musisz zachować kolejność oryginalnych danych, nie
możesz ich opuszczać.
Jubal
--
[ Miros/law L Baran, baran-at-knm-org-pl, neg IQ, cert AI ] [ 0101010 is ]
[ BOF2510053411, makabra.knm.org.pl/~baran/, alchemy pany ] [ The Answer ]
It does not do to leave a live dragon out of your calculations.
Przemek Borys
[15 Sep 00][Stardate [-30]5427.4] Miros/law `Jubal' Baran->All
> Jeszcze raz, a jak nie pomoże, wezmę większy młotek. Jeśli masz
> angielski tekst: "Kills %d, first name %s, last name %s", i
> zechcesz go przetłumaczyć tak, żeby wyszło: "Zabójstw %d, nazwisko: %n",
> nie możesz tego zrobić.
Nie tak kategorycznie. Zależnie od przypadku można coś wykombinować.
> Musisz zachować kolejność oryginalnych danych, nie możesz ich opuszczać.
Przykład:
#include<stdio.h>
void main()
{
int kills=3;
char *fname="Alfred", *lname="Belka";
printf("Zabojstw %d, %8X\b\b\b\b\b\b\b\bnazwisko: %s\n",kills,fname,lname);
}
--
____\___\___
(_(\|,|_|,|_ [ /o)\ | GCS/S/TW/P d? s+:- a20 UL++++/H L++(++++) PGP- ]
| | |. [ \(o/ | t+++ 5+ X- R- b+ E- W++ PE PS D- !r>r+++ ]
Przemek Borys
[14 Sep 00][Stardate [-30]5423.7] Piotr Sieklucki->All
> Przystosowania do gettexta nie robiłem, prawda. Ja patrzę z punktu
> widzenia osoby robiącej samo tłumaczenie, a nie jego obsługę -- mi po
> prostu wygodniej obsługiwać czyste pliki tekstowe,
.po są jak najbardziej tekstowe :)
msgid "English version"
msgstr "Polska wersja"
> niż babrać się z gettextem. Żeby nie było: gettexta też używam (w innym
> projekcie), więc wiem o czym mówię.
Dziwnie brzmi to w kontekście wspomnianej tekstowości plików :-/
Chyba, że te tagi "msgid/str" są rzeczywiście tak przerażające ;)
> Sprawa zapewne wygląda inaczej ze strony osób zajmujących się
> wsparciem dla tłumaczeń, ale to już nie moja działka. Ja chciałem tylko
> zauważyć, że chrzanienie się z gettextem przy małych programikach to
> przesada.
Ma to moim zdaniem przynajmniej następujące zalety:
- ułatwienie zadania tłumaczenia dla tłumaczy z zewnątrz
- używanie indeksowanej bazy danych zamiast jakichś prostych mechanizmów
- wdrożona od dłuższego czasu integracja z systemem (okreslone struktury
katalogowe na tłumaczenia, itp)
- łatwość ugettextowienia programu (z pamięci: 3 procedury inicjalizujące w
main(), jeden dodatkowy include i jedno makro :)
Marcin Wieczorek
>nie będzie problemów. Python używa MultiByteToWideChar i na odwrót.
>Czy to jest polecana metoda?
AFAIK tak.
>Bo mbrtowc z ISO/ANSI C ma taką wadę,
>że wchar_t to nie w każdym systemie musi być Unikod, i eksperci
>polecają mi zamiast tego użycie iconva, dołączając jego "przenośną"
>implementację kiedy nie ma go w systemie.
O jakich systemach mówisz? Pod Win9x i WinNT/2k powinien to być
najnormalniejszy Unikod. Czy iconv obsługuje multibyte chars - czyli znaki
japońskie/chińskie składające się z kilku bajtów?
--
Marcin Wieczorek ( T-1000 ) DELPHI FAQ http://delphi.koti.com.pl
________________________________________________________________
People who think they're perfect are very annoying to us who really are.
Tomasz Kłoczko
>>>> Że gettext nie jest zwiazany z C lub ten zwiazek jest taki sam jak
>>>> z dowolnym innym jezykiem.
>>> Używanie standardowych oznaczeń zmiennych z C (%s, %d etc.) to
>>> oczywiście tylko złudzenie apteczne... Jak również owo ograniczenie, o
>>> którym pisałem, a które -- bez sprawdzenia -- nazwałeś moim błędem.
>> Oczywiście używanie printfa to tylko domenna C :>
> Jeszcze raz, a jak nie pomoże, wezmę większy młotek. Jeśli masz
> angielski tekst: "Kills %d, first name %s, last name %s", i zechcesz go
> przetłumaczyć tak, żeby wyszło: "Zabójstw %d, nazwisko: %n", nie
> możesz tego zrobić. Musisz zachować kolejność oryginalnych danych, nie
> możesz ich opuszczać.
Wiem, ze jestem niedouczony ale może kawałek z printf(3):
EXAMPLES
To print pi to five decimal places:
#include <math.h>
#include <stdio.h>
fprintf(stdout, "pi = %.5f\n", 4 * atan(1.0));
To print a date and time in the form `Sunday, July 3, 10:02', where
weekday and month are pointers to strings:
#include <stdio.h>
fprintf(stdout, "%s, %s %d, %.2d:%.2d\n",
weekday, month, day, hour, min);
Many countries use the day-month-year order. Hence, an
internationalized version must be able to print the arguments in an
order specified by the format:
#include <stdio.h>
fprintf(stdout, format,
weekday, month, day, hour, min);
where format depends on locale, and may permute the arguments. With
the value
"%1$s, %3$d. %2$s, %4$d:%5$.2d\n"
one might obtain `Sonntag, 3. Juli, 10:02'.
Marcin 'Qrczak' Kowalczyk
> >Bo mbrtowc z ISO/ANSI C ma taką wadę, że wchar_t to nie w każdym
> >systemie musi być Unikod, i eksperci polecają mi zamiast tego
> >użycie iconva, dołączając jego "przenośną" implementację kiedy
> >nie ma go w systemie.
>
> O jakich systemach mówisz?
Nie pamiętam; jakieś Uniksy.
> Pod Win9x i WinNT/2k powinien to być najnormalniejszy Unikod.
Niestety wolałbym większą przenośność. Na szczęście decyzja
o implementacji tej konwersji jest podjęta w jednym miejscu
i mogę na różnych systemach mieć różnie.
> Czy iconv obsługuje multibyte chars - czyli znaki japońskie/chińskie
> składające się z kilku bajtów?
W praktyce tak (ten w glibc-2.1.3 i ten w libiconv; nie wiem, jak te
w komercyjnych Uniksach, zgaduję że też).
Specyfikacja nie mówi, jakie zestawy znaków są obsługiwane, co jest
dużą trudnością przy przenośnym stosowaniu iconva. Trzeba znaleźć
dobry wspólny język i jego nazwę: nie każdy iconv oferuje np. Unikod
w formie tablicy wchar_t w natywnej kolejności bajtów w słowie,
a jeśli ma, to może się różnie nazywać. "UTF-8" jest łatwiejszy:
powinien być obsługiwane przez wszystkie implementacje i ma całkiem
jednoznaczną nazwę, ale to niepotrzebny narzut na konwersję po stronie
iconva i po mojej.
Przemek Borys
[18 Sep 00][Stardate [-30]5441.4] Tomasz Kłoczko->All
> Wiem, ze jestem niedouczony ale może kawałek z printf(3):
Wow, to dla mnie pewna nowość :)
Od kiedy to jest? To glibc czy jakaś nakładka?
Marcin 'Qrczak' Kowalczyk
> Wow, to dla mnie pewna nowość :)
> Od kiedy to jest? To glibc czy jakaś nakładka?
glibc (na pewno w 2.1.3 jest).