CPH a Omega resp. CPH/Omega by mohly být přímo klíče, ale asi by to fakt nejdřív chtělo probrat s Jersonem.

No dá se to udělat i později jen jede o to aby se na to nezapomnělo.

Chtěl bych, aby anotace (jak při rozbalení ve výpisu tak při nájezdu myší) ukazovaly i miniaturu obrázku. Byl by to příliš velký opruz nebo ne?

No dobře, když už jsem tu heretickou myšlenku vyslovil veřejně, proč to rovnou nehodit i sem abych mohl být patřičně uzeměn rovnou ještě než se stihnu rozletět.


Jak moc náročné by bylo připravit Kostku (v rámci Nightfall překlopení, rozhodně neuvažuju nijak o Sunrise) na alternující anglickou lokalizaci?

Moje představa je jeden a tentýž web kde by se:
a) jedním kliknutím přeplo mezi CS a EN zobrazením
b) články a diskuse by měly dodatečný atribut LANG s hodnotami CS / EN nebo tak něco a bylo by možné je v nastavení vyfiltrovat (stylem "CS", "EN", "CS+EN")


Píšu "připravit", protože neříkám, že bysme nutně museli mít tu možnost přístupnou (tj. všechno přeložené atp.), prostě aby se to dalo případně průběžně dodělat (dodělávat)

No rozhodně to bude dost práce navíc.
A chtělo by to určit čeho všeho by se to mělo týkat jen by to tedy fungovalo na základě přepnutí žádný filtr na hledání ve všech jazycích bych nedělal.

Nechci kazit velké plány, já bych nejdřív hrozně rád viděl plně funkční Nightfall - do kterého jsme si už tak vymysleli kotel nejrůznějších funkcí a pokud budeme postupovat stylem že by se nám hodilo tohle a tamto a možná ještě támhleto, je to nejlepší recept jak nemít nikdy nic.

Druhá věc, Kostka stojí na česky psaných článcích, překladech do češtiny a českých diskuzích. I kdyby Google začal zítra prodávat babylonské rybky, nikoho to nepřinutí aby místo na rpgnet začal chodit na Kostku.

Za třetí, už tak se pohybujeme v poněkud kalných vodách, co se autorských práv a podobného bullshitingu týká. Radši bych tuhle krabici s dobrotami nechal nenápadně postávat za dveřmi, namísto abychomu ji postavili do výlohy na náměstí.

Gurney: no takhle to právě úplně nefunguje... když chceš aby měl systém jazykové verze, tak je potřeba si to rozmyslet co nejdřív, protože převod už existujícího systému, který s tím předem nepočítal, je velice netriviální (jakože kurva složitej).

Aby to fungovalo, tak musíš mít určitou logiku v DB a funkce napsané s tím že se počítá s více verzemi.


Ale jak jsem psal, byl to jen nápad a souvisel hlavně s Polskem atp., nebyl to žádnej záměr konkurovat EnWorldu nebo tak něco. A máš asi pravdu, že priority jsou jinde... já si to tu spokojeně konečně dostal pryč z hlavy, tak to zase můžeme s klidem zahodit a zapomenout :)

Ta jazyková mutace není úplně blbej nápad, ale muselo by to být dobře propojené s Google Translatorem.

Lidé tu asi dál budou diskutovat hlavně česky a případným cizincům by se měly posty asi samy překládat.

Gurney: (z Grey Council)

Ok, s dovolením bych tuhle diskusi přenesl do exaktnějšího módu formální logiky, protože to je to co nakonec bude implementováno a myslím, že je potřeba si to vyjasnit přesně:

Klíče musí následovat nějakou logiku, která bude konzistentní a nednoduchá na pochopení a další použití. Zásadní je zvážit, v jakých instancích budou klíče používané a to jsou podle mě v zásadě dva případy:

