Hi Xin (is that how you are properly addressed?)
Hi Ralf
Jiang Xin <worldhello.net@xxxxxxxxx> 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@xxxxxxxxx> 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
--
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