Allow partial overriding of nested YAML content #142
Comments
|
+1 for this :). |
|
Hi! I agree with the premise behind this issue. We definitely need to make sure that the solution for this is "not magical" and that the behavior always meets users' expectations. We right now have an implicit "dictionary update" that occurs when localized documents are used. I think yaml anchors and aliases (see relevant section at http://rhnh.net/2011/01/31/yaml-tutorial) could be a good start towards adding this feature -- but we'll likely need to do something a little more custom to allow the anchors/aliases to work across documents. |
|
Hi folks -- I have a concept of this implemented. See sample structure below. Please note the I like that we've introduced this feature, but I'm not happy with the name of the flag As an aside: note that Grow's yaml parser fully supports aliases and anchors -- they just cannot be used across documents per the yaml spec. Attempts to alter this behavior also failed since we use libyaml directly and likely shouldn't modify it. |
|
Maybe "replace" as its replacing the contents of that level's key value? |
|
I also preferred the idea of showing in the localised section that this was going to happen. Can't we opt in to the "replace" on a per locale setting? |
|
Because you may want to totally replace the value in one locale, but update/merge in another locale? |
|
Hm, thanks for hashing this out with me -- I'm not sure that's good either since it doesn't describe how the replacement behaves. The most descriptive way to describe this behavior is a "recursive update" or a "recursive merge", but that might be too much of a mouthful to use for the config files. To answer your second question -- yes, can definitely do that. :) We can allow you to specify the replace/update/merge (whatever we're calling it) behavior on a per-locale basis. |
|
I don't suppose this would be configurable on a per-key basis instead of for all keys in the localised document? I assume we can't introduce any special syntax within the key itself because, as you mention, we are using a third-party yaml parser? I was thinking something like: The "+" is just the first symbol that came into my head for "merge". I put it at the end of the key name to try and be at least a little consistent with how strings are marked for translation with the It's highly likely that I'm missing some obvious flaw in my suggestion, it's late ;). |
|
Yeah -- that's a really nice suggestion actually. Let me iterate on a few variations of that a little. Believe it or not I'm considering deprecating the
We could leverage a custom yaml constructor to control fallback behavior as well -- |
|
How does that work when you need to pass in variables such as _(text, url="url") |
|
Just been thinking about this some more... What would happen in the case of deeply nested structures? For example I know we've done this sort of thing before: We've had cases in the past where we've needed to replace the data in section_b but leave section_a (and other data under As you can see this gets complicated (and maybe confusing). In my mind if I wanted to replace section_a for the ja locale I'd have to specify the "merge" modifier (whatever that is, just using my previous syntax here) on every parent property. Would merging child properties of structures like this work or would it only work at the top level? |
|
Hey @jeremydw have you had any more thoughts on how we might achieve this? |
|
I finally have something, including a prototype, which I'm very happy with. In this proposal, we no longer leverage multiple YAML documents for localization, but rather a "decorator" for keys in YAML documents that are localized. Because we keep everything in one document, we can now leverage YAML anchors and aliases for repeating/referencing other content. Here's an example localized document: I'm really happy with the above, and I hope that one could deduce the meaning of this content structure just by reading the YAML document. In short, keys that are localized are decorated with This allows developers to override entire blocks of YAML content (including Grow builtins like Thoughts? I'm working on finishing up some tests and then will have a prototype ready in |
|
Does this mean this will work: Means that for all locales will get the first slide but FR will get both slides? |
|
Also, does this mean that |
|
To answer your first comment: Based on how the current proposal works, no, in non-FR locales, that list item would simply be empty since Grow would discard the keys ending in Off the top of my head, to achieve "use all the root slides, and add a special slide to FR" (which I think is what you're looking to have in your example), you'd have to restructure the data slightly since YAML does not support merging lists with anchors and aliases -- it only supports merging maps (http://yaml.org/type/merge.html, http://www.yaml.org/refcard.html) Option 1: Create anchors for each slide and enumerate each slide using aliases. Option 2: Use a mapping instead of a list and use the merge key. You might think that option 2 is exactly what you want, as it appears correct. The only issue here is that mappings are unordered, and when this is serialized to JSON and yielded to the template, the order will be non-deterministic. You can fix this by always sorting the data when rendering it inside a template. For example, frequently you'd want to sort this type of data by something like a date, or alphabetically, anyway -- so hopefully the merge+mapping capability does the trick. As a result, neither option 1 nor option 2 are exactly perfect but my hopes are they're close enough. To answer your second comment: No changes to how this works today -- strings that don't end in Then the string "Hello from FR" would be extracted. Also interested in hearing any feedback from @stucox, @WillsB3, and @dcgauld. |
|
I'll very likely have some questions to add here over the next few days 🙂 On Saturday, 4 June 2016, Jeremy Weinstein notifications@github.com wrote:
|
|
Would this work? smoothies:
flavours:
- name: "Coconut"
price: 10
- name: "Strawberry"
price: 9
flavours@it:
<< : *smoothies.flavours
- name: "Amaretti"
price: 10My intended result here is that for We often have "top level" groupings of things which then contain lists of other things as per this example in our yaml files, and I'm not sure that the merge would work since it's being used within the same "parent" map (and I guess that |
|
Alternatively, given the above proposal, would this be the way to achieve it? smoothie_flavours: &smoothie_flavours
- name: "Coconut"
price: 10
- name: "Strawberry"
price: 9
smoothie_flavours@it: &smoothie_flavours@it
<< : *smoothie_flavours
- name: "Amaretti"
price: 10
smoothies:
... lots of other things ...
flavours: *smoothie_flavours
flavours@it: *smoothie_flavours@itThis seems pretty strange/complex though. |
|
The former would work, although you'll need to add an anchor for On Thu, Jul 7, 2016 at 5:23 AM, Wills Bithrey notifications@github.com
jeremydw |
|
That's good news, I honestly didn't expect that to work :) |
|
Okay, #239 is merged! Time to resume work on this feature. |
* Use remap instead of walk for translation untagging. #142 * Implement localized field untagging, add tests covering documents. #142 * Add additional test coverage for lists. #142 * Implement fix for string tagging, handling unordered dictionary. #142 * Add test verifying behavior for tagged, localized strings. #142 * Fixes #142
A section of an example YAML file:
The above YAML is used in the default locale (en_US). If in the en_IN locale I want to override just the promo section, using the code below would override the whole sections object:
Obviously the desired outcome is that we only affect the promo subsection.
/cc @meizon
The text was updated successfully, but these errors were encountered: