How can we best support unopinionated i18n?

[ssalbdivad]

Currently, although error configs like problem are English-specific, the final ArkErrors instance returned by an invalid parse result can be directly introspected and mapped to localized errors as needed, using error.hasCode("min") or similar to discriminate the error and access associated context.

We need further documentation for these APIs (tracked in #1273), but based on some initial discussion, this may be sufficient to enable clean integrations with i18n libraries.

I wanted to open this discussion seeking other feedback on i18n and what we can do to make it as straightforward as possible without an opinionated solution.

[cgatian]

I'm finding it difficult to use this library and integrate it with i18n.

Sometimes an error message cannot be formed in "chunks" like the english support has. A string could be completely unique based on the rule and other options. For example, I've been trying to make this work but the lack of types at the various levels of error handling make it difficult.

 max: {
        expected: (ctx) => {
          // ctx.exclusive exists as an optional on `ctx` but it's too early to determine the message
          return ctx.rule.toString();
        },
        problem: (ctx) => {
          // ctx.exclusive does not exist here, I need to know whether it's exclusive or not to properly format the message
          // ts error: Property 'exclusive' does not exist on type 'ProblemContext<"max">' 
          if(ctx.exclusive) {
             return t('Must be less than {{count, INTEGER}}', {
                   count: Number(ctx.expected),
             });          
          }
          return t('Must be less than or equal to {{count, INTEGER}}', {
            count: Number(ctx.expected),
          });
        },
        message: (ctx) => {
          // I never want the default `propString` within the error messsage, It's apparent in the UI
          // This is why I just return the problem
          return ctx.problem;
        },
      },

I also found it odd that keywords can be configured on the global level, but not in the scope (or at least I havent found a way to do this). I would need keywords to be runtime configurable per scope (as the user can change their language dynamically).