Új hozzászólás Aktív témák
-
martonx
veterán
Az a baj, hogy valami miatt (talán mert ennek a legegyszerűbb átlátni magát a forráskódját is), a wp felhasználók, sőt a wp fejlesztők sem tudják hogyan is kellene normálisan szabályosan wp-zni. És van aki még könyvet is ír... Tragikus.
Egyébként kismillió fordító plugin van hozzá: link a legelső szerintem része az alap telepítő csomagnak.
[ Szerkesztve ]
Én kérek elnézést!
-
#5303
Sk8erPeter
nagyúr
biker
#5300
Sk8erPeter
nagyúr
"POEDIT a neve, offline szerkesztheted a .po .mo nyelvi fileokat"
Az, hogy fájlokat kell szerkesztgetni, az nem egy normális fordítási megoldás.
Adatbázisszintű, normális grafikus felülettel rendelkező, átlátható fordítófelületre gondolok, amilyen például Drupalnál van. Ott is .po-fájlok a kiindulópont, de aztán lehet normálisan alakítgatni a fordításokat, azokat is, amelyek saját modulban/theme-ben fordulnak elő, a t('text to translate') függvényhívással (azt is lehet látni az admin-felületen szövegesen, hogy nagyjából melyik oldalelemnél hívódott meg először a fordításra szolgáló függvény).
Feltételezem, WordPress-ben az az alsóvonalas __('text to translate') való erre, már amennyit láttam belőle. De eddig csak a .po- és .mo-fájlok szerkesztéséről láttam infót, a martonx által említett xili-language-ben is .mo-fájlokra láttam hivatkozást.
Na de van valami normális megoldás is rá, nemcsak fájlszintű?"vagy wpml plugin és online is megteheted"
Ja, végül is megválaszoltad, csak ezt most néztem meg: http://wpml.org/
De ez fizetős! A legolcsóbb 29$, ami normálisan használható, az már 79 dollár, vagyis majdnem 18 ezer Ft.
Ingyen tényleg nincs WordPress-ben normális fordítási megoldás?
(Drupalban alap, hogy ingyen van a legalább ilyen komplexitású fordítási megoldás.)Sk8erPeter
-
#5304
The DJ
addikt
Sk8erPeter
#5303
The DJ
addikt
válasz
Sk8erPeter
#5303
üzenetére
"Ingyen tényleg nincs WordPress-ben normális fordítási megoldás?"
Én ezt használom és eddig tökéletesen megfelelt minden ilyen feladatra: [link]
https://wpszaki.hu - Minden, ami WordPress, cikkek kezdőknek és haladóknak.
-
#5305
biker
nagyúr
Sk8erPeter
#5303
biker
nagyúr
válasz
Sk8erPeter
#5303
üzenetére
a .po .mo fileok matatása (ami kb xml) miért gáz?
a rendszer meghívja a nyelvi filet, és utána ha ki kell íratni valami szöveget, akkor van például így(mantra a sablon neve):
<?php _e( 'Tagged','mantra'); print ' '.$tag_list; ?>és ha van a hu_HU.po fileban fordítás arra, hogy Tagged, akkor nem Tagged lesz, hanem "Jelölve" pl.
Vagy link kiírása:
<?php edit_post_link( __( 'Edit', 'mantra' ), '<span class="edit-link">', '</span>' ); ?>
Ezen mi olyan szörnyű? Mitől okosabb a Drupal?Na ha valaki elkezdi a forrásban átírni a kódot, akkor gány lesz.
poedit ingyenes, és a hülye is tudja kezelni, talán 4 gomb van rajta.igen, wpml sajna fizetős. és még mennyi ilyen van WP-hez, hogy ingyen kapsz valamit, de a segítség hozzá fizetős
na az a genyóság, igen
Pl WooCommerce ingyenes, de az egyetlen normális importáló/exportáló 200USD, hát köszi, anélkül hogy kezelsz egy rendes webshopot, pl 1000 temékkel?Elektromos autó töltő berendezések | Mesterséges növényvilágítás | Mai ajánlatunk: www.gerisoft.hu | www.e-autotoltokabel.hu | www.agrar-vilagitas.hu |
-
-
#5307
Sk8erPeter
nagyúr
biker
#5305
Sk8erPeter
nagyúr
"és ha van a hu_HU.po fileban fordítás arra, hogy Tagged, akkor nem Tagged lesz, hanem "Jelölve" pl.
Vagy link kiírása:
<?php edit_post_link( __( 'Edit', 'mantra' ), '<span class="edit-link">', '</span>' ); ?>
Ezen mi olyan szörnyű? Mitől okosabb a Drupal?"
Korábban pont ezt írtam le, de akkor elmondom másképpen.
Meglep, ha ezzel újdonságot mondok neked, de a fájlkezelés mindig nagy overhead egy tisztességes adatbázisban való lekéréshez képest. Gondolom nem újdonság, hogy egy normálisan karbantartott, indexelt adatbázis többszázezer sorban való kotorászástól sem esik hasra. Ezzel szemben ha fájlokban kell ennyit kotorászni, na az úgy már elég durva lehet.
Attól okosabb a Drupal, hogy a fordítandó stringek adatbázisban (is) tárolva vannak, van egy locales_source tábla, amiben a forrásstringek helyezkednek el, megfelelő azonosítóval (lid) ellátva, az eredeti angol szöveggel, egy szövegcsoporttal (pl. menu vagy field és ilyesmik), megjelöli a belső Drupalos path-t és kontextust, ahol a szöveg maga előfordul, aztán van egy locales_target tábla, amiben a fordítások a korábbi lid azonosító mentén vannak összekapcsolva (így jelölve, mi a forrás-azonosító), nyelvkóddal meg vannak jelölve az egyes források (pl. "de", "hu", stb.), meg van még pár tájékozódást segítő mező. (Aztán biztos tud még egy pár dolgot, ami most nem jut eszembe.) Most Drupal 7-ről beszéltem, a 8-asban ezt még továbbcsiszolták.
Amit ti említettetek, abban nem látom sehol, hogy ezek a WPML plugin nélkül, ingyenesen hol lennének megvalósítva.
A fordítás egyébként mára már nagyjából mindenre kiterjed, a 8-asnál szinte a legapróbb részletekig lefordíthatóak az oldalelemek, sok CMS-nél korlátokba lehet ütközni ezen a téren.
Egyébként korábban láttam olvastam valami összehasonlító cikket, ahol azt hozták ki, hogy Drupalban a többnyelvűsítés amúgy is kiemelkedő a többi CMS-hez képest. Biztos van olyan dolog, amiben más CMS-t lehet kihozni győztesként, tehát ez nem flamewar, de szerintem tényleg nagyon el van találva a többnyelvűsítés Drupalban.
Ha pedig valaki nem szeretne költeni a honlapja tényleges, mindenre kiterjedő többnyelvűsítésére, akkor számomra legalábbis egyértelmű a választás.
Mondjuk én persze elfogult vagyok, még ha a Drupal forráskódját sem tartom túl szépnek, de sok esetben több lehetőséget látok benne, mint a többi PHP-alapú CMS-ben (igaz, WordPress-szel nincs konkrét tapasztalatom, inkább összehasonlító cikkekből indulok ki, hogy mi az, amit nem tud). Biztos, hogy van, akinek meg a WordPress áll jobban kézre, de én az ilyenek miatt például biztos, hogy nem használnám. Meg amiatt, mert a Drupalhoz tudok modult írni, a WordPress-hez viszont nem is akarnék.
(#5304) The DJ :
Ez még mindig fájlkezelős megoldás. Legalábbis én nem láttam, hogy említést tettek volna bármilyen adatbázis-használatról.Sk8erPeter
-
#5308
biker
nagyúr
Sk8erPeter
#5307
biker
nagyúr
válasz
Sk8erPeter
#5307
üzenetére
Sajnos annyira nem rágtam bele magam a magba, hogy megállapítsam, mikor hogyan használja fel a po filet, de ha _én_ írtam volna, mert én így csinálom, hogy ha valami többnyelvű, akkor ha egy külön fileban van, akkor megnyitom, beolvasom, pl egy tömbben van benne a magyarítás, és azt mint tömb, vagy változók tartalmazzák a szövegeket, így se adatbázis, se fileban keresgélés nem valósul meg
pl a saját többnyelvű webshopomban van egy $lang tömb, ebben vannak kulcs>érték párban a szövegek, és ami nyelvet választ ki a loginnél (kivéve default nyelv esetén) betölti a kért nyelvet, lesz egy 3-400 stringet tartalmazó tömb, és azzal dolgozok
Ez rossz megoldás?Elektromos autó töltő berendezések | Mesterséges növényvilágítás | Mai ajánlatunk: www.gerisoft.hu | www.e-autotoltokabel.hu | www.agrar-vilagitas.hu |
-
#5309
martonx
veterán
Sk8erPeter
#5307
martonx
veterán
válasz
Sk8erPeter
#5307
üzenetére
Szvsz, meg az adatbázis nem azért van, hogy fordítást tároljunk benne. Persze lehet, nem tiltja senki. Jellemzően pár száz, pár ezer kulcsokkal dolgoznak a fordítások. Ezek már miért ne lehetnének file-ban? Ne tegyünk úgy, mintha az adatbázis valami csoda lenne. Az is file-ban tárolódik ugyanúgy a lemezen
(kivétel a NoSQL, bár még X időnként az is szinkronizálja magát file-ba a háttérben).
Egy xml-en végigrohanni semmivel nem tart tovább, mint elindítani húszszor egymás után, hogy select ize from forditas where key = valami. A húsz-al arra céloztam, hogy mondjuk 20 elem fordítását kell lekérdezni az oldal rendereléséhez. Sőt lehet hogy, az xml nyerne.Én kérek elnézést!
-
cidalain
veterán
En is kulon nyelvi fajlban oldottam meg a keretrendszeremnel a forditast.
Tombos modszerrel.A legtobb anyag ugyis a tartalomkezelovel kerul feltoltesre, olyan nyelven ahogy eppen kell. A szerkezetben meg minimalis a nyelvaszukseglet, inkabb csak vezerlogombok, stb. Kevesebb mint 50 elem van, de lehet hogy meg 25 sincs. Ezt sokkal egyszerubb volt igy csinalni.
Masik projekt oldalnal mar kemenyebb dio, ott ugyanis pont a szerkezet a nehezebb nyelvi szempontbol, a vezerles, urlapok, egyedi beallitasi lehetosegek miatt. De ott is hasonloan csinaltam, bar mar 5 eve. Majd most lesz redesign, itt lehet hogy at fogom gondolni, es adatbazisba szervezni.
>> GearBest Club Veszprém << >> https://www.facebook.com/gbc.veszprem <<
-
#5311
Sk8erPeter
nagyúr
martonx
#5309
Sk8erPeter
nagyúr
válasz
martonx
#5309
üzenetére
"az adatbázis nem azért van, hogy fordítást tároljunk benne"
Bocs, de ez a vélemény szerintem ebben a formában teljesen értelmetlen. Mi az, hogy "nem azért van"? Miért ne lehetne "azért", amennyiben sokkal rugalmasabb fordítási és nyilvántartási módszereket biztosít az adott CMS (vagy keretrendszer, vagy teljesen mindegy, micsoda)? Ha épp arra van szükség, akkor adott esetben miért ne lehetne előnyösebb, mint fájlokat b@szogatni, minden egyes lekéréskor beolvasni, parse-olni, kikeresni a megfelelő elemet?
Fontos: mindkettő módszerre lehet találni érveket, de te lényegében leszögezted, hogy nem, csak az egyik módszer a helyes. Bocs, de most a válaszod inkább tűnt kötekedőnek és önigazolónak (hogy miért is jobb a WordPress, mint a Drupal, ha már azt választottad), mint előrevivőnek és érdeminek.
Korábban már leírtam, hogy a Drupalt a legapróbb részletekig le lehet fordítani, entitásszinten, field-szinten, blokkszinten, theme-szinten, modulszinten, mindennek nagyjából lehet tudni az első előfordulását is, vannak ezentúl fordítási csoportok is. Ha adatbázisban van tárolva, azért pár fokkal könnyebb karbantartani, és rugalmasabban kezelhető a dolog.
Másik: amikor az ÖSSZES fordításban keresgélek - amire van lehetőség Drupalban - akkor szerinted tényleg az lenne a legjobb, ha az adott esetben száz telepített modul (úgy, hogy egyes moduloknak lehetnek almoduljai, akár 10 almodulja is lehet, épp a modularitás jegyében, hogy azok kikapcsolhatóak legyenek), 3 smink, és a core fordítási fájlját is összekaparná, parse-olná, és kinyögné valahogy pár másodperc után a végeredményt, hogy melyik fájlban találom az adott stringrészletet? Azért azt hangsúlyozzuk: NEM egy XML-fájlról van szó, mint amiről te beszéltél. Ez amúgy nem is értem, honnan jött, hogy egy darab XML-ről beszéltél. Bár lehet, hogy a WordPress így oldja meg, bár én sehol nem láttam XML-t említve, feltételezném, WP-nél is pluginfüggő fordítások vannak; és amennyiben uninstallálsz egy plugint, akkor feltételezném, hogy annak a fordításai is mennek a kukába, hogy tök feleslegesen ne legyenek ott.
Amikor a fordítási felületre rámegyek, és több csoportosítási szempont szerint is láthatom a fordításokat - például hogy valamelyik elem a menühöz tartozik, valamelyik az entitásokhoz, meg a tököm tudja most a többit hirtelen fejből -, akkor mindegyik fájlból össze kéne kaparásznia a csoportosítási szempontoknak megfelelő adatokat? Ekkor is végig kellene rohannia a fájlokon (amiből ezek szerint lehet sokszáz - már ha össze nem pakolja egybe)? Oké, akkor erre most lehet jönni azzal, hogy hát a fájlokra is van mindenféle cache-elési módszer. Végül is azzal is lehet jönni, hogy de hát az adatbázis is fájlok formájában képzelendő el (ahogy sajnos az imént megtetted). De nem biztos, hogy ezek találó szempontok.
Lehet, hogy mérlegelni kellene, hogy a WordPress és a Drupal más jellegű CMS-ek. A Drupalban mindenféle menütípust, blokktípust, entitástípust, tartalomtípust, taxonómiát, és minden egyebet eleve létre lehet hozni, és mindezt le is lehet fordítani apró részletekig. Tudtommal ebből a szempontból a WordPress jóval kötöttebb. Lehet, hogy nem csak az az egyféle szempont létezik, amit mi a fejünkben egyszer elképzeltünk, lehet, hogy van más eset, mint amivel mi eddig találkoztunk."Ezek már miért ne lehetnének file-ban?"
És miért ne lehetnének adatbázisban?
Egy csomó szempontot fel lehet hozni mindkettőre. Továbbra is tök értelmetlen az egyiket egyértelmű győztesként kihozni. De mivel úgy tűnik, Drupal esetén az adatbázisszintű tárolás a jóval praktikusabb, ezért talán el lehetne fogadni, hogy lehet benne valami ráció, és hogy indokolt volt, hogy így találták ki, és nem szükséges az előfeltételezés, hogy biztos kretének dolgoztak a rendszer kitalálásán, akik nem értenek hozzá.
Amúgy gondolom nem csak hype-olásból hangsúlyozzák, hogy a CMS-ek között a Drupal többnyelvűsítési mechanizmusa nagyon rugalmas.
Persze biztos azt is csak hülye elfogult f@szok mondják."Egy xml-en végigrohanni semmivel nem tart tovább, mint elindítani húszszor egymás után, hogy select ize from forditas where key = valami. A húsz-al arra céloztam, hogy mondjuk 20 elem fordítását kell lekérdezni az oldal rendereléséhez. Sőt lehet hogy, az xml nyerne."
Adatbázisszintű cache is létezik. Durva, nem? Akár ha olyan van, ezt is le lehet kérni egyben is. Query cache is van, meg hasonlók."Ne tegyünk úgy, mintha az adatbázis valami csoda lenne. Az is file-ban tárolódik ugyanúgy a lemezen
"
Te most tényleg ekkora idiótának nézel, hogy úgy érezted, ezt ki kell hangsúlyozni? Azért reménykedtem, hogy ennél többre tartasz. Ez rosszabb, mintha simán csak lehülyéztél volna, de köszönöm, hogy elláttál ezzel a teljesen újszerű információval.
Bár egyébként sem értem, ez az érv hogyan lehet jelen esetben releváns, amikor teljesen máshogy működik egy adatbázis (még ha fájlok formájában is jelenik meg a háttértárolón (ami nem biztos, hogy lemez![;]](//cdn.rios.hu/dl/s/v1.gif)
)), mint a fájlnyitogatás, parse-olás. De mint említettem, van olyan is, hogy a fájlos módszer tűnik praktikusabbnak. Nem változtat semmit azon, hogy adott esetben meg az adatbázisszintű megoldás lehet az előnyösebb. Mint jelen esetben.
Igaz, én is elkövettem azt a hibát, hogy két, teljesen más felépítésű CMS megoldását vetettem össze.
De legalább senkit nem néztem hülyének.Sk8erPeter
-
#5312
Sk8erPeter
nagyúr
biker
#5308
Sk8erPeter
nagyúr
Korábban hibásan én is kihoztam győztesnek valamelyik módszert, de igazából ez totál értelmetlen. Mindegyik szempontra lehet találni érveket. Egy száz telepített modulból, 3 telepített sminkből, és magából a core-ból, tetszőlegesen létrehozott tartalomtípusokból, entitásokból, hozzá tartozó tetszőlegesen létrehozott fieldekből, cikkekből, külön aloldalakból, hierarchikus, tetszőleges számú menüből, és ki tudja, még hány dologból álló CMS összes apró-cseprő elemének lefordítása elég brutális feladat lehet, egy adott oldal megjelenítésekor rengeteg fordítandó összetevő jelenhet meg. Mivel a Drupal esetén mindent apró részletekig lehet fordítani, azokat csoportosítani, különböző szempontok szerint lekérni, és mivel erre is megvannak a cache-elési módszerek, és az update-elési módszerek is elég kényelmesek és összetettek, úgy gondolom, hogy helytálló jelen esetben az adatbázis alkalmazása.
Más esetben még a tömbös módszer is helytálló lehet, amit írtál. Meg a fájlos módszer is. Lehet, hogy a fájlos módszer nem ró nagy overheadet a WordPress-re, és ezt rosszul írtam korábban, fogalmam sincs, ott milyen részletekbe menően lehet fordítgatni, csoportosítani a dolgokat, tudtommal ebből a szempontból jóval kötöttebb; lehet, hogy nem kell többszáz fájlt összekaparnia. De ezt ti majd megmondjátok.
Most is igaz az, hogy nincsen ultimate módszer, még ha most a végén azt is sikerült kihozni az egészből, hogy biztos én vagyok a hülye, hogy jelen esetben az adatbázisos módszert sokkal célravezetőbbnek és kezelhetőbbnek, meg könnyebben karbantarthatónak (update-elhetőnek) találom. Nekem sem kellett volna kritizálnom a fájlos módszert, mert nyilván más esetben az is tökéletesen megfelelő, főleg, hogy sokan meg ezt alkalmazzák.[ Szerkesztve ]
Sk8erPeter
-
#5313
biker
nagyúr
Sk8erPeter
#5312
biker
nagyúr
válasz
Sk8erPeter
#5312
üzenetére
Lehet, hogy a fájlos módszer nem ró nagy overheadet a WordPress-re, és ezt rosszul írtam korábban, fogalmam sincs, ott milyen részletekbe menően lehet fordítgatni, csoportosítani a dolgokat, tudtommal ebből a szempontból jóval kötöttebb; lehet, hogy nem kell többszáz fájlt összekaparnia.
BIZTOS hogy nem kell, mivel maximum kettő filet kell, a default .po filet, és az adott theme .po fileját.
Ennél akkor kell többet, ha sok plugint használsz, amit úgy írtak meg, hogy a gyári fordítás nehogy jó legyen, és mindhez van saját, na akkor 20 plugin 20.po file
bár azokhoz rendre magyar támogatás úgysincs
engem amúgy nem izgat, melyikkel lehet 0,001mp-et nyerni, akkor kezd izgatni, ha valamiért 10mp alatt töltődik be a woocommerce 15.000 termékkel, miközben egy mezei shop 150.000 termékkel 1,5mp alatt
de ott nem a nyelvvel van hiba úgysemElektromos autó töltő berendezések | Mesterséges növényvilágítás | Mai ajánlatunk: www.gerisoft.hu | www.e-autotoltokabel.hu | www.agrar-vilagitas.hu |
-
#5314
Sk8erPeter
nagyúr
biker
#5313
Sk8erPeter
nagyúr
"BIZTOS hogy nem kell, mivel maximum kettő filet kell, a default .po filet, és az adott theme .po fileját.
Ennél akkor kell többet, ha sok plugint használsz, amit úgy írtak meg, hogy a gyári fordítás nehogy jó legyen, és mindhez van saját, na akkor 20 plugin 20.po file"
Ezt a szempontot nem értettem, hogy "a gyári fordítás nehogy jó legyen". Miért, egy pluginben csak olyan fordítandó szövegek fordulhatnak elő, amik a gyári fordításban is benne vannak? Azért az érdekes lenne, ha minden fordítást lefedne a gyári fordítás, ezt senki nem várhatja el.
Tehát akkor magyarul ahogy írtad is, ha 20-féle összetettebb plugined van, akkor 20 .po-fájlból kell összekaparnia a fordításokat, pontosan erről beszéltem az előző hsz.-emben, ezek szerint nem tévedtem.Sk8erPeter
-
#5315
biker
nagyúr
Sk8erPeter
#5314
biker
nagyúr
válasz
Sk8erPeter
#5314
üzenetére
Nem, par pelda:
Next helyett following
Add to cart helyett put to basket, proceed to checkout helyett megint mas stb
Emiatt se a gyari wp hu nyelv , se woocommerce magyar modul nem volt joElektromos autó töltő berendezések | Mesterséges növényvilágítás | Mai ajánlatunk: www.gerisoft.hu | www.e-autotoltokabel.hu | www.agrar-vilagitas.hu |
-
#5316
martonx
veterán
Sk8erPeter
#5311
martonx
veterán
válasz
Sk8erPeter
#5311
üzenetére
Bocsánat, szokásomhoz híven nem CMS-ben gondolkoztam, amikor írtam a felvetésemet, amivel igaziból csak arra akartam reflektálni, hogy abszolút nem lehet olyan magabiztossággal kijelenteni az adatbázisban tárolt fordításról, hogy az a jó megoldás, mint ahogy tetted. Lehülyézni végképp nem állt szándékomban, bocsánat.
És az én nézőpontomból nézve, valóban nincs semmi értelme db-ben tárolni a frodításokat, persze miért ne lehetne, csak értelmetlen, hiszen a benne tárolt relációs adatokhoz semmi módon nem kapcsolódnak, semmi pluszt nem ad a a db-ben tárolás a fileban tároláshoz képest.
Ugyanakkor a te CMS-es nézpontodból, ahol a UI összeállításához szükséges minden egyéb információ is db-ben tárolódik, és minden hiperdinamikusan állítható, össze-vissza paraméterezhető, ott valóban ez lehet a jobb megoldás, és ekkor lehet, hogy még relációban is állnak más egyéb adatokkal.
Ráadásul úgy érzem kölcsönösen félreértettük egymást. Egyrészt ezek szerint te sem gondoltad az egyetlen üdvözítő útnak a db-ben tárolt fordítás megoldását, én sem gondoltam egyetlen üdvozítő útnak a file-ban tárolást. Akkor már említsük meg a harmadik megoldást is, amikor teljesen külön lokalizáció függő templateket, html-eket használ valaki, amit rohadt macerás ugyan karban tartani (pláne minél több nyelvet kell támogatni), de teljesítményben mindkét fenti megoldásnál jobb.
"Másik: amikor az ÖSSZES fordításban keresgélek - amire van lehetőség Drupalban - akkor szerinted tényleg az lenne a legjobb, ha az adott esetben száz telepített modul (úgy, hogy egyes moduloknak lehetnek almoduljai, akár 10 almodulja is lehet, épp a modularitás jegyében, hogy azok kikapcsolhatóak legyenek), 3 smink, és a core fordítási fájlját is összekaparná, parse-olná, és kinyögné valahogy pár másodperc után a végeredményt, hogy melyik fájlban találom az adott stringrészletet?"
Nyelvenként egy po file-t lehet nyitva tartani a jobb po editorokban, és keresni bennük a pillanatok műve.Szerintem elég jól körüljártuk a témát, és bocsánat ha túl lekezelő lettem volna, nem volt szándékomban megbántani.
Én kérek elnézést!
-
#5317
Sk8erPeter
nagyúr
martonx
#5316
Sk8erPeter
nagyúr
válasz
martonx
#5316
üzenetére
Semmi gond, valószínűleg én értettem félre a szándékot, vagy reagáltam túl.
Ilyenkor szedni kell két adagnyi hangyát, és az ember megnyugszik."nem CMS-ben gondolkoztam, amikor írtam a felvetésemet, amivel igaziból csak arra akartam reflektálni, hogy abszolút nem lehet olyan magabiztossággal kijelenteni az adatbázisban tárolt fordításról, hogy az a jó megoldás, mint ahogy tetted"
Ebben teljesen igazad van, bocs, tényleg erőltettem egy darabig, hogy az adatbázis a mindenekfeletti megoldás, pedig ebben a formában nem igaz, később rájöttem. Rugalmasabbá teszi persze a karbantartást, több információ kapcsolható így a fordításokhoz (ahogy végül is Te is írtad)."Nyelvenként egy po file-t lehet nyitva tartani a jobb po editorokban, és keresni bennük a pillanatok műve."
Egy fájl esetében tényleg semmi gondot nem jelent. Mármint maga a keresés. A karbantartása már más kérdés (szerintem), de ezt mindjárt.
Tehát a fájlos megoldást sem szabad leszólni, én igazából csak azt nem láttam be, és még továbbra is kérdőjel maradt a fejemben, hogy valójában miért is ne lehetne arra is használni az adatbázist, hogy fordításokat tároljunk benne (amire utaltál), miért nagyobb gond az, ha adatbázisból kérjük le a fordításokat, akár egyben, még ha nem is kell hozzácsatolni valami plusz információkat (lásd Drupal, összetettebb információhalmaz), valami összepakolt cache-ből, mintha egyetlen nagydarab fájlból.
Bár az egyetlen nagydarab fájlnak a modularitás továbbra is ellentmond (és végül is modul nem csak CMS-ben lehet), hiszen az elvileg azt kívánná meg, hogy akár modulonkénti külön fájlokból álljon össze egy fordítás; igaz, ezt is meg lehet kerülni úgy, hogy "aggregáljuk" a fordításokat egyetlen nagy fájlba, a modul telepítésekor egyszerűen hozzáfűzzük annak a fordításait. Csak kérdés - és többek közt itt jön elő a karbantartási probléma -, akkor az egyik modul törlésekor mi legyen. Keressük meg a megfelelő részeket, és azokat töröljük ki a fájlból, mert a törölt modul fordításai már feleslegessé váltak? Elvileg így lenne helyes, de akkor ez a karbantartást picit megint nehézkesebbé teszi - könnyebbnek tűnik legalábbis adatbázisból megkeresni adott kulcs mentén adott modulhoz tartozó fordításokat, majd azokat kidobni, mint egy nagy .po-fájlon végigrohangászni, és tudni, hol van a modulok fordításának eleje, majd vége. Kérdés, hogyan tartjuk nyilván, hogy a modul fordításai hol kezdődnek? Vagy akkor modul törlésekor gyártsuk le ismét az összepakolt fordítási fájlt? Na de az nem jó, mert azóta a nagy fájlban végezhettünk módosításokat. Szóval marad az előbbi, hogy meg kell keresni az elejét, meg a végét. Persze lehet, hogy ez a ritkább eset, amivel nem kell annyira foglalkozni, de modularitás esetén engem zavarna, hogy nem szükséges fordítások is szükségtelenül növelik a fájlméretet. Meg biztos van még valami szempont, de most csak ez jutott hirtelen eszembe.Engem legalábbis érdekel a téma, jó néha véleményeket ütköztetni, szóval még körbe tudjuk járni másképpen is.
[ Szerkesztve ]
Sk8erPeter
-
#5318
martonx
veterán
Sk8erPeter
#5317
martonx
veterán
válasz
Sk8erPeter
#5317
üzenetére
Én kettő konkrét példát tudok mondani. Az egyik az általában mostanában használt Orchard CMS. Itt is adatbázisban van tárolva a fordítás. Miközben ez egy ASP.NET MVC-re épülő CMS. Ez mindjárt fontos lesz.
Admin felületről lehet fordítgatni benne a cuccokat, egész korrektül megcsinálták. CMS-hez talán tényleg ez a megoldás a legjobb, mivel amúgy is minden content az utolsó betűig az adatbázisban van. Ha már úgyis adatbázis kell a legkisebb hello world-höz is, akkor kézenfekvő, hogy egyúttal onnan rögtön a nyelvnek megfelelő szöveget vegye ki a rendszer.A másik az általam napi szinten használt ASP.NET MVC keretrendszer (illetve a többiek is saját megoldásokat hoztak, az igaziból mindegy, hogy PHP vagy ASP.Net vonalról beszélünk). Itt pedig .resx fileokban vannak tárolva a fordítások (ugyanaz, mint a .po fileok). Minden file egy nyelvet jelent, Visual Studioból, vagy Resx editorból szerkeszthetőek. Egyszerre több file-t párhuzamosan kezel az editor, nagyon kényelmes használni, jelzi a hiányzó fordításokat, bármilyen nyelven is legyenek azok, és gyors is. Képzeld el, hogy Notepad++-ban megnyitsz mondjuk 3 db egyenként 1Mb-os file-t és általános szöveg keresést csinálsz bennük. Mennyi idő alatt van meg a keresés első eredménye, bármelyik file-ban is legyen a keresendő szó? Gyakorlatilag rögtön, még ha ez nyilván ms nagyságrendő is a valóságban. Bevallom annyira sosem mentem a dolgok mélyére, hogy a gyakorlatban elemezgessem, hogy az ASP.NET MVC aztán hogy szedi ki ezekből az xml fileokból a fordításokat, de hogy pillanatok alatt megvan azt látom, mérem. Szvsz teljesen normális 1-1 pár száz kb-os, folyamatosan használatban lévő file tartalmát memóriában tartani, de szerintem azokat megnyitogatni és realtime olvasni is minimális idő. Anno, amikor pénzügyi vonalon dolgoztam és XML feldolgozó programokat is kellett csinálnom, én is meglepődtem azon, hogy milyen iszonyatosan gyors tud lenni a bennük való keresés.
De vegyük tovább. A nem CMS-ek, template fileokkal dolgoznak, és ezeknél nem azt írod a template-be, hogy <h1>Hello world</h1>, hanem <h1>helloworldfordításkulcs<h1>. Aztán majd a motor a template feldolgozásakor, a html kimenet legenerálásakor egyúttal kiszedi hozzá a szükséges fordítást is, miért is kellene ehhez adatbázis? És hidd el, ez így jóval gyorsabb, mint db-hez fordulni mindenféle protokollon keresztül (arról nem is beszélve, hogy a db külön gépen is szokott lenni), aztán megkérni, hogy adja már ide a helloworldfordítás kulcshoz tartozó értéket, pláne ha egy oldal kigenerálásakor kell vagy 20-50 ilyen lekérdezés. Persze ennél a megoldásnál is előjön pluszban adatbázisban fordítás tárolás is, ha mondjuk webáruházról beszélünk, és a termék megnevezés, szöveges adatai több nyelven is meg kell, hogy legyenek, de ez nyilvánvalóan relációs adat.És ahogy mondtam van a harmadik megoldás, amikor van egy helloworld.html-ed, meg egy sziavilag.html-ed, és a komplett cuccot az adott nyelven írod meg. Nyilván ez a leggyorsabb teljesítmény szempontjából, mert se db-hez, se .po file-hoz nem kell fordulnia a rendszernek. De amikor rájössz, hogy egy többször előforduló szöveget át akarsz írni bennük, és mondjuk 5 nyelvet kezel a rendszer és van 30 fileod, akkor ez nem kevés szívást jelenthet.
Leírok még két szempontot, az adatbázis nem erre való érvemre. A komolyabb alkalmazásoknál rendre az adatbázis a szűk keresztmetszet. Általában annak is örülünk, ha a rengeteg adatot kezelni tudja, nem hogy még azzal is terheljük, hogy ja de a helloworldfordítás értékét is add már ide, mert a címhez be kellene illesztenem.
Másrészt vegyük észre, hogy a hoszting cégeknél a sima lemez kapacitás jellemzően több, mint az SQL tárhely. Sőt felhőben hosztingolva pl. a lemez kapacitás szó szerint szinte ingyen van, míg az SQL-es adattárolásnál azért zsebbe kell nyúlni.Én kérek elnézést!
-
Orionk
senior tag
Sziasztok !
Egy kis segítséget szeretnék kérni szépen.
Hogyan lehet a legegyszerűbben megvalósítani azt, ami a nyitóoldalon van, hogy a Csajnak a fotója és aláírása, azaz a KÉP elhalványul és a következő kép, ami feljön pedig felerősödik.
Tehát egy időben történik az áttünés az egyik fotóból a másikba.
Én egy ilyesmit próbáltam összehozni, de az a baj vele, hogy a két kép áttünése nem egyszerre történik. Először elhalványul az egyik és utána erősödik fel a következő :
<script type="text/javascript">
var images = new Array();
images[0] = "IMG1.JPG";
images[1] = "IMG2.JPG";
images[2] = "IMG3.JPG";
setInterval("changeImage()", 3000);
var x=0;
function changeImage()
{
x++;
if (x == 3) x = 0;
var img = document.getElementById("start");
fade(img);
img.src="pics/"+images[x];
}
function fade(img){ alert(img);
if (img.style.opacity > 0){
img.style.opacity = img.style.opacity-10;
setTimeout(function(){fadeImg(img);}, 10);
}
}
</script>köszi szépen
-
cidalain
veterán
Nem szarakodnék magam ennek megírásával.
Vennék valami kész Javascript slidert, pl:E kettő pont jquery-s, de más js kerethez is van persze ilyen.
Általában könnyen, 1000 féleképpen paraméterezhetők, és nem feltétlenül csak áttűnéssel megy (lapozás, csúsztatás, mozaik, stb - másodiknál sok példa van online az oldalon, ki is próbálható).De én az elsőt ajánlom, a Light-demo pont azt csinálja ami neked kell a leírásod alapján.
[ Szerkesztve ]
>> GearBest Club Veszprém << >> https://www.facebook.com/gbc.veszprem <<
-
-
cidalain
veterán
igen, be kell oda tenni a jquery-t
be kell tenni még a slidernek a scriptjét
meg lehet hogy kell egy kis inicializáló scriptet is írni.A doksiba le lesz írva minden, de ha mást nem akkor puskázol a demo oldalról
Ez a lényeg: (persze az elérési utakat a saját kialakításod szerint kell javítani)
<script type="text/javascript" src="http://www.simplefadeslideshow.com/wp-content/themes/simplefadeslideshow_com/js/jquery.js"></script>
<script type="text/javascript" src="http://www.simplefadeslideshow.com/wp-content/themes/simplefadeslideshow_com/js/fadeSlideShow.js"></script>
<script type="text/javascript">
$(document).ready(function(){
$('#slideshow').fadeSlideShow({
PlayPauseElement: false,
NextElement: false,
PrevElement: false,
ListElement: false
});
});
</script>
.......
<div id="slideshowWrapper">
<ul id="slideshow">
<li><img src="http://www.simplefadeslideshow.com/wp-content/themes/simplefadeslideshow_com/images/4.jpg" width="640" height="480" border="0" alt="" /></li> <!-- This is the last image in the slideshow -->
<li><img src="http://www.simplefadeslideshow.com/wp-content/themes/simplefadeslideshow_com/images/3.jpg" width="640" height="480" border="0" alt="" /></li>
<li><img src="http://www.simplefadeslideshow.com/wp-content/themes/simplefadeslideshow_com/images/2.jpg" width="640" height="480" border="0" alt="" /></li>
<li><img src="http://www.simplefadeslideshow.com/wp-content/themes/simplefadeslideshow_com/images/1.jpg" width="640" height="480" border="0" alt="" /></li> <!-- This is the first image in the slideshow -->
</ul><br clear="all" />
</div>[ Szerkesztve ]
>> GearBest Club Veszprém << >> https://www.facebook.com/gbc.veszprem <<
-
Orionk
senior tag
válasz
cidalain
#5322
üzenetére
Értem. Próbálkozom, ha nem menne, akkor jelentkezem.
Alap esetben miben különbözik, a Jquery a Javascript-től ?
Valamint szintén visszatérve a http://www.fittalak.hu/ oldalra.
Kicsit lentebb, a áttünő effekt alatt két nagy kör van, amiben a csajnak 1-1 fotója. Mindkét nagy kör egy link. Viszont, amikor fölé viszed az egeret, akkor a kör széle kicsit színt vált. Világosabb és sötétebb rózsaszín.
Ezt hogyan csinálták meg ?, hogy amikor fölé megy az egér, akkor színt vált ?
köszi
-
DNReNTi
őstag
"Alap esetben miben különbözik, a Jquery a Javascript-től ?"
Minden jQuery javascript, de nem minden javascript jQuery.Magyarról magyarra: a jQuery egy fasza kis javascript függvénytár. A javascript meg egy objektumalapú szkriptnyelv.
but without you, my life is incomplete, my days are absolutely gray
-
cidalain
veterán
Simán 2 db kép van ott. Két négyzet alakú png kép, körön kívül átlátszó háttérrel.
a:hover-nél meg valószínűleg képcsere van egy ugyanolyanra, aminek más a kör kerületének színe.
Ezt is valami jquery script-tel oldották meg, de nem hiszem hogy ez feltétlenül szükséges, css-sel szerintem megoldható.>> GearBest Club Veszprém << >> https://www.facebook.com/gbc.veszprem <<
-
Orionk
senior tag
válasz
cidalain
#5325
üzenetére
Köszi.
Azt hogyan csinálhatták meg, hogy kitették a fő oldalra, ezt a hosszú képet, ami folyamatosan változik áttünéssel, hogy ez a kép a monitor bal szélétől egészen a jobb széléig tart.
Én, amikor kitettem egy fotót a saját próba weboldalamon, akkor ott a lentebbi JavaScript megoldásommal amikor váltogattam a képeket, akkor a képek nem a bal széltől jobb szélig mentek, hanem balról és jobbról is kb. 5mm-rel hamarabb vége lett a képnek, minthogy egészen a széléig elérjen.
köszi
-
cidalain
veterán
hát ez attól függ, hogy milyen az oldalszerkezeted.
elsőkörben a <body> marginja és paddingja legyen mindegyik oldalon 0px.
második körben az összes konténered marginja és paddingja legyen 0px.
harmadik körben a slideshowWrapper marginja és paddingja is legyen 0px.ha ez megvan, akkor nem lehet hézag egyik oldalon sem.
ennél többet látatlanban nem tusok segíteni
[ Szerkesztve ]
>> GearBest Club Veszprém << >> https://www.facebook.com/gbc.veszprem <<
-
Rhino666
őstag
Üdv!
Villámkérdés, nem találtam megoldást neten.
<form method="POST" action="ide.php" onsubmit="return prompt('Name?', '')">
<input type="submit" />
</form>Hogyan tudok hivatkozni a prompt mezőbe gépelt névre az ide.php-n??
Köszönettel:
Rhino666Rich enough to buy an iPhone, smart enough to not buy one.
-
Rhino666
őstag
válasz
cidalain
#5329
üzenetére
Az onsubmit-nál javascript prompt-tal elkérek egy értéket, ezt szeretném felhasználni a következő oldalon, ahová a post visz. Eddig csak confirm() függvényt használtam, az működik rendesen - ha OK-t nyomok, post-ol, ha Cancel-t, nem.
[ Szerkesztve ]
Rich enough to buy an iPhone, smart enough to not buy one.
-
cidalain
veterán
válasz
Rhino666
#5330
üzenetére
Olyat nem lehet hogy egy kulon fv-t irsz az onsubmitra, es a prompt utan meg az erteket beteszed a formba egy hidden text mezobe. Es ekkor er veget az onsubmit fuggvenye, es ekkor iranyitodik at a php-ra. Es a hidden mezobe meg ott az ertek.
>> GearBest Club Veszprém << >> https://www.facebook.com/gbc.veszprem <<
-
Orionk
senior tag
Sziasztok !
Egy kis segítséget kérnék szépen. Vagyis inkább nagy segítséget.
Itt van a jelenlegi kódom : https://db.tt/QNC29VfO
Egy video Slidert akarok csinálni, ahol időközönként beúszik a következő YouTube videó. Kerestem a neten egy már megírt ilyen Slidert és ezt találtam : AnyThing Slider egyik verziója.
Ezt a Slidert letöltöttem és egész délután tanulgattam, nézegettem, hogy rájöjjek, hogy a kódomba belehelyezve a szükséges dolgokat pont úgy működjön, ahogyan a 2 sorral fentebbi Anyithing Slider bemutatója.
Végül már mindent sikerült összehozni, csak egy dolgot nem. A YouTube videó FullScreen ben jelenik meg és nem tudom lekicsinyíteni. Le szeretném kicsinyíteni, hogy akkora legyen, amekkorát akarok és ott legyen az oldalon, ahol én akarom.
Szóval erre az 1 dologra nem jöttem rá egész délután, hogy miért mindig FullScreen ben jelenik meg ? hogyan lehetne lekicsinyíteni ?
Légyszives nézzetek bele a fenti 3ik sorban a jelenlegi kódomra, hogy mi lehet szerintetek a gond, hogy ilyen nagy a videó ? köszi szépen A mappába benne van minden CSS, JavaScriptek, index.html, minden...Sokmindent nem én csináltam a kódban, pl. JavaScript fájlok.
köszi szépen.üdv.,
[ Szerkesztve ]
-
The DJ
addikt
// Set up Sliders
// **************
$(function(){
$('#slider1')
.anythingSlider({
theme : 'metallic',
easing : 'easeInOutBack',
resizeContents : true,
autoPlay : true,
})resizeContents : true
Kezdetnek írd át a true-t false-ra és máris nem lesz teljes képernyős a youtube videó.
https://wpszaki.hu - Minden, ami WordPress, cikkek kezdőknek és haladóknak.
-
cidalain
veterán
Tudtok valami egyszeru fajlbongeszorol, amit az ckeditorhoz hozza tudok kapcsolni, es a tarhelyen lehet a fajlok kozott nezelodni, a kepbeszurashoz? A gyari json megoldas megfelelne, ha lehetne vele mappat valtani. Ingyenes kellene.
Ha a kepfajl feltoltest is tudja, akkor kulon orom, de ez nem feltetel.>> GearBest Club Veszprém << >> https://www.facebook.com/gbc.veszprem <<
-
cidalain
veterán
Köszi!
Ezek funkciója már túl sok. Az ügyfelet nem akarom fárasztani a jogosultságokkal meg miegymás.CKFinder-t néztem tegnap, de az pénzes.
Viszont van egy KCFinder nevű alternatívája ami ingyenes, opensource.
Csak annyit tud amit feltétlenül szükséges. Mappaváltás, létrehozás, fájlfeltöltés, fájlkiválasztás.
Könnyű az integráció (CKEditor, FCKEditor, TinyMCE)[ Szerkesztve ]
>> GearBest Club Veszprém << >> https://www.facebook.com/gbc.veszprem <<
-
#5340
Sk8erPeter
nagyúr
cidalain
#5339
Sk8erPeter
nagyúr
válasz
cidalain
#5339
üzenetére
Még esetleg ezt megnézhetnéd:
elFinder
http://elfinder.org/Sk8erPeter
-
#5341
Sk8erPeter
nagyúr
martonx
#5318
Sk8erPeter
nagyúr
válasz
martonx
#5318
üzenetére
"Admin felületről lehet fordítgatni benne a cuccokat, egész korrektül megcsinálták. CMS-hez talán tényleg ez a megoldás a legjobb, mivel amúgy is minden content az utolsó betűig az adatbázisban van. Ha már úgyis adatbázis kell a legkisebb hello world-höz is, akkor kézenfekvő, hogy egyúttal onnan rögtön a nyelvnek megfelelő szöveget vegye ki a rendszer."
Igen, én is pont így gondoltam korábban, ami CMS esetén ellentmond annak az érvnek, hogy az adatbázis ne lenne erre való.
Ha épp az kell, akkor arra való."Szvsz teljesen normális 1-1 pár száz kb-os, folyamatosan használatban lévő file tartalmát memóriában tartani, de szerintem azokat megnyitogatni és realtime olvasni is minimális idő."
Na ja, ez lehet, korábban arra utaltam, hogy amennyiben a modularitást vesszük elő (lásd CMS), akkor esélyes, hogy nem csak egy fájlban lesznek tárolva a fordítások. Vagy ha igen, akkor feláldozzuk a modularitást. Viszont ha már nagyon sok fájlt kell megnyitva tartani (pl. 100 modul), és sok fájlt is kell update-elni, megnyitogatni az oldallekéréskor minden apró elemhez, akkor már nem járunk jól, és akkor már a fájlbeli kotrás teljesítménye nem olyan meggyőző. Igaz, cache-szerűség érdekében le lehet akár generálni egy fájlba is különböző feltételektől függően, vagy adatbázisban, cache-táblában tárolni valami bejegyzés alatt a megfelelő fordításokat. Nem tudom, itt melyik megoldás nyer sebességben/erőforrás-igényben/más tekintetben, de mindkettő megoldás mellett szólhatnak érvek.Egyébként a fájlkezelés oprendszer-szinten költséges művelet, erre akartam célozni, persze abban igazad van, hogy talán nem mérhető össze az adatbázishoz kapcsolódás, lekérés költségével, főleg, ha az adatbázis másik szerveren van...
"Másrészt vegyük észre, hogy a hoszting cégeknél a sima lemez kapacitás jellemzően több, mint az SQL tárhely. Sőt felhőben hosztingolva pl. a lemez kapacitás szó szerint szinte ingyen van, míg az SQL-es adattárolásnál azért zsebbe kell nyúlni."
Ez mondjuk jó szempont.
Bár itt fordításokról beszélünk, nem brutális adatmennyiségekről, igaz, ha a fordítások különböző relációban állnak egymással, és az fontos, akkor nőhet a mennyiség szép lassan, de akkor meg úgyis az adatbázis a jobb megoldás elvileg.Na de tényleg összegezhetjük annyiban, hogy mindig attól függ, mit használunk, egyik megoldás sem nevezhető szarnak.
Most már tényleg jól körbejártuk a témát.Sk8erPeter
-
#5342
cidalain
veterán
Sk8erPeter
#5340
cidalain
veterán
válasz
Sk8erPeter
#5340
üzenetére
Ez jó, tetszik, köszi
El is teszem talonba, mert ha teljes értékű fájlkereső kell akkor ez jobbnak néz ki (látom van szerkesztés, kép átméretezés, vágás gomb is, ami simán jól jöhet. no meg tud csomagolni is.)De a mostani projekthez bőven elég lett az amit előbb linkeltem.
>> GearBest Club Veszprém << >> https://www.facebook.com/gbc.veszprem <<
-
Orionk
senior tag
Sziasztok !
Tudnátok ajánlani egy Slidert, ami tud kezelni YouTube és Vimeo videókat ?
Én ezzel próbálkoztam : Flex Slider , de nem sikerül betenni IFRAME-et, amivel beágyaznánk a képek közé videót is. Vagy szerintetek hogyan lehet ezzel kompatibilissá tenni a YouTube videókat ?
Úgy tudom, hogy YouTube videót csak IFRAME-el lehet beágyazni.
köszi
üdv., -
#5345
Orionk
senior tag
Sk8erPeter
#5344
Orionk
senior tag
válasz
Sk8erPeter
#5344
üzenetére
Szia !
köszi
Ez a kódom : https://db.tt/qbouNjS4
Nem mindent én írtam. A FlexSlider honlapjáról van, innen : FlexSlider
A JAvaScript és Css fájlokat is ők csinálták.
Tehát az probléma, hogy YouTube és Vimeo videókat szeretnék berakni a képek közé, de nem sikerül. IFRAME-re és EMBED re sem reagál.
Utána az lenne a gond, hogy szeretném lekicsinyíteni ez a Slidert, hogy például 480px és 385px legyen, valamint a képernyőn tudjam mozgatni, hogy hol jelenjen meg. Én a bal oldalon szeretném.
köszi
-
cidalain
veterán
Pedig az altalad linkelt oldalon ott a pelda a yt video beagyazasra. A htmlben az img tag helyett az iframe van a videoval. Figyelni kell hogy a meghivaskor benn legyen a player javascript kodja is. Fontos hogy az iframe-be be kell tenni a player id-t, nem eleg csak bemasolni az iframe-t a yt-rol!
>> GearBest Club Veszprém << >> https://www.facebook.com/gbc.veszprem <<
-
Orionk
senior tag
válasz
cidalain
#5346
üzenetére
Szia !
Igen, ott van az oldalon, de ott Vimeo videó van beágyazva.
De az így van beágyazva : <li><a href="video-wistia.html">Video & the api (wistia)</a></li>Youtube videót meg csak IFRAME-el lehet levenni a Youtube oldalról. Ott van a videók alatt egy embed menüpont és azzal lehet onnan levenni, a Youtube oldalról.
Viszont ez a lejátszó meg IFRAME-et nem ismer fel, báris nekem nem ismerte fel.
Ha van időd, akkor légyisz próbáld ki. Itt a jelen állás szerinti kódom : https://db.tt/qbouNjS4
-------------
A JavaScript kódokat beletettem. Mármint megfigyeltem, hogy a linkelt oldalról letöltött Slider-es html oldal forrását megnyitottam szerkesztőben és megpróbáltam megfigyelni, hogy melyiket használhatja a Slider. Azokat beletettem a sajátomba is.köszi
-
Orionk
senior tag
Hello ismét !
Megoldódott a lenti probléma.
Most ez a kódom : https://db.tt/fBk07Bo4 , és az a baj, hogy túl nagy a Slider.
Ha van időtök, akkor légyszi töltsétek le, a fenti kódom és ha elindítjátok, akkor látszik, hogy még a YouTube videó is elveszik a Sliderban, mert az olyan széles, pedig beállítom, hogy a Sliderben levő képek is kisebbek legyenek.köszi, ha megnézitek.
-
cidalain
veterán
Én a főoldalon a kódban a vimeo videót is Iframe-ben látom még mindig
<li>
<iframe id="player_1" src="http://player.vimeo.com/video/39683393?api=1&player_id=player_1" width="500" height="281" frameborder="0" webkitAllowFullScreen mozallowfullscreen allowFullScreen></iframe>
</li>Ugyanígy kell a YT videót is gondolom.
>> GearBest Club Veszprém << >> https://www.facebook.com/gbc.veszprem <<
-
cidalain
veterán
Rakd egy konténerbe a slider section-t
<div class="slider_container" style="width:480px; height:385px;">
<section class="slider">
..............
</section>
</div>Jó lenne ha a stílusformázását inkább majd a css-be áttennéd
akkora legyen a kontérner, mint a benne lévő cuccok.
[ Szerkesztve ]
>> GearBest Club Veszprém << >> https://www.facebook.com/gbc.veszprem <<
na az a genyóság, igen
(kivétel a NoSQL, bár még X időnként az is szinkronizálja magát file-ba a háttérben).
![;]](http://cdn.rios.hu/dl/s/v1.gif)
)), mint a fájlnyitogatás, parse-olás. De mint említettem, van olyan is, hogy a fájlos módszer tűnik praktikusabbnak. Nem változtat semmit azon, hogy adott esetben meg az adatbázisszintű megoldás lehet az előnyösebb. Mint jelen esetben.