1) budou v podobě klíčenek (klíčenka = množina klíčů) použité k definování "sekcí", což uděláme my a "předem" při rozkládání obsahu skrz Kostku.

2) budou v podobě jednotlivých klíčů použité k filtrování, což budou dělat uživatelé.


Otázka je, jaká logika bude v tom kterém případě používána.

V případě 1 to bude disjunktivní logika (parametr OR, neformální označení "nebo"): "A v B => C" kde C bude obsahovat všechna A i B), tj. budeme skládat klíče k sobě podle toho co všechno budeme chtít dát do jedné skupiny.

• Pokud uděláme fiktivní sekci DnD kde budeme chtít mít všechna pravidla DnD, pak definujeme klíčenku (množinu) "sekce všech pravidel DnD" jako "2e v 3e v 4e v 5e" výsledkem čehož bude sekce, která shrne všechno z DnD.
• Pokud uděláme fiktivní sekci d20 systému, kde budeme chtít mít všechna d20, použijeme tutéž logiku, jen levou stranu věty (argumenty implikace) rozšíříme o např. "v d20system v SWSE"

V tomto případě je myslím zjevné, že je výhodné mít klíče definované jako vzájemně výlučné (tj. pokud jsou klíče obecné "d20system" a konkrétní "DnD5e", pak je "DnD5e" vyloučeno z "d20system"; souhrn d20system+DnD získáme klíčenkou "d20system v DnD5e"), protože to usnadní naší práci s věcí (budeme používat pouze "součty").

Pokud bys použil překrývací logiku (DnD5e by zároveň vždy bylo d20system), pak bys d20system bez DnD musel použít konjunktivní logiku (parametr AND, laicky "a zároveň") a definovat to jako (d20system ^ ¬DnD5e). V tu chvíli používáš druhý typ logiky (konjunkci) a ještě navíc negační parametr (¬), přičemž bys tím nedosáhl ničeho, co v případě výlučné logiky nedokážeme zařídit s jednoduchou disjunkcí - tj. je to složitější (možná i na implementaci, rozhodně na práci s tím), systém to učiní méně přehledným a nepřináší to žádnou výhodu.



V případě 2 bude ale uživatel nejspíš používat odlišný postup. Přijde k filtru a řekne "chci DnD5e". Zjistí, že dostal příliš mnoho výsledků (články mají více klíčů) a prohlásí "chci DnD 5e proDM" (zaškrtne druhý klíč). Zjistí, že to stále nestačí a prohlásí "chci DnD5e proDM a Přelad" (přidá třetí klíč).

V tomto případě uživatel intuitivně používá konjunktivní logiku ("DnD5e" - nestačí, příliš mnoho výsledků; "DnD5e ^ proDM" - stále příliš mnoho; "DnD5e ^ proDM ^ Překlad"). Přičemž v každém kroku (při každém přidání dalšího klíče) chce z hledání vyloučit vše, co neodpovídá jeho hledání.

Pokud použijeme výlučnou logiku klíčů, pak je situace snadná - uživatel prostě a jednoduše přidá další klíč, který jeho hledání upřesní (odfiltruje všechny ostatní výsledky). Pokud uživatel zjistí, že nenachází to, co hledá, tak hledání rozšíří (přihodí výsledky dalšího klíče). Důležité je, že jak upřesnění, tak rozšíření výsledků hledání probíhá úplně stejně - přidáním dalšího klíče do "logické věty" za použití té samé logiky (konjunkce, AND, ^) a zakliknout 3-4 další klíče je minimální náročnost (pokud se teda stránka nebude refreshovat při každém jednom dalším klíči, což ale pokud vím Dukolm psal, že nebude)

