You are viewing a plain text version of this content. The canonical link for it is here.
Posted to docs@httpd.apache.org by Mi...@telekurs.de on 2004/01/12 20:48:49 UTC

Re: German translation mod_negotiation




> <p>Bei der Content Negotiation oder Anpassung einer Antwort

Apache doesn't "adapt" (anpassen) the response.
IMHO this sounds like Apache would modify the content itself
(like a filter would do that, for example).

Apache selects (auswählen) one of several possible responses
(if possible; the user's data might turn out insufficient
for a distinct choice, see below).

> an die

Make that "gemäß der".

> <code>type-map</code>), die die Dateien mit den unterschiedlichen

For readability's sake: "die die" => "welche die".

> <li>Eine MultiView-Suche (aktiviert &uuml;ber die
> <directive module="core">Option </directive>

The logic of the sentence requires "Option" to be singular.

Yet, the Apache directive that this points to is "Options",
i. e. plural.
So either the link or the logic of the sentence must be broken.

This problem is already there in the English version, so
this is no translation issue - it should be corrected in
the original.

> <code>MultiViews</code>), bei der der Server nach einem

Again: "bei der der" => "bei welcher der".

> <code>MultiViews</code>), bei der der Server nach einem
> Dateinamensmuster sucht und eine Ergebnisliste zusammenstellt.</li>

The most important part is missing here.
Apache doesn't just create a result list, it attempts to
select one item from this list - if the user's preferences
were distinct enough.

So this should be:

"<code>MultiViews</code>, bei welcher der Server einen
impliziten Mustervergleich des Dateinamens und innerhalb
der Ergebnisse (dieses Vergleichs) eine Auswahl durchführt."

This is very vague, and it has to be this way, as the
mechanism of selection that is to be described here is not
only complex but may even fail to have a result.
Therefore we must not even say "and selects one of the
results" here - because that might not be possible.

> Ein Header-Datensatz enth&auml;lt ein Schl&uuml;sselwort und
> einen Wert, die durch einen Doppelpunkt voneinander getrennt
> werden.

This might be close to the original but the English version
implied that the colon were part of the keyword, while your
translation makes the colon a separator between keyword and
value. This might break other parts of the document...

> Innerhalb des Header-Datensatzes d&uuml;rfen zwischen den
> einzelnen Elementen Leerzeichen stehen.

... and this is happening in the very next line already.

According to your text whitespace would be legal between
keyword and colon, while the English version ruled this out.

So which one of these different semantics is the correct one?

> <dt><code>Content-Encoding:</code></dt>
> <dd>Das Komprimierungsverfahren der Datei.

Nope, but "Das auf diese Datei angewendete Kodierungsverfahren."
It _can_ be compression, but it _can_ be something else as well.
("Encoding" has a lot of potential fields of application.)

> Apache erkennt nur Komprimierungsverfahren,

Again: "Kodierungsverfahren".

> Normalerweise geh&ouml;ren hierzu die Optionen <code>x-compress</code>
> und <code>x-gzip</code>.

The English version is a bit more explicit about the meaning
of these values; yet it uses the values of these options as
verbs within the sentence itself in a tricky way which cannot
be done this way in any other language.
So your reduced translation might be a good approximation.

> Der Pr&auml;fix <code>x-</code> wird bei Vergleichen ignoriert.</dd>

The English version restricted this to comparisons of encodings
only.
It _might_ be implicitly clear as this line is part of the
"Content-Encoding" paragraph, yet the English version was more
precise.

