Üdv! Egy olyan modult keresnék, amivel többnyelvűsíteni lehetne az oldalamat. Erre persze számos modul létezik, többek között az i18n, de nekem egy olyan kellene, ami nem azt csinálja, hogy létrehoz egy nyelvválasztó menüt, aztán pedig minden oldalhoz külön el kell készíteni másik oldalakra a lefordított változatotokat (tehát magyar, angol és német nyelvek esetében egy oldalt 3 példányban kell elkészítenem, és mindig a megfelelő nyelvűt tölti be). Olyan kellene, ami csak egy oldalt hoz létre, és ott az oldal létrehozáskor paraméterként az egyes nyelveknek megfelelő mezőkbe írt fordított változatok közül mindig az aktuális nyelvűt köpné ki. Mintha lenne egy változó, ami megmondja, hogy az angol nyelv beállítása esetén az angol címet és az angol törzset töltse be, magyarnál a magyart, és németnél pedig a németet. Valami ilyesmi megoldást keresek. Tudnátok segíteni?
CCK-val annyi mezőt hozhatsz
CCK-val annyi mezőt hozhatsz létre amennyi nyelvre akarod a tartalmat lefordítani. A aktuális nyelvet a tartalomtípus sminfájlában vizsgálod és és jeleníted meg a megfelelőt. A nyelvvátásra vagy használsz egy meglévő modult, vagy írsz egy minimodult.
...mit tudok: http://web.termuves.hu
csak ezt ne .tpl.php -ban inkább szerintem
hanem az előfeldolgozóban kéne.
vagy mégtutibb lenne, hogy az egyazon mező külön-külön nyelvverzióit mindig egy mezőcsoportba rendezed és a mezőcsoport előfeldolgozójában az aktuális nyelven kívül a többit unset.
mindazonáltal azt gondolom, hogy ez teljesen elvetemült megoldás, nem tudom mi lehet az előnye. ami kézenfekvő előnye, hogy egy lépésben hozhatsz létre egy nodeot, szuper, és minden mást ami nem node hogyan többnyelvűsítesz?
szerintem az egész ötlet rossz megközelítés.
-
clear: both;
Rajtam nem múlik...
Éppen ezért kérdezem, hogy nem tudtok-e olyan modult, ami menü/blokk/új oldal létrehozásakor lehetővé teszi, hogy rögtön más nyelveken is létre lehessen hozni a tartalmakat, menüt, stb. dolgokat.
Abban egyetértek, hogy ez nem túl szerencsés megközelítés, statikus weboldalnál még talán oké lenne, de dinamikusnál nagyon sámli megoldás. Nekem semmi bajom nem volt az i18n modul használatával, de sajnos az adatfeltöltő userek számára túl bonyolult, össze-vissza hozzák létre a tartalmakat, nem jelölik be a nyelvet, nem a megfelelő menü alá teszik be, stb. Az egyik főszerkesztő kérte, hogy ezt a rendszert szüntessem be, de nagyon gyorsan. Elkezdte magyarázni, hogy nem kell ide két-három külön adatbázis meg mit tudom én mi... Hiába mondtam neki, hogy ez nem több adatbázis, hanem pusztán csak külön oldalakra vannak bontva a magyar/angol/német nyelvű tartalmak; szerinte ez így nem jó, bonyolult és használhatatlan. Utána elmondta, hogy csináljam meg így, ahogy fentebb is írtam. Pontosabban azt mondta, hogy a PHP kódba nyúljak bele, és ott írjam át a címkéket többnyelvűre. Na most én megnézem azt az adatfeltöltőt, aki még életében nem látott PHP forráskódot, hogy hogyan fogja majd egy újonnan létrehozott oldal esetében kibővíteni a PHP fájlokat a megfelelő fordításokkal...
Nem értek vele egyet, de a felhasználói igényeket nem hagyhatom figyelmem kívül (pontosabban megtehetném, csak azzal magam alatt vágnám a fát, mert több megrendelést akkor biztos hogy az életben tőlük nem kapnék), így kénytelen leszek más megoldás után nézni.
betanítás?
többszerkesztős-főszerkesztős környezetkeben szokott olyan lenni, hogy a szerkesztőket betanítják a rendszer használatára. ;)
tulajdonképpen nem neked van a többnyelvűség i18n megoldásával problémád, hanem a felhasználóid nem értik annak a működését. nagy különbség.
ilyeneket lehet tenni, hogy például egy saját modul form_alter -jében a nyelv mezőt elrejted előlük és mindig csak azon a nyelven engedsz nekik tartalmat beküldeni, amilyen éppen a kezelőfelület nyelve. máris nem tudja elrontani, hogy melyik menübe rakja.
(menü adminisztrálására egyébként se érdemes tartalomszerkesztőknek jogot adni, a jól átgondolt menürendszerbe nem "gyalog" pakolja az ember bele a nodeokat)
-
clear: both;
Bürokrácia
Én azt hittem, hogy értelmesen el lett magyarázva nekik. A jogosultságokat nem korlátozhatom, egyetemi intézet honlapjáról van szó, és köteleztek arra, hogy néhány oktatónak admin jogosultságot adjak. Ezek közül az egyik kérte az i18n likvidálását, mondván hogy hülyén van megcsinálva... Volt, aki tudta használni, de van olyan is, aki képtelen kezelni.
aggályos, de megoldható
ilyenkor annyit tehetsz, hogy közlöd a szakmai aggályaidat ahogy illik, aztán eldöntöd megcsinálod-e vagy sem, amint olvashatjuk ezt már eldöntötted
Ádám által is említett cck+preprocess megközelítéssel szerintem ezt egészen kulturált módon meg lehet oldani, persze ettől még ez így nem az igazi, de ha a szükség úgy kívánja én megoldhatónak látom
olyan, hogy "admin jogosultság" nem létezik!
illetve igen, egy darab user számára, akinek az idje 1.
a többiek jogait ő dönti el.
és ez így van rendjén!
persze csinálhatsz egy "admin" csoportot, akinek mindig minden jogot megadsz, de ezt nem ajánlom. (jogosultságok adminisztrációjára pl nem igazán szeretek jogot adni egy csoportnak se, eltekintve attól az esettől, aminkor az ilyen csoportba tartozó egyének maximálisan képben vannak, tudnak "drupalul" gondolkodni)
-
clear: both;
Ez az a pont, ahol én kiszállnék
Ha bárki másnak admin joga van rajtam kívül, akkor én ott befejeztem. Nem, nem akarom a mások hülyeségeit helyrehozni.
Nagy Gusztáv
Én is...
Ezzel én is így vagyok, és hidd el, hogy szívem szerint ki is szállnék, de diplomázás előtt egy évvel nem lenne túl szerencsés kihúzni a gyufát a szakdolgozat konzulensemnél és a szakdoga bírálóinál... Úgyhogy kénytelen leszek végigvinni az egészet.
Rajtad múlik!
Nem értek vele egyet, de a felhasználói igényeket nem hagyhatom figyelmem kívül
A felhasználói igény az az, hogy a bonyolultságot szüntesd meg. A felhasználók az idők folyamán kondicionálva lettek arra, hogy a megoldást is ők találják ki, mert a sok lusta programozó a "nemmegoldható" típusválaszt tolta az arcukba. Ettől még Neked kell megtalálni a megoldást. Igény nem egyenlő tehát megoldással!
Fel kell derítened pontosan mi okozza a problémát, miért nem állítanak be nyelvet.
Lehet, hogy csak annyit kell tenned, hogy egy form_alterrel a nyelvválasztó legördülőt mindig az aktuális nyelvre állítod és kész.
Ugyan így semeddig nem tart elrejteni a formon a nem szükséges elemeket, legyen bármilyen jogosultsága a júzernek. Írsz egy kis js-t, ami elrejti a legtöbb elemet, csak a téma, törzs és menü részt hagyja meg. Ez a kis js még kirak egy linket valahova alulra, ami megjeleníti az eltüntetett elemeket.
A Drupal felhasználói felülete egy katasztrófa. Ha valaki azt mondja nem jól használható igaza van. Testre kell szabni! Erre megvannak az eszközök, meg kell ezeket találni. Soha nem fogsz találni azonban kész megoldást rá! Mert nem lehet egy speciális kérdésre általános választ adni, vagyis lehet itt is van a Drupal maga. Válasz lesz de nem jól használható és kényelmes, no meg nem felhasználó barát.
A Drupal mint program azonban elég jól össze van rakva(és egyre jobb lesz) a működésbe ezért belenyúlni vétek.
Javaslom ülj le és figyelj, hallgasd meg a felhasználóid problémáit. A megoldási javaslatait hallgasd megértően és kukázd, ha baromság. Javaslom szánj arra időt, hogy több alternatív megoldást készítesz számára, hogy ki tudja próbálni és kiválasztani a legjobbat.
(pontosabban megtehetném, csak azzal magam alatt vágnám a fát, mert több megrendelést akkor biztos hogy az életben tőlük nem kapnék), így kénytelen leszek más megoldás után nézni.
Nem akarlak elkeseríteni, de lehet, hogy soha nem fogsz tőlük több megrendelést kapni. Én még nem láttam olyan megrendelőt, aki ne lebegtette volna a szemem előtt, hogy "éshosszútávúegyüttműködésbengondolkodjunk" mivel azt akarta, hogy olcsóbban dolgozzak neki. Egyébként is, ha már az elején ilyen konfliktusok vannak talán mindkettőtöknek jobb, ha elválnak útjaitok.
Sokszor elvárás a Drupallal szembe, hogy szakértelem nélkül össze lehessen vele kattintani egy profi oldalt. Ez irreális. Elemes bútorból se fogsz berendezni tetszőleges szobát professzionális módon. Én mindig azt mondom a Drupal olyan mint a Lego: Bármit kirakhatsz belőle de mindig rücskös lesz a teteje.(© pp) A simításhoz pedig szakértelem kell, ezt vagy megszerzed vagy megfizetsz valakit aki megcsinálja.
pp
Palócz István
https://palocz.hu | https://tanarurkerem.hu
jól szóltál
+1
default node language
A node nyelvenek alap beallitasara core issue is letezik: http://drupal.org/node/311158
(© pp)-vel jelzett szalloigeket pedig ki kellene tenni a d.hu fooldalara :)
otlet
Ne pakolj egy node-ba tobb nyelvet. Ahogy aboros is irta ha a mukodesi alapelvet akarod atirni akkor eselyed sincs, hogy valaha ertelmes weboldal lesz belole. Az osszes kiegeszito modul ami a forditassal kapcsolatos hasznalhatatlanna valik..
Mindenkepp annyi node kell ahany nyelvet akarsz hasznalni.
elindulasi tipp:
Letrehozol egy sima bekuldo lapot kb igy:
Angol
cim: ___
torzs: ___
Magyar
cim: ___
torzs: ___
Nemet
cim: ___
torzs: ___
na es mi tortenik a mentes gombra? 3 node-ot keszit egyszerre. Meg lehet igy is oldani a tobbnyelvusitest, de nem 2 perces munka, es akkor meg a menu-rol nem is beszeltem, ami Drupal 5 alatt "kicsit" maceras. Nem, nincs ilyen kesz modul tudomasom szerint..
a foszerkeszto ne tervezzen programot, mert nem ert hozza..
jogosultsagot meg korlatozni kell, mert azert van. A sajat felhasznalom is korlatozott, ami nem kell azt nem akarom latni..
Valami hasonlót gondoltam
Na ez a megoldás már kezdi közelíteni az elképzeléseimet...
+1
kicsit messziről indítom, bocs. (és igazából nem is pasqualle hozzászólására válaszolok, hanem a témára, csak erre +1)
örök vita, hogy eléggé felhasználóbarát e a drupal.
két külön megközelítésről van szó. én (te) aki developer vagyok, számomra tökéletesen felhasználóbarát, mert értem a működését.
van a "végfelhasználó" aki számára nem biztos, hogy tökéletesen (vagy eléggé) felhasználóbarát.
viszont mivel a végfelhasználók és azok igényei felhasználóbarátság szempotnjából alkalmazásonként változik, ezért éppen elég, hogy a fejlesztő számára felhasználóbarát + baromi rugalmas, hiszen így minden egyes alkalmazásra könnyedén testreszabhatom a teljes felületet (nem a működést, hanem a megjelenést!) adott alkalmazás végfelhasználóinak igényei szerint.
itt is erre van szükség.
nem egy alternatív többnyelvűség-megoldást kell kidolgoznod, hanem a meglévő és hibátlanul működő többnyelvüsítési mechanizmus adott végfelhasználói körre való testreszabását kell megoldd.
a konkrét témánál maradva, egy saját modulra lenne szükséged, ami könnyebbé (könnyebben érthetővé, kezelhetővé) teszi többnyelvű tartalmak létrehozását.
egyik ötlet:
egy saját modul multistep formra cseréli a tartalmak beküldését, rögtön az első lépés lesz, hogy hány nyelven akarod létrehozni ezt a tartalmat. aztán kap annyi lépést kap, ahány nyelvet kiválasztott és a végén mented mindegyik nodeot az adott nyelven, megadva, hogy ezek egymás fordításai.
másik ötlet:
létrehozod cckval a beküldő űrlapot egy (a default) nyelven. aztán a saját modulod nyelvenként új mezőt ad a node beküldő űrlaphoz és elintézi azt, hogy ha mondjuk kitöltöm akárcsak az egyik mezőt valamelyik nem default nyelven, akkor az űrlap beküldésekor rögtön két "node_save" történik.
persze ez csak egy kósza ötlet még jól át kell gondolni, mert pl mi van a taxonómiával..
zárszóként annyit szeretnék mondani, hogy az semmiképp nem megoldás, hogy megerőszakolod a drupal immáron kiforrott többnyelvűsítési logikáját (csupán csak azért mert adott alkalmazás felhasználói nem tartják eléggé logikusnak azt) ha másért nem is megoldás, hát azért mindenképpen, mert minden más contrib modulod erre a logikára épít és ha te lecseréled azt egy saját logikára, akkor minden más modullal is tudatnod kell majd, hogy nem úgy kell működnie hanem amúgy.
vics iz novánz ájdia of hev fán. :)
-
clear: both;