Release Criteria

Thomas Diehl thd at kde.org
Fri Nov 15 11:56:19 GMT 2002


Am Freitag, 15. November 2002 06:28 schrieb George Staikos:

> On November 14, 2002 14:46, Roberto Selbach Teixeira wrote:
> > > I'm sure that there will be some documentation and i18n feedback too. 
> > > I don't know enough about those processes to insult the team members
> > > with an attempt at determining what makes their work "ready to ship".

Currently, a translation becomes a "release candidate" as soon as there's 
a fully translated kdelibs.po (which means 90% translated strings or more) and 
around 75% translations of kdebase and the assorted desktop files. There is a 
new statistics page at http://i18n.kde.org/stats/gui/HEAD/essential.php which 
is supposed to reflect that minimum requirements (soon). For the main GUI 
statistics see http://i18n.kde.org/stats/gui/HEAD/index.php. There are 
similar pages for branches and docu translation (all by Claudiu Costin).

Apart from that, translations can also be included on special request of their 
maintainers even if they don't meet the above requirements (if they eg think 
that they can attract new translators easier that way).

> > Translations are even more important than most realise. Often I find
> > small translation problems in KDE, but sometimes there are some really
> > nasty ones. For the end user, a bad translation can ruin a great
> > interface. The most common problem is literal translations.

For me, the most common problems are stemming from the fact that translators 
just don't get enough context in their PO(T) files to really understand what 
a certain string is aiming at. What you usually get is a single word like 
"light" and it is mere guesswork to understand whether this means "light" as 
in "sun light", "light" as opposed to "heavy" or "bold", "light" as in "light 
green" or as in "light rain" etc. etc. Not to mention the many highly 
specialized tech terms in many strings.

At any rate, it would be helpful at times if developers could take a look at 
their POTs and for a moment, assume the role of a translator and add as many 
context info via comments as possible. Please be aware that translators often 
don't have the time for a thorough context check in a freshly compiled CVS 
version before releases. And even if they do they can't dig up all dialog 
boxes from every menu layer.

>   Do you think it is feasible to get an "Ok" from the coordinator for each
> translation team before?

We have people watching the GUI statistics and creating lists of release 
candidates during the betas. (Currently, this is mostly done by Piotr 
Szymanski.) They are also supposed to contact teams that start lagging behind 
for no apparent reasons. The lists are posted on kde-i18n-doc. If anybody 
thinks his/her translations are not yet ready for release or should be 
included no matter what (s)he is invited to comment on that. Doc translation 
is not yet included in the basic release requirements.

> > Also, there should be a minimum percentage of messages translated to some
> > language for it to be released with KDE. Mixing untranslated strings with
> > translated ones looks quite unprofessional.

As to the basic requirements, see above. Of course, we don't have a chance to 
control the quality of those translations. This is the job of the maintainers 
of the individual languages and the users. For a list of maintainers see 
http://i18n.kde.org/teams/

Mixing untranslated strings with translated ones can't be entirely avoided 
nevertheless.

>From the developers side, there is always a certain rate of strings that for 
some reason or other does not appear in the POTs at all, esp. in newly 
included programs. It would _really_ help if developers would use a 
translated version of their program now and then and would use the "xx" 
language in CVS for testing purposes as much as possible.

>From the translators side, it's just too much work for small or newcoming 
teams to expect completely localized KDE versions (currently we have 
something like 60,000+ GUI and 38,000+ doc strings overall, including nonbeta 
and extragear). And on a program level, there will always be POs that slip 
into releases while they are only half-translated.  Sometimes this is not a 
big problem, sometimes it is. It's up to the individual teams and esp. their 
coordinator to decide which files should go in and which should not. -- 
Anyway, this gives me a good chance to remind developers of our long-standing 
feature request to enable language selection on an app basis, not only for 
KDE as a whole. Hope we are going to see this in 3.2 ;-)

Regards,

Thomas


-- 
KDE translation: http://i18n.kde.org
Deutsche KDE-Uebersetzung: http://i18n.kde.org/teams/de






More information about the kde-core-devel mailing list