Urso,<br>
<br>
Just want to clarify some things about "string freeze" and it's meaning
in terms of localization work.<br>
<br>
First and most important is that "string freeze" is a restriction on
developers and not translators. String freeze means developers need to
stop changing UI strings so that translators can do their final work
prior to release, in other words, string freeze is a start signal for
translators to perform their final reviews and commits of PO files, not a
stop signal, even the release date itself is not a stop signal for
localization.<br>
<br>
Second is that even after a release is made and declared final and
stable, localizers can complete their work and a deployment team can
make a customization stick for a deployment that includes the
post-release localization work, so you will not "miss the boat" for
providing a localized UI environment for your deployment if work on
lang-pap is not complete by the next release date. This is part of the
beauty of separating the code (release) from the strings (PO/MO files). <br>
<br>
Of particular note, since you are looking at using Sugar on XO laptops
(either 1.0 or 1.5), you are most likely looking at deploying the 0.84
version as the details of deploying the very latest version of Sugar on
the XO have not yet been fully worked out (at least to a level that is
stable enough for a live deployment), although I understand that there
is ongoing work on that. Version 0.84 Fructose / Glucose strings will
not be changing and the string freeze for those was a long time ago, so
in some real sense, the upcoming string freeze is meaningless to your
near term plans.<br>
<br>
I'll add some detail interlaced with your questions below.<br><br><div class="gmail_quote">On Wed, Feb 24, 2010 at 4:08 PM, Urso Wieske <span dir="ltr"><<a href="mailto:uwieske@gmail.com">uwieske@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Hi,<br>
<br>
We are reaching our deadline February 28th for the first translations of<br>
Papiamento (PAP).<br>
I know that "String Freeze" is due March 1st.<br>
<br>
I have the following questions:<br>
- what are delivery requirements?<br></blockquote><div><br>There are no delivery requirements on localizers related to string freeze. It is a signal to language admins to start final review and commit of PO files before release date, but even release date is not the last chance to add new localization.<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
- where can I find them?<br></blockquote><div><br>You can't, they don't exist. The requirement is on developers to stop changing UI strings in their code.<br><br> <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
- whom should give notice that Papiamento is ready on March 1st?<br></blockquote><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
- we still have some translations we need to do after the string freeze: how<br>
much time do we have to work on and still deliver (the second<br>
delivery) after March 1st?<br></blockquote><div><br>Localization doesn't need to be ready March 1. It would be nice, but is not
essential, if you had your work done by March 31st.<br>
<br>
The full release schedule is here:<br>
<a href="http://wiki.sugarlabs.org/go/0.88/Roadmap">http://wiki.sugarlabs.org/go/0.88/Roadmap</a><br><br>There is no notification to be given, only language admin actions to be taken 9PO file review and commit), the rest happens more-or-less automagically.<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
- What are the criteria to integrate a PO file in the software<br>
release/build?<br></blockquote><div><br>A language administrator must perform the Commit to VCS action through the Pootle user interface, it is on the Translate tab of Pootle for those users like admins that have the commit PO file privilege. Pootle is directly connected up to the git software repository (git) through some magic on the back end performed by Sayamindu at the time the language was set up. The language admin's action in Pootle triggers a commit in the software repo (by a special user called user:pootle, but traceable back to the language admin). The PO file for that language can be found in the /po directory of the git project's source code tree and after the commit of the PO file, you can see the evidence in the git commit log and in the date stamp of the PO file in the source tree.<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
- We have PO files which are completed BUT we have still occurrences of<br>
suggestions in it: IS THIS A PROBLEM with delivery or integration? (will it<br>
be accepted as such?)<br>
- We have some words that need attention, because of some reason: will it<br>
still be accepted?<br><br></blockquote><div><br>Suggested strings will not show in the committed PO file and will not be shown to users. If a particular string has not been translated at all, the English version of that string will show to users. There are no functional consequences of partially completed PO files, but as you can imagine, it is not a pretty or desirable result to have mixed language UI strings.<br>
<br>Accepting or rejecting suggestions is done by language admins (or other localizers that may be granted the review priv in a given language). It is generally part of the review process to clear up any pending suggestions.<br>
<br>There is some technical stuff that occurs in taking the PO files committed by the language admin and converting it into an MO file during the build process, but this is largely transparent to localizers. <br><br>The important steps for a language admin to take are to:<br>
<br> 1) Review PO files using the Review tab in Pootle, these are msgfmt (message format) checks from the Translate Toolkit and while some things that get flagged (e.g. whitespace) are not critical, while some other flags (e.g. printf) could cause a PO file to fail during the build process. If there are errors being flagged on the Pootle Review tab that you do not understand or cannot resolve, post to this list about them and hopefully we can get you some help figuring it out.<br>
<br>2) After a review of a PO file, language admins must commit the PO file. This is about as far as the localizers responsibility goes, after that, things happen in the git repo and during the build process, but localizer intervention is typically not needed. <br>
<br>I hope that clarifies things a bit.<br><br>cjl<br> </div></div>