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

Status: RESOLVED WORKSFORME

(Calendar :: Lightning Only, defect)

Description

[Rimas Kudelis [use needinfo to ping]]

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?

Comment 1

[Rimas Kudelis [use needinfo to ping]]

The second paragraph had to actually say "It seems not possible..."

Comment 2

[Stefan Sitter [:ssitter]]

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.

Comment 3

[Rimas Kudelis [use needinfo to ping]]

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

[1] http://en.wikipedia.org/wiki/Days_of_the_week

Comment 4

[Stefan Sitter [:ssitter]]

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.

Comment 5

[Rimas Kudelis [use needinfo to ping]]

The default categories are OK.

But the default timezone and the start of the week are still not correct.

Comment 6

[Philipp Kewisch [:Fallen][📱📆]]

Is this something that needs to be fixed in the respective locales? I'm not quite sure what to do here?

Comment 7

[Robert Brand]

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?

Comment 8

[Rimas Kudelis [use needinfo to ping]]

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

True.

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

Comment 9

[Rimas Kudelis [use needinfo to ping]]

By the way, this doesn't seem to work on Linux either.

Comment 10

[Philipp Kewisch [:Fallen][📱📆]]

The file should be named lightning-l10n.js and not be in the jar file, but in /defaults/preferences.

Comment 11

[Rimas Kudelis [use needinfo to ping]]

And it's not there.

Comment 12

[Stefan Sitter [:ssitter]]

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.

Comment 13

[Rimas Kudelis [use needinfo to ping]]

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.

Comment 14

[Robert Brand]

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.

Comment 15

[Rimas Kudelis [use needinfo to ping]]

Perhaps I should rename this bug to "lightning-l10n.js is not being shipped" to attract more attention?

Comment 16

[Philipp Kewisch [:Fallen][📱📆]]

I guess another issue is that there are no per-locale preferences in a multi-language xpi. Or am I mistaking?

Comment 17

[Rimas Kudelis [use needinfo to ping]]

Philipp: I don't think of this issue as another. Isn't it the same?

Comment 18

[Philipp Kewisch [:Fallen][📱📆]]

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.

Comment 19

[Rimas Kudelis [use needinfo to ping]]

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.

Comment 20

[Philipp Kewisch [:Fallen][📱📆]]

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.

Comment 21

[David :Bienvenu]

Is this still a blocker?

Comment 22

[Philipp Kewisch [:Fallen][📱📆]]

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+

Comment 23

[Wayne Mery (:wsmwk)]

Calendar add-on is now integrated with Thunderbird, so it is likely this issue should no longer occur and closing this bug report as a result.

Please comment if you are still seeing a problem when using a current version of Thunderbird.