Nikt tutaj poza Wami nie chwalił się wykształceniem i domniemanym doświadczeniem. Jeżeli o wykształcenie zaś chodzi - Wasza znajomość języka ojczystego graniczy z podstawówką. Stwierdzenie o nauce języka od Mistrza Yody jest jak najbardziej prawdziwe. Tłumaczenia zawierają masę błędów lub wręcz są kopiami tłumaczeń zrobionych przy pomocy translatora Google'a. Igor, wszystkie wpisy dodane przez Ciebie jakie przejrzałem zawierają co najmniej jeden poważny błąd językowy. Część nawet błędy stricte techniczne, wynikające zapewne z Twojej wątpliwej znajomości języka angielskiego. Aby nie być gołosłownym omówię kilka ostatnio dodanych, wskazując tylko najpoważniejsze błędy:
object http_parse_cookie ( string $cookie [, int $flags [, array $allowed_extras ]] )
Analizuje ciasteczka HTTP jak wysłane w odpowiedzi struct
...
flags- Analiza flag (HTTP_COOKIE_PARSE_RAW)
...
allowed_extras - tablica zawierająca rozpoznane dodatkowe klucze; domyślnie wszystkie nie znane klucze będatraktowane jako nazwy ciasteczek
Pierwsze zdanie jest całkowicie niezrozumiałe do momentu zapoznania się z oryginałem - "Parses HTTP cookies like sent in a response into a struct." To zaś jest manual PHP przetłumaczony przez usługę Google. Cóż, brzmi znajomo. 'Analiza flag' czy 'flagi parsowania\analizy' - w języku angielskim kolejność wyrazów ma niebagatelne znaczenie dla właściwej interpretacji tekstu.
string ob_inflatehandler ( string $data , int $mode )
Wypełnia uchwyt wyjścia
To wszystko? Co przyjmuje a co zwraca? Tłumaczenie całkowicie błędne, może co najwyżej wprowadzić w błąd. Różnica pomiędzy handle a handlerem jest taka jak pomiędzy koniem a koniakiem...
string ob_etaghandler ( string $data , int $mode )
Uchwyt wyjścia ETag
Wyjście bufora obsługi generujące ETAG z określonego algorytmu mieszani.
To wyjście obsługuje też http_cache_etag().
Oryginał pierwszego zdania - "ETag output handler". Translacja przez Google'a - nieco bardziej rozbudowana wersja powyższego. I znowu, co z argumentami? W oryginale jest link do opisu trybów używanych przez tą rodzinę funkcji, u Ciebie zaś brak. Jak w poprzednich wypadkach - absolutnie niezrozumiałe.
string ob_deflatehandler ( string $data , int $mode )
Wypuszcza uchwyt wyjścia może zostać użyty tylko raz.
Tworzy konflit z ob_gzhandler() i zlib.output_compression oraz nie powinien być użyty po
mbstring mb_output_handler() i session oraz URL-rewrite
Tutaj trochę Twojej inwencji widać, wcale nie lepiej niż zrobił to translator Google'a. Komentarz zbędny - j\w. Do tego literówki, w czasach przeglądarek z wbudowanym sprawdzaniem pisowni.
Szczerze? Mam dość... Teksty są całkowicie niezrozumiałe, przykładów albo brak albo kiepskie\błędne. Dorzucam screeny abyś nie wpadł na pomysł skasowania wpisów - http_parse_cookie, ob_inflatehandler, ob_etaghandler, ob_deflatehandler.
Igor_funkcje_net napisał(a)
pÓÓÓÓki co kolo to rozwaliłeś forum dym screenem :), a tą rozdzielczosc to se rób dla siebie ciekawe jakie strony to trawią chyba tylko biedne 100% CSS'y, ciekawe wogólę jak ci windows wygląda na takiej rozdzielczości chyba z lupą śmigasz :) polewka
"Póki", "tym", "sobie", "w ogóle"... do tego interpunkcja, styl. Z lupą 'śmigać' nie trzeba - starczy mieć nieco większy monitor, większość programistów aktualnie ma coś koło 19", rozdzielczość musi być dopasowana do monitora, chyba się zgodzisz? "Polewka", cóż za kolokwializm, powiało profesjonalizmem, że się tak wyrażę.
Wracając do wcześniejszych postów - niestworzone rozdzielczości? Dlaczego zasłaniacie się sugestiami w3c skoro ich się nie trzymacie? Wedle statystyk z podanej przez Was strony - na początku tego roku ponad 1/3 użytkowników używała rozdzielczości większej niż 1024. Z użycia wychodzą stare monitory CRT oferujące niskie rozdzielczości, aktualnie jeszcze więcej ludzi używa wyższych. Wypadałoby zauważyć, że programiści zwykle używają sporych monitorów - strona 800x600-only jest co najmniej niewygodna. Zdecydowanej większości potencjalnych użytkowników utrudniacie korzystanie z serwisu, tylko dlatego, że ktoś jeszcze używa zapomnianych rozdzielczości. Hm, fakt, Wy możecie pracować w 800x600, w końcu robicie serwis dla siebie. Skoro zachowujecie kompatybilność z zabytkami to dlaczego strona wymaga obsługi JS do sensownego działania? Podobnych niekonsekwencji jest jeszcze wiele.
Nikt Was nie krytykuje "bo tak", Wy zaś odpowiadacie w ten właśnie sposób. Jak już wielokrotnie zwracano uwagę - tylko jedna strona tej dyskusji posługuje się rzeczową argumentacją.
divix napisał(a)
Stworzyłeś cokolwiek czego się nie wstydzisz? Pokaż.
W przeciwnym wypadku nie potraktuję Cię poważnie, a Twoje wypociny zignoruje z okna ekranu i zacznę czytać post poniżej. Proste? jasne że proste...
Czymże jest okno ekranu, kodeku? Dlaczego ktoś ma Tobie udowadniać, że zasługuje na Twoją uwagę? Sam nie pokazałeś absolutnie nic poza tym wątpliwej jakości sewisem. Strona nie na wszystkich popularnych przeglądarkach wyświetla się całkowicie poprawnie, o jakości tekstów można powiedzieć tylko tyle, że na bashu mają wyższy poziom... i lepszą moderację. Oczekujesz od nas uwag, kiedy pojawia się krytyka - odrzucasz ją.
divix napisał(a)
Krytykować, każdy głupi umie, stworzyć coś na co jest zapotrzebowanie.. właśnie.
Udowodniono Ci, że takiego zapotrzebowania nie ma, nawet oficjalny manual nie jest do końca przetłumaczony, z prostej przyczyny - nikt w tym nie widzi sensu. Jeżeli jest inaczej - o dowody proszę.
divix napisał(a)
(bez urazu oczywiście)
Różnica pomiędzy urazem a urazą jest jak między... handle a handlerem.
Mam świadomość, że post ten zostanie 'zignorowany z okna ekranu', jest po prostu niewygodny. W sumie napisałem go nie tyle aby wytknąć Wam błędy, ale aby oderwać się od kilku projektów open-source, nad którymi aktualnie pracuję. Hm, właśnie - udostępnijcie źródła swojego CMS-u.