Make actions translatable

[off...@netwerkstatt.at]

Hi all,

an issue at the #SilverStripeEU conference last weekend was how to get actions translatable. I discussed it with Sam and some other devs and did now a quick demo of how it could work:

https://github.com/wernerkrauss/silverstripe-translatable-actions

It adds the actions prefixed to the lang files when running the textcollector task, adds the translated action names to $url_segment and translates outgoing links.

What do you think about it?

Cheers,

Werner (wmk)

[Sam Minnée]

So, to summarise the approach, you've set up "{controller}.action_{action}" as a string in the translations, and then hooked into that in the controller action processing. That makes sense to me (which is unsurprising, as it was in line with our previous discussion).

A few comments/tweaks, though:

 - Once we agree on an implementation, I think this should be implemented as a patch to the translatable module, and it shouldn't require a special controller. This was a good way to do a proof-of-concept, though.

 - I'm not sure if this action logic will work if you have some actions on a parent class and some on a child class.

 - It's not clear that the translated strings need to be URL fragments. I think this is okay, but should be make clear, and maybe the translation string name shouldn't start with "action_". Also, it's possible (a bit weird, but possible) that 2 URL fragments map to the same url fragment, so maybe the translation key should be based on a sanitised version of the url handler itself (e.g. remove '$' and replace '/' with '-').

 - A lot of actions are accessed by specifying a URL rule that includes an '$Action' variable, and points to the action '$Action' (or the deprecated 'handleAction'). Your system doesn't work with this, and it should. The way to do this would be to identify all the allowed_actions that don't relate to a special url handler. Or you could just list everything in allowed_actions.

Thanks,

Sam

[off...@netwerkstatt.at]

Hi Sam,

 

thanks for your reply. Yes, it was just a quick proof-of-concept hack which is not ready for production, and it should either be a controller extension or built in  basic  Controller class, not a separate controller.

 

IMHO it should not only be an extension to Translatable cause some of us also have non English single language sites. I18N and _t() works without translatable and in a long term every module should have the actions translatable, at least in the lang files.

 

The “problem” of translatable actions consists of two tasks: Incoming URLs (define translations in $url_handler) and outgoing URLs (translate the action string in every call to Link() method)

 

Translatable actions now work with actions defined in parent class, I’m always surprised how easy this is to achieve when digging around in Silverstripe’s source looking for methods that addressed a similar problem.

 

I extended the functionality to also generate “{controller}.urlhandler_{sanitised urlhandler}” for translating the edge cases where we may have already action aliases defined. I don’t know if this is really necessary as it opens a huge hole for destroying url handling in language files. Maybe we shouldn’t generate it automatically…

 

Do you think $ inside the translation key is a problem?

 

Outgoing URLs is another problem. How about a static method in controller to translate the action name?

 

Cheers,

 

Werner

 

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at http://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.