Pokud použiješ překrývající logiku klíčů, tak má uživatel problém, protože některé klíče nebudou fungovat jako jednoznačné určení. Řekněme, že uživatel hledá překlad něčeho ze SWSE pro DMy. Přijde k filtru a zadá "d20 system". Vypadne mu mrtě výsledků s DnDčky. A teď udělá co? Přidá klíče proDM a Překlad. Vůbec si nepomohl, stále se topí v DnDčku. Jediné, co by mu pomohlo, je klíč SWSE, jenže tímhle způsobem se v klíčích brzo utopíme.
Další možnost by byla dát mu právo použít jinou, než konjunktivní logiku, jenže praxe říká, že valná většina lidí ve skutečnosti nedokáže pracovat s formálními operátory hledání (OR, AND, -, / atp. - pár lidí sotva zvládá "" a i to je pro jiné dost aby je považivali za "experty")

Pokud by uživatel hledal všechno pro d20, tak při výlučné logice si vystačí s tím, že zatrhne pár DnD klíčů navíc, což je easy a intuitivní a v neposlední řadě si tak vystačíme s méně klíči, protože obecné klíče budou užitečnější (povedou na konkrétní výsledky které nejsou tak rozsáhlé, aby se týkaly specifických klíčů)




Tj. jsem velmi silně přesvědčený, že pro obě hlavní instance užití a z nich vyplývající logiky a postupy práce (pro naší práci s klíčenkami pomocí disjunkce a pro práci uživatelů s filtry pomocí konjunkce) je značně výhodnější, aby každý klíč byl pokud možno výlučný ostatním - ostatně právě kvůli tomu dáváme článkům více klíčů, protože práce s klíči prostě používá výlučný systém - když nebudeme mít výlučné klíče, tak můžeme z klíčů rovnou udělat strom kdy každá úroveň blíž kořenu "všechny články" bude zahrnovat všechny sobě podřazené a článkům pak můžeme dávat klíč jen jeden - což je překombinované, nesmyslné a ke zbláznění (a logika toho by byla maniakální na vytvoření)

No to je textu. Tak popořadě.

Multijazyčná kostka.
Možná vyhlídka do budoucna ale ne dříve jak 2018, trošku jsem s tímhle požadavkem počítal do budoucna. Ale Nighrfall je přední a dokud nebude on hotový se vším co jsme v něm chtěli, nehodlám nic takového řešit. Mužem někdy u piva probrat jak se dá jít ven s anglickým obsahem a nedávat ten český tolik na oči.

Štítky
Sirien to nazývá klíči ale promine máme tu překladový klíč a aby se to nepletlo zvolil bych tento název a i více to bude popisovat funkci.
Funkce bude taková že každý štítek bude patřit do jedné skupiny.

Počítám s tím že v rámci skupiny bude vyhledávání/filtrování fungovat tak že štítky skupiny budou mít vazbu OR a skupiny mezi sebou AND.

Příklad

Skupiny a štítky (pouze ilustrační systémy by byly konkrétnější)

Systémy (skupina)
- DnD
- Fate
- GURPS

Typ (skupina)
- Pro GM
- Dobrodružství
- Pro hráče

Tak půjde vyfiltrovat věci co jsou Věci pro vypravěče které jsou k DnD nebo k Fate.
Tohoto modelu bych se chtěl držet pokud by to šlo přejde mi nejpoužitelnější.

Zároveň budou existovat i skupiny štítků které běžný uživatel neuvidí a budou sloužit nám aminům a systémovým funkcím.

Multijazyčná kostka
Jako zas to neberte jako že to chci zazdít, nepřijde mi to jako marnej nápad, ale ani jako priorita.

Štítky/Klíče
Ten pohled formální logiky má sice něco do sebe, blbé na tom ale je, že výlučnost klíčů prostě neodpovídá realitě, kdy DnD prostě je jedním z mnoha d20 systémů.

