« previous week | index | next week »

Meeting Details

• 9:00am Pacific, 12:00pm Eastern
• 650-903-0800 x91 Conf# 206 (US/INTL)
• irc.mozilla.org #l10n-drivers for backchannel

Attendees

WilC, Mic, Axel, Tim, Choffman

Notes

• Goals for L10n and L10n-drivers
  • Strengthen existing teams - all agreed
  • Enable new localizations - all agreed
  • Expand use of extensions/add-ons to int'l users of which localizing AMO is one enabler of this - this may not be in scope for L10n but we want awareness in other groups
  • We need to inventory the support availability in each locale and find locales without good support and ensure they are covered or start to get coverage in SUMO
  • Measure things we do achieve what we want for example:
    • count existing funnel
    • count speed of funnel
    • no localization loss from Firefox 2 to Fx3
  • Strengthen teams specifically in terms of QA
    • find new people
    • encourage team to find a variety of skills e.g., developers, testers, translators
  • How would we beef up locale team (especially if they are struglling)?
    • this implies we'd have a rough measurement system for assessing health of localization team; we need to create this, it doesn't exist now. Some ideas:
      • Do they have set of localizers ready to jump on projects we propose; do they have set of testers; creating builds;
      • gather information about health and then go through and review it and give them a rough grade and then from there can make those choices on specific support/help; we need to start with cataloging of community e.g., India was one area with a bit of help we've been able to nurture into serious effort
      • Stanislav has been doing a system for community pals- something we could leverage or base this upon
  • making it easier - closer look at the last mile e.g., make sure new languages get released and don't hop from one fire drill to next and then we don't know when shipping and then dropping; like what happened to Ukrainian now doesn't happen on regular basis; room for improvements; we need to transform this process to something more visible
  • on our Goals, there will be discussion not within this group that may over rule what we may come up with

ACTION: Mic: go back through goals that are published in the other groups and identify work there that might need to happen in relation to localization

• QA update
  • automate spot tests on locales; tomcat automating not just our bot checks (12-15 test cases for obvious things like formatting, button clipping, etc), able to automate smoke tests (20-30 test) for French, Finnish, German (5 all together). All for Fx2. hoping have better automated testing for locales. this is a process that would have normally taken 1 hour per language per locale got it down to 2 hours total.
  • based on screen shots; ensures systems doesn't regress based on small graphical images; menu items not corrupted

• Tools
  • Dwayne vs Gandalf approach (i.e., web interface vs process); it's kind of in conflict in terms of resources
  • the objective is to reduce barriers to entry (making it easier for more folks to get involved with Firefox localizations) - best way to accomplish this goal, e.g., web interface, plug in strings; then figure out how to get those things checked back in to right spots
  • on other end of spectrum for objectives is reducing cycle time for creation of build; wouldn't use web interface; want tools installed on system, then when ready commit them to CVS
  • We need to discuss where or biggest problem is and which area first focus needs to be e.g., barrier to speeding up exiting work or is there some way to accomplish both;
  • everyone wants web tools - but they all want a different one - challenge will be to find out what is actually the target audience/problem solve and (b) can solve it in a way that enables you to solve related problems as well
  • Axel has seen feedback from French team - on their updated thinking/approach - proposing parts of functionality get moved out into a web service which might help some things; understanding our boundaries will be biggest challenge
  • we should try to get that communication more out there; find right people able to do software design as well
  • more we can leverage people who can do coding/scripting to help non-coders, make it modular
  • utf8 text tool submit strings; more from end user standpoint, we need to do a better job of indicating what we want them to translate; web interface to text file
  • Our current process is several parts:
    • parsing of data formats (nice diff for CVS - not easy); get data parse into editing UI
    • translation algorithms like glossaries, memories and machine translations; local translation tests (do i have all strings in this file, are variables in this entry does English string do that as well or do they differ, may be heuristics that says shouldn't translate here) on top of that could be different user interfaces exposing diff levels of complexity
    • integration texts - complicated steps to determine e.g., is help still working, dialog sizes right/wrong
  • modeling work flows only seen rosetta proposal; there are people using rosetta out of launch pad
  • web interfaces beyond POOTLE - important to find out so we can properly recommend if we invest more in POOTLE

ACTION: mic find out how we can get on this from Ubuntu

• • on lowering barrier or streamlining process for more technical people, reducing barrier might be place to focus first cause think there might be a side effect to that; if we reduce barrier do we create something that gets more eyes on translated materials, answer is yes
  • like comparisons of languages e.g, Argentinian and Spanish - created lots of discussion about how to better leverage across localizations, tools that Choffman and Axel write are more simple on a diff level than Dwayne is thinking; would it be better to start from scratch; ask Ubuntu whether Rosetta is interesting