Module: Languages (multi language content management)

[Oliver]

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.

[ryan]

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.

This is correct. I don't think there is any crossover between what your module is doing and the new Languages modules being built for PW 2.2. I am very excited about what you've put together here and can't wait to try it out.

[Oliver]

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.

[ryan]

Oliver, just got a chance to try this here and I'm really impressed. This seems very polished for an alpha version. Everything worked for me as I thought it would and was very easy and straightforward to use. I don't have any good test cases at the moment so just experimented rather than tested with a real site... But if this works as well in larger scale/real use, it is really a great system you've built. It looks like a lot of work has gone into this and this may the most extensive modules built yet. Thanks for your efforts here and keep up the great work!

[Oliver]

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.

[Soma]

WOw great module already, very well done. It's quite long code to study, but I just went and am playing around for a little.

I see there's still some way to go But still that's what's there is great! Love it.

I experienced some weird things.

The template created home_language has fields set from the default basic page template. I think it should not add (only title) to or may try implement something to select it when installing

-- So far so well, now the template fields are not using asmSelect it seems, so I cant add or change them. Dooh!!

-- So also it shows me in the template overview page int he fields col "6 home" which is strange and shouldn't be, only count of fields.

-- And when I add a physical php template to it, I get an memory excaused php error from adminbar module when viewing page. Errm not sure why, haven't looked further at it for now.

I strongly suggest now that you're throwing out a first cut version, to upload a git repository of this. This would help and other may can help easier. Also it's great for issues. I fear it can get cumbersome to manage all in this thread alone.

Thanks again for working on this awesome thing!

[Oliver]

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.

[apeisa]

Just gave this quick testing and I am super impressed with this! I didn't found any problems (also running AdminBar on my test site). I was also amazed about how much there is already implemented, I see how useful this will be for sites that have multiple languages and need to have links between pages. Excellent work Oliver!

Testing this got me thinking, this cloning/syncing stuff might be beneficial in other ways also than only language versions. Not sure though, but one example I remember building was site where was "levels", and each level had same articles. (Those levels were like grades for professional sports coaches and articles where different areas about coaching).

[Nico Knoll]

I moved my 404 page into a language tree and now I'm receiving this error, if I want to edit it:

Argument 1 passed to InputfieldWrapper::add() must be an instance of Inputfield, boolean given, called in /var/www/l3s46/html/nico-knoll.de/schiller/site/modules/ProcessLanguages.module on line 473 and defined (line 102 of /var/www/l3s46/html/nico-knoll.de/schiller/wire/core/InputfieldWrapper.php)

This error message was shown because you are logged in as a Superuser. Error has been logged.

[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!

[Nico Knoll]

I don't get this error anymore, but if I'm trying to create a translation by cloning I get this ProcessWire error:

You may not modify 'id' on page '/de/http404/' because it is a system page

(But it's working if I select "by creating a blank page")

And there is a "2" at the top left of the page.

---

And if I try to open a broken link I always get redirected to the original 404 page...

[Oliver]

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

[Nico Knoll]

Ehm, could you post a reply here if the fixed version is available?

[Oliver]

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

[Nico Knoll]

Well, the 2 is still there... And it's still the wrong 404 page for other languages...

[Oliver]

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?

[ryan]

The 404 page is a system page, so it's a special type of page that has a predefined purpose in the system. It's best to leave it where it is and work with it. What I would suggest is creating a new template and assigning that to the 404 existing page. That template should display a "page not found" message in multiple languages.

But if you wanted to take it further, you could detect language was at the beginning of the URL (via PHP's $_SERVER['REQUEST_URI']) and output a language specific version, or pull in another language-specific 404 page and echo $otherPage->render();

Since there are multiple routes you could take here, from very simple to more complex, this may be something worth leaving to the individual installations to handle on their own according to their needs.

[Oliver]

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?

[Nico Knoll]

I think the language-404-pages should work like the "home" page: A special template ("404_language") should be created automatically and work like the "home_language" (using the original's fields, template, etc.) or copy its fields, etc. After this in every language tree should be created copies of the orignal file which can be edited. And the original file should just render the language-404-pages like Ryan wrote...

[Oliver]

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.

[Nico Knoll]

Well, the pages are created but there is no connection between the german and english 404 page (in the language tab). And it still shows the root 404 page...

[Oliver]

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

[Nico Knoll]

Ehm,... the link between the 404 pages is correct right now, but... it shows the root 404 page...

[Oliver]

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.

[Nico Knoll]

Ok, I tried a bit around:

- If I put a var_dump() into the function "getErrorPage" it won't appear.

- If I go to the original function to look what it receives I can only see that that this is "NULL"

- If I try to var_dump() "$language" on the 404 page i get "NULL"

It's like the hook won't work...