Places:L10n impact meeting/2007-03-19: Difference between revisions
Jump to navigation
Jump to search
(l10n impact meeting for places, put up an agenda) |
No edit summary |
||
| (2 intermediate revisions by the same user not shown) | |||
| Line 2: | Line 2: | ||
= Attendees = | = Attendees = | ||
* axel, dietrich, dan mills, seth, mano | |||
= Agenda = | = Agenda = | ||
| Line 13: | Line 15: | ||
* Up-, side-, and downgrading behaviour | * Up-, side-, and downgrading behaviour | ||
* Testing | * Testing | ||
= Links = | |||
* [https://bugzilla.mozilla.org/show_bug.cgi?id=371926 places l10n tracking bug] | |||
* [http://lxr.mozilla.org/mozilla/source/browser/locales/en-US/chrome/browser/places/ places locale files] | |||
= Notes = | |||
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 | |||
Q&A: | |||
* 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? [http://lxr.mozilla.org/seamonkey/source/browser/locales/en-US/chrome/browser/bookmarks/bookmarks.properties#144 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 | |||
=Takeaways= | |||
* bug for removing default_places.html ([https://bugzilla.mozilla.org/show_bug.cgi?id=349523 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 ([https://bugzilla.mozilla.org/show_bug.cgi?id=374491 bug]) | |||
Latest revision as of 18:32, 19 March 2007
The first l10n impact meeting is for places, on Monday, March 19th, 10am PDT. The conf-call bridge is 251, backchannel is #places.
Attendees
- axel, dietrich, dan mills, seth, mano
Agenda
- Introduction
- Status report on places
- ... and it's documents
- Localization quality
- Stability, communication, timeline
- Information to be localized
- Up-, side-, and downgrading behaviour
- Testing
Links
Notes
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
Q&A:
- 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