BrandingForDerivatives

Differences between revisions 24 and 26 (spanning 2 versions)
Revision 24 as of 2005-04-25 03:55:17
Size: 4216
Editor: intern146
Comment: dump some notes from Monday's BOF
Revision 26 as of 2005-04-25 04:48:13
Size: 5185
Editor: intern146
Comment:
Deletions are marked like this. Additions are marked like this.
Line 53: Line 53:
   * Default browser boomarks    * Default browser bookmarks
Line 66: Line 66:
  1. Neutralizing strings   1. Neutralizing strings   
Line 72: Line 72:
   * Create small abstraction library to return distro name string and patch packages to use it rather than directly using a hard coded way (like lsb_release) -> then we can change the way we lookup names without touching many packages
    * for now: just do a simple s/Debian/$DISTRO/g for now and look how far we come with this -> initial library just uses lsb_release and returns distro name
    * future: two stage translation process: mark and translate tags for special word cases in language (in Rosetta/langpacks)
    * both static and dynamic library (static for installer usage)
    * agree on a very simple initial interface, we can (and will) extend it later; changing the way the function is called is easier than switching from e. g. hard-coded lsb-release to hard coded gettext; for now: `const char libbranding_get_distro_name()`
    * Problem: if we want to push this upstream, all upstreams have to agree on this solution, and moreover, the API
Line 90: Line 96:
  * Used by tools such as reportbug (don't fall back to Debian!)
 * Posibility to create a tool to derivate distros: [http://software-libre.org/moin/Meta/en/BrandingSystem Branding System] (not checked translation from [http://metadistros.hispalinux.es Metadistros] subproyect)
  * Used by tools such as reportbug  (don't fall back to Debian!)
 * Possibility to create a tool to derivate distros: [http://software-libre.org/moin/Meta/en/BrandingSystem Branding System] (not checked translation from [http://metadistros.hispalinux.es Metadistros] subproject)
Line 107: Line 113:

 *

Branding

Status

Introduction

This specification describes our strategies to allow for the effective branding of Ubuntu and derivatives. Some branding can be attained without affecting packages, other branding initiatives will require derivatives to rebuild or even modify and rebuild packages. We will also refer to aspects of Rosetta that should affect distro branding.

Rationale

Scope and Use Cases

  • Provide for branding or neutralization, as appropriate, of the following components:
    • CD
      • Boot loader splash image
      • Boot loader text
    • Installer
      • Debconf templates
      • Package selection
      • Help texts
      • Dialogs
    • Express Intaller(UbuntuExpress)

      • Artwork (Logos, images..)
      • Help texts
      • Dialogs
    • Live CD
      • "Starting Ubuntu..."
    • Base
      • Archive keyring?
      • Debconf templates?
      • lsb-release? (hard)
    • Boot
      • USplash image
      • "Starting Ubuntu..."
      • Grub menu entry
      • Grub theme
    • Application defaults
      • GDM theme
      • Splash graphic
      • Default wallpaper
      • Default browser homepage
      • Default browser bookmarks
      • Gnome/Kde theme
      • Menu
      • Apps on "Add/Remove programs"
      • Icons on panel and desktop
      • "About Ubuntu..." (System Menu)
    • Others
      • Debootstrap script

Implementation Plan

  • We have discussed several approaches to branding, and in which cases they are useful:
    • The Rosetta team has done some initial work to mark branded strings
    1. Neutralizing strings
      • The simplest case to handle, and requires no effort to re-brand for each derivative
      • We should apply this technique wherever possible
    2. Runtime substitution
      • Appropriate for simple circumstances (e.g., Apache version string, Mozilla version string)
      • Can use lsb_release, and have a reasonable chance of having the code passed upstream
      • Create small abstraction library to return distro name string and patch packages to use it rather than directly using a hard coded way (like lsb_release) -> then we can change the way we lookup names without touching many packages

        • for now: just do a simple s/Debian/$DISTRO/g for now and look how far we come with this -> initial library just uses lsb_release and returns distro name

        • future: two stage translation process: mark and translate tags for special word cases in language (in Rosetta/langpacks)
        • both static and dynamic library (static for installer usage)
        • agree on a very simple initial interface, we can (and will) extend it later; changing the way the function is called is easier than switching from e. g. hard-coded lsb-release to hard coded gettext; for now: const char libbranding_get_distro_name()

        • Problem: if we want to push this upstream, all upstreams have to agree on this solution, and moreover, the API
    3. Refactoring
      • Collect brand data into central locations
      • Works well for artwork
      • Works well for gconf configuration data
    4. Build-time branding
      • There are hard problems to be solved in the packaging system and in Launchpad before we can manage a separate build for every derivative
      • This isn't achievable for Breezy, so for the near term we must avoid it entirely
    5. Branding human-readable strings via translation mechanisms (gettext, Rosetta)
      • Installer dialogs fall into this category
      • Linguistic issues: deal with plurals, genders, tenses, etc.
      • Human-readable strings must be translated, so retranslation is required after branding them
      • Would require additional complexity and effort in order to avoid duplicating work across distributions which target the same languages
      • Try to neutralize where possible instead

Outstanding Issues

UDU BOF Agenda

  • Runtime branding, build-time branding and package-selection branding
    • Which approach is most suitable for each requirement?
    • Can we avoid build-time branding entirely? It causes big infrastructure problems
  • Branded CD builds
  • Debconf branding
  • Refactoring desktop branding
    • gconf schemas, etc. (<dist>-branding)

    • artwork (<dist>-artwork)

UDU Pre-Work

UbuntuDownUnder/BOFs/BrandingForDerivatives (last edited 2008-08-06 16:23:24 by localhost)