Message of the day:
Welcome to SilverStripe | Current stable: https://goo.gl/C4F1T9 | Feature requests: https://goo.gl/EcQ34L | Community Forum: https://forum.silverstripe.org | StripeCon EU 2019! https://stripecon.eu
If you have any SilverStripe related questions, please supply the version of Framework you're using.
Did you flush? 🚽 =
will be even faster than someone updating the channel topic 😉
How do you guys handle widgets with multiple locales, i.e. having a page with multiple locales that may or may not each need a similar widget but translated to that locale?
That's a really good question, that isn't restricted to just widgets.
Projects with pages that have has_xxx relations to
DataObject subclasses that should also be translated, but obviously only where translations exist.
tl;dr - talk to your client. What are their expectations? Will they be able to provide translations for everything (assuming they're the content editor). This isn't a 100% technological fix.
Indeed they are the content editor. I believe that pages utilising widgets have translations for each locale.
The thing I'm trying to figure out is how exactly translatable fields work on widgets when added to a page via the Widgets tab. Setting DO fields to be translated then viewing the DO directly will enable defining content for the current locale. With widgets attached to page that have translated fields defined however, content for the widget fields with be constant through multiple locales.
I'm still not 100% sure what the actual problem you're having is. While I've not worked with widgets before, they're just dataobjects, so you'll have all the same problems any other DO has, when it comes to the available translations on the widget itself, compared to say a subset of those on its parent page (or indeed, vice versa)
I had some success on a project using tractorcow/silverstripe-fluent, using SilverStripe's ORM to "subvert" the
DataObject::get() results, depending on a given variable or parameter. We made decent use of
DataList::alterDataQuery() from memory
dont most of the translatable stuff rely on a yml of x,y,z for a? or am i still in the past 😄
having cmsable "content" translatable sounds like you would be better off translating on the fly (maybe an external service?) or having a cron to save multiple translations in the db