I'm a little concerned that Kat might conflict with BCP 47 language tag in the future.

Unsolved problem:

• Custom translation:
  • "Discussion" vs. "Talk" vs. ...
  • "Publish" vs. "Save" vs. ...
• Custom content:
  • "This page has been protected to prevent editing or other actions. ..." vs. "This is the source code of the main page of the site. You can propose changes on ..."
  • "This action has been identified as harmful ..." vs. "This edit does not comply ..."

It looks more like something custom content vs. custom translation.

(fixed message)

In T229992#10307636, @Pppery wrote:

Xaosflux wants:

Custom en-CA -> custom en -> default en-ca -> default en

That seems right to me too - wiki customizations are more important than which variety of English is used.

In T229992#9303273, @Xaosflux wrote:

The user story in the description of this task says that you should only have to define the root language, not mirror it to every possible variant in order to override them.

In T229992#9303513, @Xaosflux wrote:

Does that mean spelling variants would need to be recreated on every WMF wiki? -- not if they are localized, only if they are on that tiny list coming from external source

The current fallback sequence:

Affects both page translation and CentralNotice.

Possibly caused by TranslateEventMessageGroupStateChange hook.

Current workaround: Edit the page for translating and mark the new revision for translation.

We could also think about whether to use private language tags (x-*) or use private use area of language subtags (qq*).

Yeah, I figured out it would be problematic for maintenance.

{{int:conversionname}} is for the user interface language conversion, which is not identical to the language converter (page content view language) conversion.

Not equivalent:

The only possible problem as far as I can see is that the ULS might not respecting the uselang priority of variant language -> site language when logged out.

I didn't see any problem as the site logo will (and should) always use the UI language, which is using the URL uselang parameter => user preference => URL variant parameter => Accept-Language priority.