1607729 - [project-config] Define "parsing context" when processing nested configuration files

Status: NEW

(Localization Infrastructure and Tools :: compare-locales, task)

Description

[Axel Hecht [:Pike]]

Right now, there's a couple of open ends when it comes down to handling project configs with includes and excludes. One way to think about them is a "parsing context".

locales

One thing that's undefined is how locales are handled. The way we currently implement it is that configs w/out locales specified take the locale list from the parent config. At least that's what we do for [[includes]]. For [[excludes]], the implementation right now is rather broken, :shrug:.

One interesting detail here is what it means if no configuration file has an locales entry. When there are not unqualified [[paths]] (no locales entry on the paths itself), we currently don't do anything special. There's a generated all-locales property which gathers all locales from children and paths, which is used for compare-locales, for example. But when there's really no locales field, compare-locales refuses to touch anything (unless you pass --full). One way to interpret this is to just accept whatever is on disk instead.

This interpretation could be helpful for trying to unify the code paths inside pontoon's sync code.

filters

Right now, the implementation in compare-locales only picks up filters from the top-most config file. I can see that being both a bug and a feature.

It's nice and helpful if you have shared code, but you want different rules on what's OK to ignore and what's not. Obviously, if you have shared code that has shared rules, you're hosed.

This hasn't been a real-life problem yet, as filters are rarely used, but still we should define this a bit more rigorously.

Also, is there anything to do for filters in excludes? I think no, I wonder if someone can come up with ideas on where they would be.

paths

Paths resolving is implemented to be reversed in order across imports, depth first (I guess), but it's not defined in the docs on project configs.

The spec says that additional locales in Paths would be ignored, I'm not sure that's actually a good idea. It's the currently implemented behavior, though.