Mnohem závažnější argument mi tak přijde to vyhledávání a jeho intuitivnost. Přemýšlel jsem nad tím a myslím že problémem ve skutečnosti není, že bychom měli klíč, pod kterým jsou všechny non-DnD d20 systémy, jen se ten klíč prostě nemůže jmenovat d20, když každý kdo se o to trochu zajímá se na wiki dozví, že "The d20 System is a role-playing game system published in 2000 by Wizards of the Coast originally developed for the third edition of Dungeons & Dragons..." (což je pravda). Tedy mohli bychom mít něco jako d20 bez DnD (pokud někdo vymyslíte lepší název) a pak se nabízí otázka, jestli vůbec mít d20 tag.

S tím související otázka, v těch skupinách co představuje Dukolm (s tím že pokud to dobře chápu, funkčně to nejsou klíčenky, jen formální kategorie tagů, které už používám dneska), chceme mít skupinu Engine, která by pak obsahovala šítky Fate, d20, Storyteller/Storytelling, atd. Mě přijdou docela užitečný, ale zas uznávám, že by je používala asi spíš jen menšina uživatelů Kostky.

Štítky, oprava: Zaprvé se omlouvám za chybu v popisu - v druhém případě (filtrování uživatelem) při použití konjunktivní logiky (postupného upřesňování dotazu) samozřejmě nelze zadané hledání dalším klíčem rozšířit. K rozšíření by došlo odebráním nevhodného klíče. V podstatě to ale na logice použití moc nemění.


Gurney: Pokud je problém s názvem klíče, tak to je ten poslední problém vůbec - prostě přejmenujeme "d20 system" na "ostatní d20". Jestli takový klíč bude potřeba nebo ne závisí, jak moc věcí by do něj spadlo (tj. zda se například vyplatí dělat samostatný klíč pro SWSE). Pokud by se nevyplatil, věci z něj spadnou pod klíč "jiné RPG".

Oddělovat samostatně "engine" mi přijde zbytečný. Efektivně většina lidí se podle toho neorientuje a nás pár super geeků co tohle rozlišujeme dokážeme potřebné věci dohledat i bez toho.


Dukolm: "klíče" to kdysi nazval Alnag, já se snažím jen udržovat konzistentní názvosloví - občas mi to dělá problémy, intuitivně bych to nazýval labels/štítky, tak klidně můžeme přejít na to že tomu budeme říkat štítky, proč ne, když si všichni řekneme že si tak budeme rozumět.


To co píšeš k filtrování mi nedává moc smysl - aktuálně nejsou štítky nijak rozdělené, všechny fungují stejně a jejich výpis po skupinách je jen otázka zobrazení (orientace), nikoliv funkce; skutečně chceš přidávat další úroveň struktury a rozlišovat skupinu štítků a štítek a zacházet s nimi odlišně?

Jako ta logika co píšeš (použít AND mezi skupinami a OR uvnitř skupiny) zní dobře, jen se bojím aby to pak dokázali pochopit a intuitivně použít i lidi, co neumí používat operátory.

Jen pro představu, pokud zadám "fantasy + historický + horor + dnd3e + dnd5e + překlad + inspirace + ke stažení + proDM", tak tím vytvořím následující logickou větu:

(fantasy v historický v horor) ^ (dnd3e v dnd5e) ^ (překlad v inspirace v ke stažení) ^ proDM => SEARCH RESULT

to není úplně triviální...

...na druhou stranu je pravda, že tohle uživatel neuvidí, ten uvidí jen kategorie se zaklikávátky - ale právě proto se bojím jestli bude pochopitelné, že zakliknuté položky v jedné kategorii se vůči sobě chovají jinak ( v ) než zakliknuté položky napříč kategoriemi ( ^ ).

Tak nějak se prokousávám první částí realizace a to jsou články. A při navrhování editace jsem došel k nápadu udělat stránky článku jako samostatnou část jádra a umožnit tak jejich rychlé prohazování a zachování jejich unikátnosti v rámci webu.
ten současný tag <page name=""></page>mi příjde dost nanic musí se zpracovávat speciálně při každém zobrazení článku.

