Open Bug 395504 Opened 13 years ago Updated 3 years ago

Allow to have localized default values for some preferences (lightning-l10n.js not shipped)


(Calendar :: Lightning Only, defect)

Not set


(Not tracked)


(Reporter: rimas, Unassigned)


(Blocks 1 open bug)


Lightning currently only has only one preferences file - defaults/preferences/lightning.js. However, it should be possible to set some default values from the locale that is in use (calendar.week.start and calendar.categories.names are the first and most important ones that come to mind). 

It seems not impossible to do that now, but according to some comments in lightning.js (see URL), it was planned. Maybe it's time to make these plans come true?
The second paragraph had to actually say "It seems not possible..."
Summary: Allow some default values in localization → In localization, allow to have default values for preferences
As far as I know it's not possible to have locale specific preference file in an extension. Or is it possible now? If yes - how? Not having local specific preferences is e.g. the cause for Bug 382967.
Well, bug 382967 probably depends on this one then.

I don't know if it's possible or not to have a locale specific preference file. 

However, what I know is that, according to Wikipedia [1], in "...most of Europe, South America, and parts of Asia, Monday is now considered the first day of the week. This agrees with the international standard for date and time representation, ISO 8601, which defines Monday as the first day of the week and Sunday the last." In Lightning, first day of the week is Sunday, and that isn't nice...

This should be fixed by Bug 402534 for 0.8. Reporter, could you retest please? Precondition is that you either start with a new profile or remove all user defined categories.
The default categories are OK.

But the default timezone and the start of the week are still not correct.
Summary: In localization, allow to have default values for preferences → Allow to have localized default values for some preferences
Is this something that needs to be fixed in the respective locales? I'm not quite sure what to do here?
Start of the week can be set for each locale via lightning-l10n.js, timezone is guessed after install. Can't this bug be closed?
(In reply to comment #7)
> Start of the week can be set for each locale via lightning-l10n.js,

For me, this doesn't really seem to work on Windows. This file is obviously not in lightning-lt.jar. Am I missing something? Perhaps it's just not being included anywhere?

> timezone is guessed after install.


> Can't this bug be closed?

I guess so, after the problem with lightning-l10n.js is resolved. I think this bug is basically about that file actually being included.
By the way, this doesn't seem to work on Linux either.
The file should be named lightning-l10n.js and not be in the jar file, but in /defaults/preferences.
And it's not there.
Maybe you need to differentiate between 1) Fully localized Lightning build and 2) English Lightning build that includes additional localizations. The 2nd solution is used for the official Lightning releases.
In my case, it's the version of Lightning that I installed using the addon manager (thus, from AMO). I don't know what the difference between 1) and 2) is, or what's the point of having a difference, if both versions actually include localizations.
Rimas is right.
I tried building from trunk on Win32 several times, with --enable-ui-locale=de in .mozconfig or building en-US and then using repack-l10n for de. lightning-l10n.js is not included from xpi-stage into the .xpi.
The same for older comm-1.9.1-builds, e.g. from November 2009.

I'm no building expert, but it seems there's something wrong during creating the localized .xpi.
Perhaps I should rename this bug to "lightning-l10n.js is not being shipped" to attract more attention?
I guess another issue is that there are no per-locale preferences in a multi-language xpi. Or am I mistaking?
Flags: blocking-calendar1.0+
Summary: Allow to have localized default values for some preferences → Allow to have localized default values for some preferences (lightning-l10n.js not shipped)
Philipp: I don't think of this issue as another. Isn't it the same?
Shipping lightning-l10n.js is easy, no problem. The real problem is there are no dependent prefs. For example

if (locale is lt) { start of week is Monday }
else { start of week is Sunday }

is not possible via prefs.js

So when we build the lightning-all.xpi that contains all locales, we can't specify which lightning-l10n.js file is used.
Can't we resolve pref values using the following scheme?

1) check user config, if value exists, stop.
2) check lightning-l10n.js of the locale in use (locale overrides for default prefs), if value exists, stop.
3) check default prefs, if value exists, stop.
4) other fallbacks (if any).

What I suggest is basically to always process lightning-l10n.js, and give it higher priority than the default config (however it's stored). This would allow the localizers to override any _default_ values they need to, not just some predefined set.
Yeah, thats how it should work, but toolkit doesn't provide mechanisms for this. 

We'd need to create a manual mechanism to do this, but I do have some ideas how this could work out.
Is this still a blocker?
The number of preferences are not very high, but at least the categories are very visible. It would be great to solve this to improve the experience for localized users and given we have centralized getters for our preferences it shouldn't be to hard to solve. I guess we can degrade this to wanted1.0+
Flags: blocking-calendar1.0+ → wanted-calendar1.0+
Blocks: 1230124
You need to log in before you can comment on or make changes to this bug.