Saxon

The specification states that the prefix should be output when a fallback language is used, but this seems unhelpful behaviour when the only fallback is to ignore the sublanguage.

Thanks. I'm still not able to reproduce the problem.

What operating system are you using, and what are the settings for the default language / country / locale?

The user has supplied a repro; the failure occurs on a Windows machine with system locale en-us; so far we've been unable to reproduce it. O'Neil is trying the repro on a Windows box.

We've now established that it's failing under HE but not under EE.

The conditions for the prefix to be output are that:

• the language argument is explicitly specified
• the language requested is not "en"
• the numbering is being performed using the Numberer_en class.

These conditions weren't satisfied in my tests because it was using the ICU numberer (which is only available under PE/EE).

Let's remind ourselves what the spec says: If the fallback representation uses a different language from that requested, the output string must identify the language actually used, for example by prefixing the string with [Language: Y] (where Y is the language actually used) localized in an implementation-dependent way.

It's not entirely clear, but "fallback" here presumably means that an explicit language was requested for which the product has no support.

I think there are two things wrong with the current code. (a) we're interpreting "uses a different language from that requested" too strictly; a different sublanguage should be OK. (b) we're not outputting any message if we're using ICU.

I'm reluctant to start outputting the prefix in cases where wasn't output before, because users would complain. So despite the fact that it's a non-conformance, I think that I'll keep the first test: i.e., we'll never output the prefix where ICU is used.

I'll change the second test so we only output the prefix if the first component of the requested language is something other than "en".