git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Rast <trast@student.ethz.ch>
To: Jiang Xin <worldhello.net@gmail.com>,
	Ralf Thielow <ralf.thielow@googlemail.com>
Cc: "Junio C Hamano" <gitster@pobox.com>,
	"Git List" <git@vger.kernel.org>, "Jan Krüger" <jk@jk.gs>
Subject: Re: Please pull git-po master branch
Date: Wed, 2 May 2012 09:54:20 +0200	[thread overview]
Message-ID: <87d36n2f2r.fsf@thomas.inf.ethz.ch> (raw)
In-Reply-To: <CANYiYbHtKKWw9LPnr+1khC5Oms-kOtA2WEucoNoE3Njzqiahzw@mail.gmail.com> (Jiang Xin's message of "Wed, 2 May 2012 10:45:56 +0800")

Hi Xin (is that how you are properly addressed?)
Hi Ralf

Jiang Xin <worldhello.net@gmail.com> writes:
> Ralf Thielow (3):
>       l10n: Add the German translation team and initialize de.po
>       l10n: Initial German translation
>       l10n: Update German translation

Junio C Hamano <gitster@pobox.com> writes:
> Both branches pulled; I found it somewhat iffy to *add* new language support
> on the maintenance track, but decided to let it pass this time.
> 
> A new lang.po file is very unlikely to introduce regression to anybody
> else, so it probably is OK.

Objection.

Jan "jast" Krüger and me had most of the following "in the works", and
couldn't get it shaped up before the pull request went out.  Any
translation mistakes are mine, we drafted it in German.

Consider this addressed to Ralf w.r.t. the content, but I think it
constitutes a general argument as to why a new translation should *not*
be merged and immediately released, much less in the maintenance track.


We (Jan and me) looked at your translation while it was WIP at [1].  We
have both toyed with translating Git to German, and got stuck with some
pitfalls.

To put it bluntly, we have significant concerns with your translation so
far.  That's usually not a problem in OSS -- release early and release
and release often -- but the maint release would require you to get it
Right(tm) the first time.

The basic issues correlate with those found in many translations of
non-professionals.  (We wrote the list while looking at the WIP version
5c98748a2.  I have briefly checked that the points mentioned here are
still in the released version, but may have missed many other changes.)

* One tends to stick too closely to the English text, frequently missing
  an opportunity to completely restructure sentences.  In some cases the
  translation may be outright wrong, even though the words are correctly
  translated.

  Example, if a bit harmless:
    Original: "If you are sure you want to delete it, [...]"
    Your translation: "Wenn du sicher bist diesen Zweig zu entfernen, [...]"
    Alternative: "Wenn du ihn wirklich entfernen willst, [...]"

* Frequently there is an ambiguity, or overloading of terms, in one or
  both languages.  The context (of the original message) will make clear
  *for the translator* what the meaning is, but it may be lost on the
  user.

  A related issue is when a single word splits into several in German.

  Examples:

  "commit" -> "Eintrag/Version/eintragen"
  "committer" -> "Einreicher/Eintragender"
  "remote" -> "entfernt" (weg? Aber ich hab's doch gar nicht gelöscht...?)
  "tracked/untracked" -> "verfolgt/unverfolgt" (Paranoia? "Unverfolgt" ist
      zudem nicht unbedingt ein Wort aus dem Sprachgebrauch)

* Translating technical terms may turn them into something that is
  completely unknown to anybody in German.

  Examples:

  "commit" -> usually translated simply as "Commit", e.g. in the SVN Red
              Book

  "staging area/index/stage" -> "Bereitstellung/bereitstellen" is
      correct (e.g. in military usage), but gives the user little
      intuition.  "Index" isn't good either (same issue as in the
      original).  We don't have a really good idea either, and haven't
      heard of one.  However, this is one of the most important
      translations: the index is very central to git, but few users know
      it already.  You can try finding a good term (perhaps taking some
      liberties) but otherwise "Index" may be the lesser evil.

      On a related note, an earlier unfinished translation translated
      "to stage" as "vormerken".  We think that captures the essence
      very nicely.  It then tried to completely avoid referring to the
      index as a noun.

* The translator may not be sufficiently familiar with the context
  and the tool to correctly translate.

  Example:
  Original: Cloning into bare repository '%s'...
  Translation: Klone in leeres Projektarchiv '%s'...
  [for non German speakers: "leer" means "empty"]
  "bare" denotes a repository that does not have a worktree associated
  with it.  It is *not* usually empty.


Please don't take this personal.  We are happy that you picked up the
effort of translating it, since all previous efforts have stalled.
It's also a bit too late now for the German translation, since it has
already been released.

However, we do feel that git is so complex and has so much confusing
(not your fault really) terminology associated with it that translations
should not go straight from translator to release.

Some ideas on how we can do better in the next language, and proceed
from here:

* Make a glossary of the relevant terminology first.  Sadly
  gitglossary(7) has gotten somewhat stale, and perhaps can also benefit
  from an overhaul.  Ævar Arnfjörð Bjarmason recently made a list[4] of
  the most important terms, which is a good start.

* If you are interested in collaboration, IRC may be a good choice for
  the many little questions that probably arise?  We hang out in
  #git-devel on Freenode[3].  Email is of course also an option, but
  more time-consuming.

Note that in the context of Git, a major problem is that the
documentation and books are only available in English.  There isn't even
a glossary.  For example, you translated "detached" as "losgelöst".
From our experience the detached HEAD is something that users stumble
into, rather than learn about beforehand.  They usually come crying for
help when they've already lost their work in the "void" of unreachable
commits.  Now put yourself into the position of a user.  Where can he
look up what the root of his problem is?  At least for "detached HEAD"
there is a wealth of blog posts that rescue the poor user.

We think -- pardon the strong words -- that your current draft
translation makes things harder, not easier, for German users.  The
issues mentioned above, especially when it comes to ambiguities, splits
into several terms and mistakes, add up to considerable bad weather, and
the lack of reference material leaves the user out in the rain.

Of course now that it has been released, we'll also have to file patches
in the true open source spirit.  Sigh.

Regards / Liebe Grüsse
Thomas

-- 
Thomas Rast
trast@{inf,student}.ethz.ch

  parent reply	other threads:[~2012-05-02  7:54 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-02  2:45 Please pull git-po master branch Jiang Xin
2012-05-02  5:17 ` Junio C Hamano
2012-05-02  7:54 ` Thomas Rast [this message]
2012-05-02  9:13   ` Ralf Thielow
2012-05-02 13:58     ` Thomas Rast
2012-05-02 19:14       ` Ralf Thielow
2012-05-02 19:44         ` Christian Stimming
2012-05-02 13:49   ` [PATCH 0/5] de.po suggested updates Thomas Rast
2012-05-02 13:49     ` [PATCH 1/5] stash: make "saved" message translatable Thomas Rast
2012-05-02 16:42       ` Junio C Hamano
2012-05-02 13:49     ` [PATCH de.po 2/5] de.po: translate "bare" as "bloß" Thomas Rast
2012-05-02 13:49     ` [PATCH de.po 3/5] de.po: hopefully uncontroversial fixes Thomas Rast
2012-05-02 13:49     ` [PATCH de.po 4/5] de.po: translate "bad" as "ungültig" ("invalid") Thomas Rast
2012-05-02 13:49     ` [PATCH de.po 5/5] de.po: collection of suggestions Thomas Rast
2012-05-02 18:36       ` Ralf Thielow
2012-05-02 19:43         ` Thomas Rast
2012-05-02 19:42       ` Christian Stimming
2012-05-03  7:42         ` Thomas Rast
2012-05-03 13:12           ` [PATCH on ab/i18n] branch: remove lego in i18n tracking info strings Nguyễn Thái Ngọc Duy
2012-05-04 16:10             ` Junio C Hamano
2012-05-06 13:06               ` Nguyen Thai Ngoc Duy
2012-05-02 17:52     ` [PATCH 0/5] de.po suggested updates Ralf Thielow
2012-05-02 19:13     ` Christian Stimming
2012-05-02 16:40   ` Please pull git-po master branch Junio C Hamano
2012-05-03  4:31     ` Jiang Xin
2012-05-03  6:47       ` Junio C Hamano
2012-05-03 10:19         ` Jiang Xin
2012-05-03  7:49       ` Thomas Rast

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=87d36n2f2r.fsf@thomas.inf.ethz.ch \
    --to=trast@student.ethz.ch \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jk@jk.gs \
    --cc=ralf.thielow@googlemail.com \
    --cc=worldhello.net@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).