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.

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

Towards a single binary

Non-build steps

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.

Questions:

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? :(

Repository layout

While the main Camino binary is largely self-contained (localizable files in resources/localized/English.lproj and 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

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/resources/localized/English.lproj/InfoPlist.strings.in.

Preference Panes

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

Feedhandlers contain an InfoPlist.strings(.in) file that is similarly preprocessed. It does not currently live in an .lproj.

Frameworks

Camino includes third-party frameworks Sparkle, Growl, and Google Breakpad; each lives in a subdirectory of camino.

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

NPAPI plug-ins

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.

Repository access

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.

Binary Size

This will remain an issue, particularly as the number of l10ns continues to grow again.

Build infrastructure

.strings.in files

Lots more files to hook up to this mechanism: 1 per nib per locale, in addition to one per locale for all existing .strings.in files

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.