Thadeu Lima de Souza Cascardo <cascardo@xxxxxxxxxxxxxx> writes:
> On Mon, Jun 29, 2009 at 09:08:00AM -0700, Junio C Hamano wrote:
>> Thadeu Lima de Souza Cascardo <cascardo@xxxxxxxxxxxxxx> writes:
>>
>> > Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@xxxxxxxxxxxxxx>
>>
>> Thanks.
>>
>> > +Você também pode dar ao 'git-log' um "intervalo" de commits onde o
>> > +primeiro não é necessariamente um ancestral do segundo; por exemplo, se
>> > +as pontas dos ramos "stable" e "master" divergiram de um commit
>> > +comum algum tempo atrás, então
>> > +
>> > +-------------------------------------
>> > +$ git log stable..experimental
>> > +-------------------------------------
>> > +
>> > +irá listas os commits feitos no ramo experimental mas não no ramo
>> > +stable, enquanto
>> > +
>> > +-------------------------------------
>> > +$ git log experimental..stable
>> > +-------------------------------------
>> > +
>> > +irá listar a lista de commits feitos no ramo stable mas não no ramo
>> > +experimental.
>> > +
>>
>> I think you would want to update this part to match what you did in your
>> [PATCH 1/2 v2].
>
> Well remembered. Thanks.
As I do not speak the language, even though I can guess that a straight
replacement "s/experimental/master/g" would be enough for the above quoted
part (including the body text), I do not feel comfortable enough to update
these myself. Please send in a replacement [PATCH 2/2 v2].
>> I however am not sure how practical it would be to force people to look at
>> the *.txt version of document, only 1/n lines of which is now readable by
>> him (if you are like a typical American who understands only English ;-).
>>
>> Thoughts?
>
> I think that using something like po would be better. There are tools
> that can extract and update the template messages from many differente
> sources. Adapting them to produce a template file from gittutorial.txt
> would allow translators to verify how stale their translations are and
> much smoother merges. How about that?
After thinking about it a bit more, I think I would prefer something that
keeps translation sources separate from the original text. That way, I
have a lot less chance of having to deal with merge/patch conflicts.
Your patch adds Documentation/pt/ hierarchy, but I noticed that the kernel
folks seem to use Documentation/{ja_JP,ko_KR,zh_CN}/. I do not think it
would make much difference for Japanese language between ja vs ja_JP, but
for many languages used in different geographic areas, such an arrangement
would make a lot more sense. As your patch identified itself as a
translation to "Brasilian Portuguese", I am imagining that it would be
sufficiently different to merit the distinction from Old-world Portuguese.
Perhaps your patch should be made to Documentation/pt_BR instead?
As to the choice of the tool, from a quick superficial glance, po4a could
be a reasonable choice, but I do not know how mature and/or widely used it
is, or if there are better alternatives. http://po4a.alioth.debian.org/
says it does support AsciiDoc.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html