Oliver

Nico, I guess the 404 page wasn’t mapped correctly. I’ll look into that. UPDATE: Actually the problem was, that the template of error pages prohibits deletion. So the "delete" tab doesn’t exist, what caused the error on adding the "languages" tab. But it’s fixed and pushed already: https://github.com/LorGG/ProcessLanguages Actually I‘ve no idea, if it will work using translated error pages within the language page trees. Never tested it or even considered it. Let me know!

I had a quick look at the data model in the db associating the files with their pages. I haven’t tested your plugin, yet, but I think, it would be nice to let the user navigate through files by treating the page structure and file fields like directories. Similar to the url paths. And with the possibility to directly upload files into those "virtual" directories.

Would love to have the possibility to manage "assets" like files / images in an own manager interface. File or image fields of pages could be linked with directories in the asset manager, so there wouldn’t be a conflict between centralized and page related approach.

Ok, I have to admit I don’t have any Git experience. But I somehow got a github repo set up. So here you go: https://github.com/LorGG/ProcessLanguages Yes, it’s a lot of code. You’ll find several functions regarding sync functionality. I tried to make the code more or less readable by adding some comments and by grouping the functions by their field of use.

Thanks, Ryan. There are still some issues to deal with regarding basic functionality/pure translation management. Like reliably mapping pages created outside a language tree after they've been moved into it. Or manually selecting existing pages to map them as translations of each other. Beyond that there is already a lot of stuff within the code for the more advanced features like the mentioned syncing. Currently translations are mapped in a "mirrored" way. Every translation of a page has the current page's parent's translation as its parent. This fact causes some logical problems if there should be an option offered-like requested here several times-to exclude single pages or whole parts of the language page tree from syncing. And should the language trees-if synced-be synced with the default language's page tree? Or should any change to the page structure of any language be synced accross all language page trees? Also there has been the question what happens to-for example-file or image fields. Currently they are duplicated. Maybe we should think about providing some "synced" field types. Like an images field that acts like an alias of a real images field, and that can be attached to translation pages. Would love to hear some ideas what could make the module more useful.

Nico is already testing the module and helped me to make some little changes for the better. As already said, I'll keep the opening post of this thread updated with the most recent version of the module. I just updated it this afternoon.

Oh, I guess, I mixed something up here. I’ll change it to $languages. Ryan’s plan is all about language implementation in the back end and maybe for static parts in the templates. So I think both approaches cover different aspects of the same problem. I’m sure his thoughts on the topic will give me the one or other idea for enhance my module. UPDATE: Changed the template var name to lowercase.

Sorry, another bug, I thought, I already had fixed. Seems I never finished that one. Ok, here’s the fix: On installation the module clones the root page’s template and copies the file in the template directory. But it misses the ".php". Go there, attach it, and your language’s start pages should be fine. It’s fixed in the updated version. I attached the most recent version of the module to the first post of this thread. I’m working on the template variable thing. There will be a variable $languages available with information the current language and of course ids and paths to the translations in the other languages. Yes, there is still a long way to go. UPDATE: Template var is implemented. In all mapped pages there is the var $languages accessible. $languages->current stores an assoc array with data on the current language (id, language, code,...). $languages->translations stores an assoc array with the language codes as key and the translation page’s id as value. If there is no translation, the value is null.

Glad to hear that. In the page edit form of any page created within a language’s page tree, you should find a tab «Languages» at the top, left of «Delete» and «View». There are all languages – besides the one the currently edited page belongs to – listed with a link to the page’s translation, if available. If there is none, there is a select box to create a translation by cloning the current page or creating a blank page in the other language’s page tree. There is no possibility to map an existing page of another language page tree manually to the currently edited page, yet. Or did I miss your point?

Nico, I think I fixed it. Just replace the module file with the attached one.

Do you have set any other language up, yet? I guess, it’s a problem with adding the language tab to the page edit form while there is just a single language. So the field may not be set up but the var passed to the add-method anyway. I’ll have a look.

What version of PW do you use? Never had this error before.

So, guys. Although I’m scared like hell I attached a first test version of the languages module to this post. It’s heavily cut down and removed a lot of the functionalities we discussed here. But the most of it is still in the code to implement it. At this point, it just manages the mapping between language trees and leads the visitor to the default language. Be warned: it’s still buggy. And there is a lot stuff it just doesn’t allow to be done. Like moving translated pages and stuff. Anyway: feel free to play around with it on your own risk. If you want to, have a look at the quick and dirty style code of an autodidact. I’d be more than happy to get some feedback and some hints to do the one or other thing in a better or at least cleaner way. So, go fort it! UPDATE: Attached file is out of date. Updated one here.

