[Xfce-i18n] po/ChangeLog

[Daichi Kawahata]

On Fri, 21 Oct 2005 18:16:04 -0700
Brian J. Tarricone wrote:

> > Did you mind my branch/tag unification in xfmedia/trunk/po/ChangeLog?
> > What I've been concerned before modifying the file was exact that,
> > my intention trimming a ChangeLog (but hasn't any loss) is for end-user
> > who'll get the packages from their distributor, in which the given
> > path `xfmedia/trunk', `xfmedia/branches/xfmedia_0_9' for each files
> > won't make sense anymore after `make dist'.
> 
> I didn't even notice, to be honest.  xfce4-commits has been flooded with
> mail lately from all the work you do, and I've just been marking mostly
> everything read without actually reading it.

I know, that's certainly problem and another story, mass-updating will
happen when it comes with re-sync with the sources, it can be determined.
As for the frequently minor updating, another commit list may resolve the
problem.

> If you want to go to the extra trouble, that's fine, but I don't think
> it's necessary.  My guess is that a very small percentage of end-users
> actually read the detailed changelog, and those that do can cope with
> the strange layout.

Well, it was necessary for me (possibly certain end-users considering to
be translator) at least, BTW it's not even detailed!

> > Also, I was still not sure how they should be treated in between
> > top level ChangeLog and po/ChangeLog (sometimes, they have duplicate
> > entries).
> 
> My feeling is that po/ChangeLog contains only stuff that happens in the
> po/ directory, and the toplevel ChangeLog contains everything that
> happens underneath that top level (including po/) so the duplicates are
> fine.  At any rate, for me, I never touch po/ChangeLog, and I update the
> toplevel ChangeLog erratically with svn2cl, and I don't edit it at all.

That's exactly what I was doing on ChangeLog (excluding commit log happened
at another places), anyway I should avoid to commit diffs across the whole
modules, that's really terrible when I run svn2cl.

> >>What I'm suggesting is a "COMMITTING" file in the root of each module.
> > 
> > Well, do you mean xfmedia/trunk/COMMITTING, xfmedia/branches/xfmedia_0_9/
> > COMMITTING for example?
> 
> Well, I'd create a new one in xfmedia/trunk/COMMITTING, but I wouldn't
> bother to create one for existing branches.  Or, maybe it just makes
> sense to do xfmedia/COMMITTING, since presumably the policy is the same
> for all branches.  Yeah, I like that better.

And another modules (libraries, panel, file manager) follow that? If you're
just considering about committing by us, would it be better locating in po/
with renamed xfmedia/trunk/po/README.commit, README.svn? As you said you'll
care different trees with different ways, I'm not sure whether toplevel
one-stop file is sufficient. At least for me, I don't care some different
notifications are in the different locations.

> > >It need not be long (preferably it's no more than a couple short
> > >paragraphs and/or a bulletted list), and should contain any
> > > requirements
> > >for committing to that module.
> > 
> > Probably, if there's a certain guidance for that, we can get more
> > descriptive logs, as for the beautiful way of logging, you or Benedikt
> > can play a certain role, can't you?
> 
> Sorry, not sure what you mean.

Well, as far as I know, only you and Benedikt showed/noted an opinion
about commits (and logging), I'm not sure how the other developers think
about that. Okay, never mind.

> > > I don't want to scare translators away by creating a bunch of
> > > different requirements, but at the same time, module maintainers
> > > need to feel ok about other people committing to their trees.
> > 
> > Let me say, filename `COMMITTERS_READ_THIS' has already enough impact
> > as well as `YES_I_AM_BRIAN'. Well, what did you mean with `module'?
> > If you considered that as entire tree (from top to the bottom), probably
> > it's me you'd talk with, in other words, translators are basically
> > nothing to do with module, only the SVN commit-able translators can
> > access MODULE_ROOT/configure.ac(in.in) and MODULE_ROOT/po/.
> 
> I suppose not.  I'm probably just making up something to do that really
> has very little utility.  For the most part, translators will only be
> committing in po/ with the exception of the few people that have access
> to configure.ac to update XDT_I18N() as needed.

Or did you mind translation updating under development module (trunk)
itself? Shouldn't it be touched until they're frozen for the release?
At least, as for the Xfmedia, you can show your opinion or feeling to
us.

> > > So, if you're a module maintainer and don't give a damn (kinda like
> > > I feel about xfdesktop), feel free to not bother.  Otherwise, if
> > > this is important to you (like I feel about xfmedia), what do people
> > > think?  If this is a good idea, we can add this to the translation
> > > committers guidelines as well.
> > 
> > I'd agree if we could have such guidance at the first place, I was bit
> > tired of unfriendly po/ChangeLog (since, having look for the translators
> > to create the decent credits, there were many obstacles in front of me).
> 
> Right.  This should probably be a more general thing in the translation
> guidelines - translation committers should never commit .po files that
> don't have proper credits in them, or whatever.

My first thought was auto-modifying with script so the translators are
not being bothered, but it can be only applied for the maintained files
(without any active translators for the while).

Regards,
-- 
Daichi

Language Codes: http://www.w3.org/WAI/ER/IG/ert/iso639.htm
Country Codes: http://www.ics.uci.edu/pub/ietf/http/related/iso3166.txt