Re: [Changeset] r4828 - django/trunk/django/conf/locale/de/LC_MESSAGES
Malcolm Tredinnick
On Sun, 2007-03-25 at 18:31 -0500, nor...@djangoproject.com wrote:
> Author: adrian
> Date: 2007-03-25 18:31:40 -0500 (Sun, 25 Mar 2007)
> New Revision: 4828
>
> Modified:
> django/trunk/django/conf/locale/de/LC_MESSAGES/django.po
> django/trunk/django/conf/locale/de/LC_MESSAGES/djangojs.po
> Log:
> Fixed #3633 -- Added credit to German translators. Thanks, Dirk Eschler
Given our "no names in code" policy, I'd been thinking about not
applying this. All translators' names are (or should be) in AUTHORS in
any case.
Apologies for not making my intentions clear in the ticket: I was
waiting until after 0.96 to have the conversation, since we didn't seem
to have enough spare cycles to address even all the things we had to do
before hand.
Are you happy with having all the credits at the top like this? If so,
we're going to get a bunch of these changes for every language file. I'm
not totally comfortable with these files being different from code
files, but am happy if you want to do so -- just want to be consistent
in what we do in the future.
Regards,
Malcolm
Adrian Holovaty
> Given our "no names in code" policy, I'd been thinking about not
> applying this. All translators' names are (or should be) in AUTHORS in
> any case.
>
> Apologies for not making my intentions clear in the ticket: I was
> waiting until after 0.96 to have the conversation, since we didn't seem
> to have enough spare cycles to address even all the things we had to do
> before hand.
>
> Are you happy with having all the credits at the top like this?
Ahh -- great point. I completely neglected to consider that policy. My mistake!
Are there any arguments *for* breaking the policy and including the
names? If not, let's roll it back.
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.com
Malcolm Tredinnick
I don't think there are strong arguments for including the names.
Ironically, the patch was submitted because of a suggestion I made on
the i18n list and only 24 hours later did I think of how it integrates
with our policy (I realised that translators were no more or less
special than other contributors).
One thing we do have to watch out for as translation activity picks up
is that we currently have no language coordinators/maintainers. This
could potentially lead to translation "battles" with some phrases
changing back and forth, if there's any confusion or dispute. Having the
names of previous contributors makes tracking down the history and
resolving these problems a little easier.
However, Jacob and I have discussed (after prompting from the
translators) giving commit privileges under django/conf/locale/ to
certain language maintainers -- one for each language -- to keep things
on an even keel there. That makes a lot of sense to me, because,
frankly, I have no way to judge if a patch for, say, the XYZ locale is
an improvement or not; I would much rather have a native speaker take
responsibility there. Jacob wants to make it easier for those people to
set up passwords via the web interface to ease his load a little, so
that will happen in due course, but I realise he seems pretty busy at
the moment, so I'm not pushing that yet. For now, we don't really have a
problem here, so it's not blindingly urgent.
Assuming you're happy with allowing locale maintainers to commit
directly (it's pretty normal on a lot of other projects), I don't think
there's a technical reason for having the names in the code, so we
should be consistent.
Regards,
Malcolm
Nicola Larosa
Malcolm Tredinnick wrote:
> One thing we do have to watch out for as translation activity picks up
> is that we currently have no language coordinators/maintainers. This
> could potentially lead to translation "battles" with some phrases
> changing back and forth, if there's any confusion or dispute. Having the
> names of previous contributors makes tracking down the history and
> resolving these problems a little easier.
That's not going to help when one's having "battles" with oneself. Case in
point, before 0.96 I updated the italian translation, more or less out of
the blue. Then some discussion ensued on the italian Django mailing list,
which prompted me to make further updates a couple of times. In the
meanwhile, the author named the .po file stayed the same, of course. :-)
> However, Jacob and I have discussed (after prompting from the
> translators) giving commit privileges under django/conf/locale/ to
> certain language maintainers -- one for each language -- to keep things
> on an even keel there. That makes a lot of sense to me, because,
> frankly, I have no way to judge if a patch for, say, the XYZ locale is
> an improvement or not; I would much rather have a native speaker take
> responsibility there.
That would be great. It would make it easier having more frequent updates
and corrections, relieving the burden of committing them from the main
developers.
It could also lead to a bit more instability and more changes than
necessary, but that can be mitigated if the language maintainers try to
discuss changes locally a bit, before committing them. Yes, I'm promising
I'll do better on that front, from now on. ;-)
> Jacob wants to make it easier for those people to
> set up passwords via the web interface to ease his load a little, so
> that will happen in due course, but I realise he seems pretty busy at
> the moment, so I'm not pushing that yet. For now, we don't really have a
> problem here, so it's not blindingly urgent.
Well, as they say, best is enemy of good. :-) Setting up passwords
centrally is a one-time job, while the translation-committing burden
lightening is ongoing: maybe it's better not to wait for such a web
interface to materialize.
> Assuming you're happy with allowing locale maintainers to commit
> directly (it's pretty normal on a lot of other projects), I don't think
> there's a technical reason for having the names in the code, so we
> should be consistent.
Ok, go ahead and strip the italian translation of them too, I and the
previous translator (hi, C8E!) are in AUTHORS already. No, I'm not creating
a patch. ;-P
--
Nicola Larosa - nicola...@gmail.com