Je možné používat názvy polí bez diaktritiky?

[avojacek]

Rad bych se zeptal, zda je mozne pouzivat specifikace s nazvy poli bez diakritiky?

Obecne je problem nebo alespon pritez datove typy a nazvy s diakritikou pricemz prinos pouzivani diakritiky v nazvech typu, pripadne sloupcu v DB, atp neni v podstate zadny.

Dekuji Ales Vojacek

[jakubklimek]

Dobrý den, ne, možné to není, je to potřeba pro přesnou reprezentaci v češtině bez vynalézání "cestiny" se všemi možnými konflikty.

Můžete být ale přesnější v tom, co konkrétně je to za přítěž? Jednak sloupce v bežných relačních DB mohou již delší dobu být pojmenovávány v kódování Unicode, stejně jako může být Unicode použit v kódu, druhak ale také nikdo neříká, že sloupce v interní databázi či proměnné v kódu musíte pojmenovávat dle klíčů v externím datovém formátu. Vždy lze, pokud máte s unicode problém, udělat mapování.

[avojacek]

Ok, samozrejme vim, ze pojmenovani sloupcu v DB (alespon vetsine) lze i s diakritikou, stejne tak vlastnosti trid takto nazvat, ale pritez to samozrejmne je, protoze ne vsude to je mozne, a osobne sem nevidel zatim system, kde by se diaktritika pouzivala ve zdrojovych kodech nebo v DB. Samozrejmne je mozne provest vramci serializace/deserializace mapovani. Spis me osobne ta cestina v nazvech prekvapila, protoze doposud jsem se s tim v zadnych datech ani od statnich instituci nesetkal. (coz je jedna z mala pozitivnich informaci ohledne datove komunikace se statnim aparatem)

Osobne pracuji i kdyz ne s nadsenim, ve vyvojovem prostredi, kde neascii znaky nelze pouzivat, obejit se to da. (to je ta pritez)

Samozrejme beru z potazVasi odpoved a jenom budu doufat, ze otevrene formalni normy nebudu muset pouzivat a nebo alespon ne prilis casto.

Dekuji Ales Vojacek P.S. Issue muzete timto uzavrit, diky. P.S.2. Napadla mne jeste jedna pritez, ze timto se stavaji otevrena data otevrena pouze pro CR ;-)

[jakubklimek]

Díky za názor, samozřejmě to není poprvé kdy se s ním setkáváme, ale osobně to považuji za přežitek. Můžete říct, co za vývojové prostředí to je, které to nepodporuje?

Ad P.S.2 - jednak v tom nepomůže ani "cestina", a druhak cílem používání JSON-LD či CSV on the Web v OFN je, aby se data dala použít jako RDF, přičemž jsou namapována na mezinárodní slovníky. Tedy i ten kdo česky neumí, pokud s daty pracuje jako s RDF, datům porozumí. Pokud by toto mělo být částečně zajištěno i na úrovni názvů klíčů v JSON nebo sloupců v CSV, musely by být anglicky. S tím je ale řada problémů

1. Pokud se jedná o pojmy z české legislativy, oficiální překlad často není k dispozici.
2. Řada vývojářů neumí anglicky tak dobře, jak si myslí. Vznikají tak různé a různě kvalitní překlady a z nich pak dezinterpretace založené na představě, že k pochopení dat stačí název klíče či sloupce, což tak není.

[avojacek]

Powerbuilder je prostredi, kde v kodu pouzit diakritiku nejde. Pocitam, ze kdokoliv kdo programuje dostatecne dlouho a nebo v prostredi, ktere neumi uplne dobre Inelisense / code completion a podobne vymozenosti, tak diakritiku v kodu nema rad. Ma to hodne duvodu, jeden z nich je, ze se lehce prehledne dozdil mezi nazvem s diakritikou a bez, knihovny 3tich stran a frameworky jsou typicky anglicky (nekdy ne moc dobre, ale jsou) a pak Vam vyleze mix češtiny, cestiny, anglictiny v kodu a to je silene. Takze prezitek to urcite neni a osobne bych takovej kod ve svem projektu nechtel.

Add P.S.2 samozrejme, ze pomuze, protoze lide s neceskou klavesnici nejsou schopni napsat dane znaky a nebo obtizne, Namapovani na slovniky je super vec a pritomnost schemat take, ale čeština podle meho patří do description a ne do nazvu poli. Nicmene to je nazor asi minoritni, kdyz to neni brano v uvahu a lidi kterym to vadi neni vetsi nez male mnozstvi.

1. souhlas
2. souhlas a prave zde bych znovu upozornil na to, ze nazvy poli cesky a popis pole česky je vec se kterou bych nemel zadny problem, zejmena pri existenci slovniku ,AI strojovych prekladu atd.,

Jedine kde by snad diaktritika v nazvu mohla byt ospravedlnena je CSV s hlavickou, kde by clovek prostym importem mel krasnou excelovskou tabulku. Pro strojove zpracovani nebo predzpracovani je čeština jenom přítěž v lepším případě malá v horším případě velká.

[avojacek]

Jeste doplneni proc mam pohled jaky mam. Sem relativne stary a kdyz "počeštili" funkce v Excelu bojoval sem s tím a vysvobodilo me az moznost pouzivat anglicke nazvy funkci i v českém Excelu (co bylo strasne napriklad, ze nektere fce mely český nazev a nektere anglický) A rozhodne se nechci dozit doby, kdy se podobne prelozi i klicova slova v programovacich jazycich nebo nejake automaticke preklady funkci ve frameworcich jako je .NET a nebo knihovnach. Proste dobre preklady do cestiny neexistuji podle meho nazoru a nema cenu tlacit češtinu do míst kde postrada jakykoliv smysl.

[jakubklimek]

Jasně, tady ale nejde o překlady do češtiny, ale naopak o nepřekládání češtiny jinam, což je taky typicky ztrátové, a to včetně "cestiny".

[avojacek]

Ja Vam rozumim. Osobne vim, ze je tezke vybrat dobre pojmenovani a napriklad u typu castky me vyse uplne taha za oci :-) Coz je ciste muj problem, protoze sem dlouho delal ve firme, ktera delala ERP systemy pro leasingove spolecnosti a pojmenovane jsme to meli jinak a je to proste sila zvyku. Co sem se snazil zduraznit je, ze pojmenovani, at jiz je na spouste mist mozne, s neascii znaky je z pohledu toho co sem za poslednich 25 let programovani zazil spatny napad a nastesti se to pokazde stihlo utnout v zarodku. Čeština patří řekněme do popisů, možná komentřů, ale ne do programu a podle mého ani k pojmenování objektů v DB. Nepřináší to oproti castine nic a přináší spíš problémy. To je celé. Odpověď akceptuji, Vaš pohled na věc též a doufam, že tyto "standardy" nebudu muset používat často. Pěkný den.