git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Please pull git-po master branch

From
Thomas Rast <trast@student.ethz.ch>
Date
May 2, 2012, 07:54 UTC
Message-ID
<87d36n2f2r.fsf@thomas.inf.ethz.ch>
In-Reply-To
<CANYiYbHtKKWw9LPnr+1khC5Oms-kOtA2WEucoNoE3Njzqiahzw@mail.gmail.com>

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:
Show 5 quoted lines
> 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
Previous: Junio C HamanoNext: Ralf Thielow
Message 3 of 28 in “Please pull git-po master branch”
  1. Jiang XinMay 2, 2012
  2. Junio C HamanoMay 2, 2012
  3. Thomas RastMay 2, 2012
  4. Ralf ThielowMay 2, 2012
  5. Thomas RastMay 2, 2012
  6. Ralf ThielowMay 2, 2012
  7. Christian StimmingMay 2, 2012
  8. 0/5 de.po suggested updatesThomas Rast, May 2, 2012
  9. 1/5 stash: make "saved" message translatableThomas Rast, May 2, 2012
  10. Junio C HamanoMay 2, 2012
  11. 2/5 de.po: translate "bare" as "bloß"Thomas Rast, May 2, 2012
  12. 3/5 de.po: hopefully uncontroversial fixesThomas Rast, May 2, 2012
  13. 4/5 de.po: translate "bad" as "ungültig" ("invalid")Thomas Rast, May 2, 2012
  14. 5/5 de.po: collection of suggestionsThomas Rast, May 2, 2012
  15. Ralf ThielowMay 2, 2012
  16. Thomas RastMay 2, 2012
  17. Christian StimmingMay 2, 2012
  18. Thomas RastMay 3, 2012
  19. branch: remove lego in i18n tracking info stringsNguyễn Thái Ngọc Duy, May 3, 2012
  20. Junio C HamanoMay 4, 2012
  21. Nguyen Thai Ngoc DuyMay 6, 2012
  22. Ralf ThielowMay 2, 2012
  23. Christian StimmingMay 2, 2012
  24. Junio C HamanoMay 2, 2012
  25. Jiang XinMay 3, 2012
  26. Junio C HamanoMay 3, 2012
  27. Jiang XinMay 3, 2012
  28. Thomas RastMay 3, 2012

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.