<div class="gmail_quote">On Sun, Oct 9, 2011 at 6:02 AM, Jakub Ratajczak <span dir="ltr"><<a href="mailto:jamarat@o2.pl">jamarat@o2.pl</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;">
Chris,<br>
Unfortunatelly the <a href="http://wiki.laptop.org/go/Localization/Testing" target="_blank">http://wiki.laptop.org/go/Localization/Testing</a> is out of date. Most directions are obsolete (i.e. using QEMU, obsolete links). History tab shows it was updated last time over 3 years ago.<br>
<br></blockquote><div><br>Yes, I am aware of that and mentioned the staleness in my call for testing, but perhaps I was not explicit enough. The language pack generation process was badly neglected and not maintained since that time. We are beginning work on correcting this, but there is no question in my mind that it will unfortunately take some time to get it right, at which time, clear documentation will be created and hosted on the SL wiki,<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;">
I tried to setup test environment for localization using the newest .iso image on an USB stick (using Fedora USB live creator). On such environment the LL_lang_pack_v2.sh script fails to run due to missing /home/olpc/ directory (I tried to use Polish).<br>
</blockquote><div><br>I appreciate the attempt. At this point in time, we desperately need assistance to understand the many ways in which the langpacks have become broken since they were last properly maintained. please remember that when they were last maintained and functional, there was only a single way to experience Sugar (via an XO laptop), this is reflected in assumptions that are not longer valid (e.g. the existence of a /home/olpc/ directory). <br>
<br>Sugar is now available in a multitude of ways and we will have to work to add support for the most commonly used by localizers (probably some variation on SOAS) to get the langpack process back to something once again generally useful. I suspect we succeed with re-establishing usefulness first on an XO laptop first, with other Sugar environments / distro methods gaining support over time. Feedback from users of those methods will be critical to getting it right.<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;">
<br>
Beside this details I have one general comment and question:<br>
This is extremely difficult, especially for a non-tech person (localizer), to setup environment for testing localization. One needs to know how to switch to root (what is root?!?) or install Sugar-Jhbuild (but first install python and git), get familiar with msgfmt command-line tool, generally be able to use UNIX terminal tools and many others. Ok, I know how to do all this stuff but it's impossible to ask someone without tech background to do it. It was comment. </blockquote>
<div><br>You make a fair comment, the current options for testing L10n (in between builds) are beyond the skills one would expect from the average localizer. We are in the very early stages of beginning to address that problem and need all of the help and detailed feedback we can get to produce a better result than simply firing up some very outdated code, which is all we've done so far. Only with the testing and diagnostic assistance of more Linux-savvy users like yourself and Samy will be be able to move forward successfully on behalf of the broader L10n community.<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;">The question is: why night build tools can't link sources with the latest version of .po (making .mo first of course) to provide up-to-date localized version for next day testing? Such version would be also available next day for other testers.<br>
One can still use detailed tech-description from /Localization/Testing web page if necessary.<br>
I don't know details and responsibilities for building process but linking the newest .po/.mo files doesn't seem to be very complicated task.<br></blockquote><div><br>That is precisely the intent of nightly builds. I would emphasize the the lang-pack process will work off of the git repo (committed PO files) and not the Poolte instance as it is only after commit that there is some reasonable assumption that the PO file has undergone some sort of QA review prior to commit. Do you think it is an unreasonable assumption that a language effort in the midst of a L10n push would regularly review and commit PO files incrementally? There are real challenges in pointing directly at the individual PO files in Poolte as they often exist in a state that will cause fatal errors in a language build process (failing msgfmt checks). whcih wou;d probasly prevent the completion of the automated langpack refresh.<br>
</div></div><br><br>cjl<br>