Názory k článku
Umnějí portáli česki?

Asi mají k sobě blízko - při vyplňování formuláře pro přehlášení pevné linky jsem se nemohl zbavit pocitu, že formulář sestavoval cizinec a také jsem jim svůj názor červeně do formuláře napsal :-)

Za chybu bych povazoval i tvar tel. cisla. Spravne by melo byt ve tvaru +420 xxx xxx xxx.

A vy jste na to videl nekde nejake normy a zavazne predpisy, ze to povazujete za chybu?

Ano, je to norma.

Ne, není to norma. Číslo se má psát tak, aby bylo snadno zapamatovatelné, to je vše.

Proto také třeba na obalu (a na začátku) Zlatých stránek najdete čísla v různých tvarech:

800 77 77 77
2 3337 3337
8001 0 8001
241 41 41 41
800 20 20 20

Pokud není číslo nějaké zvlášní, nejsnadněji se zapamatuje ve tvaru xxx xxx xxx. Ale třeba informační linka pražských dopravních podniků se jistě zapamatuje lépe ve tvaru 296 19 18 17 než 296 191 817. Bohužel občas nějací pomatenci prosadí ten druhý tvar.

http://mobil.idnes.cz/legislativa/Liberalizace/jakpsatcislo020920.html

Navic typograficka pravidla (kterymi se ridim, protoze delam DTP :D) doporucuji rovnez format XXX XXX XXX. A dokonce jsem, kdyz panovala hysterie okolo precislovani, cetl, ze tento format je vyzadovan nejakou normou prevzatou z DIN (nebo ISO, ted nevim).

Způsob zapisování čísel řeší ITU-T doporučení číslo E.123 (2001), odstavec 2.9 řeší sdružování číslic do skupin takto:

2.9 Grouping the digits of a telephone number is advisable for reasons of memorizing, oral presentation, and printing.

Přímo v tomto doporučení jsou uvedeny příklady:
+22 607 123 4567
+39 211 5432
+41 71 78 901
+49 6 65 43 21

V onom odkazovaném článku jde jen a pouze o názor autora.

V mnoha diskusích se to tenkrát probíralo, a nikdo odkaz na žádnou euro-normu, která by předepisovala tvar XXX XXX XXX, neuvedl. A jsem přesvědčen, že ani neexistuje, třeba ve Francii se stále používá tvar +33 X XX XX XX XX i když mají stejný počet číslic národního čísla (9) jako je u nás. V Anglii se zase používá třeba +44 XX XXXX XXXX.

Naprosto nesmyslné pokusy něco normovat a označovat za "správné" a "chybné" vedou k tomu, že mizí zdravý selský rozum a je nahrazován byrokratickými předpisy.

Proč by mělo být číslo zapsané ve tvaru 296 19 18 17 označené jako chybně zapsané? V rámci své profese byste ho opravdu změnil na 296 191 817, kdybyste dělal propagační leták na tuto linku pro DP Praha? Vůbec by Vám nevadilo, že by tím ten leták plnil svoji funkci podstatně hůř?

A pro zajímavost:

http://www.din.de/

DIN Deutsches Institut für Normung e. V.
10772 Berlin
Tel.:(030) 2601-0
Fax.:(030) 2601-1260

http://www.iso.org/

International Organization for Standardization (ISO)
1, rue de Varembé, Case postale 56
CH-1211 Geneva 20, Switzerland

Telephone +41 22 749 01 11;
Fax +41 22 733 34 30

Takže DIN ani ISO to zřejmě nebudou :-)

Dival jsem se na DIN i ISO stranky a nikde to nenasel... takze to asi byl blabol nebo ma vlci mlha.

Mno, s tim letakem... zalezi na situaci. Zrovna v pripade tel. cisla se pokousim respektovat prani zakaznika, pokud po me nechce vyslovene nesmysly (treba 602-895-587).

Tenkrát se o tom hodně psalo, ale nikdo nedokázal říct, jak se vlastně na ten zápis XXX XXX XXX přišlo.

V ITU-T E.123 jsou povoleny i jiné znaky, ale mezera je doporučovaná:

9.1 Grouping of digits in a telephone number should be accomplished by means of spaces(6) unless an agreed upon explicit symbol (e.g. hyphen) is necessary for procedural purposes. Only spaces should be used in an international number.

