Global Metadata: split by geo

[3ch023]

EDS allows splitting the global metadata file into several separate files.
The consumer projects like CC are using 1 file for all geo's. At the moment there is no big issue with that and BACOM proves that it is possible to maintain a file with a large number of lines (56k currently for bacom)

However, if we have a separate metadata file in each geo folder I would expect:

• authors to be more confident in doing the changes for their geos, without risking breaking something for another geo
• less need for the 'blocking' of the file during go-lives, see the screenshot below
• less risk in general to break something worldwide, impact reduced to 1 geo

As we are in the early stage, this split is easy to do. We would need:

• create 1 metadata file and with LOC roll it out to 93 folders
• configure in helix/.config additional metadata files
• optional, but good to have - introduce validation in each excel, so that authors could only add URL entries that start with respective geo, e.g. in /de/metadata.xlsx you can't specify URL as '/fr/**'. This will prevent overrides by mistake.

WDYT?

[mokimo]

This is up to consumers, but I've heard a lot of complaints from GWP. Authors are scared to break things, splitting up the metadata file in smaller chunks would enable GWP to confidently push changes. In the worst case scenario, only one geo would be broken.

I'm all for it. 👍

[mokimo]

A question about the EDS feature, is it still possible to still roll out global changes?
So target /** from a root metadata file and roll out changes to ALL pages for a specific consumer?

[3ch023]

So target /** from a root metadata file and roll out changes to ALL pages for a specific consumer?

yes, it would be still possible.
I would keep this filter only in the us/en metadata file though, to avoid conflicts and overrides. with excel validation rules on the column we can control what glob filters are possible in each geo.

[auniverseaway]

I think a metadata per locale makes the most sense from our recommendation perspective. To @mokimo's point, if a consumer with low needs doesn't need that, we shouldn't force it on them.

Forgive my ignorance, but does this mean certain changes will need to be kept in sync or will they roll up to the singular metadata file if there's a match there?

[3ch023]

tbh, I am not sure I did get your question. Still will try to answer :)
The way I see it:

1. we create an empty file in us/en.
2. we roll out this file to 93 geo folders (just to save time)
3. we never do a rollout again and never sync the us/en with ROW - the files become completely independent.

If there is a new common metadata setting that is needed for all geo's, GWP should just set it once in us/en metadata with the glob '/**'

Pls let me know in case I've misunderstood what you were asking.

[overmyheadandbody]

I remember that Dermot was also looking for such a feature, so it definitely sounds good on paper.

But I'm also not clear on how this would work. File-level metadata obviously stays the same. What I'm curious about is global metadata vs local metadata.

Say that global metadata currently has these entries:

URL	my-metadata
/**	global
/de/**	german

So what you're suggesting is that through some process, we split that Excel file into a global (/**) and a local (/de/**) one? Which would take final precedence if the same metadata field is defined in both? Or do you envision just a lot of locale-specific metadata files with no way of defining something global, asking authors to go through 90+ folders for any global change?

Another question: how would we define locale folders? Since different consumers have different locales, from an EDS perspective any folder could be a locale. Is there any documentation to clear this up?

[3ch023]

I would suggest configuring it like this.
Instead of currently existing 1 global /metadata.xlsx, we will have (in helix/.config):

1. /metadata.xlsx
2. /de/metadata.xlsx
3. /fr/metadata.xlsx
4. ...

The priority is evaluated top down, so first global (/**) glob will apply to a page and later geo specific (/de/mypage) can override it.

/metadata.xlsx entries

URL	my-metadata
/**	global
/products/**	products-specific

/de/metadata.xlsx entries

URL	my-metadata
/de/**	german
/de/products	german products

/metadata.xlsx is a combination of global + us/en metadata.
So, /metadata.xlsx can have global (/**) and us/en entries, but can't have geo folder entries (/de, /fr etc).
/de/metadata.xlsx can only have entries starting from /de. No global (/**) entry is possible.

Validation

is very important. to avoid errors we will need to restrict excel columns with the rules outlined above. but it is possible.

[3ch023]

Another question: how would we define locale folders?

Each consumer could define their locale folders. helix/.config is a consumer-specific file, so whatever you will configure there will be your valid list of locales with locale-specific metadata files.

[vhargrave]

I think in general what you're saying is a good idea, but don't think you need to restrict the excel columns like you were saying, because that makes everything too complicated.
What if authors want to manage content for lesser used locales like ch_de in the global folder and get more specific with tier 1 locales like /fr . Then we need to adjust the logic for them.
For me it's simpler to just say metadata can be set in the global file (/**), the specific locale file (/de/**), or the word doc. And the weight of which metadata wins is also in that order.

[fwelterlin]

I am in favor, anytime we split off critical content from large docs and into smaller docs, this is a good thing for us in GWP because it helps minimize the risk of "toe stepping" between the dozens of authors all over the world...

[gabr1ela]

hi, very good topic and one we've been working on since last year when Franklin introduced the ability to add more than 1 metadata file thanks to a request from us :).

The quick answer is yes but not yet. We are taking a phased approach on the data management side.

For redirects, placeholders, and metadata* files:

1. We have restricted access to gwp owned files to "curators" only.
2. Need to standardize the use of these across projects. Number of files, owners, self service needs, etc.
3. Get complete requirements from gwp, self-service, and regions to divide up files.
4. Provide a good way to "stage" changes and minimize risk of pre announcement.
5. Communicate every step of the way.

End game for certain files: provide a better user experience for content management, focusing on redirects and canonicals first.

If you have questions or recommendations, let me know.

[overmyheadandbody]

Is there anyone leading this discussion with GWP? This request is coming from multiple places (request for Milo Core, for example), so it would make sense to get some resources to coordinate this initiative.