Places:L10n impact meeting/2007-03-19
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
- Status report on places
- ... and it's documents
- Localization quality
- Stability, communication, timeline
- Information to be localized
- Up-, side-, and downgrading behaviour
- 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