(6) Administrations using dots or hyphens as separators nationally may require time to determine the consequences of discontinuing their use.

(verze z roku 1993 a 2001 jsou v tomto shodné)

1) na vojně nás kdysi učili, že pro zapamatovatelnost a vyslovitelnost jsou nejlepší dvouciferné skupiny.

2) ta norma neřeší situaci, kdy je vhodné odlišovat číslo pobočky a předčíslí. Je-li číslo pobočky čtyřciferné, tak při doporučovaném zápisu xxx xxx xxx je to totálně nesrozumitelné. A to nehovořím o situaci, kdy je několik předčíslí podle operátorů a číslo pobočky zůstává stejné.

Vojna - predpis Spoj4-1, ktery resil pravidla provozu na pojitkach (radiostanice, telefonni systemy atd.) urcoval, ze se cislice ctou po trojmistnych skupinach. Protoze pocet cislic zpravy vetsinou neni delitelny tremi beze zbytku, na konci textu se pouziji dvojmistne skupiny (jedna nebo dve).
Byla v tom koncentrovana dlouholeta zkusenost.

Uci se to uz na strednich skolach v obchodni korespondenci :) Zejm. tedy na obchodnich akademiich. Je to upraveno normami.

A ze se k tomu jeste vracim, podivejte se na vase stranky http://www.elap.cz/about/?what=kontakty mate to tam pokazde jinak. Uz jste to rikal vedeni, jak se maji psat cisla?:-)

"Uz jste to rikal vedeni, jak se maji psat cisla?:-)"
Ano, mnohokrat, marne ;]
Po precislovani pred dvema lety jsem hledal, jaky je vlastne spravny tvar zapisu. Tehdy jsem nasel spoustu clanku, z nichz vyplynulo, ze spravny tvar je bud +420 xxx xxx xxx, nebo xxx xxx xxx. Misto znaku + si muzete doplnit cislo pro mezinarodni volaní (0, 00, 1 apod.) Tehdy jsme pouzili jeden z programu, ktery provedl precislovani v nasi databazi, nicmene, jak sam vidite, se spatnym formatem. Moji utechou je, ze aspon u svych klientu a me korespondence pouzivam spravny tvar.

No, nechci stourat, ale podle me spousta clanku nerovna se norma. A uz vubec bych nespojoval normy zapisu telefonnich cisel jak je definuji softwarovi architekti s pravidly ceskeho pravopisu. Do pocitace to zadam jak to po me zada software (resp. interpretuje), v psanem textu by me spise zajimalo co rikaji pravidla. Dosud jsem vsak nemel potrebu hledat, jestli je to nekde definovano.

Nevim jestli na to je norma, ale typografove maji jasno:

====================
pro zápis telefonních čísel platí následující konvence, čísla píšeme po trojicích
tel.: 321 722 544
s předvolbou tel.: +420 321 725 544

Vladimír Beran & kolektiv, Typografický manuál, Kafka design 1999

z http://www.pruzkumnik.cz/nz/okenko/typografie.html

Az nekdo napise genialni algoritmus (nejlepe open source), ktery udela mezery tak, aby to bylo nejlepe zapamatovatelne, tak prosim. Ale pro strojove zpracovani/zobrazovani je nejlepsi tvar xxx xxx xxx. Norma nenorma!

Kdysi jsem se setkal s překlepem dokonce i v banneru, Aleš Slabý v něm inzeroval nabídku jakéhosi "zažízení"

"Výkonná rada ODS vyzvala vládu, aby při výběru uchazečů o evropské funkce respektovala názory a návrhy opozice tak, aby nominovaní reprezentovaly celou Českou republiku."

Zdroj: Prave se stalo na IDNES :-) Co dodat? Leo

Možná jde o nový politický newspeak a obrat "nominovaní reprezentovaly" má vyjadřovat požadavek na oboupohlavnost/bezpohlavnost případných kandidátů. ;-)

Nebo mají reprezentovat i svou znalostí shody podmětu s přísudkem... :-)

"oboupohlavnost/bezpohlavnost"

Tomu se ted prece rika "flexibilita" :-) Leo

Jakou gramatickou úpravou by byla vyjádřitelná naprostá bezpáteřnost politické reprezentace?

