Our current approach for packaging Fluent that's not ready for l10n doesn't work.
What we did was packaging the pre-release files in the same
/localization path as we will in prod.
At repack time, that breaks all kinds of things once you actually have them in localizations, as we see in bugs 1568438, 1569807.
I'm still counting on how many streams we cross, filing this in Intl right now, but I might also move this.
Here's what we need to keep from the current behavior:
- The ftl files from content are packages for all locales, as if they were localized. That's a workaround for bug 1464156.
- We can change the contents in content ftl files freely, w/out having to care about IDs.
I read the latter to mean that we can't use the localized fluent file as a drop-in replacement for a content one, in a cross-channel world. The IDs we have on l10n-central might overlap with different content-content.
Thus, we should have distinct path locations for these files. I propose that we should have use
preview/aboutLogins.ftl instead of
Now, there's an interesting question around packaging. We can continue to do what we do now, and package the files a few times. Or we could package them once in a known location in omni.ja, and add to
browser/l10n-registry.manifest a line like
category l10n-registry 0-preview resource://app/fluent-content/
(and move toolkit to 2).
Given that this would be the last location to look at in regular builds, I don't think this should come with perf problems. Maybe as a follow-up?