alapertelmezett nyelv (default language):
az alapertelmezett nyelvet nem lehet kesobb megvaltoztatni, mert a dinamikus forditasok (string translation) nem fognak mukodni.
ahhoz, hogy a latogatok magyar nyelven lassak az oldalt amikor eloszor latogatnak a weboldalunkra, akkor magyar nyelvure kell allitani az alapertelmezett nyelvet. Igy ezt legjobb mar telepiteskor megtenni, es igy minden dinamikus forditas alapja is a "magyar" lesz.
tehat a "kutya"-t forditom "dog"-ra es nem forditva. A felulet forditasa tovabbra is angolrol magyarra forditas marad..
szoval jobb eldonteni milyen nyelven szeretnenk udvozolni a latogatokat, es mar installalaskor ezt valasztani, vagy ragaszkodni az angolhoz a egyseges forditas miatt (es bizni a bongeszo beallitasaiban, hogy mindenkit a megfelelo oldalra iranyit)

Contact oldal magyar utvonala:
Az utvonal alneveknek (alias-oknak) van nyelvi beallitasa, igy letrehozhato a "contact" oldalhoz csak magyar nyelvu "kapcsolat" alias.

taxonomia forditas:
ha a taxonomia forditasnal a "Localize terms" modot hasznalod (tehat nincsenek kulon kifejezesek (term-ek) nyelvenkent, hanem a kifejezesek vannak leforditva) akkor erosen javaslom a Translation table modul hasznalatat..

nagyon nehez ez a Drupal install, de szerencsere megbirkoztatok vele :)

Most akkor kipróbáltam, hogy nehogy véletlenül is hülyeséget írjak.
A második problémádat nem is értem. Simán megy a keresés nekem úgy ahogyan azt elvárná az ember. Tök pöpecül szűri a hoteleket, panziókat, jakuzzi, félpanzió meg minden.

Az első problémádra továbbra is az általam vázolt lesz a megoldás. Ha nem érted a válaszom végét akkor meg tanulj és kérdezz. :D Ott leírom ugyanis hogyan lehet széppé varázsolni egy ilyen csúnya dolgot.

Drupal olyan mint a Lego: Bármit kirakhatsz belőle de mindig rücskös lesz a teteje. - pp -

Az, hogy bonyolult, vagy sem, egyszerű vagy alapvető az meg annyira szubjektív, hogy csak na.
Ha a két kérdést a végén komolyan gondoltad akkor kérdeznék én is kettőt:
Ha ismersz olyan rendszert amiben ez sokkal egyszerűbben megoldható, mint a Drupalban, akkor miért nem azt használod? (tényleg komolyan kérdezem, megfelelő feladatra a megfelelő eszközt.) Ha meg nem ismersz ilyen eszközt akkor miből gondolod, hogy ez olyan alapvető és egyszerű lenne?(ez meg itt csak amolyan gondolat ébresztés akar csak lenni... hátha)

pp

Én is sokat szenvedtem a views megértésével és átlátásával, még nem tökéletes a dolog, de azt hiszem a te problémádon tudok segíteni.

Tegyük fel, hogy létrehoztál egy tartalom típust, amelyben feltöltöttél 20 db fényképet. A probléma lehet az, hogy a képek szépen egymás alatt helyezkednek el. Erre megoldást nyújthat, ha kreálsz egy új view-t. Adni kell neki egy nevet, a type pedig node legyen. A basic settings-nél a style legyen grid és vertikális. A fields-nél group=content és kijelölöd azt a mezőt, amelyet létrehoztál a kép feltöltéséhez. A filtereknél fontos, hogy közzétett legyen és a node type pedig az általad kreált tartalom típus.
Most jön a view ráerőszakolása a tartalom típusodra. A bal oldalon az "add display" segítségével adj hozzá egy node content-et. Itt a node type legyen az általad létrehozott tartalom típus. Elvileg máris érződnek a változások, de persze kell még csinosítani a views segítségével, de már látható a fény az alagút végén.

update:

Közben rájöttem, hogy a kreált view-nél létre kell hozni egy argumentumot, amely Node: Nid legyen. A Breadcrumb mezőbe ezt írd be: Title. Azt hiszem ennyi. Remélem nem beszéltem túl nagy butaságokat.

De ugye ezekről a hibákról ment egy rögtön issue is? Ha leírja az ember, hogy mi a gond, akkor a következő változatban nagy valószínűséggel kijavítják. Néha ugyan szájbarágósan kell elmagyarázni, hogy mi a probléma, mert a contact person nem feltétlenül tudja, hogy minek az a $sticky a node.tpl.php-ba. De nekik is érdekük, hogy minél jobb legyen a szoftver.

Szar volt a maintenance képernyő, elgépelés volt a generált style.css-ben, fordíthatatlan volt a smink néhány helyen, nem kezelte jól az RSS feedek ikonját, kihagyta a $sticky, $promote, stb. változóktól függő css osztály hozzáadását a node.tpl.php-ből, user defined css mező is nagyon hiányzik belőle, és még sorolhatnám. A 2.4-et konkrétan még nem néztem meg idő hiányában, de ha ezek megjavultak benne, az mind egy-egy hibajelzésem eredménye.

Nyilván nem automatizálható teljesen egy smink elkészítése. Viszont van egy szoftver, ami kiindulási alapnak már jó - és ezt kevés másik, konkrétan kb nulla - tudja magáról elmondani. Szerintem nem az a megoldás, hogy ne használd, hanem a hibák jelzése. A következő változat jobb lesz, és pont annyival lesz jobb, ahány hibát / fejlesztési igényt jeleztek a júzerek.