Should a non US fragment localize when placed on the page of another geo?

[vgoodric]

The fragment feature automatically localizes fragments to the page's geo. If an author wants to prevent this, they can add #_dnt to the end of their fragment reference.

Here is an example page: https://main--milo--adobecom.hlx.page/de/drafts/vgoodrich/fragments/localize-fragments/
and it's source file: https://adobe.sharepoint.com/:w:/r/sites/adobecom/_layouts/15/Doc.aspx?sourcedoc=%7BC57F3C6E-AA7E-4E71-9F9D-3049A52E264C%7D&file=index.docx&action=default&mobileredirect=true

Notice that the first marquee uses the DE version but the second marquee uses the US version. The fourth marquee also uses the US version as you would expect.

What I'm wondering about is the third marquee. No #_dnt is used, and yet the fragment does not localize because it's not referencing a US fragment.

This topic came up because we had someone building fragments for 6 EMEA regions (but not US). They started with a UK fragment and then copied it into the other 5 geos. But the fragment used the UK fragment in all geos until they updated the link to a non-existent US version of the fragment.

So my question is, is that what we want?

1. I think the #_dnt anchor allows authors to not localize if they do not want to, so fragments without the anchor should localize. I feel this is more intuitive.
2. But maybe some feel this a "fringe case" and because there's a simple work-around we should leave it as is. I think it is more likely to come up with the use of MEP because tests and promos may often be created by regional teams that never build a US version of the fragment.
3. Are there any pages out there that would be negatively impacted by the change? My guess is no but want to be sure.

[auniverseaway]

We very specifically say, "If you spec a locale, you are opting out of localizing a link." This is either same-locale or different locale.

Taking a non-US locale and treating it as a source of truth to make copies of other docs in different locales would also be considered an anti-pattern. You start to create a lot of overhead to support many to many relationships between locales. This also doesn't follow our localization flows... so there would be little to no localization support in assisting this behavior.

In this light, I would opt to not add complexity in our code for these types of, "what ifs" if we have firm rules and guidance already in place. If it truly becomes a pain point for actual authors, I would then revisit.

I don't want to minimize that there's knowledge and KT involved in how this works, but I think it is the lesser of evils to provide predictability and less code maintenance than to start trying to solve every different permutation of how content could be created.