Places:L10n impact meeting/2007-03-19

From MozillaWiki
Jump to: navigation, search

The first l10n impact meeting is for places, on Monday, March 19th, 10am PDT. The conf-call bridge is 251, backchannel is #places.


  • axel, dietrich, dan mills, seth, mano


  • Introduction
  • Status report on places
    • ... and it's documents
  • Localization quality
    • Stability, communication, timeline
    • Information to be localized
  • Up-, side-, and downgrading behaviour
  • Testing



places status:

  • still bugs for bookmarks parity that'll have string changes: date metadata, etc
  • new features: sync, tagging - the l10n impact/plan should be added to the feature template for places


  • seth: how is sidegrading a l10n issue?
    • axel: migrating from one locale to another, need to migrate bookmarks, etc.
  • axel: what in default_places.html needs to be localized?
    • need to have structure/default data separate from bookmarks.html to allow default data to be created when up/sidegrading from an existing profile
    • move queries from default places into properties files
  • axel: names from the default structure: could we load at runtime instead of import time? do we do this already?
    • seth: Isn't that how it already works? see source
    • Mano: sspitzer: i'm not sure this code is used
  • axel: quality - P1s in prd need high quality for all languages. feature authors need to be clear about what is or isn't stabilized in the UI. it's not advantageous to land a bunch of strings before they're used, b/c can't be tested.
  • axel: for old bookmarks: make sure all strings are used, remove the rest
  • mano: is it acceptable to ship the next few alphas w/ strings in content?
    • axel: sure, if they're unstable. localizers can still see them, but they don't have to do the l10n work unnecessarily.
  • mano: what about UI done as extensions, late landing?
    • axel: user-documentation is big concern here. bigger issue than actual strings.
    • axel: extensions vs core strings: should be in core long before string freeze, and should be called out in the PRD.
  • mano: what about experimental extensions on places?
    • axel: whether they make it in fx3 is up the qa/l10n issues involved.
  • should we move all places strings into content?
    • axel: yes.
    • seth: no. instead, we should audit/clean the parity strings, and keep in locale if they're stable.
  • seth: can you clarify when we should create a new entity when changing strings?
    • axel: when the meaning of the string differs from the meaning of the entity name.

Axel's list of l10n-friendly dev practices

  • keep unstable strings in content until stabilized
  • when strings are moved to locales, communicate that to the l10n newsgroup
  • timeline: "here's a chunk of code, i'm planning on moving it to l10n at this date..."
  • litmus testcases for manual string identification
  • testcases for error messages are particularly helpful


  • bug for removing default_places.html (bug)
  • have another meeting before places-bookmarks are turned on
  • have l10n group newsgroup review the l10n part of the places feature plan document
  • do an audit of current places strings (bug)