<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 3, 2015 at 11:17 AM, Toby Elliott <span dir="ltr"><<a href="mailto:telliott@mozilla.com" target="_blank">telliott@mozilla.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class=""><br>
On Sep 3, 2015, at 9:48 AM, Axel Hecht <<a href="mailto:axel@mozilla.com">axel@mozilla.com</a>> wrote:<br>
> The question is not if, but where we want to get to.<br>
<br>
</span>Agreed. Part of my goal is to help coalesce some of these questions and figure out what's really important to us. Thanks for these thoughts, they help.<br>
<span class=""><br>
<br>
> The databases in pontoon and pootle today carry golden nuggets. And I can't discover them, because I don't have access, and I don't know the schemas.<br>
<br>
</span>This is not a problem with a database. If you can't discover or extract data, that's an API problem (and merits attention).<br></blockquote><div><br></div><div>We should just agree to disagree on this one then.  Its not our experience.  Both the APIs can't keep up with the access to the underlying data that we want to dig out, and when the schema actually does need to change the orginal developers of the scheme run away, or the system breaks down with performance and other problems trying to access the data in ways that weren't intended or designed for.<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
This is what I'm getting at: ideally, localization should not have to know the underlying technical specs. It shouldn't matter, just as it doesn't matter that I don't know the technical details that underly, say, github. If github decides tomorrow that they want to run everything off a MongoDB cluster, it shouldn't impact me the user (well, that particular decision might have some visible effects!) Changing all that out doesn't affect the openness of the data.<br>
<br>
It may be that this is a case where the API level is, literally, hg. If the consensus is that that's the case, so be it. But that's a very strong constraint to put on a system this early on in discussions.<br>
<span class=""><br></span></blockquote><div><br></div><div>I think you are mixing requirements for different sets of the people this system will serve.<br><br></div><div>yes, localizers might not want to know about or care about where the localization strings come from or go.  but in some cases the most active sets of localizers do.  the work like developers with hg and text editors.  so it does matter to them if you change version control systems.   all the abstraction just gets in the way of their work.<br><br></div><div>same for release and localization managers that are also responsible for the end to end system.   its not only about getting the strings translated, its about getting them into builds, and out for testing...<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
<br>
> It's great to make tools great at what they're great at. Restricting us to just one thing is in the way of progress.<br>
<br>
</span>Yes and no. This is what I was getting at with my python/perl analogy. There are lots of benefits to that - programmers get to work in what's comfortable, and get to decide what's the perfect tool for a particular job. But, there are also downsides. Getting new people on board is harder. Making changes to the underlying system involves a whole lot more work (just as we're seeing here). If your one guy who wrote Haskell leaves, you may be in serious trouble.<br></blockquote><div><br></div><div>most of the new people that we have coming into the project are coming from the linux world. they are used to and work just fine with pootle and the capabilities we have there.   we have contracts with the pootle developers to keep things operationally sound.  this makes up about 1/3 or more of our contributors.  the other 1/3 are on hg and text editors..  that really doesn't require us to do much direct work to help them be more effecient.<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
It may be that letting each localizer set up their own workflow and build their own tools is the ur-goal and that we're willing to make the sacrifices and expend the additional effort to make that happen. Note that I am not advocating for one-true-way. I believe that (some) other ways should be possible, but may require extra effort on the part of that user.<br>
<span class=""><br></span></blockquote><div><br></div><div>Its really not each localizer setting up there own workflow.  they have a small set of basic choices to choose from, and we experiement with new choices from time to time.  we also shut down obsolete choices and have done so with narro, transafex and others.    so we are managing this...<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
<br>
>> "Storage database" is the agnostic representation of hg. We can call out hg explicitly if you prefer.<br>
> I find "agnostic representation" to be a bold claim. I can go into any particular detail of hg, and make that a requirement.<br>
><br>
> Our version control and the text files within that are the one true data source. It's what we're using to build products.<br>
><br>
> They're not a tangential artifact.<br>
<br>
</span>One of the points of go-faster is to question this statement.<br>
<br>
Is the technical implementation of our build process an essential piece of information for our localizers?<br></blockquote><div><br></div><div>getting builds out of the system so they can view context of newly landed features and en-US strings is, and getting more builds out of the system to show the results of their translation work are both essential.   minimizing turn around time for putting all these things together is essential.   if we are planning a system addon and update system where localizers and testers are basically in situation of having to roll their own to assemble a bunch of things from here and there we won't be meeting the needs of trying to go faster.  localizers and testers do just fine if we deliver full builds on a regular schedule with all the things they need to look at.  when those builds break, or when lots of assembly is required things start to come to a standstill.   what is that you are suggesting we do to the build system.  will it stand up to the needs I just mentioned?<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Is "we use hg" a fundamental requirement for defining our build process?<br>
<br></blockquote><div><br></div><div>not sure where this is coming from or where its going.<br><br></div><div>yes, is the answer in the short term.   if 1000's of hours are invested then other options might be possible.<br><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Do localizations (along with various dictionaries and other pieces under discussion) need to exist as part of the central codebase? Can they be pulled in during the build process? Do they even need to be part of the build process, or can they be delivered separately?<br>
<br></blockquote><div><br></div><div>Maybe they could.   But the question gets back to how efficient might that be towards getting to a globally released and distributed product?    That's the main goal in reaching the bulk of our user base as fast and effectively as possible.<br><br></div><div>You also introduce lots of complexity by shifting to some kind of asynchronous build and distribution system for a single product (the browser).  With complexity comes errors and extra decision making and all that slows us down.<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I don't have the answers here (and, honestly, don't expect to until dtownsend has had the opportunity to dive into the guts of Firefox and figure out our options).<br>
<span class=""><br></span></blockquote><div><br></div><div>so what happens next?  just waiting for dtownsend?<br><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
<br>
> We don't have the resources to do a bunch of things, let alone doing things that may or may not work out.<br>
<br>
</span>We should be taking risks and trying things that might fail. Sometimes we'll succeed and sometimes we'll learn something.<br>
<br>
Also, if we don't have the resources to do a bunch of things, why are we supporting a lot of different localization workflows? Is that the most important constraint in the system?<br></blockquote><div><br></div><div>As mentioned above.  We don't support "a lot' of localization workflows.   We support a few that work for different localizers with different levels of technical skill and background.  for those with advanced skills hg and editors (and not much work invovevd there).   for those that want/need a web interface and might be coming from the linux localization world pootle gets the job done.  then we keep data formats open and interchangable to a variety of other pet tools that can work and translators are used too, but we offer no support there.  Once in awhile we invest in some experimentation on new system that have promise.  If it doesn't work out and the developers loose interest or go away or can't support us like with narro and transafex then we shut those experiments down.   That's how we see a way to experiment and innovate with tools to try things out.  That's the camp we see your work with pontoon to be.   It has some promise, but its got a lot of work ahead to be a good enough tool that it might replace a host of requirements from a variety of wildly different kinds of localization contributors, or maybe even just a minority of localizers.  I think you are starting to get this picture, and I think you are starting to understand the importance of making sure that what ever you are working on can't be in the critical path for trying to get localization work done on system addons. <br><br></div><div>It was great to have this requirement added to the PRD  [ <a href="https://docs.google.com/document/d/1H0be9rVfK-molaEa3KPvPLO4hS6iSKs-eHy2HGQwMNY/edit">https://docs.google.com/document/d/1H0be9rVfK-molaEa3KPvPLO4hS6iSKs-eHy2HGQwMNY/edit</a> ]<br><br><ul style="margin-top:0pt;margin-bottom:0pt" id="docs-internal-guid-69a4e49b-9a5e-0088-6b6a-4e599bf97fff"><li dir="ltr" style="list-style-type:disc;font-size:14.6667px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline"><p dir="ltr" style="line-height:1.656;margin-top:0pt;margin-bottom:0pt"><span style="font-size:14.6667px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">System add-ons will be localized as per normal processes, as much as possible. Localization dashboards and tools will need to be updated to understand the location and cadence of system add-on strings. String changing updates will need to be added to a schedule and localizers will need to be notified.</span></p></li></ul><br></div><div>-chofmann<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Toby<br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
Gofaster mailing list<br>
<a href="mailto:Gofaster@mozilla.org">Gofaster@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/gofaster" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/gofaster</a><br>
</blockquote></div><br></div></div>