Soma

Yah! First poll! For fun, but also seriously...

Yeah, maybe it's not as ideal as one may wish it to be to enter translations. But it's pretty decent start. As I understand it, it's using gettext and it uses textdomain for each file/module in the context of it. This may seem inefficent, but one global file for all words used all over the system would be a nightmare. One phrase used in the context of a module may be differently translated in the context of another module in another language. Note also context information (descr) can be added right after the translation syntax, that will show in the translation editor. I think it's well thought out by Ryan, even though there's always things to improve. Maybe he also pops in to give his statement.

Ah. Then are you using the translation for frontend template? I tried it once and got away from it for various reasons. I still use translation files for frontend translation (for the static terms, forms etc) using yaml file for each langauge. So it's much easier to compare and have them in a readable key -> value format. It allows me to define them like: label_send: Send ... Then in templates I can use it like: $txt['label_send']; In the head I include and determine the langauge using this code: require_once($config->paths->root . "site/libs/yaml/sfYaml.php"); require_once($config->paths->root . "site/libs/yaml/sfYamlParser.php"); $yaml = new sfYamlParser(); // parse language file $txt = $yaml->parse(file_get_contents($config->paths->root . "site/languages/" . $lang . ".yaml")); I use this php yaml parser lib https://github.com/fabpot/yaml

Why? I've never had the feeling I need to edit them directly in the file. Edit: Maybe something like this does help? http://www.jsoneditoronline.org/

Yeah I mean it serious!! Hehe thanks a bunch Ryan, it actually works! Funny solution I'd neve thought of myself. How comes it is like this? Is there something like outputformatting to turn beautifier off while creating pages?

For same reason Ryan mentions. I believe there's this need, as the web is a child of print, but those rules/habbits that were true to the print medium doesn't apply well in the new dynamic medium. The industry, and people in general need to first grow on it, and is only yet adapting which will take some more years or even decades. I don't say there's no solution for this problem in particular mentioned here and maybe wasn't really a problem as of now (devices are not only desktops anymore), so it's coming back at us for not yet considering/knowing.

Ok thanks for mention. Then I guess it's because it's theme dependend. Couldn't this be done without, and add hidden to such things (as with the mastheader) inline? Every such feature will require to update all themes in the future and can be a trap or/and annoying. Maybe it doesn't make sense, and can't be done as I think. Just wanted to mention it. Sorry, now trying to find the issue, it was a "fault" on my side. The process input css is the one hiding it with absolute position and I overwrote without knowing the context class to add padding and top attributes, thus overwritiing the top -9999 of the core css. So it's all good I guess anyway

Ryan, he means the default URL description text. Which is nice, but if you enter a space in the description there will be still a space above the input text field. I figured that adding in a 0 (zero) will ommit it completely, thus no space anymore. I think there should be the default text in the field description, or none at all. So you can input or leave it empty, without asking anyone. AS for the other problem of field heights. It's annoying and I started a js script that would set all (in one row) to the height of the highest. Unfortunately it's more of a bad hack to something that should be possible in browsers since a decade (imho) and will fail for the reason you mention. Maybe we will find some solution here that works better.

I have an import script that imports static html pages via API script. Some of the pages have a name like "001._pagename.htm". Untill now it worked and the name of the page was the same and links worked to those documents. Yesterday I did an update to latest PW, now it changes the name to "001-pagename.htm", and links stop working cause the name is different. When and what did change? I think the previous core version was 2.1 or something. Can this be changed or avoided? $p = new Page(); $p->parent = $parent; $p->template = wire("templates")->get("gb-page"); $p->name = $filename; // sanitizes string different now $p->title = $title; $p->body = $dom; $p->addStatus(Page::statusUnpublished); $p->save();

apeisa, yes that's what I did. I thought why so complicated if there's a nice method to add those in PW. Sorry to not explain further.

I don't understand why and what exactly you did. But for having $page->children()->renderListItem(), you could just simply create a module to add that method to page array objects. I've done similar things in a project.

Hey Jeff, thanks for the nice words. I agree with you here. ProcessWire aim is to keep things simple and I enjoyed contributing to it with this nice little resource. Hope you enjoy your stay

Just enter 0

