bfncs

Hm, this seems like a clean solution, because everyone can only watch the translations he's interested in and so on. On the other hand, if you have quite a lot of translations, the overhead for managing all the repos might be quite big. I'm not so sure, what will be the best way to do this to be honest.

Hm, so probably soft symlinks (ln -s) don't work but hard symlinks (ln) do? But I agree, it's not a big issue, just something to remember.

So for each module for each language another repository? Or one repository with all translations for one module, but separate from the module itself?

Thanks, but I already cleared the cache with no effect (only files related to ModuleManager in there either way). Then I changed /site/modules/FiledtypeCropImage/ from the symbolic link that it was to be the actual files and now it's working! And the scales felt from my eyes, too... For sure, a translation file called site--modules--fieldtypecropimage--fieldtypecropimage-module.json doesn't apply to a file physically stored somewhere else then /site/modules/FieldtypeCropimage/FieldtypeCropImage.module. Just didn't think about this thoroughly enough before. So, for everyone running into this problem, too: Don't try to translate a module that you just symbolically linked into the filesystem. It won't work! Thanks for all your help here!

Hey Soma, thanks a lot for testing! Hm, seems like the problem occurs somewhere else, but I have no idea where. There are no errors shown or anything... I'll keep on testing.

I just stumbled upon this topic by now and this is definitely something that I didn't find a convincing solution for in all CMS I've tried and would love to use (and also wouldn't mind paying for, if done right). The scenario you pointed out is what I believe to be the most common, having a two or three different instances of the site, local dev, probably staging and production and only wanting to work on the field/template schema data. Wouldn't it then be sufficient to have a tool to export your field/template schema data to a file and safely reimport them, so you can make it part of your version control? This should even be more secure than the idea of logging changes, which might be a problem if you have several developers working on local dev versions.

Thanks a lot for looking over it! That's exactly the same thing that I thought, but still I can't get it to work, it's a pity. There is no kind of super-special translation cache or anything like this, that I'm not aware of, is it? I'll set up a new PW instance to test this further...

I think I'd prefer to get the translations with the module. This will make it more easy to find the right place to contribute your translation to. Also, in the module management, there might be a function added at some point to look for translations inside the module directory and add them to a language you specify. What is definitely needed then is a convention for this.

Thanks for sharing your thoughts here, Soma! I haven't been using the multi-language system heavily, just read a lot and experimented with it, and I think all in all it's already a great solution, especially while it is still so young! The "tedious" was more targeted to the fact, that probably a lot of translations for modules are done over and over again, because currently there's no good way to share them with each other. I think the approach you took with the JSON files is something very usable, but I also agree, that it will need a more comfortable manager at some point - while this might prove to be sufficient for most needs. For me the most crucial point currently is to deliver a backend with one consistent language throughout the UI the editor sees, which means that I'll have to translate some modules here and there. I also read a lot about multilanguage in the frontend and the route you propose with YAML/PHP-vars sound really reasonable to me for small to medium-sized sites. So, in the end the two points at the end of your post is ultimately what I want to completely agree on.

Hi again, while just being occupied with Processwire's multi-language support, this question came to my mind: Is there already some mechanism established to deliver translations with a module? This seems like it can't work out of the box, because everyones language subtree will be different. But since it also would be impossible to pack translations for all modules in the official repo into the language packs, is there some mechanism for this? Or maybe at least some convention how to deliver translations then? The way I understand how it works now, everyone using a module is required to translate it for him-/herself, which is a bit tedious. With kind regards, Marc

Hi there, I worked on making apeisas great Thumbnail module translateable (I need a German translation of the UI), but can't really get it to work. I hope that someone here can give me a pointer in the right direction on this. This is what I did: 1. Installed the LanguageSupport module via ModuleManager. 2. Added the German language pack to the Default language. => Everything worked great until now, the backend is mostly translated. 3. Since a lot of strings in Thumbnail weren't translateable, I went through the code and added $this->_() and __() where needed (referring to how it is done with core modules). You can find this version here: https://github.com/boundaryfunctions/Thumbnails/tree/translateable This is the commit adding translatable function: https://github.com/boundaryfunctions/Thumbnails/commit/c3bcb8af480d91bc8ee7cfd4477aadeeab6a708e 4. Using the Language Translator in the backend, I added translation files for each of the three module files of Thumbnail to my default language. I uploaded all three translation files I created (not the best translations at this point, to be honest) here: https://gist.github.com/d41fe1e71791fccf5cc4 5. All of the things I translated aren't translated in the backend, I'm still displayed plain English. Any idea what I might have done wrong here? I really don't get it, because these steps worked perfectly for me until now. Any help is much appreciated. With kind regards, Marc

@tibs: Thanks a lot for pointing this out, I didn't see this before, but I think it's an elegant solution for an all-too-common problem and should work for a lot of use cases. It would definitely be worth the effort to develop this as a module of its own or integrate this into Thumbnail as an option, where you can choose which flavour of cropping you want for every field. Would be a lot of work though. @ryan: I'm completely aware that this is not coming into existence magically just because I want it. Just writing down my ideas here, and I hope to find the time for looking closer into this on my own. But I also wouldn't be offended if anyone likes the idea and gives it a try.

Exactly, to be honest I was more thinking about as groups and didn't even think of assigning more than one group to a user. Thanks to your explanation, I now got that it's more like distinct feature sets. Coming from MODX with its completely over-the-top-for-most-projects permission system, this is really a simple and smart solution.

Yes, exactly that does the trick! Thanks a lot four your help here soma, seems like I had some tomatoes on my eyes!

But if I give the permission to the role, they already have delete permission for all pages. I want to limit the delete permission to only some templates, independently from the edit permission.

Wow, sorry, you're totally right, I didn't reread through my inital post and missed the most crucial part of it So what I want to do in the end would be assigning delete permissions to groups on a per template basis.

Thanks for your quick answer, Soma° I just tried that: 1. Assigned a role without page delete permission to my user. 2. On a template I want them to be able to delete, I gave them edit permission in the template control. With the result, that there's still no delete button when editing a page with that template.

Hi everybody, I just ran into a quite pressing problem: I don't see a possiblity to allow a user group from deleting a page but grant them access to edit it. Did I look over something here or is there already a module to add this functionality that I didn't find? With kind regards, Marc Edit: Sorry, I missed the most crucial point in my initial question... What I want to do is grant a group permission to delete pages of one template but not another one: delete permissions on a per template basis. I still want to grant the edit right for templates, that can't be deleted. I hope this is more understandable now...

Hi Ryan, thanks for putting so much time into this! While definitely seeing the advantages of the CSS approach, I still want to go with the traditional style of image editing here (to keep bandwith usage low, etc). The solution you proposed is a handy workaround, but I'd still have the problem, that I'd be generating an image from a slightly bigger image while I have the original (with a possibly huge resolution) lying around unused which bothers me in a way, to I lose quality that might have been there. I still think, a great addition to the module would be to store the cropping metadata in the DB. This wouldn't only enable to recrop from already cropped images (without loosing quality) but also the case, where you want to change image sizes slightly after you have used the ImageCrop a lot already. Imagine you do a redesign of a page involving slightly resizing your thumbnails and/or changing the aspect ratio. This would involve then doing some quirky workaround with your old thumbnails, possibly involving a lot of unnecessary bandwith, because you don't want to loose the images you have cropped so far. With the crop data in the db, it would be a breeze to add some kind of batch processing to reprocess your images with the sections, you have manually chosen, from the originals.

Ryan, you're pretty right about everything you said there, but I just didn't make my use case clear: I don't want to support retina screens, but I want completely different version of an image while saving the same clipping. What I want is for example let the user crop an image to 400x300 with the CropImage-Inputfield and use this image somewhere (i.e. as a preview in article overviews) as it is. At another place I want the same image sized to 200x100. Everything's different about this, the size and the aspect ratio. I don't want my user to crop to this size on his own (because that might get a lot of different versions of an image for a large site) and I just assume, that what is in the 400x300 version is the most important part of the image and will work in the smaller dimension, too. So I want to zoomcrop my 200x100 version from the center of the 400x300 version, but not working with that image again but with the original image to get the best quality. I hope this is more understandable now

Hi Ryan, thanks for your answer. I think you're pretty right for a lot of use cases, but this doesn't serve my use case here. I think I didn't make it clear enough that I don't only want to crop but zoomcrop, cropping of the larger dimension so that after zooming the smaller dimension fits. Also I want to use these different versions of the image on different pages (overviews, recommendations to other pages, etc). I still might scale browserside with an <img> tag resized with CSS, but this isn't a good practice, the resizing of older browser is quite bad and it will limit me to an aspect ratio. For the project I'm working on now, I'm just going to add another image variant in the CropImage field settings. This is a little less comfort, but since this won't be used too much either way, I can't afford to spent the time to rewrite the CropImage module to serve my needs. I'll definitely come back to this, because I think that I'd still want to see this in the module. Thanks for all your help so far, Marc

Thanks for your quick answer, Anttii! I can really understand that this doesn't fit in there too well. Still I'm wondering how to do it, too. One option would be to define addional sizes that inherit proportions and section from another size in the field settings already: thumbnail, 150, 100 thumbnailvariant, 100, 100, thumbnail 'thumnailvariant' would then not be shown when editing the field and might be generated right after 'thumbnail' is generated. This wouldn't enable to get arbitrary sized images, but should be relatively easy to accomplish and would definitely fit my needs at the moment. To enable this, it would be necessary to store the data from jCrop (x and y coordinates, width and height) in it's own table in the DB to do custom crops based on that data later. This variant sounds like a lot of work but also would be a great basis for a lot of other features that might come later (i.e. being able to change the proportions of certain image sizes without losing all custom crops already done by batch processing existing images). I'll definitely wrap my head around this, might take some time though.

Thanks a lot for this great module, this really makes image handling in Processwire a breeze. That said, I'm looking for a quite specific feature that seems to be hard to accomplish with the current module. I'd like to recrop a given image with the same visible section as a given image version. Imagine I have an image version for crop image set up to be 150x100. Then I need a version of that image in 100x100, but cropping from the section that was selected for the 150x100 version. The new image should be generated from the originally uploaded one to not run into more issues with quality, for sure. Does anyone see a way how this might be possible already? And can this be integrated in the module? I'm imagining something like $page->myImage->getThumb('sizename', 100, 100); With kind regards, Marc

Thanks a lot for sharing your thoughts on this, it's always great to get some feedback! Thanks for the interesting link, but I don't really get the point here. Looking at the post where he argues for it, the only "argument" I see there is this: Sorry, I may be ignorant when it comes to SEO, but I have a strong feeling that apart from choosing your keywords wisely, having your markup structured well, using pretty URLs, avoiding duplicate content and aiming for good links back to your site, there's not much more to say about it. Everything else (and what de Valk says there) is more on the quackish and esoteric side in my opinion. Seeking the black cat in the dark room. Please don't feel offended, if you have other thoughts about this. Why I'm interested in this is because of these reasons: Make it easier to port Wordpress sites that have grown out of their "just a blog"-state. As thistimj pointed out above, this might motivate some more Wordpress users to tinker with Pw. The URL structure with dates may not be perfect for everything, but if you literally have a blog/news section it offers a really nice way to offer your post archives easily. Imagine /blog is the overview of all your posts, /blog/2012/ are all posts of 2012, /blog/2012/12/ are all posts in decembre of that year (adding a canonical tag pointing to /blog for the latter two to not make Google punish you for duplicate content, for sure). This would make sense to me and is just something nice to have. Building a good reference implementation for custom routing. Showing the flexibility of Processwire. I already saw some questions like "how can I get the category in the URL but not in the tree", so custom routing in general seems to be a common need. In what I'm imaginating, routing paramters wouldn't be limited to the "Structured tags" that Wordpress offers by default, but should be extended to all the input fields you have for a template, making most kinds of custom routing available with minimized tinkering with code. I'll try to build a module that brings some of the features mentioned here, hopefully get this done in the holidays (no promises though). I'm not currently looking for it, but I already feel, that there will be some customer, that is going to need this and also, I hope to get some better grasp of the core this way. Greetings, Marc

Hi there, I was just reading through the forum and anticipated, that I'll need something like this sooner or later, so I'm already asking: is there already some easy way to get Wordpress-style URLs (including the date) working for a subbranch of the tree? This should solve use cases like if i have a tree like this with the corresponding URLs: blog -> /blog my-article -> /blog/2012/12/24/my-article my-older-article -> /blog/2012/12/19/my-older-article ...and so on. It would also be nice to have options to format the URL with all the standard "Structure tags" the Wordpress has: year monthnum day hour minute second category author post_id postname I see that this is not too hard to do in your templates with URL segments but I'd prefer to have a handy module for this. Didn't have any time to really investigate into this already, just want to get some feedback on the idea: do you like/need this, is there already something solving this or a similiar featureset? Greetings, Marc