> <dd>Die Sprachevariante(n) angegeben mit dem standardm&auml;&szlig;igen
> Sprache-Tag (<a href="http://www.ietf.org/rfc/rfc1766.txt"

I would use "angegeben mit dem Internet-Standard-Sprach-Tag (RFC1766)".



A short note about the English version:

> Content-Length:
> The length of the file, in bytes. If this header is not present,
> then the actual length of the file is used.

I am not sure which "actual length of the file" is meant here.
Consider compression being applied dynamically, and two alter-
native files would compress differently.

So file A might be smaller than file B before compression, but
after compression this relation might reverse, meaning that
Apache would actually negotiate the "wrong" version of the file
- can this actually happen?



> und anderen Parametern ein Semikolon getrennt. Die Syntax lautet

Rather: "Ihre Syntax lautet".
By splitting up the sentence in two you lost the implicit
reference here.

> gebr&auml;cuhlichen Parametern

Typo: "gebr&auml;cuhlichen" => "gebr&auml;uchlichen"

> F&uuml;r <code>text/html</code> ist dies <code>2</code>, sonst

Nope, but: "Für text/html hat diese den Standardwert 2, sonst...".
It may well have different values.

> ohne R&uuml;cksicht auf die M&ouml;glichkeiten des Clients capabilities.

The last word of this line should be deleted.

> Handelt es sich hingegen um eine reine ASCII-Darstellung,

I am not sure that this is a good translation of "ASCII art",
because the "art" aspect has been lost completely.
("ASCII art" is a way to display a picture by ASCII character in
an "artsy" way; if there were only text to be displayed then ASCII
and JPEG would rarely be alternatives, except from a client that
cannot display graphics at all.)

> Medientyps, verschl&uuml;sselt nach der angegebenen Inhaltskodierung).

