New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

String translations for non-admins #20

Closed
JoryHogeveen opened this Issue Jun 13, 2016 · 20 comments

Comments

Projects
None yet
7 participants
@JoryHogeveen
Copy link
Contributor

JoryHogeveen commented Jun 13, 2016

Is it possible to allow other roles to access String translations only? Maybe a custom permission?

@Chouby

This comment has been minimized.

Copy link
Contributor

Chouby commented Jun 20, 2016

I am using the 'manage_options' capability because the strings translations are intended to translate options. Thus I believe that only users having this capability should have access to it.

@JoryHogeveen

This comment has been minimized.

Copy link
Contributor

JoryHogeveen commented Jun 20, 2016

Ah ok, I am also using them for front-end stuff like strings in a theme and widgets. My clients all have the editor role so they can't get to settings they could break but I'd like to allow them to translate these strings.
If you have any idea on how to accomplish this without the need of extra plugins or .mo files, please let me know.

@Chouby

This comment has been minimized.

Copy link
Contributor

Chouby commented Jun 20, 2016

Theme options and widgets should not be accessible to editors. Am I wrong?

@JoryHogeveen

This comment has been minimized.

Copy link
Contributor

JoryHogeveen commented Jun 20, 2016

You are correct but I change these and added the "edit_theme_options" cap to the editor role.
Thus I know this is not a default configuration :)

I'll close this issue because I guess it is out of the scope for your support but if you have an idea for a workaround, please let me know (maybe a filter for the capability??)

@diggy

This comment has been minimized.

Copy link
Contributor

diggy commented Jun 20, 2016

strings translations are intended to translate options