"Noční můra bez ůvodu"

Ekonom.Ihned.cz, 7. 3. 2004

Lupo, to vam tak často vypadávají autoři, že tam je po pátku i v pondělí výplňovka o ničem od p.Chlebouna? Už ho prosím zastavte v jeho grafomanství a sebeupozorňování.

Ono občas upozornit na spravnou interpretaci našeho, a konec koncu, jakehokoli jazyka je minimalne vhodne. Tohle se zabyvalo pouze chybama c carkou ci hackem. Pruser je kdyz nejaky portal velkeho ISP rozesila postu v nejake obskurni CP1250 kterra je sice registrovana ale to je vse. Na dotaz proc nepouzivaji jedinou, v CR platnou, normu "ISO8859-2" mi bylo receno ze vetsina uzivatelu ma Windows. Ostatni jsou asi plebs a nestoji jim za to se jim zaobirat. Kdyz si pak chcete vymenovat texty tak musite zbytecne transkodovat. Tady uz se hacky ani carky nezobrazi natoz abych sledoval jejich spravne umisteni. Sranda je ze ISO8859-2 mi v pohode zobrazi i mobil u cp1250 uz je to problem.

Nekdo se timto zabyvat musi a myslim ze je to dobre to obcas pripomenout.

Lidem s CP1250 se mstim tim, ze jim vse posilam v ISO 8859-2 :-). Treba u emailu to pro ne neni velky problem, ale uz jste nekdy koukali na Windows na film s titulkami v ISO norme?

Nekoukali. Obvykle totiz koukame na filmy s titulky.

Heled Krsek, nestvi :-). Premyslel jsem nad tim asi minutu, nez jsem se rozhodl spatne.

Spravne cesky bohuzel zapominam. Chybi cit. A cestina na netu mi v boji proti tomu zrovna dvakrat nepomaha.

Zkusil jste někdy poslat mail, který používá jiný charset například pro předmět a jiný pro tělo mailu, samozřejmě vše korektně? To se pak nebudete stačit divit, až vám přijde na takový mail odpověď poslaná z Outlooku, například předmět bude "Re: Šíleně žluťoučký kůň" specifikováno jako iso-8859-1, protože tělo mailu bylo iso-8859-1. Možná už je to v některé z novějších verzí opraveno (moc tomu ale nevěřím).

Ad koukání na film: Ne, ale už jsem se koukal v linuxu na film s titulky v cp-1250, stačí mít pro mplayer vhodné fonty a není třeba titulky ani překódovávat. :-))

Podle manualu by mel stacit parametr -subcp cp1250, ale to neni takova skodoliba sranda.

No jo, to je otázka, zda budete podporovat normu de jure (a většina zákazníků bude mít problémy), nebo de facto (a problémy bude mít menšina).
BTW: Můj mobil ani PDA nemají s 1250 žádné problémy.

Žádná většina mít problémy nebude, pletete si e-mail s webem (a ani tam nemají windowsoví klienti problémy se zobrazením ISO 8859-2). Zatímco pro použití na webu je windows-1250 v pořádku (i když je vhodnější použít ISO 8859-2 nebo UTF-8), v e-mailu nemá co dělat.

Proboha :) jak jste přišel na to, že je rozdíl mezi e-mailem a webem, že na webu je cp1250 v pořádku a v emailu ne? cp1250 samozřejmě není v pořádku nikdy v "mezisystémové" komunikaci - cp1250 není normované kódování, dokonce by ani nemělo být registrované (kvůli přidání znaku eura, ale to se taktně přehlíží), takže co by dělalo na webu???

Metodou nepříliš populární, a to četbou příslušných specifikací. W3C ve specifikaci HTML 4.01 nijak nepreferuje standardní kódování a jako seznam kódování (a jejich jmen) zmiňuje registraturu IANA - a tam windows-1250 bohužel je. Takže windows-1250 je samozřejmě horší volba než ISO 8859-2, ale jeho použití na webu ničemu neodporuje.

Situace u e-mailu je zcela odlišná. RFC 2045 a 2049 zmiňují mezi povolenými kódováními pouze us-ascii a iso-8859-*. Takže v e-mailu opravdu nemá windows-1250 co dělat.

> RFC 2045 a 2049 zmiňují mezi povolenými kódováními pouze us-ascii a iso-8859-*.

