[3:55pm] webchick: hey hey party people! [3:56pm] Bojhan: webchick: hola [3:57pm] GaborHojtsy: hey [3:57pm] Druplicon: salut [3:57pm] yoroy: hallo! [4:00pm] GaborHojtsy: hey, its about time to start the D8MI meeting if I've set the invite right [4:01pm] good_man: hey [4:01pm] Druplicon: hola [4:01pm] GaborHojtsy: I hope you all had plenty of time to read up the main discussions in the i18n group on g.d.o... in case, you need a higher level overview of the current overall plan, I've created a graph especially for you: https://docs.google.com/drawings/d/1EJWdw8A_EF-bXwwnB4e4KGBXLRLXjFndvY2tBVQIsfo/edit?hl=en_US [4:02pm] GaborHojtsy: ok, ok, this will be shared far and wide, but I think it serves as a great overview of the bigger plans [4:03pm] GaborHojtsy: there are smaller things like legions of people wanting to see admin_language module in core, but these are the main pieces [4:03pm] good_man: yeah nice graph [4:04pm] GaborHojtsy: I think our initiative is in a great position since we can basically work on lots of cool stuff while context and config gets into place, but those are the bigger problems (which I just put under config translation here) [4:05pm] GaborHojtsy: so we can push ahead on all except the red pieces right away [4:05pm] GaborHojtsy: any overall questions, comments, omissions? [4:06pm] OSInet joined the chat room. [4:06pm] GaborHojtsy: I'm pretty sure not all of the pieces should be self-evident [4:06pm] OSInet: Hi all [4:06pm] GaborHojtsy: OSInet: hi! [4:07pm] GaborHojtsy: OSInet: we are talking about https://docs.google.com/drawings/d/1EJWdw8A_EF-bXwwnB4e4KGBXLRLXjFndvY2tBVQIsfo/edit?hl=en_US [4:07pm] good_man: for translatable titles, what decisions to be made? [4:08pm] GaborHojtsy: good_man: it was briefly in core in Drupal 7, then got removed... the main problem is that people considered it is a developer experience nightmare as a field [4:09pm] GaborHojtsy: good_man: http://drupal.org/node/1188394 is our current issue http://drupal.org/node/571654 was the revert [4:09pm] Druplicon: http://drupal.org/node/1188394 => Make title behave as a field (again) => Drupal core, entity system, normal, active, 6 comments, 1 IRC mention [4:09pm] Druplicon: http://drupal.org/node/571654 => Revert node titles as fields => Drupal core, node system, normal, closed (fixed), 129 comments, 36 IRC mentions [4:09pm] good_man: GaborHojtsy: yes that's right, but Title module (AFAIK) solved this nightmare, what's left? [4:09pm] GaborHojtsy: plach also explained he does not think that title module as-is is good for inclusion, although it needs to work around stuff in core, so it would be different in core [4:09pm] good_man: GaborHojtsy: ah the field thing again! [4:09pm] OSInet: the main problem I had with that at the time was the the "title" is essentially an admin element which doubles as a default end-user title. decoupling the two roles limits the need for i18n on title [4:09pm] GaborHojtsy: good_man: well, it needs to be a core feature definitely [4:10pm] good_man: GaborHojtsy: so this bold decision (title as field) will affect not just translation, but nearly all Drupal, right? [4:10pm] • sun looks at the chart [4:10pm] GaborHojtsy: OSInet: you mean have a separate label field for admin purposes and a custom title field you can use on the front end? [4:10pm] GaborHojtsy: good_man: yes [4:11pm] OSInet: exactly: on largeish sites I've had to work, this has happened every time, as the intrinsic limitations on the title field are usually unacceptable for actual titles (HTML entities, formatting...) [4:11pm] GaborHojtsy: good_man: having a simple text title for objects is very typical, used for listings, links, etc. [4:11pm] OSInet: but they are just fine the the back-office/admin UI [4:12pm] • plach catching up [4:12pm] sun: mayhaps not large enough of a task package, but is a stub no-op t() considered/contained in any of these action items? [4:13pm] GaborHojtsy: sun: not yet, but it would be great for some things definitely you can file an issue with the D8MI tag or just tag the/an existing issue with that [4:13pm] GaborHojtsy: sun: there is an issue to move the formatting part of t() to its own function [4:13pm] GaborHojtsy: sun: as well, which is kind of related [4:13pm] sun: i.e., t_without_locale('Some string to export but don't localize right here'); [4:14pm] GaborHojtsy: http://drupal.org/node/1191614 [4:14pm] Druplicon: http://drupal.org/node/1191614 => Make t() formatter available as its own function => Drupal core, base system, normal, needs review, 9 comments, 2 IRC mentions [4:14pm] GaborHojtsy: sun: how'd you do that for format_plural and friends? [4:14pm] sun: mmm, that's actually a different feature [4:15pm] good_man: sun: I'm not following, but why using t() without locale? [4:15pm] plach: GaborHojtsy: do we have an agenda? [4:16pm] sun: GaborHojtsy: same function. The idea is to simly have a stub for cases in which you are not able to pass a string literal to t(), but you have code like t($var) or format_plural($count, $var). The string in $var is still localized, because it has been exported through the no-op. [4:16pm] GaborHojtsy: plach: the plan was to start off with getting on the same page with the bigger plan, so far we are drifting out to two topics, title fields and no-op-t [4:17pm] GaborHojtsy: sun: ok, I've heard the idea often before, sounds good, an issue would be great to flesh it out not sure its a "big piece" in the puzzle [4:17pm] GaborHojtsy: any other bigger items people think we are missing? [4:17pm] plach: GaborHojtsy: yeah, I'm n'sync now, pretty onboard with the graph [4:17pm] GaborHojtsy: plach: cool [4:18pm] sun: I think we need to consider a bigger piece of multilingual fields API clean-up [4:18pm] sun: too many people are getting confused by 'und' and how to work with multilingual fields [4:18pm] good_man: GaborHojtsy: is direction (i.e. content language) appropriate as an i18n topic? [4:19pm] plach: sun: are you suggesting some kind of evangelizing in D7 or improving DX for D8? [4:19pm] sun: plach: the latter, better DX for D8 [4:20pm] sun: no idea how though [4:20pm] sun: all I know is that we've introduced a serious amount of confusion [4:20pm] GaborHojtsy: sun: plach: I think maybe we can do more docs/evangelizing, when you write docs, you usually find ways to improve what you are documenting, at least in my experience [4:20pm] GaborHojtsy: good_man: where do you see that missing? [4:21pm] good_man: hmmm anyone has expiernce from other systems/PLs on how they deal with i18n stuff, maybe we can find something useful [4:21pm] sun: mayhaps... the situation might improve if $entity->field_foo would no longer be an arbitrary, anonymous array, but a well defined field object instead. [4:21pm] plach: sun: I ain't sure it's already the moment to address this, but IMO that's how it should work in D8: $entity->body($language = NULL) [if $language = NULL then us a default] [4:21pm] OSInet: i see nothing about contexts [4:22pm] OSInet: i.e. the ability to have the same source string have different translations depending on context [4:22pm] good_man: GaborHojtsy: http://drupal.org/node/780508 and I've worked on something similar in http://drupal.org/project/language_switcher (still buggy) [4:22pm] plach: GaborHojtsy: well, there's that i18n gate stuff pending [4:22pm] Druplicon: http://drupal.org/node/780508 => Set language by content language for LTR/RTL display => Drupal core, language system, normal, active, 8 comments, 1 IRC mention [4:22pm] plach: GaborHojtsy: I already thought we could mention there which is the correct way to use TF [4:22pm] GaborHojtsy: OSInet: beyond what Drupal 7 supports for contexts? [4:23pm] OSInet: not necessarily, but it does not appear in this overall view [4:23pm] sun: hence, unfamiliar coders could simply do $entity->field_foo->getValues(), getting the right values for 99% of all cases, without having to care for the confusing data that's in there [4:24pm] GaborHojtsy: OSInet: currently I'm considering that educational rather than something we need to rework, since we'll have the majority of our work in intgrating what we have in contrib for several things and redoing translation for config from the ground up [4:24pm] webchick: So this is kind of getting into the weeds a bit. Maybe everyone here is already super familiar with the underlying issues that https://docs.google.com/a/acquia.com/drawings/d/1EJWdw8A_EF-bXwwnB4e4KGBXLRLXjFndvY2tBVQIsfo/edit?hl=en_US is talking about, but for benefit of those who aren't (like me!) GaborHojtsy would it be possible to provide a high-level overview of the i18n initiative, the goals, how we know if we've succeeded, next step [4:25pm] GaborHojtsy: sun: yes, I agree making fields real objects would be great, it has multilingual implications, but its not really a "multilingual" piece is it? [4:25pm] sun: doesn't necessarily require field_foo to be a real class/object. We could use an ArrayObject. See example: http://drupal.org/node/402896 [4:25pm] Druplicon: http://drupal.org/node/402896 => drupal_get_schema() wastes 1-3mb of memory for nearly every request => Drupal core, base system, major, reviewed & tested by the community, 117 comments, 26 IRC mentions [4:25pm] webchick: Just a quickie 3-minute thing. I don't want to break up good discussion. [4:25pm] OSInet: ok [4:25pm] good_man: GaborHojtsy: something related to context, is there anyway in D7 to determine where the string came from? this is very helpful in translating UI [4:25pm] GaborHojtsy: good_man: yes, if it provides context [4:26pm] GaborHojtsy: webchick: ok, I'm glad you asked quick overview: [4:26pm] sun: good_man: that's one big epic discussion, and it would require someone to take that on + do massive moderation [4:26pm] good_man: GaborHojtsy: I see, didn't got into context that much, need to re-read your posts in your blog's series [4:27pm] GaborHojtsy: D7 has basically three/four pieces to translate (node, entity), UI text, variables and other arbitrary configuration [4:27pm] good_man: sun: what issue? the context or content language and direction? [4:27pm] ngnp joined the chat room. [4:27pm] sun: good_man: context [4:28pm] GaborHojtsy: node and entitiy have both a relational translation model and an in-object translation model, UI text, variables and other config mostly have in-object translation (eg. you can translate your contact form pieces) [4:28pm] good_man: sun: do you have anylinks? [4:28pm] tsvenson joined the chat room. [4:28pm] DamZ joined the chat room. [4:28pm] iStryker joined the chat room. [4:29pm] DamZ: plop [4:29pm] GaborHojtsy: we should (a) expand on the relational model to cover more items (b) expand on the in-object translation to have more things fields, like title and have a (c) UI for them to be translated, (d) simplify the UI translation flow and make it reusable and hookable (e) unify config translation that is now split for variables and other config and make it use "field-like" constructs [4:29pm] webchick: DamZ: heya, catching you up... [4:29pm] sun: good_man: http://groups.drupal.org/node/154394 [4:29pm] Druplicon: http://groups.drupal.org/node/154394 => Move interface strings entirely out of Drupal code files? => 92 comments, 4 IRC mentions [4:29pm] webchick: DamZ: https://docs.google.com/a/acquia.com/drawings/d/1EJWdw8A_EF-bXwwnB4e4KGBXLRLXjFndvY2tBVQIsfo/edit?hl=en_US is the overview of the i18n initiative. GaborHojtsy is walking us through it atm. [4:29pm] GaborHojtsy: I've written posts on most of these in detail on the i18n group [4:30pm] DamZ: killing the i18n module is one of my pet projects [4:30pm] GaborHojtsy: DamZ: awesome to hear [4:30pm] DamZ: and I'm sad that the D7 version had to be resurrected [4:30pm] Janusman joined the chat room. [4:31pm] • sun too [4:31pm] GaborHojtsy: yeah... [4:31pm] jucallme joined the chat room. [4:31pm] GaborHojtsy: unfortunately translatable fields did not resolve config translation at all, which is i18n mostly about [4:31pm] tsvenson: DamZ: Its served us well, but a replacement wouldn't be bad... [4:31pm] DamZ: it's still too big, but that's another issue [4:32pm] DamZ: hell breaks loose when you start enabling this thing [4:32pm] webchick: GaborHojtsy: cool, that makes sense. thanks. "relational" vs. "in-object".. do you mean relational as things like the node author, and in-object as things lke the body? [4:32pm] GaborHojtsy: DamZ: yeah, I've had a huge post about why it is too big and how it needs to produce field-like things for configuration, so that is my comment above that we need to introduce these in core [4:32pm] plach: we totally have to ensure D8 can go natively multilingual, at very least for the core behaviors [4:33pm] GaborHojtsy: webchick: relational I mean like content translation module in core, that you have copies of your thing in multiple languages, and in-object means you have one object and then copies of only the translatable pieces [4:33pm] GaborHojtsy: plach: ++ [4:33pm] good_man: plach: ++ [4:33pm] GaborHojtsy: I think the biggest problem we have in D7 is config translation, since config is so non-standard everywhere [4:33pm] DamZ: i18n_object_wrapper goes a long way toward this [4:33pm] webchick: GaborHojtsy: Ok, so relational == an article "Hello world" with a French "Bonjour monde" translation. [4:33pm] GaborHojtsy: think views, a contact form or a rule is very different [4:33pm] GaborHojtsy: webchick: y [4:34pm] webchick: GaborHojtsy: In-object is the "t-shirt colour" field which has "Red, Green, Blue" in English, and "Rouge, Vert, Bleu" in French? [4:34pm] GaborHojtsy: config is also the biggest problem in D8 since most people don't want to work on anything related to its UI yet [4:34pm] GaborHojtsy: webchick: y [4:34pm] webchick: GaborHojtsy: thanks. Sorry for the dumb questions. [4:35pm] webchick: GaborHojtsy: has any work been done in wireframing out a possible UI for translations? [4:35pm] DamZ: in D8, TranslatableDrupalConfig should get us a long way [4:36pm] GaborHojtsy: webchick: no, what we have so far is we follow the core translation module UI also mimicked by the entitiy translation (field translation UI) module [4:36pm] GaborHojtsy: DamZ: already have that? [4:36pm] plach: webchick: Bojhan did some work when we were talking about the TF UI in core, but it was not feasible with the time and concept we had [4:36pm] DamZ: in that sense, better object translation in core is totally dependent on the configuration iniatiative [4:36pm] webchick: DamZ: yeah. [4:36pm] GaborHojtsy: DamZ: yes [4:36pm] plach: webchick: don't know if there have been later attempts [4:37pm] marktheunissen joined the chat room. [4:37pm] DamZ: GaborHojtsy: no, my point is that once the configuration initiative will have uniformized configuration storage, adding a translatability layer will be easy [4:37pm] webchick: The Config Management initiative's been mostly focused on low-laying library stuff, for now. The issue of contextual config has been pushed off. We need to have a BoF or 6 on this at London, though. [4:37pm] GaborHojtsy: DamZ: so I think what we can do is to (a) push ahead with the field translation work, title module and ET in core sooner than later and (b) work on the low hanging fruit and (c) evangelize and help with our need with the context/config initiative [4:37pm] tsvenson: Have those of you that got Google+ Accounts looked at the Language setting you have there (Cogwheel/Settings/Language)? It has almost exactly what I always wanted to be able to set as a user. Only thing missing is a separate setting for the UI. [4:37pm] GaborHojtsy: DamZ: last time I talked to heyrocker about this, he was not sure if a generic context-sensitive config will be or just langage specific [4:37pm] webchick: GaborHojtsy: how exactly are we going to reintroduce $node->title as translatable? We did that once, and had to pull it for performance (iirc) [4:37pm] DamZ: GaborHojtsy: ok for everything, not sure about ET [4:38pm] DamZ: one of the issue about ET is that we don't necessarily agree on what the UI should be like [4:38pm] DamZ: there are a *ton* of different use cases around translation [4:38pm] GaborHojtsy: DamZ: how could D8 be multilingual if we don't have a UI for it? [4:38pm] webchick: Do we have a list of said use cases anywhere? [4:38pm] DamZ: GaborHojtsy: that's a good question [4:38pm] good_man: Does configuration iniatiative know that they need to solve the translation issue too in their abstract way? (don't have details about configuration iniatiative) [4:39pm] webchick: I attended a i18n sprint back in 2006 and I can remember a few. [4:39pm] plach: webchick: http://drupal.org/node/1188394#comment-4602774 IMO [4:39pm] Druplicon: http://drupal.org/node/1188394 => Make title behave as a field (again) => Drupal core, entity system, normal, active, 6 comments, 2 IRC mentions [4:39pm] GaborHojtsy: good_man: yes, they do [4:39pm] webchick: good_man: They're punting for now. There's a lot of interrelated dependencies. [4:39pm] GaborHojtsy: I think our main problem there is that this context specific config consideration might come "too late" [4:39pm] DamZ: GaborHojtsy: for two recent projects I implemented things different then ET because there was a need for a different UI [4:39pm] webchick: web services is setting up the config object, CMI is setting up a unified mechanism of storing/reading configuration, and between those two and i18n initiative, we need to come up with contextual config [4:40pm] GaborHojtsy: just had a great discussion with Bojhan on this [4:40pm] GaborHojtsy: DamZ: would be great to see some UI variants you have used [4:40pm] GaborHojtsy: DamZ: mockups are great, no need for secret screenshots if you can't share [4:40pm] D4rKr0W joined the chat room. [4:41pm] DamZ: GaborHojtsy: let me see what I can do [4:41pm] GaborHojtsy: webchick: I think if they implement context specific config, multilingual comes for free [4:41pm] webchick: A definitive list of "These are the translation workflows we want to support in core" would be insanely helpful for UI design considerations [4:41pm] GaborHojtsy: webchick: if context can be "logged in", "comes from Canada", "it is afternoon", "French" then... [4:42pm] webchick: GaborHojtsy: in my experience, nothing comes for free. [4:42pm] GaborHojtsy: webchick: hehe [4:42pm] GaborHojtsy: so far my approach was to (1) get more things entities (2) get more things fields => we get lots of language support among other great features without special one-off solutions [4:43pm] GaborHojtsy: you can call that "for free" [4:43pm] DamZ: I don't really see context-specific config happening anytime soon [4:43pm] webchick: GaborHojtsy: you can if catch doesn't stab you over it. [4:43pm] GaborHojtsy: who wants to work on making things entities and fields? [4:43pm] DamZ: I feel that translatability is a narrower use case [4:43pm] plach: GaborHojtsy: perhaps incredibly, but I ain't so sure we should make more things entities just to get transltability [4:43pm] GaborHojtsy: DamZ: yeah, that is my feeling as well... not sure context specific config like that will be there [4:44pm] GaborHojtsy: plach: well, we get lots of other great stuff, no? [4:44pm] GaborHojtsy: plach: entites = better than custom data storage and custom CRUD [4:44pm] DamZ: plus, context-specific adds a level of additional complexity for translatability [4:44pm] davereid joined the chat room. [4:44pm] DamZ: because you are to translate all the different contexts [4:44pm] plach: IMO we should aim to have an unfied behaviorfor Field API fields and generic properties [4:44pm] DamZ: you *have* to [4:44pm] webchick: GaborHojtsy: We do, but catch's point about "Do you need formatters for 'Number of posts to show on the home page'" is important. [4:44pm] sun: DamZ: given some screenshots or mockups, we could try to make ET more flexible in what it allows UI-wise. guess the fundamental widgets/UI parts could be easily abstracted and remixed [4:44pm] plach: something the Entity API is already trying to do [4:44pm] GaborHojtsy: DamZ: I think it adds complexits regardless, what's your site name for afternoon when the visitors is from Canada? [4:45pm] amateescu joined the chat room. [4:45pm] GaborHojtsy: DamZ: langauge is just a few more context options [4:45pm] plach: GaborHojtsy: sure, but I don't think we always need the field workflow [4:45pm] DamZ: GaborHojtsy: yep, plus you need to translate all the variants [4:45pm] GaborHojtsy: DamZ: what's your site name for afternoon when the visitor is from Canada and the language is French is not much farther [4:45pm] plach: if the FIeld API was able to reuse a lower layer providing widgets and so on [4:45pm] plach: we could use it for non-field properties too [4:45pm] DamZ: GaborHojtsy: design a UI for something multidimensional like that is *hard* [4:46pm] DamZ: *designing* [4:46pm] webchick: I know my site name for the afternoon when the visitor is from Canada and the language is French will be "Coffee, s'il vous plait" [4:46pm] webchick: DamZ: well, dare I say a "wizard"? [4:46pm] GaborHojtsy: DamZ: yeah, trying to point that out for Bojhan, yoroy et al on g.d.o in the current discussion at http://groups.drupal.org/node/160144 [4:46pm] Druplicon: http://groups.drupal.org/node/160144 => Core Context UX: Page & Component library => 15 comments, 12 IRC mentions [4:46pm] DamZ: we always come back to something hierarchical like http://groups.drupal.org/node/160144 [4:46pm] Druplicon: http://groups.drupal.org/node/160144 => Core Context UX: Page & Component library => 15 comments, 13 IRC mentions [4:47pm] GaborHojtsy: DamZ: they already face the "show this block when the user is logged in and the path is X" problem which is "the same" [4:47pm] DamZ: but here is no necessarily a "natural" hierarchy [4:47pm] webchick: DamZ: Most people want to pick one translation workflow for their entire site, not on a per-entity basis or whatever. Either they're a single-language site with a $other language translation, or they're a multi-lingual user-generated content site, or.. [4:47pm] GaborHojtsy: webchick: no, not really [4:47pm] DamZ: webchick: not really [4:47pm] webchick: So if we came up with 3 "templates" or whatever tht people could choose from and then an "Advanced" option for further config? [4:47pm] webchick: Hahaha, ok nevermind then. [4:47pm] GaborHojtsy: webchick: if you site has a forum and a press section and a shop [4:47pm] yoroy: I think we do realize there's no strict hierarchy. Just that the question 'what else then?' gets pretty hard to answer [4:47pm] GaborHojtsy: webchick: you'll use totally different multilingual options for these [4:47pm] webchick: GaborHojtsy: ah, true. [4:48pm] sun: but there's no need to make the user aware that she's using different multilingual options for these [4:48pm] Crell joined the chat room. [4:48pm] GaborHojtsy: eg. forum you want to know language but no translation, press section you want a workflow, moderation, signoff, etc. shop you need products translated in-object [4:49pm] webchick: right. hrm. [4:49pm] yoroy: hmmm. sections [4:49pm] webchick: workflow module in core. [4:49pm] sun: most translation methods could be figured out automatically by the system [4:49pm] GaborHojtsy: sun: well, translating forum posts make sense? workflow and approval for them makes sense? [4:49pm] GaborHojtsy: sun: we need to somehow expose the differences [4:50pm] yoroy: GaborHojtsy: for whom do we need to do that? [4:50pm] GaborHojtsy: sun: ok, you create a "foo" content type, how do we pre-configure it for translation? [4:50pm] GaborHojtsy: yoroy: what? [4:50pm] yoroy: GaborHojtsy: expose differences [4:51pm] DamZ: shop might want to have user-contributed product with a posteriori translations [4:51pm] DamZ: [4:51pm] GaborHojtsy: yoroy: I think site builders definitely, content creators, somewhat, you know depends on permissions, pretty blury [4:51pm] GaborHojtsy: DamZ: yeah [4:52pm] sun: GaborHojtsy: perhaps I'm wrong, perhaps not we should try hard to think about automations and simplification. but well, let's get the functionality in first [4:52pm] webchick: In general I'm less in favour of magic. [4:52pm] webchick: BUt yes. [4:52pm] OSInet: you could even think of per-language fields, actually [4:52pm] good_man: hmm can we start from a simple-working translation usecase, if we keep thinking of every possible case it'll be so hard to implement all [4:52pm] OSInet: i.e. not translated fields, but entirely different field sets [4:52pm] GaborHojtsy: yoroy: your press releases will need editing workflow and potentially signoff and timed perfectly for monday morning published all at once... you need to somehow expose to people these things [4:52pm] plach: sun++ [4:53pm] GaborHojtsy: agreed, lets's get functionality in first [4:53pm] plach: I tjink core should be providing sensible default behaviors (and make clear they are *defaults* i.e. alterable) [4:53pm] GaborHojtsy: I think two basic models worked so far for Drupal: object translaton relations and in-object (field) translation [4:53pm] GaborHojtsy: we've heard people are unhappy with both as-is, which is great [4:53pm] GaborHojtsy: we'll have you work on them [4:53pm] good_man: for me, the most important is translatable title + fields, other things like workflow and context can be done later [4:54pm] GaborHojtsy: plach: ++ [4:54pm] webchick: Right, so for people currently using i18n module, are they mostly using it to get the benefit of translatable titles/fields/config? [4:54pm] sun: ok. Right now, I'm slightly missing structure [4:54pm] webchick: Or are there workflow implications there too? [4:54pm] Crell: Speaking as a site builder, translation relations are a serious PITA, as it makes all other object relations more complicateed. [4:54pm] good_man: webchick: no, title has a separate module, and fields too [4:55pm] DamZ: GaborHojtsy: webchick: speaking about workflow, one of the project we did recently had a translation workflow with review and validation, with a translator oriented UI [4:55pm] DamZ: (based on editable fields) [4:55pm] webchick: DamZ: that's interesting. [4:55pm] DamZ: (tip of my hat to OSInet) [4:55pm] webchick: DamZ: like localize.drupal.org but for a specific site? [4:55pm] DamZ: webchick: yep [4:55pm] sun: Crell: right, I personally don't see a need for relational translations anymore, but GaborHojtsy and others disagree with me [4:55pm] DamZ: webchick: and with per-translation review workflow [4:55pm] GaborHojtsy: DamZ: great, sharing these use cases would be great [4:55pm] good_man: webchick: http://drupal.org/project/title and http://drupal.org/project/entity_translation [4:56pm] OSInet: DamZ: I think I know which one you mention [4:56pm] DamZ: GaborHojtsy: I have a screenshot, but it has product references on it, I can forward that to you (you know the client) but you cannot share publicly [4:56pm] GaborHojtsy: sun: well, maybe DamZ has the use case to convince me and others? [4:56pm] webchick: DamZ: can you take your black magic marker to it so we can all see? [4:56pm] GaborHojtsy: DamZ: sounds like a screenshot will not explain it [4:56pm] good_man: DamZ: http://drupal.org/project/trwf [4:56pm] Crell: Blog post? [4:57pm] DamZ: good_man: well, I have all of that [4:57pm] yoroy: GaborHojtsy: sry, distracted. Good examples on why, thanks [4:57pm] good_man: DamZ: had some working code, but the keep-changing title + entity translation have not allowed me to complete it [4:57pm] DamZ: good_man: we decided to create a separate entity for that [4:57pm] sun: Crell: https://docs.google.com/drawings/d/1EJWdw8A_EF-bXwwnB4e4KGBXLRLXjFndvY2tBVQIsfo/edit?hl=en_US [4:57pm] DamZ: good_man: so we have the main entity + one entity for each translation [4:57pm] DamZ: good_man: we merge them dynamically [4:58pm] good_man: DamZ: cool! any link? or not published? [4:58pm] tsvenson: GaborHojtsy: Love all the ideas and improvements being considered for improving administrating and editing content. However, one issue as I see it is that contributed modules often have very limited support for making it easy to use on the sites. Take Views for example, it doesn't support the language fallback and other things, you have to basically create everything from scratch on how it shall handle displaying in different languages. [4:58pm] DamZ: good_man: not published yet, but I should be able to publish part of it soon [4:58pm] GaborHojtsy: tsvenson: yes, that is where configuration translation would kick in [4:58pm] Crell: sun: Thanks. [4:58pm] good_man: DamZ: do you need that project? or I'll abandon it in favour of yours if it's too similar [4:59pm] GaborHojtsy: tsvenson: plan for D8 is that all modules will either do entities or configuration objects [4:59pm] GaborHojtsy: tsvenson: both will be translatable in soem ways [4:59pm] Crell: Translating of configuration objects is still a big unknown. [4:59pm] GaborHojtsy: Crell: yeah [4:59pm] DamZ: good_man: I think we can collaborate on that [4:59pm] Crell: That affects both hejrocker and I, but we couldn't figure out how to deal with that at the sprint. [4:59pm] sun: GaborHojtsy: so to me it looks like a sensible next step would be to "categorize" that chart a bit more, and possibly make it more granular [5:00pm] GaborHojtsy: Crell: I think the scary part is that it is 80% of i18n module, yet, we don't know anything of it in D8 [5:00pm] tsvenson: GaborHojtsy: Brilliant. So the intention is the make this as transparent as possible for developers so the don't have to add special support? it just will work right out of the box? [5:00pm] GaborHojtsy: Crell: one of our bigger problems which is very dependent on WSCII and config [5:00pm] sun: i.e., split into locale system, language system, translation system, translation module, field api [5:00pm] Crell: Especially since, we realized, language is only one possible axis on which configuration data may vary. Domain, Space, etc. are all viable candidates. [5:00pm] webchick: time of day [5:01pm] GaborHojtsy: sun: I'm dreaming of a graphing tool I can drag d.o issues to [5:01pm] Crell: So what we actually need is for a given configuration object to vary by context, which means some parts of configuration are context sensitive and others are not. Language is just one particular piece of context. [5:01pm] GaborHojtsy: sun: so you can track the status of issues and it could build the hierarchy that needs to be augmented to the d.o info [5:01pm] sun: GaborHojtsy: me, too. already thought twice about hacking something into dreditor [5:02pm] catch joined the chat room. [5:02pm] sun: catch: https://docs.google.com/drawings/d/1EJWdw8A_EF-bXwwnB4e4KGBXLRLXjFndvY2tBVQIsfo/edit?hl=en_US [5:02pm] webchick: OMG it's catch! [5:02pm] GaborHojtsy: Crell: we covered that in a bit above, and DamZ expressed this sounds too complex to happen proper in D8 [5:02pm] webchick: catch: so we're making everything in D8 entities. kthxbi [5:02pm] • catch was in #drupal-i18n? which had only one member and is multitasking a bit. [5:02pm] Crell: GaborHojtsy: Unfortunately I don't know that we have an option. I don't know how something like Domain Settings would work otherwise. [5:02pm] Crell: Or Spaces. [5:02pm] Crell: We can't just say those won't work in D8. [5:03pm] Crell: Ken Rickard would kill me. [5:03pm] GaborHojtsy: Crell: yeah, the problem is you need config for when it is afternoon, the visitor comes from Canada and the language is French [5:03pm] GaborHojtsy: Crell: and other combinations [5:03pm] GaborHojtsy: Crell: how do you store/load/edit this effectively? [5:04pm] GaborHojtsy: Crell: "logged in" is a two piece axes, language can be any number (eg. almost 100 for l.d.o) [5:04pm] Crell: That's where we broke down and cried at the Config sprint in Denver and decided to punt it to a 4th layer. [5:04pm] GaborHojtsy: Crell: so you need all possible combinations covered [5:04pm] catch: can someone define everything? [5:05pm] Crell: catch: "Everything" isn't relevant. [5:05pm] GaborHojtsy: Crell: well, our dilemma is that either we can sit back that it will be resolved some day when the time comes, or we start doing something for language to ensure it is covered [5:05pm] Crell: "Anything" is. [5:05pm] GaborHojtsy: catch: https://docs.google.com/drawings/d/1EJWdw8A_EF-bXwwnB4e4KGBXLRLXjFndvY2tBVQIsfo/edit?hl=en_US is our nice graph with colors and clouds [5:05pm] Crell: Once you have more than one thing by which config could vary, you have an infinite number. So you need to support an arbitrary number of possible axes. [5:05pm] Crell: Which... sucks. [5:06pm] GaborHojtsy: Crell: also, you might not want your file path to differ, but you want your site name or date format config [5:06pm] Crell: Right. [5:06pm] catch: Crell: no everything is relevant too. [5:06pm] catch: My database settings are not going to be an entity. [5:07pm] Janusman: Wondering... akin to the webservices initiative, is/was there anyone looking at how other CMSs/Frameworks approach i18n? [5:07pm] marktheunissen left the chat room. (Quit: marktheunissen) [5:07pm] catch: At some point there is a line between what is an entity, and what is not. [5:07pm] Janusman: (not meaning to add fuel to the fire) [5:07pm] Crell: catch: Er, I'm talking about configuration objects, not entity objects. VERY different creatures. [5:07pm] GaborHojtsy: Janusman: I've been looking at eZPublish recently, got a great demo from experts [5:08pm] good_man: Janusman: I planned to do so sometime ago, asked a RoR friend, they don't got to that much details [5:08pm] Crell: Django I've heard does good translation. [5:08pm] Crell: Although I've never looked at it myself. [5:08pm] GaborHojtsy: Janusman: heard that eZPublish often wins above Drupal for multilingual sites, so looked like a great candidate [5:08pm] good_man: Janusman: but I'm with asking every possible programmer, so we maybe can benefit from them [5:09pm] catch: Crell: I was responding to webchick, not you, let's forget the past three minutes happened [5:09pm] Crell: Oh. What 3 minutes? [5:09pm] GaborHojtsy: Janusman: in short they have similar layers of language support, they use a custom XML format for UI string translation (not gettext), they use a config file format for things like date formats, and other configuration that can be locale specific (no UI for these), and for their structure and content they have translatable fields very nicely built-in [5:09pm] webchick: lol [5:09pm] catch: actually 4 minutes. [5:09pm] good_man: GaborHojtsy: can you share the eZPublish sumary if available? [5:10pm] Janusman: GaborHojtsy: that info helps, I guess some will definitely want to take a look [5:10pm] good_man: Crell: I have a Django friend who worked on i18n sites, I'll ask him [5:10pm] Crell: GaborHojtsy: So, to make sure I understand here, there's 3 categories of "things" that need to be translatable: Entity content (titles, fields, etc.), Configuration strings (config objects, which replace variable_get()), and Code Strings (t()). Right? Anything I'm missing? [5:10pm] Crell: good_man: Good man! [5:10pm] GaborHojtsy: Crell: that is the plan [5:10pm] GaborHojtsy: Crell: yes [5:10pm] • Crell is a bit late to the meeting so a bit behidn, sorry. [5:10pm] GaborHojtsy: Crell: the trick is that config stuff needs to have *lots of* field like properties [5:11pm] good_man: btw I remember some posts on g.d.o talking about different system features and usecases, is it from 18n group? (my brain RAM is very bad) [5:11pm] Crell: And yet cannot be fields, because that creates an ugly circular dependency of doom. [5:11pm] • catch apparently behind as well but thinks that three point plan is reasonable. [5:11pm] GaborHojtsy: good_man: I've made a recording but then did not save the audio, only has the video... bummer... can do a writeup maybe [5:11pm] Janusman: Crell / GaborHojtsy: how do whole entities flagged as X language figure into this? [5:12pm] Janusman: meaning: node X is in english, node Y is its spanish translation [5:12pm] catch: Janusman: that'd be making translation module work for other entity types. [5:12pm] good_man: GaborHojtsy: ok it'll be super, I'll try it too [5:12pm] Crell: Janusman: Honestly I'd rather avoid having that situation happen at all. It makes anything that does entity relations (noderef, etc.) 10x harder. [5:12pm] DamZ is now known as DamZ^zzz. [5:12pm] Crell: It's one of the main reasons I hate doing multi-lingual sites. [5:12pm] GaborHojtsy: Janusman: catch: which sun and DamZ don't necessarily agree with and DamZ has use-cases to avoid using separate entities altogether, which I'm looking forward to eagerly [5:12pm] catch: I really wanted to get rid of separate entities. [5:13pm] catch: After trying to make contrib work with them in D6 [5:13pm] GaborHojtsy: Crell: problem there is that many properties are single-value [5:13pm] catch: which was an uphill and painful struggle. [5:13pm] davereid: yeah, separate entities are on my nerves [5:13pm] GaborHojtsy: Crell: if we can have per-language properties (which ET module hacks in there), then... [5:13pm] tsvenson: GaborHojtsy: Will this work also consider the needs of Locale support? Take an eShop for example, where some of the content has to be governed by locale (one or more territories such such as prices, currency, taxes, law, etc), other times my personal locale settings will affect how content is viewed. [5:13pm] catch: And was a big initial motivator for translatable fields in the first place. [5:13pm] Crell: If we had common support for properties, the way we do for fields, we could do that. [5:13pm] Crell: That's something we need to do in D8 anyway. [5:13pm] GaborHojtsy: Crell: same entities cannot do multiple post dates, multiple authors, separate permissions workflows, etc right now [5:14pm] catch: Yeah entity properties need to be actual things. [5:14pm] GaborHojtsy: Crell: ET module has some hacks for that [5:14pm] GaborHojtsy: Crell: *some* *hacks* [5:14pm] catch: not random columns in hook_schema() [5:14pm] • Bojhan ponders what ET is [5:14pm] Crell: catch: Agreed [5:14pm] Crell: Do we really need different authors or post dates depending on language...? [5:14pm] catch: Bojhan: entity translation. [5:15pm] good_man: Bojhan: http://drupal.org/project/entity_translation [5:15pm] GaborHojtsy: tsvenson: listing is still views or whatever listing you use, if you have your versions properly tagged you should be able to list per territory cross per language [5:15pm] Bojhan: thanks [5:15pm] GaborHojtsy: Crell: how do you do a press release workflow with moderation otherwise? [5:16pm] GaborHojtsy: Crell: imagine workbench with multilingual support [5:16pm] Janusman: separate entities would be a fact of life on many sites... but maybe then it's not *actually* i18n, it's a variation of entity metadata to limit listings.. and interlinking is just a kind of nodereference.. dunno [5:16pm] Crell: mmm... [5:16pm] Crell: Suck. [5:16pm] GaborHojtsy: Crell: we publish these press release in 4 languages on Monday morning if all are approved by Marketing and the translations contractor submitted them proper [5:16pm] tsvenson: Crell: A standard "Translated" by field would be very useful to have. That can then both be used when viewing, "translated by: name/date" and in translation workflows when for example the original content has been changed and the translated needs to be updated. [5:17pm] sun: this is circling back into workflows again [5:17pm] plach: GaborHojtsy: planning to make them *many* *not so hacks*, but I ain't sure I'll succeed [5:18pm] GaborHojtsy: tsvenson: Crell: except you need to be able to do permissions based on that field too [5:18pm] Janusman: maybe entity translations akin to GaborHojtsy's use case (e.g. press release, each language has to be translated/reviewed in a workflow) are just that... an instance for workflow-type modules. Or kind of like revisions. [5:19pm] plach: Crell: about other platforms and multiple configuration axes I find this slightly in topic: http://developer.android.com/guide/topics/resources/providing-resources.html#Compatibility [5:19pm] tsvenson: GaborHojtsy: Unfortunately locale is a bit more complicated than that, especially when there is local (country) or teritorial (EU) involved. [5:19pm] catch: at the moment, tnid is more or less a node reference. [5:19pm] catch: and translation builds an infrastructure around this. [5:19pm] catch: And nothing much else respects that infrastructure. [5:20pm] GaborHojtsy: catch: yeah, well, views does/can [5:21pm] Janusman: how else could node/entity translations (as separate entities) be abstracted? [5:21pm] sun: right. extending that to other entities more or less means to put Relation module into core [5:21pm] GaborHojtsy: catch: but I agree about the rest [5:21pm] tsvenson: GaborHojtsy: Yes, maybe this can be made smart so every language doesn't need its separate permission. That is, on top of the permission to allow a role to work with translations, it is possible to set what languages they are allowed to work on uniquely for each user. [5:21pm] GaborHojtsy: I think the main reason we have separate entieties is that we cannot have properties and relations per language [5:21pm] Janusman: kind of sounds like grouping entities into a ... thing. kind of like node revisions belong to the same node... [5:21pm] GaborHojtsy: such relations are "which menu item this node is attached to", "who authored it", "which comments belong to this", etc. [5:22pm] Janusman: or maybe not [5:22pm] Crell: Janusman: I was just thinking in that direction, yes. [5:22pm] GaborHojtsy: tsvenson: well, DamZ^zzz had a use case for community submitted and translated products, those who translate those should not translate your press releases [5:22pm] Crell: But that then makes entities, uh, even more scary than they already are. [5:23pm] good_man: Crell: oh no [5:23pm] Janusman: hmm... maybe look at how Commerce group products/subproducts? or others. [5:23pm] plach: yes, if we abstract the concept of entity translation it does not really matters if it is an standalone entity or a part of another one (or both) [5:23pm] GaborHojtsy: Crell: there is a theoretical possibility to make entitiy groups entities, and then relate things to entity groups, but its not too attractive to say the least [5:23pm] • Crell nods. [5:24pm] GaborHojtsy: plach: it does matter somewhat, if you edit a shared value, all dependent entities change, so you need to fire their hooks, clear their caches, etc. [5:24pm] Crell: We can probably remove a variable if we assume entities move to a CRAP model. I think everyone wants that, but no one is working on it. [5:24pm] • Janusman looks up CRAP [5:24pm] tsvenson: GaborHojtsy: Yeah, but then you can use modules such as the Workbench suite to manage what content types in combination with parts of the site a user can edit. [5:25pm] GaborHojtsy: tsvenson: to control permissions? [5:25pm] tsvenson: GaborHojtsy: Then, even if the same Content Type is used for both articles and press releases, it is possible to set that a role/user can only translate the articles, but not the press releases. [5:25pm] OSInet: Janusman: Create/Retrive/Archive/Purge: in essence never update, so any content is invariant until purged, which simplifies replication [5:26pm] sun: Crell: indeed, looks like we're missing another initiative [5:26pm] Crell: http://london2011.drupal.org/coreconversation/unified-entity-api-part-configuration-management-initiative [5:26pm] GaborHojtsy: Crell: how does that solve multilingual issues? [5:26pm] Crell: That's probably where it would go. [5:26pm] tsvenson: GaborHojtsy: http://drupal.org/project/workbench_access [5:26pm] Crell: GaborHojtsy: it doesn't, but it removes a variable from inside the insanity that is entities, when every one of these variables has a multiplicative impact on complexity. [5:27pm] GaborHojtsy: Crell: ha, right [5:27pm] GaborHojtsy: tsvenson: yeah, well, it depends on node access right now AFAIK [5:28pm] davereid: GaborHojtsy: yes we do not have a unified entity access system...yet [5:28pm] GaborHojtsy: tsvenson: which only works for per-language access if you have separate entities for separate entities [5:28pm] Crell: If hook_node_access turns into hook_entity_access, workbench should be able to follow that easily. [5:28pm] GaborHojtsy: davereid: tsvenson: yeah, I'm wondering how we'd do context sensitive permissions [5:28pm] Crell: If we have a clean context system, then we just need to make sure it's exposed in the right place. [5:28pm] Crell: At least at a code level. [5:29pm] Crell: At a UI level... *shudders* [5:29pm] GaborHojtsy: right now you have logged in and all roles as contexts for permissions [5:29pm] GaborHojtsy: if you factor in language... [5:29pm] tsvenson: GaborHojtsy: Somewhat yes, but it really makes a difference for being able to apply how things work in organisations needing this functionality. [5:29pm] GaborHojtsy: if you factor in more contexts... [5:29pm] good_man: Crell: wish there be a live-streaming and IRC of core conversations [5:29pm] GaborHojtsy: tsvenson: yeah [5:30pm] • GaborHojtsy needs to leave soon, sad to leave such a great conversation [5:30pm] Crell: good_man: I don't think we'll have bandwidth, but we are going to try and get them recorded this time. [5:30pm] iStryker_ joined the chat room. [5:30pm] • Crell has to leave too for a phone call. [5:30pm] tsvenson: GaborHojtsy: And that is something I am really happy to see is being prioritised for Drupal 8. [5:30pm] GaborHojtsy: thanks everyone for your *very* *valuable* input [5:30pm] plach: GaborHojtsy: can we summarize what we have said? [5:30pm] Crell: GaborHojtsy: Do we have a plan for code strings? That's the one we didn't discuss. [5:30pm] good_man: Crell: it'll be amazing! [5:31pm] GaborHojtsy: plach: will try [5:31pm] plach: GaborHojtsy: great [5:31pm] tsvenson: GaborHojtsy: Thanks, its been a very enlightening discussion. Great things are going to come out of this... [5:31pm] GaborHojtsy: Crell: I don't have great reform plans there given we have much bigger problems IMHO with the cure language/locale API and fields and config translation [5:32pm] iStryker__ joined the chat room. [5:32pm] good_man: GaborHojtsy: thanks good discussion, many things to follow up, and lots of work ahead [5:32pm] GaborHojtsy: Crell: the discussion on that was very bipolar [5:32pm] • Crell nods. [5:32pm] • Janusman loads and fires the donut laucher. [5:32pm] Crell: I didn't see the discussion, just know it happened. [5:32pm] iStryker left the chat room. (Ping timeout: 257 seconds) [5:32pm] Crell: If we consider that good enough for now, I'm cool with that. [5:32pm] iStryker__ is now known as iStryker. [5:32pm] OSInet: good evening everyone, thx for the exchange [5:33pm] plach: for anyone interested, I'm evalutaing the possibility to inclued a dependency on CTools for ET to address some entity-specific issue (I ain't sure it's the right way, but whatever). SInce this might have an impact on porting ET to core I'd like some feedback [5:33pm] plach: GaborHojtsy: sun: ^^ [5:33pm] Crell: plach: ctools is already effectively required for D7 due to Views. [5:34pm] plach: Crell: sure, but I ain't sure how the D8 plugin system will map to to it [5:34pm] good_man: plach: any link to an issue? [5:34pm] Crell: plach: And I HOPE that ctools context and plugins will end up dropped in D8 in favor of the WSCCI implementations of both. [5:35pm] iStryker_ left the chat room. (Ping timeout: 250 seconds) [5:35pm] plach: good_man: nothing yet, it all started from http://drupal.org/node/1155134 [5:35pm] Druplicon: http://drupal.org/node/1155134 => Integrate pathauto => Entity translation, Code, normal, needs review, 14 comments, 3 IRC mentions [5:35pm] yoroy left the chat room. (Quit: toedels!) [5:35pm] sun: plach: hm. need to look at that issue [5:35pm] Crell: If you go with ctools plugins, use the OO version of them. That should be easier to migrate to D8's core equivalent. [5:35pm] GaborHojtsy: plach: yeah, depends on what you need to depend on exactly [5:35pm] good_man: plach: ok [5:36pm] iStryker left the chat room. (Read error: Connection reset by peer) [5:36pm] iStryker_ joined the chat room. [5:36pm] iStryker_ is now known as iStryker. [5:36pm] • GaborHojtsy needs to leave [5:36pm] plach: Crell: I hope too we will have a unique plugin system [5:36pm] plach: Crell: sun GaborHojtsy : thanks [5:36pm] Crell: No no no, unique plugins bad. Unified plugins good. [5:36pm] GaborHojtsy: realized I don't have a full IRC log of the whole meeting, the first ten minutesor so at least are missing.. I can recollect that but if someone else has a full log please let me know [5:37pm] plach: Crell: sorry, I could not wrap my mind around this (subtle) matter yet [5:37pm] OSInet left the chat room. [5:37pm] plach: GaborHojtsy: I have them [5:37pm] iStryker left the chat room. (Read error: Connection reset by peer) [5:37pm] GaborHojtsy: plach: perfect, can you mail me [5:38pm] • GaborHojtsy just reconfigured his client to be more sane for this in the future [5:38pm] iStryker joined the chat room. [5:38pm] GaborHojtsy: THANKS EVERYONE again [5:38pm] GaborHojtsy: have a happy July 7th for the reminder of your day [5:38pm] Crell: plach: What we're trying to avoid is every system having its own plugin architecture. [5:39pm] plach: GaborHojtsy: sent [5:39pm] Crell: Right now, ctools plugins are the most standardized approach available. [5:39pm] plach: GaborHojtsy: bye! [5:40pm] plach: Crell: ok, I meant that, bad english probably [5:40pm] plach: [5:40pm] Crell: OK, good good. [5:40pm] dereine left the chat room. (Ping timeout: 240 seconds) [5:40pm] plach: Crell: is the OO CTools version stable? [5:41pm] Crell: I don't see why not. It's not really a separate version per se. More a style of usage that is IMO better. [5:41pm] Crell: See Feeds for an example of how it does it. [5:41pm] GaborHojtsy: plach: thanks! [5:41pm] Crell: You have to write your own factory/loader I believe. [5:42pm] • davereid cries at Feeds being used as an example [5:42pm] Crell: davereid: Do you have a better example of OO ctools plugins? [5:42pm] • Crell would love to hear one. [5:43pm] davereid: I've been hearing from rfay that Feeds uses its ctools plugin integration very wrong, maybe it is doing it right [5:43pm] Crell: I don't know there. [5:43pm] Crell: ctools itself doesn't work at a high enough level to even make that distinction, really. It's more how you leverage it. [5:43pm] Crell: That's one of the things I want to change for WSCCI plugins, and where a lot of the ctools folks disagree. [5:44pm] jucallme left the chat room. (Quit: jucallme) [5:45pm] You are now known as GaborHojtsy|noth. [5:45pm] good_man: ME thinking [5:45pm] You are now known as GaborHojtsy|away. [5:45pm] good_man: need to read this conv. from bottom-up [5:47pm] plach: Crell: I'll try to keep this aspect in mind if I go the CTools way, basically I'd like to avoid using ET-specific classes to handle entities in a general way, which is the current situation [5:48pm] plach: and which is really disturbing me [5:48pm] plach: Crell: anyway, thanks for the procious suggestions [5:48pm] plach: [5:48pm] Crell: Well, if you want a better wrapper for entities, Entity API seems to be the go-to module (sadly). [5:49pm] Crell: Ctools plugins are for LOGIC, not for DATA. [5:49pm] Crell: Logic, Data, and Configuration are separate thingies. [5:50pm] plach: Crell: I'm also evaluating whether integrate Entity API, but I defintely need to hndle both logic and dat in a consistent way [5:50pm] Crell: Entity API, from what I understand, is about half good stuff that should go in core and half crap that needs to die. [5:51pm] Crell: Or so I hear... [5:51pm] plach: Crell: and Entity API and CTools have different code styles, if I'm not mistaken, just to name one problem [5:51pm] Crell: Yep. [5:51pm] dixon_ joined the chat room. [5:51pm] Crell: Such is life in contrib. [5:51pm] Crell: I'm hoping that by moving more of those into core we can revamp them to be more consistent. [5:51pm] Crell: Time will tell there. [5:52pm] Crell: For now, IMO always err on the side of an OO approach for such things. That way you can autoload. [5:52pm] plach: Crell: yeah, I'm just trying to figure out which is the better choice having D8 in mind [5:52pm] ngnp left the chat room. (Quit: ngnp) [5:52pm] Crell: Whatever ends up in D8 will be different from either one. [5:53pm] plach: Crell: that's really relieving [5:53pm] Crell: I don't think I've ever seen something in contrib move to core and NOT get heavily rewritten in API-destroying ways. [5:53pm] catch: Crell: DamZ mentioned in an issue somewhere he doesn't like CRAP, there is the entity CRUD API issue from fago but I haven't reviewed yet [5:53pm] catch: afaik everyone else wants that though. [5:53pm] Crell: It would not be the first time I disagreed with DamZ. [5:54pm] Crell: CRAP simplifies so much, and the U is so easy to emulate it's pathetic. [5:54pm] plach: Crell: well, ET was started has something that had to go into core in D7, and for a while I hoped it would not be so hard to get it into D8 ; [5:54pm] plach: [5:54pm] Crell: fago didn't like it in Chicago, but I don't know if we convinced him otherwise. [5:54pm] Crell: plach: GLWT. [5:55pm] Crell: Now, it is hypothetically possible that portions of CMI and WSCCI could be back ported much as DBTNG was. If so, that would be sweet. [5:55pm] Crell: I don't know how feasible that is, though, and it's a ways away. [5:55pm] Crell: (Another advantage of well-encapsulated, low-coupling, OO systems.) [5:58pm] catch: Crell: I will work on CRAP, but I want the entity system moved to a module before we do that. [5:58pm] Crell: Why? [5:58pm] Crell: (I'm not against it necessarily, just curious.) [5:58pm] catch: Crell: because right now it is splattered all over bits of core. [5:58pm] catch: http://drupal.org/node/1018602#comment-4691400 [5:59pm] Druplicon: http://drupal.org/node/1018602 => Move entity system to a module => Drupal core, entity system, major, needs review, 42 comments, 6 IRC mentions [5:59pm] Crell: As long as it's an optional module, I am generally in support of it. [5:59pm] catch: like common.inc and sytstem.module [5:59pm] Crell: Required-modules in core suck. [5:59pm] catch: Well, it's not optional, because user module isn't optional. [5:59pm] Crell: That's a bug. [5:59pm] catch: Right. [5:59pm] catch: But if user module was optional, then entity could be too. [5:59pm] catch: Which is good enough for me. [5:59pm] • Crell nods. [5:59pm] Crell: Good enough for now. [6:00pm] catch: I somewhat want to put dependencies[] = entity in user.module [6:00pm] catch: instead of making entity required. [6:00pm] catch: although that might not work [6:00pm] Crell: Why wouldn't it? [6:00pm] catch: dependencies are very horribly broken in D7. [6:00pm] DamZ^zzz is now known as DamZ. [6:00pm] catch: mainly by install profiles. [6:00pm] Crell: Yes, but this is D8. [6:00pm] Crell: Just list entity in the modules for the install profiles. [6:01pm] catch: Yeah but they are broken in D8 too. [6:01pm] catch: One patch at a time. [6:01pm] Crell: [6:01pm] catch: if it is just swapping two lines in a .info at a later date it doesn't worry me to much. [6:01pm] catch: *too [6:01pm] catch: unlike system_rebuild_module_data() [6:03pm] plach: Crell: I forgot to mention one thing I wanted to bring to your attention during the sprint (just in case you didn't already know): in D7 we introduced language types, there are three built-in language types in core (UI, content, URL) [6:03pm] plach: now shoot me [6:03pm] plach: (language types are module definable) [6:03pm] • Crell shoots plach. [6:03pm] Crell: WTF is a language type? [6:04pm] plach: UI language is the language to be used by t() [6:04pm] plach: content language is the language I want content to be displayed in [6:05pm] plach: an admin might not understand russin bu have to unpublish a russian node [6:05pm] Crell: fun [6:05pm] plach: so it gets english UI whil viewsing russin content [6:05pm] plach: *she* gets [6:07pm] plach: Crell: in D7 we use a pretty custom callback system to initialize the value for each global, I'd be interested in seeing how can this be implemented through context in a gneral way [6:08pm] plach: http://api.drupal.org/api/drupal/includes--language.inc/function/language_initialize/7 [6:08pm] Crell: Well, the current architecture there is just a router to handler objects that lazy-init. [6:08pm] catch: I can attest that trying to test sites with Arabic user interfaces is not easy. [6:08pm] Crell: So the current-language context value can do whatever it feels like to decide what the active language is. [6:09pm] amateescu left the chat room. (Quit: Leaving) [6:11pm] D4rKr0W is now known as D4rKr0W`afk. [6:11pm] plach: Crell: currently many language detection callbacks can be chained to provide fallback in case on method was'nt able to determine the current language, do you think all of this should be implemnted in a single handler object or maybe this logic can be extended to any context value? [6:11pm] Crell: I... don't know. [6:12pm] Crell: That would be an excellent issue to file in the butler project for discussion and implementation. [6:12pm] Crell: (Or maybe g.d.o, not sure.) [6:12pm] Crell: Right now, handlers don't stack. [6:12pm] catch: plach: Crell: I have a few things here or there I'd want to chain/stack handlers for. [6:12pm] Crell: Such as? [6:12pm] catch: Mainly http://drupal.org/sandbox/catch/1153584 (no code) [6:13pm] • Crell is concerned what the impact of stacking both handlers and context objects would be. [6:13pm] catch: Also filters are arguably chained. [6:13pm] Crell: Filters aren't context handlers. [6:13pm] catch: Oh not context handlers [6:13pm] Crell: OK, yeah, you're talking about something else. [6:14pm] catch: Twice in one hour [6:14pm] catch: First time I had an excuse though! [6:14pm] Crell: [6:15pm] catch: But... if context handlers are usually a single class that is swapped out, but there is a use case for chaining them for fallback. [6:16pm] catch: That is a similar pattern to the cache chain stuff. [6:16pm] Crell: Well, cache chaining would be a meta-plugin of some sort, I think. [6:16pm] Crell: Plugins != context handlers IMO (although Earl would argue that they are, I disagree). [6:17pm] good_man left the chat room. (Quit: Konversation terminated!) [6:18pm] good_man joined the chat room. [6:18pm] tsvenson left the chat room. [6:18pm] catch: well if they're classes that respond to input and need to return something or fallback, then it's fundamentally the same pattern [6:18pm] catch: that's separate from the argument about what's a plugin and isn't. [6:20pm] Crell: A key reason I want them separate is because I want to be able to assume all plugins get context, and if plugins provide context, that creates a circular dependency. [6:21pm] Crell: That's part of what the epic thread of doom (Core Initiative Trinity) was about. [6:23pm] catch: I think I'm on the side that says it's not necessarily a circular dependency, but I also don't want to replay the thread of doom at 1.21am in #drupal-i18n [6:23pm] catch: Although it'd be fun another time [6:27pm] DamZ is now known as DamZ^zzz. [6:30pm] • Crell twitches. [6:30pm] Crell: The conclusion from that thread was to punt on it until we actually had code. [6:32pm] Janusman left the chat room. (Ping timeout: 258 seconds) [6:34pm] DamZ^zzz is now known as DamZ. [6:35pm] catch: Yeah I think punting makes a lot of sense. [6:36pm] plach: catch: what a pity, a thread of doom in #drupal-i18n might increase i18n popularity in the community (http://chxcannotbedistracted.com/i18n)