Edice CZ.NIC se brzy rozroste o další knihu. Po publikaci Pavla Satrapy (IPv6) a knize Scotta Chacona (Pro Git) přibude do ediční řady překlad knihy Dive into Python 3. Na něm se už v tuto chvíli pracuje a protože víme, že překlady odborných publikací nejsou vždycky díky nejasné české terminologii dokonalé, rádi bychom se obrátili na všechny, kteří se v této problematice pohybují a orientují, aby nám pomohli s překlady některých anglických termínů.
Naše návrhy najdete v glosáři. Komentovat je můžete pod tímto příspěvkem do 6. dubna. Vaše připomínky potom předáme překladateli, který s nimi bude dále pracovat.
Vilém Sládek
list comprehension – generování seznamu
dictionary comprehension – generování slovníku
learning curve – křivka učení
boolean context – booleovský kontext
set comprehension – generování množiny
parsing – parsování
immutable type – typ s nemenitelnou hodnotou (slovo „konstantni“ by bylo zavadejici)
Zdravím Vás,
Repository se v knize vyskytuje jednou na nevýznamném místě ve smyslu Mercurial repository (systém pro správu verzí/změn) a víckrát ve smyslu „repository“ pro různé varianty Linuxu…
Mám zájem spolupracovat intenzivně, protože to překládám.
Slovo repozitář považuji spíš za slangové (podobná počeštěnina jako direktorář). Původně jsem navrhoval překlad na „úložiště“, ale vhodnější by bylo asi celkem jasné a dobře srozumitelné „archiv“ — možná s výjimkou toho … u Mercurial.
S pozdravem,
Petr Přikryl
P.S. Zdá se, že celá ta akce není tajná — když už je zveřejněna diskuse kolem glosáře. Můžu znát nějaké konkrétnější plány? V Českých překladech (které v tom podle mého hrají důležitou a pozitivní roli) už jsou od Vás tak odstíněni, že se s nimi špatně dohadují nějaké věci, které jsou mimo jejich působnost.
(Sakra, to není napojené na mail ;-)
Nevadí. Klidně mi koukejte do hlavy.
Než se to rozjede… Nemáte někdo nápad, jak tyhle informace sbírat trošku statičtěji? Nehodil by se na to spíš nástroj typu wiki? Mám zájem o diskusi, ale bylo by dobré, kdyby to k něčemu konvergovalo. Tyhle přílepky jsou moc nestrukturované a za chvíli to bude nepřehledné.
mutable/immutable type — je taky takové „Kolik třešní, tolik višní.“ Problém je v tom, že na „typu“ nemá co být měnitelného nebo neměnného. Jde o to, že ty hodnoty toho typu jsou buď měnitelné nebo neměnitlené. Hodnota immutable typu je skutečně neměnná v tom smyslu, že je konstantní. Takže immutable jako konstantní mi tak moc zavádějící nepřipadá.
Učící se křivka (learning curve) je jasná ptákovina. Měl jsem to tam bez toho „se“ a doufal jsem, že s krátkým i (učicí křivka), ale ruku do ohně…
Křivka učení je lepší. (Jirko dík)
Tech slangových výrazů bych se tolik nebál. Přeci jenom je to psáno pro lidi z poměrně úzké skupiny. Repozitorář je podle mě zcela v pořádku. Podobná výhrada by mohla být i pro „parsování“, ale i to se celkem běžně používá.
Pak jsem přemýšlel, jestli se má používat „boolovský“, nebo „booleovský“, ale ten pán se jmenoval Boole, tak bych mu to -e nechal.
Podle mě je tam jen jeden vyloženě překladatelský oříšek, a to je „comprehension“. Bude třeba dávat hodně velkého majzla na význam vět, ve kterých se toto slovo vyskytuje.
Je třeba obecně dávat pozor, jestli je dané slovo vždy použito ve stejném kontextu. V různých kontextech se může překládat jinak. Tahle myšlenka Petra Přikryla by neměla zapadnout.
Překlad velmi vítám, bude to jistě velmi dobrý zdroj informací o Pythonu v češtině. Python se tak bude moci snadněji používat třeba i na středních školách k výuce programování.
No toto! Než jsem to dopsal, tak příspěvek, na který jsem odkazoval, zmizel.
Jedna z kapitol se jmenuje Comprehensions. Ta se rozpadá na pojmy List Comprehensions….
Dětsky by se do dalo přeložit jako „skládadlo“, „konstruovadlo“. Jde o to, že to má význam konstrukce zapsané do zdrojového textu (statický zápis) a ne význam výsledku toho zápisu při běhu nebo toho procesu vytváření.
Proto je nevhodné něco jako „generování seznamu“, ale taky je nevhodný původní „generátor seznamu“.
Nejvhodnější mi připadá trošku opisný překlad „comprehension“ = „generátorový zápis“:
generátorový zápis seznamu
generátorový zápis slovníku
generátorový zápis množiny
Šel by možná také:
generátorový konstruktor seznamu
generátorový konstruktor slovníku
generátorový konstruktor množiny
Problém je v tom, že „konstruktor“ má v jiných jazycích přesný význam, který v Pythonu sice spíš není. Ale mohlo by se to plést.
„Generátorový“ — vnitřku té konstrukce se celkem jednoznačně říká generátorový výraz a vyhodnocením generátorového výrazu vzniká generátor.
„Zápis“ — nic lepšího mě nezapadá. Je to zkrátka zápis ve zdrojovém textu, který při běhu vede ke vzniku seznamu (slovníku, množiny). Vyjadřuje to tu statičnost zdrojového textu.
Ten pojem je obtížný (nezvyklý) i v anglické počítačové terminologii.
Proto bych se přikláněl k tomu „generátorový zápis“ (seznamu, slovníku, množiny).
Repository se v knize vyskytuje jednou na nevýznamném místě ve smyslu Mercurial repository (systém pro správu verzí/změn) a víckrát ve smyslu „repository“ pro různé varianty Linuxu…
Slovo repozitář považuji spíš za slangové (podobná počeštěnina jako direktorář). Vhodnější by bylo asi celkem jasné a dobře srozumitelné „archiv“ — možná s výjimkou toho … u Mercurial.
Learning Curve — přikláním se k Jirkově návrhu „křivka učení“.
(Možná by to chtělo nějaký nástroj pro strukturovanější diskusi.)
mutable/immutable type — problém je v tom, že na „typu“ nemá co být měnitelného nebo neměnného. Jde o to, že ty hodnoty toho typu jsou buď měnitelné nebo neměnitlené. Hodnota immutable typu je skutečně neměnná v tom smyslu, že je konstantní. Takže immutable jako konstantní mi tak moc zavádějící nepřipadá.
Asi by bylo vhodné navázat na práci Jana Švece
http://www.py.cz/DoporuceniProPreklad
a na překlady další literatury
http://www.py.cz/TutorialyLiteratura
např.
List comprehension
Generátor seznamu. Předchozí verze tohoto dokumentu doporučovaly překlad Stručný seznam, který je však méně výstižný a v nových textech se doporučuje používat sousloví generátor seznamu, jež je navíc konzistentní s překladem Generator expression (Generátorový výraz).
Máme tady na výběr:
generátor seznamu
generovaný seznam
generování seznamu
kontruktor seznamu
generátorový zápis seznamu
generátorový konstuktor seznamu
konstrukce seznamu
Nejrozumnější mi připadá zachovat původně doporučený „generátor“
případně použít můj dnešní nový nápad „konstrukce“
learning curve – osobně mám zažitý výraz „učební křivka“, ale zdá se (Google), že „křivka učení“ je častější, takže budiž
statically-typed language – staticky typovaný jazyk
boolean – je sice bool(e)ovský, ale třeba v případě „boolean type“ bych volil „logický typ“
(im)mutable type – (ne)měnitelný typ; možná to vypadá jako zavádějící, ale měnitelnost hodnot zjevně je vlastností typu, a navíc je to v češtině už celkem běžná konstrukce
comprehension – tady přiznám se vůbec netuším, jak to přeložit, ale výše navrhovaný „generátorový zápis“ mi zní vcelku rozumně
slice – tady přesně nevím, nejsem pythonista, ale jestli to je v souvislosti s poli apod., tak bych navrhoval spíš „úsek“
Ještě:
parsing – parsování, příp. „syntaktická analýza“
unit test – v češtině se vcelku používá výraz „jednotkový test“
unbound variable – výraz „volná proměnná“ se v češtině používá jako překlad „free variable“, což je něco jiného; asi bych použil „nedefinovaná proměnná“
Boolean – pravdivostní
parsing – rozbor
(Poschvaloval jsem ty komentáře, co WordPress z nějakého důvodu dal do fronty.)
Repozitář je běžně užívané slovo (jako překlad repository), takže bych se ho rozhodně nebál použít.
„prostor jmen“ vs. „jmenný prostor“
Tady cítím diskusi „na krev“. Při letmém pohledu se to zdá být jedno. Kdo psal nějaký text a musel to v souvislostech mluvnicky ohýbat, dá mi možná zapravdu…
Prostor jmen — z toho je cítit více, že jde o PROSTOR. A co se v něm nachází? Jména.
Jmenný prostor — z toho je cítit víc JMÉNA. To by bylo OK. Ale zkuste napsat nadpis…
„Proměnné a prostory jmen“ (Honza Švec, Létající cirkus) a pak zkuste
„Proměnné a jmenné prostory“ — ty prostory se mění? ;) No dobrá, tak…
„Jmenné prostory a proměnné“ (čtenář: „Cože? Jmenné a proměnné? A proč je to tak divně napsané?“). OK. Jsem zaujatý. Zkusme
Doménový prostor jmen = doména je vlastníkem toho prostoru jmen
Prostor doménových jmen = v prostoru jsou uložená doménová jména
a alternativní
„Jmenný prostor domény“ = doména je vlastníkem toho jmenného prostoru
„Jmenný prostor doménových jmen“ = v jmenném prostoru jsou uložená doménová jména
„Doménový jmenný prostor“ = No nevím. To bych musel chvíli přemýšlet, co to znamená.
Zkusme skloňovat
1. prostor jmen
2. (bez) prostoru jmen
3. (k) prostoru jmen
4. (vidím) prostor jmen
5. (haló,) prostore jmen
6. (o) prostoru jmen
7. (s) prostorem jmen
a v množném čísle
1. prostory jmen
2. (bez) prostorů jmen
3. (k) prostorům jmen
4. (vidím) prostory jmen
5. (haló,) prostory jmen
6. (o) prostorech jmen
7. (s) prostory jmen
a alternativní…
1. jmenný prostor
2. (bez) jmenného prostoru
3. (k) jmennému prostoru
4. (vidím) jmenný prostor
5. (haló,) jmenný prostore
6. (o) jmenném prostoru
7. (s) jmenným prostorem
1. jmenné prostoré
2. (bez) jmenných prostorů
3. (k) jmenným prostorům
4. (vidím) jmenné prostory
5. (haló,) jmenné prostory
6. (o) jmenných prostorech
7. (s) jmennými prostory
A to neuvádím kombinaci typu „prostor doménových jmen“.
Jeví se mi to tak, že jazykově se s „prostorem jmen“
zachází stejně snadno jako s „prostorem“. Zacházení
s „jmenným prostorem“ je víc jazykolamné, na přemýšlení,
co se tím při napojení ve větě vlastně myslí, delší…
Pak je tu tradice škol. Takže to není jednoznačné,
takže se přikláním k „prostoru jmen“.
(hodím návnadu ;)
Co to je typovaný jazyk?
A je nějaký netypovaný jazyk?
boolean, boolovský, booleovský, logický, pravdivostní
Váže se to víc k datovým typům (v této knize). Pokud se v jazyce logický datový typ deklaruje, používá se spíše bool, boolean,…
Je to pocta matematiku a filosofu jménem George Boole [čti búl]. Možná kvůli výslovnosti se má psát boolovský a ne booleovský (letmá konzultace s jazykářem, který to vidí jednoznačně — ale pravidlo vám neřeknu).
Anglicky je také možné rozlišovat logical/boolean. Autor píše o boolean, takže tímto směrem je volba jasná. Když bude v textu logical, logic, atd., pak je vhodné logický.
„Pravdivostní datový typ“ — to je divné (i když věcně možná správné).
Já bych se s dovolením řídil jednou maximou: volnější překlad je lepší než ten přesný, je-li srozumitelnější pro čtenáře. Významným prvkem je zde úzus — vyrábění překladů, které jsou možná přesnější či logicky správnější, ovšem nepoužívané, nepomáhá nikomu a ze všeho nejmíň čtenáři.
Konkrétně: datové typy se možná deklarují jako „bool“ či „boolean“, ale vzdor imaginárním poctám panu Booleovi jde v první řadě o vyjádření pravdivostní hodnoty. V češtině se používá výraz „logický typ“ (protože standardní logiky jsou dvouhodnotové — pravda/nepravda), který je možná nesmyslný, ale určitě ne víc než „booleovský typ“, takže já mám taky volbu jasnou :-) Souhlasím, že „pravdivostní datový typ“ je divné.
Stejně tak jmenný prostor. Ono je důležité obojí — jak že jde o JMÉNA, tak že jde o PROSTORY (a hierarchie prostorů), do kterých ta jména patří. Nejde jen o proměnné, do jmenných prostorů (ať už společných nebo samostaných) patří názvy proměnných, funkcí, tříd atd. Jmenné prostory proměnných… Prostory jmen proměnných… On v tom asi takový rozdíl není. Osobně mám tím větší problémy, čím víc je ve větě podstatných jmen, takže sám bych volil „jmenné prostory“.
No a „typovaný jazyk“, to už je vůbec oříšek. Slovo „typování“ se podle všeho používá jako zkratka pro „typový systém“, ovšem lze ho triviálně použít i jako přídavné jméno — to je v případě „typového systému“ potřeba zdlouhavě opisovat. S konceptem typu pracují všechny programovací jazyky, takže tážeme-li se, zda existují „netypované jazyky“, můžeme se tázat i zda existují „jazyky bez typové kontroly“, a odpověď je totožná (slabě typované jazyky taky typy kontrolují — a pak provádějí implicitní typové konverze). Tohle nežeru :-)
P.S.: nésu překladatel ani jazykovědec, vyjadřuju pouze svoje skromné názory na češtinu používanou v IT — možná má svoje specifika, ale vcelku dobře funguje (jak je patrné třeba na slovu „bajt“).
K těm (jmenným) prostorům (jmen) — „Proměnné a jmenné prostory“ je sice hezký příklad, ale stejně tak se dá kontrovat úplně opačně (což bude dost možná i častější případ, protože slov typu „proměnná“ mnoho není). Třeba „Operátory a prostory jmen“ — což zřejmě znamená „operátory jmen a prostory jmen“…
Prozatímní závěr k comprehension (zdůvodnění jsem popsal v mailing listu python@py.cz. V archivuj je to tady http://www.py.cz/pipermail/python/2010-March/009576.html)
comprehension = generátorová notace
list comprehension = generátorová notace seznamu
set comprehension = generátorová notace množiny
dictionary comprehension = generátorová notace slovníku
Technická poznámka. Ten glosář původně vznikl naplněním terminologického slovníku v nástroji pro podporu překladu (nepřekládá to automaticky, je to jen specializovaný editor s rozšířenou funkčností, ale kontroluje to). Proto jsou tam uvedené i pojmy, které „nestojí za řeč“ vedle těch obtížných. Taky se to dynamicky trošku mění.
Věcná poznámka (pro Ladislava). Určitě souhlasím s tím, že dobrý překlad technické literatury má smysl jen tehdy, když do originálu nevnese nejasnosti. Jinak je to škoda času a peněz na všech stranách. Překlad by měl být určitě volnější v tom smyslu, aby využil vyjadřovací schopnost cílového jazyka a taky místní kontext (třeba pojmy, příklady). Takže slova jako „boolovský“ by se neměla objevovat všude, kde to jen trochu smrdí logickou hodnotou. Rozhodně zde nejsme ve při. A cením si každé připomínky, i když rozhodnutí pak může být jiné.
Ten glosář taky není úplný. Je to první nástřel.
Zatím jsem se taky nikde nedozvěděl, jak to s tou publikací knihy bude. Jaký je záměr — vypustit on-line verzi dříve, než tištěnou, stejně, později. Jde o to, jak moc to má být výdělečný podnik.
Přimlouval bych se za brzké zveřejnění on-line verze (nebo zaslání vybraným lidem), protože pak se to dá podrobit rozumnější diskusi, než hádání se o slovíčko. ;) Mrtvých stromů je přece jen škoda, tak ať to na tom papíře vypadá co nejlépe.
Prostor jmen
Jmenný prostor
nechť jsou to ekvivalenty, ale nemělo by se to v jednom textu míchat.
Nie som sice narodnosti ceskej, ale nejaku tu cesku odbornu publikaciu som precital. Musim povedat ze ak som zbadal „zástupné znaky“ netusil som co to moze byt, ale wildcards mi hovori vela. Neviem ale ponuknut alternativu, na slovnik.sk som nasiel preklad „náhradné znaky (*.*)“, slovnik.cz ma este alternativu „pseudoznaky“ – ani jedno nie je nic moc.
Mozno vyznam bude zrejmy z kontextu alebo navrhujem dat pri prvom vyskyte frazy „zástupné znaky“ za nou do zatvorky povodne wildcards.
wildcards
Tento pojem jsem do glosáře nevkládal, ale v knize je. Určitě ale uvedu do závorky anglický pojem, aby to bylo jasnější.
„Náhradní znaky“ by mohly být málo specifické.
„Zástupné znaky“ se mi zdá docela dobré, i když nevím, jak moc se to používá.
Někdy se používá přibližně doslovný překlad „divoké znaky“, ale nevím, do jaké míry je to přijatelné. Každopádně je to specifičtější, než předchozí. A každý karbaník zná pojem „divoká karta“ — ty znaky jsou vlastně takoví Žolíci.
unit test, unit testing
jednotkový test, jednotkové testování
Dělám průzkum. Jak se zmínil Ladislav, tohle se používá. Originální název bude v závorce (ale ne v nadpisu).
Trošku problém je v tom, že unit je jednotka ve smyslu „zařízení“, „něco funkčního“ a někteří by to mohli vnímat jako „jeden po druhém“. V tomto smyslu by bylo „testování jednotek“ a „test jednotek/jednotky“ přesnější. Jaké máte zkušenosti se skutečným rozšířením překladu tohoto pojmu?
Je to taky docela specifická tématika a této praxi (unit testing) se většinou dostanou až trochu zkušenější programátoři). Pojem „unit testing“ by třeba mohl zůstat v nadpisu v originále… Zatím nerozhodnuto.
Petře, to „booleovské“ je stejně dobře možné jako „boolovské“. Správně je podle ÚJČ oboje. Jsem zvyklý psát „Hubbleův“ z úcty k původnímu jménu, což je velmi podobný případ, a proto se spíš kloním k booleovskému. V zásadě je to ale putna.
Logický a booleovský není úplně totéž. Logika je dost široký obor, neexistují jen jednoduché výroky, i když o ty právě v Pythonu jde. Z tohoto pohledu bych se raději vyhnul i tomu pravdivostnímu datovému typu, protože pravdivost nemusí být vyjadřována jen pomocí ano a ne. Je pravda, že se to někdy používá, ale zase na druhou stranu je to tak dlouhé, až je to otravné.
K tomu „comprehension“: Poznámku beru. Překlad „generování“ je skutečně překlad názvu činnosti, při kterém daná datová struktura vzniká. To jistě nějaká forma generování je. Označení zápisu je problematické. I v angličtině to „comprehension“ musí podle mě pro laika vypadat divně. Není to nějaká narážka na Monty Pythona? Možná by se dalo použít slovo „konstrukce“. To by šlo použít jak pro zápis, tak pro proces. Slovu „konstruktor“ bych se zde vyhnul za každou cenu. Bylo by to velmi matoucí už jen pro to, že v Pythonu jsou konstruktory v tradičním smyslu také.
A ještě jedna obecná poznámka. Překlad by neměl zbytečně vytvářet jazykovou bariéru pro ty, co by se chtěli dál s Pythonem seznamovat v cizím jazyce. Naservírování do detailu přeložené a věcně správné terminologie nemusí být pro čtenáře úplně nejpohodlnější. Přechod k materiálům v angličtině by pro něj mohl být dost bolestivý. Využití žargonu je do jisté míry nutné. Kniha není pro jazykové puristy, ale pro programátory.
„Zástupné znaky“ jsou IMHO výborné. „Divoké znaky“ se taky občas používají, ale ta karbanická analogie mi přijde hodně vzdálená. Občas se dá najít výraz „žolíkové znaky“, který sice taky nemám moc v oblibě, ale rozhodně je pochopitelnější než „divoké“.
Generátorová notace — souhlas. Nevidím velký rozdíl mezi notací a zápisem, ale obojí je docela dobře použitelné.
P.S.: díky za výbornou diskusi, vypadá to, že tenhle překlad by mohl dopadnout dobře :-)
Ad divoká karta: http://en.wikipedia.org/wiki/Wild_card_%28card_games%29
To „wildcard“ evidentně pochází právě od karbaníků, takže „divoké znaky“ by mohl být docela dobrý překlad. „Zástupný znak“ je ale taky ok. Netřeba snad vymýšlet kolo.
A teď mě napadlo použít Wikipedii i pro to „comprehension“. http://en.wikipedia.org/wiki/Comprehension Vypadá to, že by ten pojem mohl pocházet z matematiky, možná z teorie množin. Nedalo by se tam něco vyšťourat?
Immutable určitě neznamená konstantní, dle mého by to bylo zavádějící. Přeci může být immutable objekt, který obsahuje reference na mutable objekty. A hlavně immutable objekty se chovají uplně jinak než konstanty. Do definované konstanty pod určítým identifikátorem by již němělo jít nic přiřadit, proto je to také konstanta. Ale při přiřazení nové hodnoty promměnné, která obsahuje immutable objekt se prostě vytvoří nový immutable objekt, který je dostupný pod stejným identifikátorem. Na starý objekt již není reference a GC ho odstraní. Tzn. chování je dost jiné a napsat, že jsou to konstanty, by bylo dost zavádějící. Asi bych se přikláněl spíš k zachování mutable/immutable objekty, aby pak mohli lidé bez potíží přejit na anglickou literaturu.
mutable vs. immutable
Určitě to bude v originále v závorce (jako všechny pojmy, které nemají zcela jednoznačný a používaný význam — například seznam). Tady to ale nevidím jako touhu po nějakém přesně definovaném pojmu, spíše jako popis vlastnosti objektu/typu. Vyplyne to z textu, ale máte pravdu, že „konstantní“ vzbuzuje jiné asociace. Asi to bude v textu přeložené víc opisem a použiju „měnitelný“, „neměnný“ nebo „neměnitelný“.
On je u Pythonu ještě jeden problém, který s tím souvisí. Není terminologický a snad ani sémantický, ale přesto způsobuje nejasnosti. Jde o chápání, co to je „proměnná“. Matematici s tím problém mít nebudou. Ale programátoři, kteří vyrostli na nějakém kompilovaném jazyce, si představí paměťové místo o určité velikosti na určité adrese a ta adresa je ve zdrojovém textu vyjádřená identifikátorem proměnné. Jenže v Pythonu je to jinak. Pokud se někde proměnné s konstantní hodnotou myslí takové místo v paměti (identifikované jménem proměnné), do kterého se nám nepodaří přiřadit, tak tohle v Pythonu není. Python ukládá reference a na skutečnou adresu se (teoreticky) nemáme dostat. Když tedy vytvořím n-tici (tuple), která je immutable, pak skutečně vytvořím n-tici s konstantním obsahem. Reference uvnitř zachycené nemůžu měnit. Ale pokud některá z těch referencí odkazuje na mutable objekt (třeba na seznam), pak obsah toho objektu měnit můžu. Obsah tuple ale bude pořád konstantní (z technického hlediska), ale když si tu n-tici nechám zobrazit a obsahuje například ten seznam, tak můžu pozorovat pokaždé jiný výstup.
to Petr Přikryl:
Myslím, že si rozumíme.
to All:
refactoring – refaktoring ( určitě ne refaktorizace )
boolova, boolovský vs. booleova, booleovský
Zkusil jsem zjišťovat (velmi orientačně) frekvenci výskytu přes Google zadáním „boolova site:.cz“, atd. Vybral jsem několit tvarů toho slova. Výsledky jsou tady:
boolova 727
boolovský 362
boolovská 769
boolovské 1050
booleova 9290
booleovský 1890
booleovská 2450
booleovské 12 000
A protože praxe je často důležitější a určující (aneb „nečůrej proti větru“), přikláním se k variantě s ‚e‘. Jirko a Ladislave, dík.
P.S. Pokud někdo v Google umíte tyhle věci dělat líp (vím, že tam jdou dělat různé věci, ale nepoužívám to), ukažte ;)
Já budu občas provokovat a rýpat a uvádět věci úplně obráceně (než si myslím, ale neřeknu kdy), abych z vás dostal názor ;) Není nad zapálené objájce svého názoru…
Přesto si musím rýpnout…
„prostor jmen“ podle vzoru „domov důchodců“
:)
parsing
Kdo zná slovo parser, tomu je jasné, co to znamená. Kdo nezná pojem syntaktická analýza, bude mu jedno jestli je to syntaktický analyzátor nebo parser (bude vedle). Ale parsování mi připadá hodně free. Já nevím. Tak trošku se to musí držet na uzdě. Pak by to začalo být všechno hodně free a vzniklo by víc zmatků, než užitku. To se netýká tak úplně tohoto slova, spíš obecně. Uvidíme. Půjde to opisem a pak k tomu dopíšu „… se tomu říká stručně parser (z anglického parse = rozložit na části, analyzovat, udělat rozbor)“ a dál můžu použít parser a snad to nikoho neurazí.
refactoring
Malý průzkum přes Google „xxxx site:.cz“
refactoring 8340
refaktorizace 1470
refaktoring 4740
refaktorování 3140
Ale pozor! Existuje matematický pojem factorization, faktorizace…
faktorizace 9630
faktorování 172
Faktorizace (zobecňuji) znamená rozklad na části, ze kterých se to dá poskládat zpět. Předpona re- znamená znovu. Takže to docela přesně vystihuje, co se při refactoringu dělá. Refactoring a refactorization — vztah těch by vysvětlil angličtinář.
V tomto smyslu se přikláním k „refaktorizace“. (Následuje krvavá smršť protiargumentů) ;)
Já bych svoje proměnné do domova důchodců nikdy neposlal! :-D
K parsování — dají se zaslechnout různá slova, ze kterých mi běhá mráz po zádech, třeba „naparsovat“ nebo „rozparsovat“. Opis je tady asi dobrá volba.
Jediný argument, který vychazí z Vašich čísel. Jestli teda zrovna nehrajete tu hru na říkání opaku, než si myslíte:)
Takže
refaktoring 4740 – VÝTĚZ:)
refaktorizace 1470
Jen bych dodal, že vítěz s y je tam kvůli tomu, jaká to je tvrdá a drtivá porážka:)
Refaktoring určitě ne. ;) Nejedu jen podle čísel.
Ještě stran refaktoringu: je to sice zřejmé, ale přece to připomenu. Anglické slovo „refactoring“ označuje jak proces úpravy kódu, tak konkrétní „typ“ úpravy kódu. Zatímco „budeme refaktorovat“ zní úplně normálně, „použijeme refaktorování extract method“ (když zůstanu u anglických názvů, ale v češtině by to asi znělo podobně) je dost hrozné. „Refaktorizace extract method“ je jen o málo lepší.
Nevím, v jakém kontextu se „refactoring“ používá v předmětné knížce, ale možná by i tady nejlíp fungoval nějaký opis („použijeme extract method“ či „použijeme extrakci metody“ nebo nejlíp „extrahujeme metodu“). Možná to neříkám úplně přesně, ale snad je to trochu srozumitelné :-)
Refactoring, v kontextu programování může být sloveso (název činnosti) i podstatné jméno (název typu úpravy). Angličtina si vystačí s jedním tvarem.
Při tomhle výrazu se mi asociuje, že budu muset makat jako továrna (factory), abych ten kód přepracoval.
Takže kdyby chtěl někdo použít český výraz, možná by to mohl být
„přepracovat“ 32 200
„přepracování“ 98 000
:-)
Osobně bych asi zvolil ponechání tvaru „refactoring“.
refactoring, refaktoring, refaktorizace, refaktorování, faktorizace, faktor
Rozumný český překlad nemůže být prošpikovaný anglickými slovíčky, pro která lze najít české ekvivalenty nebo rozumné počeštění.
Celkem zavedený pojem v matematice je „faktorizace“. Ten označuje proces, činnost rozkladu na části (z nějakého pohledu). Té části se obecně říká faktor. Faktor je tedy činitel nebo něco, co má specifický vliv na celek. V tomto smyslu se pojem faktor používá i v jiných oborech. A v této souvislosti se setkáme i se souvisejícími pojmy jako například faktorová analýza (analýza vlivu faktorů, složek).
U refactoring v procesu života softwarového projektu jde o přepracování vnitřní struktury tak, aby se to neprojevilo navenek. To znamená, že se pracuje se složkami, ze kterých je (dejme tomu) aplikace poskládána, tedy s jednotlivými činiteli, které mají vliv na celkovou funkčnost — v tomto smyslu s faktory. Protože softwarové aplikace vznikají uměle, nemusíme se (většinou) zabývat jejich rozkladem, tedy faktorizací. Musíme jen přeuspořádat nebo nahradit ekvivalenty jednotlivé faktory a poskládat to dohromady. Pokud je faktorizace procesem rozkladu, pak refaktorizace by měla být procesem opětného složení. Pojem faktorování se jaksi moc nepoužívá. Z toho mi přinejmenším porovnáním souvislostí vychází spíš „refaktorizace“.
-ing je anglická přípona. Slovo refactoring je anglické slovo a patří do anglické knížky. Slovo refaktoring je česko-anglické (a patří do česko-anglické knížky ;) )
V angličtině taky platí, že pokud existuje slovo končící na -tion (a podobně), mělo by se mu dávat přednost před variantou s -ing (opravte mě, jestli kecám; nejsem angličtinář).
Je možné, že z jazykového hlediska (českého) jsou slova „refaktorizace“ a „refaktorování“ podobná. Jsem nakloněn tomu používat oba tvary — kde se co bude víc hodit.
Jakýkoliv nový podnět je vítán.
Pocitově mi verze „refaktorování“ moc nesedí. Asi to zavání matematikou a spodní proud tenhle tvar posunuje až někam k „traktorování“, i když „traktorizace“, rozorání kódu a příprava půdy pro nový růst také není nepěkná asociace. Je to zajímavá úchylka, zabývat se tím až za hranice obzoru. Hlavně že spějeme ke světlým zítřkům. :-)
Mimochodem mě to blbnutí přivedlo na myšlenku, se k tomu slovu postavit podobně jako ke slovu „asociace“.
comprehensions, list comprehension, generátorová notace seznamu…
Test ohněm proběhl na překladu 3. kapitoly Comprehensions http://diveintopython3.org/comprehensions.html.
Zhruba řečeno, pravdu mají všichni:
1) Ani autor nepoužívá pojem důsledně v tom smyslu, že „list comprehension“ je SYNTAKTICKÁ KONSTRUKCE. Jako syntaktická konstrukce něco popisuje, ale nemůže něco dělat. Něco může být jenom důsledkem jejího použití. V tomto smyslu uvažuji, že by se na podobných místech v překladu volněji použil pojem „generátor seznamu“.
2) Zdá se, že „generátorová notace“ by se v textu dala používat místo samostatného „comprehension“.
3) Opakování pojmu „generátorová notace seznamu“ je opravdu zdlouhavé, pokud se to v odstavci vyskytuje víc než jednou. Ale celá kapitola je věnovaná tomuto tématu a asi by neuškodilo, kdyby se některé části toho pojmu vypouštěly. Pokud je například podkapitola věnována „list comprehension“, není asi nutné pořád psát dokola „… seznamu“. Na mnoha místech by stačilo „generátorová notace“, „generátorový zápis“, nebo dokonce jen „notace“ či „zápis“. Pokud se srovnává list comprehension a dictionary comprehension, hodilo by se „notace seznamu“, „zápis seznamu“ — asi jde o to, aby to bylo srozumitelné, že?
Pokud to zadavatel (CZ.NIC) dovolí, byl bych pro zveřejnit on-line uvedenou kapitolu, abyste se mohli vyjádřit a podiskutovat.
sanity check
Jak rozumně a stručně přeložit tohle?
sanity check — první návrhy
zkouška příčetnosti
zkouška zdravého rozumu
test příčetnosti
test správnosti
kontrola koreknosti
Svůj názor už mám, ale nechci zatím ovlivňovat diskusi.
Z těch nabízených je významu asi nejblíž, „kontrola korektnosti“. „Kontrola správnosti“ je hodně široké téma. „Nesprávné“ to totiž může být v mnoha oblastech. Předpokládám, že jde o podkapitolu Unit testing, tam je význam sanity check použit a ukázán na případu konverze z A do B a B do A. Tedy toho, že je taková konverze v pořádku. Jestli se dá věřit http://slovnik-cizich-slov.abz.cz/web.php/slovo/korektni tak „korektní“ by bylo celkem použitelné. Ale mám tušení, že by šlo vymyslet něco ještě lepšího.
sanity check — zatím to vyhrává „kontrola funkčnosti“.
Jde o to, že se předkládá vstup, o kterém předpokládáme, že je zaručeně korektní. Netestujeme tedy vlastnosti toho vstupu, ale funkčnost testovaného kódu v nejzákladnějším režimu (žádné hraniční případy a speciality).
On je ten původní pojem tak nějak příliš citově zabarvený způsobem, který se u nás spíš nepoužívá. I když je to pojem z oblasti Unit testing, v té kapitole použit není.