Problem/motivation:

Allow translators to translate every configuration, but don't give them access to the original config.

For example: A field is created with original translation en. The translators can translate the configuration in other languages, but unless they have manage field access they will not be able to edit the English label. We don't want to give translators access to the field settings because they can alter or delete the field.

Proposed solution:

Set the language for every configuration to zxx and allow config translation to be translated against the non-applicable language.

The patched attached removes the access restriction for locked language config translation.

Comments

Tom Robert created an issue. See original summary.

penyaskito’s picture

Issue tags: +D8MI, +language-config, +sprint

Tagging for awareness.

Kristen Pol’s picture

Title: Allow config translation against locked languages. » Allow config translation for locked languages
Issue summary: View changes

Remove gender-specific wording and minor formatting.

Kristen Pol’s picture

+++ b/core/modules/config_translation/src/Access/ConfigTranslationOverviewAccess.php
@@ -108,7 +108,7 @@ protected function doCheckAccess(AccountInterface $account, ConfigMapperInterfac
+      $source_language;

Do we even need the $source_language in the access check at all? The original code was allowing access for $source_language of NULL.

Gábor Hojtsy’s picture

Status: Needs review » Needs work

Set the language for every configuration to zxx and allow config translation to be translated against the non-applicable language.

This is currently not being done in the patch. How do you envision this working? What if someone wants to change the name of a View display? They go into editing the view, change the view display, but it does not happen because the "translation" (in the same language) still has a different label. Not sure that kind of workflow is ideal for core. Or you had something else in mind?

Tom Robert’s picture

The set Language is not included in the patch, since it is not the issue, this is an onConfigSave event to set the default language. But it can be allowed if the default language is a locked language. Now we are specifically denying access for locked languages.

If you want a translator to have access to the translations but no access to the view it self (so they can't break it). For consistency the view name is just a translatable label and the label displayed is managed by the configuration translations.

Source language is indeed not needed then.

Gábor Hojtsy’s picture

So what happens when your site changes the source view page title? Someone goes into edit the view (who has access), they change the view title and then nothing happens because the translation has something hardwired for the "same" language?

Tom Robert’s picture

Yes, labels and translations are split.
It will be consistent to treat each language the same. And if no translation is added the default label of the view will be used.

Gábor Hojtsy’s picture

All right, is it not a bug that you go edit the title of your Views page and then nothing changes?

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Gábor Hojtsy’s picture

Issue tags: -sprint

This is definitely not being actively worked on so removing from sprint.