L10n:Firefox web services process

	THIS PAGE IS A WORKING DRAFT
	The page may be difficult to navigate, and some information on its subject might be incomplete and/or evolving rapidly. If you have any questions or ideas, please add them as a new topic on the discussion page.

About this document

This document describes the process of choosing the default web services (RSS feed, RSS reader, protocol handlers, search engines) which ship with localized releases of Firefox and the "Getting Started" Page.

Triggers

What triggers the process?

• new locale added to the tree
• upcoming major release
• other per-locale cases
• changes instigated by a 3d party vendor e.g., to their url or parameters
• technical changes in Firefox e.g., favicons

Process

The process of choosing the set of web services consists of the dialog with localizers (who suggest their choices), the market research (to help localizers and to validate the suggestions), technical research of each web service to understand the latest trends and the dialog with service providers (to evaluate technical capabilities, inquire for a written permission to use their service in Firefox and validate parameters or urls, etc). Throughout the whole process we use the Firefox_web_services_guidelines to evaluate the suggestions. These guidelines were created to ensure the best experience from the default web services for the users.

Filing bugs

See L10n:Bugogram

Suggestions

The objective of this step is to gather suggestions from localizers regarding the choice of the default web services for their locale. We work closely with the localizers on validating their suggestions (see: market research) and on looking for new ones. The localizers are our ears and eyes on their local markets and their suggestions are crucial for the whole process. We expect that the localizer is in dialogue with their community so that they have a well balanced and informed perspective on their suggestions.

Market research

The purpose of the market research is to evaluate the suggestions, as well as to look for new ones together with localizers. The evaluation consists of 3 major parts:

1. technology
   • is the service up-to-date with the recent developments of the field?
   • does it provide good quality to the users?
2. user experience
   • simplicity of function, does it do exactly what's expected?
   • technical feasibility of including the service in Firefox?
   • privacy of data/provider's policy?
3. local market
   • what is the local way of using the web?
   • what can we do to ensure best web experience for the local users?

Dialog with providers

This step's purpose is to:

• obtain written permission from providers to include their services in the default installation of Firefox
• verify technical aspects of providers (search parameters, QA)

Lessons learned

This is not meant to replace the Web Services Guidelines page but to enhance our own thinking and approach to evaluate these based on experience from many interesting situations that have come up in different locales.

• kr - daum RSS reader (requiring the user to bundle reader with another service)
• Occitan sample RSS feed (culturally relevant, even though doesn't update often)
• ga-IE getting started page (Esperanto)
• search plugins are always unique - we try to keep creative commons in most locales, often times locale have more unique specific local search or knowledge search that are dependent on what's culturally relevant. lots of interesting examples (zh-CN, et, lv)

Documentation

We track every change that is made for each release in bugs and in wiki or Google documents. The reason that we do this is to enable any one to be able to reveiw what has happened in any particular locale over time.

• Firefox 3 https://wiki.mozilla.org/Firefox_web_services_Review
• Firefox 2 https://intranet.mozilla.org/Trademark_L10n_Review-Firefox2#Firefox_Search_Plug-In_Review_Document%7C

Stuff not to forget

• Requirements documentation
• feedback loop to ui/ue based on what you see in market, as well as marketing team
• email templates for outreach
• bug mail templates - link to bug-o-gram from pike
• significant market research for decisions
  • useful links that we use to find this
• What kind of releases are good for what kind of changes
  • major release, review web services for Tier 1/2 several months in advance (could even do that for all Tier's) starting with IRC chat and then moving to bugs for documentation and tracking and finally to wiki or google spreadsheet documentation, participate in the Fx product calls and listen for new features that can be localized and then if there are new ones, propose a process for localizing it and document that in the documentation (https://wiki.mozilla.org/Firefox3/L10n_Requirements)
  • minor release, update any changes that have been pending for any locale and take on new locales
• evaluation criteria - examples of questions to ask; an example for a sample RSS feed would be:
  • Is the website relevant to the users in the locale?
  • Is it updated frequently (at least once per day?) - the purpose of the sample feed is to show how the Live Bookmarks feature works
  • For news sites: is it a popular and well-known general news website?
  • Are you satisfied with the quality of articles (are they objective, gramatically correct)?
  • Does the feed happen sometimes to contain any ads?
  • Have you had any problems with the site working with Firefox?

• outcomes of each step