promiňte, ale zdá se mi, že jste si to vyložil poněkud "k obrazu svému" ...

RFC 2045 jsem nečetl celé, ale nezdá se mi, že by problém konkrétních kódování řešilo - tím se zabývá až RFC 2046, které v sekci 4.1.2 jasně říká, že smí být použita pouze kódování
1. vyjmenovaná: us-ascii a iso-8859-1 až iso-8859-10 (mimochodem, pokud se nemýlím, teď máme už i iso-8859-11 až 15)
2. kódování registrovaná u IANA
3. stanovená soukromou dohodou a prefixovaná "X-"

RFC 2049 o žádných "povolených" kódováních nemluví - o zmíněných říká pouze to, že MIME-conformant mail user agent musí rozeznat us-ascii a iso-8859-* a že musí být schopen zobrazit znaky, které mají ascii a iso společné, tedy jmenovitě 1-127 ... z čehož nijak nevyplývá, že "conformant agent" nemůže ("nemá povoleno") používat něco jiného

výše uvedené podmínky se imho docela slušně shodují s požadavky html, nevidím nejmenší důvod, proč by iso-8859-2 měla mít v e-mailu větší přednost, než na webu ...

Takhle to tam ale také není, ta zmínka o kódováních registrovaných u IANA je docela dobře ukrytá a je formulována negativně, ne pozitivně. Rozhodně nejsou tyto tři varianty prezentovány jako rovnocenné, jak jste to pojal vy. U ISO kódování je pouze uvedeno, že je to ISO-8859-X, kde X reprezentuje jednotlivé části ISO-8859 s poznámkou, že v době vydání RFC je to 1-10. Jinak 2045 byl překlep, mělo to být 2046.

To, co musí umět convormant agent, je velmi podstatné. Když použiju ISO 8859-2, vím, že ho příjemce bude schopen zpracovat. Když použiju Windows 1250, je to ve hvězdách. To je pro mne dost podstatný rozdíl.

zmínka o IANA v RFC 2046 nijak ukryta není, dokonce je několikrát opakována ...
co se týče rovnocennosti variant (či "negativní formulace" kolem IANA), máte zčásti pravdu, první bod je nutno rozdělit na us-ascii, což je preferovaná znaková sada, a na iso8859-* - ty jsou pak opravdu na stejné úrovni, jako cokoliv u IANA nebo "X-"; mezi těmito zbývajícími případy není žádný upřednostněn - pokud se domníváte, že ano, prosím odcitujte mi pasáž, ze které tak usuzujete ...
poznámkou o ISO 8859-11 až 15 jsem chtěl naznačit právě ten fakt, že případný vznik dalších sad v této rodině je postaven na stejnou úroveň, jako registrace u IANA - prostě conforming agents nejsou tímto RFC nuceni s ISO 8859-x počítat nějak více než s čímkoliv jiným

ad RFC-2049
> Když použiju ISO 8859-2, vím, že ho příjemce bude schopen zpracovat.

to, že příjemce musí toto kódování znát a že musí být schopen zobrazit znaky shodné s us-ascii, nemá v praxi valného významu - chybějící písmena (nesjpíše ta s diakritikou) a znaky mohou obsah zcela znehodnotit - z tohoto hlediska mi přijde lepší, když v případě windows-1250 se k tomu klient bude chovat jako k binárním datům, nežli aby to v případě iso8859-x zmršil k nepoznání ... ale asi mi nepřísluší kritisovat jedno nepříliš šťastné ustanovení tohoto rfcčka; už dost odbíhám od tématu

spor vznikl okolo Vašeho tvrzení vyjádřeného ve dvou příspěvcích, pokusím se jej sesumírovat do věty "kódování windows-1250 není v emailu povoleno" - toto prostě pravda není

Jak to vidím já: jsou tam vyjmenovány definované znakové sady: v bodu 1 US-ASCII, v bodu 2 ISO-8859-*. Žádné další. Pak je tam jakési pojednání o tom, co to přesně znamená, a nakonec drobná zmínka, že se nesmí použít název znakové sady, který nebyl registrována u IANA, leda by to bylo na základě dvoustranné dohody (a pak musí začínat 'x-'). Jestli tohle klade ISO a windows-1250 na stejnou úroveň, pak asi neumím vůbec anglicky nebo každý čteme jiný dokument.

