Re: [translate-pootle] Re: Web-based translation for GNOME

[David Fraser <davidf sjsoft com>]

Danilo Šegan wrote:

> Hi Dwayne,
>
> Thanks for sharing your thoughts!
>
> Today at 14:49, Dwayne Bailey wrote:
>
>  
>
> > 1) Pootle has the potential to bring much new fresh blood into your
> > communities, blood that is not all CVS, KBabel, vi inclined.
> >    
>
> Indeed, that's why we already have http://prevod.org/ for Serbian
> translations, though I've been lazy in updating it for recent Gnome
> releases (I need to run a script to fetch recent
> translation-status.xml and update my database). 
>
> Basically, we have tracking (who did what), reservation ("I'm working
> on this, don't touch"), glossary and restrictions (you can't update PO
> file which someone is working on) and (static web pages) rules.
> E-mail announcements about updated translations go to the mailing list.
>
> The big feature we're missing is per-message translation (we have
> per-domain translation, but without web editor).
>
> The biggest problem though is that my PHP code sucks there :)
>  
Ssh, don't tell anyone the code sucks :-)

> > 2) Pootle has the potential to improve the quality of translations
> > generally, through structured review cycles.
> >    
> Indeed, that's one of the best features I could see in Pootle, or any
> such system.  That's why I said web-based translation system would be
> nice to have for Gnome.
>  
>
> > 3) Pootle has the potential to make coordinating a language much easier
> > as you know whose assigned what could set goals, etc
> >    
> I agree.  But I probably have too much experience with my system, that
> I'm unwilling to sacrifice advantages it brings for advantages Pootle
> would bring, so basically,... 
>  
>
> > I'm biased :)
> >    
> ...I'm biased too :)
>
> My problem with Pootle is only that: I have my own biases, and it's
> hard for me to overcome them, especially since I have my share of code
> which overlaps with what Pootle tries to do. :)
>  
>
> > > While I think having web-based translation tool would be excellent for
> > > official GTP, I find Pootle quite lacking in features.
> > >      
> > I met a guy last week who refuses to use a cellphone: "I used a car
> > phone in the 80s they were big and impractical, been there done that, so
> > I'm not bothered with getting a cellphone"
> >    
>
> > From my sentence "I don't want us to make cellphones an official
> (meaning: promoted and recommended) way to talk to your mom", you
> deduce that I'm saying "car phones were crap back then, so I think
> cellphones are crap as well, and you won't be able to talk to your mom
> with them".  Does this really compare? :)
>
>  
>
> > At Translate.org.za we're actively using it. Yip there are many things
> > that could be added and they are appearing every day.  I've run it with
> > 40 people translating Firefox into Zulu.  We completed Xhosa in 2 days.
> >    
> So, I should be more constructive, I agree :)
>  
>
> > I guess what I'm saying is don't judge a moving target on your
> > experience from the first releases.
> >    
> Well, one can judge something just by what it is, not by what it may
> become :)
>  
That's fair enough. And its not always a bad thing to have multiple 
systems progressing in parallel

> > What can work now - or with a few changes - is to download the .zip file
> > from Pootle and extract that over your checked out Gnome.
> >    
> That's going to be very problematic (think: CVS conflicts).  I doubt
> most translators have broadband and ability to "cvs up" their entire
> Gnome checkouts prior to extraction step (they'd want only to cvs up
> what needs cvs up-ing).
>  
I've just got some initial file-based merging support working on Pootle 
and the aim is to use this for CVS merges.
Basically we could get the latest CVS revision and then do a 
PO-intelligent merge rather than dealing with CVS conflicts etc.

> > Email sounds good but do you want 100 emails?  We need some better ideas
> > on what change notification needs to come from Pootle.
> >    
> That's a problem with per-message translation systems.  Basically,
> what we want here is to have maintainers give forward announcements:
> "in three days we'll be releasing, so translators, please finalize your
> translations."
>
> Though, that's far from perfect as well.  "Notification granularity"
> is what translation coordinators would probably need (e.g. each
> message edit could be marked "critical", "normal" and "enhancement",
> with the default being "normal"; 1 "critical", 10 "normal" and 100
> "enhancement" updates might trigger an e-mail notification).
>  
Yes there would have to be some kind of intelligence built into this.
A IRC- or jabber-bot might be a nice idea for watching all the changes.

> > How would be best to represent what changed? diffs on PO files are often
> > hideous and unhelpful.  
> >    
> (Shameless plug: I'm actually working on sort of a podiff which will
> ignore differences in source references, translator's comments, etc.
> one slightly more complicated issue is actually emitting a minimal
> "diff -u" compatible patch, at least it's more complicated with my
> current PO file reader which ignores meaningless PO file data, such as 
> differences between
>
>  msgid ""
>   "blah"
>
> and
>
>  msgid "blah"
>
> )
>  
Cool, but seeing as we already have parsing stuff like this in the 
Translate Toolkit, don't you want to use ours?

> > How would you reject translations?  I'm not sure
> > if it would work to create a complex email parser.
> >    
>
> E-mails referring to web pages are just fine, IMO.  I'm too lazy to go
> to the same web pages and discover there have been no changes, while I
> regularly check my e-mail (basically, fetchmail does it automatically
> for me :).
>
>  
>
> > With the Translate Toolkit we can already merge changes into an existing
> > PO file.  Maybe one option is to email those changes and the coordinator
> > can edit those changes and merge them offline?
> >    
>
> That seems too complicated.  I think we need e-mail just for
> notification purposes.  Translation coordinator could then log in and
> enter CVS account info (which will not be stored, except *maybe* for
> username) to commit.  HTTPS would be quite beneficial for that (btw,
> is there any free software community based CA, which is also
> recognized by free software?).
>  
Apparently there is, can't remember the link.

> Things I have in my TODO list, which I suppose would be very useful
> for Pootle as well:
>
> - msgmerge reimplementation in Python (with my PO reader class), and
>   ability to use any fuzzy matching algorithm
> - word diff for msgmerge-d entries (I need this for xml2po as well)
> - glossary and translator integration
> - web translation editor should colour untranslated or fuzzy entries
>   background differently (when you _want_ to know context, so you're
>   showing all messages, these messages should be easily
>   distinguished), support search
>  
What I've currently been adding to Pootle matches some of this stuff 
nicely (it stores the differing strings separately and you can manually 
review and accept/reject them with a colour-highlighted diff).

> - using base language other than what's in msgid's (eg. if there's a
>   complete Croatian translation, and a Serbian translator is not very
>   well versed in English, she might want msgid's to be in Croatian;
>   this is easy to implement, though, but should be a big gain)
> - support full names in UTF-8 (heeey!) :)
>  
Full names?

> For reference, I've put my (yet unfinished) PO file reader class at
>
>  http://kvota.net/hacks/zmijsko-gnezdo/gettext_po.py  
>
> (it seems to be structured similar to Pootle's storage/po.py)
>  
Seeing as you're using Python for this rather than PHP, it would be 
great if we could combine efforts!
I'm very happy to accept enhancements to storage/po.py, it gets used by 
the Translate Toolkit as well as Pootle, and is fairly robust in terms 
of handling PO file syntaxes of various sorts.

> Also note that I really love some features of Pootle web editor!
Cool thanks :-)

David