474160 - [regression] mozilla UI is no longer ISO8601-compatible

Status: RESOLVED FIXED

(Core :: Internationalization, defect)

Description

[Constantine A. Murenin]

This bug is a regression from bug #441167.  Many parts of the user interface (for example, Page Info --> General tab in SeaMonkey) now disregard the 24-hour setting for time as specified in the operating system settings, making Mozilla no longer ISO8601-compatible.  Due to the changes in the patch that was committed, it is no longer possible for the user to specify the date and time format that they want to use across the entire interface.

My proposed solution is to backout the patch from bug #441167 completely, since if the user wants the interface to be in a certain language (including the date and time format), then they should select such a language in the preferences of the operating system.  Making it impossible for the user to make the selection, in favour of supporting the full monty localisation of the application on wrongly configured operating systems, is hardly acceptable, and is a wrong approach in fixing bugs like 419220 (which, by the way, remains unfixed even with the introduction of this regression that were are now discussing).

Note that similar regressions were already noticed and brought up in bugs #460988 and #468865, but I believe they weren't given enough attention as to the cause of the problem, as well as were filed in more specific and less applicable components.

Comment 1

[Jesper Kristensen]

(In reply to comment #0)
> This bug is a regression from bug #441167.  Many parts of the user interface
> (for example, Page Info --> General tab in SeaMonkey) now disregard the 24-hour
> setting for time as specified in the operating system settings, making Mozilla
> no longer ISO8601-compatible.  Due to the changes in the patch that was
> committed, it is no longer possible for the user to specify the date and time
> format that they want to use across the entire interface.

How is this related to ISO8601?

> My proposed solution is to backout the patch from bug #441167 completely, since
> if the user wants the interface to be in a certain language (including the date
> and time format), then they should select such a language in the preferences of
> the operating system.  Making it impossible for the user to make the selection,
> in favour of supporting the full monty localisation of the application on
> wrongly configured operating systems, is hardly acceptable, and is a wrong
> approach in fixing bugs like 419220 (which, by the way, remains unfixed even
> with the introduction of this regression that were are now discussing).

I am not sure what you are saying. Are you talking about completely following OS preferences including language or are you talking about 12/24h and md/dm only? Maybe we should follow OS preferences, but I guess that is up to Alex.

> Note that similar regressions were already noticed and brought up in bugs
> #460988 and #468865, but I believe they weren't given enough attention as to
> the cause of the problem, as well as were filed in more specific and less
> applicable components.

I agree that those and also the mac bugs should be fixed soon or bug 441167 should be backed out until they are fixed.

Comment 2

[Constantine A. Murenin]

(In reply to comment #1)
> How is this related to ISO8601?

Prior to this regression it was possible to specify in the operating system settings to have ISO8601 date and time format for both short and long date notations, and the setting was respected throughout all mozilla applications (after my cleanup of multiple bugs around bug #dateandtime).

> > My proposed solution is to backout the patch from bug #441167 completely, since
> > if the user wants the interface to be in a certain language (including the date
> > and time format), then they should select such a language in the preferences of
> > the operating system.  Making it impossible for the user to make the selection,
> > in favour of supporting the full monty localisation of the application on
> > wrongly configured operating systems, is hardly acceptable, and is a wrong
> > approach in fixing bugs like 419220 (which, by the way, remains unfixed even
> > with the introduction of this regression that were are now discussing).
> 
> I am not sure what you are saying. Are you talking about completely following
> OS preferences including language or are you talking about 12/24h and md/dm
> only? Maybe we should follow OS preferences, but I guess that is up to Alex.

Yes, I'm talking about completely following the OS preference, which is available for the user to modify and configure, unlike the new behaviour from bug 441167.  That said, it is specifically annoying to have to see time in something other than a 24-hour format, if the settings in the operating system are clear that a 24-hour format is the only one that is being understood by the user.

> > Note that similar regressions were already noticed and brought up in bugs
> > #460988 and #468865, but I believe they weren't given enough attention as to
> > the cause of the problem, as well as were filed in more specific and less
> > applicable components.
> 
> I agree that those and also the mac bugs should be fixed soon or bug 441167
> should be backed out until they are fixed.

Yes, please back it out until there is a solution for me and other people to continue enjoying our ISO8601-compatibility throughout the application without any additional hacks, other than appropriate settings in the operating system.

Many more international people that use the standard en-US builds are affected by this regression than by a possible inconsistency in the localisation on a wrongly configured operating system (something that arguably was more of a feature than a bug anyways).

Comment 3

[Alex Faaborg [:faaborg] (Firefox UX)]

>Many more international people that use the standard en-US builds are affected
>by this regression than by a possible inconsistency in the localisation on a
>wrongly configured operating system

That's probably true.  Since the set of languages we support is now (I believe) significantly larger than the set of languages most operating systems support, ideally we would respect the OS date format setting, while still localizing to the same language as Firefox (as opposed to using the wrong format, or the wrong language).  However until that is possible, I think you might be right that using the wrong format will have a larger negative impact than using the wrong language, since about half of Firefox users are on en-US, but that doesn't necessarily mean they are all on a 12-hour clock.

cc'ing our statistics guru to see if he can provide quantitative clarity.  The question is which population is larger:

1) en-US users who do not use an American time and date format
2) users who have a localization of Firefox that is not a supported OS language

Comment 4

[Jesper Kristensen]

(In reply to comment #3)
> Since the set of languages we support is now (I believe)
> significantly larger than the set of languages most operating systems support,

I don't think that is true. I counted on Windows Vista. The count on my machine is 118 or 204 locales depending on if you count the varieties of English as 1 or 16.

Comment 5

[Alex Faaborg [:faaborg] (Firefox UX)]

OS X 10.5 seems to have quite a few as well, although only 16 are shown in the default list, and only 18 mentioned on their web site.  Any localizes know of languages that we support that operating systems don't?

Comment 6

[Magnus Melin [:mkmelin]]

The change from bug 441167 has been backed out (bug 441167 comment 21) so this is no longer an issue.

(And as I've commented elsewhere, I hope it doesn't come back.)

Comment 7

[Constantine A. Murenin]

(In reply to comment #5)
> OS X 10.5 seems to have quite a few as well, although only 16 are shown in the
> default list, and only 18 mentioned on their web site.  Any localizes know of
> languages that we support that operating systems don't?

Where did you get this number from?  On Canadian OS X 10.5, I see a huge list of locales in System Preferences -> International -> Formats -> Region.  The number of languages in International -> Language -> Edit List is also very significant, and includes about two dozen of non-Latin and non-Cyrillic scripts alone.