Re: Project Start
- From: Christian Rose <menthos gnome org>
- To: Telsa Gwynne <hobbit aloss ukuu org uk>
- Cc: 'GNOME I18N List' <gnome-i18n gnome org>
- Subject: Re: Project Start
- Date: Sun, 08 Aug 2004 01:54:36 +0200
lör 2004-08-07 klockan 09.10 skrev Telsa Gwynne:
> There is a guide to (parts of :)) getting started which Daf and I
> put together. Which we probably need to update. But we did discuss
> this a little in that.
>
> It's in gnome-i18n/l10n-guide/C/l10n-guide.xml
[...]
> <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
> something which is an application rather than a library. This way, you will be
> able to run the application and see what it looks like. So a small stand-alone
> application is a good choice.
> </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.
So perhaps it should already here be mentioned that small standalone
applications isn't everything. ;-)
> <para>
> 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.
> </para>
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
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.
Anyway, what I want to say is that if a new team starts translating
GNOME 2.4 (or even GNOME 2.6) today, by the time they are done and happy
with the translations, the rest of the GNOME community will be working
on the GNOME 2.10 release or something, and those fresh GNOME 2.4
translations will be of very little use since so much has changed by
that time.
Moreover, that team will have wasted a lot of time translating stuff
that is perhaps no longer present anymore, and their translations will
never be as complete and shiny as they maybe expect them to be since
there will never be made releases of GNOME 2.4/2.6 anymore at that time,
where those translations would have shined.
So the shiny, complete GNOME 2.4/2.6 translations the team has carefully
produced, reviewed, tested and gotten input from linguists on, may in
fact by that time end up being only 60% or even 50% complete and miss
out on a lot of new important messages that have come since then.
This has actually happened -- some teams have in the past been very
proud of their complete or supported translations, perhaps not fully
realizing that those complete or supported translations were made for an
old GNOME version that will never again have releases made.
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.
Yes, it's difficult to test a new translation with old software, as some
of the strings will never show up translated since they have changed
between the versions. But you can test some of it, and at least get an
idea of what it looks like, and catch some of the problems in time. And
at the same time the translations are current and have a decent chance
of being useful in the latest version.
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.
[...]
> So I'd go for something like bug-buddy, gcalctool or gnome-utils as
> small stand-alone applications to get the hang of the tools.
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.
> And then libgnomeui, which contains all the stuff for toolbars and
> menus and buttons (Edit, View, New, Open a file, Save as..)
Yes, definately. And I think the importance of gtk+ cannot be
downplayed. For RTL languages it's outright essential to at least start
with some parts of gtk+ right from the start, since the RTL setting
itself is in the gtk+ translation... Also, the gtk+ translation also
defines some other stuff that is useful for many languages.
> Once you have those submitted, you will find a webpage generated as
> http://l10n-status.gnome.org/gnome-2.8/ang/index.html (assuming ang
> is your code. You can substitute cy or en_GB or da for that to get
> a look at what they look like and what info they contain).
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. :-)
Cheers,
Christian
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]