Allow translators to edit Admin->Setup->Laguages->$LANG

[maba]

Hi,

is there an easy way to allow translators to edit strings in our template files?

I know Admin->Setup->Languages->$LANG page where we can create blank template translation files and edit them, but:

- translator must have the right permission and it is not so easy (EN translator must be allowed to edit EN page only and we are under Admin page)

- (or) when admin creates blank files, download them and send it to translators, they haven't source string and/or ID

I could solve my problem (in this case) if I could create a page that call "Site Translation Files" input field (like Admin->Setup->Languages->$LANG) and allow translator to edit this page, like a shortcut.

Another way to solve this can be don't use __() methods but use a sort of placeholders (like $myTranslationsPage->myPlaceHolder) in template files and enable translators to edit /myTranslationsPage/.

Any suggestions? At the moment I have about 100 not translated strings and 4 translators for 6 languages.

Thanks,

Marco

[ryan]

Marco, it sounds like the built-in static translation process should provide everything you need except for the permissions aspect. Setup > Languages > [language] > Translate New File. Point it to any file in /site/templates/ and you should be able to translate it. Let me know if I've misunderstood? As for the permissions aspect (limiting a translator to just one language), I can add support for our new language permissions to this static translation engine on the dev branch once we get 2.7 out the door. If you need it before that, you should be able to block access with a hook. 

[maba]

Thanks Ryan.

Yes, built-in process provides everything and more (blank and replaced strings for example) and works well but how I can allow translator to use these pages? They haven’t an “Access” tab or similar to manage permission.

I tried editing Admin template (view for translator) and language template (view and edit for translator) but I not see the Admin page in the tree view.

I can wait for the “limitation” aspect for now but translator have to be allowed to use built-in process.

[ryan]

@maba I put in some updates yesterday (dev branch) that may provide what you are looking for. After installing the latest dev, click to Access > Permissions > Add New. Click the section to add a new predefined permission, and add the "lang-edit" permission. Then add that permission to the role(s) that you want to be able to access Languages (Setup > Languages). If you are using language page-edit permissions (like page-edit-lang-default, page-edit-lang-es, etc.) then the user will also need to have the appropriate language page-edit permission in order to edit translation files for a given language. Please let me know how it works for you. 

[maba]

Thanks Ryan, this is grandioso!

I saw the commit this morning and I tried immediately.

Only one problem.. I think that permissions are ok but.. translator now see Setup->Languages menu but when they choose one language they not see Site translation file and Core Translation File fieldtype. And "edit" permission is not listed in permissions list (see image): in this case translator has "view, edit, create" and translator-es has "view, edit" (only for test).

[maba]

Another little think: translators cannot edit any page.

There is no 'edit' action shortcut in tree view and if I try 

http://domain.it/cp/page/edit/?id=ID

I got 'The process returned no content.'. With the warning 'You don't have access to edit'.

[ryan]

@maba turn off access control for the language template, as I think it may be interfering with the lang-edit permission. Next make sure that the appropriate roles have the permission "lang-edit" (which I think would include all of your translator roles?). They should also have "page-edit" permission in their role, but that role doesn't need to be assigned to the language template because the lang-edit role is superseding it. 

I also recommend using language page-edit permissions if you aren't already. Meaning, your main "translator-de" role should have page-edit-lang-de permission, your "translator-ru" role should have page-edit-lang-ru permission, and so on. If your "translator" role is the one that can edit default language, then it should have page-edit-lang-default permission. I also recommend assigning your translator roles page-edit-lang-none permission, so that they can edit non-multi-language fields, such as the site/core translation files. 

Also, don't rely on the "who an access this page" fieldset on the settings tab for this particular case because the lang-edit permission is superseding the existing access control (for language template only). This is similar to the user-admin permission. You'll want to test by logging in with one of the translator accounts. 

[maba]

Thanks for your support.

Ok, with page-edit-lang-none permission translator can see site/core translator files fields. But in this way they will see also non-multi-language fields in other pages right? Mmm..

Yes, every translator role has page-edit and page-edit-XY permissions but the edit problem is still here. Probably I have made some error in my previous tests if you cannot duplicate the behavior.

[maba]

Hi, the edit problem is tied to page-publish permission.

I added this standard permission and not give it to the translator role (so, with page-hide, translator cannot hide on unpub pages), after that they cannot edit pages anymore. Probably is intentional but is it necessary with the new permissions?

Other request: make site/core translation files fields as multi-language-field so they are editable also without page-edit-lang-none permission. 

