Closed Bug 1001439 Opened 10 years ago Closed 10 years ago

[Refactoring] Move '%A, %B %e' date format from app specific files to the shared\locales\date

Categories

(Firefox OS Graveyard :: Gaia, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: azasypkin, Unassigned)

Details

Currently the same '%A, %B %e' date format is used across different apps (clock, dialer, homescreen, system, sms), but defined separately for every app. So it's a good candidate to be moved to shared\locales\date.

In general proposition for defining new date\time format is the following:

1. Check whether required format is defined in shared locale files;
2. If yes - use it;
3. If no - check whether any other apps use the same format internally;
4. If yes - move it to shared and use shared for both apps;
5. If no - define it inside app's locale file.

The same analysis should be performed when we modify\delete existing format. This will help us to keep shared and app locale files cleaner.
(In reply to Oleg Zasypkin [:azasypkin] from comment #0)
> Currently the same '%A, %B %e' date format is used across different apps
> (clock, dialer, homescreen, system, sms), but defined separately for every
> app. So it's a good candidate to be moved to shared\locales\date.

Please keep in mind usage context and things like bug 980461 comment 37 when moving these format strings.
(In reply to Stefan Plewako [:stef] from comment #1)
> (In reply to Oleg Zasypkin [:azasypkin] from comment #0)
> > Currently the same '%A, %B %e' date format is used across different apps
> > (clock, dialer, homescreen, system, sms), but defined separately for every
> > app. So it's a good candidate to be moved to shared\locales\date.
> 
> Please keep in mind usage context and things like bug 980461 comment 37 when
> moving these format strings.

The scope of this particular bug, is just to remove duplication in locale files. Format declaration will be just moved from app-specific locale files to shared locale file if it's used in more than one app.

So if the affected app didn't have problem with usage context we won't change anything, at the same time if app had such problem, it will still have one :)
(In reply to Oleg Zasypkin [:azasypkin] from comment #2) 
> if app had such problem, it will still have one :)

Not true, it that case all apps with "deduplicated" format string will have a problem/one app workaround applied.

Basically the way to go would be to move one formatting string to shared and then, for every other app separately, check if shared version is the same as app version for every locale and if so, move it.
(In reply to Stefan Plewako [:stef] from comment #3)
> (In reply to Oleg Zasypkin [:azasypkin] from comment #2) 
> > if app had such problem, it will still have one :)
> 
> Not true, it that case all apps with "deduplicated" format string will have
> a problem/one app workaround applied.
> 
> Basically the way to go would be to move one formatting string to shared and
> then, for every other app separately, check if shared version is the same as
> app version for every locale and if so, move it.

Oh, do you mean that we have cases where localizable string (that contains date\time format) with the same id may be different across different locales? If yes, then you're definitely right! I just didn't know about it.

Thanks!
Right, now I see what you meant. I think we should add appropriate comments in base en-US files for such formats as suggested in bug 980461 comment 39.
I've checked %A, %B %e format for every app that uses it. Eventually it's changed quite frequently for different locales. So it doesn't seem reasonable to move it to shared locale file for now.
Assignee: azasypkin → nobody
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.