All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nicolas Sebrecht <nicolas.s.dev@gmx.fr>
To: Emmanuel Trillaud <etrillaud@gmail.com>
Cc: Nicolas Sebrecht <nicolas.s.dev@gmx.fr>,
	Thomas Moulard <thomas.moulard@gmail.com>,
	Git Mailing List <git@vger.kernel.org>
Subject: Re: gitk : french translation
Date: Sun, 8 Nov 2009 22:41:30 +0100	[thread overview]
Message-ID: <20091108214130.GA12931@vidovic> (raw)
In-Reply-To: <9f50533b0911080955l606ea87aw4edd7b0bc926a25f@mail.gmail.com>

The 08/11/09, Emmanuel Trillaud wrote:
> 2009/11/7 Nicolas Sebrecht <nicolas.s.dev@gmx.fr>:

> > [
> >  Please, conform to Documentation/SubmittingPatches of the git.git
> >  project and send your patches inline to make the work for reviewers
> >  easier.
> >
> >  Both of your patches lack the Signed-off-by but maybe you don't want
> >  them to be merged?
> > ]
> I am aware of this recommendation but this translation is almost 22kb and
> I tought that put it inline wouldn't make the review easier. I will
> submit a patch
> gathering my workand those of the reviewers soon.

Thanks, it will really help. If the patch is very long, you could split
it into more patches for the review purpose, maybe relying on the
semantic fields. Regardless you split it or not, inline patches are the
good way to contribute here.

Side note : you _must_ have the signed-off-by from Thomas if you want to
use his work.

Oh, and please, submit the new version in this thread.

> > I disagree here. Words like "diff", "commit", "patch", etc should be
> > kept as is. Translation of those terms make things harder for the users.
>
> I agree with you when those terms refers to _commands_ names, but the
> main goal of a
> translation is to _translate_ and we have to make the best effort to
> use french word if they _exist_

I don't think so. Here is _why_: the user-frienliness of a translated
software comes from "how hard is it to connect a word with the
underlying concept".

IOW, we want to have good words to refer to the _concepts_. In the
computer science world (and more _specially_ for a SCM), those concepts
are much more well-known with the english terms. Keeping english words
help users to directly understand what it is about, without making the
users have to search for "what the fucking translators are refering to
here?".

> and _are_ appropriate (that's why I'm not sure about translate
> "cherry-pick" by "ceullir").

I don't have strong opinion for this one because :
- the translation is good enough to be directly understood ;
- where "cueillir" (or so) is used, we have the fallback to the english
  term between round brackets.

> I prefer to translate "Diff this -> selected" by "Différence entre ça
> et selection"
> because it is what the user do when he make a diff.

Looks ok to me, except that "Diff" is better than "Différence" for the
reason I give above. A "diff" is clearly about a _patch_ where
"différence" may be used to much more concepts. French people don't use
the word "différence" to talk about a diff, they use "diff" as is.

> because it is what the user do when he make a diff. I am also ok to
> translate "merge" by "fusion"
> because it's what "merge" is in french and I don't this we mislead the
> user by using the term
> "fusion".

I don't have a strong opinion on this because both english and french
words are known. That said, I tend to think that the english word is
better here too.

-- 
Nicolas Sebrecht

  reply	other threads:[~2009-11-08 21:41 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-06 14:05 gitk : french translation Emmanuel Trillaud
2009-11-06 18:16 ` Thomas Moulard
2009-11-06 20:59   ` Emmanuel Trillaud
2009-11-07  2:54     ` Nicolas Sebrecht
2009-11-08 12:33       ` Matthieu Moy
2009-11-09  1:30         ` Nicolas Pitre
2009-11-09  8:39           ` [OT] " Matthieu Moy
2009-11-09  9:24             ` Maximilien Noal
2009-11-08 17:55       ` Emmanuel Trillaud
2009-11-08 21:41         ` Nicolas Sebrecht [this message]
2009-11-08 23:11           ` Maximilien Noal
2009-11-08 23:15             ` Maximilien Noal
2009-11-09  1:24             ` Nicolas Sebrecht
2009-11-10 17:45 ` Emmanuel Trillaud
2009-11-10 21:02   ` Nicolas Sebrecht
2009-11-11  0:10   ` Nicolas Sebrecht
2009-11-11 14:15     ` Thomas Moulard
2009-11-11 16:59       ` Nicolas Sebrecht
2009-11-11 17:10       ` Emmanuel Trillaud
2009-11-19 19:47     ` Emmanuel Trillaud
2009-11-19 20:01       ` Emmanuel Trillaud
2009-11-19 21:23         ` [PATCHv4] gitk " Emmanuel Trillaud
2009-11-19 23:57           ` [PATCHv4] " Nicolas Sebrecht
2009-11-20  0:28             ` Emmanuel Trillaud
2009-12-02 10:24     ` gitk : " Emmanuel Trillaud
     [not found]       ` <c558c59b3fe779e8577fe06233d3da5d2711127f.1259795550.git.ni.s@laposte.net>
2009-12-29 22:39         ` [RESEND PATCH] french translation of gitk Nicolas Sebrecht
2010-01-08 13:22           ` Emmanuel Trillaud
2010-01-12 11:21             ` Paul Mackerras
2010-01-12 13:02               ` Emmanuel Trillaud
2010-01-28 13:23                 ` Emmanuel Trillaud
2009-11-10 18:05 ` gitk : french translation Emmanuel Trillaud
2009-11-10 20:47   ` Nicolas Sebrecht
2009-11-11  1:10     ` Emmanuel Trillaud

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20091108214130.GA12931@vidovic \
    --to=nicolas.s.dev@gmx.fr \
    --cc=etrillaud@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=thomas.moulard@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.