In the case of Tailor, as seen in the video, you can set a model to be not published in one locale, so the record doesn’t show / exists on that particular locale. But how do we replicate this in the case of non tailor models. Before multisite, for a translatable model you would just create a record and if you wouldn’t manually translate it for a locale, it would not be showed on that locale. But now, if you create a record, it exists in all locales, and you have to go “selecting” each field, clearing it and translate it (I have mixed feelings about this). But anyways, how do we control now the existence (or showing) of that record per locale / site? If you delete it from the controller list, you delete it for all locales.
In the previous translate plugin (1.x), translatable url parameters would be automatically detected in the |page filter when passing as argument. Now, in the non default locales it’s not working as before. I mean, if you have url set in a custom blog-post.htm file:
/posts/:url (for primary english locale/site)
/novedades/:url (for spanish locale/site)
being url a translatable field and in your theme (considering you get the ‘post’ record in your php block):
that works only for the primary locale, but for the other ones it replaces the slug with ‘default’ and it doesn’t work. I guess I’m doing something wrong or there’s something missing, but it would really be nice that this things behave as simply as before in this new way of doing localization.
I’d like to know how to do that now with the new version of Translate
I don’t think that is correct. Translate plugin always defaulted to the primary locale. To prevent that you had to use explicit conditions, like transWhereNoFallback. Which is still the case now.
But there are now also other options. Since any field can be translatable now (including checkboxes) you can easily make an “is_published” checkbox and make it indexable like this:
public $translatable = ['title', 'description', ['is_published', 'index' => true]];
Then by using a simple where condition, you can exclude unpublished records:
That’s great. Thank you. Now all works ok. I can also see that the new multilanguaje workflow is pretty powerful. I’m not absolutely sure about when should I index a translatable column? Is it when it will play a role in a query or url param?
Translatable columns should be indexed when they are used inside transWhere, transWhereNoFallback or transOrderBy clauses. In the background all non-indexed columns are stored as json, which is fast but impossible to query, while all indexed columns are stored individually, which enables querying.
This is great. I’m now understandig the workflow here. My concern is what to do in the case where there are already records in one language and we want to make that multilanguage… how to index the translatable fields on those pre-existing records
If the column was not translatable before, you can just add it to the $translatable array as an indexed column and it should work just fine. However if the column was translatable but not indexed, you should create a migration that will read and save every model in every language after you update your $translatable definition.
Can you confirm that ACTUALLY you can translate a checkbox / switch / or any boolean? I’ve tried it and it works with other field types, but not those. I’ve opened a question with this in: