<div class="gmail_quote">On Sun, Jul 13, 2008 at 2:59 PM, Marco Pesenti Gritti <<a href="mailto:mpgritti@gmail.com" target="_blank">mpgritti@gmail.com</a>> wrote:<br> <blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"> <div>On Sun, Jul 13, 2008 at 8:52 PM, Chris Leonard <<a href="mailto:cjlhomeaddress@gmail.com" target="_blank">cjlhomeaddress@gmail.com</a>> wrote:<br>> I would say that Sayamindu is already doing exactly that sort of working<br> > with upstream in the form of trying to coordinate translation efforts into<br>> release schedules.<br><br></div>Sure, he is! Just to make it clear in case that it isn't, I'm not<br>criticizing Sayamindu work in *any* way.<br> <br>I just proposed a couple more ways to work with upstream, to try and<br>address the confusion which has been raised recently on the<br>localization list.<br></blockquote> <div> </div> <div> </div> <div>Marco,</div> <div> </div> <div>Ok, I wasn't clear to me at first that you had been tracking the schedule coordination discussion over there, so I wanted to point you to it.  </div> <div> </div> <div>There is no question that localization is a key pivot point in pulling off the complex interplay between Fedora > Sugar > OLPC upstreams or other ribose - glucose - fructose interactions (not to mention the other complex polysaccharides) and so clear communications, common nomenclatures and good tools are very important.</div> <div> </div> <div>mpg made other points (besides scheduling):</div> <div> </div> <div>"providing docs on how to translate Glucose/activities on the sugarlabs wiki" </div> <div> </div> <div>As for hosting such documentation on <a href="http://wiki.sugarlabs.org/" target="_blank">wiki.sugarlabs.org</a>, at first, it should probably start out where the tools and primary users are (on the l.o hosts) with pointers from w.sl.o.  In this case, I would refer to localizers as primary users of the l10n tools, devels would be secondary users, although the information flow is something like devel (coder) > l10n > devel (builder/packager).  Sayamindu has posted an initial take on the l10n workflow here and I'm sure he would welcome helpful edits to expand/improve on that start.</div> <div> </div> <div><a href="http://wiki.laptop.org/go/Localization/Workflow" target="_blank">http://wiki.laptop.org/go/Localization/Workflow</a></div> <div> </div> <div>There have also been general discussions on l10n-list about improving documentation and tools.  As you know all too well, one "downside" of improving the tools is that you have to re-do the documentation.  </div> <div> </div> <div>you also mention:</div> <div> </div> <div>"and by matching the pootle groups with Glucose/Fructose modules list.  Do you see any downside with that approach?"</div> <div> </div> <div>If by that you mean, for instance, regrouping or renaming the titles of the .po files within the XO-Bundled and XO-core Pootle projects to more closely match the newly-minted Sugar taxonomy terms and modularization (glucose/fructose, etc) , that definitely should happen at some point, the question is when and who is going to help.  It seems like a big project that may be made easier (or least less disruptive) by some of the desired improvements (better global terminology sharing, etc.) in the l10n tools. Right now, it sounds like it will require localizers to understand a new organizational scheme (for mostly the same strings) at a time when they are scrambling to meet very tight deadlines set both upstream and downstream.  IMHO, it is possible that it might be too disruptive prior to the upcoming August release deadlines, unless absolutely needed to accomplish the job.</div> <div> </div> <div>It is certainly possible that if l10n efforts get the help and cooperation needed (both upstream and down), such concerns may prove to be too pessimistic, but you had asked about possible downsides, so it seemed appropriate to make the point.</div> <div> </div> <div>cjl</div> <div> </div> <div> </div></div>