Closed Bug 281935 Opened 15 years ago Closed 14 years ago

Provide means of building sunbird with other locales. (Make Sunbird Localizable)


(Calendar :: General, defect)

Not set


(Not tracked)



(Reporter: mostafah, Assigned: mostafah)




(2 files, 1 obsolete file)

To move towards supporting the same procedure other Mozilla applications are
providing for being built with another locale, the default usage of the "en-US"
string throughout the files and the makefiles should be replaced with
The browser directory is a good reference for getting this done.

On the same note I am thinking about separating the english locale files into
calendar-en-US.jar just like other locales. This will make it consistent with
other locales and will ease the procedure for translators.
Thoughts are welcome.
Depends on: 267981
Hardware: PC → All
This patch should fix the second part of Mostafah's bug description. It also
does some small whitespace cleanup in two places.
Attachment #184182 - Flags: first-review?(mostafah)
QA Contact: gurganbl → general
Hmm, I'd guess that calendar/sunbird/lightning en-US localizeable files should go into some structure under mozilla/calendar/locales/ to parallel what's done for "source L10n" in firefox, thunderbird, core and soon seamonkey...

I'm not sure why you want to do a bunch of seperate jar files... we don't do that in any of those other apps...
Sunbird and Calendar extension locales are already consolidated in calendar/resources/locale/AB-CD right now. Most of the locales in Lightning will also use the entities from calendar/resources/locale/AB-CD as can be seen in the patch for bug 298348. We can consolidate the locale files even more, once Sunbird and the Calendar extension move to the new view code. 

Lightning will most likely still have a few app-specific entities (probably consolidated in lightning.dtd, but I see no reason why this file shouldn't live in the same directory as the other locale files.
*** Bug 316389 has been marked as a duplicate of this bug. ***
v2 of first patch
The patch separates locale files from the core jar file to its own calendar-AB_CD.jar, making it easy for localizers to replace just one file in the xpi in order to localize the extension. Also having it as a separate jar file makes it possible to reuse the calendar-AB_CD.jar file from a localized sunbird build for the extension.
The AB_CD approach is by no means complete but is a step forward in that direction. It's currently hardcoded in the to be en-US but later should be read from config files.
Attachment #184182 - Attachment is obsolete: true
Attachment #207745 - Flags: first-review?(mvl)
Attachment #184182 - Flags: first-review?(mostafah)
Comment on attachment 207745 [details] [diff] [review]
locale-en-US-separation v2, replacing en-US with AB_CD

for the next steps, don't forget there is already a lot of work in bug 267981
Attachment #207745 - Flags: first-review?(mvl) → first-review+
Comment on attachment 207745 [details] [diff] [review]
locale-en-US-separation v2, replacing en-US with AB_CD

Thanks. Will do. Patch checked in.(head and branch)
The should have really used %chrome like the other in 
It seems to me as if we only can use %chrome if the locales got moved to calendar/locales, because for %chrome to be usable the directory structure need to be calendar/resources/locale/en-US/chrome/*
So it has to be fixed together with the physical move to the new directory structure.
I was wrong. This patch works but it doesn't make sense to change it prior to moving the stuff to calendar/locales/calendar/chrome.
I just want to discuss if everyone is fine if we remove the additional AB_CD directory in calendar-AB_CD.jar. Or if there are objections.
Isn't this fixed? The other stuff will get handled for 267981
With the /l10n move complete, I can now build Sunbird in French simply by adding two lines to my .mozconfig

ac_add_options --enable-ui-locale=fr
mk_add_options MOZ_CO_LOCALES=fr

Lightning being localization friendly should be spun off to another bug.

Closed: 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.