abychom si rozuměli, já čtu tohle: http://www.faqs.org/rfcs/rfc2046.html

pokud čtu dobře, nikde tam není zmínka, že definovaná znaková sada má přednost před sadou registrovanou nebo oboustranně smluvenou ...

naopak, je tam věta:
"This document does not endorse the use of any particular character set other than US-ASCII,"
kterou bych přeložil jako:
"Tento dokument nepropaguje použití jakékoliv konkrétní znakové sady jiné, nežli US-ASCII"
a ze které podle mě jasně vyplývá, že ISO-8859-*, jakožto sady jiné nežli US-ASCII, nejsou o nic více doporučeny (nebo schváleny či jak chcete "endorse" přeložit) nežli třeba právě windows-1250

Já ho čtu z IETF, ale verze je to nejspíš stejná. Jenže si všímám trochu jiných věcí. Takže vidím, že se tam také píše: A small number of standard character sets are, therefore, defined for Internet use in this document. The defined charset values are: (1) US-ASCII (zkráceno) (2) ISO-8859-X (zkráceno). Teprve o pár odstavců dál jsou zmíněny další dvě varianty, ale ne že by se měly nebo mohly používat, pouze že nic jiného se používat nesmí. Ale vzhledem ke specifickému pojetí slov must a should v RFC to nelze automaticky pokládat za schválení, že tyto znakové sady jsou v pořádku nebo dokonce na stejné úrovni jako US-ASCII nebo ISO-8859-X.

"další dvě varianty, ale ne že by se měly nebo mohly používat, pouze že nic jiného se používat nesmí." - pardon, ale neprotiřečíte si trochu? jestliže vybereme nějakou skupinu znakových sad a prohlásíme, že "nic jiného se používat nesmí", tak potom ta vybraná skupina nejspíše "by se mohla používat" (pokud ne, tak jsme zřejmě vybrali skupinu, ke které děláme opak, příliš široce, což je silně nelogické, ovšem nikoliv nemožné - ale v takovém případě by ještě v textu muselo být explicitně určeno, co z té vybrané skupiny se použít nesmí, což nikde řečeno není)
(ehm, jak si to po sobě čtu, mám pocit, že nejjednodušší by bylo nakreslit si množiny a ne plácat o "skupinách" :-)

dále mi není jasné, jakým způsobem mohla být slova "must" a "should" předefinována (imho i v RFC 2046 si zachovávají význam stejný, jako v jiných normativních textech), aby jejich NEpoužití dovolovalo Váš výklad textu (podotýkám, že tato slova v pasážích o výběru charsetu až na jednu vyjímku vůbec nejsou, a tou vyjímkou je "should" v odstavci o výběru "lowest common denominator", který se vůbec nezabývá tím, jestli je kódování definované, registrované nebo dohodnuté)

Vy opravdu nevidíte vůbec žádný rozdíl mezi tím, že jsou specifikovány definované znakové sady a způsobem, jakým jsou vymezeny ty ostatní? Proč tedy potom, podle vás, vůbec tu první skupinu výslovně jmenují? Vždyť tyto znakové sady byly registrovány u IANA už v době vydání dokumentu. Takže kdyby to bylo podle vás (tedy že by mezi US-ASCII/ISO-8859-* a ostatními registrovanými nebyl naprosto žádný rozdíl), vůbec by nebylo třeba je výslovně zmiňovat, protože spadají i do těch registrovaných.

Zmínku o významu slov must a should jsem uvedl proto, že pokud je něco striktně zakázáno, neznamená to automaticky, že cokoli jiného je povoleno nebo dokonce vhodné. To, že definice SMTP striktně zakazuje řádky delší než 998 znaků, také ještě neznamená, že řádek o délce 600 znaků je stejně v pořádku jako řádek o délce 60 znaků.

Chcete tedy říci, že záměrem autorů RFC 2046 bylo diskriminovat všechny jazyky, jejichž zápis si nevystačí se znaky pokrytými US-ASCII a rodinou ISO-8859, jenom proto, že pro účely textu zmínili existenci pouze těchto znakových sad? To snad ne ...

