Re: On translation regressions due to freedesktop.org dependencies
- From: Christian Rose <menthos gnome org>
- To: Daniel Stone <daniel freedesktop org>
- Cc: GNOME I18N List <gnome-i18n gnome org>, freedesktop freedesktop org, GNOME Desktop Development List <desktop-devel-list gnome org>
- Subject: Re: On translation regressions due to freedesktop.org dependencies
- Date: Tue, 27 Jul 2004 08:36:12 +0200
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]