[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [BOOK] Translation to spanish

From: Grzegorz Adam Hankiewicz <gradha_at_titanium.sabren.com>
Date: 2004-10-03 19:12:42 CEST

On 2004-10-02, Erik Huelsmann <ehuels@gmail.com> wrote:
> Ok. I see these relevant sections in HACKING:
> * Writing log messages
> * Patch submission guidelines
> To start with the latter, it will not be in your way, since you
> will (presumably) be committing your changes.

True, not a problem if every translator has commit access.

> The former says you should write a log message which describes
> what you changes, continuing to state requirements to documenting
> code changes in the log. The documenting-code-changes-in-the-log
> part does not apply to the book, so that the only requirement
> here will be that you describe the nature of the changes you
> applied. Maybe you interpreted HACKING differently?

I don't see any exceptions in HACKING related to
documentation. Previous posts contradict what you say
too, unless I misunderstood both HACKING and those posts.

> If so, would using my interpretation be enough to have you use
> the Subversion repository?

I could discuss this if the exceptions you talk about are clearly
defined, which currently is not the case. Have these exceptions
been communicated to other book translators?

> > The second reason would be the verbosity of the main development
> > repository. [...] I don't want translators to have to bother
> > with such amount of email. I don't want to deal with it myself.
> I chatted with some of the other devs in IRC and those who spoke
> on the subject feel that your commit volume will not be a problem
> to the rest of Subversion development. We welcome your commit
> volume as we welcome your project.

Thanks. It's just that I don't welcome extra commit messages
unrelated to the task I'm interested in, though.

Another icky problem would be non utf8/ascii logs/contents in commit
emails, as sadly documented around line 440 of commit-email.pl. I
currently fixed it hacking the charset and using an additional script
to translate svn utf8 logs into latin1 before they are included in
the mail.

This raises another issue not discussed in HACKING, which is non
English log messages and how they should be used, if at all allowed.

> We however feel that you can spend your time most effectively if
> you can work with only one repository. With resyncing much more
> risks are involved at keeping both translations up to date. Besides
> that, the project must be more actively managed which takes time
> we'd like you to be able to use to do your translation.

OTOH each translator is then forced to follow (IMHO) unproductive
rules and deal with a higher volume of emails. Since you demonstrate
willingness to lessen the former and translators might be able
to deal with the latter, I will discuss this on the mailing list,
because until now I only spoke for myself.

However, I still think that subversion code development and
translation of documentation are tasks better dealt with separately,
in a modular approach.

On 2004-10-02, Erik Huelsmann <ehuels@gmail.com> wrote:
> Do you (or will you) have a file in your tree somewhere which
> states which rev is currently being translated?

At the moment each file contains "<!-- originated from English
revision 10817 -->".

> > > Should I announce the translation project on
> > > announce@subversion.tigris.org? Maybe somewhere else?
> That would be a good place to do so. It would be even better if
> you could mention a URL for your project within the Subversion
> repository. :-)

After browsing its archives and reading Max's answer, I will try to
announce it in Spanish related websites/mailing lists once there
is a useful amount of translated chapters. Reaching the correct
audience and all that stuff.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Oct 3 19:13:05 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.