Role to save only the fields with custom string in their name?

[seddass]

Hello all,

I have a multi-language site with a separate fields for each language. They are named like "title_en", "title_fr".

I have to give access to external translation agency that will translate the site. I would like to restrict their user to save changes only in the fields ending with some language string (i.e. "_es", "_fr", "_de"). In other words... I would like to allow the translators to save changes only in the fields "title_fr", "headline_fr" and not in fields like "title_en", images.

I am not sure which is the best way. I am thinking that if in a hookBeforeSave I check the field names and change their "changed" state to not changed depending on their fields names. Is it possible? Has anybody have a better idea?

Thanks in advance.

[Pete]

I think a better way would be to write a module that hooks into the template itself and simply makes all the fields that aren't in their language hidden, then hide the surrounding DIV so the label and input fields don't show.

Of course, I'm not sure how to do that

[seddass]

Cool. Like the great ideas.  8)

But there is something important.. the translators should read from the "hidden" fields and to write the translated texts in to the other fields.

I was searching a server side solution.

[ryan]

We are already prepared for field-level access control in PW (for those that want it), so that will be coming at some point. But in your case, you are wanting to do something fairly custom to the point where I'm not sure you'd want to use the existing ProcessPageEdit. If I'm understanding correctly, that is to display a field in two (or more languages), but only make one of the languages editable. Short of a capability like this coming from a module in the future, this may be a good case where you want to create your own custom template to provide exactly the editing function you need. That's what I usually do... it's a quick and easy way to get something specific. Down the road when PW has full multi-language support and field-level access control, PW will be able to do this on it's own.

[seddass]

I dont think it is fairly custom as actually I was trying to limit the site translators permissions to save only the fields related to their language. Field level access control will be great and will do the job well. I will be glad to help with testing or whatever I could.

Something else jump into my head... for future multi-language PW releases.. I am wandering if assigning the fields to specific language will be useful in fields edit, output or even permissions.

Thank you, Ryan!

[ryan]

I dont think it is fairly custom as actually I was trying to limit the site translators permissions to save only the fields related to their language.

For a system that doesn't yet have multi-language support, this sounds fairly custom to me. But my experience with multi language sites is so far limited to just talking about it in this forum.

I am wandering if assigning the fields to specific language will be useful in fields edit, output or even permissions.

I'm not sure that I understand 100% what you mean, though I do get part of it. I'd always like to keep PW as simple and open-ended as possible. I'm wary of forcing people into one approach or another, or dedicating all resources to a specific approach. We need some multi-language support in fields themselves specifically for the admin-side of things. But this isn't necessarily ideal on the front end where a multi-tree approach is more of a best practice (especially when it comes to search engine indexing, bookmarking, linking, etc.). So my hope is to ensure that the system if flexible enough to adapt and let the developer determine the best approach for their site. I'm excited about what LorGG is developing as it sounds like it streamlines the multi-tree approach.

[seddass]

Ryan, you're right, no doubt. Thanks for pointing me to the LorGG's multi-language solution, which seems to be very promising.

[Soma]

The approach of having the languages in one page with multiple fields, can be nice as it's all in one place but to work well it requires some things to be considered and it might not as flexible as with separate tree approach.

Concerning the urls for search engines in the field approach, I don't know how easy it would be to have PW use a "name" field for each language separate. So for a german page it would have "/firma/ueber-uns/" as the path, while english it would take the english names and result in "/company/about-us/"  for the same page. To have PW and in template know which language is currently viewed, there would have to be some url segment defined that is used like domain.com/en/... or optional have subdomains. en.domain.com.

At work we often need to create multi-language websites, and there's always some sort of restrictions, problems, workarounds needed depending on system and which approach is chosen. So if there will be some strong and flexible core support for building multilingual sites, it would be a great selling argument as almost all other opensource systems lack good implementation.