W CLL i Lojban for Beginners sa bledy, ktore gdzies sa zakatalogowane.
Proponuje wyslac pytanie o nich do glownej listy przed rozpoczeciem
tlumaczenia.
Pozatym rzeczywiscie dobrze bylo by przetlumaczyc wszystkie gismu
w jbovlaste.
mu'o mi'e .totus.
.
Trochę też się wacham ponieważ wolałbym tłumaczyć moją adaptację do audiobook aby potem łatwiej ją nagrać - dzięki za uwagę donosnie błędów . Poprawie je w adaptacji (może warto też kupić książkę).
Jbovlaste ma sens.. Moja sprawność w piśmie polskim nie sprzyja szybkiego tłumaczenia długich tekstów.
co'o mu'o .i mi'e la ctujveclis.
>
> Trochę też się wacham ponieważ wolałbym tłumaczyć moją adaptację do audiobook
>aby potem łatwiej ją nagrać - dzięki za uwagę donosnie błędów . Poprawie je w
>adaptacji (może warto też kupić książkę).
>
> Jbovlaste ma sens.. Moja sprawność w piśmie polskim nie sprzyja szybkiego
>tłumaczenia długich tekstów.
>
> co'o mu'o .i mi'e la ctujveclis.
>
Rozumiem z tego ze - tak jak ja - nie mieszkasz w Polsce. A gdzie?
Ja mieszkam w Toronto, a urodzilem sie w Szkocji.
Tlumaczenie gismu tez nie zawsze jest latwe. Jako przyklad, zobacz:
http://jbovlaste.lojban.org/comments.html?valsi=396;definition=17636
Nawet jest sporo dyskusji na blogach co naprawde znacza definicje gismu po
angielsku.
A co dopiero cmavo?
No ale tu wyjscia niema. gismu koniecznie trzeba przetlumaczyc.
--
Marek Rogalski
Oj tak. To "la djan" zawsze przyprawia mnie o mdłości ;) Wymowa angielska (amerykańska?) jest beznadziejna ;) Chociaż tak pomyślałem, że jeśli szukać czegoś polskiego, to najlepiej też przekładającego się jakoś nie wprost.
> Szukałem także substytutów dla nazw w stylu "pro-bridi", "attitudinal"
> itd. Jeśli ktoś z was będzi mieć chwilę, proszę. niech spojrzy na spis
> treści: http://github.com/mafik/cll/blob/gh-pages/index.html i zgłosi
> swoje opinie.
"Attitudinals" jest faktycznie kłopotliwe. Jak dotąd myślałem sobie (nie mówiłem, bo nie miałem do kogo ;) ) "attytudynale". Kijowe, ale jakoś mniej więcej z grubsza rodzime. Z "pro-bridi" i "pro-sumti" najpierw trzeba dojść jaki jest polski analog, a ja zawsze się gubiłem w tym przyimkach, zaimkach, przedimkach, doimkach itp. ;)
BTW: W kwestii formalnej - nigdy czegoś takiego nie robiłem i interesuje mnie jak właściwie wygląda proces "publicznego" tłumaczenia? Czy git jest najdogodniejszym narzędziem? Zwłaszcza jeśli tekst źródłowy jest potencjalnie zmienny? [Nie wiem czy jest jakaś robocza wersja CLL, czy tylko wykuty w kamieniu oryginał plus errata?]
--
Ecce Jezuch
"Ash nazg durbatuluk, ash nazg gimbatuluk,
ash nazg thrakatuluk agh burzum - ishi krimpatul" - Sauron
Z tego co mi wiadomo, tekst był przez pewien czas rozbudowywany, aż na
pewnym stadium, został wydany jako książka, "The Complete Lojban
Language by John Waldemar Cowan". W dogłębny sposób opisuje każdy
element gramatyki języka i może być traktowana jako jego podstawowy
podręcznik. Kwestie prawne rozwiązuje rodział
http://dag.github.com/cll/1/8/ , który skrótowo można opisać jako:
każda praca pochodna dozwolona, pod warunkiem że modyfikacje względem
oryginału zostaną jasno wyróżnione.
W dniu 1 października 2010 19:53 użytkownik Marcin
<ctuj...@gmail.com> napisał:
> Ja też nie- ale ostatnio dużo używam Mediawiki w pracy i oczywiscie do
> moich stron lożban. Zapraszam do stworzenia account na www.learnlojban.com
> -- edycja jest łatwa przez parę osób.
Chyba słabo orientuję się w stronie... Gdzie można założyć konto?
> Jeśli bysmy chcieli robic 'synchro editing' to jest Google Wave, Gobby
> (uzywam w pracy, super programik.. moge zalozyc nasz wlasny server)..
> lub EtherPad (mam zamiar zainstalowac wlasny serwer dzis lub jutro)
>
Wg. mnie tłumaczenie synchroniczne może okazać się mniej efektywne niż
podział pracy (chociaż zdecydowanie bardziej motywuje!).
Wybierając narzędzia nie kierowałem się właściwie żadnymi powodami,
biorąc się za pierwsze narzędzie jakie wpadło mi do ręki. Jeśli git
wam nie odpowiada, możemy przesiąść się na wiki. Spróbujcie jednak o
nim pomyśleć. git to narzędzie kontrolujące pracę na plikach
tekstowych (zwykle źródła programów komputerowych). Pozwala na
śledzenie zmian i numeracji wersji, tworzenie odgałęzień projektów,
rozproszoną pracę i synchronizacje zmian podczas łączenia wielu kopii.
Wydaje mi się świetnym narzędziem do czegoś takiego.
Jako wspomagacza tłumaczenia korzystam z Google Translator Toolkit,
który sprawdza się jako tako. Za to jeśli chodzi o wiki, na
lojban.org, to może nas czekać kilka problemów związanych z
konfiguracją językową strony (elementy w menu skierowane do
angielskich wersji językowych, niemożność utworzenia kopii strony w
innym języku, a pod tą samą nazwą, oraz ignorowanie znaczników
językowych w przęglądarkach). Z tego powodu nowi goście na lojban.org
mogą zwyczajnie nie trafić na jej polską wersję... Z mediawiki, czy w
moodle, u Marcina, pod tym względem, powinno być dużo łatwiej.
Wykonanie tłumaczenia w formie html będzie chyba elastyczniejszym
rozwiązaniem. Pozwoli pobrać kopie książki, nada jej elegancki wygląd,
pozwoli na drukowanie i udostępnienie w formie ebooka. Wersja na
semantic wiki będzie pewnie preferowana przez internautów.
Jestem programistą i dobrze wiem do czego służy git :) I wiem także, że tłumacze mają swoje własne narzędzia, o których właściwie wiem tylko tyle, że istnieją. W przypadku tłumaczenia narzędzia typu git mi nie pasują ze względu na to, że nie ma tu jednego źródła - są dwa, gdzie jedno "przykrywa" drugie i zmiana oryginału nie będzie w ogóle widoczna (w sensie, że nie będzie wiadomo, że trzeba sprawdzić/poprawić/powtórzyć tłumaczenie). Przypuszczałem, że tłumacze wiedzą jak to robić efektywniej :)
Tak tylko sobie głośno rozmyślam...
--
Ecce Jezuch
"Hold me now, I'm 6 feet from the edge and I'm thinking,
Maybe 6 feet ain't so far down..." - S. Stapp
W dniu 2 października 2010 11:33 użytkownik Krzysztof Sobolewski
<jez...@interia.pl> napisał:
>
> Jestem programistą i dobrze wiem do czego służy git :) I wiem także, że tłumacze mają swoje własne narzędzia, o których właściwie wiem tylko tyle, że istnieją. W przypadku tłumaczenia narzędzia typu git mi nie pasują ze względu na to, że nie ma tu jednego źródła - są dwa, gdzie jedno "przykrywa" drugie i zmiana oryginału nie będzie w ogóle widoczna (w sensie, że nie będzie wiadomo, że trzeba sprawdzić/poprawić/powtórzyć tłumaczenie). Przypuszczałem, że tłumacze wiedzą jak to robić efektywniej :)
>
> Tak tylko sobie głośno rozmyślam...
Właściwie jest sposób na uniknięcie konfliktów. Po każdej modyfikacji
trzymać się protokołu:
git commit -am "opis" (zapisuje zmiany w plikach do lokalnego repozytorium)
git pull (ściąga i łączy ewentualne zmiany które
mogły nastąpić w centralnym repozytorium)
git push (wysyła połączone wersje z powrotem na serwer)
(bardziej szczegółowy opis na http://progit.org/book/ch3-2.html)