Ehm. A teď pro nás (mě) pitomce: co to znamená, "samostatná část jádra"?

A co to znamená "prohazování" článků?

A jak s tím souvisí PAGE tag?

No včera už sem byl z programování trochu mimo ale myšlenka zůstala.

Současný stav:
Článek má obsah ten lze rozdělit tagy na jednotlivé stránky. Se stránkami se špatně manipuluje a u delších vícestránkových dokumentu se stávají i nepřehlednými.

Moje představa je
Budeme mít článek a ten bude mít n-stranek které budou samostatně editovatelné.

takže v editaci článku by jsi měl místo obsahu seznam stránek.

• Stránka 1 - editace - up - down
• Stránka 2 - editace - up - down
• Stránka 3 - editace - up - down

Doufám že tentokrát už sem to popsal lépe.

Tak v rámci osobního rozvoje jsem testoval jednu novou technologii na práci s databází Doctrine 2 testovacím subjektem se stal Nightfall a výsledek je více než uspokojující. Méně práce pro mě tuto knihovnu využívá velké množství velkých webů takže stabilita pro nás.

Ještě odladím pár dorobností a zase se vrhnu na vývoj článků.

Vždycky, když něco takového napíšeš tak mi je hrozně líto, že vůbec netušim, o čem to mluvíš :( Skoro abych se konečně naučil nějaký programovací základy, fakt...

No to je tím že sleduji nové trendy a když mě něco vadí hledám možná řešení a tak jsem uprostřed psaní vlastní vrstvy obsluhy komunikace s databází která by fungovala nějak inteligentně se rozhodl si zkusit nové řešení že pokud se ukáže jako nedostatečné tak danou vývojovou větev smažu ale ukázalo se to jako docela dobrý krok dopředu.

No ty neumíš programovat a nerozumíš mi, já zase nemám čas se naučit s InDesingem a Photoshopem abych udělal něco pro překlady.

Tak další vývojové okénko.
Vím že jsem předestíral že by jsme měly na nightfall přejít se stávajícími hesly ale narazil jsme na možný problém.

Nastínění situace: současné době šifrujeme hesla dvěma způsoby podle toho kdy se uživatel registroval. Jeden z těch způsobu je už těžko napodobitelný v novém prostředí a oba způsoby jsou už překonané a jsou rozkódovat v rámci minut nebo hodin.

Povodní záměr byl že zachováme oba přístupy jen při přihlášení vytvoříme heslo novým zpusobem a pře uložíme ho. Výhody jsou jednoduchost pro uživatele. Pro nás odklad problému do budoucna tím že budou existovat 3 způsoby.

Aktuálně můj současný nápad je vygenerovat jednorázová hesla všem uživatelům s tím že je pošleme na email(první fáze na jejich žádost později třeba postupný obeslání po dávkách). Řešení má výhodu že bude příjemnější pro další rozvoj. Nevýhoda je zátěž na uživatele a potřeba o tom informovat dopředu aby si ty co nemají email ho vyplnily.

Na tohle bych chtěl prosím vyjádření většiny ke které možnosti se přikláníte.

Já jsem pro možnost číslo dvě.

Sice by bylo pěkné, aby uživatelé nemuseli dělat vůbec nic, ale jeden email není tak moc náročný (sice to bývá otrava, ale stejně se s tím většina lidí potkává dnes a denně na nejrůznějších jiných stránkách) a do teď nemuseli zadávat ani ten email. Hlavně teda, pokud to bude zjednodušení a zprůhlednění do budoucna, tak jsem pro. Můžeme na to upozornit na hlavní stránce a dát tomu čas. Při přihlášení (novém i stávajícím) by pak mělo být vyžadováno doplnění emailu.

A myslíš tím, že by tahle akce - tedy zasílání generovaných hesel - proběhla ještě před nasazením Nightfall? Nebo by byla možná i za jeho provozu?