Thanks for the inputs. The point is, that when a page from a language page tree is moved to trash, its translations are moved there, too. But maybe you guys are right. I should probably unmap the pages as soon as they leave their language’s page tree.

The first version won’t provide a possibility to exclude pages or parts of the language page trees from syncing. There already are methods and stuff included to implement it. I’ll also prepared the db tabels for it So it’s pretty sure, I’ll get it done for a later release. There are several logical problems to be handled when unsynced pages are moved within a language’s page tree or synced once are moved into unsynced ones. I guess I can focus on it more clearly as soon as I got a basically functional version out and in use.

Of course there is no reason. But there is the possibility to do it. And so I’ve to deal with the case someone uses the delete tab of the page edit form of a trashed page. Just to be sure the consistency of the page map won’t be corrupted.

After having lost focus on my sweet little module here, I’m back on it now. Stripping stuff to get it finally working including the most important functionality. And I start with a question again! $this->hooks['unpagemapPageOnDelete'] = $this->pages->addHookAfter("delete", $this, 'unpagemapPage'); The hook above is triggered when a page is deleted (not trashed, really deleted). But I’ve to deal with two different situations: The trash is emptied, so every page in it is deleted. As by moving a language page to trash its translations go there, too, I don’t need to care for them being deleted and unmapped. But as soon as I open the edit page of a page in trash and delete it by using the "delete" tab, the page is deleted and I actually have to care for its translations. So I need something to check on and choose a way how to process the unmapping. I guess the best way is to check the process. Can I access the process’ name in the function hooked to the event above somehow like this? public function unpagemapPage($event) { $page = $event->argument[0]; if($page->process != "ProcessPageTrash") { … Thanks in advance, again!

Thanks for the input! Sorry for keeping you waiting. Have a lot going on here at the moment, so I don’t get a real chance to work on the module again. Maybe more this week.

Thanks for the input, Ryan. Currently on installation the module creates a first language tree (english) automatically. It can be renamed to whatever language you want it to be. It is set as default language, because there always has to be one defined. The default language is the one you are redirected to when you access the root page as a visitor. Also it’s the master for all languages with sync set to 1. I reduced the functionality for this first version to the pure syncing of the language trees to all actions performed on (mapped) pages in the default language tree, syncing templates, sort, status, parent. I guess, in case of translations it makes more sense to keep the page hierarchy synchronous–and implement pages not synchronized by an option to exclude them from standard sync behaviour.

Pete, you reached the point of the story, that has been driving me nearly crazy for over a week now. As soon as you exclude pages, there has to be a logical way to deal a) with its children, as they were synced b) with synced pages maybe moved below the unsynced page as its children Soma, that's a good point. But a complex one, I guess. Maybe a cool feature for version 2 or 3.

Yeah, I’m currently reducing functionality for a first test version. Just a general question: If page trees are synced, what page attributes/properties would you guys like to be synced? Parent, order, template, status? Anything else? Or anything definitely not?

Ryan, just a GU thing: When the page has a template with noMove set, shouldn’t the "move" link in the page list be hidden? On my endless ways through the core files I believe I saw some code related to that. So far it doesn’t seem to work properly.

Thanks for the offer, Soma. Would help, if you tell about the functionalities you’d expect such a module to have. Maybe it gives me an hint for the one or other question I still have to get an answer for. The real complex thing still is to keep the page mapping (associating the different language's translations of a page with each other) consistent, while allowing pages to be moved, trashed or deleted and also to providing the possibility to have pages in a language tree that aren’t sync’ed with other languages. I implemented a sync option to automatically sync a language with the defined default language. So creation and deletion of pages in default language’s page tree will be repoduced within the synced language’s page tree all the way. Alternatively, you can deal with the translations manually by creating them from the language tab in the page edit form (as already said: by cloning as well as by creating an empty new page). What would you guys suggest should happen, when a page is moved outside the language’s page tree or is trashed? On sync, I guess, the associated pages have to be deleted or–in case of being trashed–also be trashed. When a mapped page is moved within the language tree, the associated translations will be moved to the parent within their particular page tree, that is mapped to the new parent of the current languages page tree. But if you can have pages without a translation in the other language trees, what should happen on a page being moved to such unmapped page as new parent? Should this parent be replicated to the other language trees as new parent for the as well moved translations? Or should it be forbidden to move to unmapped parents? Maybe I just should reduce the functionalities to syncing the page trees 1:1 first. Btw: What information on the current language is needed within the template? ISO-Code? LCID? Or what else? Let me know.

The further I get, the more complex it gets. Have still to deal with some issues, before I can give you a test version covering the most important functionalities.

Yeah, sorry, mixed that up. Of course "set"! Was a bit too much dealing with InputField attributes today. Anyway, got it working. Thanks.