User:Sardisson/Towards a single Camino binary
Right now, Camino releases are shipped in two separate binaries, a US English-only version built from the tinderbox and a MultiLang version built by repacking .lproj folders into the former (plus some other stuff). This is not very Mac-like (though better than Firefox, but my father always taught me to compare myself to the best, not the worst) and leads to an inconsistent user experience.
2.0, we should ship final and security-update releases as a single, unified binary produced by the tinderbox. This document outlines the beginning of a plan to achieve that goal. For previous discussion on this topic, see the 2006-10-11 Status Meeting and the corresponding log.
There's now a bug filed on this, Bug 384406.
- 1 Towards a single binary
- 1.1 Non-build steps
- 1.2 Build infrastructure
Towards a single binary
The first step (which requires very little work in the grand scheme) is getting the license on the .dmg in a multi-lingual format (Bug 363010).
- This was completed for 1.5 for the languages in which MoFo had a translation of the EULA.
Make nib changes not require localizer changes to prevent breakage
Convert nibs to use
GTMUILocalizer. This would be pretty simple to do for key nibs like MainMenu and BrowserWindow (which need no layout tweaking; Bug 569180). There are a significant number of nibs, however, so fully converting will take some time.
- How does this interact with localization tools if nibs contain no objects that should be user-resized?
- While entirely missing nibs would normally fall-over to the next language, this leaves the possibility for ”half-and-half” nibs, half localized and half English(?), with object additions (fallback happens only to English).
- Does Camino dev need to generate new .strings(.in) files for each locale when adding a new nib?
- Will the Tri-License ever become compatible with GTM's Apache license? :(
While the main Camino binary is largely self-contained (localizable files in
resources/application/English.lproj), Camino includes a large number of bundles with localizable content pulled from other locations. Some localizable content is also generated/preprocessed to be useable.
Camino’s InfoPlist.strings file is preprocessed to fill in values and then run through iconv; this would need to be extended to support localized copies of
Camino contains a number of preference panes; their localizable content lives in
PreferencePanes/*/English.lproj/. Localizations could live alongside the English ones. Either a master locale merge script could copy these locales into a final binary, or the build settings for the panes would need to be updated to include new locales.
- What about the strings.in-->iconv-->.strings conversions for the strings files in each pane?
Feedhandlers contain an InfoPlist.strings(.in) file that is similarly preprocessed. It does not currently live in an .lproj.
Camino includes third-party frameworks Sparkle, Growl, and Google Breakpad; each lives in a subdirectory of
Growl contains no localizable content.
Sparkle is currently localized and its localizations exist in our tree in
camino/sparkle/*.lproj/ (we currently strip l10ns that do not match the l10ns found in the Camino binary in a Camino shell script phase).
Google Breakpad contains strings-only localizable content in
camino/google-breakpad/src/client/mac/sender/English.lproj/, with an override file in
/camino/resources/google-breakpad/InfoPlist.strings. The override file is installed via a shell script phase in the Camino build.
- Our localizations could live alongside the original English ones in
camino/google-breakpad/src/client/mac/sender/*.lproj/, but additional work would need to be done to handle the override file (needs to move into an
.lproj, needs its shell-script phase altered).
Now that the PrintPDE.plugin and Default Plugin.plugin are gone, this “group” is less of an issue, given the JEP has no real strings. These items are by far going to be the most problematic, as they live in the Mozilla tree. We would have to create a separate “area” of the repository for these items’ localizations and then have a shell script merge in the localizations’
.lprojs during the Camino build. For the most part, these items would no longer need layout tweaks performed by localizers.
Release Notes and Readme
These files live in
camino/docs/ and are pulled onto the .dmg by a Makefile that runs the very inflexible packager. Both where these files live and how they are packaged would need to be completely reworked. Also, since Release Notes tend to fall victim to missing translations in security releases, there would probably need to be some method of merging changes from the English release notes for the current release into a localized version from the previous release.
Mozilla localizers don’t have access to the main mozilla.org Hg repository; Mozilla localizations live in a separate repository, which contents are painfully merged into localized binaries. Localizers must still apply for Hg access to this separate l10n repository. Using the l10n repository would be extra painful for Camino builds and require additional hackery. On the other hand, using the Camino repository, Camino committers would have to serve as the gatekeepers for localizer checkins, adding an extra burden.
Other options include using the caminol10n mozdev repository and adding a checkout phase to the Camino makefile to pull all of the files into the correct locations (possibly painful; requires another repo to be working) or creating a new Camino repository (same). Tagging the tree for releases would require additional steps/access. In either case, we could add and revoke localizer access as needed, however.
This will remain an issue, particularly as the number of l10ns continues to grow again.
Lots more files to hook up to this mechanism: 1 per nib per locale, in addition to one per locale for all existing
Shipping the right languages
While GTMUILocalizer will bring some form of language fallback to nibs, making it possible to ship working multilingual nightlies, even if they are only partly localized, releases (and milestones?) should only ship fully localized and reviewed languages.
Possible solution is to maintain a text file with either an opt-in or opt-out list of
.lproj names and have a shell-script build phase use this file’s list to recurse through the repo/binary and add/remove relevant
.lprojs (see Repository layout above). This file would be updated on the minibranch for the release.
Merging locales into the binary
See Repository layout above; some additional merging logic would be necessary to account for the varying locations of localized content in relation to their original English versions, and so forth.
Release Notes and Readme
See Repository layout above.