This is a partner driven project, Songbird is not currently planning on bundling localization packs with installers.
Goals
- Allow users to have a completely localized application from the very beginning of first run
- Allow users that don't have network connectivity to have a localized application
- Solution needs to not negatively affect the update process
- Solution needs to not make more likley the chances of ending up with a broken build due to localizations and code being out-of-sync (app should at most fall back to en-US).
Use Cases
- User installs PartnerSongbird, selects a langauge in PartnerInstaller, doesn't have to select the language in Songbird firstrun and gets a fully localized first run experience and launches app localized.
- User installs ParnterSongbird bundled on a device without internet connection. Language selection made in PartnerInstaller; on Songbird Firstrun the user gets a localize Networks setting dialog (before Eula standard language selection), and finishes Firstrun and launches into the localized application
- User installs PartnerSongbird and localizes it (as above). User does an application update across versions that breaks compatability with the installed langpack. Application should
- attempt to update langpack
- fallback to en-US if it can't
- As #3, but then a new profile is created
Specifications
Broken down by major area of functionality. If wireframes are required they should appear first in the section followed by the stories and tasks that relate to that wireframe.
Bundling Locales
The general approach here will be to have a ParnterInstaller include the langauges in it's installer. There shouldn't be any work outside of update testing needed from Songbird for this approach (beyond assistance with specific coding issues)
Here is a rough flow:
- PartnerInstaller (PI) runs
- Users is offered and selects a non-english locale
- PI is localized -- all Partner generated content is localized
- PI unpacks the Songbird installer
- PI installs it's addons,
- PI installs the correct locale pack into the extension directory
- PI Sets the locale preference in one of the following ways (they have different outcomes for 2nd profiles and update scenarios) TESTING REQUIRED
- distribution.ini is copied across that contains the requisite preference (after an update of the PartnerSongbird app this file is replaced, so either extra logic needs to be put in place OR the pref gets blown away)
- a js component is created that will fire at launch and set the locale preference (it should watch for first-run only)
Stories and Tasks
Notes
- Assets (e.g. graphics)
- Risks (e.g. unknown APis, dependencies, black holes)
- Some testing for step #7 has already been done by creating a new, default extension that would set the locale pref (general.useragent.locale) via js at the beginning of the first run process. PI would set an extension-specific pref to the desired locale, and then js would update the locale pref (this method was used instead of setting the locale pref directly because the extension was then disabled, and the locale value would then be lost - see behavior of default prefs). Although this method worked to set the locale pref, it wasn't "early" enough to properly set the default locale in the locale dropdown on the EULA page. distribution.ini was not tested, and may address the locale dropdown problem.
Additional Considerations
Top level things to consider across all stories/tasks.
- Integration
- e.g. More than regular amounts of overlap with other ongoing or completed projects
- Special QA Requirements
- Special attention needed to Applicaiton and addon update scenarios
- Build and Release impact
- Locale packs would need to be passed over to Partners at time of final signed executable
- BizDev
- e.g. licenses or contracts required, NDAs needed
- Project Manangement
- e.g. code or specs needed from a partner