Project

Profile

Help

Bug #4582

closed

format-date() with language="en-GB" prefixes the output with "[Language: en]"

Added by Michael Kay almost 4 years ago. Updated over 3 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Localization
Sprint/Milestone:
-
Start date:
2020-06-12
Due date:
% Done:

100%

Estimated time:
Legacy ID:
Applies to branch:
10, 9.9
Fix Committed on Branch:
10, 9.9
Fixed in Maintenance Release:
Platforms:

Description

Raised by direct email

Details: When we call format-date function, we pass language parameter as en-gb. I have changed it to en, then it works fine.

Documentation states: The $language argument specifies the language to be used for the result string of the function. The value of the argument should be either the empty sequence or a value that would be valid for the xml:lang attribute (see [XML]). Note that this permits the identification of sublanguages based on country codes (from [ISO 3166-1]) as well as identification of dialects and of regions within a country.

But it is not clear to me what format should I use for specifying sublanguages.

What format is supported by Saxon for language parameter of format-date function?

Any ideas for what is causing our problem with date strings handling?

Actions #1

Updated by Michael Kay almost 4 years ago

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.

Actions #2

Updated by Michael Kay over 3 years ago

  • Status changed from New to AwaitingInfo

I'm currently unable to reproduce the problem and have requested further information from the customer.

Actions #4

Updated by Michael Kay over 3 years ago

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?

Actions #5

Updated by Michael Kay over 3 years ago

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.

Actions #6

Updated by Michael Kay over 3 years ago

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

Actions #7

Updated by Michael Kay over 3 years ago

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.

Actions #8

Updated by Michael Kay over 3 years ago

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".

Actions #9

Updated by Michael Kay over 3 years ago

  • Category set to Localization
  • Status changed from AwaitingInfo to Resolved
  • Priority changed from Low to Normal
  • Applies to branch 10, 9.9 added
  • Fix Committed on Branch 10, 9.9 added

Patch committed.

Actions #10

Updated by O'Neil Delpratt over 3 years ago

  • % Done changed from 0 to 100
  • Fixed in Maintenance Release 10.2 added

Bug fix applied in the Saxon 10.2 maintenance release.

Actions #11

Updated by O'Neil Delpratt over 3 years ago

  • Status changed from Resolved to Closed
  • Fixed in Maintenance Release 9.9.1.8 added

Bug fix applied on the Saxon 9.9.1.8 maintenance release.

Please register to edit this issue

Also available in: Atom PDF