I would prefer "kodiert" to "verschlüsselt".
("encoded" doesn't necessary mean "encrypted".)

> Hierbei handelt es sich um URLs relativ zu Map-Datei

"zu" => "zur".

> (sie m&uuml;ssen auf den gleichen Server (!) sowie auf Dateien verweisen,
> f&uuml;r die der Client Zugriffsrechte haben muss, wenn sie direkt
> angefordert w&uuml;rden.</dd>

The map doesn't "refer" to a server, but it _resides_ on a server.

So this should be:

"sie müssen auf demselben Server (!) _liegen_ wie die Map-Datei,
und sie müssen ... verweisen ..."

> <dd>Neu in Apache 2.0, der tats&auml;chliche Inhalt der Ressource kann
> in der Type-Map-Datei mit dem <code>Body</code>-Header angegeben werden.

I would write:

"Seit (der Version) Apache 2.0 kann der tatsächliche...".

> Dieser Header muss eine Zeichenfolge enthalten, die
> die ein Begrenzungszeichen f&uuml;r den Rumpfinhalt angibt.

Did I mention that I hate these "die die" forms?
(Standard word processing software automatically considers
this type of duplication an error, and for a valid reason.)

This is a case when the duplication actually is an error,
ant this was not recognized because all of the other usages
of this type of formulation.
So remove one "die", or rather replace both of them by "welche".

And I would prefer "festlegt" to "angibt".

> <p>Eine MultiView-Suche &uuml;ber die <code>MultiViews</code>
> <directive module="core">-Option</directive> aktiviert.

The verb is missing. (Probably "wird", to be inserted after "Suche".)

> Auf diese Weise erzeugt ein k&uuml;nstliches Type-Map

Difficult to say, but I tend to treat "map" as female in German,
which would make "ein" => "eine".

> und sendet das Dokument.</p>

The "that" of the English version would be a bit more referencing
to the previous line; so maybe write "und sendet das entsprechende
Dokument" here.

> <description>Erm&ouml;glicht das Caching von Dateien,

Not "ermöglicht" (enables), but "erlaubt" (allows).

Caching by proxies cannot be "disabled", it can only be "forbidden"
(letting you hope that the proxy abides by the rules of HTTP then,
which you can't be sure about).

> allerdings ist das Caching effizienter.</p>

I would insert a full stop or semicolon before this and then write
"allerdings wird dadurch das Caching (durch den Proxy) effizienter."

"caching" is a little underspecified here.
Yes, we are in the context of proxy server, yet it might be better to
explain that browser caching is totally unaffected by this mechanism.

> HTTP/1.1 bietet bei der Content Negotiation bessere M&ouml;glichkeiten
> f&uuml;r die Kontrolle des Caching.

I would have it the other way round:
"HTTP/1.1 bietet bessere Möglichkeiten für das Caching von via
Content Negotiation ausgelieferten Dokumenten."

> <description>Entscheidung f&uuml;r den Fall, dass kein passendes Dokument
> gefunden wird.</description>

"Entscheidung" => "Durchzuführende Aktion".

> <p>Die <directive>ForceLanguagePriority</directive>-Direktive verwendet
> die vorhandene Direktive
> <directive module="mod_negotiation">LanguagePriority</directive>,

This is a very difficult line in the English original.

First of all, the author "toyed around" with a technical term as
element of the sentence's syntax.
"LanguagePriority" is used as the object of the sentence, but it
means the language priority (semantics), not the directive that
has been used to specify (syntax).
Still there _is_ such a directive, and consequently the English
version has a link to it.
So I would remove the word "Direktive" in the German version and
hope that the reader still understands what "LanguagePriority"
wants to tell him.

Or maybe write it this way:

"die vorhandene
<directive module="mod_negotiation">LanguagePriority</directive>
(Sprach-Priorität), um ..."

which would cover all the aspects of the English original.

> um eine Entscheidung zu treffen, wenn der Server keine
> &Uuml;bereinstimmung f&uuml;r die Anfrage finden kann.</p>

Not exactly.

Content Negotiation isn't about finding a "match", it is about
trying to find a "best bet", which includes failing to be able
to do so.

I would translate it as

"um eine Entscheidung zu treffen, falls der Server andernfalls
keine eindeutige Wahl (eines 'besten' Dokuments) treffen kann."

> <code>LanguagePriority</code>, um ein brauchbares Ergebnis und

"valid" would rather be "gültig" instead of "brauchbar" (usable).
(HTTP status codes 300 and 406 are no "valid" result of the
ressource to be requested, they only tell you about the failure
of the negotiation process.)

> <p><code>ForceLanguagePriority Fallback</code> liefert in Verbindung
> mit der Direktive
> <directive module="mod_negotiation">LanguagePriority</directive> ein
> brauchbares Ergebnis anstatt der Antwort <code>Status 406
> (NOT ACCEPTABLE)</code> zur&uuml;ck.

Many of what I write above applies here as well, about "Direktive"
and "brauchbar".

> L&auml;sst die <code>Accept-Language</code>-Anweisung der Antwort
> nur <code>es</code> zu,

Literally: "nur eine Antwort in der Sprache <code>es</code> zu"
(which would be spanish IIRC).

> <description>Auszuw&auml;hlende Sprachevariante falls der Client

Two typos: "Sprachevariante" => "Sprachvariante,"

> welche der Sprachevarianten

Again I would prefer "Sprachvariante".

> Die <var>MIME-lang</var>-Liste f&uuml;hrt die Priorit&auml;ten in
> absteigender Reihenfolge auf.</p>

The list doesn't contain the priorities, it contains the languages
(ordered by descending priority). Thus:

"Die <var>MIME-lang</var>-Liste f&uuml;hrt die Sprachen in absteigender
Reihenfolge ihrer Priorit&auml;ten auf.</p>

> oder wenn die
> <directive module="mod_negotiation">ForceLanguagePriority</directive>
-Direktive
> auf <code>None</code> gesetzt wurde.

Quote the opposite: "oder wenn die ... nicht (!) auf "None" gesetzt
wurde. (It if _had_ been set to "None" then this would removed the
second possible reason for this mechanism to be used.)

> Bei korrekt ausgef&uuml;hrten HTTP/1.1-Anfragen hazt diese Direktive
> ebenfalls keine Auswirkungen.</p>

Typo: "hazt" => "hat".
(By the way, this line is not part of the English V2.1 online version.)





Regards, Michael


---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org


Content-length negotiation

Posted by André Malo <nd...@perlig.de>.
* Michael.Schroepl@telekurs.de wrote:

> A short note about the English version:
> 
> > Content-Length:
> > The length of the file, in bytes. If this header is not present,
> > then the actual length of the file is used.
> 
> I am not sure which "actual length of the file" is meant here.
> Consider compression being applied dynamically, and two alter-
> native files would compress differently.
> 
> So file A might be smaller than file B before compression, but
> after compression this relation might reverse, meaning that
> Apache would actually negotiate the "wrong" version of the file
> - can this actually happen?

Yes. mod_negotiation doesn't know anything about filters afterwards and the
standard requires this behaviour (iirc).

nd

---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org