Hi, Is there a solution to this issue now, how can we make the xblocks template files check its own translation files rather than looking into edx-platform translation files?
On Thursday, March 26, 2015 at 1:25:26 AM UTC+5, Calen Pennington wrote: > > That's an interesting point around overriding the templates than an XBlock > uses. By way of analogy, Django has templates included in apps, but allows > the project to override those templates. I'll have to think about that. It > may be worth forcing XBlock authors to use a single templating system to > allow that sort of override. > > There's a longer arc around XBlocks where we'll be pulling them out and > running them out-of-process (and thus, out-of-virtualenv), to allow us to > be more flexible with allowing course authors to upload/deploy their own > XBlocks with less concern about them clashing with each other. But how > close that is... that's a bit harder to say. > > -Cale > > On Wed, Mar 25, 2015 at 3:26 PM, Eugene Medvedev <[email protected] > <javascript:>> wrote: > >> On Wednesday, 25 March 2015 14:52:38 UTC+3, Calen Pennington wrote: >> >> I don't think that a templating service gives you more flexibility to >>> override styles than having the runtime modify the returned Fragment does. >>> How would you envision the actual style overrides/injections working, if we >>> did have a templating service? >>> >> >> A templating service would be the natural place to apply any >> modifications, possibly even before a template is rendered, rather than >> after, which I'd think would be more flexible. You could actually override >> the template files themselves, for one. >> >> Though to be honest, I'm not sure, "theming" tends to mean very different >> things in different contexts, and while in some environments a theme >> encompasses most of the frontend, including the entire template, in others >> it's just replacing styles and in yet others it's only injecting colors. >> Where does, in fact, edX want to be on this scale, considering how much of >> it is javascript and won't work without? While the existing theming options >> lean towards the front of that scale, I can tell you that for me theming is >> my primary method of hacking the way edX actually works *(Many of my >> tickets consist of "disable this feature immediately!", for some, the >> quickest way to do it is hacking it out of the template, and theming saves >> me from having to touch the platform itself.)* so I naturally apply this >> thinking to XBlocks as well, when it's probably not the way to go for >> everyone else. >> >> And for that matter, just how many batteries should be included in the >> XBlock runtime? Considering that it has to share it's virtualenv with >> everything else in edX, I'd say it's better to include more rather than >> less, before some XBlock decides to require version A of package B while >> another one requires version C, but I'm probably not aware of the entire >> logic behind XBlocks. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "General Open edX discussion" group. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/edx-code/a2a028e6-fda5-43e9-a435-0f2b9d388eea%40googlegroups.com >> >> <https://groups.google.com/d/msgid/edx-code/a2a028e6-fda5-43e9-a435-0f2b9d388eea%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > > -- You received this message because you are subscribed to the Google Groups "General Open edX discussion" group. To view this discussion on the web visit https://groups.google.com/d/msgid/edx-code/6b7de7e2-71da-48ba-9f27-e0f4e78cc68c%40googlegroups.com.
