lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: German translation help file


From: John Mandereau
Subject: Re: German translation help file
Date: Wed, 03 Jan 2007 00:35:25 +0100

Johannes Schindelin wrote:
> Hi,
> 
> I'll just comment the German text in English, and leave the complete 
> translation to you...
> 
> On Mon, 1 Jan 2007, Till Rettig wrote:
> 
> > Es muss git (und evtl. cogito) installiert sein, das letztere 
> > Vereinfacht die Handhabung. Weitere Informationen finden sich auch noch 
> > im LilyPond-Wiki 
> > (http://lilypondwiki.tuxfamily.org/index.php?title=Translations_HOWTO).
> 
> I'd rather recommend against using cogito, as you are more or less bound 
> to Linux with that. When I still had a working Mac, I never got it to run 
> properly.

That's my fault, because I'm the one who told to use Cogito on the
refenrenced wiki page. I wasn't aware that Cogito was hardly portable
outside GNU/Linux (so I understand now why you spoke of "portability"
earlier). So let's drop Cogito, or could we tell Mac OS X users to
install Fink?



> I'd rather bite the bullet and say
> 
> $ git clone -n git://git.sv.gnu.org/lilypond.git
> $ git checkout -b myweb web/master
> 
> This does a little too much, but it is easier than
> 
> $ mkdir lilypond
> $ cd lilypond
> $ git init-db
> $ git fetch git://git.sv.gnu.org/lilypond.git web/master:web/master
> $ git checkout -b myweb web/master

No, I prefer the cleaner way (and kept them in the revised README), even
if the bunch of commands may scare newbies; they just need to
copy'n'paste the commands, so what's the problem?


> > Es ist dabei wichtig, dass die erste Zeile das commitish enthält,
> 
> Why would it be important that the first line has a committish?

To record the revision of the translated page, so that
"make check-translation" later tells the translator what he should
update in the translated page.

> > git-rev-list HEAD | head -1
> 
> It is way easier to say
> 
> $ git rev-parse HEAD

That's what README tells now.


> But then, you really do not need that all that often. If you work locally, 
> it is better to reference the commit by "HEAD" for the tip, "HEAD^" for 
> its parent, "HEAD~2" for its grand-parent, "HEAD~3" for the great 
> grand-parent, and so on.

Yes, but make check-translation needs a static committish.



> I'd rather tell the user that "-a" means that git will commit all the 
> changes of all files it knows about (i.e. all that were present in the 
> revision you forked from, plus all files you added), where change can also 
> mean that the file was removed.

Good point. I'll try to add this to README.


> It would be better to find the committish in another manner: When you 
> forked from the upstream web/master, like I proposed ("git checkout -b 
> myweb web/master"), you can do
> 
> $ git format-patch web/master
> 
> and you will get _all_ revisions which are not in the branch web/master, 
> but in your current branch.

That's how README tells translators to do.



> If you only want the patch which made the newest revision, do this:
> 
> $ git format-patch HEAD^
> 
> ("HEAD" is whatever the tip of the current branch is, and "^" means its 
> parent.)
> 
> You also should mention "git diff" to see what you actually changed since 
> last committing, and "git commit --amend <file>" to add some changes to 
> the current revision (this _rewrites_ the current HEAD, so you must not do 
> that when you pushed that HEAD out already).

I wonder whether "git format-patch HEAD^" and "git commit --amend
<file>" need to be explained in README.


> > Dabei werden einige Dateien erstellt, u.A. auch die Datei, die den Namen 
> > hat, mit dem man git commit ausgeführt hat. Diese Datei wird dann per 
> > E-Mail an lilypond-devel oder lilypond-user eingeschickt.
> 
> You should rather mention the commit in the email, but you don't need to 
> write down all forty characters; 8 should be sufficient.

I always copy'n'paste commit numbers with mouse, so copying 8 or 10 or
40 characters is almost the same effort. But in this case, the commit
numbers are useless, as they may be not the same as those of commits
made by the git pusher (that's me).

Johannes, thank you very much for all Git support you provided; you
should be credited in README ;-)

Till, I think you needn't bother translating README.de; do it only if it
seems essential to you.

Cheers
-- 
John Mandereau <address@hidden>





reply via email to

[Prev in Thread] Current Thread [Next in Thread]