Does/can the plugin allow Entries to be translated to other Sites regardless of the Section's propagation setting?

[taylordaughtry]

The client I'm working with wants Entries that are only on a specific Site. However, the Translations plugin requires that a Section's propagation setting be set to ALL ("Save entries to all sites enabled for this section").

This means that anyone using the plugin can't have content that's unique to a Site.

Removing this limitation would mean that attempting to translate an Entry to a Site where its section isn't enabled would cause an error—but it'd be a relatively straightforward check to ensure the Section is enabled in the Site, and returning an error if it isn't.

Based on a quick review, reworking this area to not check the supported Sites for entry would be a 'step one', if you will:

craft-translations/src/controllers/BaseController.php

Lines 920 to 938 in 0f6308e

	if ($element instanceof Entry) {
	$supportedSites = array();
	foreach ($element->getSupportedSites() as $supportedSite) {
	$supportedSites[] = $supportedSite['siteId'];
	}
	$hasTargetSites = !array_diff($targetSites, $supportedSites);
	if (!$hasTargetSites) {
	$message = sprintf(
	Translations::$plugin->translator->translate('app', "The target site(s) selected are not available for the entry “%s”. Please check your settings in Settings > Sections > %s to change this entry's target sites."),
	$element->title,
	$element->section->name
	);
	Craft::$app->getSession()->setError($message);
	return;
	}

The other changes would include ensuring the Draft being created for each File is for the proper Site, and adding the check to ensure the Draft's Section is enabled for the Target Site.

[taylordaughtry]

@sidedwards This is now a blocker for some issues the client's currently having—

Since the plugin requires the ALL setting, reverting using a revision changes the content on all Sites, not just the one being currently viewed. (So they can't use revisions if they also want to use this plugin.)

[sidedwards]

@taylordaughtry

Propagation Methods, Entry Revisions, and Localization workflows

The following Section Propagation Methods are available:

1. Only save entries to the site they were created in (none)
2. Save entries to other sites in the same site group (siteGroup)
3. Save entries to other sites with the same language (language)
4. Save entries to all sites enabled for this section (all)
5. Let each entry choose which sites it should be saved to (custom)

The first option will not propagate Entries and is useful if pages and content structure will be different for each Site. Propagation methods two through five all propagate Entries to other Sites, but each have different advantages:

2. The siteGroup setting is useful if you want to limit Entry propagation to a specific group of Sites or target market (i.e. Latin America might be a Site group containing Sites/languages for that region)
3. The language setting is useful if you have multiple Sites with the same language and you want to make an Entry available across each.
4. The all setting is useful if all Entries for a Section should be available across all of your Sites.
5. The custom setting if you would like to use Entry propagation, but would also like to have Site-specific content.

Common issues with Entry Revisions

If you want to use Entry propagation (methods 2-5) in multi-site setups you can't use Revisions without also reverting the content and settings in the other enabled Sites [1], [3].

While it is technically possible to revert an Entry to a specific Revision without affecting the other Site content, it's not likely the required criteria would be met. To revert to a Revision without affecting other Sites, the selected Revision would need to already have the other Sites disabled.

Localization workflows

When using Entry propagation (methods 2-5), if you need to update content for a specific site without affecting the others, then we recommend creating a new draft and copying the revision content over. @brandonkelly eluded to a feature that would make this process easier [2].

If the content you want to revert to is "source content," then we could include a feature that would allow you to select a specific revision as the source for a translation order similar to Entry drafts.

For sections with Entry propagation disabled (method 1), we could in theory add support for ordering translations, but there are a few issues to consider:

• Entries would no longer have a default "fallback locale" and pages may return a 404 error if an Entry isn't available for a specific Site.
• Rather than creating a new draft for an existing Entry, we would need to create a new draft for a new Entry in the specified target Site. This means that the newly created "target" Entry would have no relation to the "source" Entry and the plugin would not be able to update the target Entry after the initial translation is completed.
  • This could result in duplicate Entries in target sites if multiple translation orders are applied causing a headache for content managers.
  • We could potentially create and store a "map" for source and target Entries, but if the plugin were uninstalled, these relations would be lost.
• Though Revisions would work per Site, it would make managing content and field layouts more tedious because any changes to content would need to be done individually per Entry/Site.
• Field localization settings would likely need to be modified to store blocks and content on a per-site basis to prevent issues with "globally" stored layouts and values.

🔗 References

1. Let each entry choose which sites it should be saved to - Issue with Revisions · Issue #9844 · craftcms/cms · GitHub
2. Revert revision per site · Discussion #8888 · craftcms/cms · GitHub
3. Draft "Update Entry" opaque behavior in multi site setup (Could lead to unexpected content changes) · Issue #4642 · craftcms/cms · GitHub