Thanks

[LostKobrakai]

Other request: make site/core translation files fields as multi-language-field so they are editable also without page-edit-lang-none permission. 

Multilanguage field would mean you can supply mutliple translations to a single language, that's certainly not how it's supposed to work.

[maba]

Yes, I know and you are right. (my) Bad english not helps me.

'as' means that I would edit site/core translation field without the page-edit-lang-none permission applied. If a role has lang-edit, it must be allowed to edit site/core translation files in my opinion.

Ryan helps me a lot even if 2.7 is in rc1, I know that he not wants add too many changes before 2.7 final. 

[ryan]

Hi, the edit problem is tied to page-publish permission.

I added this standard permission and not give it to the translator role (so, with page-hide, translator cannot hide on unpub pages), after that they cannot edit pages anymore. Probably is intentional but is it necessary with the new permissions?

If page-publish permission is installed, it is required in order to edit already-published pages. I suppose we could override that for Language pages if the user has lang-edit permission, but not sure we should, will have to think about that one more. However, if you want to provide that behavior for your site, you could do so with a hook in your /site/ready.php file:

wire()->addHookAfter('Page::editable', function($e) {
  if($e->object->template == 'language' && $e->user->hasPermission('lang-edit')) $e->return = true;
}); 

If a role has lang-edit, it must be allowed to edit site/core translation files in my opinion.

I agree, I have committed a slight modification that enable this (now on dev). 

Ryan helps me a lot even if 2.7 is in rc1, I know that he not wants add too many changes before 2.7 final. 

These changes are minor enough and restricted to one permission (lang-edit) that it doesn't affect anything else, so it's fine. 

[maba]

I agree, I have committed a slight modification that enable this (now on dev). 

Perfect, it works.

No hook required (read below).

These changes are minor enough and restricted to one permission (lang-edit) that it doesn't affect anything else, so it's fine. 

 

I suppose we could override that for Language pages if the user has lang-edit permission, but not sure we should, will have to think about that one more. However, if you want to provide that behavior for your site, you could do so with a hook in your /site/ready.php file:

The "problem" is not for Language pages but for all other pages (template):

- with page-publish not installed translator can edit pages (e.g. Contact page) and unpub them

- with page-publish installed translator cannot edit pages (no action in tree menu, ecc - even with "contact" template edit page permission)

- with page-publish installed and enabled for the role, translator can edit pages and unpub them

- wanted behavior: with page-publish installed and not enabled for the translator role, translator can edit pages but not unpub them.. is it possible? Make sense in your opinion? Some wrong setting in my installation?

In any case I tried your hook and there is an issue for me: translator can edit also Language pages that are not assigned to him.

[ryan]

- with page-publish not installed translator can edit pages (e.g. Contact page) and unpub them

Correct, if you've given them edit access those templates.

- with page-publish installed translator cannot edit pages (no action in tree menu, ecc - even with "contact" template edit page permission)

With page-publish installed, that means the user must have that permission to publish any content to the live site. Editing an already published page enables one to publish live content. So that means they can't edit an already published page. That behavior is correct. On the other hand, they would be able to edit unpublished pages (or create them, if you've allowed that). 

 

- with page-publish installed and enabled for the role, translator can edit pages and unpub them

Correct. 

 

- wanted behavior: with page-publish installed and not enabled for the translator role, translator can edit pages but not unpub them.. is it possible? 

That's what you'd want the hook for. Alternatively you could add page-publish permission for that role just to the "language" template from the Access tab of the template editor (see "Additional edit permissions and overrides"). But since you aren't otherwise managing access for the language template, I would suggest just using the hook function as the best solution. 

 

In any case I tried your hook and there is an issue for me: translator can edit also Language pages that are not assigned to him.

In that case, you'd want to modify the hook function to consider the language page-edit permissions:

wire()->addHookAfter('Page::editable', function($e) {
  $page = $event->object;
  $user = $event->user; 
  if($page->template == 'language' && $user->hasPermission('lang-edit')) {
    if($user->hasPermission("page-edit-lang-$page->name")) $e->return = true;
  }
}); 

[maba]

That's what you'd want the hook for. Alternatively you could add page-publish permission for that role just to the "language" template from the Access tab of the template editor (see "Additional edit permissions and overrides"). But since you aren't otherwise managing access for the language template, I would suggest just using the hook function as the best solution. 

Ok, I have some problems to understand that because in my test it doesn't work but I have understand the logic.