Productization is the process of determining a users choice of default search engines, content and protocol handlers, bookmarks, and links to recommended sites on the in-product pages as it relates to their locale. It is one of the most customizable and localizable parts of the product L10n process, as it goes beyond string translation.
It's super important that you learn how to productize your products. The current wiki doc on this topic will instruct you on the guidelines for productizing your locale's products, but this doc will walk you through how to implement those guidelines. This process is split up into a few different phases: research & prep, patchify, review, commit, & land.
Research & prep
- File a bug under Mozilla Localizations>[your_locale] to request a productization preferences. If this is your first localization, the L10n drivers will file this bug once your hg Aurora repo has been created and you are close to completing your string translation.
- The L10n drivers review your request with you by performing market research and evaluating site quality and standards compliance.
- Note that the bug will be resolved as WONTFIX if the suggestion doesn't work out meet the above criteria.
- If there's no existing collaboration with the site provider and Mozilla, ask for permission from both parties to include it.
- Verify the parameters to use, in particular for search.
- Create a patch of the implementation containing your productization preferences.
- Search plugins are found in browser/searchplugins. Each plugin is stored as an XML file, with list.txt containing the names of each plugin. Here is an example search plugin file using French Wikipedia:
- Create XML files for each search plugin preference following the above example. Each XML file should start with a license header, and use UNIX line endings. For reference on how each tag functions, visit the OpenSearch wiki page and the MozSearch wiki page. The pages are old (I mean, Firefox 2???), but still accurate.
- In list.txt, add the search plugin's XML filename on a new line and save.
- Create a patch of the searchplugins directory by entering the following command in your command-line tool, where OUT_FILE is where you give your patch a name.
$ hg diff -p -U 8 mozilla/browser/searchplugins/ > OUT_FILE
- Run hg add if needed, but make sure to only catch the right files.
- Attach your patch file to the bug by clicking the "Add an attachment" link. Once attached and labeled as a patch, open the attachment details.
- In the attachment details, select the ? from the dropdown menu next to the review flag (see image). This will display a text box to assign the review to someone.
- Enter :flod or :Pike as the Requestee.
Review, commit, & land
- Address any review comments made by the reviewees and update the patch until it receives an r+ rating.
- If the r+ is "with nits" (i.e., that's short for nit-picky requests), fix those before committing. Also, no new patch attachment will be needed.
- Commit the patch to your Aurora repo.
- Only commit the changes you had reviewed.
- Use a commit message that mentions the bug number, describes the change, and mentions the reviewer. For example:
hg ci -m "bug 654321, copied the comment from the doc without reading, r=nobody" path-to-changed-files
- Close the bug, with copying the url to your change in the closing comment. Write up something like this for your comment:
Landed this on aurora, http://hg.mozilla.org/releases/l10n/mozilla-aurora/ab-CD/rev/adfe1234feac, marking FIXED.
- Update your sign-offs on the L10n dashboard to include the change into the next release.
If you can't close the bug (you don't have the required priviledges in bugzilla), poke on #l10n; there are folks that can fix that up.
And that's it! It can be considered a bit complicated at first, but after you do it the first time, it gets easier and easier after that :-)