freedesktop - Jul 2004 - [fdo] Re: On translation regressions due to freedesktop.org dependencies

(Please CC me on all replies: I am not subscribed.)

XDG people, this is the referenced email:
http://lists.gnome.org/archives/desktop-devel-list/2004-July/msg00491.html

On Tue, Jul 27, 2004 at 01:36:58AM +0200, Christian Rose
wrote:
> There have unfortunately been significant regressions now in translation
> coverage as we are in the phase of moving over to using freedesktop.org
> technologies inside GNOME, like recently with the MIME system, the MIME
> types and their translatable names and descriptions.
> 
> Unfortunately, there's no short-time solution to this in sight as far
as
> I can see, and it looks like this will be the case not only in the short
> GNOME 2.8 time frame, but beyond that aswell. The problem is mostly an
> administrative one, and not a minor one mind you, which is why it looks
> difficult to resolve.
> 
> This is basically the problem:
> 
> While some key developers have access to freedesktop.org CVS in order to
> be able to maintain their software, many other contributors have not.
> This includes translators.
> 
> [...]
(freedesktop hat on)

Hi guys,
Let me start out by saying translations are a hard problem - a massively
hard problem. It's not that no-one wants to fix it, it's just that
I'm
honestly not sure how.

fd.o doesn't govern most of our member projects; we consider ourselves a
little more like SourceForge like GNOME in that regard (and that regard
only, it must be stressed). They ask for projects, we create them. They
ask for new users, we add them. They ask for services, usually that
request is fulfilled. The only power we wield is the fact that we're
root on the machines in question.

Therein lies the problem: only a very small number of people can access
all the CVS repositories, and even then I would consider this a severe
violation of trust and invasion of privacy, because it involves using
sudo. Which is wrong, and bad.

We also don't dictate policies or mechanisms to our projects, which
includes not dictating who they add to their projects. Thus, we don't go
around giving all translators global access. This may change, but it
would require the consent of all projects: no offence meant to any
translators, of course, but this access is important - there are a lot
of projects hosted on fd.o, and giving a few people commit access to all
of them is like a blank cheque.

So, IMO, giving all translators CVS access isn't really a solution.

What is?

(I don't know.)

One possibility is having a i18n module with a structure such that it
can be overlaid over member projects, and performing the necessary
CVS-fu to make this happen (e.g. you check out dbus, and dbus/ comes
from /cvs/dbus/dbus, and dbus/i18n or whatever comes from
/cvs/i18n/dbus).

... I can't really think of much else.

If there is clear consensus on a solution, I'm willing to set aside a
couple of hours *tomorrow* to make this happen. I can see how this is a
time-critical problem, and am prepared to put in the effort to see it
resolved.

So, if you have any questions/comments/whatever, please reply (remember
to CC me), or catch me on IRC as daniels.

Cheers,
:) d

-- 
Daniel Stone                                           
<daniel@freedesktop.org>
freedesktop.org: powering your desktop                http://www.freedesktop.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url :
http://freedesktop.org/pipermail/freedesktop/attachments/20040727/64c66a87/attachment.pgp

Hi,

Is there some way we can have a list of groups that translators should
be in, such that each module maintainer can add their module's group to
the list?

So e.g. I could say "translators should be in group dbus" and then
translators would be able to access the dbus module.

Havoc

tis 2004-07-27 klockan 03.03 skrev Daniel Stone:
> Hi guys,
> Let me start out by saying translations are a hard problem - a massively
> hard problem. It's not that no-one wants to fix it, it's just that
I'm
> honestly not sure how.
OK, I was a little worried about the lack of response. If it's just that
there's no policy decided yet, then that partly explains it.


[...]
> Therein lies the problem: only a very small number of people can access
> all the CVS repositories, and even then I would consider this a severe
> violation of trust and invasion of privacy, because it involves using
> sudo. Which is wrong, and bad.
> 
> We also don't dictate policies or mechanisms to our projects, which
> includes not dictating who they add to their projects. Thus, we don't
go
> around giving all translators global access. This may change, but it
> would require the consent of all projects: no offence meant to any
> translators, of course, but this access is important - there are a lot
> of projects hosted on fd.o, and giving a few people commit access to all
> of them is like a blank cheque.
> 
> So, IMO, giving all translators CVS access isn't really a solution.
[...]

(Just for the record -- we don't allow CVS access for all translators in
GNOME either, and all translators don't have accounts. The person must
be able to show that he or she has already contributed, and the account
request must be sponsored by the translation team coordinator for that
language, just like regular accounts must be sponsored by the software
maintainer for the piece of software in question. Still, almost every
language team has at least one person with CVS access, and sometimes
more than that.)

> One possibility is having a i18n module with a structure such that it
> can be overlaid over member projects, and performing the necessary
> CVS-fu to make this happen (e.g. you check out dbus, and dbus/ comes
> from /cvs/dbus/dbus, and dbus/i18n or whatever comes from
> /cvs/i18n/dbus).
Translators certainly don't need access to *all* modules. Restricting
the access to some which need translations is perfectly fine -- this is
also basically what some distributions who give CVS access to external
translation volunteers do.

And as Havoc said, giving the maintainers some easy way to enable or
disable this for their module themselves instead of having to bug the
admins for it would be great.

However, I'm not sure about imposing further access restrictions on top
of this, like letting translators only commit to the po/ directory.
Experience in GNOME shows that many translators aren't translators
forever, but rather move around between different roles; testing,
bugfixing, patches, and so on. Allowing ad-hoc contributions in those
modules, given maintainer permission of course, instead of bureaucratic
manuevers to first get past technical access restrictions, often has
advantages, not at least because it encourages contribution. And I'm
hoping that by sorting out the most security critical modules from
translation access, then this is still possible to do for the modules
that are left. But that's something that's still very much open for
discussion.

> If there is clear consensus on a solution, I'm willing to set aside a
> couple of hours *tomorrow* to make this happen. I can see how this is a
> time-critical problem, and am prepared to put in the effort to see it
> resolved.
Oh, many thanks for the offer!

As a not totally unrelated issue, it would be good if we could start
getting a fd.o translation project going, at least in a small scale, to
help getting translation contributors started. A
translation@freedesktop.org mailing list would probably be a good start.


Christian