Šestisetznakový řádek je z technického hlediska naprosto stejně v pořádku, jako řádek šedesátiznakový. Není ale v pořádku z hlediska netikety. RFC 2822 jasně říká, že klient si musí poradit i s řádky delšími, než 78 znaků. Vaše pojetí významu slov by vedlo na rovnost "should" = "must", což je nesmysl.
Obdobně windows-1250 je v emailu z technického hlediska stejně v pořádku jako ISO-8859-2, rozdíl je opět v netiketě. Jak jsem již napsal, RFC 2046 kromě US-ASCII a výběru "lowest common denominator" nic explicitně neupřednostňuje ani slovy "must", ani "should"; pokud chcete namítnout, že to upřednostnění je implicitní, pak by z toho vyplývala výše zmíněná diskriminace "neISO" písem, což považuji za nepřípustné.

Ne. Jejich záměrem IMHO bylo, aby se používala US-ASCII tam, kde stačí. Kde nestačí, tam ISO 8859-X, a teprve když ani to není možné, sáhnout po jiné znakové sadě, a to pokud možno takové, která je registrovaná u IANA. Teprve kdyby ani to nebylo možné, použít (po předchozí dohodě) něco úplně jiného. To je postup, který považuji za naprosto logický a přirozený.

Mé pojetí neříká, že must = should. Mé pojetí říká, že should není jen nějaký nezávazný hint, který by byl na úrovni pouhé slušnosti. V úvodu je totiž jasně řečeno, že požadavky formulované jako should by měly být porušeny pouze v situacích, kdy k tomu máte hodně vážný důvod. Takže proto odmítám souhlasit s vaším názorem, že 600 znaků dlouhý řádek je úplně stejně v pořádku jako 60 znaků dlouhý řádek. Zrovna tak odmítám připustit, že cokoli není striktně zakázáno (must not), je automaticky v pořádku.

Souhlasím s Vámi v tom, že postup, který popisujete v prvním odstavci, je přirozený a logický. Není ovšem v onom RFCčku nijak vyžadován. Stejně tak, jako může být vážným důvodem porušení maximální délky řádku například citace dlouhé URL, tak mohou být pro někoho vážným důvodem k použití windows-1250 třeba české uvozovky, které v ISO-8859-2 chybí. Ale nepřu se o přirozenost a logiku, přu se o technickou stránku věci: Vy jste na začátku této diskuse tvrdil, že windows-1250 se použít nesmí, což není pravda. Konkrétně napsal jste "RFC 2045 a 2049 zmiňují mezi povolenými kódováními pouze us-ascii a iso-8859-*. Takže v e-mailu opravdu nemá windows-1250 co dělat." Nemluvíme přeci o schrödingerově kočce, ale o jasně rozhodnutelné věci se dvěma stavy, takže obrat Vašeho výroku "není povoleno" na "je zakázáno" nebo "nesmí se použít" si snad dovolit mohu.
Co se týče toho "should", teď říkáte, že takto dané požadavky porušeny být mohou, zatímco předtím jste k tématu tvrdil "pokud je něco striktně zakázáno, neznamená to automaticky, že cokoli jiného je povoleno". Tak tedy nově tvrdíte, že "nestriktní" (should místo must) zákaz porušen být může, zatímco předtím jste to popíral. (Jestli "automaticky" nebo "neautomaticky" je snad jedno, viz poznámka o determinističnosti výše.) Tak se rozhodněte ...
(Vaši poslední větu, která opět podporuje to starší citované stanovisko, úmyslně pomíjím, neboť pojem "v pořádku" je poněkud vágní a zahrneme-li do něj netiketu, lze s tou větou souhlasit.)

Pokud dlouhé URL považujete za vážný důvod, ospravedlňující překročení limitu 78 znaků na řádek, pak se velmi výrazně lišíme v pohledu na to, co je to vážný důvod. Jednak proto, že to lze velmi snadno vyřešit bez překročení 78 znaků, jednak proto, že si stejně nepomůžete, kdysi jsem někde viděl ukázku URL (ze stránek Microsoftu), které mělo kolem 11000 znaků - takže tam už byste to chtě nechtě řešit musel. Pod označením vážný důvod si představuji daleko významnější technické obtíže.

