Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Martin Bagge / brother <brother <at> bsnet.se>
Subject: Re: Translations feedback loop
Newsgroups: gmane.comp.desktop.lxde.devel
Date: Friday 23rd April 2010 11:17:22 UTC (over 7 years ago)
On Mon, 19 Apr 2010, Marty Jack wrote:

> One of the things that is still unsettling about the release process is 
> knowing when a code/string freeze is over.  For example LXTerminal is 
> waiting to be released.  I have no easy way to determine when it is 
> ready and I have no feedback from anyone about whether they have tested 
> it and found it stable, except that there is a known nasty segfault in 
> the latest release of VTE that is also affecting gnome-terminal.

Either I don't remember this freeze or it's announced unclear. As far as I 
know I have not issued a call for translations and by that I do not think 
we are in release mode and string freeze.

The work flow I would like to see is:
1. developer(s) add code and do magic
2. (lead) developer announces to lxde-list that a release is upcoming
3a. packagers start their individual processes and tests the code
3b. a request for translations is sent to lxde-l10n with a deadline for
     submissions
4a. the packagers acknowledges that the code does work with no know errors
     in their dists
4b. the translation period ends and all files are tested for errors. this
     might need some extra time to solve problems if they rise but
     hopefully not and by time they will all go away as we get better doing
     these things.
5. Tag release.
6. Release. Add file(s) to SF.net. Write blog post. Announce on twitter.
    And so on.

3a and 4a are one track. 3b and 4b is another track. They will work 
independently.

1, 2 and 3a are gates where a freeze and iminent release announcement can 
be rolled back.
Work in 3b can still be executed but if a roll back will happen we better 
tell the translators to wait because something is not working and so on. 
If we don't think it will impact any strings they should continue ofc.
At 5 I do think we have to release something. A statement would do - 
release 1.xx.yy will not be released until work in component X is relased 
- this would be the case for components that depend on each other in some 
way.

> If Martin Bagge could educate us on what he uses as minimum 
> percent-translated of "n" languages, or whatever other metric, at least 
> we would be able to evaluate this for ourselves using the intl analyzer. 
> At my old job we used to call this "minimum ship criteria", although 
> that also took into account number of open bugs, and other things.

Earlier I used 50% strings translated as a benchmark for languages 
considered maintained. 80% was considered in well shape and more or less 
done (very small efforts would be needed to bring one or more components 
to 100% and some of them probably was done already). This is TOTAL numbers 
for ALL components. PCManFM with hundreds of strings compared to LXDM with 
9 is two totally different cases to work with as a translator.

Nowadays it's easier to add new languages and I am not totally comfortable 
to draw a harsh step like that. Adding the release process above that I 
think we have to do the steppings in the individual components (or packs 
fo components).

My take would then be to state a time line for when to finish a 
translation. And I would include all of them in releases, it's hard to 
tell for me if a language would suffer from showing a half done 
translation. Might be.
I haven't been able to do checks but there were discussions about dropping 
the LINGUAS file method for what languages to build. I do concur with that 
but I think we should add a do-not-build-list for languages that we know 
os orphaned or in very bad shape. One example for this list would be 
Arpitian. We have a translator but he has told me that he will not be able 
to finish anything before June/July and the fact that Arpitian uses frp - 
a locale that is far from complete and usable makes me proposing this 
solution.


PS.
Sorry for the late reply.
I am still catching up. I have now moved back to my parents house for two 
months before I get a new apartment in Varberg where my new job is located 
(I commute by car 160 km every day =)).
Speaking of job situation. I reached a settlement with Vodafone and 
left them in mid April (they closed the branch where I worked) and am now 
employed by Procera Networks where I do command line interface 
implementation for Packetlogic.

Soon I am back to my normal pace.

-- 
brother

------------------------------------------------------------------------------
 
CD: 3ms