Re: Project Start



sön 2004-08-08 klockan 12.52 skrev Telsa Gwynne:
> > > <para>
> > > It is probably best to pick something very small the first time, in order to
> > > get used to the translation tools you are using. It is also useful to pick
> > > </para>
> > 
> > Yes, but after one has translated those small standalone applications to
> > test things out, I think it's probably helpful if one continues with
> > some core libraries, like gtk+ and libgnomeui. The reason being that
> > those libraries have messages that appear all over the place and in many
> > applications.
> 
> Oh, absolutely. Did the text I quoted not make that clear? Because
> I agree with you. I shall rewrite it to make it clearer if that 
> doesn't come out. 

Oh, I meant that it wasn't clear to me if I hadn't carefully read the
other following paragraphs aswell, in which it was mentioned. That's why
I meant that it could perhaps be mentioned earlier aswell.


> > > Unless you are running GNOME built from CVS on your machine, you 
> > > are likely to have the most recent stable release on it. Therefore, 
> > > it is a good idea to translate the appropriate version of the application. 
> > > So if you have <application>bug-buddy-2.4</application> on your 
> > > machine, use the 2.4 branch of the <application>bug-buddy</application> 
> > > module in CVS. If you use a different version, some of the strings 
> > > will have changed, and when you test it, you won't see all of your 
> > >translations.
> > 
> > I'm not sure I agree with this piece of advice.
> > 
> > In my experience it's not uncommon for people to use versions of GNOME
> > that are almost ancient and long since forgotten by the GNOME
> > development community, like, say, GNOME 2.0 and GNOME 2.2 these days, or
> > even GNOME 2.4. Internet connectivity is expensive in many areas, and so
> 
> Blush. I still have Gnome 2.4 on one box myself, come to think of
> it. This section was probably influenced by the fact that lots of
> us were running Fedora (pretty up to date) or Debian unstable and
> so on. And we were specifically wanting to mention that it really
> helps to test the stuff if at all possible. Having just crashed
> a lot of stuff and been typing stuff at bug-buddy, I have just 
> spotted two embarassing typos in bug-buddy/po/cy.po which are much 
> easier to spot when it's all over your screen rather than one line 
> in a .po file. 

True.


> > downloading the latest and greatest distro with the most recent stable
> > version is out of the question. Hence people often rely on what software
> > they can get from magazine CDs and the like, and software on magazine
> > CDs are quite naturally not really often as uptodate as one would want
> > it to be.
> 
> This is true. Hmm. Erm. I see what you're saying here. I'll think
> about this one. The last time we updated this, we updated all
> the release references, so it looked cutting-edge at the time.
> But yeah, talking about "the latest stable" and then referring
> to 2.4 as the example is probably not ideal. 

I don't think there is a need to quote particular release numbers here
-- the releases we work on changes every six months at least, and I
would think it sucks having to update docs for changes like this all the
time. :-)

Perhaps it's enough to point readers to the translation status pages to
see what "the latest stable release" and "the latest development
release" are. But I'm not sure we have such a good link, come to think
of it, for languages that don't have any translations yet... :-(

I have in the past been suggesting that we'd introduce a special "C"
translation team on the translation status pages, that would always just
point to the potfiles, but otherwise be like any other team pages and
show the release and branch information. Carlos, would this be easily
doable with the current pages? Because there is a clear need for such a
pointer it seems.


> > Thus, I think it's always better to advise new teams to start with
> > whatever is the latest unstable version, and fetch the potfiles for that
> > from the translation status pages. That increases the chances that
> > whenever the team is done whatever translations they have produced are
> > still relevant and can be used, and still have a decent chance of being
> > as complete as one maybe expects them to be from having translated them.
> 
> Argh. Much re-writing to do.
> 
> > I thus think we should advise all new teams to jump on the current
> > train, instead of spending time on waggons/releases we've long since
> > left behind.
> 
> Fair enough.
>  
> > gedit is also a popular starter application, especially for languages
> > that require advanced script rendering. It makes for a good screenshot
> > of pango's abilities with such a script, both with the translation and
> > the document displayed.
> 
> Good point. I had forgotten about gedit. 
> 
> > The "ang" status web page appears as soon as the first ang translation
> > is committed to CVS. That's part of why I think new teams should try to
> > get some translations committed as soon as they can. Another reason for
> > this is that partial translations in CVS or released software is often
> > the best motivator for getting even more volunteers to want helping out
> > with making them complete. :-)
> 
> That's definitely true. I actually printed out pictures of the
> status tables for cy at various stages from the middle of the
> process to the end of it. Just seeing it turn greener and greener
> over time was great. Wish I'd thought of doing it right at the
> start.

:-)
I can imagine it makes for an impressive progress history chart. :-)


> Thanks for the feedback. I shall try to find time to update the
> document, assuming Daf is happy for me to scribble all over it
> some more. (There is a TODO next to it which has quite a list of
> things to add. I had forgotten that.)
> 
> But oh, I wish you'd mentioned some of this before!

Sorry -- I haven't had time to read all excellent docs produced so far.
:-(

And in case this isn't clear, these are just my opinions -- feel free to
correct me if you feel otherwise.


Christian



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]