Oliver

Ok, so I’ll try to keep the client out of the module and setup section for now. Sorry, my code example really wasn’t very enlightening. Of course I know we deal here with the actual field names of the database schema and the relation would be lost as soon as I change the showFields array. My thought just was, that in view of usablity/readability aspects there should be a way, to change the table’s column headers without leaving the fieldname thing. For example: $this->set('showFields', array('name'=>$this->('Name'), 'title'=>$this->_('Language'), 'language_files'=>$this->_('Language Files'))); as an optional alternative to $this->set('showFields', array('name', 'title', 'language_files')); A similar approach like you already implemented in your »row()«-syntax: $table->row(array( 'text' => 'link', 'only text' ); Just an idea. But there is another point. As soon as $this->_() is used multiply within a command like this $this->method(array($this->_('Text1'), $this->_('Text2'))); or this $field->value = "<span>".$this->_('partoftext')."</span> ".$this->_('another part of the text'); just the first $this->_()-phrase of the line seems to be displayed for translation in the LanguageTranslator.

Got a little question here: I’ve been trying the Fieldset field types in a current template I’m working on. Now when opening the page edit interface, three info messages pop up at the top telling me the first part of the fieldsets name an the encapsuled fields. They all are named like »tab-xy« and »meta-xy«. See attached screenshot. Any idea, what causes these messages?

I’m currently setting up PW with LanguageSupport for a client project. And so I experimented with the $this->_() thing trying to switch the whole backend to German, as the client wants it this way. Working on this two issues came up: First one is the aready known getModuleInfo problem, as it is used to display infos on all available module admin interfaces in the backend’s setup area. I think that making this part translatable is a crucial point in view of this list being the user’s gateway to more advanced functionalities provided by – I’m pretty sure – more and more available and extensive modules. Another one came up when I was trying to make the translator itself translatable. (Why isn’t it translatable by default?) When the following is used in modules $this->set('showFields', array('name', 'title', 'language_files')); you can’t translate the table’s column names without corrupting the list rendering. I really love the system languages feature so far, anyways.

Love it, Nico! Really nice! Can’t wait to try it.

Thanks once more for the input. You touched on some aspects I still have to think about. Yeah, I guess things will get clearer as soon as I try to put them into code. With meta information I meant stuff like context specific URL (to allow context selection by domain) or language information (en-US). The point of introducing an additional template var $context besides accessing the context's subpages, would be to provide the contexts information at any time on any subpage. And to easily switch contexts (from mobile. to www. for example). I'll give it a try. Maybe you are right and there won't be a good reason left in the end for having another template var around.

Your last hint is exactly, what I thought of. A template var $context made from Wire::setFuel('context', $pages->get('/contexthome/')); . But I think it would be necessary to make $context a extended version of $pages with e.g. a ->switch($contextname) method. The context's meta data would-as already mentioned-be stored in fields of the special template of the context's home pages. BTW: Is there a way to keep template fields from being deleted?

I saw this recent post in the forums: http://processwire.com/talk/index.php/topic,770.0.html It seems, as PW progresses, the same questions pop up in community members' minds at the same time. While working on a proper solution to deal with the multi-language content stuff in future, I have been thinking about the multiple tree thing a lot. I have always been a fan of ModX' "context" idea. But as ryan and Soma already pointed out, PW as a "framework" provides a very open base that allows to "interpret" the given structure as multiple trees, if you want to. As it could actually be helpful in such a case-or a similar case like when dealing with multiple languages in frontend-to react correspondingly in view of content management, I've lately been thinking about creating a "contexts" module to store context meta information (like e.g. language or maybe content type?), context page access and context switching. All this through a template var $context with acts like $pages but just within the context's page tree. My idea was to provide this as a standalone module. And the languages module for content translations would extend the context functionality by page mapping between the contexts. So the languages wouldn't be manages separately, as the contexts represented by their particular "home" pages theirselves would be the data containers for any language data.

Besides the information on what modules are required to allow the installation of a certain module, there also should be a version info set. Like "FieldtypeXY > 104" for module FieldtypeXY version 1.04 or above being required.

Had a similar thought right this morning, Nico. That’s definitely a must, as the dev community and the numbers of modules seems be growing. There should be a kind of best practice guide including naming guidelines for modules and for their db tables for example. How to organize modules with multiple files / classes, how and where to store module specific config data etc.

Thanks again for your detailled reply here. I think I’ve to play around a bit with the language support thing to find out, if it would make sense to base the module upon your already implemented structures. We’ll see.

I see your point. But wouldn’t it also be confusing, if you had to translate the static parts of your templates through the new PW multi-language feature and also had to install the same language again in an translator module to translate the actual content of the pages?

With the upcoming multi-language support of PW2.2 in mind, I think, it’s needed to do some changes in my language module–like e.g. reacting to the fact, that the $languages template var is now already in use. First–as it could be a reason for confusion–I’ll change the modules name from "Languages" to … ehm, not sure yet. Something like "Content Translations". Also will I make all texts in the admin translatable as well, of course. There are some questions to be answered: Should I drop the language management in the admin pages and use the language table of the multi-language support of PW2.2? So the module would map the pages associated to the languages set up there? Ryan, is it possible to extend the $languages var you now implemented to add some functions to make the content translations accessible using the same interface? Would it make sense?

Nothing yet. I try to find a way around the hook by changing the config value containing the error page’s id like Ryan said. I’ll let you know when I got it working.

Thanks a lot, Soma, for your inputs. It’s right, I forgot to exclude the error page from the cloning process on creation of a new language. Also keeping the new translations unpublished is good idea. Maybe I also should exclude unpublished pages from the translations array. I’ll try to work something out here. And yeah, the uninstall process is still a mess. I know that. I’m not sure yet how to change this for the better.

Ryan, thanks for that hint. That could be really helpful. I could set $this->config->http404 the moment the language is set through setLanguage(). I guess, this would also solve Nico’s problem, as the error hook wouldn’t be necessary anymore. But I would have to change the setLanguage hook from page::render to another event, on which a missing page wouldn’t have caused the error yet.

Good. One question answered. Anyone got an idea, why this hook shouldn’t work? It does on my test environment. $this->hooks['getErrorPage'] = $this->addHookAfter('ProcessPageView::pageNotFound', $this, 'getErrorPage');

Really weird. But just to be sure: I made a mistake on my first upload to GitHub and pushed a file with a .module.php ending. Please check, that there aren’t two module files in your module directory, one .module, one .module.php. Also try to insert a die("something"); in the constructor somewhere to be sure, you are working on the right file.

Try to insert the following line between line 587 and 588 before the if condition: die("’#^".$this->config->urls->root."([a-z0-9\-_]+/).*$#’, ".$_SERVER['REQUEST_URI']); Just to be sure, the hook definitely doesn’t work here.

Damn, no idea, why it shouldn’t be working. Tried it several times here. Please open your ProcessLanguages.module and have a look, if the getErroPage hook is set in the constructor. Are you sure, it really is the root error page? The language specific ones look exactly like the root http404, as long as they haven’t been changed. Only the breadcrumbs may tell, that it’s a language trees subpage.

Oh. The new updater attached should fix the wrong mapping of your error pages. Try it. Did you replace your ProcessLanguages.module with the new one from GitHub after using the updater? UPDATE: Pushed another update to GitHub, Nico. After applying the new updater and replacing the module file once more, the error404 thing should work. I changed the handling the way that if it fails determining the language by the requests path, it serves the default languages error404 page instead of the system’s general one. Hope, it works out this time. ProcessLanguagesUpdater.module

I’ll consider your idea. I’ll try something like cloning the error pages for each language, create an own template less strict template and implement a hook (like in apeisa’s redirects) catching errors and trying to serve the correct language page or the default language's one. But I guess, it will take a moment to get this done! UPDATE: Nico, I worked something out and it’s now possible to have translated error pages. Already pushed the update. Please replace your module with the new one from GitHub. But before you do, download the little update module in this post’s attachment. Install it and uninstall it afterwards. It will create the http404 error pages what usually would be done on first install of the new module version. Make sure your http404 page is back in the site’s root where it has been originally. Updater was removed.

I think this case could be solved by creating a 404 page with an own template in the language tree and changing the original 404 template outside the tree to outputting the rendered content of the language specific error page. Should be easy to get there by using the standard API selectors (path + template filter) and a regexp to get the language path–as Ryan said–from REQUEST_URI. Maybe I should make the $language template var accessible on all pages instead of just language pages?

Sorry, there must have gone something wrong. Now the "2" is definitely gone. On the topic of translating system pages: I have neither an idea, yet, how to work around the protection of system pages, nor can I tell if the 404 pages still work the way they usually should, when placed in a language tree. Or how to assure the right translation is delivered on error depending on the current active language. Never tested that. Maybe Ryan has an idea or hint for us?

Oh, sorry, the version without debug output is already available on GitHub.

Oh, that "2" is a debug output, I forgot to remove. I’ll push again.