[Localization] Localization Digest, Vol 55, Issue 3

[Chris Leonard]

On Sun, Oct 9, 2011 at 6:02 AM, Jakub Ratajczak <jamarat at o2.pl> wrote:

> Chris,
> Unfortunatelly the http://wiki.laptop.org/go/Localization/Testing 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.
>
>
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,



> 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).
>

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).

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.


> Beside this details I have one general comment and question:
> 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.


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.



> 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.
> One can still use detailed tech-description from /Localization/Testing web
> page if necessary.
> 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.
>

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.


cjl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/localization/attachments/20111009/6316648a/attachment.html>