Let's make multisite great again

[tao]

trafficstars

Multisite is something that needs a lot of love and care. I love Statamic but unfortunately it's creating a lot of difficulty for us on our large website with multiple translations.

Handling many languages is becoming necessary for us as the organisation grows. I hope this list can be a starting point for others to collaborate on ideas so we can make Statamic a great platform for large sites with multiple languages, and I'll add to this list with new comments if I come across other issues that are important to us. I would love to see this functionality developed more and given some attention so we don't have to migrate to another CMS.

I have compiled a list of issues I believe are important, and some that are causing issues on our production site. I know multisite has to accommodate many use-cases and these are more specific to translations, but if you have any multisite ideas or feedback on how these changes might impact your own use-case, please share.

1. Creating a new translation localises the slug and adds a date to the filename, even if the slug is locked on the blueprint. <sub>This results is URLs breaking and the editors can't fix it themselves. If I translate my /library page to French and visit /fr/library it won't work because the slug gets changed to /fr/bibliotheque automatically when the Page title changed from "Library" to "Bibliothèque". So even if the blueprints Slug field is set to non-localisable it still localises when the title updates. (#6284). Since I made the slug non-localisable in the blueprint to prevent it from changing, it means the editors can't fix it because the form field is disabled... when all I wanted was the slugs to be the same across languages.
   
   I also expect the translated filename to be collections/pages/fr/library.md but it becomes collections/pages/fr/2021-08-30-2208.bibliotheque.md with a date (#2296), even though the pages (or other collections) aren't dated. So I have to SSH into the server each time there's a new translation and rename the new files manually. We can make this issue better by adding generate: false in the blueprint for each collection, but then we have to manually enter the slugs for the main English site... however the translated filename still gets generated with a date.</sub>

2. The blueprint editor can't make the slug non-localizable _{If you click on the Localise icon (globe) and hit save, the file doesn't update. The blueprint.yaml file only saves it as localizable: false on the slug field. (#4471)}

3. The upcoming* multisite permissions system should work with the revisions workflow. _{We have a team of about 50 translators but not all of them understand markdown, we want to allow them to create translations and save revisions but only allow an Admin user to publish them after they have been reviewed and cleaned up. We also only want certain translators to see specific languages not all of them as it'll be too confusing. This is also a highly requested feature. (#2667)}

4. The control panel should support RTL languages. _{In this case, we need to support languages like Hebrew and Persian, and instead of updating the entire control panel for RTL support, only the forms in the tab-container need to have the direction reversed. We discussed this before and a second time but the issue was closed without actually solving the problem. This is a blocking issue and we can't add these languages to the website until RTL content is better supported.}

5. Better API support for fetching translations. _{I recently tried creating a Javascript widget to toggle between published translations for an entry, and found it very difficult to get them. They are available in the {{ locales }} tag but otherwise no options to get them through the API or GraphQL as far as I can tell. This is useful for displaying what translations exist and toggling between them. I tried writing my own custom tag too but ended up abandoning the widget and sticking to using the Antlers tag. I also had to write some custom tags to check with Antlers if a translation exists and is published for a specific language.}

6. Allow the global language-selector to be disabled _{This is more of a personal thing but some of our translators are old and easily confused, having two options to select the language (global selector) and on the entry sidebar could confuse them. Since they are translators, they all speak English so having a config option to remove the global option would make life a lot simpler. I could do this with some custom CSS but perhaps others would find it useful too. (#350)}

7. Sync fields are not updated (after editing origin) across sites without clearing the stache first _{If you create a new translation and save it, then go back and edit the English version, you will continue seeing the old changes on the translation even though the field is supposed to be in sync. Also if you make an edit to the English version, then create a new translation, it will show you the older unedited content in the sync field instead of the new updates. (#6714)}

8. Allow optional cross-site relationships in blueprints for Multisite. _{As a book publisher, we often want to create news articles in English (for example) with a link to the German books. Using the Entries relationship field in the Blueprint, there is no option for selecting the site in the Stack Selector modal. It would be nice to have an option to select entries from other languages as an advanced option. At the moment we have to manually update the entry yaml files. (#646)}

9. Translating Globals is complicated and time consuming _{To enable translations for a collection you just select the site from the dropdown field and it defaults to English as the fallback for empty values. With Globals you need to toggle each site with an On/Off switch and also select the Origin for each site, which can be very time consuming. It would also be nice to fallback to English... for example I keep my social media links in a Global set, if we forget to update this Global when we add a new language then the website doesn't fall back to the English origin so my facebook link just uses the current page URL. (#657)}

10. Add an option to select all sites at once when configuring a collection _{It can be annoying to select 20+ different sites from the dropdown when you make a new collection, an "all sites" button would be helpful. Even better would be an option to select "all sites" without having to update this list when you add a new translation, instead the new language would be automatically added to the list. Otherwise whenever we add a new language I have to manually update ~30 collections.}

11. Asset alt-text and descriptions can't be translated _{This seems like quite a tricky issue, but it would be nice to find an elegant way to translate these in the Control Panel. I believe a solution might be creating a relationship in the Asset blueprint which links to a collection that can be translated, but the idea still needs to be tested.}

12. Sidebar UI for selecting sites could be updated to better handle many sites _{When you start going above 20 sites the sidebar gets very long and goes off screen, and you have to scroll off-screen to see the slug fields or date pickers. The multisite list could be collapsed or adjusted to handle many languages better.}

13. Translation Workflows _{This is not an issue specifically, but a feature that becomes necessary when you have multiple translators working together. We're relying on the Statamic Revisions addon and some custom Dashboard widgets to compare updated_at timestamps and Revisions to create a review list before publishing. Hopefully when Statamic is updated with multi-site permissions it'll help us a lot with our workflow... so it would be nice to make sure the Revisions function acts as a useful stepping stone to a Translations workflow, which could be build upon more later.}

14. Dispatch events when working with translations _{I tried resolving some of these issues with custom event listeners, but it seems sometimes the $event->entry() is not passed to the event listener all the time when doing work on multisite. I may have made a mistake when working on this code... but in general a better events system for translations specifically could be used to hook into and improve the translations workflow mentioned previously.}