I think a lot of people (you know, those who don't read the docs) "abuse" the strings translations for translating strings in theme template files. Maybe the strings translations tab could benefit from a subtle warning with regard to this?

@Chouby

This comment has been minimized.

Copy link
Contributor

Chouby commented Jun 23, 2016

@JoryHogeveen Changing the capability level is already possible:

add_action( 'init', function() {
    if ( PLL_ADMIN ) {
        remove_action( 'admin_menu', array( PLL(), 'add_menus' ) );
        add_action( 'admin_menu', function() {
            add_submenu_page( 'options-general.php', $title = __( 'Languages', 'polylang' ), $title, 'edit_theme_options', 'mlang', array( PLL(), 'languages_page' ) );
        } );
    }
} );

But it impacts all the tabs, not only the 'strings translations', so that may not be what you want. Having a separate capability would probably require a structure change. Maybe, I would need to create a specific menu instead of using a submenu of settings.

@diggy If you are referring to https://wordpress.org/plugins/polylang-theme-strings/, it does not disturb me as we can consider that translating the theme requires the 'manage_options' capability. What's more disturbing is using this to translate content as NextGen Gallery does.

@JoryHogeveen

This comment has been minimized.

Copy link
Contributor

JoryHogeveen commented Jun 23, 2016

@Chouby Yes I thought of that solution but this indeed allows users to see all settings, not just the translations.
If I can find some time I will look into this. It's not a high priority issue, more a thought to enhance this functionality :)

@Chouby

This comment has been minimized.

Copy link
Contributor

Chouby commented Jun 29, 2016

I reopen this issue for the future.

@Chouby Chouby reopened this Jun 29, 2016

@Chouby Chouby added the enhancement label Jun 29, 2016

@Hito01

This comment has been minimized.

Copy link

Hito01 commented Jul 19, 2016

Hi,
What do you think about adding custom capabilities for Polylang ? It would be great to have a real control of what users can/cannot do with the plugin.

@JoryHogeveen

This comment has been minimized.

Copy link
Contributor

JoryHogeveen commented Jul 19, 2016

I'm all +1 for that!

@diggy

This comment has been minimized.

Copy link
Contributor

diggy commented Jul 20, 2016

FYI, I came across another theme strings translation addon: https://github.com/marcinkazmierski/Polylang---theme-translation

@Chouby Chouby added this to the 2.1 milestone Oct 25, 2016

@Chouby Chouby closed this in 2de3193 Nov 21, 2016

@Chouby

This comment has been minimized.

Copy link
Contributor

Chouby commented Nov 22, 2016

To clarify what I did in 2de3193:
I moved the Languages submenu on top. Former tabs are now submenus and thus have their own capability. I kept this capability as 'manage_options' for all submenus, including the strings translations.

So to allow non-administrators to edit translations, you normally just need to add your own menu with your own capability after you tested that the current user does not have the 'manage_options' capability. For example:

add_action( 'admin_menu', function() {
	if ( ! current_user_can( 'manage_options' ) ) {
		add_menu_page( __( 'Strings translations', 'polylang' ), __( 'Languages', 'polylang' ), 'edit_theme_options', 'mlang_strings', null , 'dashicons-translation' );
	}
} );

Edit: the code above is buggy. Here is the fix.

@JoryHogeveen

This comment has been minimized.

Copy link
Contributor

JoryHogeveen commented Nov 26, 2016

See PR #66, I think this is a easier way for dev's to do this. If you change anything in your code every dev will need to adjust this aswell. This way they don't need to.

@Hito01

This comment has been minimized.

Copy link

Hito01 commented Nov 28, 2016

@Chouby Hi, sorry but I'm not sure to understand how the change should work. I've added your action in my functions.php, it displays the item in the menu but when clicking on it I can't see the strings translation page. Should I do something else ? Thanks !

@Sprachprofi

This comment has been minimized.

Copy link

Sprachprofi commented Dec 23, 2016

Same here, this functionality will be priceless for my site!!

@Chouby

This comment has been minimized.

Copy link
Contributor

Chouby commented Dec 26, 2016

@Hito01 Yes you are right. I forgot the most important in this example! The link to the code to display the page :/

Here it is fixed:

add_action( 'admin_menu', function() {
	if ( ! current_user_can( 'manage_options' ) && function_exists( 'PLL' ) ) {
		add_menu_page( __( 'Strings translations', 'polylang' ), __( 'Languages', 'polylang' ), 'edit_theme_options', 'mlang_strings', array( PLL(), 'languages_page' ), 'dashicons-translation' );
	}
} );

In this example I give access to the strings translations to users having the 'edit_theme_options' capability. This has no effect with standard roles. So you need to choose the capability depending on how you customized the roles.

@swissspidy

This comment has been minimized.

Copy link

swissspidy commented Dec 28, 2016

@Chouby Have you thought about introducing separate capabilities for Polylang features like this? This allows for more fine-grained capability checks and one could assign these capabilities only to specific users. Happy to open an issue for this.

@Chouby

This comment has been minimized.

Copy link
Contributor

Chouby commented Dec 28, 2016

My intention is to go far beyond this. In the long term, I plan to create some capabilities for translators. That would mean that you could restrict edition of any content in a language to specific users. Of course I want the strings translations to be part of this feature. But as it would interact with a lot of existing capabilities, I need time to think to the best way to do this. That's why I did not change anything to the current capability to edit strings translations. I don't want to create something now that I could break in a future version because I would have made things too quickly without enough reflection.

@Chouby

This comment has been minimized.

Copy link
Contributor

Chouby commented Oct 12, 2018

Security is a serious thing. Unless you want to potentially harm 400,000+ sites (including yours), there is no point to publicly disclose plugins vulnerabilities. If you believe that you found a vulnerability in Polylang, you can report it by contacting us at https://polylang.pro/support/.

Even if you don’t know how to contact a plugin author, you can follow
this guideline: https://developer.wordpress.org/plugins/wordpress-org/plugin-security/reporting-plugin-security-issues/ where you’ll find a way to report the vulnerability to the WordPress plugins team. The team has the email of all plugins authors.

There is no need to patch Polylang to modify the capability. I already explained how to proceed in a previous comment #20 (comment)

@jvcdk

This comment has been minimized.

Copy link

jvcdk commented Oct 12, 2018

Thank you directing my attention again to your example code; I believe I tried it out before but could not get it to work. It did work this time, however, so I must have done something wrong. Sorry.

Regarding security; I deleted my comment (sounded like you thought that was the best idea) and posted a support request on your page. If you would like to receive security hints that way in the future, you might want to change your wording on your form. E.g.

"The technical support is available only to users having a valid license key. For our free products, please use the support forum on wordpress.org. "

does not encourage non-pro users to contact you this way. Also, if a user (like I just did) went ahead and used the "Other" category in your form, you require your visitors to check the box "This is not a technical support request" – though it kind of is (a technical support request). Or at least a heads up.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment