[6:02pm] GaborHojtsy: hi everyone!
[6:02pm] Hydra1 left the chat room. (Read error: No route to host)
[6:02pm] webchick: greetings!
[6:02pm] floretan_ left the chat room. (Read error: No route to host)
[6:02pm] GaborHojtsy: let's start our meeting!
[6:02pm] ¥ hejrocker waves
[6:02pm] GaborHojtsy: first, current stuff
[6:03pm] GaborHojtsy: there is a minimal number of issues needing attention right now
[6:03pm] GaborHojtsy: http://drupal.org/node/1357918 needs a review
[6:03pm] Druplicon: http://drupal.org/node/1357918 => Missing update for language_default in language langcode update => Drupal core, language system, major, needs review, 43 comments, 4 IRC mentions
[6:03pm] GaborHojtsy: I think its done
[6:03pm] GaborHojtsy: hope to get the review from sun
[6:03pm] GaborHojtsy: sun: hi
[6:03pm] yched left the chat room. (Ping timeout: 258 seconds)
[6:04pm] GaborHojtsy: we have plenty in the RTBC queue, hope catch can get to them and will see them good
[6:04pm] GaborHojtsy: and we need tests fixing in http://drupal.org/node/1280538
[6:04pm] Druplicon: http://drupal.org/node/1280538 => Language negotiation UX: default the path prefix setting on installation so that it actually works right away => Drupal core, language system, normal, needs work, 33 comments, 5 IRC mentions
[6:04pm] GaborHojtsy: I should post my experimentation there after the meeting
[6:04pm] GaborHojtsy: anybody interested in looking at that?
[6:04pm] GaborHojtsy: I talked to plach and he does not have time
[6:04pm] GaborHojtsy: unfortunately
[6:06pm] GaborHojtsy: ok, well, I take that as nobody
[6:06pm] GaborHojtsy: next up (before we move on to config languages/translations discussion)
[6:06pm] GaborHojtsy: I just posted http://groups.drupal.org/node/203523
[6:06pm] Druplicon: http://groups.drupal.org/node/203523 => In-person sprints planned for the Drupal 8 Multilingual Initiative in 2012 => 0 comments, 1 IRC mention
[6:07pm] GaborHojtsy: I pinged some people with this plan before but would love a reality check
[6:07pm] GaborHojtsy: i.e hope to not sprint all alone
[6:08pm] hejrocker: GaborHojtsy, I am planning on doing a great amount of CMI sprinting as well, so maybe we can sprint together
[6:08pm] GaborHojtsy: hejrocker: that is good  I basically picked the largest US event this year and the two largest EU events
[6:08pm] attiks left the chat room. (Ping timeout: 244 seconds)
[6:08pm] GaborHojtsy: hejrocker: so if you are around in the EU I guess the dev days might be a good date target for you too
[6:09pm] hejrocker: GaborHojtsy, unfortunately Dev Days is out for me unless someone pays my way. i'll be back in the states long before then
[6:09pm] hejrocker: im hoping to get scholarship for munich
[6:09pm] GaborHojtsy: hejrocker: yeah, that is what I thought
[6:09pm] yched joined the chat room.
[6:10pm] GaborHojtsy: anyways, comments on http://groups.drupal.org/node/203523 would be welcome to indicate interest
[6:10pm] Druplicon: http://groups.drupal.org/node/203523 => In-person sprints planned for the Drupal 8 Multilingual Initiative in 2012 => 0 comments, 2 IRC mentions
[6:10pm] GaborHojtsy: ok
[6:10pm] GaborHojtsy: I don't have any "current" quick topics
[6:10pm] GaborHojtsy: so I think we can move to CMI language/translation unless someone objects
[6:11pm] hejrocker: horray!
[6:11pm] ¥ yched lurks
[6:11pm] hejrocker: So for anyone who hasn't seen, the original proposal and discussion are at http://groups.drupal.org/node/185609
[6:11pm] Druplicon: http://groups.drupal.org/node/185609 => Internationalization of Drupal 8 configuration => 4 comments, 2 IRC mentions
[6:12pm] GaborHojtsy: yup
[6:12pm] attiks joined the chat room.
[6:12pm] hejrocker: I think that proposal is still pretty solid, as long as we agree that we are just doing internationalization in CMI and not writing a generalized context solution
[6:13pm] hejrocker: I mention in there the issues around pulling the correct strings from the active store, and I think we can solve that by adding another column to the config table with language in it
[6:13pm] hejrocker: so you would have
[6:13pm] hejrocker: en | system.performance.settings | <xml>
[6:14pm] hejrocker: se | system.performance.settings | <xml?
[6:14pm] hejrocker: etc
[6:14pm] hejrocker: and the files as described would remain as described
[6:15pm] hejrocker: anyone confused yet?
[6:16pm] yched: nope
[6:16pm] GaborHojtsy: hm
[6:16pm] GaborHojtsy: looks logical
[6:16pm] hejrocker: there is still a discussion to be had about whether that is a) the full xml or b) just the changes from some master set
[6:17pm] hejrocker: or changes from site default language
[6:17pm] hejrocker: i guess
[6:17pm] hejrocker: i get a little confused about how that works still
[6:17pm] hejrocker: but basically, if its full xml, then we have a more complicated update operation (because we may have to update multiple files, but only some of the information)
[6:17pm] attiks left the chat room. (Ping timeout: 276 seconds)
[6:17pm] GaborHojtsy: yes, question is if you need to look up the site name let's say, how would you know which field to look it up in?
[6:18pm] hejrocker: if its not we have a more complicated deployment operation (because you have to deploy all the files for a view potentially, not just one)
[6:19pm] webchick: hejrocker: Is that actually more complicated deploy? Aren't I just going to swoosh over all files that git tells me have changed every time anyway?
[6:19pm] hejrocker: GaborHojtsy, it would be in the same field as always. when you request the info, you specify a language (or it uses site default). it then looks into the language-specific file and sees if its there. if not, it takes the default one
[6:19pm] hejrocker: webchick, we had hoped that you could just say one change = one file
[6:19pm] webchick: Ahh, I see.
[6:19pm] hejrocker: and in most cases you actually will
[6:19pm] hejrocker: but in this scenario its not guaranteed
[6:19pm] webchick: hejrocker: Can you concat multiple version of the XML in the same file?
[6:19pm] hejrocker: webchick, it gets complicated and it makes it harder to restore from defaults
[6:19pm] webchick: Right ok
[6:20pm] hejrocker: it also means you are often storing info you ownt use
[6:20pm] hejrocker: we had originally talked about merging the data in, but that has the same complexities
[6:20pm] attiks joined the chat room.
[6:20pm] GaborHojtsy: hejrocker: so basically each config lookup would be two queries?
[6:20pm] GaborHojtsy: hejrocker: when falling back
[6:21pm] GaborHojtsy: hejrocker: the path alias system has a tricky solution ordering by language column desc and looking for language empty or specific
[6:21pm] hejrocker: GaborHojtsy, possibly yes. another option is we always grab both and merge the differences in. however that is also two queries
[6:21pm] GaborHojtsy: hejrocker: but that is pretty custom and much simpler
[6:22pm] GaborHojtsy: hejrocker: yeah, emerging on lookup sounds like a performance problem (why not store the merged values then?)
[6:22pm] GaborHojtsy: merging that is
[6:22pm] hejrocker: the problem with storing merged info is that when we change something, we have to determine where to update
[6:22pm] GaborHojtsy: yup
[6:22pm] hejrocker: also, is this just for strings, or are we talking about locale-specific settings as well?
[6:24pm] hejrocker: david has made the argument that local-specific settings should be outside the scope of CMI (although I'm not sure its really any extra work when it comes down to it)
[6:24pm] GaborHojtsy: hejrocker: Drupal does not currently have locales (eg. UK or US)
[6:24pm] hejrocker: GaborHojtsy, well what i mean is are we looking to enable site caching off if your language is swedish, and on if your language is english
[6:25pm] GaborHojtsy: hejrocker: ok, so language specific, not locale specific  let's get out terminology straight now that we have this beautiful language module in D8
[6:25pm] hejrocker: yeah sorry im new t this
[6:26pm] GaborHojtsy: hejrocker: right, well, "settings" are well, "everything"? I mean the welcome email text is a setting
[6:26pm] hejrocker: right thats what i was triyng to think through
[6:26pm] GaborHojtsy: hejrocker: my working assumption was that from CMI's perspective, the data type being stored can be anything
[6:26pm] hejrocker: right ok
[6:27pm] yched: Thing is, the structure and nesting of a given XML file can vary depending on the "value" of the config item being stored
[6:27pm] hejrocker: i mean, its possible some of the merging difficulties could be solved by marking things not translateable
[6:27pm] GaborHojtsy: hejrocker: I think the two keys things are (a) that people can store language specific values (b) each load operation for the config passes language info as proper
[6:27pm] yched: e.g image styles with N or M effects
[6:27pm] GaborHojtsy: hejrocker: most pains in the i18n module come from (b) not happening at all
[6:27pm] hejrocker: yched actually right now its the same structure with 1 or 10 effects
[6:28pm] hejrocker: its just a matter of how many you iterate through
[6:28pm] GaborHojtsy: hejrocker: I think we'll want to have non-translatable config, yes
[6:28pm] yched: hejrocker: ok - less sure about fields / instances
[6:28pm] hejrocker: GaborHojtsy, ok thats something we'll have to manage
[6:28pm] GaborHojtsy: hejrocker: eg. if you need to store a whole view
[6:28pm] hejrocker: yched sounds like field.module's problem
[6:29pm] yched: hejrocker: it is, which worries me
[6:29pm] GaborHojtsy: hejrocker: its very unlikely people want to translate fields on them (the list of fields), but they want to translate the labels, override text, etc.
[6:29pm] GaborHojtsy: fun stuff
[6:29pm] hejrocker: GaborHojtsy, yes those issues are the ones that worry me a lot
[6:30pm] ¥ hejrocker asks if anyone wants to donate yched a bunch of money to come to denver
[6:30pm] GaborHojtsy: hejrocker: I imagine when a view is loaded it is load_config_for_me_now($view_name, $language)
[6:30pm] GaborHojtsy: hejrocker: and the loader will figure out where is translation available
[6:30pm] GaborHojtsy: hejrocker: its VITAL that language is passed at ALL places possible
[6:31pm] GaborHojtsy: hejrocker: I think the loader will need to be able to merge arbitrary structures anyway
[6:31pm] GaborHojtsy: hejrocker: the translatable thing can have any structure I guess
[6:31pm] svendecabooter left the chat room. (Remote host closed the connection)
[6:31pm] hejrocker: GaborHojtsy, the problems come into play when, for instance, someone changes one piece of information on a site that has six languages enabled. we have to go through every file and determine if we are supposed to save out this piece of data or not
[6:31pm] GaborHojtsy: hejrocker: maybe its an image and a caption for an image
[6:31pm] Hydra1 joined the chat room.
[6:31pm] GaborHojtsy: hejrocker: in which case you need the image path and caption configured per language maybe
[6:31pm] floretan left the chat room. (Read error: No route to host)
[6:31pm] floretan_ joined the chat room.
[6:31pm] hejrocker: yes sure
[6:32pm] Hydra11 left the chat room. (Read error: Connection reset by peer)
[6:32pm] GaborHojtsy: hejrocker: yeah, well that is what fields solve with metadata on fields, so it can pull up whether it was translatable
[6:33pm] yched: "we have to go through every file and determine if we are supposed to save out this piece of data or not" - yup
[6:33pm] yched: that is what worries me
[6:33pm] hejrocker: this is part of what i was getting at about settings vs strings but referring to it the wrong way i think
[6:33pm] yched: knowing what to update on ConfigurableThingy->save()
[6:33pm] berdir left the chat room. (Ping timeout: 252 seconds)
[6:33pm] hejrocker: well there are two ways to approach that
[6:34pm] hejrocker: 1) We add metadata and stuff, so the config system knows what stuff to worry about stuff is saved where
[6:34pm] hejrocker: 2) We add config->save(data, language) and just save and its up to the people passing it in to figure out
[6:34pm] ¥ hejrocker likes 2
[6:34pm] hejrocker: i dont know if it will fly
[6:35pm] GaborHojtsy: hejrocker: well, unless data contains all languages, you need to have language on save() anyway
[6:35pm] hejrocker: yes i suppose that is true
[6:35pm] GaborHojtsy: hejrocker: not sure how that solves the problem
[6:35pm] GaborHojtsy: hejrocker: if you only want to save the values that are different from the original
[6:35pm] plach left the chat room. (Quit: ChatZilla 0.9.88 [Firefox 9.0.1/20111220165912])
[6:35pm] hejrocker: its really just a question of whose responsibility it is to put the data in the right place
[6:35pm] yched: it means some_view.de.xml is left untouched unless you explicitely do $config>save($some_view, 'de') ?
[6:36pm] GaborHojtsy: hejrocker: save() would need to have a copy of the original and compare, and then update the translation or something
[6:36pm] hejrocker: GaborHojtsy, well i dont know if that is possible
[6:36pm] hejrocker: yched yeah
[6:36pm] hejrocker: and i mean
[6:36pm] hejrocker: does that mean that the caller has to explicitly save in every language posisble?
[6:36pm] hejrocker: or...
[6:37pm] hejrocker: like i save a view, i change the title
[6:38pm] ¥ hejrocker might be making assumptions about things that don't matter here
[6:38pm] GaborHojtsy: hejrocker: I think you need to specify language anyway when saving unless your data has all languages present
[6:38pm] yched: ... then I switch to 'de', re-edit the view, put the correct new translated title, save ?
[6:38pm] GaborHojtsy: hejrocker: in that case, you still need to separate the non-translated from translated, because your data will be complete and merged
[6:38pm] hejrocker: yched ok thats what i was wondering
[6:39pm] teknico left the chat room. (Remote host closed the connection)
[6:39pm] yched: and then what if I changed more critical stuff than just the title (like, added a new filetr...)
[6:39pm] hejrocker: are we still going to have the undefined language in d8?
[6:39pm] GaborHojtsy: hejrocker: I think its fine if the original values are only overridden when you specify that language
[6:39pm] hejrocker: yched well that's where we start talking about translateable vs untranslateable
[6:39pm] yched: I mean :
[6:40pm] GaborHojtsy: hejrocker: that assumes you DO have metadata on which pieces are translatable
[6:40pm] hejrocker: yes
[6:40pm] yched: what if, while being in 'de', I change structural stuff in the view ?
[6:40pm] hejrocker: yched it depends, do we want the ability to have a view with 10 items in the pager for DE and 12 for FR?
[6:40pm] GaborHojtsy: yched: if we have no metadata about what is translatable, that would mean you changed your structure for de
[6:41pm] hejrocker: right, which some would view as a feature and some as a bug
[6:41pm] yched: only works if all languages contain a full copy of the XML
[6:41pm] yched: not only diffs
[6:41pm] GaborHojtsy: yched: if we have metadata, it could mean you either changes the original view or that those changes cannot get through (or maybe even not displayed on the UI)
[6:41pm] hejrocker: yes
[6:41pm] GaborHojtsy: the translation UI would benefit a lot from metadata on what is translatable
[6:42pm] yched: We need metadata, that's for sure
[6:42pm] hejrocker: if we assume everything is translateable, and we store complete xml for all files, then actually life is pretty easy
[6:42pm] yched: hejrocker: hmmm, not so sure
[6:42pm] hejrocker: no?
[6:42pm] GaborHojtsy: hejrocker: but its very easy to screw up on the UI so the translation UI would need to be able to limit the screw-up possibilitties
[6:42pm] yched: not easier UI wise for the end user
[6:43pm] hejrocker: it would be the same for the end user, its just about the scope of the changes
[6:43pm] GaborHojtsy: hejrocker: a huge part of the i18n module's config translation code is about describing the config structures and which pieces are translatable
[6:43pm] yched: because you need to re-do "add a filter and 3 fields to my view" in every language
[6:43pm] yched: is a view is a "different" beast in every language
[6:43pm] hejrocker: yched right but some people would consider the ability to make it different per language a feature
[6:44pm] yched: you can't really keep them in sync
[6:44pm] hejrocker: no
[6:44pm] GaborHojtsy: hejrocker: yup, that is why it could be configurable
[6:44pm] GaborHojtsy: hejrocker: however, separate views per language is not really a default feature we are looking for
[6:44pm] GaborHojtsy: hejrocker: people can do that now
[6:44pm] hejrocker: GaborHojtsy, making it configurable by the user what is and isnt translateable sounds like a disaster
[6:44pm] hejrocker: that is not necessarily a scope i feel comfortable taking on
[6:45pm] GaborHojtsy: hejrocker: well, you are not thinking of any UI scope anyway, right?
[6:45pm] hejrocker: no but i would still need to account for a) arbitrary pieces of data being translateable b) having suffiecient metadata to detect that c) detecting and applying that metadata as applicable
[6:46pm] GaborHojtsy: hejrocker: as per above, we discussed we need that metadata anyway?
[6:46pm] GaborHojtsy: hejrocker: how its different that the user can change the metadata?
[6:46pm] yched: I'd really favor "a View is the same in every language - A node type has the set set of fields in every language - etc..."
[6:46pm] hejrocker: yes but if we specify it in advance, its a known quantity. the metadata not changing means we can make assumptions about the metadata
[6:47pm] yched: A "Thing" is a structured definition, with some identified places (values) being translatable holes
[6:47pm] GaborHojtsy: hejrocker: its still code provided, so if I update my module, it could change
[6:47pm] hejrocker: GaborHojtsy, right but thats your problem not mine. i dont have to provide you an interface to make the change
[6:48pm] GaborHojtsy: hejrocker: last we talked you were not planning on any UI component for CMI
[6:48pm] attiks left the chat room. (Ping timeout: 244 seconds)
[6:48pm] hejrocker: GaborHojtsy, i mean interface in the api sense
[6:48pm] GaborHojtsy: hejrocker: well, somehow the module will be updated and need to change that metadata understanding
[6:49pm] hejrocker: GaborHojtsy, right and right now i can say 'if you want to change the metadata, then ffeel free and change it all yourself by hand, and when you update i'll grab it' as opposed to 'i have to provide support in the api for metadata being changed arbitrarily, iterating the files, finding the data points, changing them, potentially updating a bunch of thigns, etc'
[6:50pm] attiks joined the chat room.
[6:50pm] GaborHojtsy: hejrocker: well, if I suddenly update from views 8.32 to 8.33, the metadata change will need to trickle down to the config storage I guess anyway, so it needs to be coded anyway
[6:51pm] GaborHojtsy: hejrocker: maybe it will only run on module updates not on a form submission, but its the same code
[6:51pm] hejrocker: GaborHojtsy, right and in that cases it is views' problem to manage that. i just save whatever it gives me
[6:52pm] svendecabooter joined the chat room.
[6:52pm] hejrocker: its a matter of whose responsibility it is to make these changes to the structure
[6:52pm] GaborHojtsy: hejrocker: yeah, I recognize it is easier to code on the core side, it makes lots of repeated work necessary for module authors
[6:53pm] GaborHojtsy: maybe we'll need a cmi_update module then that people will require
[6:53pm] hejrocker: GaborHojtsy, i understand that but i also have to manage the scope of the project in order to maintain a level of confidence i can get it done in time
[6:53pm] GaborHojtsy: sure, sure
[6:53pm] Hydra1 left the chat room. (Read error: No route to host)
[6:54pm] Hydra1 joined the chat room.
[6:54pm] hejrocker: GaborHojtsy, i think i need more time to think this over
[6:54pm] floretan_ left the chat room. (Read error: No route to host)
[6:54pm] floretan joined the chat room.
[6:54pm] GaborHojtsy: hejrocker: the #1 thing I'm looking for in CMI is that *every* place where config is loaded or saved, the language would be passed
[6:54pm] hejrocker: GaborHojtsy, that part is easy to add, and its easy to address with the data structures defined above
[6:54pm] GaborHojtsy: hejrocker: the #2 is that the language version is actually stored and retrieved
[6:55pm] hejrocker: i think the big question at this point is really about the issues surrounding items that are or aren't translateable
[6:55pm] yched: Crazy thought: only store string ids in XML files, and store actual translated strings in a flat place somewhere else - merge in the the active store.
[6:55pm] hejrocker: which worries me a bit, i have tried desperately to make this system as dumb as possible
[6:56pm] hejrocker: yched i wish we would do that everywhere in core
[6:56pm] hejrocker: i think im on the losing end of that battle though
[6:56pm] hejrocker: that would certainly make this easier though
[6:56pm] yched: "in code" is a hard sell, but in config files, who cares ?
[6:56pm] hejrocker: yeah, its worth thinking about
[6:57pm] GaborHojtsy: yched: how would that solve the merge/translatable problem?
[6:57pm] xcono: are you about translate field labels?
[6:57pm] hejrocker: it means we only ever have one xml file, which solves a lot of complexity right there
[6:57pm] yched: yup
[6:58pm] yched: config doesn't need to wonder which exact {$langcode}.xml file to save and what to put in them
[6:58pm] hejrocker: it still needs to know which langcode,txt file to save in
[6:58pm] hejrocker: or whatever
[6:59pm] xcono left the chat room. (Quit: ChatZilla 0.9.88 [Firefox 9.0.1/20111220165912])
[6:59pm] hejrocker: but since those are a flat structure, its a lot less complicated
[6:59pm] yched: sure, but the object (view, node type...) itself remains teh same
[6:59pm] hejrocker: right
[6:59pm] yched: right
[6:59pm] yched:
[6:59pm] GaborHojtsy: hejrocker: ok, but then we definitely need to have metadata, since otherwise we'd save all "strings" in those text files
[6:59pm] hejrocker: yes
[7:00pm] hejrocker: i have to think that thorugh
[7:00pm] yched: yup, still needs metadata, and somthing that was translatable in 1.0 might not be anymore in 2.1, or reversedly
[7:00pm] hejrocker: my instinct would be to make that attributes, but that has far-reaching effects
[7:00pm] GaborHojtsy: hejrocker: I think the original problem was that you need to have those text files for single language sites then
[7:00pm] GaborHojtsy: hejrocker: even if you don't have multiple langugaes
[7:00pm] hejrocker: im fine with that
[7:01pm] GaborHojtsy: hejrocker: if we don't care inflicting pain on single-language and even English sites...
[7:01pm] dealancer joined the chat room.
[7:01pm] hejrocker: i dont think its pain, to them it shouldn't be an issue
[7:01pm] hejrocker: well
[7:01pm] hejrocker: it does mean that a single language site has two files to push for a view
[7:01pm] dealancer left the chat room. (Read error: Connection reset by peer)
[7:01pm] dealancer joined the chat room.
[7:02pm] GaborHojtsy: hejrocker: well, if it does not slow them down
[7:02pm] yched: "slow" would be solved by merging before writing the active store
[7:03pm] hejrocker: yeah this would be a write-only slowdown i think
[7:04pm] yched: OK - what if the flat list of translated strings is appended within the xml file ? in a <strings> struct after the main <config> entry
[7:04pm] GaborHojtsy: I think you got pushback on that not from the multilingual people
[7:04pm] hejrocker: to some extent i suspect that, like many othe things, we will sort a lot of this out once implementation starts
[7:06pm] yched: I'm not sure we even care if the list of "translatable" properties changes from views 3.n to 3.n+1
[7:06pm] berdir joined the chat room.
[7:06pm] hejrocker: well in taht case, i defintiely say its views' problem to handle the updates
[7:06pm] hejrocker: we can only be responsible for so much
[7:06pm] GaborHojtsy: well, if all strings are stored independent
[7:06pm] yched: maybe we can always to something "acceptable" with the content of the xml
[7:06pm] GaborHojtsy: then no update is required
[7:06pm] hejrocker: thats what i like about the update process we defined, we just push it off to eht modules
[7:06pm] yched: always *do
[7:07pm] yched: if a property becomes translatable, that what the old files have is a hardcoded value - fine, we use that
[7:07pm] hejrocker: right and you break the strings out
[7:08pm] yched: if a property becomes untranslatable, then the xml still has the old translated values and we can use the one in the default language
[7:08pm] ¥ hejrocker wonders if webchick has any thoguhts about any of this or if she is even paying attention anymore
[7:09pm] hejrocker: yched GaborHojtsy does the concept of 'undefined' as a lnaguage exist any more in d8?
[7:09pm] yched: oh crap, sorry folks, I like *really* need to run right now
[7:09pm] hejrocker: ok see you, thanks for coming!
[7:09pm] yched:
[7:09pm] yched: bye !
[7:10pm] yched left the chat room. (Quit: Page closed)
[7:10pm] GaborHojtsy: hejrocker: well, it is specially used for content, tyes
[7:10pm] GaborHojtsy: hejrocker: I want to eventually add it to the language list as a configurable piece
[7:10pm] GaborHojtsy: hejrocker: anyway, anything that can have a language meaning should store what language it was stored in
[7:10pm] hejrocker: im curious if we have to have exceptions or special handling for that, i admit i dont completely understand it
[7:11pm] webchick: sorry, I am not paying attention; I have a DA meeting atm. But i'll catch up after.
[7:11pm] hejrocker: ok
[7:11pm] GaborHojtsy: hejrocker: so a view is saved in English, all the "translatable" == "language aware"(?) field should be assigned the language it was saved with
[7:11pm] hejrocker: GaborHojtsy, would it be possible to have a view saved in 'Undefined'?
[7:12pm] GaborHojtsy: hejrocker: yeah, I guess... LANGUAGE_NONE is used for that for nodes, so you can have a node saved as "Language neutral"
[7:12pm] hejrocker: o
[7:12pm] hejrocker: k
[7:12pm] GaborHojtsy: hejrocker: which is mostly understood as "has no linguistic content"
[7:12pm] GaborHojtsy: hejrocker: I assume certain configuration things will want to support that, not sure about views
[7:12pm] GaborHojtsy: hejrocker: but THAT can be in the park for views
[7:12pm] GaborHojtsy: hejrocker: not for CMI
[7:12pm] GaborHojtsy: hejrocker: I mean the UI and selection, etc.
[7:13pm] hejrocker: GaborHojtsy, well let me think this through a bit, im going to try and have a irc meeting next week to talk about update process, and we can talk about this as well
[7:13pm] GaborHojtsy: hejrocker: CMI should be able to store language neutral config structures but overall most structures are language "dependent"
[7:13pm] hejrocker: my time is getting pretty messy though
[7:13pm] GaborHojtsy: hejrocker: yeah, well, congrats for the new venture
[7:13pm] hejrocker: thanks
[7:13pm] hejrocker: maybe you should say congratudolences
[7:14pm] hejrocker: i leave in 2.5 weeks, not a ton of time to plan
[7:14pm] GaborHojtsy: hejrocker: well, it was your choice as I've read
[7:15pm] GaborHojtsy: hejrocker: sounds exciting
[7:15pm] GaborHojtsy: anyway, I'll try to pop by next week on the CMI meeting then, not guaranteed
[7:16pm] hejrocker: ok cool
[7:16pm] hejrocker: i will try and write up some of these thoughts and add them to the gdo thread
[7:16pm] GaborHojtsy: hejrocker: ok, superb
[7:16pm] GaborHojtsy: need to go now... made a quick record of the IRC log and will post later
[7:17pm] GaborHojtsy: hejrocker: great discussion!
[7:17pm] GaborHojtsy: hejrocker: thanks for making the time
[7:17pm] hejrocker: GaborHojtsy, you too! thanks