[6:01pm] GaborHojtsy: hi all, anybody here for the D8MI meeting?
[6:02pm] kalmanhosszu left the chat room. (Quit: kalmanhosszu)
[6:05pm] GaborHojtsy: nobody?
[6:08pm] GaborHojtsy: well, I'll be around for the full hour in case anybody is around
[6:13pm] plach: here I am
[6:14pm] plach: GaborHojtsy: ^
[6:14pm] GaborHojtsy: plach: hey, need help in anything?
[6:15pm] plach: GaborHojtsy: if you don't have anything better todo you might want give me your feedback about the ebntity forms issue
[6:15pm] ClemensTolboom: GaborHojtsy: I'm around too. Sort of
[6:15pm] plach: GaborHojtsy: I discussed yesterday with sun about a couple of techincal details
[6:16pm] GaborHojtsy: plach: that's great
[6:16pm] GaborHojtsy: ClemensTolboom: hey, nice seeing you virtually again  Have not seen you signed up for Munich, any plans?
[6:17pm] plach: GaborHojtsy: the other issues open with it are whether introduce the possibility to have per-context (un the general meaning) or per-bundle entity controllers
[6:17pm] ClemensTolboom: GaborHojtsy: I'm not sure … I'll be there for the conference … return on saturday .. hope to sprint some
[6:18pm] reyero: sun: hello?
[6:19pm] GaborHojtsy: plach: well, it currently has per-bundle
[6:19pm] plach: GaborHojtsy: see http://drupal.org/node/1499596#comment-6158288 and following
[6:19pm] GaborHojtsy: plach: which seems like it makes sense from the variance of what needs to be covered
[6:19pm] Druplicon: http://drupal.org/node/1499596 => Introduce a basic entity form controller => Drupal core, forms system, normal, needs work, 31 comments, 10 IRC mentions
[6:19pm] GaborHojtsy: ClemensTolboom: ah, it would be good to get your info on the signup sheet, even if only MAYBE
[6:20pm] GaborHojtsy: ClemensTolboom: big green button at http://groups.drupal.org/node/238003
[6:20pm] Druplicon: http://groups.drupal.org/node/238003 => Drupal 8 Multilingual Initiative sprint before/after DrupalCon Munich 2012, needs sponsors => 0 comments, 2 IRC mentions
[6:20pm] plach: GaborHojtsy: users have profile form and registration form, and that's not a per-bundle variation
[6:20pm] sun: reyero: ahoy   I'm relatively busy with $dayjob today, so won't have much time for stuff.  And sorry, didn't review your latest patch/proposal yet, so I can't comment on that yet.
[6:20pm] plach: GaborHojtsy: my argument is that it would be nice to have a totally different controller for ech one instead of relying on alterations
[6:21pm] navid66 joined the chat room.
[6:21pm] GaborHojtsy: plach: well, maybe provide one controller by default and then if people need more, allow for retrieving one based on the needed circumstance (avoiding context
[6:21pm] reyero: never mind: I'll keep adding more work for you in the meanwhile  http://drupal.org/node/1671080
[6:21pm] Druplicon: http://drupal.org/node/1671080 => Simplify configuration system, improve performance, by removing useless StorageDispatcher => Drupal core, configuration system, normal, active, 0 comments, 1 IRC mention
[6:22pm] plach: GaborHojtsy: well not sure if I miss something but that's what the patch does: it introduces a context ( call it what you like) parameter that can be used to instantiate a different controller
[6:23pm] plach: GaborHojtsy: not alternative ocntroller is provided except for the case mentioned above of profile and registration forms
[6:23pm] GaborHojtsy: reyero: send it to testing
[6:23pm] plach: * no alternative
[6:23pm] jibran joined the chat room.
[6:23pm] GaborHojtsy: plach: I think that is fine
[6:24pm] GaborHojtsy: plach: I did not follow some of the intricate details honestly, you definitely have good company with sun and fago on the issue
[6:24pm] plach: GaborHojtsy: however, I don't want to make this a blocker, I'll try a version  of the patch without this and see if the code is not too ugly
[6:24pm] ClemensTolboom: GaborHojtsy: I re-added the 'Remainging tasks' of http://drupal.org/node/1189184
[6:24pm] Druplicon: http://drupal.org/node/1189184 => Make gettext .po generation its own abstracted functionality => Drupal core, locale.module, normal, needs review, 227 comments, 64 IRC mentions
[6:24pm] plach: GaborHojtsy: yeah, I wanted mostly pm directions
[6:25pm] plach: GaborHojtsy: I can leav that part aside and just have something working committed if the resulting code is not too ugly
[6:25pm] GaborHojtsy: ClemensTolboom: the "Tests" are not very well qualified in there, what do you mean?
[6:25pm] GaborHojtsy: ClemensTolboom: also what's the difference between Doxygen and Documentation in this case?
[6:26pm] plach: reyero: did not have the time to follow your progess, but I was wondering if we can can coordinate soonr on later on the overlapping stuff for config/entity translation, I'm thinking mainly about the multilingual forms
[6:27pm] ClemensTolboom: good points .. I leave those for now … hope to spent some hours on the issue again this week … holidays are coming
[6:27pm] plach: reyero: are you ok with the plan of making both systems share the same UI elements (form langauge switcher, indicators that a particular widget is multinigual or not, and so on?)
[6:27pm] reyero: plach: sure, any time
[6:28pm] plach: reyero: I think my next step after the entity forms stuff will be
[6:28pm] GaborHojtsy: plach: right, agreed (leaving that part aside)
[6:28pm] • plach looks for the issue
[6:29pm] GaborHojtsy: plach: its a huge rework essentially moving the entity forms to OOP
[6:29pm] reyero: plach: I am not sure that is a good idea (sharing widgets), since we see what they have in common, they may have nothing, since some map to fields, some map to config arrays
[6:29pm] GaborHojtsy: ClemensTolboom: which means you want to look at it before holidays or on holidays?
[6:29pm] reyero: plach: I mean until we see whether they have anything in common
[6:30pm] ClemensTolboom: before … I have a derailed project running so 'precious time'
[6:30pm] plach: reyero: sorry I didn't mean sharing the data widgets
[6:30pm] GaborHojtsy: ClemensTolboom: I know penyaskito and attiks are generally happy to help ongoing if they feel like they are spending their time at the right place
[6:30pm] reyero: plach: you are really talking about mixing config forms and entity forms here, which I'm afraid, before seeing anything that it will make both way more complex
[6:31pm] plach: reyero: but the UI elemeents that should characterize multilingual forms, be them about config or entity
[6:31pm] ClemensTolboom: GaborHojtsy: well the discussion about the difference between code and doxygen was not well spend
[6:32pm] GaborHojtsy: ClemensTolboom:
[6:32pm] plach: reyero: my idea is that we would define a generic multingual form with a langauge switcher and little more and then config and entity forms would go their on way
[6:32pm] reyero: plach: well, yes, that makes some sense, though I'd send that to the UX department, first question being whether we want them to look the same (do we want people not being able to tell the difference?)
[6:32pm] reyero: plach: y, ok, that widgets should be reusable (language switcher, etc...)
[6:33pm] GaborHojtsy: reyero: Sutharsan, webflo1: BTW using you as "faces of D8MI sprint" to help entice people to come to Munich unless you complain of course  http://groups.drupal.org/node/238003
[6:33pm] Druplicon: http://groups.drupal.org/node/238003 => Drupal 8 Multilingual Initiative sprint before/after DrupalCon Munich 2012, needs sponsors => 0 comments, 3 IRC mentions
[6:33pm] plach: reyero: honestly I wasn't even sure your plan involved multilingual forms for the config stuff
[6:33pm] plach: reyero: or if you had different solutions in mind
[6:33pm] ClemensTolboom: gtg .. cy
[6:33pm] reyero: plach: I don't have any, the best idea I have atm are multilingual variables in i18n D7
[6:34pm] plach: reyero: ok, as I was saying before my next steps would be http://drupal.org/node/1498874, http://drupal.org/node/1498880, http://drupal.org/node/1498724
[6:34pm] Druplicon: http://drupal.org/node/1498874 => Provide language awareness to forms (introduce the form language concept) => Drupal core, forms system, normal, active, 2 comments, 2 IRC mentions
[6:34pm] Druplicon: http://drupal.org/node/1498880 => Introduce a form language switcher => Drupal core, forms system, normal, active, 0 comments, 1 IRC mention
[6:34pm] Druplicon: http://drupal.org/node/1498724 => UX: Introduce a #multilingual key (or similar) for form element => Drupal core, forms system, normal, active, 0 comments, 1 IRC mention
[6:34pm] plach: do you think we could coordinate on those?
[6:34pm] GaborHojtsy: plach: it would be super-important to start working on multilingual property storage sooner than later... we might end up with all the UI sugar in place and no way to actually store things
[6:35pm] reyero: plach: or if you look into the Variable module, there's some really reusable stuff there, like 'give me a form with only the variables that need to be translated'
[6:35pm] plach: GaborHojtsy: sure but I'd like to to have form language in place wihch should be pretty trivial to be able to submit ML fields
[6:36pm] plach: GaborHojtsy: otherwise all the entity form stuff would be useless
[6:36pm] reyero: GaborHojtsy, plach: agree with Gabor, first we need the storage, last resuource for quick UI will be a plain language switcher
[6:36pm] GaborHojtsy: plach: its easier to solve a UI in contrib then storage
[6:36pm] GaborHojtsy: plach: if we don't have storage in core, the whole effort is doomed
[6:36pm] GaborHojtsy: plach: if we don't have a UI in core, well, people will download a module
[6:37pm] webflo1: GaborHojtsy: its okay
[6:38pm] reyero: plach: so I agree about having a reusable language switcher: why don't we try adding a 'language' field type to forms API?
[6:38pm] reyero: plach: but for the rest, I'd look for what we can share / reuse later on
[6:38pm] plach: reyero: yeah, I think we have an issue for thata somewhere
[6:39pm] plach: reyero: for now it would be enough for me to know we are on the same page for the envisioned solutions
[6:39pm] plach: reyero: and it seems we are
[6:39pm] Pomliane joined the chat room.
[6:40pm] GaborHojtsy: plach: reyero: looks like we agree on the steps we want to have for forms, we don't agree on the priority for it over storage
[6:40pm] plach: GaborHojtsy: yeah, I know, but as I wrote you before if we have a UI capable of submitting ML fields/properties then banning in contrib will be harder, IMHO
[6:40pm] penyaskito: hi, I'm late, reading the logs...
[6:40pm] plach: GaborHojtsy: however the big step, entity forms, is not far from being done
[6:41pm] GaborHojtsy: plach: yup
[6:41pm] webflo1 left the chat room. (Read error: Connection reset by peer)
[6:41pm] webflo joined the chat room.
[6:41pm] plach: GaborHojtsy: form language should be farily easy, and should leav me time to work on other stuff (_> storage) in parallel
[6:42pm] GaborHojtsy: plach: for entities we need to (a) introduce language variance in property storage (b) integrate it with the UI (c) migrate existing nodes (d) drop content translation module
[6:42pm] plach: GaborHojtsy: I think I can come up witha a working patch in 2/3 hours
[6:42pm] GaborHojtsy: plach: I already have multilingual node_access() solved so it will automatically work when the relevant properties become multilingual, but not the listings yet
[6:43pm] plach: GaborHojtsy: b) is covered by entity forms + form langauge
[6:43pm] plach: once properties are fields and viceversa
[6:43pm] plach: GaborHojtsy: nice!
[6:43pm] plach: GaborHojtsy: hoenstly node grants was on the parts that scared me more
[6:44pm] GaborHojtsy: plach: working on multilingual node revision access and node grant records with kalmanhosszu
[6:44pm] GaborHojtsy: plach: I think the main question for node grants will be how you query it
[6:44pm] GaborHojtsy: plach: storing more data is easy
[6:44pm] penyaskito: ClemensTolboom, are the remaining tasks at the .po refactoring updated on the summary, don't?
[6:45pm] GaborHojtsy: plach: the queries may need to somehow follow the display language fallback logic, which sounds pretty convoluted
[6:46pm] GaborHojtsy: plach: eg. if there is no French version of something and it will display in English, then we should not deny it on the grounds of being French let's say or somesuch
[6:47pm] plach: GaborHojtsy: well in ET if the french translation is unpublished you see the english content,
[6:47pm] plach: GaborHojtsy: is this the intended behavior?
[6:47pm] plach: for D8
[6:48pm] GaborHojtsy: plach: not sure
[6:48pm] plach: GaborHojtsy: well, then we should step back and come up with a plan, right?
[6:49pm] reyero: plach: I really wish we had cleared what we want for multilingual entity forms with D7 ET module
[6:49pm] GaborHojtsy: plach: well, I think its clear we need language level access
[6:50pm] reyero: plach: btw, about this EntityFormController, I am really curious about the $context parameter, where can I read about it?
[6:50pm] GaborHojtsy: plach: we are storing sub-entities under each entity that should have its own access given that it would have its own publication status and authors
[6:50pm] plach: GaborHojtsy: in ET the idea is that if you don't have access to content in  particular langauge (be it unaccessible or unavilable) fallback is triggered
[6:50pm] GaborHojtsy: plach: and access is traditionally based on publication status and authors
[6:51pm] plach: GaborHojtsy: yes, which you more or less have in ET
[6:51pm] plach: reyero: I wish we could too
[6:51pm] reyero: GaborHojtsy, plach: I think language level access would be great to give contrib developers something to do
[6:51pm] plach: reyero: btw, there is some documentation in the entity.api.php hunk of the patch or system.api.php
[6:51pm] plach: don't remebver exactly
[6:51pm] GaborHojtsy: reyero: yeah, that is what we are trying to do with introducing language in node access grants
[6:52pm] GaborHojtsy: reyero: if we don't do it, then lists will never be able to support language level access
[6:52pm] GaborHojtsy: reyero: its very easy to support runtime language level access, we have that already in D8
[6:53pm] plach: reyero: don't expect too much from it, it's just a key identifying the form controller class to be used, however, nothing as complex as what your are dealing with
[6:54pm] GaborHojtsy: plach: probably using some other word than $context would help people not freak out
[6:54pm] plach: GaborHojtsy: reyero: so the core behavior would just be to throw 403 if there is no access to a particular translation, and skip fallback?
[6:55pm] plach: GaborHojtsy: I hate not being allowed to use the proper names, just because they are overloaded
[6:55pm] dschenk joined the chat room.
[6:55pm] reyero: y, I've had some issues with 'context' and 'plug-ins' too, they're taboo words for me now
[6:56pm] plach: reyero: well, isn't naming things the hardest thing to in CS?
[6:56pm] plach: * to do
[6:57pm] GaborHojtsy: plach: yeah, if you visit a node page in a language where it is denied, it should not fall back IMHO by default at least
[6:58pm] GaborHojtsy: plach: if that would happen, then denying access to translations of the node would not mean anything
[6:58pm] GaborHojtsy: plach: which invalidates the whole node access work
[6:59pm] e-anima left the chat room. (Read error: Connection reset by peer)
[6:59pm] plach: GaborHojtsy: even if the access to the other language is allowed?
[6:59pm] GaborHojtsy: plach: well, fallback logic is always a configuration thing, so I can imagine views supporting various things
[6:59pm] e-anima joined the chat room.
[6:59pm] GaborHojtsy: plach: eg. some people want to have their listings show nodes which does not have translations, so they show all content, others are strict about showing only specific language content
[7:00pm] GaborHojtsy: plach: if core supports the more strict method and then lets people do otherwise then its more flexible, right?
[7:02pm] GaborHojtsy: (views currently supports ignoring node access if you really want to)
[7:02pm] reyero: GaborHojtsy: by adding any idea of language in node access you'll need to sort out all these issues (agree upon reasonable defaults)
[7:02pm] GaborHojtsy: reyero: yes, but since node access is publication status and author dependent, we NEED TO put it in, or we did not implement per language publication status and authorship
[7:02pm] plach: GaborHojtsy: well, I was referring to a single entity, filtering listings by access is indeed a valid use case, but in views you have the tools to implement on or the other
[7:03pm] GaborHojtsy: reyero: eg. if I am an author to a node, I could edit all translations even if I only have "edit own articles"
[7:03pm] GaborHojtsy: reyero: or if the original version of something is published, I could access all translations even if unpublished
[7:03pm] plach: guys, I have to go, this time schedule is a bit tricky for me
[7:04pm] GaborHojtsy: plach: well, we are over time
[7:04pm] plach: GaborHojtsy: reyero: I'll happily read the logs however
[7:04pm] reyero: GaborHojtsy: Which I personally don't mind as long as they can be overridden, somewhere, but you'll need to suffer the discussion anyway (which I have no intention to participate in)
[7:04pm] plach: ciao!
[7:05pm] plach left the chat room. (Quit: ChatZilla 0.9.88.2 [Firefox 13.0.1/20120614114901])
[7:06pm] GaborHojtsy: reyero: no, its fine to not participate, I'm happy for you working on CMI stuff
[7:07pm] GaborHojtsy: reyero: currently in D8, if we'd have translatable author and status, node_access($node, $account, $langcode) would give you allow / deny based on the translated properties in the right language
[7:07pm] GaborHojtsy: reyero: and we are aiming for the same solution for node access records in the stored layer
[7:07pm] penyaskito left the chat room. (Ping timeout: 255 seconds)
[7:07pm] reyero: GaborHojtsy: you bet, I'm trying to focus, so on the other issues I just give opinions when asked for it
[7:07pm] GaborHojtsy: reyero: cool
[7:11pm] miro_dietiker left the chat room. (Quit: Leaving.)
[7:11pm] reyero: sun: about that StorageDispatcher issue, I'm fine if you want to pospone it, I'll just reopen it once every two weeks in case we don't have a better idea
[7:14pm] sun: reyero: LOLOLOL
[7:14pm] sun: That, I call a strategy
[7:17pm] reyero: sun: yup, that is a strategy and yes, I am a bad guy
[7:18pm] reyero: sun: however, do you like just the part of changing the config constructor? Config($name, ...) ?
[7:20pm] penyaskito joined the chat room.
[7:26pm] sun: reyero: I double-checked the code, and it looks like adding that $name argument to the constructor is something we could do
[7:27pm] reyero: sun: ok, then that will be in my next one, which is only about overridden values (getting rid of the awful global $conf)
[7:27pm] sun: reyero: shouldn't that be part of (or a follow-up to) the context plugin stuff?
[7:28pm] reyero: sun: Trying to do just one thing at a time, but the $config->setName() every time kind of hurts my aestetic sensibility
[7:28pm] sun: heh
[7:30pm] reyero: sun: well, yes, ideally it should be a one only patch, but it takes so long to get people on every patch discussion that I think we can reuse the thread just for that, it will be a small patch anyway.