Minor, but when I edit a field on the template setup, it opens in a modal window and the header of the admin template is hidden. There's this context select on the top right. When I select something it reloads the page and the admin header is suddenly shown. Seems it doesn't recognize being reloaded in the modal context.

Well, then I have something for your scientific spirit! function turnPage(){ turnPage(); } turnPage();

Ahh i was talking about a in b. In itself doesnt make sense at all.

I actually tried it the first I did when it came out, it seemed to work, though silly and not tested further.

I just commited a major update to this theme I use every day Improved page tree with some new icons. Changed login screen a bit. Changed content layout to have all content, title and tabs included with round corner and slight shadow... Made sure that everything works with field columns (had still some issues). Made the max width of layout a lot wider. I updated the first post with the lates screen. If you happen to find any bugs or problems, please let me know so I can fix it. Latest screen:

Hey Jeff, welcome to the forums. It "would" certainly be possible to use language fields, but I would not recommend. Better to use alternative fields for mobile, or even separat tree. A a simple example have a "body" field for normal desktop, and a "body_mobile" field. So you'd add a check for mobile and have a $mobile var with the string "_mobile". And add that to the fields you need. echo $page->get("body$mobile"); Not sure if that's the best way to go, but certainly a simple one.

I can confirm.

Ryan you're my hero! Loaded, tested, works now. Happy.

Hello mcmorry, are you still working on this? Mind creating a repo on github for this module, so we can collaborate more easily on this? (If you want, I could create one on my account. However... While playing around with multilang and this module I found a simple way to use sanitizer (which Ryan already modified to allow replacements). The slug method can be changed to: public function toSlug($str) { $str = mb_strtolower($str); // needed for uppercase cyrillic chars $str = $this->sanitizer->pageName($str, Sanitizer::translate); return $str; } Also has to change or add various code to support urlSegments and pageNum. So it doesn't throw an 404 but load the page before it reaches segments that aren't solved. I also changed the hook to $this->addHookAfter('Page::path', $this, 'mlUrl'); So the system internally also works, and no change is required to use mlUrl. It works great so far. I kinda collaborated with MadeMyDay over the weekend on this, as he's doing a website using this language urls together with the multisite module. So we made similar changes, altought he got more I think. He got it also working using both modules. So this could turn into an interesting alternative to multilanguage sites. Edit:: I also tried to find easy solution for defining published languages. So I created a page field that returns the proxy language pages as checkboxes. So you can turn a language off. The module then looks for this and throws an 404. To get this to work, navigation code, language switch, and all list generation has to consider those, but it works ok. A language switch would be a simple as: $lang = $user->language; $langname = $lang->name == 'default' ? 'en' : $lang->name; $user->language = $languages->get("default"); $st = $langname == 'en' ? " class='on'" : ''; echo $page->language_published->has($pages->get("/en/")) ? "<li><a$st href='{$page->url}'>EN</a></li>" : ''; $user->language = $languages->get("de"); $st = $langname == 'de' ? " class='on'" : ''; echo $page->language_published->has($pages->get("/de/")) ? "<li><a$st href='{$page->url}'>DE</a></li>" : ''; $user->language = $lang;

I tried for hours to get markup pager nav to work in the search page. After I logged out to see what happens, it worked. It seems only when I'm logged in as superuser, it doesn't works when logged in as an editor. All I do is $matches = $pages->find("title|body|sidebar%=$q, limit=3"); $count = count($matches); if($count) { $out .= $matches->renderPager(); ... Anybody can confirm this? I tried in 2 installations. EDIT:: Ok I tried again and on an install without language fields installed AND language page title set, it works. After installing and switching "title" field to language page title field AND set superuser language to an alternative like german, the pagination stops working with a search like the above. The limit isn't recognized anymore only when I would do: $pages->find("title|body|sidebar%=$q")->find("limit=3"); And then the limit works but the pagination doesn't work anyway. So in other example in short, for guest user it works when I set the guest to default language, but when set to an alternative it doesn't. What's happening?

I still can't seem to install the module. When I got to module page and click for new modules, I get a server error. 2012-05-28 07:09:52 admin http://.../processwire/module/ Parse Error syntax error, unexpected T_PAAMAYIM_NEKUDOTAYIM (line 16 of /.../site/modules/Shop/PaymentAbstract.php)

My teflon theme is uptodate. If you use one that doesn't urge them to update their theme too.