Dobrá, místo definovanými jsem napsal povolenými. Za tuto chybu se stydím, ale přesto trvám na tom, že v e-mailu nemá windows-1250 co dělat. Protože windows-1250 nepřináší nic, na co by nestačilo iso-8859-2 a jiná než definovaná kódování by měla být použita až tam, kde to bez nich nejde.

V dalším odstavci pak mícháte dvě naprosto nesouvisející věci. Za prvé: požadavky specifikované jako should mohou být porušeny - ovšem jen z vážných důvodů. V prvním odstavci jste ovšem názorně předvedl, že si frázi z vážných důvodů vykládáte jako kdykoli se mi to hodí, takže odtud asi bude pramenit ono nedorozumění. A pokud tento postoj nepřehodnotíte, asi se těžko dohodneme.

Druhá věc, a to mé tvrzení, že je-li něco zakázáno, není cokoli jiného automaticky povoleno, je naprosto přirozené a nijak nesouvisí s významem slova should. Hlavně mne vůbec nenapadlo, že tak prostá a přirozená myšlenka může být nepochopena a odmítnuta. Zkusím to demonstrovat na příkladu z reálného života: v silničním zákoně se píše, že je zakázáno vjet do ulice, kde je značka zákaz vjezdu. Má poznámka pak upozorňuje, že to automaticky neznamená, že mohu vjet do jakékoli ulice, kde ta značka není - jednoduše proto, že to může být zakázáno z mnoha jiných příčin. Pokud máte základní matematické vzdělání, shrnul bych to tak, že prostě obracíte implikaci. Vy si přečtete, větu, že (zjednodušeno) není-li název registrován u IANA, nesmí se použít (aniž by ... atd.) a vyložíte si ji tak, že je-li název registrován, může být použit bez jakýchkoli dalších omezení. Ale to ta věta přeci vůbec neříká.

Ještě horší ovšem je, když kódování neodpovídá tomu, které bylo specifikováno v záhlaví.

Čárky a interpunkce obecně nemůže přebývat, protože pravidla pravopisu definují něco, co se nazývá vložená věta. V širším pojetí, vám se to líbit nemusí, lze do každé věty vkládat větu nijak nesouvisející s žádnou částí věty.

V ještě širším pojetí lze interpunkci podle způsobu užívání autorem považovat za náhradu řečnických značek, tudíž ji vlastně není ani dobré svazovat pravidly, protože původně šlo především o záznam mluvené řeči, nikoli o logické rozclěnění textu na věty hlavní a vedlejší.

Ted nevim jestli, jsem vas dobre pochopil. Ale ja, osobne si pamatuju ze i vlozena, veta ma sva pravidla pro interpunkci. A , spousta lidi, tato pravidla nezna. A chybne, pouzita interpunkce velmi casto rusi smysl, vety.

já jsem to pochopil tak, že pan Novák neumí česky :-)

pokud je do věty něco vloženo, pak buď nesmí přibýt čárka žádná nebo musí přibýt čárky dvě (před a za) - přibude-li jedna, je to chyba

k záznamu mluveného slova není určena tužka a papír (klávesnice a počítač), nýbrž diktafon...
pokud nejde o umělecký záměr, ale o věc charakteru informativního, měla by se psaná forma držet snahy zachytit myšlenku - což pravopisná pravidla kupodivu poněkud ulehčují - a nikoliv zachytit veškeré nedostatky a vady řeči mluvčího ...

Kavole, to ses asi spletl, že? Samozřejmě jsou případy, kdy obě čárky ohraničují vložený text (a stejně tak tam nemusejí být), ale také je spousta případů (ne-li většina), kdy tam čárky dáš z obou stran - například vedlejší věta mezi dvěma větami hlavními. To bychom pak nesměli rozlišovat přístavek, přívlastek (volný, těsný, postupně se rozvíjející, několikanásobný), vedlejší větu, oslovení, samostatný větný člen a další. Já vím, studuji už nějakým rokem češtinu na MU, ale alespoň tomu trochu rozumím.

Zdravim, dnes jsem se chtel informovat o poskytovatelich internetu a narazil jsem v tabulkach na dost kuriozni cesko-anglicky hybrid "CABEL" - skutecne anglictina takove slovo nezna, a cestina bohuzel taky ne. Bud by melo byt KABEL, nebo CABLE.... Bohuzel tento preklep figuruje ve vsech tabulkach pomerne v hojne mire.