Stanisław Małolepszy

Yeah, totally! And I think `mach fluent-migration-test` is a great start, thanks to @Pike and @flodolo. Migrations are in fact a very good solution to the tight coupling problem :)

> Maybe just introducing some generic "post-processing" on messages in MessageContext, and then adding fluent-pseudolocale would work as the first step? That was my first thought as well. A few...

How would you decide when to turn pseudolocalization on? A different logic independent of the language negotiation?

> Yeah! This way the user can either detect pseudo from a langtag (oh, > you're using XA region?) or by some checkbox. > If the user sets their requested...

There's discussion in http://unicode.org/cldr/trac/ticket/3971 and http://unicode.org/cldr/trac/ticket/9819 on why CLDR didn't go for variant tags. It's mostly about compatibility with existing code. Also, since `en-XA` and `ar-XB` are now in CLDR...

On buildtime or on runtime?

Transforming the runtime AST means doing the transformation inside of `MessageContext`. That still might a viable option given my earlier comments: _fluent-web_ could supply a markup-aware transform function to the...

Note that the approach from [my previous comment](https://github.com/projectfluent/fluent.js/issues/83#issuecomment-338178282) will work with any scheme of specifying pseudolocales. In my example I chose to put `en-XA` in `requested` but it could also...

I find the explicit version easier to understand. It will also be easier to test.

Agreed. IIUC this issue is about the low-level API which `fluent-web` will completely hide.