Hi, I’d like to know if Tailor is going to work with the translate plugin. For all of the multilanguage sites I use the translate plugin and it would be a good idea to keep doing that.
I have read in another post that there’s native multisite ongoing, but for a lot of cases I think it might be overkill.
Out of the box, translation with Tailor happens with the multisite and child theme features. You could write a plugin to extend Tailor to use the Translate plugin, however, it won’t be necessary. The multisite feature should be compatible with the translate plugin.
Hi.
But multisite is still in development. Or am I wrong? Thank you.
The plugin you mention doing to add translate to Tailor, is it as easy as adding translatable trait to any other model? My concern is because about 50% of our site development requests are indeed multilingual. Our customers already manage translations using the translate plugin UI in the OC 1.x, they are used to that. As we plan to update everything to October 3, and for sure I’d like to levereage Tailor for a lot of things related to publishing content, I’m concerned about how to stay consistent in the UI. In my opinion it sounds ideal that they (my clients) continue to use the same logic.
We are also faced with the same dilemma. Currently about 75% of our projects are multilingual, so for that reason we decided against using Tailor in our projects for now. Even projects that are not multilingual from the start can later decide to add multiple languages and that would currently be impossible if we set up the site using Tailor.
Once the multisite feature becomes available we will of course re-evaluate our decision, but I have a suspicion that the translation system in the new multisite plugin will not be compatible with the current Translate plugin, which would make migrating our existing plugins and translations difficult.
Hi @daft
As I don’t know how the multisite will work, just to have some idea on what direction to take regarding tailor usage, Id like to ask this: Once the multisite is released, is it meant to replace the translate plugin for multilingual sites? With the translate plugin the client doesn’t have to publish a record for every language. It is just ONE record, and the UI to translate it to whatever language is created in the options. Will that be the case with multisite? Sorry if I’m confusing concepts here, but multilingual is so important and I can’t see yet that multisite can be an analogous feature or use case.
Multisite is a simple concept where you define a site, and it sets the application locale, timezone and theme based on the active site. This makes it theoretically backwards compatible with the translate plugin.
For example:
-
The translate plugin defines a locale and captures an active locale using a
localePicker. -
The multisite feature defines a site and captures an active site using a
sitePicker, which sets the locale.
In both cases, an application locale is being set, and the translate plugin will accept the locale set by the multisite feature.
Yes, multisite is currently in development on the roadmap: https://portal.octobercms.com/c/28-native-multi-site-support
Thanks for the explanation. I am still wondering how that will help with Tailor data translation? Will Tailor run migrations for each site individually and create separate tables for each language?
Each table already has a site_id that is used to constrain the records using a scope. Blueprints define the propagation preference. With the introduction of drafts, this propagation logic is already in place.
An example, a blog post category can be unique for each site or shared across all sites (blueprint-level). The same applies for the relationship between the post and the categories (field-level).
1 Like
Regarding my question, and not with Tailor but for any custom model, will it be possible to create it just once and have it available in all the sites and translate it all in the same screen for different languages / sites ?
Yes, this is the alternative approach to translation, and we will include something simple like this: to translate individual fields on a single model, per site or per locale (still considering). This is how the RainLab.Translate plugin works today, so there is no urgency on this requirement.
We should offer a migration path for plugins when they are deprecated by core features. For now, it’s just easier to be backwards compatible.
“This is how the RainLab.Translate plugin works today, so there is no urgency on this requirement.”
Yes, we could just keep using Translate (for now at least), but the concern in that scenario is how to use Tailor in a Translate Plugin driven website. Can we extend the $implement and $translatable properties on the tailor generated models to make them work with the translate plugin, just as with any regular created model?
You won’t need the Translate plugin for Tailor since all fields are translatable by default using multisite. Multisite works in the opposite direction, where you define fields you want to be propagated to all sites instead.
Sorry I just created a reply a couple of minutes ago, but cant’t see it posted. It said:
Then I have a question: Let’s make an example. Let’s say we have to make a website in three languages, that has a Blog created using Tailor, and also a custom model “Product” using Builder. Then my questions are:
- If the user has to publish a post in the blog, that has to be in the three languages (translated of course). Will he / she have to publish in three different steps / places? I mean, after he creates the post in the main language, will it still be necesary to publish in the other two languages? or how will it work?
- Will the translation managed by multisite feature work also in regular custom models? (in the example would be Product). If not, some translations will still be needed to be done using translate, and that would be heavily inconsistent UX/UI for the backend user.
- Is there an esimated date when the multisite feature will be available?
Thank you very much. I’ll really appretiate a detailed answer. I’m considering upgrading to the full potencial of OC3 for all upcoming projects (still working on 1.x), but the thing with multilanguage and having a consistent UX for the backend user in that field (in this case my clients) is crucial to our business.
1 Like
Don’t worry, the UX will be consistent, and the Translate plugin is not going anywhere.
When the blog post is first published, let’s say in English, it will be propagated to other languages in English, where it can then be translated. You won’t need to create three records manually, they will always be propagated from a “root record”.
The functionality is similar to the translate plugin, except there is a global site picker where the language is selected. The global site picker activates when more than one site/locale is defined. Here is a screengrab of the current progress:
Yes, you can decide how to translate plugins by site, locale, or both. In most cases, translation by locale is good enough for multilingual sites, as per the Translate plugin.
It will be released along with v3.1 (stable), and we are working hard to get it ready. We don’t have a fixed date for when it will be ready, hopefully, in the coming months.
2 Likes